Problem Statement: Conditional Custody Between Strangers
Frames escrow as an on-chain custody state machine with an off-chain coordination and arbitration layer, not a payments CRUD app.
Problem statement
Design a crypto escrow service that locks buyer funds in a smart contract until a trade completes. The buyer funds the escrow, the seller ships goods or transfers an off-chain asset (a domain, a service, a physical item), both parties confirm, and only then do funds release to the seller. If they disagree, a mediator arbitrates and can split the balance. If nobody disputes inside a published window, funds auto-release. Every transition must be resistant to double spend, forced release, replay, and mediator failure, and every dispute resolution must be logged immutably.
The defining property is that custody truth lives on-chain. The contract balance and its state variables are the source of truth; everything off-chain—orders, notifications, evidence files, dashboards, compliance holds—is a projection or a coordination aid. This inverts the usual web architecture: the database does not own the money, the consensus layer does. Therefore the off-chain platform must never promise an action it cannot execute on-chain, and must treat chain finality, reorgs, gas spikes, and token quirks as first-class failure modes.
Why the problem is distinctive
A normal payment system retries a failed write. Here a retry can double-release funds. A normal system's administrator can correct a bad row. Here no admin key may silently move customer funds, or the escrow is custodial in disguise. The design therefore separates four planes: the contract plane (on-chain state machine and token custody), the coordination plane (orders, webhooks, notifications, evidence), the arbitration plane (disputes, mediator assignment, SLA timers, appeals), and the governance plane (asset whitelists, compliance holds, upgrades, key ceremony). A strong interview answer keeps these planes separate and states which decisions are enforceable on-chain versus merely recorded off-chain.
Public operating baseline versus design assumptions
Public evidence shows the category is real. OpenBazaar ran Bitcoin 2-of-3 multisig escrow with third-party moderators at marketplace scale before shutting down in 2021. Bisq operates peer-to-peer settlement with 2-of-2 multisig, security deposits, and mediator-based dispute handling. Escrow.com is a licensed custodial escrow company that reports billions of dollars of protected transactions per year and exposes a public REST API. These are cited public facts about other systems, not requirements for ours. For capacity planning this answer explicitly assumes a mature platform with 1.2 million escrows created per year, 120,000 concurrently open escrows, 3.8 million on-chain transactions per year across three chains, and a 5x event peak. Unless tied to a citation, every number is a stated design assumption, budget, or target.
Key Highlights
- •On-chain contract state owns custody; the off-chain database owns coordination, evidence, and projections only.
- •Four planes: contract, coordination, arbitration, governance; each has a different authority and failure model.
- •Retries are dangerous: release and refund paths must be idempotent against chain events, not HTTP calls.
- •Public systems (OpenBazaar multisig, Bisq deposits, Escrow.com licensing) prove the category; our numbers remain explicit assumptions.
- •A safe unresolved escrow returns funds by published rule; silence must never freeze money forever.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate what the chain enforces from what the platform merely records before choosing components."
- "I will state the custody authority boundary first, because every later failure mode derives from it."