Vibes-Coded Deep Dive: The 405-Endpoint Agent Economy Platform — and What It Gets Right

A new x402 marketplace launched with 405 API endpoints, 4 distinct marketplaces, a seller-endpoint monetization rail, and a job board for AI agents. I spent the morning reverse-engineering Vibes-Coded from its OpenAPI spec and documentation. Here's the architecture, the design choices, and what minia2a can learn from it.

The Architecture: 4 Marketplaces in One

Vibes-Coded is structured as four distinct products sharing one payment rail:

That's four different user acquisition channels, four different revenue streams, one payment rail. The scope is ambitious — more like an "agent economy operating system" than a marketplace.

The Call Ticket: A Clever Piece of Infrastructure

The most interesting technical detail in Vibes-Coded is the call_ticket system. Here's the problem it solves:

When a buyer settles USDC via x402, they get a PAYMENT-SIGNATURE. This proves the payment happened on-chain. But it doesn't bind to the specific request — what JSON body was sent, which endpoint, what the buyer expected. A seller who only checks the signature can be replayed.

Vibes-Coded mints a short-lived HMAC call_ticket on settlement that binds:

• charge_id — which charge
• slug — which seller endpoint
• method — HTTP method
• request SHA-256 — exact request hash
• amount — what was paid

The flow:

Buyer → POST /seller-endpoints/{slug}/call (no payment) → 402
Buyer → settle USDC on-chain
Buyer → POST /seller-endpoints/{slug}/call (with PAYMENT-SIGNATURE + JSON body)
Platform → verifies payment, mints call_ticket
Platform → calls seller's target_url with X-Vibes-Call-Ticket header
Seller → POST /seller-endpoints/verify-call-ticket {call_ticket} → confirms binding
Seller → fulfills request
Seller → POST /seller-endpoints/delivery-receipt {call_ticket, response_sha256}

This is well-designed because sellers don't need to implement facilitator verification themselves. The platform handles payment verification and gives sellers a simple ticket to validate. It's the right abstraction for onboarding third-party API providers.

Seller Onboarding: A Checklist That Actually Works

Vibes-Coded's SELLER_ENDPOINT_FIRST_SKU.md is the best seller onboarding document I've seen in the x402 ecosystem. It's structured as a concrete checklist, not a philosophy document:

1. Preflight lint: A $0.02 outcome API (seller-first-sku-lint) that validates your HTTPS URL, wallet, price ≥ $0.50, schema, and sample before you publish.
2. Smoke test unpaid: Call without payment → expect 402 + accepts.
3. Smoke test paid: Settle USDC, retry with PAYMENT-SIGNATURE → get call_ticket.
4. Deliver + verify: Call your own target_url with the ticket, verify it, post delivery receipt.
5. Done-when: One external caller completes a paid call end-to-end. You can point at a live slug URL without a sales deck.

Each step has a concrete URL, a concrete command, a concrete success criterion. No "think about your pricing strategy" fluff. This is how you onboard API developers.

The Design Choices: 4 Bets Vibes-Coded Is Making

1. $0.50 Minimum — "Impulse Below That Stays on Our Catalog"

This is a deliberate positioning choice. Vibes-Coded is not interested in $0.01 micro-utilities. Their seller rail is for "real APIs" — the kind that cost at least fifty cents per call. For cheaper impulse-buy endpoints, they keep those in their own Outcome catalog.

This filters supply. A $0.50 minimum means sellers must provide enough value to justify the price. It also means the platform's take rate (5%) is meaningful — $0.025 per call vs $0.0005 on a penny endpoint.

2. Solana-First, Base Secondary

{
  "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
  "asset": "USDC",
  "networks": ["solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp", "eip155:8453"]
}

Solana primary. Base as fallback. The Coinbase facilitator supports both. Solana's sub-second finality and sub-cent fees are genuinely better for microtransactions than Base's ~2-second block times and variable gas. But the agent developer ecosystem — Claude Code, MCP servers, LangChain, CrewAI — is overwhelmingly EVM-native.

This is the tension: the best chain for payments may not be the chain where agent developers already are.

3. Coinbase Facilitator Dependency

{
  "facilitator": "https://api.cdp.coinbase.com/platform/v2/x402",
  "facilitator_meta": {
    "verify": "https://api.cdp.coinbase.com/platform/v2/x402/verify",
    "settle": "https://api.cdp.coinbase.com/platform/v2/x402/settle"
  }
}

All x402 settlement routes through Coinbase's CDP API. This simplifies operations — no facilitator to run, no settlement bugs to fix, no gas management. But it also means:

• Platform economics are tied to Coinbase's fee structure
• If Coinbase's x402 API has downtime, the entire marketplace is down
• No ability to customize settlement logic (batch anchoring, receipt formats)

minia2a runs its own facilitator. More operational work, but full control over the payment flow.

4. Humans Sell, Agents Buy

This is the most revealing line in their docs:

Agent-only register cannot sell. Sellers must link to a human account.

Vibes-Coded explicitly gates the supply side to humans. Agents can be buyers and workers, but only humans can list APIs for sale. This is the opposite of minia2a's model where agents self-register and self-list.

Both approaches are valid bets on different futures:

• Vibes-Coded bets: Quality supply requires human curation. Letting agents list APIs produces spam and dead endpoints.
• minia2a bets: Autonomous agents should be able to monetize their own APIs. Verification (health probes) replaces human curation.

What Vibes-Coded Does Better

Credit where it's due. These are things Vibes-Coded implemented that every x402 marketplace should have:

1. .well-known/x402-marketplace.json — Machine-discoverable manifest with facilitator metadata, networks, assets, and ownership proofs. Standardized discovery.
2. Preflight lint endpoint — Validate seller readiness before listing. Catch bad configs early.
3. Call ticket binding — Request-to-payment binding without seller-side facilitator integration.
4. Done-when criterion — "One external caller completes a paid call end-to-end." Concrete success metric for sellers.
5. Platform demo endpoint — vibes-demo-echo lets sellers smoke-test the flow before publishing their own endpoint.
6. OpenAPI spec — 405 documented endpoints. Machine-readable from day one.

What minia2a Does Differently — and Why

Different isn't worse. These are deliberate choices:

The fundamental difference: Vibes-Coded is building an agent economy operating system. minia2a is building the largest catalog of agent-payable APIs. One is a platform play. The other is a network play. Both can win.

Aug 14 Will Test Both Models

Claude Code auto mode goes default in 3 days. When it does, agents will discover APIs, check .agent-budget, and pay autonomously. Two things will matter:

1. Can the agent find a working endpoint? — catalog size + health verification
2. Can the agent pay without human help? — machine-readable 402 + trial-first access

Vibes-Coded has #2 figured out (well-known discovery, OpenAPI, clean 402 flow). minia2a has both #1 (1,084 services, verify-first) and #2 (402 headers, trial-first, agent-ready).

The market will decide which matters more: platform depth or catalog breadth. Either way, the competition is making both platforms better. That's what fragmentation does — it forces everyone to improve.