Proof-Gated Signing: Solver-Checked Transaction Guards that Hold Under State Drift for Onchain AI Agents

arXiv:2610.00354 · cs.CR, cs.AI, cs.CE · Submitted 2026-09-30 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: I'm Nadia, and with me are Elias and Priya, guest researcher.

Elias: Today's paper: "Proof-Gated Signing: Solver-Checked Transaction Guards that Hold Under State Drift for Onchain AI Agents".

Nadia: AI agents controlling wallets face risks from content they read, leading to harmful transactions, and this research introduces Proof-Gated Signing (PGS),

Elias: First, who's behind it and why it matters.

Title and authors: Nadia: We've been discussing how the paper "Proof-Gated Signing: Solver-Checked Transaction Guards that Hold Under State Drift for Onchain AI Agents" tackles state drift, which is a real challenge when agents are interacting with evolving on-chain environments. The authors are Bravish Ghosh and he's an independent researcher who brings a strong background in formal methods.

Elias: I think it’s important to look at the authors because their focus on formal methods suggests they aren't just proposing another heuristic defense; they are building something rooted in mathematical certainty about the system's behavior.

Priya: As someone interested in measurement, I wonder if their background as an independent researcher influences how they frame what constitutes a successful simulation of that transaction and its resulting effects?

Nadia: They define the threat model clearly, outlining how an adversary can inject content into anything the AI reads or act on-chain between the check and execution. This sets the stage for why a standard pre-signing check is structurally insufficient.

Elias: That structural blind spot they identify, where a check is only evidence about the chain state at that moment, but execution happens later in a potentially influenced state, that’s the problem they are trying to solve.

Priya: So if we look at their approach—simulating an effect vector and then using SMT solving—does their methodology inherently assume a certain level of control over the agent's proposed transaction structure?

Nadia: They assume the agent proposes a call batch, and the guard sits between that agent and the signing key, deciding whether to refuse or sign with post-conditions.

Elias: The assumption is that we can define a declarative value-and-permission policy for every price in an oracle uncertainty band, which is the input to the solver. That level of mathematical definition is what makes it possible to check against drift.

Priya: From a privacy perspective, I’m interested in how they ensure that the simulation itself doesn't inadvertently leak information about the agent's intended transaction structure before the proof is complete.

Nadia: The focus seems to be on isolating the policy check; they are compiling post-conditions after proving adherence to those bounds, ensuring only what is provably safe gets compiled onto the smart contract.

Elias: That compilation of assumptions into on-chain post-conditions is what bridges the gap between the off-chain proof and the on-chain execution environment, which I think is their main contribution here.

Priya: So, to wrap up this section, they are using formal verification tools to establish a mathematical guarantee that an agent's actions will meet its policy requirements even when the underlying chain state changes between signing and execution.

Nadia: That’s the core idea of Proof-Gated Signing: Solver-Checked Transaction Guards that Hold Under State Drift for Onchain AI Agents. This is a serious step toward making AI agents more trustworthy in financial applications.

Elias: It’s about moving beyond simple checks to formal proofs that account for the fluidity of the blockchain state.

Priya: It’s interesting to see this intersection of cryptography, formal methods, and agent security being explored so deeply in this paper.

The paper's summary: Nadia: Moving on from the setup, let's summarize what the actual mechanism of Proof-Gated Signing involves for listeners who want the technical rundown. Essentially, they simulate a transaction to get its effect vector and then feed that into an SMT solver.

Elias: The solver then checks if a solution exists for the negated policy across every price point within an oracle uncertainty band; if it finds one, they issue a refusal based on that counterexample.

Priya: That sounds like it’s checking for violations of the value and permission policies simultaneously under various potential market conditions, which is much more rigorous than just checking a single static balance.

Nadia: Exactly; they are verifying that every price point in that band respects the policy, and if a counterexample is found, they return a refusal reason based on what went wrong.

Elias: If the solver doesn't find any such counterexample, then they proceed to compile on-chain post-conditions that cover things like wallet balance bounds and allowance caps.

Priya: And crucially, they prove that every execution satisfying those derived post-conditions must also satisfy the original policy—that’s where Theorem one comes in.

Nadia: That theorem establishes soundness: whatever happens on-chain between the check and inclusion, a transaction that executes respects those proven bounds, covering balances, payee receipts, and ownership integrity.

Elias: It means the guard isn't just blocking bad transactions based on old data; it’s proving that the resulting execution will be safe regardless of how the chain evolves afterward.

Priya: So, to put it plainly, they are using a powerful tool to translate a high-level policy into concrete, executable rules that govern transaction behavior under uncertainty.

Nadia: That's right; it’s about translating abstract financial intent into verifiable on-chain constraints using the power of SMT solving.

Elias: It’s a way to close the gap between what we *think* will happen and what actually *will* happen when the transaction lands on the ledger.

Priya: I think it’s a very concrete summary because it moves past theoretical risk and shows exactly how they translate uncertainty into verifiable execution constraints.

The paper's improvements: Nadia: Now let's talk about what the authors suggest as improvements to the Proof-Gated Signing framework itself, because that’s where the real practical enhancements lie for implementing this kind of security. They focus on moving beyond just a basic guard.

Elias: They propose equipping AI agents with "Proof-Carrying Post-Conditions," meaning instead of just simulating an outcome, the agent generates a formal proof via SMT solving that its intended transaction satisfies the declarative policy.

Priya: That’s a significant step; it means the agent isn't just proposing an action; it’s proactively generating evidence that its proposal is sound according to the wallet's rules, which seems much more proactive than reactive checking.

Nadia: It also suggests using session-based budget controls where cumulative losses across multiple transactions are tracked by a solver, which prevents harmful sequences of trades—we call these "in-policy drains".

Elias: That’s a clever way to handle sequential risk; instead of checking each trade in isolation, you use the solver to manage the budget across the entire session, which addresses risks that static checks miss.

Priya: What I find interesting is their focus on explicit feedback; they suggest providing specific reasons for failure instead of a generic rejection, detailing exactly which part of the policy failed under a specific price scenario.

Nadia: That detailed feedback is crucial because it gives the agent actionable intelligence on how to fix its proposal immediately, rather than just being told "no" and having to guess what went wrong.

Elias: This ties into their trade-off mechanism as well; they allow users to tune parameters like the tolerance factor or session budget so they can balance protection against legitimate, high-impact trades.

Priya: So, these improvements suggest a system that is not only secure but also provides transparency and control over its own risk exposure for the agent operator.

Nadia: It sounds like they are pushing the AI from being misled signers to something more akin to a guaranteed policy enforcer, ensuring its actions are mathematically compliant with the owner's strategy.

Elias: They’re essentially building a system where formal proof is integral to the agent's proposal process, not just an afterthought for auditing.

Priya: It really sounds like they are making the security mechanism as dynamic and adaptive as the AI agents themselves need to be in today's complex financial landscape.

Conclusion: Nadia: So, wrapping up our discussion on this Proof-Gated Signing paper, it’s clear that this work provides a robust defense against state drift by using SMT solvers to check policies across price uncertainty bands and compiling those proofs into on-chain post-conditions.

Elias: Indeed, the concept of using these solver-checked transaction guards to bridge the gap between pre-signing checks and actual execution is a significant contribution because it provides a mathematical guarantee that what happens on-chain respects the defined policy.

Priya: The improvements they suggested, like proof-carrying post-conditions and session budget controls, really demonstrate how this research can evolve into a more comprehensive system for managing agent risk in complex financial scenarios.

Nadia: And the explicit feedback mechanism addresses the liveness aspect by giving agents precise reasons for rejection, which makes the system much more useful in an operational context.

Elias: It’s a big step forward because it moves formal verification from being a static audit tool to being an integral part of the transaction proposal process itself.

Priya: Overall, this paper on Proof-Gated Signing is an important piece for understanding how we can build more trustworthy AI agents that operate securely in decentralized systems.

Nadia: It certainly is, and as we look ahead, the next challenge will be measuring the impact of this defense when it interacts with mainnet traffic and real-world state drift scenarios.

Elias: That’s where I expect future work to focus on replaying historical exploits on a mainnet fork or evaluating this against non-expert attackers.

Priya: I think those empirical tests are necessary to really validate the claims made in the paper under conditions that mimic the real world's unpredictability.

Bravish Ghosh

cs.CR, cs.AI, cs.CE

Submitted: 2026-09-30

Updated: 2026-09-30

Comments: 16 pages, 3 figures, 5 tables. Code and data: https://github.com/LoopGlitch26/Proof-Gated-Signing

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 86/100

The gist: AI agents controlling wallets face risks from content they read, leading to harmful transactions, and this research introduces Proof-Gated Signing (PGS), a novel defense mechanism that closes the gap

Key concepts

State Drift
This occurs when an initial check on a wallet's state is not accurate for the moment a transaction actually executes. An adversary can change things like contract parameters or token values between the check and execution, creating a discrepancy that traditional checks miss.
SMT Solver
A Satisfiability Modulo Theories (SMT) solver is a mathematical tool used to prove whether a set of constraints has any possible solution. In PGS, it is used to mathematically check if any price within an uncertainty band violates the required policy.
Post-Conditions Proof
This involves taking the assumptions made during the transaction check and proving on-chain that every possible execution path will satisfy those initial requirements. This ensures that even with state drift, the resulting transaction remains compliant with safety policies.
Bounded Guard
The guard is designed to limit potential losses strictly within a defined session budget. It doesn't prevent all loss but ensures that any in-policy drains or fees are capped, providing a predictable risk profile for the agent.

Terminology

Summary

AI agents controlling wallets face risks from content they read, leading to harmful transactions, and this research introduces Proof-Gated Signing (PGS), a novel defense mechanism that closes the gap between pre-signing checks and actual transaction execution by using SMT solvers to prove policy adherence under state drift.

The Gist

PGS simulates a proposed transaction, extracts its effects on the wallet, and uses an SMT solver to check a declarative value-and-permission policy for every price in an oracle-uncertainty band. It then compiles on-chain post-conditions and proves that every execution satisfying them also satisfies the policy.

The Threat: State Drift

The usual last line of defense—a pre-signing check like a static allowlist, an LLM reviewer, or a transaction simulation—shares a structural blind spot: it is evidence about the chain state at check time, but the transaction executes in a later state that an adversary can shape through front-running, contract upgrades or token-parameter changes. This gap is termed state drift. PGS treats the pre-signing check as a proof with an explicit scope and closes this gap by compiling the proof’s assumptions into on-chain post-conditions.

The Proof Mechanism

PGS operates through a pipeline involving simulation, SMT solving, and post-execution checks:

  1. The guard simulates the transaction on the current state to extract its effects (the effect vector).

  2. It then uses an SMT solver to check if a solution exists for the negated policy over the price band: if Solve∃p ∈ band: ¬Policy(∆sim, p) = sat then return Refuse(counterexample).

  3. If a counterexample is found, the guard returns a refusal reason. If not, it compiles post-conditions (e.g., wallet balance bounds, payee receipts) and proves that every execution satisfying them also satisfies the policy (Theorem 1).

  4. The agent’s smart contract wallet enforces these derived bounds atomically with the batch; if any bound fails during execution, it reverts.

Key Guarantees and Soundness

Theorem 1 establishes the soundness of this approach: whatever happens on-chain between check and inclusion, a transaction that executes respects the proven bounds. This means that for every price vector in the band, the realized balance changes satisfy the value policy; credited payees receive at least their required amount; allowances do not exceed their caps; and owned contracts keep their owner. The guard is designed to be bounded, not prevented, meaning it limits loss within per-transaction policy (fees, in-policy drains) to a session budget.

Evaluation and Trade-offs

The PGS system was evaluated on an open testbed of 260 scripted scenarios: 14 attack families and 12 benign families. On this suite, PGS prevented 131 of 140 harmful scenarios (93.6%, 95% CI 88–97%) and passed 117 of 120 benign ones (97.5%). The system demonstrated that while it bounded in-policy drains within a session budget, untracked assets and off-chain signatures remain uncovered gaps, as noted in Table 1. The median overhead is 41k gas and about 0.1–0.2 s per check.

Comparison to Other Defenses

PGS was compared against simulation-only checking (which missed 57.9% of drift scenarios) and a static allowlist (which missed 40). Furthermore, an LLM judge was shown to be complementary: the judge catches what effects cannot show, such as reasoning about risk like sandwich setup, while PGS guarantees that whatever is signed respects the policy when it executes. The research concludes that PGS provides a guard for the one effectful boundary, the signature, and would compose with any agent-side defense.

Limitations and Future Work

The paper notes limitations, including conservatism regarding untracked assets and off-chain signatures. Future work includes measuring drift on mainnet traffic, replaying historical exploits on a mainnet fork, evaluating against a held-out attack set written by non-experts, and integrating with an ERC-4337 validator to enforce key custody on-chain. The trade-off explicitly shows that widening the policy bounds (increasing 's' or 'β') admits larger trades at the price of letting more in-policy loss through per transaction.

How it works

The guard simulates a proposed transaction on the current state to "

Improvements for AI systems

Here are the specific improvements to AI systems derived from Proof-Gated Signing (PGS), focusing on enhancing security for agents controlling financial assets:

  1. A new layer of transaction signing defense that moves beyond static allowlists, LLM reviewers, or simple simulations by incorporating an SMT solver to prove that a proposed transaction will adhere to complex, whole-wallet value policies under price uncertainty.

  2. The ability for AI agents to propose transactions (e.g., payments, swaps) while simultaneously being protected by a guard that verifies the transaction against derived post-conditions—proving atomicity and adherence to rules like balance bounds, payee receipts, and allowance caps even if the chain state drifts between checking and execution.

  3. AI agents can be equipped with Proof-Carrying Post-Conditions for their proposed actions. Instead of merely simulating an outcome, the agent would generate a formal proof (via SMT solving) that its intended transaction satisfies a declarative policy (e.g., Value sent to EOAs goes only to allowlisted payees within caps).

  4. The system will automatically enforce complex, multi-asset constraints (like net stablecoin exposure ≥ x) and correlated price models, which are currently intractable for simple simulation or allowlists, ensuring that the executed transaction respects the overall wallet policy regardless of market fluctuations within a defined band.

  5. AI agents can operate with session-based budget controls where cumulative losses across multiple transactions are tracked by a solver, preventing in-policy drains (where individual trades are fine but the sequence is harmful) by reverting if the session budget is violated.

  6. The improved system provides explicit feedback on failure modes: instead of a generic rejection, it reports precisely which part of the policy failed (e.g., Rejected because your proposed outflow violates the relative loss bound for asset X under price scenario Y).

  7. The system offers a clear security/liveness trade-off mechanism: users can tune parameters like the tolerance factor (τ) and session budget (Wmax) to balance protection against overly conservative refusals of legitimate, high-impact trades.

These improvements transform AI agents from merely misled signers into guaranteed policy enforcers, ensuring that their actions—even when influenced by external data or adversarial prompting—remain mathematically compliant with the owner's defined financial strategy.

Abstract

AI agents that control wallets read attacker-reachable content, so they can be steered into proposing harmful transactions. The usual last line of defense is a pre-signing check: a static allowlist, an LLM reviewer, or a transaction simulation. All three share a gap: the check describes the chain state at check time, but the transaction executes in a later state that an adversary can shape through front-running, contract upgrades or token-parameter changes. We call this state drift. We present Proof-Gated Signing (PGS), which simulates a proposed transaction, extracts its effects, and uses an SMT solver to check a declarative value-and-permission policy for every price in an oracle-uncertainty band. It then compiles on-chain post-conditions (wallet balance bounds, payee receipts, allowance caps and ownership) and proves that every execution satisfying them also satisfies the policy. The agent's smart-contract wallet enforces them atomically, so the guarantee applies to the executed transaction under arbitrary drift. On an open testbed of 260 scenarios (14 attack families including five drift and two adaptive families, and 12 benign families), with harm measured from attacker balances rather than from any policy, PGS prevented 93.6% of the 140 harmful scenarios and passed 97.5% of the benign ones. Simulation-only checking prevented 57.9% and a static allowlist 71.4%. None of the 50 drift scenarios produced attacker gain under PGS. The only unprevented family, an in-policy drain, was bounded by the per-session budget. We also find that giving an LLM reviewer a clean pre-drift simulation made it more likely to approve a drift attack. Overhead is about 41k gas and 0.1-0.2 s per check.

Sources

Related papers