What it is
Escrow is one of the oldest ideas in commerce, ported onchain: instead of trusting a counterparty to pay up or deliver as promised, both sides send value to a neutral holding contract first. The contract only releases the funds when some pre-agreed condition is satisfied — a deadline passes, an oracle confirms delivery, a dispute is resolved, or both parties confirm. Nobody has to trust the other party directly; they only have to trust the code (and whatever resolves disputes).
How it works
- Two or more parties agree on terms of a trade or commitment: what's being exchanged, what condition triggers release, and what happens if it isn't met.
- One or both parties deposit the relevant assets (tokens, NFTs, stablecoins) into the escrow contract, which locks them so neither party can unilaterally move them.
- The contract tracks the state of the agreed condition — this might be a simple timer, a signal from an oracle, a multisig confirmation from both parties, or a report from an arbitrator.
- Once the condition is met, the contract executes the release logic automatically: paying out to the seller, refunding the buyer, or splitting funds according to the rules.
- If the condition fails or a dispute arises, the contract falls back to a pre-defined resolution path — a refund after a timeout, an appeal to a designated arbiter, or a vote.
- Throughout, the escrowed assets sit in the contract's balance, not in either party's wallet, which is what makes the guarantee credible: neither side can walk away with both the payment and the goods.
Why designers use it
- Removes the need for a trusted third party (a bank, a platform, a lawyer) to hold funds during a transaction — the contract itself is the trusted intermediary.
- Protects both sides of an exchange from the other reneging: the buyer can't take the goods without paying, and the seller can't take payment without delivering.
- Enables conditional, multi-step transactions (crowdfunding until a goal is hit, auctions until a winner is decided, contests until judged) where funds need to sit safely until an outcome is known.
- Composability: any protocol that needs "hold this until X happens" can reuse the same pattern rather than inventing custom trust arrangements.
Failure modes
- Oracle or arbiter failure: if release depends on an external data feed or a human arbiter, a corrupted, delayed, or unavailable oracle/arbiter can freeze funds indefinitely or release them wrongly.
- Ambiguous conditions: if the release condition isn't precisely specified in code, disputes about "was this actually delivered?" have no clean onchain resolution and end up needing offchain arbitration anyway.
- Stuck funds: bugs in the release logic, or edge cases the designers didn't anticipate, can leave assets permanently locked with no path to withdrawal.
- Griefing by non-cooperation: if release requires both parties to confirm, one side can simply refuse to confirm to hold the other hostage, unless there's a timeout or arbitration fallback.
- Centralized escrow agent risk: if a single admin key or a small multisig controls the release, it reintroduces exactly the trusted-third-party risk escrow is supposed to remove.
What to check before using it
- Make sure the release condition can be verified with the same trust level as the rest of the transaction — don't attach a trustless payment to a trust-requiring release trigger.
- Define an explicit timeout and refund path for every state, so funds can never get permanently stuck if a condition is never met.
- If a dispute-resolution or arbitration step exists, make its process, incentives, and potential for capture clear upfront.
- Test edge cases: partial deposits, one party never confirming, oracle downtime, and conflicting simultaneous claims.
- Have the contract independently audited if it will hold significant value, since escrow contracts are a common target for exploits precisely because they hold funds.