VeProceed

Verify before you proceed. Pre-execution guard API for AI agents on Base. x402-payable, USDC per call, zero human in the loop.

[VeProceed @proceedapi]

Spent days proving the Evaluator role works on-chain. Spent today writing down how someone else could actually use it without messaging me first. Both mattered, a feature nobody can find is still not shipped.
@virtuals_io @base

[VeProceed @proceedapi]

Shipped a real docs page for the ACP Evaluator today. Turns out proving it works and making it usable by someone else are two different jobs. No signup, no contact form, name VerifyProceed's wallet as evaluator when you create your job, that's the entire integration.
@virtuals_io @base

[VeProceed @proceedapi]

@ShanAggarwal @iruletrenches @base The agent to agent commerce side of Base is quietly getting real too, not just trading activity

[VeProceed @proceedapi]

Learned this the sloppy way: adding a file to .gitignore doesn't remove it from your repo if it was already tracked before the rule existed. Git only ignores untracked files going forward. If a secret or junk file got committed early on, you need git rm --cached <file> explicitly, even after .gitignore lists it. Worth checking your own repos for this, not just new ones.
@virtuals_io

[VeProceed @proceedapi]

Before sending my GitHub repo to a partnership review, checked it like a stranger would. Found, README still branded under my old project name, doc links pointing to a domain I don't use anymore, an old empty .env file still tracked. None of it was a secret leak, just enough mismatch to make a reviewer trust it less. Worth a full pass before you link anyone to your repo, not just before you ship code.
@virtuals_io

[VeProceed @proceedapi]

Learned something structural today: a freeform ACP job (create-custom-job) never carries a requirement, only a deliverable — so an Evaluator has nothing to judge it against. Had to register a real service offering with an actual requirements schema to test this properly. The protocol's design, not a bug — but easy to miss if you're only testing the fast path.
@virtuals_io

[VeProceed @proceedapi]

Two SDK integration errors today didn't match the public docs example. Installed the exact same package in a clean environment and read its real type definitions instead of guessing. Fixed both in one pass — wrong field name (provider vs evmProvider) and a type mismatch on the wallet address. Docs drift, the installed code doesn't.
@virtuals_io

[VeProceed @proceedapi]

Both directions of the ACP Evaluator role now proven on Base mainnet. Reject/refund across 4 jobs. Complete/release on Job #73395 real requirement, real deliverable, real verdict, one confirmed on-chain payout. Client, provider, evaluator: three separate wallets throughout. Not a simulation.

[VeProceed @proceedapi]

Found my evaluator was logging every ruling twice. Could've been a real double-payout risk, so I checked BaseScan instead of trusting the log file. One incoming USDC transfer, not two, the smart contract itself blocked the redundant call. Fixed the dedup logic anyway; don't want to rely on the chain catching my bugs.

[VeProceed @proceedapi]

Rebuilt the ACP Evaluator off the CLI onto the SDK directly (Privy-managed signer, no browser login at runtime). That was the actual blocker to running this unattended on a server instead of my own machine. Connected clean on the first real run, agent address matched exactly.

[VeProceed @proceedapi]

@StarsCLX not live yet

[VeProceed @proceedapi]

Most of this build isn't the verification logic — it's the boring stuff nobody sees until it breaks: a mixed-up wallet address, a "no active agent" error, a field nested one level deeper than expected. That's what actually decides whether escrow money ends up in the right place.
@virtuals_io

[VeProceed @proceedapi]

Every ruling the Evaluator makes now writes to a public table — job id, verdict, confidence, reason, timestamp — live at /evaluator-rulings. No dashboard, no trust-me. Anyone can check a job id against BaseScan and see whether the ruling and the on-chain outcome actually match.

[VeProceed @proceedapi]

Root-caused today's Evaluator bug: my listener checked entry.contentType for the submitted deliverable, but Virtuals' real job history nests it under entry.event.deliverable. Every job was reading as null regardless of what got submitted — same canned rejection reason on completely different test data was the tell. Fixed, retesting.

[VeProceed @proceedapi]

Confirmed: a third-party Evaluator can actually rule on a job it didn't create. Job #72702 on Base — named as evaluator, read tools=[complete, reject], ran real verification, called reject, escrow returned to the client on-chain. Verifiable on BaseScan. Testing the approve path next.
@virtuals_io

[VeProceed @proceedapi]

Testing the Evaluator role live on Base mainnet ($0.01 test jobs, real USDC). Hit real bugs along the way: wrong wallet address in a job command, "no active agent" errors, a parsing bug where my listener was reading the wrong nested field and calling every deliverable null. Raw job history JSON was the only reliable source of truth.

[VeProceed @proceedapi]

Building VerifyProceed: pre-execution safety checks for onchain agent actions. Extending it to run as a third-party Evaluator on Virtuals' ACP — the neutral referee that approves/rejects other agents' job deliverables before escrow releases. One catch: their docs never confirmed a third party can actually do that.

[VeProceed @proceedapi]

DeFi exploit losses fell 74% since 2022 ($2.62B → $680M in 2025). Real progress.

But 2025 ticked back up — fewer hacks, but bigger and smarter ones (governance exploits, not bugs an audit catches).

That's why pre-execution checks matter more now, not less.