the402 Emerging

Name: Agent Native Offer Audit — the402
Item: the402
Rating: 75
Author: Agent Native Offers

AUDIE Score: 75/100 · Audited 2026-04-07 · Website: https://the402.ai · Machine-readable: JSON

Pillar Scores

P1 Signal Architecture — 23/25

P2 Clarity Stack — 18/25

P3 Trust Envelope — 11/20

P4 Velocity Triggers — 9/10

P5 Gravity Design — 14/20

Executive Summary

the402 is the most agent-native offer infrastructure found in any audit to date, scoring 75/100 (Emerging) — within striking distance of Agent-Ready. The platform's Signal Architecture is near-perfect: /llms.txt, /llms-full.txt, OpenAPI 3.1.0, /.well-known/the402.json, 31 MCP tools, and explicit AI crawler permissions in robots.txt represent a deliberate and sophisticated approach to agent discoverability. The platform's velocity triggers are best-in-class (9/10) — no friction, no human gates, $0.01 onboarding. The biggest gaps are in Trust Envelope: there is no public status page for an uptime-critical payments platform, no scoped agent permission tokens for multi-agent architectures, and no version-controlled terms. Closing those three gaps would push the402 to 85/100 (Agent-Ready) and position it as the reference implementation for what an agent-native offer infrastructure looks like.

Strongest Signals

Best-in-class Signal Architecture (P1: 23/25) the402 has done nearly everything right at the infrastructure layer. /llms.txt, /llms-full.txt, OpenAPI 3.1.0 spec, /.well-known/the402.json, 31 MCP tools, and explicit AI crawler permissions in robots.txt. This is the most complete agent-facing signal stack found in any audit to date.
Zero-friction activation (P4-A: 5/5) No registration required to transact. $0.01 optional registration. MCP in 2 minutes. This removes the #1 barrier for agent adoption — human gates. An autonomous agent can go from discovery to first purchase without any human involvement.
Full subscription renewal lifecycle (P5-C: 5/5) Complete programmatic renewal API with auto-cron, past_due state, retry logic, and expiration handling. Most platforms require human involvement for subscription management. The402 is fully agent-executable.
Machine-readable catalog with live pricing (P2-A: 5/5) GET /v1/services/catalog returns structured service data including price, speed, escrow model, and provider reputation. This is the gold standard for offer completeness — an agent can evaluate and compare all available services in a single API call.

Critical Gaps

No service substitution/fallback protocol (P2-C: 1/5) When a provider's webhook is unreachable or a service fails mid-execution, the agent receives an error but no documented alternative path. For autonomous agent workflows, unhandled service failure is a critical blocker. This is the single largest functional gap.
No public status page or verified uptime (P3-A: 2/5) Platform reliability claims are unverified. For an agent marketplace handling real USDC transactions, the absence of a public status page is a trust gap that will limit adoption by enterprise agent deployments.
No agent-scoped permission tokens (P3-B: 3/5) Payment-as-auth is elegant, but it provides no way for an agent orchestrator to grant a sub-agent bounded access (e.g., "spend up to $5 on this task"). Time-bounded, dollar-capped agent permission tokens would be a major unlock for multi-agent architectures.
No version-controlled terms or change policy (P3-D: 2/5) Pricing and terms could change without notice. For agents making long-running workflow decisions based on current pricing, undisclosed pricing changes create planning risk.

Priority Actions

Publish a public status page — +3 pts · P3 · Effort: Low
Build a service substitution / fallback protocol — +4 pts · P2 · Effort: Med
Introduce agent permission tokens (spending caps) — +2 pts · P3 · Effort: Med
Add AggregateRating and Offer schema.org markup — +1 pts · P1 · Effort: Low
Publish a terms versioning and change notification system — +2 pts · P3 · Effort: Low

All 20 Criteria

P1-A Structured Data — 4/5
Organization, WebSite (with SearchAction), and SoftwareApplication schemas confirmed on homepage via scrape. Missing Offer and AggregateRating schemas that would enable direct agent pricing inference and social proof evaluation.

P1-B Machine-Readable Pricing — 5/5
OpenAPI 3.1.0 spec published at https://api.the402.ai/openapi.json. Per-endpoint pricing embedded in API docs (e.g., /v1/register costs $0.01, /v1/services/catalog is free, /v1/threads/:id/inquire costs $0.001). Service catalog API returns live pricing data per listing. Best-in-class for machine-readable pricing.

P1-C llms.txt / Agent Layer — 5/5
/llms.txt confirmed present (referenced in robots.txt). /llms-full.txt confirmed at https://the402.ai/llms-full.txt with full API reference including all endpoints, parameters, and pricing. Purpose-built for LLM consumption.

P1-D API / MCP Availability — 5/5
OpenAPI 3.1.0 spec, 31 MCP tools via @the402/mcp-server (npm), /.well-known/the402.json discovery manifest, REST API at https://api.the402.ai. Full agent card + spec + MCP server — the complete stack.

P1-E Discoverability (GEO) — 4/5
robots.txt explicitly names and grants access to GPTBot, ChatGPT-User, ClaudeBot, Claude-Web, Google-Extended, PerplexityBot, Applebot-Extended, Bytespider, cohere-ai, Meta-ExternalAgent. Sitemap at https://the402.ai/sitemap-index.xml. Deducting 1 for limited AI search footprint as a newer platform.

P2-A Offer Completeness — 5/5
Machine-parseable catalog at GET /v1/services/catalog returns all services with type, price, fulfillment speed, provider reputation, and escrow model. Full offer picture available from a single free API call. Textbook agent-native offer completeness.

P2-B Scope & Limits — 4/5
Rate limits explicitly documented: 120 req/min for general /v1/* endpoints, 5/min for registration, 10/min for balance deposit, 3–10/min for auth. 429 responses include Retry-After header. Anti-gaming limits on referrals (10/day, $500/month cap). Minor deduction: no per-service or per-tier variation documented.

P2-C Substitution & Fallback Rules — 1/5
No explicit substitution or fallback protocol for service unavailability documented. When a provider's webhook is unreachable (503), the error is surfaced to the agent but no alternative routing or fallback service is offered.

P2-D Conditional Logic Transparency — 4/5
Payment conditions are machine-readable: human services require x402 (not balance), returning 400 if wrong method used. 402 response body includes "How do I pay?" guidance with provider reputation context. Payment-as-auth model explicit in /llms-full.txt. Subscription bypass for covered services documented. Minor deduction: edge cases (past_due state, retry behavior) documented in prose rather than structured format.

P2-E Semantic Precision — 4/5
Precise throughout: price ranges per service category with exact dollar amounts ($0.001–$1, $0.50–$10, $25–$1,000+), fulfillment times (< 5 sec, seconds–minutes, hours–days), 5% platform fee, 200ms settlement time, HMAC-SHA256 webhook signing, AES-256-GCM credential encryption. Occasional marketing phrase ("open marketplace") but non-obscuring.

P3-A Verifiable Performance — 2/5
/health endpoint returns platform status. Provider reputation scores (0–100) based on real job history provide service-level reliability signals. No public uptime status page or third-party verified SLA found. Settlement time self-reported at ~200ms. Score capped at 2 per evidence rule.

P3-B Scoped Permissions — 3/5
Payment-as-auth model scopes each transaction to exactly the amount authorized (per EIP-3009 signed transfer). Pre-funded balance model uses API key. Escrow protects agents from non-delivery. No explicit time-bounded, action-count-bounded, or dollar-cap-bounded agent permission tokens — which would push to 5.

P3-C Audit Trail — 4/5
Strong audit architecture: job_id correlation per transaction, request_id in all error responses, full thread history accessible via GET /v1/threads/:id, on-chain transaction hash returned in X-PAYMENT-RESPONSE header, HMAC-SHA256 signed webhooks with replay-attack protection (5-minute timestamp window). Machine-accessible via API. Deducting 1 because no dedicated agent-queryable "my transactions" history endpoint was found in docs.

P3-D Behavioral Consistency — 2/5
API versioned at /v1/ (stable namespace). Webhook signature format stable and documented. Subscription retry behavior (3 attempts over 72h) documented. No version-controlled ToS, no stated notice period for pricing changes, no public changelog found. Early-stage platform.

P4-A Friction-Free Activation — 5/5
No registration required for basic x402 purchases — any agent with a USDC wallet on Base can transact immediately. Optional registration is $0.01 (automated). MCP server installs in ~2 minutes from npm. Pre-funded balance path is ~5 minutes. No human gate, no approval process, no sales call.

P4-B Agent Decision Signals — 4/5
Free catalog at GET /v1/services/catalog includes: price, service type, fulfillment speed, provider reputation score (0–100), completion rate, confidence level, escrow model, category tags. Agents have strong programmatic signals for evaluation and selection. Deducting 1 because no explicit "try before you buy" free tier for paid services exists.

P5-A Integration Depth / Switching Cost — 3/5
On-chain wallet identity creates persistent agent identity across sessions. Thread history and reputation are tied to wallet address — switching to a competitor means starting reputation from zero. 31 MCP tools create workflow integration depth. Switching cost is real but not yet deep enough for 4+.

P5-B Agent Memory / Personalization Layer — 3/5
Thread-based conversation history persists across interactions and is API-queryable. Encrypted credentials stored in threads (AES-256-GCM). Reputation scores build per-wallet. No formal agent preference profile or recommendation layer documented.

P5-C Programmatic Renewal — 5/5
Full subscription renewal infrastructure: agent-executable subscription API, auto-renewal cron (every 30 minutes), past_due state handling with 3 retry attempts over 72-hour grace period, then expiration with 403 response. Entire lifecycle machine-executable without human intervention.

P5-D Compounding Value Signal — 3/5
Provider reputation scores compound from completed job history (real job-based multi-dimensional score). Agents can filter the catalog by reputation. Thread history builds context over time. No agent-facing "your usage history improves your results" value signal — compounding is on the provider side, not yet on the agent side.

Rubric v1 (April 2026). Scores reflect the company's state on the audit date and may have improved since.