Source-linked AI summary
PACE: Policy-Attested Contract Execution for Safe AI Agents in Decentralized Finance
Rabimba Karanjai, Yang Lu, Richard Williamson, Hemanth Hm, Prakhar Mehrotra, Lei Xu, Weidong, Shi
TL;DR
LLM-based DeFi agents can be subverted by prompt injection, while verifier approval may not bind to the exact transaction submitted on-chain. PACE enforces transaction-level policy attestations and achieves 0.00 unsafe execution and false-positive rates in its deterministic benchmark.
Problem
LLM-based DeFi agents inherit prompt-injection vulnerabilities, creating a gap in reliably controlling the irreversible transactions they propose.
Method
PACE uses typed intents, deterministic policy verification, and signed Policy Decision Records that bind approved transaction details to execution bytes and are re-checked on-chain.
Results
PACE achieves a 0.00 unsafe execution rate and 0.00 false-positive rate in deterministic sandbox experiments across its benchmark.
Takeaways & Limitations
PACE indicates that on-chain agent safety can be decoupled from model trustworthiness through signed policy enforcement across model outputs and execution.
Takeaways & Limitations
PACE binds execution bytes and policy decisions, but does not guarantee that the realised outcome matches a simulation performed at an earlier blockchain state.
Abstract
from arXiv · showhide
Autonomous AI agents are emerging as interfaces for decentralized finance (DeFi) actions such as swaps, lending operations, and yield management. Because these agents rely on large language models (LLMs) to plan transactions, they inherit the LLM's susceptibility to prompt injection and lack of mechanisms to bind a verifier's approval to the exact transaction ultimately submitted on-chain. We present PACE (Policy-Attested Contract Execution), a transaction-level authorization framework that interposes between an LLM-based agent and on-chain execution. PACE introduces typed transaction intents, a deterministic policy verifier, and signed Policy Decision Records (PDRs) that cryptographically bind the approved intent, policy, and simulation report to the exact execution bytes, with replay and expiration protection. A Solidity smart account enforces PDR signatures on-chain with a measured overhead of 29,826-31,822 gas. We evaluate PACE against six baselines on 40 tasks spanning four attack categories plus benign utility (2,800 trials, 10 seeds). In our deterministic sandbox, PACE achieves a 0.00 unsafe execution rate and 0.00 false-positive rate on benign tasks, compared to 0.80 for the unguarded baseline. Ablation studies identify permissive policy settings (+57.5 pp) and the touched-contract allowlist (+12.5 pp) as the dominant safety components. To test whether the same deterministic floor holds for real model outputs, the artifact additionally provides a three-model live-LLM evaluation over the full task suite with repeated runs. A mainnet-fork harness is included for archive-RPC deployments, but fork results are reported only when the corresponding artifacts are generated. These auxiliary studies are separate from, and never substitute for, the deterministic benchmark. We frame our claims as logic-level safety within a reproducible benchmark rather than deployment-ready DeFi security.
1. Introduction
LLM-based DeFi agents lower the barrier to on-chain finance but import prompt-injection and irreversible-transaction risks. PACE addresses this by making safety depend on deterministic verification and cryptographic execution binding, while evaluating logic-level safety in a simplified benchmark.
- Motivation: LLM-based agents accept natural-language goals, plan multi-step DeFi strategies, and emit transactions, bringing autonomous financial activity onto public blockchains.DeFi protocols hold tens of billions of dollars in user funds, and such agents have begun operating on-chain under real capital.
- Threat model: Prompt injection can cause agents to approve attacker transactions because LLMs cannot reliably distinguish trusted instructions from untrusted data.Adversarial content may appear in token names, price feeds, memo fields, or other tool outputs, making mistakes potentially irreversible.
- Limitations of existing safeguards: Existing safeguards are probabilistic, can be evaded, or fail to bind simulation results and off-chain authorization to the exact transaction bytes broadcast.Model defenses reduce unsafe proposals without guaranteeing the submitted transaction; simulation and wallet guards address different parts of the execution chain.
- PACE approach: PACE makes safety independent of model trustworthiness by reducing actions to typed objects, applying deterministic model-independent checks, and re-verifying cryptographically bound decisions at execution.The stated safety property is that even a fully compromised LLM cannot cause a policy-violating transaction to settle.
- Evaluation and scope: 2,800 deterministic-sandbox trials show 0.00 unsafe execution rate and 0.00 false positives, while ablations identify permissive policy settings (+57.5 pp) and the touched-contract allowlist (+12.5 pp) as dominant components.The evaluation spans 40 tasks, four attack categories plus benign utility, and six non-PACE baselines; results are scoped to logic-level safety in a simplified simulator with a regex-based mock LLM.
2. Background
This section introduces DeFi’s smart-contract primitives and the transaction risks faced by autonomous LLM-based agents. It motivates external, execution-time guardrails for agents that can autonomously construct irreversible DeFi transactions.
- DeFi primitives: DeFi protocols provide permissionless financial services through Ethereum smart contracts, with assets represented as ERC-20 tokens.This establishes the on-chain substrate for the paper’s transaction-level authorization problem.
- DeFi primitives: AMM token swaps use the constant-product invariant x ⋅y = k, with output ∆y = Ry ⋅∆x ⋅(1−f) / (Rx + ∆x ⋅(1−f)).Price impact grows super-linearly with trade size relative to pool reserves.
- DeFi primitives: Aave-style lending positions use health factor h = C ⋅p ⋅t / D to determine liquidation risk.The variables represent collateral, oracle price, liquidation threshold, and outstanding debt, respectively.
- DeFi risks: ERC-20 approve(spender, amount) grants transfer permission, while unlimited approvals amount = 2256−1 can let compromised spenders drain a full token balance later.Approval-based exploits are identified as a recurring DeFi attack pattern.
- Agentic DeFi: LLM-based agents translate natural-language goals into autonomous DeFi calldata, including swaps, approvals, and deposits.They can plan multi-step strategies and submit the resulting transactions through tools.
- Agentic DeFi: Prompt injection can override an agent’s intended behavior, enabling fund redirection, unlimited approvals, or unbounded slippage with irreversible on-chain losses.This motivates a guardrail external to the model and binding at execution.
3. Threat Model
PACE models an LLM-based DeFi agent as operating under adversarial inputs, while deterministic verification and on-chain PDR checks constrain execution to the user’s declared policy. The threat model excludes compromise of trusted policies, verification logic, signing keys, and owner credentials, and makes no completeness claim.
- Agent and system boundary: The agent receives a natural-language goal, plans transactions, and submits them, while PACE interposes before on-chain execution.PACE separates the agent’s output from on-chain submission.
- Adversary capabilities: Adversaries may inject context, target malicious contracts, front-run transactions, mutate calldata, or replay stale simulations to cause theft, loss, policy bypass, or tampering.The listed goals include unauthorized transfers or approvals, slippage, sandwich attacks, and oracle manipulation.
- Out-of-scope compromises: The adversary cannot modify the user policy, verifier, or smart-account validation logic, and owner-key, verifier-signing-key, and policy compromise are out of scope.The agent has only PDR-gated authority and lacks the owner key and owner-only raw-execution path.
- Trust assumptions: Trusted components are the user policy, policy verifier, and deterministic auditable simulator, whereas the LLM/agent, its intent, and external contracts are untrusted.The user policy is set by the user or administrator.
- Security invariant: The verifier never queries the LLM; it deterministically compares transactions against the user’s policy, targeting soundness regardless of LLM behavior.PACE makes no completeness claim: the user remains responsible for whether the policy captures every unsafe outcome.
- Benchmark scope: The benchmark covers four attack categories—prompt injection, unsafe contracts, DeFi exploit patterns, and MEV/slippage—plus benign utility, with 8 tasks each.Section 6 provides the task details.
4. Pace Design
PACE inserts deterministic verification between an LLM agent and on-chain execution: typed intents are simulated, checked against a user policy, sealed in signed Policy Decision Records, and re-checked by a smart account. Its guarantees bind approved fields and execution bytes, but depend on trusted field provenance and do not ensure simulated outcomes occur on-chain.
- Verification pipeline: PACE interposes a deterministic pipeline that converts LLM output into a typed intent, simulates it, verifies it against policy, and gates external calls with a signed PDR.The smart account re-checks the approved decision on-chain before execution.
- UserPolicy: A UserPolicy specifies allowlists, value and approval limits, slippage bounds, blocked functions, simulation requirements, post-state thresholds, and metadata regexes.Policies are versioned using SHA-256 hashes.
- Deterministic verifier: The pure stateless verifier approves only violation-free intents, checking policy constraints plus simulation success, freshness, touched contracts, health factor, loss, and intent-hash equality.It neither accesses the network nor consults the LLM, so an attack must evade every applicable check.
- Policy Decision Record: The PDR binds the full intent, policy, simulation, decision, hashes, timestamp, and exact execution bytes, with replay and expiry protection.Only approved decisions are signed; rejected records remain off-chain for audit.
- Guarantees and limits: PACE guarantees byte- and field-level fidelity to the verifier’s decision, not equality between simulated and realized outcomes at a later blockchain state.The contract does not replay simulation on-chain, so reserves, prices, or targets may differ at execution.
- Field provenance: Soundness requires trusted reconstruction of semantic fields from decoded calldata and simulation traces because calldata-hash equality alone does not prove that typed fields match executing bytes.The reference implementation uses typed intents and simulator traces; its backend is pluggable, with production deployments expected to use archive-node trace simulation.
5. Implementation
PACE is implemented as a reproducible transaction-processing system with deterministic simulation, layered agent guards, and on-chain PDR enforcement. Its smart-account path cryptographically binds verified decisions to execution while preventing replay and supporting comprehensive tests.
- Simulation: The deterministic simulator covers ERC-20 tokens, a constant-product AMM, lending health factors, malicious hidden-contract calls, and approval draining.The AMM uses x⋅y=k with a 30 bps fee; the lending pool uses oracle-based health factor calculations.
- Simulation: The MEV module finds profit-maximising constant-product sandwich front-runs and reports victim loss, attacker profit, and strict-slippage blocking.Inputs include pool reserves, victim trade, slippage, fee, and attacker budget; optimization uses iterative refinement.
- Agent implementations: Seven agents span Raw execution, prompt-only and simulation-only guards, wallet and static guards, SimGuard, and full PACE enforcement.PACE combines simulation, full policy verification, and PDR protection; SimGuard lacks PDR/calldata binding.
- Evaluation interfaces: Deterministic experiments use regex-based mock-LLM responses, while live responses are logged and still pass through the same policy verifier.The mock LLM returns canned safe or unsafe responses without API keys; compatible live endpoints include self-hosted models.
- Testing: 21 Foundry tests cover smart-account enforcement, 6 gas-overhead cases, and 4 fork-harness cases, including mutation, replay, expiry, identity, and chain checks.The enforcement suite includes valid ERC-20, approval, and AMM executions plus owner-only raw execution.
6. Evaluation
The evaluation uses a reproducible deterministic benchmark to test PACE’s safety, utility, baseline comparisons, component contributions, and overhead. Separate live-LLM and fork studies address external-validity concerns, while sandbox results are framed as logic-level evidence rather than deployment security.
- Benchmark design: 40 benchmark tasks span five categories, including benign utility and four attack classes expected to be rejected.Each task specifies a TransactionIntent, UserPolicy, expected decision, attack label, and severity.
- Benchmark design: Tasks are deterministically generated across seeds while varying wording, attacker budgets, reserves, slippage, injections, targets, and simulation age.Specialized simulators exercise stale-simulation and calldata-mutation attacks.
- Metrics: Evaluation distinguishes unsafe execution, attack success, dangerous blocking, false positives, correctness, completion, and overhead metrics by explicit denominators.Task completion measures recorded results only and is not a correctness metric; generic execution or blocked rates use all trials unless otherwise specified.
- Experimental protocol: 2,800 trials use 10 seeds, 7 agents, and 40 tasks per seed in deterministic full mode without live LLM API calls.Seed-level means and standard deviations are reported, with seeds treated as deterministic task variants rather than live-deployment draws.
- Limitations: The in-memory sandbox demonstrates logic-level safety properties but does not establish efficacy against adaptive adversaries or unmodelled live-chain DeFi behavior.The suite validates modeled verifier decision logic rather than robustness to fuzzed calldata, real ABIs, upgradeable proxies, or exotic token standards.
- External validity: Auxiliary studies use three live LLMs and a mainnet-fork harness to probe external validity, with fork results reported only when generated.The live evaluation uses the same PolicyVerifier and full 40-task suite, while both studies are reported separately from the deterministic benchmark.
7. Results
PACE achieves perfect deterministic benchmark safety and utility, while its dominant protections are policy strictness and touched-contract allowlisting. Live-LLM results preserve zero guarded attack success, but introduce benign false positives, and adaptive tests clarify that PACE enforces policy soundness rather than economic safety.
- Deterministic benchmark: 0.0312 attack success rate: SimGuard is the strongest non-PACE baseline but admits the calldata-mutation task because it lacks PDR calldata binding.PACE rejects mismatches by comparing the approved intent_hash with the submitted intent, binding simulation to execution bytes.
- Ablation: +57.5 pp unsafe execution rate: an explicitly permissive policy is the largest ablation failure, followed by +12.5 pp from removing the touched-contract allowlist.Skipping simulation adds +5.0 pp; the ablation contains 320 trials across 8 PACE variants.
- Execution overhead: 29,826–31,822 gas per transaction: PDR verification is dominated by ecrecover and nonce SSTORE, with relative costs of 91.7% for approvals, 78.9% for transfers, and 50.5% for swaps.The ∼0.04 ms figure covers verifier-only decision latency and excludes simulation, ABI decoding, and archive-RPC access.
- Live-LLM evaluation: 0.000 Pace-guarded attack-success rate: all three evaluated live LLMs reach this floor across the full 40-task suite, while benign false positives range from 5.0–12.8%.The live evaluation comprises 595 trials and is reported separately from the deterministic benchmark; model and parser variance causes the benign false positives.
- Robustness and scope: 8/8 policy-valid-but-harmful transactions: PACE and every baseline admit them, because PACE enforces declared policy and verifies one transaction at a time rather than economic safety.Against policy-violating adaptive attacks, PACE blocks 32/32 per seed, while SimGuard and StaticGuard block 7/8 and WalletGuard blocks 2/8.
8. Discussion
PACE’s discussion concludes that policy and simulation layers are complementary, with safety driven primarily by policy quality and defaults. The benchmark is synthetic and defensive, so it supports evaluating safeguards before real-capital deployment rather than claiming protection for deployed protocols.
- Layer Complementarity: A permissive policy raises unsafe execution by 57.5 pp, making policy specification and well-designed defaults the dominant safety factor.Policy-only misses simulation-dependent attacks, while simulation-only catches only reverts; PACE therefore combines both layers.
- Limitations: All attacks use an in-memory simulator and local test contracts with no real funds at stake.The benchmark reuses documented attack categories and contains synthetic scenarios rather than newly disclosed deployed-protocol vulnerabilities.
- Motivation: The artifact’s primary role is helping defenders evaluate agent-level safeguards before agents manage real capital.This motivation follows from the benchmark’s defensive, synthetic design and does not establish deployment-ready DeFi security.
9. Related Work
PACE complements existing contract-analysis, DeFi-attack detection, account-guard, and model-safety approaches by enforcing transaction policies before submission. It most closely extends Transaction Intent Schema and Policy Decision Record abstractions into a concrete, evaluated, on-chain-enforced system with simulation binding.
- Smart-contract analysis: PACE verifies proposed transactions against user policy before contract execution, complementing static and symbolic contract-analysis tools.A correct contract can still be dangerous under incorrect parameters, such as unlimited approval to a phished spender.
- DeFi attacks and MEV: PACE acts pre-submission by enforcing slippage, value, and simulation-based post-state checks before transactions enter the mempool.This differs from literature focused on detecting and measuring sandwich attacks, MEV, front-running, and other DeFi attacks.
- Account abstraction and modular guards: Existing smart-account guards and modular-account standards enforce allowlists, spending caps, scoped permissions, and execution hooks, while PACE validates agent transactions against policy.The cited ecosystem includes ERC-4337, Safe guards and modules, Zodiac Roles, ERC-6900, and ERC-7579.
- LLM safety and prompt injection: RLHF, Constitutional AI, and input-level defenses address harmful model behavior and prompt injection, but these approaches remain probabilistic compared with PACE’s external verifier.The cited prompt-injection literature includes both direct and indirect attacks.
- Tool-using and on-chain agents: Agent benchmarks measure susceptibility but do not prevent unsafe execution; PACE provides a concrete, evaluated, on-chain-enforced instantiation of Transaction Intent Schema and Policy Decision Record abstractions.Alqithami’s roadmap is identified as the closest framing, while PACE adds simulation binding.
10. Future Work
PACE’s path toward deployment-grade assurance centers on testing adaptive attackers, harmful multi-step compositions, and higher-fidelity execution against forked mainnet state. Broadening attack coverage remains another future direction.
- Deployment-grade assurance: Adaptive attackers that learn against the verifier over many rounds remain an important open target.The paper identifies this as a next step toward deployment-grade assurance.
- Deployment-grade assurance: Multi-step agent loops that compose policy-valid legs into a harmful sequence remain an important open target.The paper highlights sequential composition as a limitation not addressed by single-step policy validity.
- Deployment-grade assurance: Higher-fidelity execution should run the full attack suite under trace-based simulation against forked mainnet state.This is proposed as a future evaluation direction.
- Deployment-grade assurance: Broadening attack coverage to cross-contract reenactments is identified as another future direction.The supplied passage begins this direction with “cross-contract reen…”, but its remaining wording is truncated.
11. Conclusion
PACE separates untrusted LLM planning from deterministic, attestable safety enforcement for DeFi agents. Its transaction-level policy attestation decouples on-chain safety from model trustworthiness by enforcing signed decisions off- and on-chain.
- PACE separates untrusted LLM planning from deterministic, attestable safety enforcement for AI agents acting in decentralized finance.
- PACE’s three-part primitive comprises typed transaction intents, a deterministic policy verifier, and signed Policy Decision Records re-checked on-chain by a smart account.The records bind intent, policy, and simulation to the decision before execution.
- PACE decouples on-chain action safety from model trustworthiness by treating the model’s entire output as untrusted and enforcing signed policy decisions off- and on-chain.The framework is intended as a building block for autonomous agents operating under transaction-level policy attestation.