X402 Health Oracle MCP Server

x402 Health Oracle

Execution oracle for AI agents: tells you — before you sign — whether your transaction or payment will land on time, or be delayed, stalled or reverted. 12 chains, measured every 2 s from the kernel up. Every answer is signed and backed by L1/L2/L3 evidence records. Pay per call via x402 (Base, Polygon, Arbitrum USDC).

Live: https://rtt.phoenix-ai.work | npm: phoenix-mcp-server | MCP Registry: io.github.kant19801201behax5/phoenix-mcp-server

Try it yourself (guided, ~3 min, no wallet): https://rtt.phoenix-ai.work/?tour
On-chain registry on Arbitrum: 0xD394fFAE51d8fB52187Cf3aE3b014Ddc80Dc7B15 (Arbitrum Sepolia)
Signed live verdict (free, 60 s delayed): https://rtt.phoenix-ai.work/api/v1/demo/safe?chain=arbitrum

Problem

AI agents making autonomous on-chain transactions have no way to check network health before committing funds. 64% of DeFi protocols don't verify sequencer health. In June 2026 Base stopped producing blocks for 116 minutes (25 June) and again for 20 minutes the next day; L2Beat showed just under $11 billion of value secured on it (Cointelegraph).

Existing solutions (Chainlink L2 Sequencer Feed) give binary up/down with 30-second OCR updates. Agents need nanosecond-precision RTT, revert ratios, and stall detection — before signing a transaction.

What you actually buy: network delay is visible here before it hits you. If a sequencer is stalling or RPC latency is spiking, your swap, bridge or x402 payment will arrive late — or not at all. Phoenix measures that delay right now and answers act now / wait / route elsewhere.

Measured by Phoenix (independently confirmed from public-RPC block receipts):

• Base, Oct 1 2026, 08:06–08:13 UTC — 7× the usual traffic; 26 % of transactions failed (up to 70 % in some blocks), ~$68 of fees burned on failed transactions in 7 minutes (calm hour: 6 %). An agent sending then had 4× the risk — and its RPC node said nothing.
• Polygon zkEVM — no new block since Jul 3 2026, yet its RPC nodes answer in ~50 ms. A latency monitor calls it healthy; Phoenix reports chain_halted from the chain's own block timestamps.

Evidence base: three layers, recorded continuously

The server writes ~1.2 GB/day of these records; a paid verdict is derived from them and signed (EIP-191, signer 0xdac8adC44f621bC3A56E9DC108d2F76Be3142294) so it can be verified offline.

Solution: One Core, Four Entrances

                    ┌── MCP Server (Claude/Cursor/Windsurf)
                    │
Agent ──────────────┼── Olas Mech (DeFi/arbitrage agents)
                    │
                    ├── Direct HTTP/x402 (any agent by URL)
                    │
                    └── RPC Gateway (transparent proxy)
                           │
                           ▼
                    PHOENIX CORE
                    ├── x402 paywall ($0.01/query)
                    ├── 12-chain RTT probe (2s interval)
                    ├── BLAKE3+Ed25519 integrity signing
                    ├── Isolation Forest anomaly scoring
                    ├── Surge pricing daemon (3-tier: $0.01/$0.03/$0.10)
                    └── eBPF XDP enforcement (prog 6293, live)

Distribution Channels

Chains Monitored

12 L2 networks with 2-second sampling interval:

Casper is included as an L1 reference chain (L1 thresholds: stall ≥ 10 s, high latency > 2 s).

x402 Payment Rails

Every 402 response carries the x402 v2 PAYMENT-REQUIRED header and the same x402Version/accepts in the JSON body.

# Try it — returns 402 Payment Required with x402 challenge
curl -i https://rtt.phoenix-ai.work/api/v1/health

# Free demo — the same verdict, 60 s late (100/day/IP, no payment)
curl https://rtt.phoenix-ai.work/api/v1/demo/safe

# Free current price (surge multiplier)
curl https://rtt.phoenix-ai.work/api/v1/price

# Free health endpoint (no payment)
curl https://rtt.phoenix-ai.work/api/health

Paid Endpoints ($0.01 USDC; surge ×3 = $0.03 when Base p99 > 500 ms or revert > 25%, ×10 = $0.10 on stall ≥ 5 s or revert ≥ 50%)

Free Endpoints (no payment required)

On-chain Registry on Arbitrum

PhoenixOracleRegistry — 0xD394fFAE51d8fB52187Cf3aE3b014Ddc80Dc7B15 on Arbitrum Sepolia. Source: contracts/PhoenixOracleRegistry.sol (Solidity ^0.8.20).

• A publisher writes the live verdict on-chain every 5 minutes (more than 10,000 updates by 4 Nov 2026): Base p99 latency, revert ratio (bps), risk level (SAFE / ELEVATED / HIGH / STALL), timestamp, Base block number.
• Smart contracts read it directly: isSafe(), riskLabel(), latest(), updateCount(); event SnapshotPublished.
• Access control: only the owner or the designated oracle address may publish (setOracle, transferOwnership).
• The publisher runs inside a BPF LSM kernel sandbox (no new executables; outbound only to DNS / HTTPS / RPC ports).
• The contract is chain-agnostic Solidity — deployable to any EVM chain; a Casper oracle contract exists as well.

Caller label and agent passport

Every response of the paid gateway (/v1/*, both 402 and 200) carries a label for the caller: X-Silicon-DNA-Class (HUMAN / LEGIT_AGENT / MALICIOUS_BOT / SYBIL), -Confidence, -Layers (passed/14), -Layers-Applicable, -Timing-Intervals, -Timing (insufficient / human_like / agent_like / bot_like), -Paid (settled payments of this caller), -Passport. The label never blocks a request: a bot-like caller still receives the normal 402, so directories that list the oracle keep seeing the payment terms.

GET /api/agent/passport returns the full passport with an Ed25519 signature. Verify it without trusting the server: take signed_payload and signature_ed25519 from the answer and the public key from /.well-known/silicon-dna-key.json (the page explains the check in Node and Python). The payment block comes from settlements confirmed by the x402 facilitator.

Honest limit: the timing layers (L3, L4, L6, L7) need ≥ 20 request intervals from the same caller. Most API callers make fewer, so their class rests on headers and request rate until enough history accumulates (measured 8 Oct 2026: 2 of 30 outside callers had ≥ 20 intervals).

Components

eBPF Kernel Security

XDP Threat Filter (LIVE since Aug 28, 2026)

eBPF XDP program (prog id 6293) on eth0 drops malicious packets before the TCP stack (run time of the XDP program: 927 ns per packet on average (measured 8 Oct 2026 with the kernel's BPF run counters, generic mode on virtio_net)). Silicon DNA's 14-layer bot detection feeds the BPF map every 5 seconds.

LSM Agent Guard (live: guards the Arbitrum registry publisher)

BPF LSM program (kernel boot lsm=landlock,lockdown,yama,integrity,apparmor,bpf). Sandboxes the service named in LSM_TARGET_SERVICE — currently phoenix-arb-publisher, which keeps publishing on-chain under the guard (verified by an on-chain publish):

• Block execve — agent can't spawn child processes
• Restrict connect — only ports 53 (DNS), 443 (HTTPS), 8545 and 7777 (RPC)
• File access — limited to agent's working directory

MCP Server (AI Agent Discovery)

Published to npm and MCP Registry. Any AI coding assistant can discover and use our health oracle.

# Install from npm
npm install -g phoenix-mcp-server

# Or add to Claude Desktop (claude_desktop_config.json):
{
  "mcpServers": {
    "phoenix-zero": {
      "command": "npx",
      "args": ["phoenix-mcp-server"]
    }
  }
}

Tools:

• check_safety_free — FREE safety check (100 calls/IP/day). Returns {safe, reason, chain} for any of 12 chains.
• preflight_network_health — PASS / DEGRADED / FAIL with kernel-level evidence. Free for health_check, x402 $0.01 for rtt_ns/revert_ratio.

npm SDK — phoenix-zero-preflight

3-line integration for bot developers:

const { PhoenixPreflight } = require("phoenix-zero-preflight");
const phoenix = new PhoenixPreflight();

// Free demo — no payment needed
const result = await phoenix.checkSafe("base");
// { safe: true, reason: "ok", chain: "base", demo: true }

// For AgentKit / LangChain — drop-in tool
const { createPhoenixTool } = require("phoenix-zero-preflight");
const tool = createPhoenixTool();
// tool.name = "phoenix_preflight_safety"

RPC Gateway (Transparent Proxy)

Agent connects to Phoenix as if it were a normal RPC endpoint. Phoenix checks health before forwarding:

Agent → POST /rpc/base {"method": "eth_sendRawTransaction", ...}
     Phoenix checks health:
       PASS → forward to upstream RPC → response + X-Phoenix-Health: PASS
       DEGRADED → forward + X-Phoenix-Warning header
       FAIL → 503 "Transaction blocked to protect funds"

Live — try it now:

curl -X POST https://rtt.phoenix-ai.work/rpc/base \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
# → {"jsonrpc":"2.0","result":"0x...","id":1}
# + X-Phoenix-Health: PASS header

Supported chains: base, arbitrum, optimism, zksync, scroll, mantle, linea, blast, mode, taiko, polygon_zkevm.

Docker

Runs the x402 gateway locally. Real-time telemetry comes from the production server at rtt.phoenix-ai.work.

cp .env.example .env   # works as is (x402.org facilitator, Base Sepolia); add CDP keys for Base mainnet
docker compose up
curl -i localhost:3002/v1/safe       # → 402 Payment Required
curl localhost:3002/                  # → service info

Security Stack

• eBPF XDP — kernel-speed threat response (live, prog 6293)
• eBPF LSM — per-agent syscall sandbox (3 LSM programs; attach target configurable)
• ML-KEM-768 (NIST FIPS 203) post-quantum key exchange
• BLAKE3 + Ed25519 integrity signing on all telemetry
• 14-layer bot detection — CPU jitter, Spearman correlation, Argon2 PoW, Frankenstein headers, Sybil clustering, Privacy Pass
• Isolation Forest anomaly scoring (offline-trained, edge inference; anomaly_score in every PHOENIX_METRIC)

Test Suite

• Main repo: over 1,000 TypeScript and over 700 Python automated tests, passing in CI (4 Nov 2026)
• This repo: gateway 21 + MCP server 10
• Every production release is verified by sha256 against git, checked live (including a forged-payment test) and rolled back automatically on failure.

Verified Revenue

External (non-owner) x402 settlements, 10 Oct - 4 Nov 2026: 25 payments of 0.01 USDC = $0.25 from 11 wallets (24 on Base, 1 on Arbitrum One); own test payments excluded; some of the 11 wallets may be automated directory checks. Each payment was checked on-chain (USDC Transfer to PAY_TO). Verify on-chain:

• PAY_TO: 0xbb967F16C7f3e9B4c1626680684445d41dBE44Ab

Continuity

This project extends 6+ months of production work (since March 2026). Server uptime 170+ days. 14 production services on DigitalOcean. See CONTINUITY_PROOF.md.

Paper

Cross-Chain Temporal Correlation and Kernel-Level Enforcement for Layer-2 Bot Detection (preprint, CC BY 4.0, Zenodo version 2.0, September 2026) DOI: 10.5281/zenodo.22239862

License

MIT