Transaction Inclusion, Censorship and Liveness Governance

2. Summary

Transaction Inclusion, Censorship and Liveness Governance requires that every AI agent submitting transactions to public or permissioned blockchains implements structural controls to detect, mitigate, and respond to transaction censorship, delayed inclusion, selective ordering (MEV extraction), and liveness failures that prevent the agent's transactions from being included in blocks within operationally required timeframes. The dimension addresses the reality that transaction inclusion on blockchain networks is not guaranteed — it is contingent on the behaviour of block proposers, sequencers, relay operators, and the MEV supply chain (builders, searchers, relayers). An AI agent that assumes its submitted transactions will be included promptly and fairly is operating with an incorrect model of the network. On Ethereum mainnet post-Merge, approximately 90% of blocks are built through MEV-Boost relays, which introduce builder-level transaction selection that can exclude, delay, or reorder transactions for economic advantage. On L2 rollups, a centralised sequencer has absolute discretion over transaction inclusion. For AI agents executing time-sensitive operations — liquidations, oracle updates, governance votes, collateral adjustments, approval revocations (AG-212), or emergency pause transactions — censorship or delayed inclusion is not a theoretical risk but an operational reality that can result in millions of dollars in losses.

3. Example

Scenario A — Liquidation Transaction Censored by MEV Builder: An AI liquidation agent on Ethereum mainnet detects a lending position that has become undercollateralised: 500 ETH of collateral backing a 400 ETH debt, with the liquidation threshold at 80% LTV. The agent submits a liquidation transaction via the public mempool with a 50 gwei priority fee. An MEV searcher detects the liquidation opportunity, front-runs the agent's transaction with a higher priority fee (200 gwei), and captures the liquidation bonus (typically 5-10% of the collateral). The agent's transaction either fails (if the position is already liquidated) or is excluded from the block entirely because the builder preferentially includes the searcher's transaction. Over a 30-day period, the agent attempts 1,200 liquidations and is front-run on 847 of them, losing approximately USD 2.1 million in liquidation bonuses that it was entitled to earn.

What went wrong: The agent submitted transactions to the public mempool, exposing its intent to MEV searchers. It used a fixed priority fee rather than a dynamic strategy. No private transaction submission (e.g., Flashbots Protect, MEV Blocker) was employed. No analysis of block-builder behaviour informed the submission strategy. Consequence: USD 2.1 million in lost liquidation revenue, degraded protocol health (delayed liquidations during periods of high MEV competition), competitive disadvantage.

Scenario B — Governance Vote Censored During Critical Proposal: An AI governance agent is instructed to cast a vote against a malicious governance proposal that would transfer USD 45 million from the protocol treasury to an attacker-controlled address. The proposal is in its final 4-hour voting window. The agent submits the vote transaction via the public mempool. The attacker, who controls a significant share of MEV builder infrastructure, instructs their builders to exclude any transactions that call the castVote() function on the governance contract with a "No" vote. The agent's transaction is not included in any block for 3 hours and 47 minutes. With 13 minutes remaining, the agent detects the censorship and attempts to submit via Flashbots Protect, but the remaining time is insufficient to accumulate enough votes to defeat the proposal. The malicious proposal passes. USD 45 million is transferred from the treasury.

What went wrong: The agent had no censorship detection mechanism — it waited for block inclusion without monitoring whether its transaction was being systematically excluded. It had no alternative submission channels pre-configured. It did not detect the censorship pattern (all "No" votes being excluded) and alert operators. No fallback mechanism (e.g., direct validator submission, cross-chain governance relay) existed. Consequence: USD 45 million treasury loss, governance failure, protocol trust destroyed.

Scenario C — Emergency Pause Transaction Delayed by Network Congestion: An AI security agent detects an ongoing exploit draining USD 8 million from a DeFi protocol at a rate of USD 200,000 per minute. The agent submits an emergency pause() transaction to halt the protocol. However, the exploit itself is generating extreme network congestion: the attacker is submitting hundreds of transactions per block to extract funds, driving gas prices to 800 gwei (from a baseline of 30 gwei). The agent's pause transaction, submitted at 100 gwei, is not competitive. The agent increases to 500 gwei — still not competitive. By the time the agent's gas price exceeds the attacker's (at 1,000 gwei), 12 minutes have passed and USD 2.4 million has been drained. The pause transaction finally executes, halting further loss, but the delayed inclusion cost USD 2.4 million.

What went wrong: The agent used an incremental gas price escalation strategy rather than an immediate maximum-priority submission for emergency transactions. No pre-signed emergency pause transaction with maximum gas was maintained in a hot standby. No Flashbots bundle was used to guarantee inclusion in the next block (Flashbots bundles bypass gas price competition by paying the builder directly). Consequence: USD 2.4 million additional loss due to delayed pause, incident response failure, regulatory scrutiny.

4. Requirement Statement

Scope: This dimension applies to any AI agent that submits transactions to a public or permissioned blockchain where transaction inclusion depends on the behaviour of block proposers, sequencers, builders, or relay operators. This includes Ethereum mainnet (where block builders select transactions), L2 rollups (where sequencers order transactions), and any chain where the agent's transaction may be censored, delayed, reordered, or excluded by the entity responsible for block production. The scope includes agents submitting user-facing transactions, governance votes, oracle updates, liquidations, emergency responses, approval revocations, and any other on-chain action. An agent that only reads on-chain state without submitting transactions is excluded.

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 implement censorship detection that identifies when an agent's transaction has not been included within a configurable number of blocks after submission (default: 5 blocks on Ethereum mainnet; 30 seconds on L2s), triggering an escalation procedure.

4.2. A conforming system MUST maintain at least two independent transaction submission channels (e.g., public mempool plus Flashbots Protect, or multiple builder-direct APIs) and automatically failover to an alternative channel when the primary channel fails to achieve inclusion within the configured threshold.

4.3. A conforming system MUST implement a priority fee strategy that dynamically adjusts based on network conditions, with the ability to immediately escalate to maximum priority for emergency transactions (emergency pause, exploit response, critical approval revocations).

4.4. A conforming system MUST pre-sign and maintain in hot standby any emergency transactions (pause, shutdown, emergency withdrawal) at maximum gas price, ready for immediate submission via multiple channels simultaneously.

4.5. A conforming system MUST log every transaction submission attempt, including: submission channel, gas price, priority fee, block number at submission, block number at inclusion (or failure), and any censorship detection events.

4.6. A conforming system MUST NOT submit transactions containing sensitive operational intent (liquidation targets, large trade parameters, governance vote direction) to the public mempool without MEV protection (private transaction submission, commit-reveal schemes, or encrypted mempools).

4.7. A conforming system SHOULD implement MEV-aware transaction submission using Flashbots Protect, MEV Blocker, or equivalent private submission channels that prevent front-running and sandwich attacks.

4.8. A conforming system SHOULD monitor block builder and sequencer behaviour for patterns of selective censorship (e.g., systematically excluding transactions to specific contracts, from specific addresses, or with specific function selectors) and report detected patterns.

4.9. A conforming system SHOULD implement commit-reveal schemes for transactions where the content of the transaction itself creates an MEV opportunity (e.g., large swaps, oracle updates, governance votes), separating the commitment to transact from the revelation of transaction parameters.

4.10. A conforming system MAY implement transaction submission through multiple geographically distributed nodes to increase inclusion probability and resist regional censorship.

5. Rationale

Transaction inclusion on blockchain networks is not a technical guarantee — it is an economic and political process. On Ethereum mainnet, block proposers (validators) delegate block construction to builders through the MEV-Boost relay system. Builders construct blocks to maximise their own revenue, which means they include transactions that pay the highest fees and arrange transactions in an order that extracts the most MEV (Maximal Extractable Value). A transaction that creates an MEV opportunity for a searcher (e.g., a large swap that can be sandwiched) will be included — but reordered to the searcher's advantage. A transaction that competes with a searcher's transaction may be excluded entirely.

Censorship — the deliberate exclusion of a valid transaction — is distinct from delayed inclusion due to fee competition, but the practical effect is the same: the agent's transaction does not execute when needed. OFAC compliance censorship by builders (refusing to include transactions involving sanctioned addresses) demonstrated in 2022-2023 that builder-level censorship is technically trivial and, for some builders, routine. The percentage of OFAC-compliant blocks peaked at approximately 73% in November 2022 before declining, but the mechanism exists and can be repurposed for any censorship criterion.

For AI agents, the consequences of transaction censorship or delayed inclusion are severe:

Liquidation timing. DeFi lending protocols depend on timely liquidations to maintain solvency. A 10-minute delay in liquidation during a rapid price decline can convert a solvent position into bad debt. If the agent's liquidation transaction is censored or front-run, the protocol (and by extension its depositors) absorbs the loss.

Emergency response. When a protocol is under active exploit, every second counts. An emergency pause transaction that is delayed by even 5 minutes can cost millions. If the attacker is driving gas prices higher as part of the exploit (a common pattern), the agent's pause transaction may be economically excluded.

Governance. On-chain governance votes with fixed deadlines create censorship opportunities: an attacker who can delay opposing votes until the deadline passes wins the vote regardless of actual sentiment. This is particularly dangerous for governance proposals that modify protocol parameters, transfer treasury funds, or change access controls.

Approval revocation. Following AG-212 (Delegated Spend, Token Allowance and Session-Key Governance), emergency approval revocation during a security event depends on timely transaction inclusion. If the revocation transaction is delayed, the attacker may drain approved assets before the revocation executes.

The MEV supply chain (searchers → builders → relays → proposers) creates a complex landscape where transaction inclusion is mediated by multiple parties, each with their own economic incentives. An AI agent that does not account for this landscape — that assumes "submit transaction, get inclusion" — is operating with a naive model that will fail precisely when inclusion matters most.

6. Implementation Guidance

Recommended patterns:

• Multi-channel submission. Maintain simultaneous connections to: (1) the public mempool (for baseline inclusion probability), (2) Flashbots Protect or MEV Blocker (for private submission that prevents front-running), (3) at least one builder-direct API (e.g., Beaverbuild, Titan Builder) for guaranteed inclusion at a price, and (4) the L2 sequencer's direct submission endpoint (for L2 operations). When a transaction is time-sensitive, submit to all channels simultaneously. The first inclusion wins; duplicate submissions on other channels are harmless (they will fail with a nonce error).
• Emergency transaction hot standby. For each contract under the agent's operational scope, pre-sign emergency transactions (pause, shutdown, emergency withdrawal) at a gas price of 10x the current 99th percentile gas price. Store these pre-signed transactions in a secure, immediately accessible cache. Update them every 100 blocks to keep the nonce current and the gas price relevant. When an emergency is detected, submit all relevant pre-signed emergency transactions to all channels simultaneously. This eliminates the latency of transaction construction and signing during a crisis.
• Censorship detection heuristic. After submitting a transaction, monitor each subsequent block. For each block, check: (a) was the transaction included? (b) if not, was the gas price competitive (i.e., above the block's minimum included priority fee)? If the transaction's gas price was competitive but it was excluded for N consecutive blocks, flag this as potential censorship. N should be calibrated: on Ethereum mainnet, N=3 (approximately 36 seconds) is a reasonable threshold for a competitive-gas transaction. On detection, escalate to alternative channels, alert the operations team, and log the event for pattern analysis.
• Commit-reveal for high-value transactions. For transactions where the parameters themselves create MEV opportunities (e.g., a swap of 10,000 ETH, a governance vote in a contested election), implement a two-phase commit-reveal scheme: (1) submit a commit transaction containing a hash of the actual transaction, (2) after the commit is included, submit a reveal transaction containing the actual parameters. This prevents front-running because the parameters are not visible until after the commitment is on-chain. Gas overhead is approximately 2x (two transactions instead of one), but the MEV savings on large transactions can be orders of magnitude larger.
• Dynamic gas escalation with ceiling. Implement a gas price strategy that starts at the current base fee + 2 gwei priority and doubles the priority fee every 2 blocks if not included, up to a configurable ceiling. For emergency transactions, skip the escalation and submit at the ceiling immediately. The ceiling should be set based on the maximum acceptable inclusion cost for the transaction type (e.g., USD 50 for a routine swap, USD 10,000 for an emergency pause protecting USD 100 million in assets).

Anti-patterns to avoid:

• Public mempool submission for sensitive transactions. Submitting a large swap, a liquidation, or a governance vote to the public mempool exposes the agent's intent to every searcher and builder monitoring the mempool. This is the primary vector for front-running, sandwiching, and censorship. Always use private submission channels for transactions with MEV exposure.
• Fixed gas price strategy. A fixed gas price (e.g., always submit at 30 gwei) will result in non-inclusion during congestion periods and overpayment during low-activity periods. Dynamic adjustment is essential.
• Single submission channel. Relying solely on the public mempool, or solely on Flashbots, creates a single point of failure. If Flashbots Protect is down, the agent has no private submission alternative. Multi-channel redundancy is critical.
• Ignoring transaction failure after submission. An agent that submits a transaction and moves on without monitoring for inclusion may never discover that the transaction was censored. Every submission must be tracked to inclusion or failure.
• Escalating gas without a ceiling. An agent that escalates gas indefinitely in pursuit of inclusion can be exploited: an attacker can create artificial congestion to drain the agent's gas budget. Ceilings prevent unbounded gas spend.

Industry Considerations

DeFi Protocols (Liquidation Bots). Liquidation agents should use Flashbots bundles for all liquidation transactions, bundling the liquidation with the subsequent collateral swap in a single atomic package. This eliminates the risk of front-running and ensures the agent captures the liquidation bonus. The bundle should include a tip to the builder that makes inclusion economically rational.

Oracle Providers. Oracle update agents must ensure that price feed updates are included within tight timeframes (typically within 1 block of the trigger condition). Delayed oracle updates can cause cascading liquidation failures across all protocols using the oracle. Oracle agents should use multi-channel submission and pre-signed update transactions.

DAO Governance. Governance platforms should implement commit-reveal voting to prevent vote censorship. The commit phase reveals only the voter's identity and the fact that they voted — not the vote direction. The reveal phase, occurring after the commit deadline, reveals the actual votes. This prevents builders from censoring votes based on direction.

Sequencer-Dependent Chains. For L2 agents, sequencer censorship is a direct risk (see AG-213). The forced-inclusion mechanism is the primary mitigation, but it has a multi-hour delay. For time-sensitive L2 transactions, agents should maintain L1 fallback mechanisms that can execute the equivalent action on L1 if the L2 sequencer censors the transaction.

Maturity Model

Basic Implementation — The agent uses a single submission channel (public mempool or sequencer RPC) with a dynamic gas price strategy. Transaction inclusion is monitored — the agent detects when a transaction is not included within a threshold and retries with higher gas. Emergency transactions use maximum gas. No private submission, no censorship detection, and no multi-channel redundancy. This level handles fee competition but is vulnerable to censorship and MEV extraction.

Intermediate Implementation — Multi-channel submission (public mempool plus Flashbots Protect or equivalent). Sensitive transactions are submitted privately. Censorship detection heuristic identifies potential exclusion patterns. Emergency transactions are pre-signed and available in hot standby. Dynamic gas escalation with configurable ceilings. All submission attempts are logged with inclusion outcomes. The agent can achieve transaction inclusion within 5 blocks under normal conditions and within 2 blocks for emergency transactions.

Advanced Implementation — All intermediate capabilities plus: commit-reveal schemes for high-value transactions. Multi-builder direct submission. Geographic distribution of submission nodes. Builder behaviour analysis identifies censorship patterns and adjusts submission strategy. Integration with encrypted mempool proposals (e.g., threshold encryption schemes) where supported. Independent testing has confirmed that the agent achieves inclusion under simulated censorship scenarios including builder collusion, extreme gas price manipulation, and sequencer selective exclusion. L1 fallback mechanisms for L2 censorship scenarios.

7. Evidence Requirements

Required artefacts:

• Transaction submission logs. Complete logs of all transaction submissions, including: submission channel, gas parameters, block number at submission, block number at inclusion (or failure), retry attempts, channel failovers, and censorship detection events. Minimum 12 months.
• Submission channel configuration. Documentation of all configured submission channels, including endpoints, authentication, failover logic, and backup channels.
• Emergency transaction inventory. List of all pre-signed emergency transactions maintained in hot standby, including contract addresses, function selectors, gas parameters, nonce management strategy, and refresh frequency.
• Censorship incident reports. Reports of any detected censorship events, including the evidence, the response taken, the outcome, and any pattern analysis.
• MEV exposure analysis. Periodic (minimum monthly) analysis of the agent's MEV exposure: how many transactions were front-run, sandwiched, or excluded due to MEV competition, and the estimated financial impact.

Retention requirements:

• Transaction submission logs and censorship incident reports: minimum 7 years for regulated financial services; minimum 5 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours.

8. Test Specification

Test 8.1: Censorship Detection

• Stimulus: Submit a transaction with competitive gas pricing and simulate censorship by configuring the test environment to exclude the transaction from the next 10 blocks.
• Expected behaviour: The censorship detection heuristic identifies the exclusion pattern within 5 blocks (configurable threshold) and triggers the escalation procedure: failover to alternative submission channel, alert generation, and logging.
• Pass criteria: Censorship is detected within the configured block threshold; escalation activates automatically.
• Fail criteria: The agent does not detect censorship or does not escalate.

Test 8.2: Multi-Channel Failover

• Stimulus: Disable the agent's primary submission channel and submit a transaction.
• Expected behaviour: The agent detects the primary channel failure and automatically submits via the secondary channel. The transaction is included within the expected timeframe.
• Pass criteria: Failover occurs automatically; the transaction is included via the alternative channel without manual intervention.
• Fail criteria: The agent fails to submit the transaction or requires manual intervention to switch channels.

Test 8.3: Emergency Transaction Readiness

• Stimulus: Trigger an emergency condition (e.g., exploit detection) and measure the time from detection to emergency transaction submission.
• Expected behaviour: Pre-signed emergency transactions are submitted to all channels within 5 seconds of the emergency trigger.
• Pass criteria: Emergency transaction submitted within 5 seconds; included within 2 blocks on L1 or 5 seconds on L2.
• Fail criteria: Emergency transaction submission takes longer than 5 seconds, or inclusion takes longer than the expected timeframe.

Test 8.4: MEV Protection

• Stimulus: Submit a transaction that creates an MEV opportunity (e.g., a large swap) through the private submission channel and verify that no front-running or sandwiching occurs.
• Expected behaviour: The transaction is included without any related MEV extraction transactions in the same block or adjacent blocks.
• Pass criteria: No front-running or sandwich transactions are observed around the agent's transaction.
• Fail criteria: MEV extraction transactions (front-run or sandwich) are observed, indicating private submission failure.

Test 8.5: Dynamic Gas Escalation

• Stimulus: Submit a transaction during a period of high gas prices where the initial priority fee is insufficient for inclusion.
• Expected behaviour: The agent dynamically increases the priority fee according to the configured escalation strategy until the transaction is included, without exceeding the configured ceiling.
• Pass criteria: The transaction is included after escalation; the final gas price does not exceed the ceiling.
• Fail criteria: The transaction is not included despite escalation, or the gas price exceeds the configured ceiling.

Test 8.6: Private Submission for Sensitive Transactions

• Stimulus: Instruct the agent to submit a liquidation transaction and verify that it uses a private submission channel rather than the public mempool.
• Expected behaviour: The transaction is submitted via Flashbots Protect, MEV Blocker, or equivalent private channel. No trace of the transaction appears in the public mempool before inclusion.
• Pass criteria: Sensitive transactions are never submitted to the public mempool.
• Fail criteria: A sensitive transaction appears in the public mempool before block inclusion.

Test 8.7: Submission Logging Completeness

• Stimulus: Submit 100 transactions across various channels and conditions, then audit the submission logs.
• Expected behaviour: Every submission attempt is logged with all required fields (channel, gas parameters, block numbers, outcome).
• Pass criteria: 100% of submission attempts are logged with complete metadata.
• Fail criteria: Any submission attempt is missing from the logs or has incomplete metadata.

Conformance Scoring

• Score 0: The agent submits all transactions to the public mempool with fixed gas pricing and no inclusion monitoring — fully exposed to censorship, MEV extraction, and delayed inclusion.
• Score 1: Dynamic gas pricing and transaction inclusion monitoring exist, but all transactions go through a single public channel with no private submission, no censorship detection, and no emergency readiness — basic fee management without MEV or censorship protection.
• Score 2: Multi-channel submission with private channels for sensitive transactions; censorship detection heuristic with automatic escalation; pre-signed emergency transactions in hot standby; dynamic gas escalation with ceiling; complete submission logging — structural controls handle MEV, censorship, and emergency scenarios.
• Score 3: All Score 2 capabilities plus commit-reveal schemes, multi-builder direct submission, geographic distribution, builder behaviour analysis, encrypted mempool integration, and independent adversarial testing confirming transaction inclusion under simulated censorship and MEV attack scenarios.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
MiCA	Article 68 (Obligations for Crypto-Asset Service Providers)	Supports compliance
MiCA	Article 76 (Best Execution)	Direct requirement
MiFID II	Article 27 (Best Execution)	Direct requirement
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Supports compliance
FCA COBS	11.2 (Best Execution)	Direct requirement
NIST AI RMF	MANAGE 2.2, MANAGE 4.1	Supports compliance
ISO 42001	Clause 6.1, Clause 8.2	Supports compliance

MiCA — Article 76 (Best Execution)

Article 76 requires crypto-asset service providers to "take all sufficient steps to obtain the best possible result for their clients when executing orders." In blockchain environments, "best execution" includes not just price but also the cost of transaction inclusion (gas fees), the risk of MEV extraction (front-running, sandwiching), and the timeliness of execution. An agent that submits a large swap to the public mempool, enabling a sandwich attack that costs the client 2% of the trade value, has failed its best execution obligation. AG-214's requirement for private submission channels (4.6, 4.7) and MEV-aware strategies directly implements best execution for on-chain order execution.

MiFID II — Article 27 (Best Execution)

Article 27's best execution requirement has been interpreted by ESMA to include execution venue selection, timing, and all costs associated with execution. For AI agents executing trades on DEXs, the MEV supply chain is part of the execution cost. An agent that does not use MEV protection is not achieving best execution because a predictable, avoidable cost (MEV extraction) is being imposed on the client. AG-214 provides the specific controls — private submission, commit-reveal, multi-channel failover — that constitute best execution in the on-chain context.

FCA COBS — 11.2 (Best Execution)

COBS 11.2 requires firms to "take all sufficient steps to obtain the best possible result for their clients." For crypto trading agents, this maps directly to AG-214's MEV protection requirements. The FCA has signalled through its Crypto-Asset Activities consultation that it expects firms offering crypto-asset trading to demonstrate equivalent best execution standards, which necessarily includes MEV mitigation.

DORA — Article 9 (ICT Risk Management Framework)

Transaction censorship and liveness failures are ICT risks. An agent that cannot submit transactions because its submission channel has failed, or because its transactions are being censored, has experienced an ICT incident that must be identified, managed, and reported per DORA Article 9. AG-214's multi-channel failover (4.2), censorship detection (4.1), and logging requirements (4.5) implement ICT risk management for the transaction submission layer.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	All operations dependent on timely transaction inclusion — potentially all assets under the agent's management, all protocol users dependent on the agent's operations (e.g., liquidation bots protecting protocol solvency), and all governance outcomes where the agent's vote was censored

Consequence chain: Failure of transaction inclusion governance creates a timing vulnerability where the agent's intended actions do not execute when needed. The severity depends entirely on context: a delayed swap of USD 1,000 may cost a few dollars in slippage; a delayed liquidation during a market crash may cost millions in bad debt; a censored emergency pause during an active exploit may cost the entire protocol TVL; a censored governance vote may result in a hostile governance takeover. The failure mode is particularly dangerous because it is often invisible — the agent submitted the transaction, it simply was not included. Without active inclusion monitoring and censorship detection, the agent may not even know its transaction failed until the consequences materialise. The financial impact ranges from marginal (MEV extraction on routine transactions) to catastrophic (emergency transaction censorship during an exploit). The regulatory impact includes best execution violations (MiCA Article 76, MiFID II Article 27), ICT incident reporting obligations (DORA Article 19), and potential enforcement for inadequate systems and controls. The systemic impact is particularly acute for liquidation agents: if multiple liquidation bots are simultaneously censored during a market crash, the resulting bad debt cascade can threaten protocol solvency and trigger contagion across the DeFi ecosystem.

Cross-references: AG-001 (Operational Boundary Enforcement) defines the mandate within which the agent's gas budget and submission strategy operate. AG-007 (Governance Configuration Control) governs the versioning of submission channel configurations, gas ceilings, and censorship detection thresholds. AG-014 (External Dependency Integrity) provides the general framework for managing dependencies on external infrastructure (MEV relays, builder APIs, sequencer endpoints) that AG-214 specialises for the transaction inclusion context. AG-212 depends on AG-214 because emergency approval revocations require timely transaction inclusion — a censored revocation leaves approvals exposed. AG-213 addresses the broader sequencer dependency that determines L2 transaction inclusion, while AG-214 focuses on the agent's strategies for ensuring inclusion within those constraints. AG-210 depends on AG-214 because segregation enforcement actions (emergency asset movement, reconciliation corrections) require transaction inclusion to execute.