Taproot annex

BIP-341 reserved the field for future soft forks and gave it no meaning, so no node reads its contents today. Bitcoin Core's IsWitnessStandard rejects a Taproot spend that carries a 0x50-tagged annex, so the transaction will not relay, and BIP-341 warns it may lead to permanent fund loss. Wallets have no reason to attach one, so nothing you do when buying or holding bitcoin depends on it.

How it works

A Taproot annex is identified by position rather than by a named field in the transaction format. If a Taproot input carries at least two witness elements and the first byte of the last element is 0x50, that element is the annex and is removed from the witness stack before anything else is examined. Only then does a node decide what it is looking at: one remaining element means a key path spend, two or more mean a script path spend.

BIP-341 picked 0x50 deliberately. Leaf versions come in even and odd pairs that must not be mistaken for the first byte of a P2WPKH or P2WSH witness, and 0x50 was an unpaired leftover, so it cost the fewest future script versions. The rule runs backwards too: a leaf version may not be 0x50, because a control block starting with that byte would be indistinguishable from an annex.

What the annex does not do is influence validation. BIP-341 says the field "is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation." Every Taproot signature message carries a one-byte spend_type equal to (ext_flag * 2) + annex_present, and when one is present the message also carries sha_annex, the 32-byte SHA256 of the annex's length prefix and the annex itself, 0x50 byte included. Absence is signed as firmly as presence, so nobody can bolt an annex onto your transaction in the mempool or strip one off. BIP-341 puts the signature message at 174 bytes, minus 49 for ANYONECANPAY, minus 32 for NONE, plus 32 when an annex is present, capped at 206.

Where you see it

You do not see a Taproot annex in ordinary use, which is the design working. Bitcoin Core's relay policy, in src/policy/policy.cpp, checks every witness version 1 input with a 32-byte program and returns false when the witness holds two or more elements and the last one begins with the ANNEX_TAG constant, defined as 0x50 in src/script/script.h. The comment beside that check is the whole policy: "Annexes are nonstandard as long as no semantics are defined for them." A transaction carrying one is valid by consensus and undeliverable in practice: a default node drops it instead of passing it on.

An annex genuinely shows up in one place, every Taproot signature you have ever made, whose spend_type carries a zero bit saying there is no annex here. That commitment is what would make an eventual soft fork usable: BIP-341 names the intended job as flagging the validation cost of expensive new opcodes without a node fetching the output being spent.

Taproot annex vs OP_RETURN

OP_RETURN is bitcoin's designated slot for publishing bytes nobody will spend, and the Taproot annex is not a publishing slot at all. Both get described as room for data that consensus ignores, and they behave in opposite ways. OP_RETURN data lives in an output, is part of the transaction every node validates, and announces one agreed meaning: nothing here is spendable. Annex bytes live in the witness, are stripped off before the stack is read, and carry a warning from the specification itself, that "users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS."

That warning is not decoration. A soft fork can only add rules, so bytes ignored today can be rejected tomorrow, and your signature commits to the annex, so you cannot remove it from an already signed transaction. Anyone presigning spends years ahead, as a vault or a Lightning channel does, would be locking in a field whose meaning nobody has written yet.