KaizenScope

DeFi agents you can verify before you sign.
A BNB Smart Chain Testnet marketplace where the agent proposes, the buyer's own wallet executes, and the payment is captured only after the work is verified on chain.

---

The problem: a registry full of agents, none of them auditable

ERC-8004 gives agents an on-chain identity. It does not give a buyer any way to decide whether one is worth trusting.

We probed both ERC-8004 registries on BSC directly over public RPC (the official 0x8004… registry and the BRC8004 fork) and measured, per agent, whether its AgentCard resolves, whether it carries on-chain feedback, and whether it was active. The reproducible run is in agents/output/summary_20260811.md, and its numbers are committed as public/contest/registry-census.json so the product reads them instead of restating them as prose:

Registry	Agents observed	AgentCard resolves	With on-chain feedback	Passing the seed filter
BRC8004 (full census)	26	17	0	0
Official 0x8004… (sampled, not enumerable)	40	35	0	0

Zero agents carried reputation a buyer could compare, and none were DeFi native. The observed total is deliberately a floor rather than a full count: the official registry does not expose totalSupply, so it is sampled through Registered events instead of swept.

Wiring a home page straight to that registry would render noise, not a marketplace. So KaizenScope inverts the question: instead of listing who claims to be an agent, it publishes what each listing is allowed to do, and then proves it did it. That measured gap is the third statistic on the live home page, linked back to the summary above.

The answer: a bounded plan, signed by the buyer

Every listing declares its allowed contracts, its allowed function selectors and its dedicated payment wallet before anyone connects. The buyer sees all of it, then signs each step from their own wallet. KaizenScope never holds custody, never asks for a seed phrase, and never requests an unlimited approval.

How an order runs

Four gates, always in this order. The payment gate is last on purpose.

sequenceDiagram
    autonumber
    actor Buyer as Buyer wallet
    participant App as KaizenScope
    participant Chain as BSC Testnet
    participant Relayer

    Buyer->>App: POST /api/orders/quote
    App->>Chain: read the live position at a specific block
    App-->>Buyer: bounded plan + x402 payment requirement
    Note over Buyer: reviews contracts, selectors,<br>values and expiry
    Buyer->>Chain: approve Permit2 for the exact amount, never unlimited
    Buyer->>App: POST /orders/:id/authorize (Permit2 signature)
    Note over App: validates the signature.<br>No money moves yet.
    Buyer->>Chain: sign and send every work transaction
    Buyer->>App: POST /orders/:id/submit (work tx hashes)
    App->>Chain: verify buyer, calldata, recipient, value, receipt
    Chain-->>App: all steps succeeded
    App->>Relayer: capture payment, only now
    Relayer->>Chain: Permit2.permitTransferFrom
    App-->>Buyer: public receipt with both sets of hashes

Loading

What this buys you, concretely:

• The work cannot be faked. submit re-derives the expected calldata from the stored plan and matches it against the receipts on chain. A hash that does not match the buyer-signed plan is rejected.
• A failed agent is a free agent. Payment settles after verification, so work that reverts is never charged for. If work succeeds and capture then fails, the order becomes an explicit unsettled state whose already signed payment can be retried without repeating the work.
• The authorization is bounded in time and amount. The Permit2 deadline is derived from the quote expiry, so a stale authorization cannot be replayed later.
• The server never sees a private key. It holds a signature, and a relayer that can only pull the exact amount the buyer signed for.

Proof: four categories, four settled receipts

The gate is public at /proof and reads the same committed manifest as the table below.

4 of 4 categories settled · 8 buyer-signed work transactions · 4 captured payments.

Every receipt below belongs to the same buyer wallet, 0x4bc6019c…483216, on BSC Testnet (chain 97).

Category	Work, signed by the buyer	Payment, captured after verification	Public receipt
Yield planning · Venus	0x9da4bf72…0d8ea1 0x6aec43ea…752716	0x1d738079…8d8d65	receipt_cdde8bf66a3841fd9090d9b078818609
Grid trading · PancakeSwap V2	0xffd6cadf…d80b02	0x94cf4440…c370bb	receipt_fe6975e5163b461da62f292a27f293a7
Health-factor protection · Venus	0x9d239c2f…51233b 0x25a5f58a…e0514e	0x299c2b24…878ade	receipt_e9ebebeb108443508d7b1aac30da3215
Range management · PancakeSwap V3	0xf533f1b8…7edf75 0x51c21797…a9b7bc 0x8a2cae18…68b390	0x9ae0a03e…96ba1a	receipt_997a8b5529ad4b478a0e56bb7664490b

_{Generated from public/contest/evidence.json by pnpm evidence:sync. Do not edit by hand.}

A receipt only counts here when it has a fresh quote, buyer signed work transactions, a settled payment, a useful result and a public receipt id. Historical laboratory transactions are labelled as such throughout the product and are never presented as buyer evidence.

The four listings

Listing	Category	Protocol	Bounded action
Venus Yield Planner	Yield planning	Venus Protocol	Supply a capped USDT amount
PancakeSwap Grid Planner	Grid trading	PancakeSwap V2	One bounded swap inside fixed limits
Venus Health Factor Planner	Health factor	Venus Protocol	A capped repayment against the buyer's own debt
PancakeSwap V3 Range Planner	Range management	PancakeSwap V3	A bounded action on a buyer owned position

Each one resolves its payment wallet from a distinct environment key. A listing whose wallet is missing, invalid or shared with another listing is rendered paused and refuses orders, rather than disappearing from the catalogue.

Architecture

src/
├── app/                     Next.js App Router
│   ├── api/orders/          quote → authorize → submit  (the only order path)
│   ├── api/hire/[agentId]/  retired, returns 410 Gone
│   ├── api/health/          runtime configuration gate
│   └── proof/               public contest gate, reads the evidence manifest
├── lib/
│   ├── catalog/             featured listings, allowed contracts and selectors
│   ├── quotes/              per protocol adapters that build the bounded plan
│   ├── orders/              store, encryption, execution verification, settlement
│   ├── contest/readiness.ts the shared PASS/PENDING/BLOCKED rules
│   └── x402.ts              402 negotiation and Permit2 envelope
├── public/contest/          committed manifests: buyer evidence and the registry census
├── agents/, indexer/        the ERC-8004 registry census behind "The problem"
└── scripts/                 local testnet bootstrap and the evidence table sync

Why plain Permit2 and not B402's permit2-exact. Permit2 is deployed at the same canonical address on every chain, testnet included. Witness binding would have meant standing up extra infrastructure for a testnet demo, so the binding is enforced server side instead: the signed spender must be our relayer, and the signed amount must match the quote.

Why the payment is conditional, not atomic. True atomicity would require an escrow contract, which would need an independent audit before it deserved anyone's trust. This build trades escrow complexity for a deterministic work first ordering, and says so out loud rather than implying more than it proves.

Run it locally

pnpm install --frozen-lockfile
cp .env.example .env.local
pnpm run ci
pnpm dev

Populate only Testnet values in .env.local. Never commit keys, database URLs or wallet secrets. pnpm run ci runs the evidence table check, lint, typecheck, the full test suite and a production build.

pnpm evidence:sync      # regenerate the README evidence table from the manifest
pnpm testnet:status     # local Postgres and public configuration state

What this is not

• Testnet only (chainId 97). No mainnet operation is implied by anything in this repository.
• Not a 24/7 service. Each listing prepares one bounded execution per fresh quote. Nothing runs unattended in the background.
• Not investment advice, and no yield, performance or execution guarantee is offered.
• Not audited. Mainnet is conditional on an independent security review, permission and revocation controls, monitoring and an escrow decision. See the roadmap.
• The catalogue metadata is curated and static, and labelled as such in the product. Protocol readings are live from BSC Testnet.

Documentation

Document	What it covers
docs/USAGE.md	Operating guide: setup, wallet connection, the buyer execution gate
docs/CONTEST_READINESS.md	Evidence contract and the operator verification matrix
docs/DEMO_RUNBOOK.md	Step by step runbook for reproducing a buyer session per category
docs/JUDGE_AUDIT.md	Evidence based review against the official rubric
docs/ENGINEERING_LIMITATIONS.md	Risk disclosure, read before testing with a wallet
docs/THREAT_MODEL.md	Trust boundaries and what the relayer can and cannot do
docs/BUSINESS_MODEL.md	Zero platform fee on testnet, and what a mainnet model would have to disclose
docs/ROADMAP.md	What is complete, and what has to happen before mainnet
docs/LOCAL_TESTNET.md	Local Postgres and bootstrap for development

Licensed under MIT.