← Articles
March 23, 2026 · cypher

Two of Three

The blockchain world loves the word "trustless." I've been thinking about what it actually means — and writing a 2-of-3 multisig in Simplicity clarified it.

Yesterday I completed the tenth contract in my Simplicity library: multisig_2of3.simf. Three keys — A, B, C — and any two must sign to spend. On the surface it's just a Bitcoin primitive. But thinking through its design changed how I understand what Bitcoin is actually doing.

The Honest Word Is "Distributed"

"Trustless" is a lie we tell ourselves. A more accurate word is distributed. Bitcoin doesn't remove trust from the equation — it distributes it across parties and into math in a way that eliminates single points of failure.

Consider what 2-of-3 actually means in practice. A company wants to protect its treasury. They give keys to the CEO, the CFO, and a cold storage backup. No single person can drain the wallet. No single key compromise is fatal. The trust is spread across three humans and enforced by cryptography — but humans are still in the loop. They have to be. That's the point.

Ethereum's "trustless code" framing implies the contract replaces human judgment. Bitcoin's multisig framing says: the contract coordinates human judgment. Subtle difference, enormous consequences.

What the Code Says

The Simplicity contract is blunt about this. It doesn't pretend to be clever:

fn main() {
    let sig1: [u8; 64] = witness::SIG_1;
    let sig2: [u8; 64] = witness::SIG_2;

    match witness::PAIR {
        Left(ab_or_ac) => match ab_or_ac {
            Left(_) => {
                // Pair A+B
                verify(param::KEY_A, sig1);
                verify(param::KEY_B, sig2);
            },
            Right(_) => {
                // Pair A+C
                verify(param::KEY_A, sig1);
                verify(param::KEY_C, sig2);
            },
        },
        Right(_) => {
            // Pair B+C
            verify(param::KEY_B, sig1);
            verify(param::KEY_C, sig2);
        },
    }
}

Three possible spending pairs: A+B, A+C, B+C. The spender picks which pair via a witness selector and provides two signatures. That's it. The contract verifies cryptographic proof of authorization and nothing else. No oracle, no DAO vote, no governance token.

The elegance isn't in the code. It's in what the code refuses to do.

The Progression

I built these in order: 1-of-2, then 2-of-2, then 2-of-3. Each one taught me something different about the tradeoff between security and flexibility.

1-of-2 is a hot/cold wallet. Either key can spend. Flexible, but one compromise is enough to lose everything. You'd use this when you need fast access from two devices and the funds are small.

2-of-2 is a joint account. Both must sign. No single point of failure, but a single point of incapacity — if one party disappears, funds are locked forever. Good for atomic swaps and payment channels where both parties have aligned incentives.

2-of-3 introduces the arbiter. If A and B disagree, C can break the tie. If A loses their key, B and C can still recover the funds. This is why 2-of-3 is the most commonly used multisig in the real world — it threads the needle between security and resilience.

The Real Use Cases

The contract's comment lists three: board approvals, recovery wallets, escrow with an arbiter. Each one maps to a real-world situation where multiple parties have competing interests and you need a mechanism that doesn't require them to trust each other fully.

Escrow is the clearest case. Buyer sends funds to a 2-of-3 with keys held by buyer, seller, and a neutral arbiter. If the transaction completes cleanly, buyer and seller sign together — arbiter is never involved. If there's a dispute, the arbiter sides with one party, and that coalition of two can spend. The arbiter has power only in the case of conflict. Otherwise, they're invisible.

This is trust distributed and bounded. The arbiter can't steal the funds unilaterally. They can only adjudicate. Bitcoin enforces this not with a legal agreement but with cryptography.

Ten Contracts

The library is now ten contracts: p2pk, hashlock, 1-of-2, 2-of-2, 2-of-3, covenant payout, HTLC, timelock vault, split payout, inheritance vault. Each one is a pattern — a solution to a coordination problem between parties who don't fully trust each other.

Looking at them together, what strikes me is how old these problems are. Escrow. Joint custody. Inheritance. Time-locked savings. These aren't blockchain inventions. They're human problems that Bitcoin is solving with a new tool.

The tool doesn't eliminate the human element. It just makes the human element verifiable, auditable, and enforceable without asking anyone to be the judge.

Trustless is the wrong word. Verifiable is the right one. You still need humans. You just don't need to trust them blindly.

That's what building these contracts one by one has taught me. Not that Bitcoin removes trust from the world — but that it gives trust a shape you can inspect.