Pre-execution firewall for AI agents: called before any onchain action, it decodes the calldata and returns allow or deny plus a signed, verifiable receipt. Blocks drainers like unlimited approvals.
VEA (Verified Execution Agent) is a non-custodial pre-flight firewall for AI-agent transactions. Before an agent touches the chain it makes one call: /verify returns allow or deny plus an Ed25519-signed, publicly verifiable receipt. VEA holds no keys and never executes — the agent executes with its own keys, then calls /attest for a post-execution deviation check (EXECUTED_AS_INTENDED or DEVIATION_DETECTED).
TRY IT FREE, IN ONE CLICK: https://vea-x402.onrender.com/samples — six documented sample intents, run through the SAME engine as the paid route, no payment and no signup. Watch it decode an unlimited approve() hidden behind a friendly rationale and refuse it, with the reason stated. Every decision lands in the public ledger: https://vea-x402.onrender.com/ledger
Four-layer gate, all four live: (1) structural validation, (2) safety rules, (3) a Calldata Guard that ABI-decodes the real bytes — catching drainers like an unlimited approve() disguised as a swap, and (4) a model layer that can only ADD blocks, never remove them, so determinism always wins. The unknown-selector sample shows layer 4 earning its place: the deterministic layers merely FLAG an unverifiable call, and the model escalates it to a block.
Honest scope, stated plainly: the gate, the Calldata Guard and the receipts are real — verify any receipt yourself via POST /receipts/verify, offline, without trusting us. Payment is a real x402 handshake settled through the OFFICIAL OKX facilitator: the Base transaction 0x36332194040918c2268612c6aed32fb92c2966b2d98362066a3eeefdb356404b moved real funds. The X Layer hash is a sponsored broadcast — no funds moved, and that is exactly what the hash shows. On-chain custody is out of scope by design: VEA is a verifier, not a custodian.
Live: https://vea-x402.onrender.com — LISTED and live on OKX.AI as Agent 6358, passed review 27 Jul 2026. Source: github.com/alicesparkai/verified-execution-agent
Built during the hackathon, in order, each step forced by a concrete failure:
1. The gate itself: structural validation, safety rules, and a Calldata Guard that ABI-decodes raw bytes without pulling in a keccak dependency — the well-known selectors are hardcoded and auditable. It catches approve(spender, 2^256-1), setApprovalForAll, hidden transferFrom, and refuses with the reason stated.
2. Ed25519 attestation: every verdict is signed and verifiable offline via POST /receipts/verify. Trust does not require trusting us.
3. x402 payments on the OFFICIAL OKX SDK (@okxweb3/x402-express, x402-core, x402-evm). This took six rejected listing submissions. The instructive one: rejection #2 came because a paid GET returned HTTP 405 — my attempt to be principled and "not charge for a useless GET". I ran a real payment with their own tooling and saw what a reviewer sees: status failed, merchant returned 405. Not taking money is no virtue if you hand back an error instead. Now a paid GET does a real verification.
4. Proven settlement: one real paid call on Base mainnet through the official facilitator (0x36332194...404b). Funds moved, verdict returned, receipt signed.
5. Listed on OKX.AI as Agent 6358, passed review 27 Jul 2026.
What I fixed on the final day, by walking a judge's path instead of my own:
- The project link served "Cannot GET /". I had set that URL myself an hour earlier and only ever tested /verify.
- The listing link pointed at okx.ai/agent/6358. The correct path is /agents/ — my single strongest proof led to a 404.
- Every route to a verdict was paid, so /ledger read total: 0 and the landing's 402 example returned an empty body. Fixed with a free documented sample gallery: paid is verifying YOUR intent, free is running MY six samples through the same engine, no leniency.
- A GET could not carry a rationale, yet the gate requires one — a paying caller got refused for a reason they could not possibly supply.
- The model layer had been silently dead in production: the free provider returned 402 from datacenter IPs, so every verdict shipped with confidence 0.6 and "LLM unavailable". Moved to a working provider with a token scoped to inference only.
Honest about the gaps: one real paid call, not a revenue stream. The ledger's entries are the startup self-test of the documented samples, and the endpoint says so in plain words rather than letting the number speak for itself.
VEA (Verified Execution Agent) is a non-custodial pre-flight firewall for AI-agent transactions. Before an agent touches the chain it makes one call: /verify returns allow or deny plus an Ed25519-signed, publicly verifiable receipt. VEA holds no keys and never executes — the agent executes with its own keys, then calls /attest for a post-execution deviation check (EXECUTED_AS_INTENDED or DEVIATION_DETECTED).
TRY IT FREE, IN ONE CLICK: https://vea-x402.onrender.com/samples — eight documented sample intents, run through the SAME engine as the paid route, no payment and no signup. Watch it decode an unlimited approve() hidden behind a friendly rationale and refuse it, with the reason stated. Then open /samples/attest-deviation: the agent declared 25 to one address, the chain shows 2500 to another — both deviations named. Every decision lands in the public ledger: https://vea-x402.onrender.com/ledger
A PRODUCT, NOT A DEMO. Integration is three lines, not an afternoon:
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
Machine-readable contract at /openapi.json (OpenAPI 3.1 — generate a client in your language). Price and unit economics stated openly at /pricing. Zero dependencies is a deliberate choice: a firewall that drags in a package tree enlarges the very attack surface it exists to reduce.
FOUR LAYERS, ALL LIVE: (1) structural validation, (2) safety rules, (3) a Calldata Guard that ABI-decodes the real bytes — catching drainers like an unlimited approve() disguised as a swap, and (4) a model layer that can only ADD blocks, never remove them, so determinism always wins. The unknown-selector sample shows layer 4 earning its place: the deterministic layers merely FLAG an unverifiable call, and the model escalates it to a block.
REVENUE, STATED WITHOUT INFLATION. Two recorded uses on OKX.AI, one of them my own verification purchase. That is not a revenue stream and I will not dress it up as one. What IS proven is the rail: a real x402 settlement on Base mainnet through the OFFICIAL OKX facilitator — 0x36332194040918c2268612c6aed32fb92c2966b2d98362066a3eeefdb356404b — funds moved, verdict returned, receipt signed. Per-call pricing, because a firewall billed monthly is a firewall someone forgets to renew; the protection must be present exactly when the risk is. The asymmetry is the argument: 0.001 USDC against one unlimited approve() that drains a whole balance.
HONEST SCOPE. Verify any receipt yourself via POST /receipts/verify — offline, without trusting us. The X Layer hash that appears in my materials is a sponsored broadcast, not a payment: no funds moved, and that is exactly what the hash shows. On-chain custody is out of scope by design — VEA is a verifier, not a custodian.
Live: https://vea-x402.onrender.com — LISTED and live on OKX.AI as Agent 6358, passed review 27 Jul 2026. Source: github.com/alicesparkai/verified-execution-agent