Rollup sequencer idempotency key requirements for retryable writes

Idempotency Requirements for Rollup Writes

Most rollup protocols do not mandate a separate, explicit idempotency key for retryable writes because they rely on account-based nonces to ensure atomicity and prevent duplicate execution. In these architectures, the nonce serves as the implicit idempotency key; the sequencer will reject any transaction with a nonce that has already been processed for that specific account.

Implementation Analysis

While protocol specifications may not mandate a dedicated key, the actual deduplication behavior typically falls into two categories:

• API-Level Deduplication: Some sequencers implement idempotency keys at the gateway level. This prevents the same request from entering the mempool multiple times during network instability, but it does not protect against duplicates if the transaction is submitted via different entry points.
• State-Level Deduplication: The sequencer tracks the last processed nonce per account. If a client retries a write with an existing nonce, the sequencer identifies it as a duplicate and rejects it without altering the state.

Fallback Strategies and State-Root Stability

When a sequencer fails to recognize a duplicate write after L1 inclusion, the fallback is typically the L1 settlement layer. Since L1 transactions are immutable and ordered, the L2 state transition function will naturally reject the duplicate transaction during the execution of the batch, as the account nonce will have already advanced.

Regarding state-root comparison, this is generally an unreliable deduplication strategy. State roots verify the result of a transition, not the intent of the request. If a node re-indexes or re-executes a state tree, the root may remain the same, but it cannot distinguish between a successful previous write and a new write that happens to result in the same state.

Verification Steps

To verify the deduplication behavior of a specific rollup implementation, use the following scoped approach:

1. Duplicate Submission: Submit the same signed transaction (same nonce and signature) twice to the sequencer API. A compliant implementation should return a specific error (e.g., "nonce too low" or "transaction already exists").
2. L1 Inspection: Check the L1 calldata for the transaction hash. If the same transaction appears multiple times in the L1 batch but only one state change is reflected in the L2 state, the deduplication is happening at the execution layer.

Diagnostic Requirement: To provide a more specific recommendation, please clarify if the rollup uses an account-based model (like Ethereum) or a UTXO-based model, as deduplication logic differs fundamentally between the two.