The problem Verifiable Agent Execution Bundle (VAEB) solves

AI agents today are multiple variants of chatbots. In finance, they can advise on financial decisions, but people are hesitant to let them directly execute money due to lack of security guardrails. VAEB changes that by letting agents spend money on authorizers' behalf without ever touching their private key.

The core problem is simple: if you want an AI agent to pay for a service, execute a swap, or move funds, you either hand over your private key (dangerous), or sign every transaction yourself (defeats the purpose of an agent). VAEB introduces a third option:

an MCP server where the agent calls and submits transactions, but a ZK proof cryptographically guarantees the transaction matches what you approved.

For simple payments (e.g., an agent paying for an API via x402), the counterparty specifies the address and amount, and the user signs an intent bundle with those exact parameters. The ZK proof here acts as a safety net, ensuring the agent can't swap in a different address or inflate the amount between your approval and on-chain execution. The agent handles gas, timing, and submission without ever seeing your key.

This first version focuses on simple payments. When an agent paying for an API via x402, or sending tokens to a recipient, the user signs an intent bundle with the exact parameters, and the agent handles gas, timing, and on-chain submission without ever seeing the private key. The ZK proof acts as a safety net, ensuring the agent can't swap in a different address or inflate the amount between your approval and execution. This alone is a significant leap to enable agents from passive advisors to active economic participants.

The architecture is designed for what comes next. The same ZK proof infrastructure naturally extends to complex DeFi operations (swaps, multi-step strategies) where the agent derives

calldata

from simple intents, and ultimately to intent-as-boundary-conditions, where users sign constraints ("spend up to 500 USDC per day", "only interact with these protocols") and agents make autonomous decisions within those boundaries. The current exact-match mode is the most restrictive version of this architecture, proving the trust layer works before expanding agent autonomy.

Challenges we ran into

1. Deploying across EVM chains with different quirks. Our Groth16 on-chain verifier relies on the

   ecPairing

   precompile (EIP-197) for BN128 pairing checks. Base Sepolia supports this natively, but deploying to Kite AI Testnet is different: gas pricing for the pairing operation, RPC endpoints that don't support

   eth_sendTransaction

   (requiring private-key signing locally), and L2 propagation delays where contracts appeared deployed but had no code. We built a chain-agnostic config system in the SDK and per-chain deployment scripts that auto-update deployments.json, so the MCP server, frontend, and prover all point to the right contracts without manual coordination.

2. Integrating with Canton's completely different ledger model. Canton uses Daml (not EVM) with sub-transaction privacy and RISC0 zkVM proofs, a fundamentally different stack from VAEB's Circom/Groth16 on EVM. The challenge was designing a clean boundary: Canton defines what should happen (settlement terms via

   CrossChainSettlement

   contracts), and VAEB executes how (ZK-verified EVM transfers). This required a dual-proof architecture where each settlement is backed by two independent ZK proofs. RISC0 proving the chain state exists, and Groth16 proving the execution matches the user's intent.

3. Wiring 0G decentralized inference into the agent loop. Instead of calling centralized OpenAI APIs, we integrated 0G Serving for decentralized AI inference. This meant using @0glabs/0g-serving-broker to discover available GPU providers, manage sub-account funding with A0GI tokens, and handle the fact that 0G models (Qwen 2.5 7B) don't support native function calling. We had to fall back to prompt-based tool calling where the model outputs structured JSON that we parse into MCP tool invocations.

4. Bridging Poseidon and Keccak256 across the ZK boundary. Our Circom circuit uses Poseidon hashing (ZK-friendly, ~10x fewer constraints), but Solidity and EIP-712 signatures use Keccak256. We designed the commitment scheme so the circuit proves derivation correctness with Poseidon, while the contract verifies signatures via EIP-712/Keccak256, bridging two hash worlds without breaking the proof chain.

5. snarkjs signal ordering caused silent on-chain failures. snarkjs outputs public signals as

   [output_signal, ...public_inputs]

   , but our contract expected

   [public_inputs...]

   . Proofs generated fine off-chain but silently failed the pairing check on-chain. We built a Groth16VerifierAdapter contract to bridge the gap.

Use of AI tools and agents

VAEB is built as an AI-agent-native protocol. The AI agent is not a helper, it's the execution layer.

The agent interacts with the blockchain via MCP. We built an MCP server exposing 23 tools across 6 categories: chain queries, intent creation/execution, wallet management, agent reputation, marketplace, and proof verification. Any MCP-compatible AI model can discover and call these tools. The agent reads balances, constructs intents, generates ZK proofs, and submits verified transactions, all through standard tool calls.

The core flow: A user chats naturally ("I need someone to walk my dog" or "send 10 USDC to 0x..."). The AI agent interprets the request, calls create_intent to build a structured IntentBundle, presents it to the user for EIP-712 signing, then calls execute_intent which generates a Groth16 ZK proof and submits the verified transaction on-chain. The agent handles the full lifecycle from natural language to on-chain settlement but is cryptographically constrained by the ZK proof to only execute what the user signed.

AI coding assistants (Claude Code, Cursor) were used extensively during development: contract testing, MCP server implementation, and multi-chain deployment scripting were all built with AI pair programming.