Definition
A major Solana blockchain reorganisation (“reorg”) invalidates previously confirmed transactions performed by ElizaOS agents (an open-source multi-agent operating system). This is not a direct attack on ElizaOS; it is an inherent infrastructure risk. However, if the agent framework does not handle reorgs gracefully, the invalidated transactions leave downstream agent state incorrect, compounding into financial losses or cascading failures in dependent workflows.
What it looks like in practice
An ElizaOS agent executes a confirmed buy order on a decentralised exchange. The trade appears in several block confirmations. The agent updates its internal position ledger, signals a peer agent to proceed with a follow-on sell strategy, and the peer agent begins placing orders. A blockchain reorganisation then occurs and the original buy transaction is reversed: it no longer exists on the canonical chain. The agent’s internal ledger still shows the position as open; the follow-on sell strategy continues to execute against a position that no longer exists on-chain, resulting in failed transactions, incorrect balance state, and potential double-spend conditions.
Why it’s dangerous in multi-agent context
Agents build multi-step workflows on the assumption of transaction finality. A reorg retroactively invalidates earlier steps without triggering any agent-layer error, because the original confirmation event was genuine at the time of emission. In a multi-agent deployment, the reorg propagates through agent-to-agent signals: the agent that received the now-invalid confirmation signals downstream agents, which take autonomous actions based on a world state that no longer exists. Without a reorg event subscription and reconciliation path, the inconsistency persists and compounds across the fleet until a human audit identifies the discrepancy. T35 (Manipulation of Proof of Sampling) is the adversarial complement: where T33 is an infrastructure-induced audit failure, T35 is an attacker-induced one.
Detection signals
A reorg leaves a specific audit fingerprint: the agent’s internal ledger records a position that no longer exists on the canonical chain, and downstream agents continue acting on signals derived from the now-invalid transaction.
- An agent’s internal position ledger showing an open position for a token pair while a query to the Solana RPC confirms no corresponding transaction at the recorded block height on the canonical chain: run a reconciliation check after every confirmation event and alert on any ledger-vs-chain discrepancy.
- A reorg event notification from the Solana RPC node (a
slotChangedorblockNotificationsubscription emitting a slot rollback) that is not followed within 30 seconds by areconciliation_startedevent in the agent’s own audit log: a missing-reconciliation alert triggered by the reorg event itself. - Downstream agent activity (e.g. sell orders placed) within a session window where the triggering buy transaction’s block hash does not appear in the current canonical chain: cross-reference every downstream tool call’s
triggering_tx_hashagainst the RPC node’s confirmed block index. - An
AlreadyProcessederror returned by the Solana runtime in response to a transaction submission: instrument the submission layer to count and alert on any such response, as it indicates the agent is resubmitting a transaction whose prior version was reorged. - An agent’s balance or position state changing without a corresponding agent-initiated transaction in its transaction log: an orphaned state change that signals the agent acted on a now-reorged confirmation.
Mitigations
- Wait for a sufficient confirmation depth (defined by the blockchain’s finality model) before treating a transaction as permanent and signalling downstream agents.
- Subscribe to reorg events from the blockchain node; implement a reconciliation path that rewinds affected agent state and cancels or replays downstream signals on detection.
- Store all agent state changes with the block hash and block height at which the triggering transaction was confirmed; use this metadata to identify and invalidate state derived from reorged blocks.
- Design multi-agent workflows to be idempotent and rollback-safe: downstream agents must be able to receive a “cancel prior signal” message and cleanly reverse any actions taken on the basis of the revoked confirmation.
Relation to base threat (T1–T17)
T33 extends T8 Repudiation and Untraceability. Where T8 addresses an attacker altering or suppressing records to evade accountability, T33 addresses an infrastructure event, the blockchain reorg, that retroactively alters the confirmed record of agent actions. The outcome is the same: the audit trail no longer accurately reflects what happened, and the agent’s state diverges from ground truth.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T33 is covered by the following Top 10 entries:
-
ASI08 Cascading Failures primary A single low-severity fault (a hallucinated value, a corrupted tool output, a poisoned memory entry) propagates across a network of agents that each build on the last agent's output, compounding into system-wide harm that is disproportionate to the original defect. ASI08 is about propagation and amplification, not the fault's origin; the initial trigger may itself be innocuous.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T33 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-Depth A blockchain reorganisation invalidates previously confirmed transactions without generating any agent-layer error: the original confirmation event was genuine at the time of emission, so the agent's normal error-handling path is never triggered. Single-layer defences that rely on confirmation events cannot detect a reorg after the fact. Depth means waiting for a sufficient confirmation depth before treating a transaction as permanent, maintaining a reorg event subscription with a reconciliation path that rewinds affected agent state and cancels downstream signals, storing all state changes with the block hash and height so that reorged blocks can be identified, and designing multi-agent workflows to be idempotent and rollback-safe: each layer independently limiting the damage of an invalidation that the previous layers failed to prevent or detect.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T33, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
-
An agent that has been compromised, poisoned, or gone rogue will, in most cases, behave differently from its established baseline. Anomaly isolation acts on that difference: when an agent's behaviour score crosses a configured threshold, it is quarantined automatically, credentials revoked, message-queue access cut, in-flight actions aborted. Manual revocation cannot match the speed that cascading multi-agent failures demand.
why it helps Blockchain reorg exploitation depends on an agent acting on unconfirmed transaction state before on-chain finality. Anomaly isolation detects agents that deviate from their expected transaction-confirmation behaviour and quarantines them before further on-chain actions are committed.
- Tier 2 Blockchain tx guard (Blockchain transaction guard — pre-commit safety checks for every agent-initiated transaction)
A blockchain transaction, once committed, cannot be undone. An agent that signs and broadcasts a transaction without an enforcement layer before it can exceed its authorised value, call a contract it was never provisioned to reach, or drain a wallet in a runaway loop, and by then the funds are gone. A transaction guard intercepts each proposed transaction before signing, checks it against value bounds, a contract allowlist, a gas or compute-unit limit, and a replay-protection nonce, and refuses to sign anything that falls outside declared policy.
why it helps Blockchain Reorganisation exploits the window between transaction broadcast and finality. Requiring N-block confirmation before treating a transaction as settled reduces the reorg exploitation window. The guard does not eliminate reorgs below the confirmation threshold, but it prevents the agent from acting on unconfirmed state.
Multi-agent variants: OWASP MAS Guide
The OWASP OWASP MAS Threat Modelling Guide v1.0 catalogues 1 named multi-agent variant of T33, anchored to specific MAESTRO layers. Each is a concrete attack pattern that emerges when this threat compounds across agents.
- CL Blockchain Reorganisation and Audit Integrity Collapse extends T33, T26, T8
A chain reorganisation attack (T33) rewrites the on-chain audit trail; agents relying on the reorged state make irrecoverable decisions (T26: resource misallocation); the post-hoc audit (T8) is unreliable because the canonical record itself changed.
Source: OWASP MAS Threat Modelling Guide v1.0, §2 Overview of MAESTRO Framework — Extended Threat Scenarios + Cross-Layer table.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
AML.T0031 Erode AI Model Integrity view on ATLAS ↗ Adversary degrades model output quality over time so users lose confidence or downstream consumers act on incorrect predictions.
AML.T0067 LLM Trusted Output Components Manipulation view on ATLAS ↗ Adversary manipulates the structured parts of an LLM response (citations, tool-call arguments, approved-action markup) that downstream systems treat as trusted.
Agentic angle: Structured outputs are exactly what agent frameworks parse to decide what to execute. Undermining the structure undermines every safety check downstream.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §4 ElizaOS — Layer 4 Deployment Infrastructure.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §4 Eliza OS — Layer 4 Deployment Infrastructure