/consensus-tx-identity-invariants

name: "consensus-tx-identity-invariants"
description: "L1 trigger - audits replay protection, transaction identity binding, and cross-layer uniqueness."

Injectable Skill: Consensus Tx Identity Invariants

> **L1 trigger**: `CONSENSUS` flag AND (`txid`, `tx_hash`, `nonce`, `sequence`, `signature`, `message_id` detected across modules) > **Inject Into**: `depth-consensus-invariant`, `depth-state-trace` > **Language**: Go and Rust > **Finding prefix**: `[TXI-N]`

1. Identity Definition

Determine what uniquely identifies a transaction in each layer:

• explicit nonce / sequence
• hash of body
• hash of signed payload
• envelope ID distinct from execution payload ID

Tag: `[TX-ID:DEFINITION]`

2. Replay Protection

For every submission path, ask what value changes to prevent replay and whether it is monotonic, chain-bound, and sender-bound. Flag replay surfaces on the same chain, across forks, or across layers.

Write the answer as a table:

| Tx Type | Replay-unique field | Sender-bound? | Chain-bound? | Expiry / bound | |---|---|---|---|---|

Tag: `[TX-ID:REPLAY]`

Mandatory enumeration:

1. List **every signed transaction/message type**, not only system transactions: user transactions, system transactions, commitments, block-level commitments, gossip messages, admin/config messages, and any wrapper/envelope format. 2. For each type, identify the replay guard: nonce, sequence, anchor, recent-block hash, expiry, chain ID, domain separator, or explicit consumed marker. 3. If no per-sender or per-message replay guard exists, emit a finding. Do not accept "outer EVM signature has chain_id" as sufficient unless the inner payload identity and all consensus effects are also covered by that exact signature domain. 4. Check same-chain replay, cross-fork replay, cross-layer replay, and re-inclusion after reorg separately.

3. ID / Signature Binding

Verify that the provided ID equals the hash of the signed content and that the signature covers the exact bytes later used for execution or persistence.

Questions: 1. Is the ID recomputed by the verifier, or trusted from peer input? 2. Does the signature sign the same bytes the ID is derived from? 3. If the ID and signature are derived from different byte domains, can the content change while one of them stays stable?

Mandatory binding table:

| Object | Claimed ID field | Recomputed from | Signature covers | Persistence key | Mismatch possible? | |---|---|---|---|---|---|

Apply it to blocks, transactions, commitments, and any included commitment list. If a block/tx/commitment ID is accepted from peer input without recomputing it from the signed bytes, emit a finding.

Tag: `[TX-ID:BINDING]`

4. Cross-Layer Consistency

Trace the transaction through admission, mempool, consensus inclusion, execution, and indexing. All layers must agree on nonce / chain identifier / sender identity / canonical ID.

If a wrapper transaction carries an inner transaction or message, verify the wrapper ID is tied to the inner payload identity instead of being an unrelated field.

Tag: `[TX-ID:CROSS-LAYER]`