Glossary / Protocol & upgrades
OP_CHECKSIGADD
- Definition
- OP_CHECKSIGADD counts signatures one key at a time inside tapscript, replacing the old multisig opcode with a check that batch verification and future key types can both handle.
Specified in BIP-342.
The opcode takes three stack items, a signature, a running count and a public key, and pushes the count back either unchanged or increased by one. BIP-342 assigned it opcode 186 and disabled OP_CHECKMULTISIG in the same breath, so every Taproot script multisig is written this way. The practical gain is that a threshold policy no longer stops at 20 keys.
How it works
A tapscript threshold is a chain of signature checks with a tally passed along between them, and a comparison at the end.
Written out, a two-of-three reads: push the first public key, OP_CHECKSIG, push the second, OP_CHECKSIGADD, push the third, OP_CHECKSIGADD, push 2, OP_NUMEQUAL. Execution walks left to right. OP_CHECKSIG leaves 1 or 0 on the stack, and each OP_CHECKSIGADD pops a public key, pops that running total, pops the signature offered for this key, and pushes the total back with 1 added if the signature verified. The final comparison decides whether enough of them did.
A signer who is not participating supplies an empty byte string in place of a signature. The opcode sees it, treats the slot as unsigned, and returns the tally untouched, which costs a single byte in the witness. That is the whole mechanism, and it removes the dummy stack element that OP_CHECKMULTISIG required because of an off-by-one bug in the original implementation.
Two consequences follow from checking one key against one signature. Verification becomes batchable: a node can throw every Schnorr signature in the block into one aggregate check instead of testing candidate keys in order, which is a large part of Taproot's validation speedup. And the number of keys is bounded by the tapscript validation budget, which spends 50 weight units per signature checked, rather than by a hard ceiling written into the opcode.
Where you see it
OP_CHECKSIGADD appears in any Taproot script that needs more than one signer, which in wallet software usually means a descriptor rather than raw script.
Bitcoin Core exposes it as the multi_a and sortedmulti_a fragments inside a tr() descriptor, so a three-key quorum is written as tr(internalkey,multi_a(2,KEY1,KEY2,KEY3)) and the software emits the opcode chain for you. Miniscript treats it the same way, and hardware devices that support Taproot policies sign these scripts without needing to know the arrangement in advance.
The design also changes how you can shape a quorum. Instead of one leaf holding all three keys, a taptree can hold three separate two-key leaves, one per possible pair, and a spend then reveals only the pair that actually signed. That costs more in script leaves and saves a public key in the witness, and it is a genuine privacy improvement over publishing the full key set on every spend.
OP_CHECKSIGADD vs OP_CHECKMULTISIG
OP_CHECKSIGADD and OP_CHECKMULTISIG both count signatures against a set of keys, and only one of them works in a Taproot leaf. OP_CHECKMULTISIG remains perfectly valid in legacy and SegWit version 0 scripts, so the bc1q multisig people have been running for years is unaffected and needs no migration.
Inside tapscript, OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are disabled outright. Beyond the venue, three differences matter: the old opcode caps a script at 20 public keys and the new one has no such number, the old one requires an extra dummy item on the stack that BIP-147 later forced to be empty as a consensus rule, and the old one cannot be batch verified because a verifier does not know in advance which key each signature belongs to.