| 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:
- 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.
- For each type, identify the replay guard: nonce, sequence, anchor,
recent-block hash, expiry, chain ID, domain separator, or explicit consumed
marker.
- 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.
- 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:
- Is the ID recomputed by the verifier, or trusted from peer input?
- Does the signature sign the same bytes the ID is derived from?
- 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]
