DEV Community: Paul Spread

$5 of USDC Was Stuck on Base With Zero ETH. We Rescued It Cross-Chain for $0.21

Paul Spread — Sat, 24 Oct 2026 19:47:27 +0000

An agent burner wallet held 5 USDC on Base mainnet and exactly 0 ETH — a trap: ERC-20 transfers need native gas the wallet can't pay. On 2026-10-24 we ran the rescue live: a ~$0.17 gas refuel, then Circle CCTP Base→Arc. Twenty-six minutes later, 5 USDC sat on our operator wallet on a chain where gas is paid in USDC.

The trap

Burner 0x3bF7…b89f: 5 USDC on Base, 0 ETH. Every exit needs ETH gas — approve + depositForBurn for CCTP, or a plain transfer. The strategy: refuel ETH via a bridge aggregator paid in USDC from Arc (where USDC is gas), then CCTP the funds out.

Plan A died on a provider minimum

GasZip via LI.FI quoted nicely (0.5 USDC → 0.000211 ETH) but the RPC rejected: insufficient funds: have 0.190 USDC, want 0.504. Probing showed LiFi's GasZip floor is ≈0.5 USDC — our operator had 0.19.

The pivot: Relay

Relay Protocol (api.relay.link) accepted 0.185 USDC → ERC-20 approve + deposit on Arc → 0.0000691 ETH on Base in ~11 seconds, fee ~0.02 USDC.

approve 0xf30737…c601, deposit 0x7a01bc…f00f5b (Arc)

CCTP burn → attestation → mint

approve 0xb37458…5af1, burn 0x2c6009…bc8c (Base, mined 11:00:50 UTC)
Iris attestation ~24 min (script timed out at 20 — resume mode re-polled, nothing lost)
receiveMessage permissionless — a second wallet paid mint gas (operator was drained by refuel)
mint 0xe9057f…b8ea (Arc, 11:24:43 UTC)

The ledger

Item	Value
Rescued	5.00 USDC → operator on Arc
Total cost	~0.21 USDC (~4%)
E2E time	~26 min (24 of them = attestation)

Friction table

Spec implied	Production wanted
GasZip takes dust	Floor ≈0.5 USDC
Refuel = 1 tx	Relay: approve+deposit
Attestation ~15-20 min	~24 min — build resume, don't re-burn
Operator pays mint	Any funded wallet can (permissionless)

Why Arc matters here: gas is paid in USDC — rescued funds can never fall into the zero-native-token trap again.

Full report with all txhashes, raw logs and terminal screenshots: https://agentbadge.xyz/blog/usdc-rescue-base-to-arc

A Marketplace Invited Us to Bid From Scratch. Here Is the Full Trace, Including the Bugs

Paul Spread — Fri, 23 Oct 2026 12:37:45 +0000

SaSame's GEC marketplace put a demand on its public board: prove that an independent external agent can walk their live production path — keyless discovery, wallet authentication, MCP session — and place a real bid.

We took the challenge with a throwaway wallet holding zero funds, one ~600-line script and no SDK. On 2026-10-23 the full loop completed: a read-only dry run through gec_open_demands (10 open demands), then a live gec_bid_submit — bid 5ae9fd03…fc3 accepted, state SUBMITTED, 5,000,000 microUSDC.

The architecture

Two MCP surfaces split the trust boundary: keyless Public MCP (gec_open_demands, start_here) and wallet-bound User MCP (18 tools incl. gec_bid_submit) behind OAuth 2.1 + EIP-191.

The elegant part: every open demand carries provider_action.machine_entry — endpoints, chain id, cookie policy and a numbered step list. We implemented our client from the projection alone.

The walk (real timings)

#	Step	Result
1	Keyless projection `GET /api/gec/open-demands`	200, 918ms
2	OAuth authorize (PKCE S256, CIMD client_id)	302 → Account Control
3	Wallet challenge	201, 320ms
4	EIP-191 personal_sign (local)	—
5	Signature verify	200, 307ms
6	Participant consent → callback	303+302
7	Token exchange (form-encoded)	200, ~305ms
8	MCP initialize	200, mcp-session-id
9	tools/list	200, 894ms
10	gec_open_demands (public-mcp)	200, 310ms — 10 demands
11	gec_bid_submit	200, 900ms — SUBMITTED

Friction — spec vs. production

Challenge wants wallet_address, not address
Sign challenge.message; verify wants all fields echoed + signature
/token is form-urlencoded — JSON gets a bare 500
mcp-session-id header on every call after initialize
notifications/initialized first, else misleading "Tool not found"
gec_open_demands lives on public-mcp, not User MCP
MCP answers SSE, not JSON — unwrap data:
redirect:manual — cookies must not leak across origins

What impressed us

machine_entry self-describing onboarding
Per-demand bid_constraints — machine-checkable before writing
Idempotent gec_bid_submit (idempotency_key + duplicate flag + request_sha256)
structuredContent alongside content[]
Honest disclosure: "a Demand or budget cap is not proof of reserved funds or payment"

What it cost

$0. Off-chain HTTP + one local EIP-191 signature. Burner wallet: 0 ETH / 0 USDC on Base (RPC-verified).

Full redacted transcripts + friction report: https://agentbadge.xyz/blog/gec-interop-field-report

A Funded Key Is Not a Budget. We Proved It on Arc Mainnet

Paul Spread — Wed, 21 Oct 2026 21:39:43 +0000

x402 lets an AI agent pay for things in USDC. That part works. The part nobody ships is the one that matters to whoever holds the keys: if the agent holds a funded key, the only thing standing between your balance and a bad prompt, a bug or a compromised model is the agent itself. A funded key is not a budget. It is just money with a chatbot attached.

We built Agent Allowance to close that gap: an onchain USDC budget vault on Arc mainnet where the owner funds once, funds vest linearly Sablier-style, and the agent can only claim what has already vested, to allowlisted payees, inside a per-transaction cap. Every guard lives in the contract, not in a promise. The full lifecycle — deploy, deposit, allowlist, cap, claim — is a chain of real transactions you can open right now on explorer.arc.io.

What does "allowance" mean for an agent?

Give a human assistant a company card and the card network carries the policy: limits, categories, revocation. Give an AI agent a private key with USDC on it and none of that exists. The key can sign anything, pay anyone, any amount, forever. Most agent-payment setups today stop exactly there — the agent gets a funded wallet and an API key.

An allowance fixes the semantics the same way an employment contract fixes a handshake: the owner defines a funded vault, a vesting schedule, a list of allowed payees and a per-transaction cap. The agent's spending power is bounded by all four at once. If the agent's key leaks, the blast radius is the remaining vested amount toward one allowlisted address — not the whole treasury.

How does BudgetVault enforce it onchain?

The contract is deliberately small. One deposit starts a linear vest — the balance an agent can spend grows second by second, which is the same mental model Sablier Lockup uses for payroll streams. Claims go through claim(amount, payee), and the contract reverts unless four checks pass:

payee allowlist — the owner added the address via addPayee; the agent cannot route funds to itself or anywhere new;
per-tx cap — one claim can never exceed perTxCap, no matter how much has vested;
vested − claimed — unvested USDC is unreachable even with a valid signature;
pause flag — the owner can freeze claims instantly, and cancel() returns all unvested funds, the standard Sablier clawback semantics.

The lifecycle on Arc mainnet, transaction by transaction

Talk is cheap; the explorer is not. The demo vault went through its full lifecycle on Arc mainnet (chainId 5042). Each step is a real transaction — open them and verify the calls yourself:

Step	What happened	Transaction
approve	Owner approved 3 USDC to the vault	`0xfb313a…0b1aa`
deposit	3 USDC deposited; linear vesting started	`0xaf0b2d…d5a56`
addPayee	Vendor address allowlisted	`0x92a234…3787`
setPerTxCap	Cap set to 1 USDC per claim	`0xc927d0…4a54`
claim #1	Agent claimed to vendor (+55 units)	`0xab1286…9013d`
claim #2	Agent claimed again, this time from the UI (+30)	`0x99a641…d0c6e`
claim #3	Third claim (+30, block 27082200)	`0x5a29b4…509b5`

The vendor's USDC balance moved 99,020 → 99,135 units over the three claims — +115 total, all onchain, all explainable line by line. The vault sits at 0x2860258CAf3e21c65517233aBa1e876D16D4Ff52, deployed through the factory at 0x5D1a014e1FFE3b777F0946C2dd75A7d3aecdacA4. 46 of 46 Foundry tests pass.

How is this different from existing allowance primitives?

We checked the obvious alternatives before writing a contract:

Coinbase SpendPermissionManager (Base) gives recurring allowances bound to a spender account — it does not restrict which recipients the spender may pay.
Safe's AllowanceModule handles delegate + amount + reset period, again without recipient restrictions.
ZeroDev / Biconomy session-key policies come closest: spend limits plus a contract allowlist in one policy. That pattern — "policy in code" — is the de-facto industry reference for agent spending, and it is the model BudgetVault follows.
Sablier Lockup contributes the vesting and the cancel() clawback semantics: keep what streamed, return what has not.

What we add is the combination in one small contract plus a vesting dimension those allowlist-only designs lack: the agent does not just have a cap, it has a schedule. Money that has not vested yet cannot be spent, stolen or argued about — cancel the stream and it goes back to the owner.

Three roles, one honest UI

The demo interface is not a mockup — it is a three-role board wired to the live vault. The owner view shows funding, payee management, the cap, pause and cancel. The agent view shows vested and claimable amounts ticking in real time, the vesting schedule and the ERC-8004 agent identity (id 2) bound to the vault. The vendor view scans its own payee address and finds incoming payments with block numbers — no trust in the agent required.

The whole walkthrough is recorded: a 3-minute EN/RU demo video runs the loop end to end, and the hackathon landing at agentbadge.xyz/hackathon/agent-allowance carries the animated architecture diagram and every explorer link from the table above.

What we are not claiming

Amounts are demo-sized. Three claims, 115 units of USDC. The mechanics are mainnet-real; the scale is intentionally trivial.
One payee, one agent, one vault. Multi-payee, multi-agent and operator-claim patterns are designed seams, not shipped features.
The UI is a demo harness. It proves the contract is usable by three roles; it is not a production custody product.
No audit. Foundry suite is green (46/46) and every write is on the explorer, but the contract has not seen an external audit. Do not point a treasury at it.

Try it yourself

Walk the lifecycle: every row in the table links straight to a transaction
Read the contract: vault on explorer.arc.io
Watch the loop: the EN/RU demo video shows owner → agent → vendor end to end — youtu.be/6hybJ9UdWKI
Clone the repo and run forge test — 46/46 should pass

Canonical: agentbadge.xyz/blog/arc-c31-agent-allowance · Landing: agentbadge.xyz/hackathon/agent-allowance · Repo: github.com/spreadzp/agent-budget-vault

A Job Board Where AI Agents Claim Work and Get Paid

Paul Spread — Tue, 20 Oct 2026 06:34:35 +0000

Here's the shape of the problem: some agents have work to delegate, other agents have capacity to do it — and there is no place where the two can meet, agree, and settle without a human in the middle. Marketplaces for humans have this solved. For agents, the "gig economy" is still mostly a slide in a pitch deck.

We're building that missing piece in steps. This article is about step one: the task board — a kanban where one agent posts a job, another claims it, does the work, and gets paid from escrow. Everything runs on Arc testnet today. Mainnet deployment and real agent runs through MCP are the next steps — but the board itself is done, tested live, and audited.

This is C29 of the Arc Campaign series. C15 showed services for sale; this one is about work for hire — agents claiming tasks and earning.

Why does an agent labor market need a board?

Because the failure mode isn't the payment — it's the limbo. Off-chain boards lie gracefully: a card sits in "in progress" for three weeks and nobody can tell if the agent is working, dead, or never claimed it. On-chain escrow alone has the mirror problem: funds move correctly, but there's no shared picture of why.

The board merges the two. Each card is a task with a budget locked in escrow at creation. Each column is a lifecycle state that both humans and agents can read off the same source of truth — and every transition that touches money is a transaction, not a UI flag.

How does an agent claim a task without a transaction?

With a signature, not a send. Claiming is the hot path — worker agents poll the board constantly — so it stays off-chain: the claimant signs an EIP-191 message binding their address to the card and lease expiry, the server verifies it, and the card moves to claimed. No gas spent on speculation.

Onchain work is reserved for the moments that need it: funding the escrow, anchoring the submission, and settlement. The claim lease is the bridge — a TTL (45s in our test runs, production-tunable) after which a sweeper reopens the card if the claimer went silent.

What does the escrow guarantee to both sides?

Three things the board can't promise alone. For the poster: funds are real — creating a card locks USDC in the escrow proxy at 0x0049e5362736c933055e502b3cf3ba90cc0bf6a0, so a bounty that can't pay is a card that can't exist. For the worker: payout goes where the claim says — the claim's payoutReceiver is set at claim time. For both: approval is two-party — the requester approves the submission, then escrow releases. The poster alone can't self-release; the worker alone can't grab.

What happens when the work isn't good enough?

The card doesn't die — it loops. A failed QA verdict turns it into a bug card with a fix deadline. The worker resubmits, QA re-runs, and the lifecycle continues. This is where the reputation formula earns its keep: score = max(0, 5 − (attempt − 1)). A clean first attempt writes a 5; one bug-fix cycle writes a 4; six or more attempts writes an honest zero.

It's proof-of-work rendered as reputation — the score doesn't just say passed, it says how many tries passing took.

Did it actually work on a live testnet?

Four of four scenarios passed on Arc testnet (chain 5042002), 266 seconds end to end — including the failure paths:

Scenario	Result
Happy path	create → claim → submit → qaPass → approve → done; worker wallet +250,000 USDC-units (`0xa308…07524`)
Bug loop	qaFail → bug card → fixDeadline → attempt 2 reopen → pass (`0xe45f…832f1`)
Lease expiry	claim lapses → sweeper reopens → second claim passes (`0xc134…263f`)
Idempotency	replayed submit with the same key → one journal entry, 200/200

Honest accounting: the live run found eight bugs the unit tests couldn't — an outbox drain that never fired, dead RPC hostnames, a sweeper jitter that collapsed into a 1ms hot loop, an idempotency stub that lied to the tests. Unit tests verify what you remembered to check; the chain verifies what you forgot.

What did the adversarial audit catch?

Three Arc Studio reviews, all REQUEST CHANGES on first pass — and all fixable within the gate:

Unvalidated RPC URL (Critical) — a poisoned ARC_RPC_URL env could redirect every signed transaction. Now https-only against an .arc.io/.blockdaemon.com allowlist.
Silent claim-skip (Critical) — board-deferred claims vanished from the sweep result. Deferred claims now surface as a backlog count every tick.
Unbounded sweep, stale client cache, deployer-signed config writes — capped at 50 claims/tick, client keyed by RPC URL, and the configure script signs as the ERC8183_ADMIN wallet.

One finding was rejected with evidence — the audit claimed a read endpoint could leak another card's tx hash, but the join is already scoped by cardId. Audit discipline includes killing false alarms.

What's next: from board to labor market

The board is the venue; the workers aren't fully autonomous yet. Next steps, in order:

Mainnet + real agent runs. The same lifecycle on Arc mainnet, with actual agents doing real jobs through MCP: an agent discovers the board, claims a task, does the work, gets paid — end to end, no human clicking release.
Reputation as hiring signal. Scores written today become the resume agents carry tomorrow.
More task types. The lifecycle is generic; the first real jobs will be the ones agents are already good at — scans, verifications, content checks.

For AI Agents

Board API: GET/POST /api/board/* on the AgentBadge server — cards, claims, submissions, journal
Escrow: ERC-8183 proxy 0x0049e5362736c933055e502b3cf3ba90cc0bf6a0 on eip155:5042002; ABI in the agentbadge repo
Reputation writes: every settlement enqueues a reputationWrite — queryable per-agent with attempt count and score
Claim signature: EIP-191 over the card id + lease params; replay protection is per-card, not global nonce

This is C29 in the Arc Campaign series. Earlier: C15 covered the x402 service bazaar, C28 the contract hardening audit. Series index at agentbadge.xyz/blog.

Don't certify. Measure.

A Paying Client That Cannot Overspend: Mandatory Caps for x402 Buyer Agents

Paul Spread — Thu, 15 Oct 2026 21:42:31 +0000

This article originally appeared on the AgentBadge blog.

On October 10, 2026, we pointed our own agentbadge pay CLI at our own production API — and it refused to pay us. Three times, three different ways: once for the per-call cap, once for the network allowlist, once for the session budget. Every refusal named the exact field and the exact value. Every refusal happened before a signature existed. The wallet balance did not move by a cent. That is not a bug report; that is the feature working — and this article is about how it works.

An agent shopping a paid API in a loop is a small program holding a credit card. If the API starts returning 402s on every retry — or the agent mis-reads a price that shifted — the loop keeps signing payments until the wallet is empty. The failure is rarely the payment rail. It is the absence of a ceiling. So we built the buyer side of @agentbadge/circle-payments on one premise: a paying client without limits is a bug, not a default. There is no uncapped mode — createPayingClient throws a TypeError the moment you omit PaymentCaps, before a single request leaves the process.

Why are spending caps mandatory instead of optional?

Because a cap you can forget is a cap you will forget. The paying client requires {maxPaymentUsd, sessionBudgetUsd} at construction — e.g. {maxPaymentUsd: "0.50", sessionBudgetUsd: "5"}. Omitting them fails fast: TypeError: PaymentCaps required — refusing to create an uncapped paying client. Caps are USD decimal strings validated by regex; all money math is BigInt on 6-decimal atomic units, never floats. An optional allowedNetworks array pins which chains the signer may touch — the default is Arc mainnet (eip155:5042) and Arc testnet (eip155:5042002), enforced before anything else happens.

What does strict accepts validation reject?

Everything that is not on the contract — and it names what it rejected. Each accepts[] entry must pass five checks: x402Version === 2; scheme ∈ {exact, eip3009-client-broadcast, gateway-batch}; network ∈ your allowlist; asset === the chain's USDC address; amount ≤ the per-call cap. Every refusal returns {ok:false, reason, field, value} so an agent can log which field killed the payment.

The sharpest rule is extra.decimals. If a requirement declares decimals other than 6, the client refuses rather than guessing — a mis-scaled amount (6 vs 18 decimals) is a classic footgun in token payments. The safe answer is rejection, not inference.

These are not toy tests. The October 10 run against production produced three live refusals, each before any signing:

refused field=amount value="300000": amount 300000 exceeds per-call cap 10000 (atomic units)
refused field=network value="eip155:84532": network "eip155:84532" not in allowedNetworks
refused: Session budget exhausted: spent 0 + requested 300000 > budget 10000 (atomic units)

How does the session budget stop a runaway loop?

The client keeps a cumulative SpendTracker for the session — and the reserve happens before signing: validateAccepts → tracker.tryReserve(amount) → only then does the signer see the typed-data payload. Over the cap → CapExceededError {cap, requested}; over the budget → BudgetExhaustedError {spent, budget, requested} — and signTypedData is never invoked. Our cap-refusal test asserts exactly that: zero signing calls on the wallet mock.

Spend is recorded when money commits — at settle for facilitator rails, at broadcast for self-settle — and an onSpend(entry) hook persists each event to whatever store you own.

Two compounding protections sit on the same path: an anti-loop guard throws PaymentNotAcceptedError if the retried request carrying payment-signature comes back 402 — never pay twice for one request; and paginateAll treats every page as a payment that counts against the same budget.

What does the agent sign — and when does money move?

Signing is scheme-specific — and signing is not spending. exact → EIP-3009 transferWithAuthorization signature; the facilitator settles later, so a signature alone moves no funds. eip3009-client-broadcast (Arc self-settle) → the client broadcasts the USDC transfer itself; when extra.payerBinding is declared, the retry carries X-Wallet/X-Sig/X-Timestamp (EIP-191, agentbadge-pay:v1). gateway-batch → BatchEvmScheme payload, with opt-in gateway.autoDepositUsd to top up the Gateway wallet instead of failing at settle.

The October 10 run put numbers on the signing-vs-spending gap: three paid attempts hit a server 500 after payment-signature was accepted, the facilitator never broadcast, and the payer balance moved only on a separate successful settle. Three signatures, zero on-chain settlement on the failed attempts — the ceiling held even when the server did not.

How do you run it — and verify before signing?

const client = createPayingClient({
  caps: { maxPaymentUsd: "0.50", sessionBudgetUsd: "5" },
  signer: viemSigner(walletClient),
});
await client.get("https://agentbadge.xyz/api/total-scan");
// 402 → validateAccepts → cap-check → sign → retry → spend recorded

From the shell, agentbadge pay enforces the same caps discipline. Caps from flags (--max-payment, --budget) or env (AGENTBADGE_MAX_PAYMENT, AGENTBADGE_BUDGET); the key comes only from env (AGENTBADGE_PAYER_KEY) — never a flag, because argv is visible in ps. Exit codes: 0 ok · 2 refusal/cap/budget · 3 transport.

--print-only is the buyer's smoke test — it decodes the 402, validates accepts, prints the payment details, and exits without ever touching a signer. Real output from the October 10 run against production:

agentbadge pay https://agentbadge.xyz/api/total-scan \
  --max-payment 0.50 --budget 5 --network eip155:84532 --print-only
# {"scheme":"exact","network":"eip155:84532","asset":"0x036CbD53…",
#  "amountAtomic":"300000","priceUsd":"0.3","payTo":"0x9a66…95A5"}

Can a client verify the server's contract before paying?

Yes — the 402 body the client validates is part of the machine-readable API contract. The server's committed openapi.yaml carries the x402 components (X402PaymentRequired, X402PaymentRequirement, X402HonestRefusal) with x402Version: 2, the scheme enum, extra.decimals: 6, and charged: false pinned as consts; a CI drift-check fails if the spec drifts from the live routes. The same contract is verified on both sides of the wire.

Dogfooding caught us too. On the same October 10 run, our catalog declared eip155:5042002 (Arc testnet) while the live 402 offered only Base Sepolia (eip155:84532) — the default Arc-only allowlist refused the offer until we passed --network explicitly. Our own validator flagged our own catalog drift, which is exactly the kind of failure you want a validator to cause.

This is C18 in the Arc Campaign series. Previously: Never Charged for a No — the machine-checkable refusal contract.

Links: Service catalog · openapi.yaml · llms.txt · @agentbadge/circle-payments · AgentBadge

Don't certify. Measure.

Don't Trust Us — Check the Chain: Public Verification for AI Agent Verdicts

Paul Spread — Tue, 13 Oct 2026 22:16:31 +0000

This article originally appeared on the AgentBadge blog.

What happens if we lie to you? Not a bug — a lie. The verdict endpoint says "approved," the signature is ours, the JSON looks right. If verification means "ask the issuer whether the issuer is honest," the answer is worthless by construction. The only honest design is one where the issuer's own claims are checkable by a stranger with an RPC endpoint and no faith in the issuer at all.

That is what we shipped for every verdict our evaluator signs. Each paid response now carries its own verification receipt — links and a deterministic memo id — and every claim in that receipt re-verifies on-chain through a standalone package that never calls our API. If our server disappears tomorrow, the proofs still check.

How do you verify a verdict through the public API?

One GET, no auth: GET /api/verify/:verdictId returns the stored verdict artifact, machine reason_codes, the per-verdict memo anchor state (status, memoId, txHash, blockNumber), the hash-chain status (anchored/pending/disabled with a head_ref pointer for offline recomputation), and a proof_kinds registry summary. Unknown id → 404 verdict_not_found; it never answers a fake-valid.

The response is layered by design. ?kind=verdict returns only the verdict layer (artifact + memo anchor); ?kind=anchor-head returns only the chain layer; ?kind=witness answers implemented:false — the kind is declared in the registry so verifiers can feature-detect it before it ships. Ask for an unregistered kind and you get 400 unknown_proof_kind with the full known list, not a silent fallback.

What does the /verify page do?

It is the same check for humans: a server-rendered page at /verify that accepts a verdict id, an anchor transaction hash, or a memo id — all 0x-prefixed 64-hex strings — and resolves which one you pasted via the anchor reverse-lookup. It renders the verdict, the reason codes, the anchor status with an explicit pending banner when the on-chain write has not landed, explorer links, and JSON-LD metadata — all without JavaScript, so it works in curl and in an agent's text browser.

Honest statuses are the point. An unanchored verdict renders "pending," never "valid." A malformed id is a 400, a well-formed unknown id is a 404, and the page tells you which of the two happened.

How do you verify without trusting AgentBadge at all?

Run the standalone package. @agentbadge/verify-verdict re-checks everything against the chain itself — the memo contract at 0x5294E9927c3306DcBaDb03fe70b92e01cCede505 on Arc, no call to our API, no account, no key:

npx @agentbadge/verify-verdict 0x<verdictId-or-txHash>
# exit 0 — every executed proof passed (VALID, or VALID partial when a declared layer isn't implemented yet)
# exit 1 — invalid, unanchored, or a typed error (rpc_unavailable)

Each run produces a proofs[] report — one entry per layer, each ok:true/false plus detail:

verdict — the per-verdict memo anchor exists at memoIdFor("eaas", verdictId) and its memo data equals keccak256 of the canonical artifact JSON (pass the artifact via --artifact for the tamper check).
anchor-tx — the memo event lives inside the transaction you supplied and is bound to the supplied verdictId; a bare txHash with no verdict id exits 1 (no verdictId supplied), rather than matching some other verdict's anchor.
anchor-head — the periodic epoch anchor at memoIdFor("chain", "eaas-verdicts", epochSeq) binds (headHash, count, prevAnchoredHeadHash), chaining epochs.
chain-recompute — feed it the chain entries (--entries) and it folds them locally: a broken entry fails with firstBrokenSeq, a verdict absent from the entries fails honest-invalid.

Every verdict we sign lands in that hash chain at issue time, and the head flushes on-chain per epoch — so the Level-2 verifier answers the only question that matters: is the thing the server showed me the thing the chain holds?

verify-verdict 0x4af3… --artifact verdict.json --entries chain.json
# proofs: verdict ok | anchor-head ok | chain-recompute ok | witness skipped (declared, not implemented)
# VALID (partial) — exit 0

What is the proof-kind registry?

A versioned enum of every on-chain proof the verification surface understands. PROOF_KINDS_V1 declares three kinds — verdict, witness, anchor-head — each with its memo format, the verifier rule for ok:true, and a specVersion for negotiation. The registry is itself the contract: a verifier can enumerate what exists, check which kinds a deployment supports, and fail loudly on an unknown kind rather than skipping a layer it was asked to verify.

The witness kind is the telling entry. It is declared — with memo format and rule stub — but returns implemented:false, because the witness layer (independent attestations per job) is still shipping. A registry that lists unimplemented kinds lets third parties build against the future surface today, and lets anyone see the full honesty map: what is checkable now, what is declared, and what would be a lie if we claimed it early.

What does "pending" mean — and why is there no fake-valid?

Because a verification surface that lies is worse than none. Anchor writes are fire-and-forget after the verdict issues — the paid response returns instantly, and the memo lands on-chain asynchronously. Until it lands, every surface says pending: the API's anchor.status, the page's banner, and the package's verdict proof (ok:false, detail says no memo events found). When our RPC dies, the package throws VerifyError("rpc_unavailable") and exits 1 — an honest "cannot determine," never a shrug stamped VALID.

The inline receipt makes the pending state useful rather than invisible. The paid response's verify:{api, page, memoId} block carries the deterministic memo id computed from the verdict id — a client can start polling the chain for its own anchor the moment the response arrives, without waiting for a second API round-trip.

This is C16 in the Arc Campaign series. Previously: The x402 Bazaar — a service catalog machines can shop. Next: Never Charged for a No — the machine-checkable refusal contract.

Links: Verify API · Verify page · openapi.yaml · llms.txt · @agentbadge/verify-verdict · AgentBadge

Don't certify. Measure.

37 Ways to Break Our Contracts, and Why None of Them Work Anymore

Paul Spread — Mon, 12 Oct 2026 07:16:21 +0000

This post is part of the Arc Campaign series (C28) on agentbadge.xyz.

On October 10, 2026 we pointed an AI auditor at the AgentBadge contract pack and told it to be mean. It found 37 findings across identity and escrow — seven of them High, including a fully transferable "soulbound" passport and an escrow operator who could rotate themselves into the payout seat. On October 11, all eight contracts went live on Arc mainnet as hardened UUPS proxies with zero open findings.

How do you audit contracts without a security firm?

We used Arc Studio — Circle's server-side AI builder — as an adversarial auditor. Not a linter, not a checklist: a max-preset adversarial prompt that required a runnable forge PoC for every finding before it counted as a finding at all.

The prompt discipline mattered more than the model. Three rules did the heavy lifting: hunt specific bug classes (access-control bypasses, role confusion between cross-referencing contracts, upgrade/rotation gaps), produce an executable proof-of-concept test for each claim, and don't touch the source — audit only, recommended fixes as diff sketches. Two packs, two reports: identity/passport contracts (VULN-01..21) and escrow/marketplace (VULN-1..16).

The auditor-earned-its-fee numbers:

Identity pack: 21 findings — 7 High, 7 Medium, 6 Low, 1 informational
Escrow pack: 16 findings — including 3 Critical-class (operator rotation, poster self-release, global platform fee)
Every finding shipped with a forge PoC that compiled and demonstrated the behavior — no "might be exploitable" hand-waving

What were the worst things it found?

The kind of bugs that don't show up in unit tests because the tests were written by the same happy-path brain that wrote the code.

Transferable identity (High) — AgentPassportNFT had no _update override, so passports — our ERC-8004 identity documents — were fully transferable. An issued identity could be sold or stolen; holder ≠ verified identity. Fixed with the soulbound _update guard.
Operator rotation trap (Critical) — the escrow operator could be swapped in one call. Two-step proposeOperator/acceptOperator plus a zero-address revert closed it.
Poster self-release (Critical) — the task poster could call release directly. Now release is 2-of-2: poster approves, operator executes.
Zero-address log DoS (High) — constructing with log_ == address(0) silently bricked every mint, revoke and attest call forever. initialize now reverts on zero.
Revoked-slot lockout (High) — revoking a pass poisoned its passOf slot; a subsequent mint took the renewal branch on a dead token. Irrecoverable — until we made the renewal branch check !revoked[id].

Three findings were rejected with disproof PoCs — the auditor flagged "NFT owner race" and "pay() shrinks release window," and the same PoC discipline showed the invariants hold. A good audit closes bugs; a great one also kills false alarms.

What does "hardened" actually mean on-chain?

Same eight contracts, rewritten underneath. Every contract is now a UUPS upgradeable proxy (ERC1967Proxy subclass AgentBadgeProxy), with _authorizeUpgrade gated behind UPGRADER_ROLE, _disableInitializers() in every constructor, and 50-slot storage gaps for future layout.

The behavioral fixes on top:

REVOKER_ROLE — server operator can revoke a compromised pass without touching the admin key
redirectClaimer — a claimer key rotates itself without an operator roundtrip
platformBps timelock — fee changes are propose → 48h → commit; no instant fee rug
xHolds — escrow holds keyed by a separate uint256 space; an NFT tokenId can never collide with a taskId
MIN_DEADLINE_OFFSET = 1h — deposits must leave operators time to work
CLASS_FULL_COVERED whitelist — a FULL pass covers MEDIUM+HEAVY, not "every future class bit" (the audit caught CLASS_EAAS leaking through)
_emitLog in try/catch — a dead event log can't DoS escrow settlement

The full list is 33 fixes across Critical/High/Medium/Low — every one with a regression test. Final suite: 197 tests green.

What's it like auditing with Arc Studio?

Practically useful, with sharp edges worth documenting.

What worked. One well-specified prompt per run beat iterative chatting — the agent wrote PoCs, ran forge tests, and assembled the report itself inside the sandbox. The PoC requirement is the killer feature: it converts audit output from opinions into reproducible evidence. Cost was ~3% of the daily budget per pack audit; the whole engagement (two packs + re-audit) fit comfortably inside a week of quota.

What to watch. Arc Studio is testnet-only — all mainnet deploys stayed on our hardhat/chain-cli path. Its outputs are agent-generated, not attested: we re-verified every finding locally before fixing, and three findings turned out to be false positives. And the audit prompts are worth keeping under version control — ours live in scripts/arc-studio/prompts/ (audit-identity.txt, audit-escrow.txt), so the next run is reproducible.

Net: an AI auditor doesn't replace a security firm for mainnet money. But for "find the bugs your own tests were blind to," it earned its tokens.

How did the deployment go?

Two chains, one idempotent script, ~0.9 USDC total gas.

deploy-arc-v2.ts deploys an implementation, wraps it in AgentBadgeProxy, calls initialize with the right params (USDC, treasury, operator, platformBps), and records every address in deployments/{network}-v2.json. Run it twice and it skips what exists — which we proved unintentionally when the first mainnet run was interrupted halfway: the resume deployed only the missing three.

Arc testnet (5042002): 8/8 proxies, full write-path smoke PASS (registry → badge → passport → passes → escrow deposit/approve/release)
Arc mainnet (5042): 8/8 proxies, read-only sanity PASS — writer → passport, escrow usdc/operator/log, splitter bps=1000/treasury

Contract	Mainnet v2 proxy
AgentEventLog	`0x20387070057178e9629dd6c9037c52487f090a90`
TrustRegistry	`0x0b56d876fa0b11742e8139b0291fa5080912a222`
TrustBadge	`0xebcb3adb5f7def429e9c3254bcbe6cd46aef2821`
AgentPassportNFT	`0x1f2426b102f57ecfeac2ab75c3fd853493f00a76`
AccessPassNFT	`0x8e254abfd8e4691b11f8553fb9a9f180a248982f`
MarketplacePassNFT	`0x6e408672e56001dc24a5db68107f9abf900f87e5`
TaskEscrow	`0xc58dd0890a8a186b651cd02f34af629c8cc91d53`
MarketplaceSplitter	`0x69043c847e9ee79b7128ec6d280f5f25fc76aba9`

We checked the v1 contracts first (decision D-196-5): two marketplace passports and nothing else, all owned by our deployer — no external holders — so v2 is a clean restart, not a state migration. The v1 addresses stay frozen as read-only history.

Who can upgrade these contracts?

Today, the deployer EOA — with a documented exit. UPGRADE-GOVERNANCE.md lays out the migration: when the first real USDC lands in TaskEscrow, UPGRADER_ROLE moves to an OZ TimelockController (≥24h delay) whose proposer/executor is a multisig. A queued malicious upgrade becomes cancellable inside the timelock window.

The reasoning is simple: an upgrader key is god — one compromised key swaps in a hostile implementation and repoints every reference. Day-to-day roles (MINTER, RECORDER, REVOKER, OPERATOR) deliberately carry no upgrade power.

Don't certify. Measure.

Source and deploy ledgers live in the agentbadge repo. Series index: agentbadge.xyz/blog.

One POST Gets Your Agent an On-Chain Passport — No Wallet, No USDC, No Waiting

Paul Spread — Sat, 10 Oct 2026 15:51:14 +0000

One POST Gets Your Agent an On-Chain Passport — No Wallet, No USDC, No Waiting

Originally published: https://agentbadge.xyz/blog/arc-c20-self-serve-registration
Tags: erc8004, arc, ai-agents, web3

Registering an agent for ERC-8004 identity used to mean a deploy script, a funded key, and a block of your afternoon. As of this week it means one line:

curl -X POST https://agentbadge.xyz/api/v1/agents/register \
  -H "content-type: application/json" \
  -d '{"name":"my-agent"}'

The 201 that comes back carries three things at once: an agent_id anchored to a freshly minted NFT in the canonical ERC-8004 IdentityRegistry on Arc (eip155:5042:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432:<tokenId>), the mint transaction hash, and an agb_… API key that already works — shown exactly once, stored on our side only as a SHA-256. No account, no form, no approval queue.

This is article 20 in the Arc Campaign series. C14 was about how agents find each other; C27 covered how a platform proves its own identity. C20 is the missing middle: how a third-party agent gets an identity at all — and how we kept the door open without letting the bots walk through it.

What does one POST actually return?

POST /api/v1/agents/register accepts {name} plus optional endpoint, capabilities, description. The response is the whole onboarding record: agent_id in eip155:<chainId>:<registry>:<tokenId> form, registry_tx you can open in the Arc explorer, agent_uri — a base64 data-URI containing the EIP-8004 registration-file JSON itself — an api_key, the tier assigned (observer), the keyed free-tier limits it gets, and a next_call hint pointing at GET /api/v1/agents/me.

Two details worth the bytes they cost. First, agent_uri is a data-URI, not an IPFS hash: the registration file travels inside the mint calldata, so the agent's metadata is anchored in the same transaction as the NFT — no pinning service, no second dependency, hard-budgeted at 2 KB with a truncated marker if oversized fields get shed. Second, the mint runs through a dedicated ops signer (ARC_OPS_KEY) with a hard gas cap, not a treasury master key — the key that pays for your passport can do exactly one thing.

What do you get with the observer tier?

The agb_ key lands you on the first keyed rung of a seven-level trust ladder — observer in /api/meta/trust-tiers. It's keyed rate limits, not a discount: anonymous callers get 1 request/minute on the free-tier surface, a bearer key gets 10. Paid surfaces still run through x402 for everyone — observer is identity, not a coupon.

The key itself is deliberately boring: agb_ plus 32 bytes of base64url, hashed with SHA-256 before it touches a store. GET /api/v1/agents/me returns the public record — agent_id, registry tx, tier, limits, registration timestamp, and for sponsored registrations the owner address — and DELETE /api/v1/agents/me self-revokes, busting the 60-second auth cache on the spot. If the key leaks, the key dies; the passport on-chain is unmoved because the key was never the passport — it's just a rate-limit handle pointed at it.

How do you keep a self-serve door from being farmed?

Three guards, ordered by cost to the honest caller — cheapest check first.

Per-IP daily cap. A regcap:<ip>:<day> bucket (default 20 mints/day, backed by the shared cache with an in-memory fallback, 48-hour TTL) trips before any chain work happens: 429 register_rate_limited. When the cache backend is down the counter fails open — we'd rather absorb a burst than take registration down with a dependency.

Honest failures, never fake records. If the mint reverts, the route returns 502 execution_failed and persists nothing — no half-written agent_ids pointing at tokens that don't exist. And if the feature isn't configured, the routes return 503 rather than pretending to work. The same honest-zero discipline from C17 applies to onboarding.

A kill-switch that actually kills. DELETE /api/v1/admin/agents/:agentId marks the record revoked and busts the auth-cache entry in the same call — a revoked agb_ key returns 401 agent_key_revoked on its very next request, not up to a minute later. Self-revoke uses the same cache-bust path. Instant revocation is what makes a permissionless front door safe: whatever gets in can be put back out in one call.

Can an agent register without USDC for gas?

Yes — that's the part of this launch we expect to matter most. Send {name, owner, signature} instead of plain {name}: owner is the EOA that should own the passport, signature is the owner's EIP-191 signature over a registration intent binding the chain id, registry address, owner, and agent name. The server verifies the signature, then its ops wallet does two calls — register() to mint, transferFrom(ops → owner) to hand the NFT over. The passport lands in the owner's wallet and the treasury pays the gas. The requester never needs USDC, never needs a funded key — only the ability to sign a message.

The sponsored path has its own budget — a global sponcap:<day> bucket (REGISTER_SPONSORED_DAILY, default 50/day) returning 429 sponsored_quota_exceeded — and the check order is deliberate: per-IP regcap first, signature verification second, sponsored budget last. Farming signatures is pointless if you can't get past the same IP cap everyone else answers to, and burning our daily sponsored budget still leaves the free self-pay path open. Registration records stamped sponsored:true carry owner and ownerTx in /me, so the handoff is auditable after the fact.

Honest status

Shipped across five slices over four days, all against the canonical IdentityRegistry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on Arc (eip155:5042): the store + key model; the route with real ERC-8004 mint; bearer-key auth middleware with observer-tier enrichment; the sybil guards and admin revoke with instant cache-bust; and the sponsored relayer with EIP-191 intent verification and its own daily budget. Test coverage: 30/30 unit tests and 9/9 e2e green on the registration surface — including signature round-trips with real viem accounts, the 429 cap ordering, and the revoke-before-next-request timing.

Two honest limits to name. The self-pay path still needs the server to pay mint gas — it does; "self-serve" means you don't sign a transaction, the treasury eats a ~80k-gas mint per registration at current Arc fees, which is why the caps exist. And the legacy POST /agents/register from the Hedera-directory era still exists under its own name — the new route lives at /api/v1/ precisely so the two never collide.

Try it

# Register (self-pay path — treasury pays your mint gas)
curl -s -X POST https://agentbadge.xyz/api/v1/agents/register \
  -H "content-type: application/json" \
  -d '{"name":"probe-agent","endpoint":"https://example.com"}' | jq .

# Use the returned key immediately
curl -s https://agentbadge.xyz/api/v1/agents/me \
  -H "authorization: Bearer agb_<your-key>" | jq .

# Sponsored path (owner = your EOA, signature = EIP-191 intent over
# "agentbadge:register:v1\neip155:<chainId>\n<registry>\n<owner>\n<name>")
curl -s -X POST https://agentbadge.xyz/api/v1/agents/register \
  -H "content-type: application/json" \
  -d '{"name":"gasless-agent","owner":"0x<your-eoa>","signature":"0x<sig>"}' | jq .

Verified live — the first production registration happened while writing this article:

POST /api/v1/agents/register → 201
{
  "agent_id": "eip155:5042:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432:2332",
  "registry": "erc-8004",
  "registry_tx": "0x78dd4d11ea3c6c95e78afc0f9a078da875d21b615050c07d6c3bdf909ed9d3cb",
  "tier": "observer",
  "api_key": "agb_…"
}
GET /api/v1/agents/me (Bearer agb_…) → 200

Externally reviewed — beyond our own tests:

Testnet dry-run on Arc testnet (5042002): self-pay + sponsored mints, /me auth, negative paths — tokens 897222/897223 (mint).
Arc Studio adversarial review audited the module → REQUEST CHANGES: replayable sponsored intents + racy JSON store (2 critical), plus treasury-budget, IP-trust, mint-orphan, auth-cache findings.
All critical/high fixed and re-verified on testnet: intents are now 10-minute single-use signatures, store writes are mutex-serialized, the sponsored budget fails closed, and header-spoofed IPs collapse into one shared rate bucket.

Mint tx on Arc mainnet: https://explorer.arc.io/tx/0x78dd4d11ea3c6c95e78afc0f9a078da875d21b615050c07d6c3bdf909ed9d3cb (437,174 gas, block 25270327 — paid in USDC by the treasury).

Source: server/lib/agent-registration/{register,intent,sponsored-gate,public-view,store}.ts, route in server/routes/agents-register-api.ts — agentbadge repo
Tests: tests/agent-registration-api.test.ts (unit, incl. EIP-191 verify), tests/e2e/agent-registration.test.ts (full cycle incl. sponsored + caps)

What's next

Registration answers "who are you" — the next slice answers "prove it". Ownership-verification rails (per-agent codes, DB-level exclusivity on (type, locator, network)) are already specced as 184-7: claim a domain, X handle, or Substack publication and you prove it before it can route payouts. Our own domain goes through the same rail via /.well-known/agentbadge-verify.txt — no special-casing ourselves.

This is C20 in the Arc Campaign series. Previously: Who Are You, Agent? A DID Your Domain Can Prove.

Links: Trust tiers · Error catalog · llms.txt · Verification policy · AgentBadge

Don't certify. Measure.

Proving a Verdict Exists Is Easy. Proving Nothing Was Deleted Is Not.

Paul Spread — Fri, 09 Oct 2026 14:19:10 +0000

A signed verdict lands in a hash, the hash lands on-chain — and a week later that same verdict still verifies. That's the easy part. The question nobody asks a paid evaluator is the uncomfortable one: how do you prove you didn't quietly drop the verdicts that made your score look bad? Existence proofs don't cover completeness. An archive can be honest about everything it shows you while lying about what it removed.

This week we closed that hole on AgentBadge's evaluation layer: every verdict now extends a linear hash-chain, and the chain's head is anchored to the Arc Memo contract on a heartbeat — even when nothing new ships. Anyone with a curl can recompute the head themselves and compare it to what's on-chain. No trust in our API required.

Why Isn't Per-Verdict Anchoring Enough?

Because it answers the wrong question. Each verdict gets a memo anchor — memoId = keccak("eaas:verdictId") with the artifact hash on-chain. Point at a verdict, check the anchor, done. But anchoring proves each entry independently. Delete entry 47 of 200 and every remaining anchor is still valid. The proof set has a hole shaped exactly like the verdict you deleted.

This is the same gap certificate-transparency ran into: RFC 6962's original design proved inclusion, not consistency — Microsoft's ADR-0017 rewrite added signed tree heads precisely because "the log showed me the cert" is not "the log shows everyone the same history." An evaluator without consistency guarantees is a marketing claim, not an evidence source.

How Does a Linear Hash-Chain Fix Deletion?

Every verdict append writes a ChainEntry: entryHash = keccak256(prevHash ‖ artifactHash) — each entry cryptically married to its predecessor, pinned to a genesis hash. Edit an entry's content, its hash breaks. Delete an entry, the next one's prevHash dangles. Insert one, the sequence number and link both fail. The whole chain verifies in one O(n) fold, and verifyChain reports the exact first broken sequence — not just "invalid", but where.

Our store is a JSON file, deliberately. The threat model isn't a hardened database — it's that any replay of history diverges from the anchored head. Mutability accepted; detection guaranteed.

What's the Heartbeat Anchor For?

Liveness. A chain that only anchors when it has new work silently downgrades during quiet periods — no anchor means "unknown", not "unchanged". So createChainFlusher anchors the head every ARC_CHAIN_FLUSH_MS (default 24h), new entries or not:

New entries → anchor the fresh head.
Empty window → re-anchor the same headHash with epochSeq + 1. Heartbeat, RFC 6962's signed-tree-head pattern: the log asserts "my state at time T is this" so an operator can't fork and serve different views to different auditors.
Restart after a missed window → immediate catch-up flush.

Each anchor is one memo(self, 0x, memoId, memoData) call — memoId = keccak("chain:eaas-verdicts:<epoch>"), memoData the ABI-encoded (headHash, count, prevAnchoredHeadHash). O(1) on-chain cost per window regardless of verdict volume.

What Can a Third Party Verify Without Trusting Us?

Everything, via three free rate-limited endpoints — an RFC 9162-inspired proof surface:

GET /api/eaas/chain → {domain, headHash, count, lastFlushAt, chainOk, anchor:{epochSeq, txHash, blockNumber, explorerUrl}, chainId}
GET /api/eaas/chain/entries?from&to&limit → paged ChainEntry[] (cap 100)
GET /api/eaas/chain/proof/:verdictId → {seq, path, head} — inclusion suffix
GET /api/eaas/verdicts/:id/verify → gains chain:{included, seq?, headHash}

The audit recipe, no SDK, no account:

# 1. pull the inclusion proof
curl https://agentbadge.xyz/api/eaas/chain/proof/0x<verdictId>
# 2. fold it yourself: h = path[0].prevHash;
#    for each entry: h = keccak256(h ‖ e.artifactHash)
# 3. compare with the on-chain Memo event for
#    memoId = keccak("chain:eaas-verdicts:<epochSeq>")

If your fold hits the anchored headHash, the verdict is provably inside the history the operator attested. If the operator serves you a rewritten store, the fold lands on a different hash than the anchor and the lie is arithmetic, not opinion.

How Is This Different from Rekor or Predge?

Rekor-style transparency logs anchor software supply chain artifacts with Merkle trees — a general log for anyone's blobs. Predge-style agent chains attest signed calls: proof that a proxy relayed a request/response pair. Ours chains verdicts — the semantic evaluation artifact itself — inside the same API that issues them, and ships a public proof surface rather than a query console.

Three differences that matter: one entry per priced verdict (not per HTTP call); heartbeat epochs + chainOk expose deletion and silent windows; linear fold beats Merkle when proofs are suffixes — a verifier needs entries after the target, nothing before.

The trade is real: linear scans are O(n) not O(log n). For an append-heavy verdict log where audits fetch suffixes, that's the right-sized data structure.

Try It

Buy a verdict for a cent: bun run examples/eaas-client.ts --endpoint https://agentbadge.xyz --policy deliverable-present. Then pull its proof and fold it — the arithmetic either matches the chain head or it doesn't. The code: hackathon/server/src/server/lib/eaas/chain*.ts, and the dogfood: scripts/eaas-chain-dogfood.mts (3 verdicts → force flush → real Memo event on Arc testnet).

Don't certify. Measure.

Part of the Arc Campaign series. Previous: payer binding — who paid.

An Agent Lands on Your Homepage — What Can It Actually Read?

Paul Spread — Fri, 09 Oct 2026 09:14:53 +0000

An AI agent evaluating a vendor does what a human does: it opens the site and looks for proof. The difference is speed and format — the agent gives you seconds, not minutes, and it wants JSON, not hero banners. Until recently, an agent landing on agentbadge.xyz found a page built for humans and nothing else — while our own readiness scanner was grading other sites on exactly the signals we lacked. The cobbler had no shoes. We fixed that: the entire discovery surface is now generated from live sources, served free with no auth, and verified by our own scanner in CI.

What does an agent find in 200 milliseconds?

Eleven machine-readable manifests, all 200 OK, all free, all generated — not hand-maintained:

/.well-known/agent-card.json        A2A v1.0 — who we are, skills[]
/.well-known/api-catalog            RFC 9727 linkset — every API entry
/.well-known/erc8004-agent.json     on-chain identity registration
/.well-known/mcp/server-card.json   MCP capabilities + tools surface
/.well-known/agent-evaluation.json  verification ladder (claims→refs)
/.well-known/owner-questions.json   "who runs this" for due-diligence
/.well-known/did.json               did:web:agentbadge.xyz document
/.well-known/did-configuration.json signed domain linkage (VC-JWT)
/.well-known/jwks.json              real Ed25519 key, kid'd
/.well-known/security.txt           RFC 9116, Expires generated +1y
/llms.txt                           agent-oriented sitemap

The agent-card alone answers the A2A handshake: name, provider, supportedInterfaces[], skills[] with tags and examples, and securitySchemes declaring x402 as the payment rail. One GET and a foreign agent knows our identity, capabilities, and how to pay.

Where do the manifests come from?

Not from a copywriter — from the code itself. A manifest registry collects the same live sources the runtime uses (openapi.ts, route config, blog-data.ts, the SKU catalog), and every manifest is a projection of that truth:

Boot-time: env-dependent manifests generate into a manifest registry at server start; routes serve from it — one source.
Build-time: bun run gen:discovery writes snapshots under public/.well-known/; manual edits are banned.
CI drift-check: regenerate + git diff --exit-code — if a manifest drifted from code, the build fails.

Ours cannot go stale without the build telling us.

What does a machine-readable sitemap look like?

llms.txt — the de-facto convention for telling an LLM "start here": H1 title, a blockquote describing the platform, ## sections of named links. Ours is generated with machine-readable entry points, quick start, free and paid endpoints — and the services section anchors into the same /api/v1/services catalog that powers the bazaar extension on every 402.

Why serve the same page twice?

Because the reader might not be a browser. Accept: text/markdown on any page returns the markdown representation — verified live:

$ curl -sH "Accept: text/markdown" https://agentbadge.xyz/blog
content-type: text/markdown; charset=utf-8

Blog articles carry .md mirrors too (/blog/arc-c10-payer-binding.md → 200 text/markdown). HTML stays canonical; <link rel="alternate" type="text/markdown"> points machines at the twin.

Can an agent verify our claims without trusting us?

agent-evaluation.json — a verification ladder: claims ordered by check-time, each with action + ref:

{
  "depth": "5s",
  "checks": [
    { "claim": "mainnet deployment — AgentEventLog on Arc",
      "action": "open",
      "ref": "https://explorer.arc.io/address/0x1bb6…4700" }
  ]
}

5s: we exist on-chain and publish a card. 60s: manifest validity, live OpenAPI, refusal contract. Deeper: dogfood txs and audit trails. owner-questions.json answers enterprise due-diligence (operator, jurisdiction, contact) in the same shape.

How do we know it works?

We run our own scanner on ourselves — the same 142-rule engine that grades foreign sites: mcp/server-card.json (AB-006), llms.txt (AB-014), JSON-LD/OG (AB-015/016), ai.txt (AB-017) — against agentbadge.xyz in CI. 100% pass required. A broken manifest fails our own product's grade on our own domain.

Honest status

Live: all 11 manifests 200, markdown negotiation serving text/markdown, .md mirrors on articles — generated, not hand-edited.
Deliberately absent: ai-plugin.json (ChatGPT Plugins EOL 2024 — dead manifest is cargo cult); /.well-known/agent.json → 301 to agent-card.json.
Verify now: curl https://agentbadge.xyz/.well-known/agent-card.json — or scan us: npx agentbadge-scan agentbadge.xyz.

C14 in the Arc Campaign series. C15 continues — the agent found us, now it reads the price list.

Originally published at agentbadge.xyz.

A txHash Is a Bearer Token — We Bound Ours to the Wallet That Paid

Paul Spread — Thu, 08 Oct 2026 20:08:46 +0000

A txHash Is a Bearer Token — We Bound Ours to the Wallet That Paid

On Arc's self-settle payment rail the buyer broadcasts the USDC
transferWithAuthorization themselves and hands the server the
transaction hash as proof. Convenient — and a bearer credential:
the txHash sits in the public mempool before it confirms, and whoever
presents it to the paid endpoint first gets the content. We closed
that hole on every AgentBadge paid surface with agentbadge-pay:v1 —
a one-line signature binding a payment transaction to the wallet that
made it, verified before the replay slot is ever touched.

Can someone else spend your agent's payment?

On the self-settle rail, yes — if the endpoint only looks at the
txHash. The attack is Attack I-B from the x402 threat analysis
(arXiv:2605.11781) and it's mechanical: your agent pays, a sniper
reads the txHash out of the mempool, builds its own
PAYMENT-SIGNATURE pointing at your transaction, and races you to the
server. First presenter wins the replay slot — your money buys their
answer.

The txHash is proof a payment happened. It is not proof the request
came from the payer.

What does payer binding actually check?

Three headers — X-Wallet, X-Sig, X-Timestamp — carrying an
EIP-191 signature over a canonical challenge:

agentbadge-pay:v1
wallet:<payer, lowercase>
method:POST
path:/api/eaas/verdicts
payref:<txHash, lowercase>
timestamp:<unix seconds, ±300s>

The check runs before payment verification — order matters,
because verification is what burns the replay slot:

inspect() the receipt claim-free — read the USDC Transfer log, extract the on-chain from. A rejection never poisons the payment.
Recover the challenge signer; compare to X-Wallet and the on-chain payer. A valid signature over someone else's txHash is still a rejection — that's the snipe.
403 WRONG_SIGNER (or 402 payer_binding_required when headers are absent on a txHash payload). Gateway/exact payments carry no txHash and skip binding.

The e2e proves the ordering: attacker's request → 403, seenTxHashes
empty; legit request → 200; third call → replay-402. Slot lifecycle
intact.

How does an agent pay with binding enabled?

Every 402 advertises it — extensions.payerBinding and
accepts[].extra.payerBinding carry {required: true, challenge: "agentbadge-pay:v1"}. Spec: https://agentbadge.xyz/payer-binding.md.

import { buildPayerChallenge, signPayerChallenge } from "@agentbadge/circle-payments";

const timestamp = Math.floor(Date.now() / 1000);
const signature = await signPayerChallenge(account, {
  wallet: account.address, method: "POST",
  path: "/api/eaas/verdicts", payRef: txHash, timestamp,
});
// + headers: x-wallet, x-sig, x-timestamp next to payment-signature

How do you verify a bound request yourself?

No trust in us required. recoverMessageAddress over the canonical
challenge yields X-Wallet; the txHash's Transfer(from,to,value)
log gives the on-chain payer. Mismatch = snipe attempt, valid
signature or not.

Why a signature and not a redeem token?

The redeem_token pattern (two-phase quote → pay → redeem) closes the
same hole but costs a second round-trip plus a server-side token
store. Ours is stateless — replay dedup already existed, the binding
rides inside the same request. A sniper holding your txHash can't
produce a signature naming itself payer of that tx — the on-chain
from won't match.

Honest status

Live behind PAYER_BIND_ENABLED (off until funded dogfood) across
five paid surfaces — EaaS, marketplace, scan-packs, keeperhub, bstock
— with per-group kill-switch PAYER_BIND_DISABLED_GROUPS.
scripts/payer-bind-dogfood.mts replays the full attack on testnet:
victim pays, attacker replays the txHash → 403, victim's bound request
→ 200, retry → 402 replay.

ENDPOINT=https://agentbadge.xyz \
PAYER_KEY=0x... ATTACKER_KEY=0x... \
bun run scripts/payer-bind-dogfood.mts

C10 in the Arc Campaign series. Earlier: C15 made every 402
self-declaring; C4/C13 built the wallet controls this binding sits
behind.

Originally published at agentbadge.xyz.

Your Agent Shouldn't Have to Guess the Price — One Catalog, Declared on Every 402

Paul Spread — Thu, 08 Oct 2026 08:24:13 +0000

Originally published: https://agentbadge.xyz/blog/arc-c15-x402-bazaar

An agent buying from an API answers three questions before it pays: what does it cost, what do I send, is there a free way to try? Most payment-gated APIs make it guess all three. We closed that loop: GET /api/v1/services returns the full machine-readable catalog, and every 402 across the platform declares itself for x402 indexers — price, input schema, free alternatives, before a cent moves.

One registry, three consumers

The catalog isn't a hand-maintained list — it's a declarative SKU registry reading the same config sources the payment middleware reads. The price in the catalog IS the price the gate charges. One registry feeds /api/v1/services, the bazaar extension on every 402, and the llms.txt Paid Services section.

14 SKUs across 8 paid surfaces: scans, passport mints, marketplace buys, keeperhub, EaaS verdicts/jobs/subscriptions, bstock passes, venue subscriptions. sku_id is surface:slug, immutable — a golden test fails CI on rename.

Every 402 declares itself (bazaar)

Every payment gate — x402 Hedera, MPP/Stripe, bstock freemium, the manual settle seam, all three EaaS middlewares — attaches bazaarExtensionFor("<sku_id>"). The emitted inputSchema is inputSchemaOf(sku), byte-equal to the catalog entry. One function produces the schema — catalog and wire can't drift (D-179-4).

Even the L402 macaroon gate is accounted for — it lives on an explicit exception list (no JSON slot) instead of pretending.

Free as the front door

free[] sits next to services[]: health, scan-packs catalog, market browsing — each with a next_call pointer to the natural paid step. Discovery → free trial → paid call, zero doc reading.

No paid endpoint without a declaration

tests/e2e/catalog-coverage.test.ts keeps a GATE_TABLE — every gate ↔ SKU both directions. A new paid route without a SKU fails CI. The two non-SKU gates (l402, attestation-api) are an explicit allowlist with written reasons.

curl -s https://agentbadge.xyz/api/v1/services | jq '.services[].sku_id'

Full article with decoded 402 payloads:
https://agentbadge.xyz/blog/arc-c15-x402-bazaar