How escrow works here

The happy path

1. DRAFTAgreement being created
2. AWAITING ACCEPTANCECounterparty reviews the terms
3. ACCEPTEDBoth parties agreed
4. AWAITING FUNDINGBuyer preparing the transaction
5. FUNDEDEscrow received expected funds
6. IN PROGRESSSeller is working
7. AWAITING APPROVALBuyer reviews the delivery
8. RELEASEDPayment transferred

Off the happy path: REFUND REQUESTED DISPUTED RESOLVED CANCELLED. See the dispute policy.

Guarantees

• Both parties sign the same SHA-256 agreement hash. Any edit after sending changes the hash and invalidates acceptances.
• Fees are snapshotted into the agreement. Publishing a new fee schedule never affects accepted deals.
• Only a verified on-chain event (the indexer) can mark a deal funded. A frontend message cannot.
• Each milestone releases only its own allocation. Released funds are final.
• The arbiter can split the escrowed balance between buyer and seller and nothing else. Admins have no withdrawal power.
• Pausing blocks new deposits only. Releases, refunds, and settlements always remain available.
• After the deadline, with no pending delivery, the buyer can reclaim. Funds can never be locked forever.
• Only SOL and the canonical USDC mint are accepted. Any other mint is rejected.

Architecture

Next.js app

UI, deal wizard, deal rooms. Never decides that money moved.

Escrow program (Anchor)

Holds funds in a PDA vault. The only authority for balances and settlement.

Indexer

Watches program events, verifies them, and updates app records idempotently.

Supabase

Off-chain metadata: profiles, listings, messages, evidence, audit log. Row-level security on every table.

Source for the Anchor program lives in programs/escrow, database migrations in supabase/migrations, and setup, devnet, and deployment guides in README.md.