Self-Custodial Creator Infrastructure with On-Chain Escrow

The commercial problem

Independent creators — writers, artists, freelancers, consultants, niche-software developers — depend on a stack of platforms that can drop them with no appeal: Linktree-style link aggregators, Stripe and PayPal for payments, social platforms for distribution. The structural vulnerabilities are now well-documented.

The market response has been creator-economy platforms that solve the bio-link problem but inherit the same payment-platform dependencies underneath. Linktree-on-Stripe is still Linktree-on-Stripe.

What was missing is a primitive that does three things at once: a censorship-resistant profile that lives on-chain, direct creator-to-fan payments with no platform float, and escrow automation for the work-for-hire and paid-content cases where payment-on-promise needs to become payment-on-delivery without a human arbiter.

The system shipped

A Solana program plus a reference frontend. Creators claim a handle, connect a wallet, and ship a public profile in under a minute. The profile supports three payment primitives.

Direct support

Visitors send SOL or USDC straight to the creator's wallet. No payout schedule, no holds, no minimum. Settlement is on-chain at network finality.

Paid links

A creator can paywall any URL behind a fixed price. Buyer pays in SOL; the URL reveals on-chain payment confirmation. Up to eight link slots per profile, freely mixed between free and paid.

Timed deposits with dispute window

This is the primitive that matters for client work. A buyer locks SOL into an escrow account with a configurable dispute window. The creator delivers the work; if the buyer is satisfied, they release the funds. If the creator does not deliver within the window, the buyer reclaims their SOL automatically — no support ticket, no platform arbitration, no PayPal-style indefinite hold. The same primitive, deployed at scale, is procurement settlement for an enterprise.

Economics

Architecture choices that mattered

The contract is the source of truth; the frontend is one viewer. The protocol's program ID is published. Anyone can build a different frontend on the same on-chain data; the official frontend has no privileged access. This is what makes the censorship-resistance claim real — even if the operator's domain is taken down, profiles remain on-chain and addressable through any other client.

Open source with a published audit tag. The program is open source on GitHub with a tagged audit release. A buyer of this kind of infrastructure does not have to trust the operator; they can read the code and the audit and decide for themselves.

Frontend-only content moderation. The operator reserves the right to remove profiles from the official frontend that violate content policy, but the underlying on-chain data is not affected. This is the only honest position: the protocol cannot moderate what it does not control, and the frontend should be transparent about the moderation it does perform.

Self-custodial by construction. No private keys ever leave the user's wallet; the protocol does not custody funds at any point. Direct-send payments hit the creator's wallet directly. Escrowed payments sit in a program-derived account that only the participants can release.

Timed-deposit as a first-class primitive, not an add-on. The escrow logic is part of the core program, not a separate optional contract. This matters because it means escrow has the same security review as the rest of the protocol and the same composability story.

How it compares to the existing stack

What this proves about the firm

We ship escrow as infrastructure, not as a feature. The timed-deposit primitive is what most clients actually need from a Web3 procurement engagement, generalized into a public protocol so we can show how it behaves in production.

We operate where on-chain meets jurisdictional reality. The frontend-versus-protocol moderation distinction is exactly the conversation we have with corporate counsel on every client engagement. Building it cleanly into a public reference is faster than explaining it on a call.

We publish enough that buyers can verify the claim. Open-source code, published audit tag, on-chain program ID — every line of the marketing copy maps to something a CTO can check. This is the standard we hold client deliverables to.

What we extract for client work

For asset managers, marketplaces, professional service firms, and any institution that needs payment-on-delivery without a third-party custodian, this reference establishes the production pattern. Common client extensions:

• ·Procurement settlement — buyer locks funds, supplier delivers, automatic release on milestone
• ·Commission distribution — multi-party splits on every settled transaction (sales agent, manager, house)
• ·Credential issuance and verification — the same on-chain registry primitives used here for handles, deployed for professional credentials, certifications, and document attestations
• ·Tipping and patronage rails for media properties needing creator-to-fan flows without a payment processor in the middle

Engagement type: Pilot Launch (Package B) for a single workflow, Transformation Program (Package C) for organization-wide procurement migration.