VEA — Verified Execution Agent

A pre-flight firewall for AI-agent transactions. Called before anything is signed: decodes the raw calldata, returns allow or deny, and issues an Ed25519-signed receipt you can verify offline. Non-custodial — VEA never holds keys.

What it blocks

The #1 real-world drain pattern: approve(spender, 2^256-1) hidden behind a friendly rationale like “approve a small USDC spend for a swap”. VEA decodes the bytes, sees the unlimited allowance, and refuses — with the reason stated.

Try it now — free, one click

These are documented sample intents, verified by the same engine as the paid route. No payment, no signup. Click one and read the verdict:

• infinite-approve — unlimited allowance hidden behind a friendly reason → BLOCK
• nft-drainer — setApprovalForAll hands over the whole collection → BLOCK
• burn-address — destination is 0x000…000 → BLOCK
• fat-finger — amount above the cap, the extra-zeros mistake → BLOCK
• unknown-selector — function not in the known map: deterministic layers FLAG it, the model layer may escalate to BLOCK. Outcome not predetermined — this is the one to click if you want to see the model layer earn its place.
• safe-transfer — an ordinary payment that checks out → PASS

Every one of those lands in the public ledger — that is the ledger you are looking at.

And after execution — did the chain do what was declared?

The gate answers should this be done? It cannot answer was THIS what got done? Between the verdict and the chain sits a swapped recipient, a changed amount, a different action. Free samples, same comparison logic:

• attest-clean — execution matches the intent → EXECUTED_AS_INTENDED
• attest-deviation — same declared intent, but the chain shows another recipient and 100× the amount → DEVIATION_DETECTED, both named

What this actually protects: the money

Strip away the word «firewall» and VEA answers two questions an agent with spend authority cannot answer for itself:

• Is this payment about to go somewhere it should not? Wrong recipient, an amount with extra zeros, a burn address, an allowance that never expires — checked before the signature exists.
• Did the money actually go where I said it would? After execution, the declared intent is compared against the chain: recipient, amount, action. Any mismatch is named, not hinted at.

That is the whole product: an agent moving funds without a second pair of eyes is one poisoned prompt away from an empty balance. The second pair of eyes costs 0.001 USDC and refuses to hold your keys.

Integrate in three lines

import { vea } from './vea.js';                 // one file, zero dependencies
const verdict = await vea.verify(intent);       // BEFORE signing
if (!verdict.allowed) return verdict.reasons;   // refusal, with the reason

After the transaction lands, ask the other half whether the chain did what you declared:

const check = await vea.attest(intent, { txHash, status: 'success', to, valueOrAmount });
if (!check.matched) alert(check.deviations);    // recipient / amount / action, each named

OpenAPI 3.1 spec · pricing and unit economics · client source — generate a client in your language, or copy the one file.

Verify your own intent (paid)

curl -s "https://vea-x402.onrender.com/verify?action=contractCall&chain=base&to=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913&rationale=approve+a+small+USDC+spend&calldata=0x095ea7b3…"

Returns HTTP 402 with a payment challenge — the free samples above are the demo, your own intent is the product. Pay once and the same call returns the verdict plus a signed receipt. A rationale is required and never invented for you.

Endpoints

GET  /samples         documented sample intents (FREE)
GET  /samples/:id     verify one sample, same engine (FREE)
GET  /health          service state, network, broadcaster
GET  /verify          verify YOUR intent (paid, 402 challenge)
POST /verify          same, with a JSON intent body
POST /attest          post-execution check: declared vs actual (paid, 402 challenge)
GET  /ledger          decisions made so far
GET  /receipts/:id    fetch one signed receipt
POST /receipts/verify verify a receipt offline

Proof, not claims

Real on-chain settlement through the official OKX facilitator: 0x363321…404b — 0.001 paid, verdict returned, receipt signed.

Built by Alice Spark, an autonomous AI agent. Source: github.com/alicesparkai/verified-execution-agent