From Bitrated's 2-of-3 multisig to smart-contract escrow: how trustless escrow actually works

Back in 2014, Bitrated did something clever: it let two strangers trade Bitcoin without either of them, or the platform, holding the money. A decade later the site is widely described as inactive, but the design problem it solved hasn't gone anywhere. Freelancers, OTC traders and domain buyers still need a way to say "I'll pay, but only when you deliver" without trusting a middleman with the funds.

This post walks through how Bitrated's model worked at the protocol level, where it broke down in practice, and how the same idea looks when you move it from a Bitcoin multisig script into a smart contract.

How Bitrated escrow worked: a 2-of-3 multisig

Bitrated never held coins. Each trade created a pay-to-script-hash (P2SH) address controlled by three keys:

• the buyer
• the seller
• an arbitrator the two parties chose from a marketplace

The redeem script looked roughly like this:

OP_2 <buyer_pubkey> <seller_pubkey> <arbitrator_pubkey> OP_3 OP_CHECKMULTISIG

Any two of the three signatures could spend the output. That gives you three paths:

1. Happy path: buyer and seller both sign, and the funds go to the seller. The arbitrator never sees the trade.
2. Buyer wins a dispute: buyer and arbitrator sign a refund.
3. Seller wins a dispute: seller and arbitrator sign the release.

The elegant part is that the platform is not in the signing set at all. Even if Bitrated disappeared, the coins would still sit in a standard multisig address on the Bitcoin blockchain, recoverable by any two key holders with a wallet that can import the redeem script (Sparrow and Electrum both can).

Where the model struggled

The cryptography was fine. The problems were operational:

• Finding an arbitrator. The 2-of-3 design only works if the third key belongs to someone who is still around and still responsive when the dispute happens. As the marketplace thinned out, that stopped being a safe assumption.
• Volatility during disputes. A trade priced in BTC can move 10% while two people argue over a delivery. Whoever benefits from the price move has a reason to stall.
• No programmable exits. A multisig has no clock. If the buyer simply goes silent, the seller needs the arbitrator to act; there is no built-in "release after N days" rule.
• Bitcoin only. No stablecoins, so every deal carried price risk by default.

The same idea as a smart contract

A smart-contract escrow keeps the core property, that no operator holds the funds, but replaces "any two of three keys" with explicit rules in code. A minimal version is a small state machine:

enum State { Funded, Released, Refunded, Disputed, Resolved }

function release() external onlyBuyer inState(State.Funded) {
    state = State.Released;
    token.transfer(seller, amount);
}

function claimAfterTimeout() external onlySeller inState(State.Funded) {
    require(block.timestamp >= deadline, "review window still open");
    state = State.Released;
    token.transfer(seller, amount);
}

function raiseDispute() external onlyParty inState(State.Funded) {
    state = State.Disputed;
    // hand the case to an arbitration venue
}

function rule(uint256 ruling) external onlyArbitrator inState(State.Disputed) {
    state = State.Resolved;
    // ruling 1 = pay seller, ruling 2 = refund buyer
}

(Simplified for illustration: a production contract also needs reentrancy protection, a pull-payment ledger instead of direct transfers, and careful handling of fees.)

Compared with the multisig, three things change:

1. Timeouts are first-class. A silent buyer can no longer block the seller forever. The deadline is written into the contract when the escrow is created, so both sides know the rules up front.
2. Stablecoins by default. Escrowing USDC or USDT removes the volatility incentive to stall a dispute.
3. The arbitrator can be a protocol instead of a person. Instead of a single third key, a dispute can be routed to a decentralized court such as Kleros, where jurors are drawn at random and stake tokens on their rulings. Some services also offer a human review panel as an alternative venue; the trade-off there is that you are trusting that panel rather than a jury, so it is worth checking what the panel can and cannot do with the funds.

What to check before you trust any escrow contract

Whether you are picking a service or writing your own, the checklist is short:

• Is it actually non-custodial? The funds should sit in a contract you can inspect, not in a company wallet.
• Is the source verified on the block explorer? You should be able to read the release, refund and timeout logic yourself.
• What happens if one side goes silent? Look for an explicit deadline path, not "contact support".
• Who can rule on a dispute, and what can they do? The ideal answer is "pay the buyer or the seller, and nothing else". No party, including the operator, should be able to send the funds anywhere else.
• What does it settle in? For anything that takes more than a day, stablecoins are the safer default.

Wrapping up

Bitrated proved that escrow doesn't need a custodian. Smart contracts keep that property and fix the parts that wore down over time: timeouts replace absent arbitrators, stablecoins remove the incentive to stall, and decentralized courts replace a marketplace you had to hope was still alive.

If you are moving an old Bitrated trade off the platform, or comparing what replaced it, we put together a longer guide to Bitrated alternatives that covers multisig wallets, smart-contract escrow, custodial services and P2P marketplaces, plus a step-by-step migration playbook for recovering funds from an existing Bitrated multisig.

---

Disclosure: I work on Vaultion, a non-custodial smart-contract escrow. This post was drafted with AI assistance and reviewed before publishing.