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]
1---2name: consensus-tx-identity-invariants3description: L1 trigger - audits replay protection, transaction identity binding, and cross-layer uniqueness.4---56# Injectable Skill: Consensus Tx Identity Invariants78> **L1 trigger**: `CONSENSUS` flag AND (`txid`, `tx_hash`, `nonce`, `sequence`, `signature`, `message_id` detected across modules)9> **Inject Into**: `depth-consensus-invariant`, `depth-state-trace`10> **Language**: Go and Rust11> **Finding prefix**: `[TXI-N]`1213## 1. Identity Definition1415Determine what uniquely identifies a transaction in each layer:1617- explicit nonce / sequence18- hash of body19- hash of signed payload20- envelope ID distinct from execution payload ID2122Tag: `[TX-ID:DEFINITION]`2324## 2. Replay Protection2526For every submission path, ask what value changes to prevent replay and whether27it is monotonic, chain-bound, and sender-bound. Flag replay surfaces on the28same chain, across forks, or across layers.2930Write the answer as a table:3132| Tx Type | Replay-unique field | Sender-bound? | Chain-bound? | Expiry / bound |33|---|---|---|---|---|3435Tag: `[TX-ID:REPLAY]`3637Mandatory enumeration:38391. List **every signed transaction/message type**, not only system40 transactions: user transactions, system transactions, commitments,41 block-level commitments, gossip messages, admin/config messages, and any42 wrapper/envelope format.432. For each type, identify the replay guard: nonce, sequence, anchor,44 recent-block hash, expiry, chain ID, domain separator, or explicit consumed45 marker.463. If no per-sender or per-message replay guard exists, emit a finding. Do not47 accept "outer EVM signature has chain_id" as sufficient unless the inner48 payload identity and all consensus effects are also covered by that exact49 signature domain.504. Check same-chain replay, cross-fork replay, cross-layer replay, and51 re-inclusion after reorg separately.5253## 3. ID / Signature Binding5455Verify that the provided ID equals the hash of the signed content and that the56signature covers the exact bytes later used for execution or persistence.5758Questions:591. Is the ID recomputed by the verifier, or trusted from peer input?602. Does the signature sign the same bytes the ID is derived from?613. If the ID and signature are derived from different byte domains, can the62 content change while one of them stays stable?6364Mandatory binding table:6566| Object | Claimed ID field | Recomputed from | Signature covers | Persistence key | Mismatch possible? |67|---|---|---|---|---|---|6869Apply it to blocks, transactions, commitments, and any included commitment70list. If a block/tx/commitment ID is accepted from peer input without71recomputing it from the signed bytes, emit a finding.7273Tag: `[TX-ID:BINDING]`7475## 4. Cross-Layer Consistency7677Trace the transaction through admission, mempool, consensus inclusion,78execution, and indexing. All layers must agree on nonce / chain identifier /79sender identity / canonical ID.8081If a wrapper transaction carries an inner transaction or message, verify the82wrapper ID is tied to the inner payload identity instead of being an unrelated83field.8485Tag: `[TX-ID:CROSS-LAYER]`