CORTX
Reliability infrastructure for x402 — verify paid services actually deliver.
An x402 service can be online and still be broken: its payment terms are malformed, it takes the payment and returns nothing, or it returns something the caller can't use. CORTX makes controlled paid test calls against x402 services and records what happened at every stage — payment terms, price, payment, settlement, delivery and response schema — so builders catch failures before agents and users do.
Live at usecortx.dev. Built on Base, starting with Bankr builders.
How a check works
CORTX runs the open x402 Reliability Spec pipeline:
| # | Stage | What CORTX verifies | Pays? |
|---|
| 1 | Availability | The endpoint answers | No |
| 2 | 402 response | It asks for payment instead of answering for free | No |
| 3 | Payment terms | Terms parse, in x402 V1 (402 body) or V2 (PAYMENT-REQUIRED header), with a Base USDC option | No |
| 4 | Price | The price is valid and within the service's bounds | No |
| 5 | Payment | CORTX signs an EIP-3009 authorization, retries with X-PAYMENT (V1) or PAYMENT-SIGNATURE (V2), and reads the settlement receipt (PAYMENT-RESPONSE) — the transaction hash comes only from that receipt | Yes |
| 6 | Delivery | The paid response is a 2xx with a body | Yes |
| 7 | Schema | The body is JSON and matches the service's JSON Schema, if one is set | Yes |
Check tiers, from cheapest to most complete:
- Lightweight (stages 1–4, free) — frequent uptime and payment-terms checks.
- Readiness (free) — asks the service's own facilitator to
/verify a signed authorization without settling it. Only possible when the service publishes its facilitator and that facilitator accepts CORTX's requests; otherwise it is "unavailable", never a failure.
- Paid (all 7 stages, real USDC) — the proof. Runs on each service's schedule; once a day when readiness is passing and the last paid check passed.
CORTX's own problems are never blamed on a service. An empty test wallet, a spent budget or an internal error is recorded as a CORTX-side error: it opens no incident, sends no alert to the builder and doesn't count in uptime.
Two failed checks in a row open an incident; a passing check of the same tier or higher closes it.
What builders get
- Monitoring and incidents with stage-level evidence, including the settlement receipt and a Basescan link
- Telegram and Discord alerts when incidents open, get worse and resolve
- Public status pages —
/status/[userId] and /status/service/[serviceId]
- Badge —
/api/badge/[serviceId]
- Reliability API —
GET /api/v1/reliability/[serviceId]: 30-day uptime, paid delivery, schema validity, latency, the open incident, and the latest paid check as an x402 Reliability Spec evidence record. Docs: usecortx.dev/docs/partner-integration
- Registry — usecortx.dev/registry: monitored and observed x402 services
- Free reliability report — usecortx.dev/report: the free stages for any public x402 URL, plus the paid stages for services up to $0.01 while the report's small daily budget lasts
Open source
Open tools, paid network. The checker is open; the accumulated evidence — months of checks, incidents and recoveries across services — is what CORTX builds.
- x402 Reliability Spec (Apache 2.0) — the open standard for x402 reliability evidence. CORTX is its reference implementation:
lib/check-runner/spec-conformance.test.ts runs every spec test vector through the real check runner, and all pass.
- This repository (MIT) — the full CORTX app.
Cori
Cori is CORTX's autonomous reliability agent. Today (Scout v0) it discovers paid x402 services from the Coinbase CDP Bazaar, checks them for free, and queues good candidates for human review in the admin. Cori holds no wallet key and never pays; all spending stays in CORTX's deterministic payment path. See agent/cori/ and docs/CORI_SCOUT_V0_SPEC.md.
Stack
| Layer | Technology |
|---|
| App | Next.js 16 (App Router, React Server Components) on Vercel |
| Database | Supabase — Postgres, Auth, Row Level Security |
| Payments | viem (EIP-3009, x402 V2) and x402/client (V1), Base mainnet USDC |
| Scheduling | cron-job.org calls /api/cron every 15 minutes; each run checks several services at once and carries over what doesn't fit |
| Alerts | Telegram Bot API, Discord webhooks; email reports via Resend |
| Cori | Node process on its own server, Postgres as a least-privilege role |
Running locally
git clone https://github.com/danbuildss/cortx.git
cd cortx
npm install
cp .env.example .env.local # fill in values below
npm run dev
npm test # unit, end-to-end and spec-conformance tests
Environment variables
| Variable | Required | Description |
|---|
NEXT_PUBLIC_SUPABASE_URL | yes | Supabase project URL |
NEXT_PUBLIC_SUPABASE_ANON_KEY | yes | Supabase anon key (client-side auth) |
SUPABASE_SERVICE_ROLE_KEY | yes | Supabase service role key (server only) |
CRON_SECRET | yes | Bearer token cron-job.org sends to /api/cron |
CORTX_TEST_WALLET_KEY | for paid checks | 0x-prefixed private key of the dedicated test wallet. Set it only in your host's secret store — never in code or on any other server |
CORTX_DAILY_SPEND_CAP_USDC | no (1.00) | Platform-wide daily spend cap for paid checks |
CORTX_MONTHLY_SPEND_CAP_USDC | no (10.00) | Platform-wide monthly spend cap |
CORTX_WALLET_LOW_BALANCE_THRESHOLD_USDC | no (0.05) | Admin alert when the test wallet drops below this |
BETA_MAX_ENDPOINT_PRICE_USDC | no (1.00) | Highest per-call price CORTX will pay |
REPORT_DAILY_BUDGET_USDC | no (0.25) | Daily budget for the paid part of the free /report (also counts toward the caps above) |
REPORT_MAX_PRICE_USDC | no (0.01) | Highest per-call price the free /report will pay |
TELEGRAM_BOT_TOKEN | for alerts | Telegram bot token |
TELEGRAM_BOT_USERNAME | for alerts | Bot username without @, for deep links |
TELEGRAM_WEBHOOK_SECRET | for alerts | Verifies Telegram webhook calls |
CORTX_ADMIN_USER_ID | for admin | Supabase user id of the owner (enables /admin) |
CORTX_ADMIN_TELEGRAM_CHAT_ID | for admin | Owner's Telegram chat for wallet and Cori alerts |
|
Cori has its own settings — see agent/cori/README.md.
Repository layout
| Path | What's there |
|---|
app/ | Next.js app: dashboard, admin (/admin, /admin/cori), public pages, API routes |
lib/check-runner/ | The check pipeline: x402 parsing (x402.ts), payment (payment.ts), readiness, scheduling, persistence, spec records |
lib/cori/, lib/net/ | Cori's pure rules; SSRF-safe networking |
agent/cori/ | The Cori process |
supabase/migrations/ | SQL migrations, applied in order in the Supabase SQL editor |
test/ | Test hooks, stubs and the vendored spec test vectors |
docs/ | Specs: check runner, Cori Scout |
Database
Postgres on Supabase with Row Level Security on every table. The main groups:
- Monitoring —
services, checks (insert-only, per-stage evidence as JSONB), incidents, alert_configs, telegram_connections, discord_connections, profiles
- Spending —
spend_reservations plus the reserve_spend() and get_spend_totals() functions (atomic budget reservation)
- Registry and submissions —
registry_seeds, endpoint_submissions
- Cori —
discovered_services, discovery_events, cori_runs, cori_sources, cori_denylist, and the cori_agent role
- Settings —
system_settings
Security
- The test wallet key lives only in the app host's secret store, is redacted from every error and log path, and never reaches Cori
- Every paid check reserves budget atomically against the daily and monthly caps first
- SSRF protection: every request to a service or facilitator address (checks, readiness, service detection, ownership verification, Cori) goes to HTTPS only, and the address is checked when the connection is made and again on every redirect, so a service can't send CORTX to a private or internal address
- Response bodies capped at 1 MB
- Cron and webhook secrets compared in constant time; Telegram link tokens are single-use and expire after 10 minutes
- The service role key is used only on the server; Cori connects as a least-privilege Postgres role
- Budget and wallet functions are not callable by anonymous or signed-in users
License
MIT
