When I tell developers "we have an API," they assume Bearer tokens, OAuth, and a pricing page that hides the real number behind "Contact Sales."

Today we shipped something different. The same daily Bitcoin cycle data, on-chain indicators, and aggregated strategy insights are now reachable through three channels — REST, MCP, and x402 pay-per-call in USDC on Base. No account required for the third one. An AI agent can find the endpoint, get a HTTP 402, sign a one-line USDC authorization, retry, and have the data three seconds later. No human in the loop.

Here's what's actually live, why we built it this way, and what it cost us in real engineering hours.

What's live, in one table

The REST and MCP channels share one subscription and 42+ endpoints. The x402 channel exposes a focused subset (13 endpoints today): 8 daily snapshots at $0.01 USDC each — Arena Pulse score, BTC cycle phase, Altcoin Season, Fear & Greed, Mayer Multiple, funding rates, hash ribbons, bullmarket gauge — and 5 aggregated insights at $0.05 each.

You can browse the full surface at tradingstrategies.work/openapi.json. The x402 endpoints carry an x-x402 extension with their price, network, and asset, so an autonomous agent can discover them without reading any docs.

Why three channels?

Different consumers want different things.

A human developer building a trading dashboard wants a stable API key, a free tier, and predictable monthly pricing. That's REST.

A user of Claude Desktop or Cursor wants their LLM to call the data directly without leaving the chat. That's MCP — same authentication, different transport. One subscription covers both.

An autonomous agent — the kind that spends its own treasury and has no way to sign up for accounts — wants to pay per call. No subscription, no commitment, no payment-info on file. It signs an EIP-3009 TransferAuthorization, and the facilitator settles on Base. The agent never sees a checkout page. Total settlement time: a few seconds.

This is the bet behind x402 — HTTP 402 was always in the spec, it just never had a payments protocol attached. Now it does. Coinbase donated the protocol to the Linux Foundation in April. Multiple facilitators exist. The plumbing is real.

The Coinbase Detour That Cost Us a Day

The original spec said "Coinbase Facilitator." That's the path of least resistance: their hosted endpoint at pay.openfacilitator.io is free, well-documented, and Apache-2.0 licensed. We pointed our code at it. Configured the wallet. Built the endpoints. Smoke-tested.

It worked perfectly on Base Mainnet. It failed instantly on Base Sepolia testnet with a RouteConfigurationError.

Reason: OpenFacilitator's public hosted endpoint is mainnet-only. Their /supported endpoint advertises eip155:8453 (Base Mainnet) and Solana. It does not advertise eip155:84532 (Sepolia). The x402 resource server validates against this list at boot. If the combo isn't supported, the server crashes.

This is a subtle thing the docs didn't surface. We switched to xpay.sh for our dev environment (their facilitator supports both Sepolia and Mainnet, free, no signup) and kept OpenFacilitator for production. The total code change to swap facilitators: zero lines. Just an environment variable.

That's the design we wanted: facilitator-agnostic by construction. If xpay.sh ever charges fees we don't like, we point at a different one. If OpenFacilitator's hosted instance goes down, we self-host. If the protocol diverges, we replace the whole @x402/next dependency without touching our service layer.

We also discovered Coinbase Developer Platform signup is currently restricted to the United States and Singapore — a hard blocker for us as a DACH-based operator. So even if we had wanted CDP, we couldn't have used it. The facilitator-neutral approach turned out to be load-bearing.

What an agent's "first paid call" actually looks like

Here's the full flow for an autonomous agent fetching today's Arena Pulse score, observed by curl:

# Step 1: agent makes naive GET
curl -sI https://tradingstrategies.work/api/v1/agent/arena-pulse/today

HTTP/1.1 402 Payment Required
Cache-Control: public, max-age=0, must-revalidate
Content-Type: application/json
Payment-Required: eyJ4NDAyVmVyc2lvbiI6Mi...  # base64 x402v2 payload

The Payment-Required header decodes to a JSON shape with accepts[] listing the supported schemes:

{
  "x402Version": 2,
  "accepts": [{
    "scheme":  "exact",
    "network": "eip155:8453",
    "amount":  "10000",
    "asset":   "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo":   "0xe09D11aC5a07c050FC2073684a6bCD4c10c0aAD6",
    "maxTimeoutSeconds": 60,
    "extra":   { "name": "USD Coin", "version": "2" }
  }]
}

amount: 10000 is in atomic USDC (6 decimals). The asset is Circle's native USDC on Base — not bridged. The agent signs an EIP-3009 TransferAuthorization for $0.01 USDC from its wallet to ours, then retries with an X-PAYMENT header. The server submits the signature to the facilitator, the facilitator verifies and broadcasts, the chain settles, the agent gets a 200 OK with the data and an X-PAYMENT-RESPONSE header containing the transaction hash.

Gas? Sponsored by the facilitator (we lose nothing on either side). Total round-trip: typically 2-4 seconds.

Honest caveats

If you're building an autonomous agent and consider x402, three things are worth knowing.

Volume economics. A $0.01 call has roughly $0.005 of settlement overhead and $0.001 of Vercel compute. Margins are tight at the bottom tier. Higher-priced endpoints ($0.10+) are healthier. We deliberately priced for adoption, not for margin.

Receipt logging is server-side. Every settled payment writes a row to our agent_api_requests table with the transaction hash, payer wallet, endpoint, and amount. If your agent ever needs to reconcile what it spent on our endpoint, you can verify it on-chain (payer, transaction, and amount are all public on Base).

This isn't financial advice. All data we expose is historical aggregations. The fact that a strategy had a 53% win-rate in High-Volatility BTC days last quarter does not mean it will tomorrow. Use this for context, not for orders.

What this isn't

It's not a real-time market feed. Daily snapshots, refreshed by morning cron.

It's not a trade-execution layer. We give you market context. Your agent's order routing is its own problem.

It's not a flexible "pay any amount" gateway. Each endpoint has a fixed price. Universe backtests and custom reports (where the per-call cost scales with the workload) will come in the next phase.

What's next

Phase 4's MVP is 13 read-only endpoints. The next phase opens the trigger surface: POST endpoints for running custom backtests, ordering custom reports, and triggering grid-bot simulations — each priced by the work involved. That work is roughly one more day of code and one open question (how to surface async-job polling to x402 callers cleanly).

Beyond that: more publishers, more readers. We've already submitted ourselves to a handful of MCP registries (Lobehub, Cline, Smithery). The x402 ecosystem listings are next. If you're building an AI agent that needs market context — try the snapshots. They cost a cent each. We promise no marketing emails.

The full API surface, including curl examples, lives at tradingstrategies.work/api. The skill card for autonomous discovery is at /skill.md. The OpenAPI spec is at /openapi.json.

---

Built solo from Germany/Austria. No VC, no team. Just one developer and a database that's been ingesting daily Bitcoin indicators since 2009. If you want to know more about how this got built in 70 hours, the meta-stack is here.

Study the Past — Improve your Future.