Imagine asking an automated assistant to earn a little yield on your stablecoins. The request sounds simple. Behind it may sit a chain of swaps, token approvals and deposits—each one a real transaction that can move money permanently. If the assistant reads a malicious instruction hidden in a token description, or sends the wrong transaction after a safety check, a sensible-sounding request can end somewhere the user never intended.
That gap between what an AI agent proposes and what a blockchain executes is the problem behind PACE, a system described by researchers from the University of Houston, PayPal and Kent State University. Instead of trying to make the language model clever enough to catch every trick, PACE treats the model as untrusted. Its central idea is to put a separate, deterministic gate between the agent’s plan and the moment a smart contract acts.
The distinction matters because a blockchain does not execute an explanation. It executes transaction data: the target address, the function being called and the encoded instructions, often called calldata. A model might describe a harmless swap while assembling a transaction that grants a contract permission to spend far more than intended. And even if a transaction looks safe during a simulation, the submitted version could be altered afterward.
PACE tackles that problem in three stages. First, the agent’s proposed action is converted into a structured transaction intent. It records details such as the target, token approvals, spending limits and slippage tolerance. Second, a policy verifier checks those details against rules set by the user—for example, which contracts and tokens are allowed, how much can be spent, and whether unlimited approvals or excessive slippage are forbidden. The verifier is a fixed program: it does not ask the language model whether the transaction is safe.
Third comes the paper’s key piece of glue: a signed Policy Decision Record, or PDR. The record binds the approved intent and policy to a simulation report and to a hash of the exact transaction data. Before execution, a smart account checks that signature, the account and target, the transaction data, a one-use nonce and the record’s validity window. If the submitted bytes differ from the approved bytes, the account rejects the call.
Think of it as attaching a tamper-evident seal to a safety decision. A simulation alone can say, “This transaction looked acceptable.” PACE tries to make the stronger statement: “This exact transaction, under this policy and this simulation, was approved—and the onchain account will check that it is still the same one.” That matters because the researchers found that a baseline using policy checks and fresh simulations still let through a test in which calldata changed after simulation. Binding approval to the transaction data caught that mismatch.
The researchers evaluated PACE in a deliberately bounded setting, not by handing it real funds. Their benchmark contained 40 tasks: benign actions and attacks involving prompt injection, unsafe contracts, DeFi exploit patterns, and slippage or front-running. Across 10 seeded versions of the tasks and seven agent configurations, the team ran 2,800 trials in an in-memory simulator. PACE recorded a 0.00 unsafe execution rate and a 0.00 false-positive rate in that benchmark. The unguarded baseline had a 0.80 unsafe execution rate.
Those figures are promising, but they describe performance on tasks designed around the system’s modeled checks—not a statistical guarantee against every attack. The distinction is important. A deterministic checker can reliably enforce a rule, but it cannot rescue a bad rule. In an ablation test, making the policy permissive raised the unsafe execution rate by 57.5 percentage points. Removing the allowlist for contracts touched during simulation raised it by 12.5 percentage points. The rules, and the machinery that checks them, carry much of the safety burden.
The team also sent three language models through the same policy verifier on a separate set of tests. In that evaluation, guarded attack success was 0.000 for all three. But the benign false-positive rate ranged from 5.0% to 12.8%, and this was still not a test of live blockchain transactions. The paper’s local smart-account tests checked valid and invalid records, including altered transaction data, replayed records and expired approvals. The authors report that their mainnet-fork harness did not produce results unless connected to an archive node; they make no live-chain result claim.
There is another boundary to the protection. PACE checks whether an action follows the declared policy; it does not promise that a policy-compliant action is wise. In a separate adaptive test, it blocked all eight tested attempts to evade policy limits. Yet it also admitted all eight transactions deliberately designed to be harmful while still staying within those limits. A swap at the maximum allowed slippage, for example, may obey the rule and still be a poor deal. The system also checks transactions one at a time, so a series of individually permitted actions could add up to an unwanted outcome.
Nor does the signed record freeze the market. It binds approval to transaction bytes, not to the financial result. Prices, pool reserves or contract behavior can change between simulation and execution. The researchers also note that a real deployment must reconstruct checked details—such as approvals and spending—from trusted decoding of the transaction data, rather than simply trusting fields supplied by the agent. PACE’s reference simulator is an in-memory model; production use would require a more capable simulation backend and careful integration.
That caution shows up in the cost, too. Onchain verification added 29,826–31,822 gas per transaction in the researchers’ tests. The reported verifier-only decision latency was about 0.04 ms, but it excluded simulation, decoding and network access, which can dominate the full process.
PACE’s larger contribution is a change in where trust sits. Rather than betting that an AI agent will always interpret instructions correctly, it places the final decision in an auditable policy and asks the smart account to enforce that decision at the point of execution. The approach does not make a financial agent invulnerable, and it leaves hard questions about policy design and changing market conditions. But it offers a concrete answer to a narrower question: even when a model proposes the action, can the system make sure that only the action actually approved is the one that reaches the chain?
