• Script anatomy: What the repayment leaf is made of?
• Hard isolation: The VaultId commitment
• the DCN is not the custodian
• The Borrower’s single key signs Bitcoin and controls the USDC
• Why it scales credit

Last tuesday we covered NUMS, the construction that disables the key-path backdoor on every taproot vault, so every spend has to satisfy one of the three tapscript leaves. We’ve already walked through two of them: exit, the borrower’s unilateral path home, and the nums internal key that makes those leaves the only spending surface. This week is the leaf most vaults will live and die by: Repayment.

§Script anatomy: What the repayment leaf is made of?

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

The script 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 check is op_checksig followed by op_checksigadd == 2, the standard tapscript way of saying “both 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 the 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 blast radius of any single position is exactly one position, enforced by Bitcoin.

§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 the loanPubkey. The loanPubkey itself is an aggregate x-only key produced by a 3-of-4 threshold schnorr signing session (Lin24, 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. A subpoena to any single dcn signer doesn’t reach into your vault any more than a subpoena to a single Bitcoin miner reaches into the chain.

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 single key signs Bitcoin and controls the USDC

The other half of the non-custodial story is what’s holding userPubkey. The answer is: the borrower, with a single private key that they hold themselves and that surge never sees.

The detail that’s easy to miss is that the same key controls both sides of the credit line. The borrower’s private key signs the schnorr signature on the Bitcoin repayment leaf, and the corresponding evm address derived from that same key is where surge delivers the usdc against the collateral. One key, two networks. No platform-issued account, no surge-managed wallet, no hand-off between a Bitcoin identity and a dollar identity that depends on us linking them correctly.

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 support ticket if something goes wrong. In surge, the link is cryptographic. The same secret that proves the borrower can sign the repayment also proves they own the address that received the usdc.

When the repayment leaf is satisfied, the borrower has signed for both halves of the trade: the btc being released back to them on Bitcoin, and the usdc obligation they hold on evm. Self-custody isn’t a label on one side of the architecture. It’s enforced on both.

§Why it scales credit

Credit’s destroyer isn’t a single bad loan, it’s contagion. One position’s collateral getting tangled with another’s. One liquidation cascading into a margin call that wasn’t supposed to be triggered. 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 blast radius of any single position is exactly one position, enforced by Bitcoin. 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. 🟧