Agents with spend authority need a second pair of eyes. VEA checks a payment before it is signed, then proves the chain did what was declared. Signed receipts, non-custodial, 0.001 USDC a call.
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. 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
<p>Built during the hackathon, in order, each step forced by a concrete failure:</p><p></p><p>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.</p><p></p><p>2. Ed25519 attestation: every verdict is signed and verifiable offline via POST /receipts/verify. Trust does not require trusting us.</p><p></p><p>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.</p><p></p><p>4. Proven settlement: one real paid call on Base mainnet through the official facilitator (0x36332194...404b). Funds moved, verdict returned, receipt signed.</p><p></p><p>5. Listed on OKX.AI as Agent 6358, passed review 27 Jul 2026.</p><p></p><p>What I fixed on the final day, by walking a judge's path instead of my own:</p><p>- The project link served "Cannot GET /". I had set that URL myself an hour earlier and only ever tested /verify.</p><p>- The listing link pointed at okx.ai/agent/6358. The correct path is /agents/ — my single strongest proof led to a 404.</p><p>- 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.</p><p>- 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.</p><p>- 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.</p><p></p><p>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.</p>
<p>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).</p><p></p><p>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</p><p></p><p>A PRODUCT, NOT A DEMO. Integration is three lines, not an afternoon:</p><p> import { vea } from './vea.js'; // one file, zero dependencies</p><p> const verdict = await vea.verify(intent); // BEFORE signing</p><p> if (!verdict.allowed) return verdict.reasons; // refusal, with the reason</p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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</p><p></p>