- Six-state machine (Draft → Funds committed → Active → Disputed ⇄ Settlement offered → Settled), each state a distinct signed contract, not a status field
- Tripartite signatory authority (Depositor, Beneficiary, and the escrow agent) on every material transition, with Mediator escalation on dispute and a binding-arbitration path once mediation is exhausted. The escrow agent, which checks and directs each release, and the asset custodian, which holds the money and executes the release, can be separate institutions or one
- Complex topologies: weighted multi-beneficiary payout, recurring and access-gated escrow, and parent/child contract aggregation (all-children-settled or any-child-settled rules) for related shipments or tranches
- Two clearing modes selected at signing and fixed for the life of the contract: progressive (each milestone releases independently) or all-or-none (nothing releases until every milestone clears)
- Zero-fee off-chain negotiation layer for terms and milestones before anything is committed to the ledger, with bilateral ratification required for on-chain promotion
- Four-eyes separation between the party who drafts terms and the party authorized to commit funds: a preparer role can never unilaterally fund a contract
- Structured disputes: a dispute is filed with a reason, a narrative and supporting evidence from the start, and a missed performance deadline routes to mediation, never to a unilateral refund
- The mediator’s fee is agreed in the contract at signing, not chosen once a dispute arises; settlements are allocated by percentage, so every unit of the escrowed amount is accounted for
- Cancellation needs every depositor and beneficiary to approve, then any one of them can carry it out: no single party can cancel alone
- A printable progress and completion report for each escrow, for the parties’ own records
- Escrow history: every escrow a party is on, closed ones included, searchable by status, state, counterparty, currency and amount, each with a timeline of every state it passed through and the step that moved it. Each party sees exactly what the ledger shows it; the history is a rebuildable index of the ledger, and every action still reads the ledger itself
← Back to Tripart overview
Platform capabilities
Escrow Contract Lifecycle
LiveThe contract's state and every party's authority to change it are enforced by the ledger, not by application code. Each lifecycle state is its own contract template with its own signatories and controllers, so an unauthorized transition is rejected by the network before it can ever reach the application layer.