💻 computer science

Safety Invariants for Agents Orchestrating Irreversible State Transitions: A Four-Dimensional Formalism Evaluated on Public Ledgers

This paper introduces a four-dimensional formalism and seven derived safety invariants to guarantee "execution fidelity" for autonomous agents performing irreversible state transitions on public ledgers, ensuring that realized effects are either null or exactly match the user-rendered transition, a framework empirically validated to significantly improve safety over standard baselines in adversarial settings.

Original authors: Zhaoming Yin

Published 2026-08-04

📖 8 min read🧠 Deep dive

CC BY 4.0

Original authors: Zhaoming Yin

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are handing a very smart, but slightly scatterbrained, robot butler a list of chores. You say, "Please move my allowance from my piggy bank to my savings jar." In the world of computer science, this is the realm of autonomous agents: software programs that use artificial intelligence to make decisions and take actions on their own. Usually, these agents are great at answering questions or writing stories, but they are just starting to learn how to touch the real world—like moving money, saving files, or turning on lights. The problem is that some of these actions are irreversible. Once you transfer money to a stranger or delete a file, you can't just hit "undo." If the robot misunderstands your order, or if the internet glitches, you could lose everything. This paper tackles the scary question: How do we make sure a robot doesn't accidentally burn your money while trying to help you?

The author of this paper is building a safety system for these digital butlers, specifically for the world of blockchains (public ledgers where money and assets live). They realized that existing safety checks were too vague. Instead of just hoping the robot "gets it right," they created a strict mathematical rulebook. They proved that while we can't force a robot to perfectly understand human intent (because language is messy), we can guarantee that the robot will either do nothing at all or do exactly what it promised to do, and only once. They call this "execution fidelity." Think of it like a magic contract: if the robot says it will move $10, it either moves exactly $10, or it moves $0. It cannot move $100, it cannot move $10 twice, and it cannot move $10 to the wrong person. If the robot gets confused, the system forces it to stop and ask for help, rather than guessing and potentially causing a disaster.

The Four-Dimensional Map

To make this guarantee possible, the author invented a new way to look at a digital wallet. Instead of just thinking about "how much money I have," they map every transaction onto a four-dimensional grid. Imagine a giant spreadsheet where every row is a specific state of your money, defined by four coordinates:

Wallet: Which set of keys (your identity) owns the money.
Chain: Which digital highway the money is on (like Ethereum, Bitcoin, or Solana).
Address: The specific mailbox on that highway.
Protocol: The specific type of asset or game the money is playing (like USDC, a bridge token, or a staked derivative).

The paper argues that you cannot safely move money unless you know all four of these coordinates. If you only know three, you might accidentally send your Bitcoin to a Bitcoin address that doesn't exist on the Ethereum chain, or send it to the wrong wallet entirely. By treating the transaction as a precise move on this 4D grid, the system can check the "before" and "after" states with mathematical certainty.

The Seven Safety Rules (The Invariants)

The core of the paper is a set of seven safety rules (called invariants) that the robot must follow. These aren't just suggestions; they are hard-coded gates that stop the robot from acting if the rules aren't met. Here is how they work in everyday terms:

The "Show Me" Gate: Before the robot touches your money, it must show you a preview of the exact move it plans to make. You (or a strict automated check) must say "Yes" to that specific preview. The robot cannot just say "I'm doing it" and then do something different.
The "Check the Balance" Gate: Right before the robot signs the transaction, it must check the real balance on the blockchain, not a cached or old number. If the money isn't there, the robot stops. This prevents the robot from trying to spend money that vanished a second ago.
The "Wait and See" Rule: After the robot sends a transaction, it doesn't immediately say "Success!" if it can't see the result on the blockchain yet. If the internet is slow or the blockchain is busy, the robot says "I'm not sure yet" instead of "It's done!" This stops the robot from panicking and trying to send the money again just because it didn't get an instant reply.
The "No Ghost Success" Rule: If the robot gets a receipt (a transaction ID) but the blockchain never actually records the move, the robot admits it failed. It refuses to lie and say "Sent!" when the money is still in your pocket.
The "ID Badge" Rule: If a robot is acting on your behalf (like an automated savings bot), it must wear a digital ID badge that says exactly what it is allowed to do. If the badge says "Transfer only," the robot cannot "Swap" or "Bridge" money, even if it gets confused by a tricky prompt.
The "Verify Before Retry" Rule: If the robot thinks a move failed, it cannot just try again immediately. It must first go check the blockchain to prove the move didn't happen. If the move actually did happen (but the robot didn't know), the robot is forbidden from sending it a second time. This prevents "double-spending" your money by accident.
The "One Message" Rule: If the internet accidentally sends the same request twice (like a double-click), the system recognizes it as a duplicate and ignores the second one. This ensures that even if the network glitches, the robot only acts once.

What They Found (and What They Didn't)

The author tested these rules using a "villain" simulator that tried to trick the robot into making mistakes. They used a dataset of 60 tricky scenarios and tested them against four different AI models.

The Big Win: On two AI models that were eager to act (called "write-aggressive"), adding these seven safety rules improved the success rate by about 74 percentage points. The unguarded robot (without rules) failed almost everything, while the guarded robot succeeded most of the time.
The Caveat: On one AI model that was naturally cautious and hesitant to act, the safety rules only added about 3 percentage points of improvement. This taught the author a crucial lesson: the safety of an agent depends heavily on which AI brain is underneath it. A safety layer can't fix a brain that is too eager, nor does it need to fix a brain that is already too careful.
Real-World Proof: The system isn't just a theory. The author deployed it in the real world and tracked 108 actual write operations across 8 different blockchains. They observed real-world failures (like "phantom successes" where the internet lied about a transaction) and showed how their rules caught them. For example, they found a case where a robot almost double-spent $200 because it thought a transaction failed when it actually succeeded; the safety rules stopped the second attempt.

The Limits of the Magic

The paper is very honest about what it cannot do. It explicitly states that it cannot guarantee the robot understood what you meant. If you say "Send all my money to the moon" and the robot sends it to a scammer, the system will still work perfectly: it will send exactly what you asked for, exactly once. The safety system ensures the robot is a faithful executor, not a wise advisor. It makes sure the robot doesn't make mistakes in the process, but it doesn't stop the robot from following a bad order.

The author also admits that their safety guarantee stops if the internet connection is broken for too long, or if the AI model itself changes its behavior in a way the system didn't expect. They proved that their seven rules are enough to stop the robot from making technical errors (like sending twice or sending to the wrong address), but the final responsibility of "Is this a good idea?" still rests with the human.

In short, this paper doesn't solve the problem of "How do I make a robot that thinks like a human?" Instead, it solves "How do I make a robot that acts like a robot, but never makes a mistake while doing it?" By turning the messy world of digital money into a precise four-dimensional map and building seven unbreakable gates, they created a system where the only thing that can go wrong is if you ask for something bad in the first place. And that, they argue, is the best safety we can hope for.

Technical Summary: Safety Invariants for Agents Orchestrating Irreversible State Transitions

Problem Statement

Autonomous agents based on probabilistic planners (LLMs) are increasingly tasked with producing irreversible effects on external systems, such as transferring funds on public ledgers, writing to durable storage, or actuating hardware. Existing frameworks (e.g., ReAct, Reflexion, MCP) optimize for task success on benchmarks but largely ignore the safety of irreversible side-effects.

The core challenge is that a runtime layer cannot definitively determine if a generated transition faithfully renders a natural-language user intent (the "intent-mapping" problem). However, the paper argues that while intent mapping is unsolved, the execution of that intent can be strictly controlled. Without such controls, agents suffer from specific failure modes:

RPC-level: "Phantom success" (RPCs returning hashes that are later retracted) or "Phantom failure" (legitimate transactions landing but reporting as failed due to short verification windows).
LLM-level: "Stale-context drift," where agents parrot outdated conclusions (e.g., "user has no account") even after ground truth changes.
Exchange/API-level: "Documented-atomicity drift," where actions specified as atomic (e.g., cancel-and-replace) execute only partially upon rejection, leaving users in unsafe states.
Operational: Duplicate deliveries and mis-mapped wallet selections leading to unintended double-spends.

Methodology and Formalism

Four-Dimensional State Space

The paper formalizes wallet operations as state transitions in a four-dimensional space $S = W \times C \times A \times P$ :

$W$ (Wallet): The mnemonic/seed controlling the funds.
$C$ (Chain): The blockchain network.
$A$ (Address): The specific address on that chain.
$P$ (Protocol): The specific token, contract, or off-chain account (e.g., USDC on Arbitrum vs. perp-USDC on Hyperliquid).

A transition $\tau$ is a partial function modifying balances at a bounded set of quadruples. Crucially, the formalism treats the Wallet ( $W$ ) as a fixed coordinate for a single transition. This allows the system to distinguish between "insufficient funds" (a valid state check failure) and "wrong wallet selection" (a fatal error where the agent chose the wrong $W$ ), a distinction lost in lower-dimensional models.

Execution Fidelity

The paper defines Execution Fidelity as the guarantee that for any session $\sigma$ , the realized effect on the ledger, $real(\sigma)$ , is either:

Nothing ( $\emptyset$ ), or
Exactly the transition $\tau_p$ that was rendered to the user, exactly once.

The theorem explicitly does not claim that $\tau_p$ matches the user's natural language intent. Instead, it reduces the unbounded semantic question of "did the agent understand?" to a bounded, decidable check: "does the four-coordinate tuple and amount match what was previewed?"

The Seven Safety Invariants

Derived via case analysis of the fidelity condition (preventing unrendered execution, duplicate execution, and derived-but-different execution), the system enforces seven invariants:

Confirm Gate (Executor-local): No signing key is derived until an explicit confirmation is recorded against a rendered transition tuple. This forces the system to commit to a single point in $S$ before irreversible steps.
Pre-state Sufficiency (Executor-local): A ground-truth balance check (bypassing eventually-consistent caches) is performed immediately before signing to ensure the transition is applicable at broadcast time.
Post-state Observability (Executor-local): If a broadcast outcome cannot be observed within a bounded window, the system reports "uncertainty" rather than "failure" to prevent false triggers for retries.
No Phantom Success (Executor-local): A transaction is never reported as successful unless its existence on the chain is verified by an indexer or RPC.
Scoped Delegation (Cross-tier): Non-human callers (avatars) operate under explicit scope sets (e.g., {transfer}) derived from delegation tokens. The executor admits calls only if the scope covers the required transition, decoupling authentication from authorization.
Plan-level Retry Safety (Plan-level): Avatars may not re-issue an irreversible transition on a reported failure/uncertainty until they have positively verified via ground-truth state that the transition's effect is absent.
Idempotent Intent Receiver (HTTP Receiver): External intents arriving over at-least-once channels are deduplicated by hashing the sender ID and request bytes, ensuring a single user intent produces a single transition tuple.

Key Contributions

Formal Reduction of Risk: The paper proves that under a fault model admitting planner mis-mapping, ambiguous outcomes, and retries, the seven invariants confine all residual risk to the single predicate of intent-mapping. Every other failure mode is forced to yield no effect.
Derivation of Invariants: Unlike prior work that enumerates safety rules from experience, these invariants are derived logically from the definition of execution fidelity, ensuring completeness with respect to the defined fault model.
Multi-Tier Architecture: The paper describes cryptitalk-wallet, a deployed system with an Avatar tier (persistent agents acting on behalf of users) and an Executor tier (the wallet service). The architecture treats avatars and humans as interchangeable callers from the executor's perspective, secured by scoped delegation tokens.
Methodological Argument on Evaluation: The paper argues that safety evaluations are highly dependent on the "backing model" (the LLM). A safety stack's value is a function of the model's inherent aggressiveness; evaluating a stack on a single model is "close to unfalsifiable."

Empirical Results

Controlled Adversarial Suite ( $N=60$ )

The system was evaluated against a labeled adversarial prompt suite targeting the identified failure classes across four backing models:

Write-Aggressive Models (Claude, MiniMax): The full invariant stack lifted the pass rate by ~74 percentage points over a baseline ReAct approach (e.g., 81.7% vs 10.2% for Claude).
Write-Cautious Model (Gemini): The stack lifted the pass rate by only ~3 points (60.0% vs 56.7%), as the model itself declined write tools on ambiguous prompts.
Ablation Studies: Disabling code-gate invariants (I1, I3, I5, I6, I7) caused pass rates to collapse to near-zero on specific failure classes, confirming each gate is load-bearing. Tool-level ablations (I2, I4) showed smaller impacts, as agent reasoning sometimes absorbed single-tool removals.

Production Deployment

The system has performed 108 production write operations across 8 chains and 8 transition primitives.

Failure Taxonomy: The deployment record validated the failure taxonomy, with incidents observed for "Phantom success," "Preview gate bypass," "Wrong-wallet selection," and "Duplicate webhook delivery."
Avatar Fleet: In a fleet of 87 DCA (Dollar Cost Averaging) runs, 32% succeeded, 32% were escalated to humans, 24% errored (correctly surfaced), and 11% were aborted. Crucially, no duplicated on-chain transitions occurred in the post-Invariant-6 deployment period, contrasting with a pre-deployment case study where a "phantom failure" led to a realized double-spend of 400 USDT.

Significance and Claims

The paper claims that execution fidelity is a tractable safety property for autonomous agents acting on irreversible state, even when intent mapping remains unsolved. By formalizing the state space and deriving invariants from first principles, the system ensures that if an agent acts, it acts exactly as previewed, exactly once.

The significance lies in:

Reducing Unbounded Risk: Converting the infinite problem of "did the agent understand?" into a finite, checkable comparison of a four-coordinate tuple.
Practical Deployment: Demonstrating that these formal guarantees can be implemented in a real-world, multi-chain wallet system handling production funds.
Evaluation Rigor: Highlighting that safety layers cannot be evaluated in isolation from the underlying LLM's behavior, advocating for the backing model as a first-class experimental variable.

The paper explicitly acknowledges limitations: the guarantee stops at the "unattended case" (where scope checks replace human confirmation), duplicate suppression is time-bounded ( $\Delta$ ), and the system does not provide atomicity for multi-step plans (only prefix consistency). It does not claim to solve MEV, smart contract bugs, or key compromise, focusing strictly on the agent-orchestration surface.