NUMS: Nothing Up My Sleeve

Last time we covered the Unilateral Exit - the Tapscript leaf that lets a borrower recover their Bitcoin alone, after a timelock, with no permission from Surge.

This post closes the loop on the other side of the same architecture: the NUMS key, which is how we shut the back door that would otherwise make Exit beside the point.

The key path, and why we needed it dead

Every Taproot output (BIP341) commits to two things at once: a single Schnorr key called the key path, and a Merkle tree of Tapscript leaves (BIP342). The intent is that parties cooperate in the common case and spend via the key path with one signature, indistinguishable from any other on-chain spend. When they disagree, default, or vanish, the script tree carries a fallback they committed to up front.

But the key path is an unconditional spend. Whoever can sign for the internal key moves the coins, full stop. No leaf to reveal, no commitment to check.

It's a backdoor - useful when both parties hold a share, dangerous when they don't. For a credit vault that default is exactly wrong. The script tree carries Repayment, Liquidation, and Exit. A usable key path would mean none of those conditions matter; collateral could move without satisfying any of them.

Exit is only meaningful if there's no other way to move the coins.

So we needed the key path to exist (Taproot requires it) and to be unusable.

NUMS: a key no one can sign for

NUMS means "Nothing Up My Sleeve" - a value derived transparently from a fixed string so anyone can recompute it and confirm it wasn't chosen for any hidden reason.

Two distinct properties make it work, and they're often conflated.

The first: the constructor can't cheat. If we picked any point P freely, we could quietly pick P = k·G for some k we kept - a backdoor in plain sight. Deriving P from SHA256("SURGE-NUMS") removes that freedom. The hash output is what it is; we don't choose it.

The second: no one can spend through the resulting key. Given P = lift_x(SHA256("SURGE-NUMS")), recovering k where k·G = P requires solving discrete log on secp256k1 - the same problem that protects every Bitcoin private key in existence.

🚨 SHA-256 stops us from cheating. Discrete log hardness stops anyone from spending. 🚨

BIP341 specifies a canonical such point:

H = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)

It works. We wanted the commitment to be Surge-specific - a string that names what it is and who deployed it:

NUMS_x = SHA256("SURGE-NUMS")
       = 0x6a1bac977b8af761b330d1473dba1e5cfc75b3256a1ae900b78a369e175423f2

That's the x-only internal key on every Surge Vault. One line of code in any language. The string is the seed. The point is what it is.

Why this is more than a destroyed key

A destroyed key was once real. You have to trust the ceremony, the RNG, the participants. Its security is operational.

NUMS has no ceremony. Nothing was generated. The construction is a public hash of a public string, and the resulting point's security reduces to discrete log - the same assumption every Bitcoin user already trusts.

That's the difference between we won't move your coins through the key path and we can't, and you can verify it. The first is a promise that needs a company to keep existing. The second is a property of the script.

Why this scales Bitcoin-backed dollar credit

NUMS and Unilateral Exit are two ends of the same architecture. Unilateral Exit guarantees the borrower can always leave. NUMS guarantees no one can leave through any other door.

Together they make every Surge Vault structurally identical: same Taproot output, same three Tapscript leaves, same NUMS commitment. No per-vault ceremony, no per-borrower setup, no quietly evolving custody policy. A borrower opening their first Vault verifies the same construction as one opening their thousandth.

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

Don't trust. Verify. 🟧