The state of agent commerce readiness: three audits, three different shapes of unfinished

TL;DR

We ran the AgentCrush Agent Commerce Readiness Audit against three projects sitting at different points along the agent-commerce stack: aixbt (Virtuals Protocol's marquee crypto-intelligence agent), Coral Protocol (an agent infrastructure platform with ERC-8004 wired in), and Daydreams / Lucid Agents (an agent-commerce framework). The three audits surface the same pattern at three different intensities.

aixbt is production-grade live — .well-known set, OpenAPI, MCP server card, x402 endpoint settling USDC on Base — with the gap on the trust side. Coral has built more agent-commerce wiring than most teams we'll audit (ERC-8004 manifest block, x402 budget primitives, typed marketplace API) but the default x402 service is a no-op stub and nothing is yet on a public discovery surface. Lucid Agents is one of the better-shaped agent-commerce frameworks shipping today — x402, A2A, AP2, and ERC-8004 as first-class composable extensions — but daydreams.ai itself publishes no .well-known/x402, no agent card, no ERC-8004 file, and the canonical x402 example targets Base Sepolia.

The meta-finding across all three: most teams in agent commerce are 80% built and 20% published. The constraint on the next phase of the agent economy is not protocol design — it is protocol exposure.

Why we ran three audits

AgentCrush is the market intelligence layer for the agent economy — protocol-neutral, evidence-ranked, no favorites. We do not build the rails. We track who has shipped what across x402, ERC-8004, MCP, A2A, AP2, Agentverse, Stripe ACP, Virtuals, and the rest of the stack, and we publish the gaps in plain language.

Case Study #3 is the third in our public series demonstrating the Agent Commerce Readiness Audit methodology that backs Labs Offer 1. The first two — the x402 discovery post-mortem and the first cross-protocol agent — audited our own infrastructure and one third party (CrewAI). This one widens the lens to three projects at once, on public data only, without permission or coordination. Every claim is cited. If anything is wrong, the evidence trail is here for the audited teams or anyone in the community to correct.

We picked three projects deliberately. aixbt is the most-followed crypto-native AI agent on X and the Virtuals Protocol flagship — a useful test of whether high social visibility coincides with finished agent-commerce wiring. Coral is one of only two confirmed cross-protocol agents in the AgentCrush index by ERC-8004 attribution and has been visibly building toward agent commerce. Daydreams is the framework most commonly cited next to x402 in Coinbase DevRel channels, with stated focus on agentic commerce.

The point is not to rank them. The point is to make the spectrum legible.

Methodology

The Agent Commerce Readiness Audit covers seven areas. For each we document a finding, the evidence (with URLs or file:line references), a severity rating, and a recommendation:

1. Discovery — can an agent find this project?
2. Understanding — can an agent parse its API?
3. Payment — can an agent pay it?
4. Verification — can an agent verify what it received?
5. Trust — can a counterparty trust it?
6. Default judge model disclosure (tool-backed: tools/audit/primitives/default_judge_model_disclosure.mjs)
7. Prioritized roadmap and skip-list

One of the seven primitives is currently tool-backed; six are expert review against the published audit framework — the same shape that will be tool-backed as additional primitives ship through the Field Lab.

A note on self-correction. During this audit run we found and patched a known false-positive shape in the tooled primitive: default_judge_model_disclosure matched on eval keywords inside a JSONPath parser (packages/core/src/parsing/jsonpath.ts in the Daydreams source tree) where eval is a parser method name unrelated to model evaluation. The primitive returned undisclosed when the substantive answer is not_applicable. We have logged the shape and tightened the primitive's match rules to exclude JSONPath / JSON parsing contexts. The methodology improves in public.

The comparative table

A single view of the three projects across all seven areas. Severity ratings in parentheses; severities are project-internal — they describe distance from agent-commerce readiness, not absolute quality.

The three rows read the same column three different ways: the wiring is in (or mostly in), the publishing is not.

Audit 1 — aixbt: the positive baseline

aixbt by Virtuals is best known to humans as the @aixbt_agent X account and to machines as one of the most fully-instrumented agent commerce surfaces we have audited. The audit reads positively because the evidence warrants it; the remaining gaps are real and worth naming.

Headline finding. aixbt has shipped the unglamorous wiring that lets other agents transact against it without human intervention. Discovery, understanding, and payment are all simultaneously live, well-documented, and usable. The remaining gaps are on the trust and verification side: no ERC-8004 identity registration we could locate, no signed-evidence wrapper on paid responses, no public reputation surface beyond the X account.

Discovery. aixbt publishes a .well-known/api-catalog linkset declaring the locations of the OpenAPI spec, MCP server card, agent-skills index, and a portable agent skill. The MCP server card at aixbt.tech/.well-known/mcp/server-card.json is a valid mcp-server-card/v1.json schema instance with transport streamable-http. OAuth2 authorization-server and protected-resource metadata are also published. The x402 payment endpoint returns the extensions.bazaar.discoverable: true flag. The single discovery gap: CDP Bazaar does not yet include api.aixbt.tech in the top 500 — the Bazaar indexes after first successful settlement, so this likely lags rather than fails. (Minor)

Understanding. aixbt publishes a full OpenAPI v3.0.0 spec at api.aixbt.tech/v2/openapi.yaml covering 15+ paths with typed schemas. The documentation corpus mirrors to docs.aixbt.tech/llms-full.txt and llms.txt for agent-readable consumption. A portable skill.md describes surface selection rules and core data primitives. The OpenAPI defines an UpgradeMeta schema embedded in responses, declaring upgrade.protocol: x402 and upgrade.payment: USDC on Base — a machine-readable upsell hint. (None)

Payment. Production-ready. POST https://api.aixbt.tech/x402/v2/api-keys/1d returns HTTP 402 with a v2 PAYMENT-REQUIRED header. Decoded payload:

{
  "x402Version": 2,
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "10000000",
    "asset": "0x833589fCD6EDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0x8e4b195c14f20e1ba4c40234f471e1781f293b45",
    "maxTimeoutSeconds": 300
  }],
  "extensions": { "bazaar": { "discoverable": true } },
  "spec": "https://github.com/coinbase/x402/blob/main/specs/x402-specification-v2.md"
}

Base mainnet (chain id 8453), 10 USDC for a 1-day pass, canonical Base USDC asset, real payTo on chain. Published pricing: 1d/$10, 1w/$50, 4w/$100. Free /v2/grounding endpoint returns 200 without a key. (None on the payment primitive itself.)

Verification. Weak. OpenAPI defines response shapes but no field is named signature, attestation, evidence, proof, hash, or nonce across the spec. The MCP server card declares no signed-response capability. For consumer use the absence is irrelevant; for agent-to-agent commerce where a buyer agent wants to assert "aixbt told me X at time T," the burden falls entirely on the buyer's logging. (Moderate)

Trust. Partial. aixbt has substantial social trust and verified ERC-20 contracts on three chains (Base 0x4F9F...A825, Ethereum, Solana). It does not have a discoverable ERC-8004 identity registration we could locate. We searched the ERC-8004 surface and the AgentCrush index for "aixbt" and matching contract addresses; we did not find a registration. We do not claim one does not exist — we claim we could not find one. (Moderate)

Ship now (three)

1. One ERC-8004 identity registration on Base. One transaction, one static JSON file. Converts social trust into machine-portable trust.
2. Signed evidence wrapper on paid responses. {signature, signed_at, signer_address} header signed by the payTo wallet. ~1 day. Unlocks composable agent commerce.
3. Static .well-known/x402 manifest + one self-test settlement. ~1 hour. Catches conventional-path crawlers and surfaces in CDP Bazaar.

Skip today (two)

• TradFi identity stack (Experian, Visa, Skyfire) before on-chain identity exists.
• A bespoke /reputation endpoint on aixbt's own domain — once ERC-8004 is live, the reputation and validation registries are the right surface.

What we did not test: did not settle a real x402 payment end-to-end (verified shape and asset only). Did not authenticate against the MCP tools/list (no paid key). Did not inspect closed-source components — @aixbt/cli, the API backend, the Indigo chat endpoint, the recipe execution engine. Did not verify payTo operator identity beyond published docs. Did not audit Virtuals Protocol agent NFT or Genesis Launch mechanics.

Audit 2 — Coral Protocol: scaffolded, awaiting the live endpoint

Coral Protocol is an agent infrastructure platform — "Kubernetes for AI agents" in their framing — that has been visibly building toward agent commerce. The AgentCrush index links Coral to ERC-8004 token #9634 ("AgentLab", Ethereum mainnet) on the basis of a name match against Coral's AgentLab product reference. As we explain in the self-correction section below, that linkage does not survive primary-source verification. The audit is against Coral Protocol's published surface regardless of who controls token #9634.

Headline finding. Coral has done more agent-commerce wiring than most teams we'll audit. None of it is live on the public surface yet. The default X402Service is a no-op stub. Marketplace discovery is local-only in v1.1. Settlement is configured for Solana. An agent that finds Coral cannot actually transact through x402 today.

Discovery. Partial. docs.coralos.ai/cloud/using-api documents GET /api/v1/registry and GET /api/v1/registry/{source}/{agentName}/{version} — all bearer-token gated. No .well-known/x402 on coralos.ai (404). No matching listing in api.cdp.coinbase.com/platform/v2/x402/discovery/resources at audit date. (Moderate)

Understanding. Strong. The agent manifest format (coral-agent.toml) is documented in src/test/resources/agent/coral-agent.toml of Coral-Protocol/coral-server with explicit field constraints: lengths, semver, base58 wallet patterns, URI schemes, runtime types, MCP transport types (mcp_sse, mcp_streamable_http), and authentication shapes. OpenAPI specs are referenced (api_v1.json, v1-openapi.json, discovery-openapi.json) but were not retrievable at the implied URLs during audit. (Minor)

Payment. Scaffolded, not live. src/main/kotlin/org/coralprotocol/coralserver/payment/BlankX402Service.kt defines the default service as a no-op:

class BlankX402Service : X402Service {
    override suspend fun executeX402Payment(...): Result<X402PaymentResult> { ... }
}

X402BudgetedResource.kt and X402ProxyRequest.kt define the budget and proxy request shapes. PaymentConfig.kt:31–39 exposes x402WalletName and x402Wallet. build.gradle.kts declares implementation("org.coralprotocol.payment:blockchain:0.1.1:all") — 0.1.x, early stability. Per docs: "remote execution and payouts are currently disabled in v1.1.0" and "if you enable marketplace discovery, treat pricing as metadata only." Settlement chain per Coral docs is Solana, distinct from the Base-centric x402 graph CDP Bazaar currently indexes. (Critical)

Verification. Unknown from public data. Coral's session API documents that agents send results back via custom webhook tools rather than synchronous responses, with the response schema application-defined per session. No canonical evidence-bundle format described. (Moderate, with a knowledge gap.)

Trust. Partial. RegistryAgentMarketplaceSettings.kt:37 defines erc8004: RegistryAgentMarketplaceIdentityErc8004? = null. RegistryAgentValidation.kt:569–593 validates wallet (base58, 25–32 bytes) and endpoints (name + URL pairs). Coral's chosen endpoint shape is a simplification of the canonical EIP-8004 agent-card endpoint set — it does not distinguish the canonical types (mcp, a2a, web). Not wrong, but limits interop with cross-protocol indexers that key on canonical types. (Moderate)

Ship now (three)

1. One live paid x402 endpoint on Base mainnet (or a chain CDP Bazaar currently indexes). Even a $0.005 USDC registry-list endpoint. ~1 day given the existing X402Service interface.
2. Static .well-known/x402 on coralos.ai. ~1 hour. Highest signal-to-effort ratio in the roadmap.
3. Canonical ERC-8004 endpoint type alignment. Normalize erc8004.endpoints[].name against the canonical set (mcp, a2a, web). ~2 days including a manifest migration.

Skip today (two)

• TradFi-side trust stack before the ERC-8004 anchor has a live reputation surface.
• Multi-chain x402 settlement before any single chain is live.

What we did not test: did not test paid x402 settlement end-to-end (no Coral endpoint accepts real payments today). Did not inspect Coral Cloud's authenticated API responses (no API key). Did not read on-chain tokenURI for token #9634 byte-for-byte. Did not audit the org.coralprotocol.payment:blockchain package internals (binary dependency). Did not review the Coral Marketplace UI or closed-beta features.

Audit 3 — Daydreams / Lucid Agents: the publishing gap, named

Daydreams is the agent framework most commonly cited next to x402 in Coinbase DevRel channels. The first surprise of the audit was a subject-scoping one: the daydreamsai/daydreams repository README opens with a maintainer notice:

"This agent framework is no longer the core focus as features are already obsolete. The Daydreams core focus is on Agentic Commerce and not the agent harness."

It points users at daydreamsai/lucid-agents. We therefore split the audit: Areas 1, 2, and 7 cover the Daydreams public brand surface; Areas 3, 4, and 5 audit Lucid Agents in detail; Area 6 runs the primitive against both code trees.

Headline finding. Lucid Agents is one of the most agent-commerce-native frameworks we have audited. x402 payments, A2A, AP2, and ERC-8004 identity ship as first-class composable extensions. The CLI scaffolds a working monetized agent in one command. Every scaffolded agent gets an auto-generated /.well-known/agent-card.json and an optional /.well-known/agent-registration.json. And yet daydreams.ai itself publishes none of it — no .well-known/x402, no agent card, no ERC-8004 registration file, no CDP Bazaar listing. The canonical x402 example targets Base Sepolia, not mainnet. The wiring is in. The publishing is not.

Discovery. Weak. curl -sI https://daydreams.ai/.well-known/x402 returns HTTP/2 404 (Netlify-served). curl -sI https://daydreams.ai/x402.json returns 404. The CDP Bazaar discovery payload returns no items matching daydreams, dreams.fun, or lucid. The framework auto-generates /.well-known/agent-card.json for every scaffolded agent; the vendor domain does not host one. (Critical)

Understanding. Strong on the SDK, weak on the public site. packages/api-sdk/codegen.ts generates a TypeScript SDK from an OpenAPI spec via @hey-api/openapi-ts. Scaffolded agents serve curl http://localhost:3000/.well-known/agent-card.json and curl http://localhost:3000/entrypoints out of the box. No equivalent schema is served from daydreams.ai. (Minor at SDK level / Moderate at brand level)

Payment. Scaffolded and well-shaped. daydreamsai/daydreams/examples/x402/nanoservice/server.ts:

import { paymentMiddleware, type Network } from "x402-hono";

const facilitatorUrl = "https://facilitator.x402.rs";
const payTo = (process.env.ADDRESS as `0x${string}`) ||
  "0xb308ed39d67D0d4BAe5BC2FAEF60c66BBb6AE429";
const network = (process.env.NETWORK as Network) || "base-sepolia";

Default network is base-sepolia (testnet, chain ID 84532). @lucid-agents/payments documents x402 micropayments, persistent storage, and bi-directional payment policies. AP2 is a first-class extension (createAgentCardWithAP2(), merchant/shopper role declarations). No live, paid x402 endpoint operated by Daydreams was discoverable at audit date. (Moderate)

Verification. Partial. Lucid Agents ships typed Zod input/output schemas per entrypoint, SSE streaming, task-based operations with status tracking and cancellation. The ERC-8004 identity package exposes a validation registry client (packages/identity/src/registries/validation.ts, structurally compatible with the canonical ERC-8004 validation registry) but the framework does not wire it into the default paid-entrypoint response shape. Example output is { output: { message: '...' } } — no signed receipt. (Moderate)

Trust. Strong, with one important caveat. packages/identity/README.md documents three registry clients (identity, reputation, validation), ownership-transfer via the underlying ERC-721 is supported, identity wires into the agent manifest via getTrustConfig(identity). The identity package is at version 3.0.0 — maintained, not abandoned. The caveat: documented CHAIN_ID=84532 (Base Sepolia) default. A reputation built on Sepolia is a testnet reputation. (Moderate)

Ship now (three)

1. Static .well-known/x402 on daydreams.ai pointing to one paid endpoint. Under 1 hour. Highest signal-to-effort ratio in the roadmap.
2. One live paid x402 endpoint on Base mainnet for the Dreams Router. ~1 day given existing scaffolding. Converts the Sepolia example into a mainnet proof point.
3. Flip identity-package documentation defaults from Sepolia (CHAIN_ID=84532) to Base mainnet (CHAIN_ID=8453). Move Sepolia into a "for local development" callout. ~half a day.

Skip today (two)

• TradFi-side trust stack before ERC-8004 has a publicly visible reputation read-out.
• A vendor MCP server for Daydreams itself before the vendor publishes a .well-known/x402 file. Ship discoverability first.

What we did not test: did not test paid x402 settlement end-to-end (no Daydreams-operated mainnet endpoint). Did not mint or transfer an ERC-8004 identity through the Lucid Agents CLI. Did not inspect Dreams Router authenticated responses (no account). Did not audit the pi-mono harness the maintainers recommend (separate project, out of scope). Did not verify the OPENAPI_URL env-var driven build target.

The pattern across all three: the publishing gap

Three projects, three different starting points, one shared pattern.

aixbt has done the publishing work. Coral has not. Daydreams has not. The wiring quality varies — Lucid Agents has arguably the most coherent agent-commerce architecture we have audited, ERC-8004 wired as a first-class concept rather than a marketing claim, three composable registry clients in the identity package, AP2 shipping alongside x402 — and it still trails aixbt on the readiness spectrum because the architecture is invisible to an agent crawler. The architecture does not matter if no machine can find it.

The gap is small and well-shaped. For Coral, one live paid endpoint and one static .well-known/x402 file would move the project from "scaffolded" to "discoverable" in a week. For Daydreams, three static files on daydreams.ai — .well-known/x402, an agent card, an ERC-8004 registration JSON — would do the same in under an engineering day. For aixbt, the next layer up: one ERC-8004 mint, one signed-response header.

This is now a recognizable category. Teams shipping agent-commerce infrastructure today have done the hard architectural work for traffic that is two-to-four quarters out. The constraint on the next phase of the agent economy is not protocol design; it is protocol exposure. The teams who ship one paid endpoint plus one .well-known file in the next month will be the teams agent crawlers find. Everyone else will be discoverable only by humans Googling them.

There is a reason this pattern repeats. Protocol design has been the loud, expensive work for the past year — ERC-8004 standardized through three drafts, x402 v2, AP2, A2A, MCP, Skyfire, Kite. Publishing is the quiet, cheap work that turns those protocols into a live ecosystem. It is also the work nobody gets credit for. We think the next quarter belongs to the teams who do the boring publishing work first.

aixbt is the proof point that the work is finishable. The remaining two are well-positioned to follow. The pattern is the story.

What this audit run also surfaced in our own index

Two things we found by running these audits, both about AgentCrush rather than the audited teams. We name them here because the methodology is "self-correction in public" and this is what self-correction looks like.

Index attribution: token #9634 to Coral. The AgentCrush index links the ERC-8004 token #9634 ("AgentLab", Ethereum mainnet) to Coral Protocol on the basis of a name match against Coral's AgentLab product reference. On primary-source verification, the linkage does not survive: the on-chain owner is 0xcf03760479225d3d258e634f8bd85c8965980c11, the tokenURI metadata is generic boilerplate with no Coral-namespaced endpoint set, and x402Support: false. We could not independently verify on public data that this token was minted by the Coral team. We are demoting the linkage to evidence-tier marketplace-reported rather than verified onchain, tightening the AgentCrush cross-protocol matching rules to require a primary-source signal beyond name match before promoting an attribution to evidence-ranked, and reflecting both in the next index refresh. The Coral audit above is against Coral Protocol's published surface regardless of token #9634 attribution.

Audit primitive: false-positive on JSONPath eval. During the Daydreams audit run the default_judge_model_disclosure primitive returned undisclosed against daydreamsai/daydreams. Manual verification showed the match was on eval keywords inside packages/core/src/parsing/jsonpath.ts — a JSONPath parser where eval is a method name unrelated to LLM-as-judge evaluation. The substantive answer for both Daydreams and Lucid Agents is not_applicable (neither repo ships an eval surface). We have patched the primitive to exclude JSONPath / JSON parsing contexts from the match set. The primitive is one of seven bundled into Labs Offer 1 and the patch ships with it.

Neither finding makes the audited teams look worse. They make AgentCrush look more honest. The point of doing audits in public on public data is that the methodology improves where everyone can see it.

What we did not test (combined)

This audit is bounded to public surface area. Across the three subjects we did not:

• Settle a real x402 payment end-to-end for any of the three (we verified 402 shapes, asset addresses, and payTo for aixbt; the other two have no live mainnet endpoint we could settle against).
• Authenticate against any of the projects' paid surfaces — no API key was purchased for any audit.
• Inspect closed-source components — aixbt's API backend, @aixbt/cli, the Indigo chat agent; Coral Cloud's authenticated API responses; Dreams Router authenticated responses; the org.coralprotocol.payment:blockchain binary dependency.
• Read every ERC-8004 token on every chain by hand. We searched public registries and the AgentCrush index for each subject's known names and matching contract addresses and recorded the absence where one was found.
• Audit related but distinct subjects — Virtuals Protocol agent NFT mechanics, the Coral Marketplace UI, the pi-mono harness, third-party closed-beta features.
• Mint or transfer an ERC-8004 identity for any of the three.
• Verify operator continuity between known on-chain addresses (e.g., the aixbt payTo wallet and the AIXBT token contract operator) beyond the inference from published documentation.

Where evidence was not verifiable from public data, the audit says so explicitly. Anything any of the three teams ships after this audit date is naturally out of scope.

Want one of these for your project?

The Agent Commerce Readiness Audit is Labs Offer 1. Same methodology, same seven areas, applied to your stack with a prioritized roadmap and an explicit skip-list.

• $299 for startups (5–8 page report).
• $1,000+ for an implementation roadmap with cost/effort estimates.
• Custom for build support.

See /labs for the full offer, or reply to any of our public channels.

All audits conducted on public data only between 2026-05-13 and publish date. Every claim above cites evidence — fetched URLs, file:line references, decoded x402 payloads, or on-chain reads. Corrections welcome from any of the audited teams or anyone in the community — we will update inline with attribution.