OP_CHECKSIGADD

OP_CHECKSIGADD (opcode 0xba) is the Tapscript replacement for legacy multisignature checking, introduced in BIP 342 alongside the Taproot upgrade. It pops three stack elements — a public key, an integer counter, and a signature — and verifies the signature against the key using BIP 340 Schnorr rules. If the signature is valid it pushes the counter incremented by one; if the signature is the empty vector it pushes the counter unchanged; and if the signature is present but invalid, script execution fails immediately. This simple accumulate-as-you-go design lets a script tally valid signatures one key at a time.

Building m-of-n without OP_CHECKMULTISIG

Chaining OP_CHECKSIGADD across several keys, then comparing the accumulated counter to a threshold with <m> OP_NUMEQUAL (or OP_GREATERTHANOREQUAL), reproduces any m-of-n policy that OP_CHECKMULTISIG once provided. A 2-of-3 Tapscript looks like: push the first key, OP_CHECKSIG; then for each remaining key, OP_CHECKSIGADD; then OP_2 OP_NUMEQUAL. A spender supplies a signature slot for every key in order, filling the slots for keys they can sign with and leaving empty vectors for the rest. The structure is explicit: each signature is bound to exactly one key position, and the script simply counts successes.

Why the design changed

Legacy OP_CHECKMULTISIG does not associate a given signature with a given public key until runtime — the verifier must try signatures against keys in order to discover the matching, which blocks efficient batch verification and historically required the notorious extra dummy stack element to paper over an off-by-one in the original implementation. By making each signature check explicit and position-bound, OP_CHECKSIGADD keeps every operation individually batch-verifiable: a validator can accumulate thousands of Schnorr signature checks from many transactions and verify them together substantially faster than one-by-one. That validation efficiency across the whole network is the real payoff. OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are disabled entirely inside Tapscript — using them makes the script invalid.

What it means for real wallets

For anyone running multisig custody, OP_CHECKSIGADD is the script-path workhorse of modern Taproot wallets. The most private arrangement puts a key aggregation (such as MuSig2) on the key path, so the cooperative case looks like a single-signer spend, and reserves OP_CHECKSIGADD-based scripts in the tree for fallback quorums — recovery keys, degraded thresholds, timelocked paths. Compared with legacy multisig, the script reveals only the branch actually used, and fees stay proportional to the path taken rather than the full policy. Each successful non-empty signature check also draws against the per-input sigop budget, a Tapscript resource limit that scales with witness size — generous for normal policies, but the reason enormous exotic quorums need care in construction.

OP_CHECKSIGADD is the modern counterpart to OP_CHECKSIG: same Schnorr verification underneath, plus a counter that turns one signature check into a building block for arbitrary threshold policies in Bitcoin Script.

A concrete reading of the script

It helps to trace a 2-of-3 spend by hand. The witness supplies three slots, top of stack first: perhaps a valid signature for key A, an empty vector for key B, and a valid signature for key C. Execution runs <keyC> OP_CHECKSIG — valid, stack holds 1 — then <keyB> OP_CHECKSIGADD — empty signature, counter stays 1 — then <keyA> OP_CHECKSIGADD — valid, counter becomes 2 — and finally OP_2 OP_NUMEQUAL leaves true. Every step is a simple, independently verifiable operation with no hidden matching logic, which is precisely the property that makes batch verification possible and implementation bugs less likely. The empty-vector convention also means unused key slots cost almost nothing in witness weight, so generous key sets — several hardware devices plus a recovery service, say — stay affordable in the cooperative case.