PACE: Policy-Attested Contract Execution for Safe AI Agents in Decentralized Finance

Abstract: 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 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.

• The paper introduces PACE, a system that combines typed transaction intents, deterministic policy verification, signed decision records, and on-chain calldata binding to make execution safety independent of LLM reliability.
• PACE achieved 100% correct decisions, 0.00 unsafe executions, and 0 false positives across 2,800 benchmark trials, while adding roughly 29,826–31,822 gas per transaction for attestation checks.
• The paper shows that PACE blocks adaptive evasion and transaction tampering but cannot prevent policy-valid economic harm, making policy design, multi-step analysis, and realistic DeFi testing essential for deployment.

PACE (Policy-Attested Contract Execution) addresses a specific gap in the safety of LLM-based agents operating in decentralized finance: existing defenses either operate probabilistically at the model level or validate transactions without cryptographically binding their verdict to the bytes that actually execute. The paper's central claim is that agent safety can be decoupled from model trustworthiness by making every action an explicit, typed object, checking it with a deterministic verifier that never consults the LLM, and re-checking a signed attestation on-chain at execution time. Safety then becomes a property of the policy and verifier rather than of the model.

Motivation and threat model

LLM-based DeFi agents inherit prompt injection susceptibility—both direct and indirect—and translate it into irreversible financial harm: hijacked agents can drain wallets, grant unlimited ERC-20 approvals ($2^{256}-1$), or submit swaps with unbounded slippage. The paper surveys why each existing safeguard is insufficient: alignment and structured-query defenses are probabilistic; simulation previews are not bound to broadcast calldata; smart-account guards ingest no attested off-chain simulation.

The adversary model allows context injection through metadata, chat history, or external feeds; directing the agent to malicious contracts; MEV front-running; post-simulation calldata mutation; and replay of stale simulations. Trusted components are limited to the user policy, the verifier, and the simulator. The stated invariant is that the verifier never queries the LLM. The framework targets soundness only—any executed transaction provably satisfies the declared policy—with no completeness guarantee over harmful-but-policy-valid behavior. Compromise of the owner key, verifier signing key, or the policy itself is out of scope.

Architecture

PACE interposes three layers between the LLM and on-chain submission:

1. Typed transaction intents capture chain ID, sender/target addresses, ETH value, function selector, calldata, token approvals, slippage tolerance, and metadata, with canonical JSON serialization and SHA-256 hashing for content addressing.
2. A deterministic policy verifier evaluates the intent against a declarative UserPolicy: address allowlists, value caps, approval controls, slippage bounds, selector blocklists (e.g., flashLoan, delegateCall), mandatory simulation freshness, touched-contract allowlists, post-state health-factor and loss thresholds, and metadata regexes. It is a pure, stateless function.
3. Signed Policy Decision Records (PDRs) bind intent hash, policy hash, simulation report, calldata hash, nonce, and validity window. PDRs are signed only on approval, so a valid signature attests approval. A Solidity PaceSmartAccount recovers the ECDSA signature over a keccak256 digest of 12 fields and performs nine checks—including keccak256 calldata-hash binding and nonce consumption before any external call (checks-effects-interactions ordering)—before executing.

The paper is explicit about what the PDR does not bind: it guarantees byte- and field-level fidelity, not outcome fidelity. A transaction approved at state $S$ may execute at $S'$ with different reserves or upgraded targets, since no on-chain simulation replay occurs. It also concedes a key assumption regarding field provenance: soundness requires that checked semantic fields reflect the executing bytes, which in production demands reconstructing fields from decoded calldata and traces via trusted code rather than trusting LLM-supplied values. Context-sensitive contracts could also touch different addresses at inclusion than during simulation, so touched-contract checks hold only if relevant execution state is unchanged.

Evaluation

The deterministic benchmark spans 40 tasks across five categories (benign utility plus four attack families: prompt injection, unsafe contracts, DeFi exploit patterns, MEV/slippage; 8 tasks each), run across 7 agents and 10 seeds for 2,800 trials using a regex-based mock LLM and an in-memory DeFi simulator.

Agent	Correct rate	Unsafe exec. rate	Attack success	FP rate
Raw	—	0.8000	1.0000	0
Prompt-Only	~41%	~0.59	~0.73	0
Sim-Only	—	—	—	0
WalletGuard	—	—	—	0
StaticGuard	—	—	—	0
SimGuard	—	0.0312 attack success	0.0312	0
PACE	100.0%	0.0000	0.0000	0

PACE achieves a 0.00 unsafe-execution rate with 0.00 false positives; SimGuard, the strongest baseline, still admits the calldata-mutation task because it lacks the intent-hash equality check. A worked example makes the mechanism concrete: when submitted bytes differ from simulated bytes, SimGuard's simulation report hash no longer matches, but it never checks this, while PACE rejects both off-chain (via intent_hash) and on-chain (via keccak256 data binding). The authors correctly caution that PACE's zero seed-level variance is a deterministic consequence of pure-function verification, not a statistical estimate, and should not be read as a guarantee against adaptive adversaries.

Ablation

Across 320 trials, removing the policy's restrictiveness raises unsafe execution by +57.5 pp (permissive policy yields 0.575), removing the touched-contract allowlist adds +12.5 pp, skipping simulation +5.0 pp, and removing calldata binding or freshness enforcement +2.5 pp each. Sensitivity analysis shows accuracy peaks at a 100 bps slippage threshold, dropping to 95% at both 10 bps (over-rejection) and 1,000 bps (MEV admitted); a zero-second freshness window drops accuracy to 80%. These parameters trade false positives against admitted attacks, underscoring that safety rests substantially on deployer-chosen policy values.

Overhead, live models, and adaptive adversaries

Measured with Foundry (Solidity 0.8.24), PDR verification costs 29,826–31,822 gas per transaction, dominated by nonce SSTORE (~20,000) and ecrecover (~3,000)—a material relative cost (91.7% overhead for an approval, 78.9% for a transfer, 50.5% for a swap). Verifier decision latency is ~0.04 ms, though this excludes trace-based simulation and archive-RPC access that would dominate production latency. All 11 Foundry smart-account test cases pass, covering valid executions and rejection of calldata mutation, target mutation, replay, expiry, and wrong verifier/account/chain-ID.

An auxiliary live evaluation runs three LLMs (gpt-4o, DeepSeek-V4-Flash, gemini-3.1-flash-lite) through the same verifier over the full suite. Unguarded, gpt-4o judged 6.9% of attack trials safe and DeepSeek-V4-Flash 2.6%; the deterministic verifier rejected all of them, yielding 0.000 guarded attack success across all three models. Benign false positives were non-zero (5.0–12.8%) from parser and model variance—a deployment tuning concern. A mainnet-fork harness against real Uniswap V2 bytecode is provided, but fork results are conditionally reported only when artifacts are generated, so no fork claims are made.

The adaptive-adversary study delineates the framework's boundary sharply. Against eight evasion attacks by a policy-aware adversary (boundary-value manipulation, typo-squatting, hidden delegatecall, disguised unlimited approval), PACE blocks 8/8; the disguised approval is caught by exact-approval matching rather than the metadata regex, which proves non-load-bearing. But against eight policy-valid-but-harmful transactions—a swap exactly at the slippage bound, transfers at the value cap, large finite approvals to allowlisted spenders, and a five-leg multi-transaction drain with sub-cap legs—every guard including PACE admits all 8/8. This is by design: PACE enforces the declared policy one transaction at a time, not economic safety.

Limitations and open questions

The evaluation uses a simplified in-memory simulator and a mock LLM for the headline results; the authors explicitly state these demonstrate logic-level safety within a reproducible benchmark, not deployment-ready DeFi security. Tasks are constructed around the policy's modeled properties, so the suite validates verifier logic rather than robustness to unmodeled DeFi behavior such as fuzzed calldata, real ABIs, upgradeable proxies, and exotic token standards. Multi-step agent loops composing policy-valid legs into harmful sequences, adaptive attackers learning over many rounds, cross-contract reentrancy, governance, and bridge exploits remain unaddressed. Integration as an ERC-4337 validator/hook module, EIP-712 typed-data hashing for PDRs, and tooling for policy authoring—the empirically dominant safety factor—are left as future work.

Conclusion

PACE contributes a concrete instantiation of transaction-level policy attestation: typed intents, a deterministic verifier, signed PDRs, and on-chain enforcement, evaluated on a reproducible benchmark where it eliminates all unsafe executions without benign false positives at modest gas cost. Its most instructive empirical finding may be the adaptive study's negative result—that a fully compliant transaction sequence can still be economically harmful—which cleanly separates what cryptographic binding can deliver from what policy authorship must supply.