Mints

Escrow

Conditional money. Released only when the condition proves true.

Hold funds against milestones, conditions, or third-party verification. Funds release when the condition proves true — and only then.

Get early accessAPI reference
POST /v1/escrows — create a milestone escrow
POST /v1/escrows
{
  "payer":  "did:oas:l1fe:agent:7f3a…c9e2",
  "payee":  "did:oas:l1fe:agent:9b1d…44f0",
  "amount": "500.00",
  "currency": "USDC",
  "milestones": [
    { "name": "draft", "amount": "200.00" },
    { "name": "final", "amount": "300.00" }
  ]
}

HTTP 201 Created
{
  "id":     "esc_01JXMW…",
  "status": "funded",
  "held":   "500.00 USDC"
}
2+
Milestones in an escrow — no ceiling

Each milestone holds and releases independently. A single escrow can span a whole project.

1
Events per state change — fully auditable

Every funding, condition evaluation, and release is a single immutable event. Nothing is edited in place.

0
Trusted parties required for release

Conditions are evaluated by the platform against verifiable proof. No counterparty can block or force a release.

Milestone lifecycle

From funded to fully settled.

Five states, each a discrete event. Funds move only when conditions prove true — never on a promise, never by counterparty agreement.

Escrow #esc_01JXMW…500.00 USDC · 2 milestones
Draft released · 200.00 USDC

Escrow created

Payer funds the escrow. 500.00 USDC locked. Neither party can unilaterally release.

Draft milestone

Agent submits the draft artifact. 200.00 USDC held for this milestone alone.

Condition evaluated

Platform evaluates the release condition against verifiable proof. No counterparty trust required.

Draft released

Condition met → 200.00 USDC released to payee. 300.00 USDC remains in hold for the final milestone.

Final delivered

Final artifact accepted. Remaining 300.00 USDC released. Escrow closed. Immutable audit trail complete.

Draft milestone

200.00 USDC

Released

Final milestone

300.00 USDC

Pending delivery

Condition gate

Platform evaluates condition on submit.
Release is deterministic — not discretionary.

Illustrative escrow. Amounts and identifiers are representative.

Immutable audit

Every state change is an event, not an edit.

Escrow balances are never written directly. They are the result of replaying a deterministic event log — from funding through every release and closure.

Event streamappend-only
Live
SeqEventTimeBalance
52094
PolicyEnforcedSpend limit re-evaluated for atlas-research
14:31:02
12,840.00
52095
TransferInitiatedvendor-ops → data-sync · 1,200.00 USDC
14:31:09
11,640.00
52096
EscrowReleasedEscrow #e-9a2c released to pay-router
14:31:22
10,240.00
52097
PaymentApprovedatlas-research approved · 340.00 USDC
14:31:35
9,900.00
52098
NetSettlementCompletedCycle #14 · 8 agents · net 12 transfers
14:31:47
9,900.00
replay ↔ any point reconstructable
balances derived, never edited

Illustrative event sequence. Each balance is computed by replaying the event log from origin.

Audit and trust commitmentsEvent log API

What makes Mints escrow different

Conditions, not promises.

01

Milestone releases

Split a payment across deliverables; each milestone releases independently.

02

Conditions, not promises

Release rules are evaluated by the platform against verifiable conditions, not by counterparty goodwill.

03

Full audit trail

Every state change in an escrow is an immutable event you can replay.

Max held across all milestones simultaneously
500USDC
04

Dispute handling built-in

When a condition cannot be automatically evaluated, human-in-the-loop escalation routes to designated approvers — with a full audit chain either way.

05

x402-composable

Escrow flows chain with x402 payments. An agent can fund an escrow and trigger milestone release in the same HTTP round trip.

06

Multi-party support

Escrows are not limited to two parties. Add verifiers, arbiters, or observer accounts — each role is explicit and auditable.

07

Atomic release

A milestone release is a single atomic ledger event. Either it succeeds in full or nothing moves. Partial states are impossible.

A promise is a social contract. A condition is an architectural one. Mints escrow enforces the latter.

— Mints escrow design

Why escrow

Trust in the protocol, not the counterparty.

Mints escrow

Funds held, conditions verified, release deterministic

Ad-hoc conditional payment

Relies on counterparty goodwill and off-chain coordination

✓Funds held at platform layer
✕
✓Conditions evaluated objectively
✕
✓Per-milestone independent release
✕
✓Immutable event audit per state
✕
✓No counterparty trust required
✕
✓API-native, no manual step
◐
vs

API

Release a milestone in one call.

Once a condition is met, release is a single authenticated API call. The response carries the settled amount, the updated escrow state, and the event sequence number — everything needed for reconciliation.

Partial releases, timeouts, and dispute escalation are all first-class operations on the same resource. No workarounds, no side channels.

Full API referenceDeveloper docs
POST /v1/escrows/{id}/milestones/{name}/release
POST /v1/escrows/esc_01JXMW…/milestones/draft/release
{
  "proof": "ipfs://Qm…"  // verifiable artifact reference
}

HTTP 200 OK
{
  "milestone": "draft",
  "released":  "200.00 USDC",
  "seq":        52096,
  "escrow": {
    "id":     "esc_01JXMW…",
    "status": "partial",
    "held":   "300.00 USDC"
  }
}

What pairs with escrow

01

Payments

x402 native HTTP payments that fund or receive escrow releases without a checkout flow.

Payments →
02

Channels

For continuous work rather than discrete deliverables — stream value per second as the agent produces output.

Channels →
03

Accounts

The self-custody account that holds escrow funds. Keys never leave the payer's device — the platform holds the condition lock, not the keys.

Accounts →

Ship conditional payments your agents can depend on.

Mints is in early access. Tell us what you're building — milestone-based, condition-gated, or multi-party.

Get early accessTalk to us