Pay-to-Contract

Pay-to-contract is the cryptographic construction that lets a party embed an arbitrary commitment inside an ordinary-looking public key without changing how that key appears or behaves. Given an internal key P and some contract data c, the committed key is Q = P + H(P || c)·G. Because the tweak is added on the elliptic curve, Q is a perfectly valid public key: the original keyholder can still sign for it using the shifted private key p + H(P || c), while anyone later shown both P and c can verify that Q commits to that exact contract. To everyone else, Q is indistinguishable from any random key on the curve.

The idea's lineage

Pay-to-contract predates Taproot by years. It was proposed in 2012 by Ilja Gerhardt and Timo Hanke as a way for a merchant and customer to bind an invoice into the payment address itself: the customer tweaks the merchant's public key with the contract text, pays the tweaked address, and forever after can prove — using the untweaked key and the document — exactly what the payment was for. The merchant can still spend, because they can compute the same tweak. The same trick resurfaced in sidechain proposals and in BIP 32-style derivation before finding its most consequential application in Bitcoin's consensus layer.

Taproot is pay-to-contract at consensus level

BIP 341 applies the scheme directly: the "contract" committed inside every Taproot output is the Merkle root of its script tree, and the published output key is the tweaked key Q. This is the exact mechanism that lets a Taproot output conceal an entire tree of alternative spending conditions behind a single key that looks like a plain payment. The keyholder remains bound to those scripts — any of them can be proven and executed later via the script path — yet nobody can detect their existence beforehand. When the output is instead spent with a simple Schnorr signature on the key path, the commitment is simply never opened, and the scripts stay secret forever. Even a Taproot output with no scripts uses the construction: BIP 341 recommends tweaking by H(P) anyway, so that no output can be secretly hiding an unexpected script path.

The security detail that makes it safe

The hash must include the public key P itself as a prefix — H(P || c), never H(c) alone. Committing to the contract without binding the key would leave the scheme malleable: someone who knows a target commitment could shift keys around to graft it onto a different keypair. Including P locks the tweak to that specific key, and tagged hashing (Taproot uses the tag "TapTweak") provides domain separation so these commitments can never collide with any other hash in the protocol. These are the quiet details that separate a sound commitment scheme from an exploitable one.

Why it matters to a sovereign user

The construction's close cousin, sign-to-contract, applies the same tweak to the nonce inside a signature rather than to a key, letting a signer embed a commitment in any transaction they were making anyway — the basis of some timestamping schemes and a proposed countermeasure against hardware-wallet nonce exfiltration. Together the two techniques show how much mileage Bitcoin gets from one algebraic identity: commitments hidden in plain sight, at zero on-chain cost.

Pay-to-contract is the reason Taproot improves privacy for everyone: vaults, multisig arrangements, and Lightning channel closes can all present on-chain as identical single-key payments, shrinking the fingerprints chain-analysis firms feed on. It costs nothing extra — the commitment rides inside a key that had to exist anyway. The general pattern lives on in Bitcoin as the Taproot Tweak, binding the Taproot Internal Key to its script tree and producing the output key your node verifies on every Taproot spend.