Every HNS name you own routinely does one of a handful of boring things: it gets transferred, finalized, renewed, updated. But "boring" isn't the same as "simple." A responsible owner also wants an answer for the uncommon cases — a lost key, an inactive wallet, a registrar-cosigned recovery — and today, building that in means either skipping it entirely or wiring up a custody arrangement the chain doesn't actually enforce or hide.

Bitcoin ran into the identical problem with coin ownership and solved it with Taproot — BIP340, BIP341, and BIP342. This post walks through what that solution actually does, and introduces an open-source reference implementation, hns-taproot, that applies the same pattern to Handshake's covenant model. It's real, tested cryptography — not a stub. It is also, explicitly, not something hsd will accept on mainnet today. Both of those things are true at once, and the difference matters.

Lesson 1: What Taproot Actually Solved

Before Taproot, a Bitcoin UTXO with multiple spending conditions had to expose all of them up front in the script — whether or not they were ever used. Want a routine key, plus a 2-of-3 recovery multisig, plus a timelocked fallback? All three show up on-chain the moment you spend, whichever path you actually take. That's a privacy leak and a fee cost baked into caution.

Taproot's fix: commit to every condition inside a Merkle tree (a "MAST" — Merkelized Alternative Script Tree), but only reveal the one branch you actually use. The common case — a single cooperative signer — reveals nothing extra at all. It looks identical to the simplest possible spend, no matter how much conditional logic is sitting behind it unused.

Lesson 2: Name Ownership Has the Same Shape as Coin Ownership

An HNS name's controlling output isn't so different from a Bitcoin UTXO. The routine transitions — TRANSFER, FINALIZE, UPDATE, RENEW — ideally look identical on-chain and cost the minimum. But a name owner might reasonably also want:

  • a timelocked fallback claim path — if the primary key goes dark for 90 days, a backup key can reclaim the name;
  • a registrar- or guardian-cosigned recovery path, without handing that cosigner day-to-day control;
  • an emergency revoke path distinct from routine ownership.

Wrapping the name's output key the way Taproot wraps a coin's key would make all of that chain-enforced and invisible until it's actually needed — instead of either absent or bolted on as an off-chain trust arrangement.

Lesson 3: Key Path vs. Script Path

The mechanism has two halves. First, key tweaking: an internal public key gets combined with the Merkle root of every hidden condition into a single output key, Q = P + hash(P || root)·G. Second, spending takes one of two forms:

  • Key path — a single Schnorr signature (BIP340) from the tweaked key. This is the every-day TRANSFER/FINALIZE spend, and it's indistinguishable from any other single-sig output on the chain.
  • Script path — reveal one leaf script from the tree plus a "control block" of sibling hashes proving that leaf belongs to the committed root, without exposing any of the other leaves.

This is the same crypto-agility idea this series covered with ZK proofs and HNS and with per-domain post-quantum record types — conditional capability that stays out of sight until it's invoked.

Lesson 4: What's Actually in the Open-Source Reference

The hns-taproot repository is a from-scratch, dependency-free Python implementation, not a wrapper around someone else's library. Every piece is unit-tested against its own construction:

  • BIP340-style Schnorr signing and verification (tagged hashing, deterministic nonces, x-only public keys) over secp256k1;
  • MAST tree construction — tapleaf and tapbranch tagged hashing, Merkle root computation, and control-block generation for a chosen leaf;
  • Taproot key tweaking for both the output public key and the corresponding tweaked private key, so a key-path spend round-trips correctly;
  • Bech32/Bech32m address encoding matching hsd's HRPs (hs mainnet, ts testnet, rs regtest, ss simnet);
  • a covenant wrapper modeling HNS's actual covenant types (OPEN, BID, REVEAL, REGISTER, TRANSFER, FINALIZE, and the rest, matching hsd's own type list) that ties a name's controlling output to a Taproot-style key with optional hidden recovery leaves.

The included demo builds a TRANSFER output for a name, adds one hidden 90-day timelock recovery leaf, signs a routine key-path spend, and separately reveals the recovery leaf with its control block — showing both paths working against the same output key.

Lesson 5: Where This Stops Being Just Code

Here's the part that's easy to gloss over and shouldn't be: Taproot is not part of HNS consensus today. hsd doesn't define a witness-v1 program, and nothing in this repository can construct a transaction a real Handshake node will accept. The Schnorr math, the MAST hashing, the key tweaking — all of that is real and correct. What's missing is everything on the other side of a soft fork:

  • a sighash design review for how Schnorr composes with HNS's existing signature hashing;
  • actual hsd opcode sequences behind the recovery leaves, in place of this repo's placeholder script encodings;
  • a fee/weight model that gives script-path privacy an actual cost advantage, the way witness discounting does on Bitcoin;
  • and, underneath all of it, a real proposal and community discussion — not a unilateral protocol change.

What this repository is meant to do is make that conversation concrete instead of abstract: here is exactly what the primitives look like, here is exactly what they'd let a name owner do, and here is exactly what's still missing before any of it could ship.

Lesson 6: Why Bother If It's Not Deployable Yet

Because the alternative to "concretely explore this" isn't "wait for someone else to." Bitcoin's own Taproot went through years of BIP drafts, implementation prototypes, and public review before activation. Protocols that want the option of adopting something like this eventually benefit from having a working reference to argue about now, rather than starting the conversation from a whiteboard sketch later. That's the same spirit behind this site's earlier look at a post-quantum migration path for HNS custody — lay out the real mechanism, be explicit about what's proven versus what's proposed, and let the trade-offs be argued on their merits.

NIHON — Handshake Infrastructure & Web3 Identity.