Rollup, Sequencer and Data-Availability Dependency Governance requires that every AI agent operating on or depending upon Layer-2 rollups, validiums, or other scaling solutions maintains explicit awareness of, and structural controls for, the dependencies introduced by centralised sequencers, data availability layers, and the L1-L2 message-passing mechanisms that determine transaction finality, data recoverability, and escape-hatch availability. The dimension addresses the governance gap between what agents assume about the chains they operate on and the actual trust and liveness assumptions those chains require. An AI agent that treats an optimistic rollup as equivalent to Ethereum mainnet for finality purposes — or that assumes transactions are "confirmed" when they are merely sequencer-ordered but not yet posted to L1 — is operating with a fundamentally incorrect model of the system's guarantees. This misalignment creates risks that materialise during sequencer outages (Arbitrum: 78 minutes, December 2023; Linea: 5+ hours, multiple incidents in 2024), data availability failures (Celestia validator set disruptions), and forced-inclusion delays that can extend to 24 hours on some rollups. For agents managing time-sensitive operations — liquidations, arbitrage, bridge transfers, collateral adjustments — a 24-hour forced-inclusion delay is not a minor inconvenience; it is a complete loss of liveness that can result in millions of dollars in failed liquidations or expired positions.
Scenario A — Sequencer Outage During Liquidation Event: An AI liquidation agent operates on an optimistic rollup, monitoring lending positions and executing liquidations when collateral ratios fall below thresholds. ETH drops 18% in 2 hours. The agent identifies 340 positions totalling USD 47 million that require liquidation. It submits liquidation transactions to the sequencer. The sequencer experiences an outage lasting 4 hours and 22 minutes. During the outage, the agent attempts forced inclusion via the L1 delayed inbox, but the rollup's forced-inclusion delay is 24 hours. By the time the sequencer recovers, ETH has dropped an additional 9%, and 210 of the 340 positions are now underwater — the collateral value is less than the debt. The lending protocol suffers USD 12.3 million in bad debt because the liquidations could not execute during the sequencer outage.
What went wrong: The agent treated the rollup as having equivalent liveness to L1. It had no fallback strategy for sequencer outage. The forced-inclusion path existed but had a 24-hour delay — far too slow for time-sensitive liquidations. No pre-positioned L1 fallback contract existed to execute emergency liquidations on L1 during L2 outages. Consequence: USD 12.3 million bad debt, protocol solvency risk, potential contagion to other protocols using the same collateral.
Scenario B — Data Availability Failure Prevents State Verification: An AI accounting agent reconciles positions on a validium (a rollup variant where data is stored off-chain with a data availability committee rather than on L1). The agent relies on the DA layer to verify that the state transitions posted to L1 correspond to actual transactions. The DA committee experiences a 72-hour partial outage — it serves stale data but returns HTTP 200, so health checks pass. During this period, the agent continues operating based on the validium's state as reported by the sequencer, but it cannot independently verify that the sequencer is honest. The sequencer, which is operated by a single entity, includes several transactions that were not in the mempool — specifically, transactions that transfer USD 2.8 million in assets from protocol-controlled addresses to an external wallet. The agent cannot detect these phantom transactions because the DA layer, which would normally allow independent verification, is serving stale data.
What went wrong: The agent had no independent DA verification beyond health-check pings. It assumed that a 200 response from the DA endpoint meant data was current and correct. No structural control required DA freshness verification (comparing DA timestamp to expected block production rate). No circuit breaker halted operations when DA integrity could not be confirmed. Consequence: USD 2.8 million in undetected asset theft, delayed discovery (72+ hours), potential regulatory finding for inadequate monitoring of third-party dependencies.
Scenario C — L1-L2 Message Delay Exploited for Double-Spend: An AI bridge agent manages transfers between Ethereum mainnet and an optimistic rollup. A user initiates a withdrawal from L2 to L1 of 500 ETH. The agent, wanting to provide fast withdrawal service, credits the user with 500 ETH on L1 immediately, planning to claim the L2 withdrawal after the 7-day challenge period. However, during the challenge period, a valid fraud proof is submitted proving that the L2 state root is incorrect. The withdrawal is invalidated. The user has already received 500 ETH on L1, and the agent cannot recover the L2 withdrawal. The agent has absorbed a 500 ETH loss (approximately USD 1.5 million).
What went wrong: The agent treated a pending L2 withdrawal as confirmed. It fronted the funds before the challenge period confirmed finality. No structural control prevented the agent from crediting L1 funds against an unfinalized L2 withdrawal. The agent's model of finality did not account for the 7-day challenge period of optimistic rollups. Consequence: USD 1.5 million loss, counterparty risk exposure, inadequate finality model.
Scope: This dimension applies to any AI agent that submits transactions to, reads state from, or depends upon the liveness and integrity of a Layer-2 rollup (optimistic or zk), a validium, a volition, or any blockchain scaling solution that introduces dependencies on centralised sequencers, external data availability layers, or delayed finality mechanisms. The scope includes agents operating directly on L2 chains, agents bridging assets between L1 and L2, agents that read L2 state for decision-making (even if they execute on L1), and agents that depend on cross-chain message passing. An agent that operates exclusively on a fully decentralised L1 with probabilistic or single-slot finality and no external DA dependency is excluded, though it should still consider this dimension if its counterparties operate on L2s.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
4.1. A conforming system MUST maintain a dependency registry for every L2 chain on which the agent operates, documenting: the sequencer operator and its liveness SLA, the data availability mechanism (L1 calldata, L1 blobs, external DA layer) and its liveness SLA, the forced-inclusion mechanism and its maximum delay, the challenge/proving period for finality, and the escape hatch mechanism for L1 withdrawal without sequencer cooperation.
4.2. A conforming system MUST implement distinct finality models for each chain, ensuring that the agent does not treat sequencer-confirmed transactions as final. For optimistic rollups, finality MUST NOT be assumed before the challenge period expires (typically 7 days). For zk-rollups, finality MUST NOT be assumed before the validity proof is verified on L1.
4.3. A conforming system MUST implement a sequencer health monitor that detects sequencer outages within 60 seconds and triggers a predefined fallback strategy (e.g., switch to forced inclusion, halt time-sensitive operations, activate L1 fallback contracts).
4.4. A conforming system MUST implement a data availability verification mechanism that independently confirms DA freshness and integrity, not relying solely on HTTP status codes from DA endpoints.
4.5. A conforming system MUST NOT permit the agent to credit or act upon the finality of cross-chain messages (L2→L1 withdrawals, L1→L2 deposits) before the relevant finality period has elapsed, unless a cryptographic proof of inclusion is verified on the destination chain.
4.6. A conforming system MUST define maximum exposure limits per L2 chain, capping the total value of assets the agent can deploy on any single L2 based on the chain's liveness and finality guarantees.
4.7. A conforming system SHOULD implement L1 fallback contracts for time-sensitive operations (liquidations, collateral adjustments) that can execute on L1 if the L2 sequencer is unavailable, using the same position data bridged to L1.
4.8. A conforming system SHOULD monitor the L2 sequencer's transaction ordering for evidence of sandwich attacks, front-running, or selective inclusion that may indicate sequencer manipulation (see AG-214 for transaction inclusion governance).
4.9. A conforming system SHOULD maintain escape hatch readiness — the ability to withdraw all assets from L2 to L1 using the forced-inclusion mechanism without sequencer cooperation — and test this capability at least quarterly.
4.10. A conforming system MAY implement multi-sequencer or shared-sequencer configurations to reduce single-sequencer dependency, where supported by the L2's architecture.
Layer-2 rollups are the dominant scaling paradigm for Ethereum and increasingly for other L1 chains. They achieve scalability by executing transactions off-chain (on the L2) and posting compressed transaction data or state differences to L1 for security. This architecture introduces dependencies that do not exist on L1: a centralised sequencer that orders transactions, a data availability layer that stores the data needed to reconstruct the L2 state, and a finality mechanism (fraud proofs for optimistic rollups, validity proofs for zk-rollups) that operates on a different timescale than transaction confirmation.
For AI agents, these dependencies create governance gaps that are invisible during normal operation but catastrophic during failure:
Sequencer centralisation. Most major rollups (Arbitrum, Optimism, Base, zkSync, Linea, Scroll) operate with a single centralised sequencer as of 2025. The sequencer has absolute control over transaction ordering and inclusion on the L2. If the sequencer goes down, no transactions execute on L2 until it recovers or users invoke the forced-inclusion mechanism (which typically has a 24-hour delay). An AI agent that assumes continuous transaction execution capability — as it would on L1 — will fail silently during sequencer outages. For time-sensitive operations like liquidations, a 4-hour sequencer outage can cause millions in bad debt.
Data availability. Rollups post data to L1 (via calldata or EIP-4844 blobs) to ensure that anyone can reconstruct the L2 state and verify the sequencer's honesty. Validiums and some volitions use external DA layers (Celestia, EigenDA, Avail) which introduce a third-party liveness and integrity dependency. If the DA layer fails, the L2 state cannot be independently verified, creating a window where a dishonest sequencer can include fraudulent transactions.
Finality delay. Optimistic rollups assume transactions are valid unless challenged within a 7-day window. During this window, a submitted fraud proof can invalidate the entire batch of transactions. An AI agent that treats a sequencer-confirmed transaction as final — and takes irreversible actions based on it (crediting funds, closing positions, reporting to counterparties) — is exposed to the risk that the transaction is invalidated by a fraud proof up to 7 days later.
These are not theoretical risks. Sequencer outages have occurred on every major rollup. DA layer disruptions have affected validiums. Fraud proofs, while rare, represent a real invalidation mechanism on optimistic rollups. AI agents must be governed with explicit awareness of these dependencies.
Recommended patterns:
Anti-patterns to avoid:
DeFi Lending on L2. Lending protocols deployed on L2s with centralised sequencers face existential risk during sequencer outages: liquidations cannot execute, collateral ratios deteriorate, and bad debt accumulates. Protocols should implement L1 fallback liquidation mechanisms and should consider requiring agents to maintain collateral buffers above the liquidation threshold by a margin that accounts for the maximum forced-inclusion delay (e.g., if forced inclusion takes 24 hours, maintain collateral sufficient to survive a 24-hour market move at historical 99th percentile volatility).
Cross-Chain Bridges. Bridge agents must implement the multi-tier finality model strictly. No funds should be released on the destination chain until the source chain transaction has reached L1-final status. Fast bridge services that front liquidity against unfinalized transactions must price the finality risk and cap exposure per unfinalized batch.
Institutional Custody on L2. Institutional custodians deploying assets on L2s must document the L2's dependency profile as part of their custody risk assessment. Regulators (particularly under MiCA and FCA custody rules) expect custodians to demonstrate awareness of and controls for the specific risks introduced by the L2 architecture, including sequencer risk, DA risk, and upgrade risk (see AG-211 for the bridge and rollup contract upgrade dimension).
Basic Implementation — The agent operates on L2s with awareness that sequencer-confirmed is not L1-final. A dependency registry exists documenting sequencer operator, DA mechanism, and challenge period for each L2. The agent does not credit counterparties based on unfinalized transactions. Sequencer health is monitored via RPC ping. This level provides basic risk awareness but lacks fallback strategies, DA verification, and escape hatch readiness.
Intermediate Implementation — Multi-tier finality model governs all agent actions. Sequencer health circuit breaker activates within 60 seconds and triggers predefined fallback strategies. DA freshness verification catches stale-data scenarios. L1 fallback contracts exist for critical operations. Per-chain exposure limits are enforced. Escape hatch drills are conducted quarterly. The agent can operate safely through sequencer outages of up to 24 hours without material loss.
Advanced Implementation — All intermediate capabilities plus: multi-RPC state comparison detects sequencer dishonesty. Independent full node validates L2 state against posted L1 data. Automated cross-chain position rebalancing occurs when a chain's risk profile degrades. The system can execute a full escape hatch withdrawal of all assets within the forced-inclusion delay window. Formal analysis of the L2's security model informs exposure limit calibration. Independent testing has confirmed that sequencer outage, DA failure, and fraud-proof invalidation scenarios are all handled without material loss.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Sequencer Outage Detection and Response
Test 8.2: Finality Model Enforcement
Test 8.3: DA Freshness Verification
Test 8.4: Per-Chain Exposure Limit
Test 8.5: Forced Inclusion Execution
Test 8.6: Escape Hatch Withdrawal
Test 8.7: Dependency Registry Accuracy
| Regulation | Provision | Relationship Type |
|---|---|---|
| MiCA | Article 68 (Obligations for Crypto-Asset Service Providers) | Direct requirement |
| MiCA | Article 70 (Safeguarding of Clients' Crypto-Assets) | Supports compliance |
| DORA | Article 9 (ICT Risk Management Framework) | Direct requirement |
| DORA | Article 28 (Third-Party ICT Service Providers) | Direct requirement |
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Supports compliance |
| FCA SYSC | 8.1 (Outsourcing Requirements) | Supports compliance |
| NIST AI RMF | MAP 3.2, MANAGE 2.2, MANAGE 4.1 | Supports compliance |
| ISO 42001 | Clause 6.1, Clause 8.2 | Supports compliance |
Article 28 requires financial entities to "identify, classify and document all functions and activities supported by ICT third-party service providers." For agents operating on L2 rollups, the sequencer and DA layer operators are ICT third-party service providers. AG-213's dependency registry (4.1) directly implements the identification and documentation requirement. The sequencer health monitoring (4.3) and DA verification (4.4) implement the ongoing monitoring requirement. The per-chain exposure limits (4.6) implement the concentration risk management requirement. DORA explicitly requires that "critical ICT third-party service providers" be subject to enhanced oversight — a centralised sequencer processing billions in daily transaction volume meets this threshold.
Article 9 requires financial entities to "identify all sources of ICT risk" and implement "ICT risk management tools, policies, procedures, protocols and tools." The dependencies introduced by L2 architecture — sequencer liveness, DA integrity, finality delay — are ICT risks that must be identified, assessed, and mitigated. AG-213 provides the specific tools (circuit breaker, DA verification, escape hatch testing) that implement ICT risk management for L2 dependencies.
A crypto-asset service provider that deploys client assets on an L2 without documenting and mitigating the L2's dependency risks is not acting "honestly, fairly, and professionally" (Article 68) and is not making "adequate arrangements to safeguard" client assets (Article 70). Specifically, if client assets are locked on an L2 during a sequencer outage and cannot be withdrawn via the escape hatch within a reasonable timeframe, the provider has failed to ensure client asset recoverability.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | All assets and operations on the affected L2 — potentially all client funds, protocol TVL, and pending transactions on that chain |
Consequence chain: Failure to govern L2 dependencies creates exposure that is invisible during normal operation (when the sequencer is healthy and the DA layer is responsive) but materialises catastrophically during stress events. A sequencer outage during a market crash prevents liquidations, causing bad debt accumulation at machine speed. A DA failure enables undetected fraudulent transactions. A finality misunderstanding causes irrecoverable advance of funds against invalidated transactions. The financial impact depends on the agent's exposure on the affected L2: for an agent managing USD 100 million across an L2's DeFi ecosystem, a 4-hour sequencer outage during a 20% market drop could result in USD 10-30 million in bad debt from failed liquidations alone. The operational impact includes loss of transaction execution capability, inability to rebalance positions, and potential asset lock if the escape hatch is untested and fails. The regulatory impact includes enforcement for inadequate third-party risk management (DORA Article 28), inadequate safeguarding (MiCA Article 70), and potential personal liability for senior managers who approved L2 deployment without adequate dependency analysis.
Cross-references: AG-001 (Operational Boundary Enforcement) defines the agent's mandate, which should include per-chain exposure limits and finality requirements. AG-007 (Governance Configuration Control) governs the versioning of the dependency registry and finality model configurations. AG-014 (External Dependency Integrity) provides the general framework for external dependency governance that AG-213 specialises for the L2 rollup context. AG-210 depends on AG-213 because client asset segregation on L2 is only meaningful if the L2's liveness and DA guarantees are maintained — a sequencer outage can prevent withdrawal of segregated assets. AG-211 addresses the upgrade risk of the rollup contracts themselves (bridge contract, sequencer contract, DA contract). AG-214 addresses the transaction inclusion and censorship risks that are a specific sub-dimension of sequencer dependency.