Phoenix Zero — Execution Oracle for L2s

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