The Repayment Leaf: How Cooperative Spends Work on a Taproot Vault

We've already walked through two of the three Tapscript leaves: Exit, the borrower's unilateral path home, and the NUMS internal key that makes those leaves the only spending surface.

This one is the leaf most Vaults will live and die by: Repayment.

Script anatomy

The Repayment leaf is the cooperative spend path. It's the one that closes a credit line when the borrower pays back what they owe, and the one that releases collateral proportionally on a partial repayment while keeping the line open.

The script itself is short. It commits a 32-byte vaultId, drops it from the stack, then requires two Schnorr signatures: one from userPubkey (the borrower) and one from loanPubkey (the DCN). The signature check is an OP_CHECKSIG followed by an OP_CHECKSIGADD == 2 - the standard Tapscript way of expressing "both of these signatures must be valid."

Neither side can spend through this leaf alone. The cooperative requirement is in the script, not in a service agreement.

Hard isolation: the vaultId commitment

vaultId is a 32-byte value committed inside every Repayment leaf, computed as keccak256(abi.encodePacked(userEvmAddress, nonce)). It encodes which borrower and which credit line this Vault belongs to, and no two Vaults share it.

A witness produced for Alice's Vault cannot be replayed against Bob's, because Bob's leaf encodes a different vaultId and the script won't validate.

🚨 Hard isolation at the script level, not soft isolation at the bookkeeping level. Vault A has no script path to Vault B. 🚨

The DCN is not the custodian

The Repayment leaf requires the DCN's signature, which raises the obvious question: who signs for the DCN?

The DCN (Distributed Custody Network) is the network of signers that holds threshold shares of loanPubkey. The loanPubkey itself is an aggregate x-only key created by distributed key generation, signed under a 3-of-4 Lin24 threshold Schnorr session (BIP340). No single signer holds the private key. There is no "the DCN" in the sense of a single party with credentials to sign. There is a quorum, and signatures only get produced when enough independent signers participate.

That distinction is what makes Repayment non-custodial. In custodial lending, the second signature on a 2-of-2 closure comes from one custodian - and that custodian, by definition, holds something that could move your collateral if compelled. In Surge's model, no individual party can produce the DCN's signature. The threshold is mathematical, not policy.

The cooperative requirement in the script - "both signatures must be valid" - sounds like a multisig with two parties. It's actually a multisig with you on one side and a network on the other.

The borrower's own key, on both sides

The other half of the non-custodial story is what's holding userPubkey. The answer: the borrower, with a private key that they hold themselves and that Surge never sees. Your own Bitcoin wallet, signing your own Schnorr signature on the Repayment leaf.

The dollar side is bound just as tightly. The USDC against your collateral is always delivered to the EVM address you verified and signed for at draw time - not to a platform-issued account, not to a Surge-managed wallet, not to a balance we hold on your behalf.

This is a different posture from most lending products, where the borrower holds a Bitcoin wallet, the platform holds a dollar account on their behalf, and the link between the two is administrative - KYC records, account IDs, a customer support ticket if something goes wrong.

In Surge, both halves are signed by the borrower and enforced by the protocol. Control of the BTC is enforced by Bitcoin script. Control of the USDC is bound to a signed intent, not to our bookkeeping. Self-custody isn't a label on one side of the architecture. It's enforced on both.

Why it scales credit

Credit is a product where the failure mode that destroys you isn't a single bad loan - it's contagion. Pooled credit scales the blast radius, not the safety. More activity through a shared structure means more positions a single failure can touch.

The Repayment leaf is one of the places we refused to make that trade. Every Taproot Vault is its own UTXO, its own script tree, its own vaultId. Repayment for one Vault has no script path to another. The DCN signs by threshold, not by custodian. The borrower signs with their own key, on both sides of the trade.

That isolation and that non-custodial posture were built in on day one, before there was a book to protect.

The credit book grows. The blast radius does not. The thing you have to trust does not.

Don't trust. Verify. 🟧