Skip to content

fix: reject sentinel transactions from eth_sendRawTransactionSync#393

Open
matthias-wright wants to merge 3 commits into
veridise-audit-april-2026from
m/send-raw-tx-sync
Open

fix: reject sentinel transactions from eth_sendRawTransactionSync#393
matthias-wright wants to merge 3 commits into
veridise-audit-april-2026from
m/send-raw-tx-sync

Conversation

@matthias-wright
Copy link
Copy Markdown
Contributor

@matthias-wright matthias-wright commented May 20, 2026

Builds on #392.

Sentinel transactions never end up in the pool or in a block, so the subscriber would wait forever.

Changes:

  • eth_sendRawTransactionSync will reject sentinel transactions
  • the send_raw_transaction_sync deserializes (recovers) transactions and returns early if the transaction is a sentinel transaction. This means that a normal transaction will be deserialized twice. Avoiding the double deserialization would have meant more invasive changes.

@matthias-wright matthias-wright requested a review from cdrappi as a code owner May 20, 2026 18:30
@github-actions
Copy link
Copy Markdown
Contributor

Adds comprehensive replay protection to ops whitelist system with validator IDs, admin nonces, and enhanced sentinel transaction validation.

Phase 1

  • PR description severely understates scope — The description mentions only rejecting sentinel transactions from eth_sendRawTransactionSync, but this PR actually adds major replay protection infrastructure: per-process validator IDs, monotonic admin nonces, 5-stage sentinel validation, new bootstrap RPC endpoints, and updated contract interfaces. This mismatch makes it difficult for reviewers to understand what they're actually reviewing.

Phase 2

  • crates/seismic/chainspec/src/lib.rs:398 — Genesis hash changed from 0xf88fc8... to 0x34d66d... due to contract bytecode update. This breaks backward compatibility with existing dev chains using the old genesis. Deployment guide should note this requires fresh chain state.

  • crates/rpc/rpc-layer/src/signature_auth_layer.rs:82rand::rng().fill_bytes() for validator_id generation is cryptographically secure, but consider documenting that validator collision across different node instances could theoretically allow cross-instance replay (astronomically unlikely with 256-bit IDs).

LGTM — The implementation is well-designed with proper concurrency handling, comprehensive validation, and extensive test coverage. The replay protection architecture correctly uses strict-greater nonce comparison and validator binding to prevent attacks while allowing legitimate out-of-order delivery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant