From the sighash algorithm:

6. The Annex Field in Tapscript

The annex is an optional data field in Taproot inputs that was defined in BIP 341 but left without defined semantics. It is reserved for future protocol upgrades.

What is the Annex

When spending a Taproot input, the witness stack contains the spending data. For script path spending, this is:

Witness stack (script path, no annex):
[<script inputs...>, <tapscript>, <control block>]

Witness stack (script path, with annex):
[<script inputs...>, <tapscript>, <control block>, <annex>]

The annex, if present, is always the last item in the witness stack. It is identified by starting with the byte 0x50. If the last witness item starts with 0x50, it is treated as the annex, not as script input data.

def has_annex(witness_stack):
    if len(witness_stack) >= 2:
        last_item = witness_stack[-1]
        return len(last_item) >= 1 and last_item[0] == 0x50
    return False

def get_annex(witness_stack):
    if has_annex(witness_stack):
        return witness_stack[-1]
    return None

Current Status of the Annex

As of now, the annex has no defined consensus meaning. Transactions that include an annex are relayed and accepted by nodes, but the annex data itself is not interpreted or validated beyond its presence check.

However, the annex is committed to in the sighash when present:

# From the sighash algorithm:
if annex:
    sha_annex = sha256(ser_string(annex))
    # sha_annex is included in the sighash preimage

This means a signature can commit to a specific annex value. If the annex is present, the signature covers it. This ensures that if the annex is later given semantics by a soft fork, existing signatures that committed to an annex value cannot be reused in contexts where the annex has different data.

Why the Annex Exists

The annex is a forward-compatibility mechanism. Several proposed Bitcoin upgrades could use the annex to carry additional data:

OP_VAULT / Covenant proposals: The annex could carry authorization data for covenant enforcement without requiring changes to the scriptPubKey format.

Batch validation hints: The annex could carry data to assist with batch Schnorr signature verification across many inputs.

Cross-input signature aggregation: If Bitcoin ever implements CISA (Cross-Input Signature Aggregation), the annex could carry aggregated signature data at the transaction level.

Version information: Future versions of Tapscript (leaf versions beyond 0xc0) could use the annex to carry version-specific metadata.

// Hypothetical future use of annex for OP_VAULT:
Witness stack:
[<trigger sig>, <tapscript>, <control block>, <0x50><vault_params>]
                                               ^^^^^ annex marker

Technical Insight

This topic covers essential mechanics for Chapter 11. Understanding these details is key to mastering advanced Bitcoin script constructions like Taproot and specialized covenants.