Rollup sequencer idempotency key requirements for retryable writes

Rollup sequencers often provide retryable transaction endpoints to handle state-changing operations during network instability. While many implementations support idempotency keys to deduplicate these writes, the current protocol specification does not mandate their use as a requirement.

Without a protocol-level constraint, clients may currently rely on state-root comparison to detect duplicates. However, this approach is unstable if the node re-indexes or re-executes the state tree. Furthermore, some optimistic rollups treat every retried submission as a distinct transaction, potentially leading to duplicate state changes or double-minting if the client fails to provide a unique identifier.

There is a lack of defined permission boundaries regarding who is authorized to supply these keys and whether they are restricted to the original sender or accessible to any participant.

• Does the rollup protocol require mandatory idempotency keys for all retryable writes to ensure atomicity?
• What is the documented fallback strategy when a sequencer fails to recognize a duplicate write after an L1 transaction inclusion?
• How do deduplication semantics vary across different rollup implementations regarding state-root check stability?