# Phoenix Zero — Execution Oracle for AI Agents

> Ask before you sign: will a transaction sent to this L2 right now land on time?
> 12 chains monitored, each polled every ~2 seconds against 2-3 independent RPC nodes ($0.01 USDC per call via x402).
> How many chains are in service right now: chains_in_service in /api/v1/health.

## When to call
Before you send a swap, bridge, liquidation or payment on an L2.
A lagging or overloaded RPC never reports its own problem — your transaction just arrives late,
reverts, or hangs. Phoenix polls 2-3 independent RPC nodes per chain in parallel, counts only real
JSON-RPC answers, and tells you whether to send now.

## One call = one decision
GET https://rtt.phoenix-ai.work/api/v1/safe?chain=base        ($0.01 USDC, x402)

  {"safe": true,  "reason": "ok", "p99_ms": 21.4, "revert_ratio": 0.08}
  {"safe": false, "reason": "high_latency", ...}

reason: ok | elevated_latency | high_latency | sequencer_stall | elevated_revert | high_revert | data_stale
        | no_data (no fresh measurement for this chain) | chain_halted (the chain's last block is > 10 min old)
safe=true  -> send now.
safe=false -> wait 10-30 s and ask again, or execute on another chain.
Charged only for an answer with data (HTTP 200): no fresh measurement = HTTP 503 (reason no_data / data_stale, safe=false) and nothing is charged.
The same 503 with reason no_working_nodes: no RPC node of that chain returns a valid answer (no measurement, not a stall).

## Other paid endpoints ($0.01 USDC each, x402)
GET  /api/v1/health           all 12 chains in one snapshot + recommendation
                              recommendation = the chains in service (since this version); recommendation_all_chains = all 12;
                              out_of_service = chains left out (closed, or no working RPC node) with the reason; recommendation_by_chain = each chain's own status;
                              chains_in_service / chains_total = the counts
GET  /api/v1/chains/{chain}   one chain: p95/p99 latency, stall flag, revert ratio
POST /api/v1/preflight        PASS / DEGRADED / FAIL with evidence id
GET  /api/v1/correlation      12x12 cross-chain latency correlation (are failures spreading?)
GET  /api/v1/health-proof     HMAC commitment of current node health (verifiable only by this node; per-process key); the ebpf flags mean attached in the kernel, not merely loaded; node.ebpf.lsm_mode counts the services per LSM mode: under a ban (enforce, enforce_exec) or only recorded (observe), see Node self-protection
POST /api/v1/classify         caller type: HUMAN / LEGIT_AGENT / MALICIOUS_BOT / SYBIL / UNKNOWN
                              optional target = a User-Agent string to classify instead of your own (confidence at most 0.5)

## Free
GET /api/v1/price             current price and surge multiplier
GET /api/v1/demo/safe         the same safe/reason verdict, delayed 60 s (100 calls/day/IP)
GET /api/v1/openapi.json      OpenAPI schema
GET /.well-known/x402         x402 discovery
GET /.well-known/mcp.json     MCP tools

## Live stream (WebSocket)
wss://rtt.phoenix-ai.work/ws   first message: {"api_key": "<key>"}, or {} for the keyless feed
Free, no key: the feed delayed 300 s, without the kernel-RTT records.
searcher / professional / enterprise: the full live feed, up to 5 sessions per key.
Stream pass (tier searcher): GET /api/v1/stream-pass, ONE payment of $30 USDC (x402 exact, Base or Arbitrum One only; fixed price, no surge) = a key for 30 days, up to 5 sessions.
Day pass (tier searcher): GET /api/v1/stream-pass-day, ONE payment of $0.99 USDC (x402 exact, Base or Arbitrum One only; fixed price, no surge) = a key for 1 day, up to 2 sessions. Same stream, same key rules; the 1 day counts from the payment on the chain.
  The key is shown once in the answer (only its hash is stored); the 30 days count from the payment on the chain, not from the activation of the key; it works within about 60 s.
  Many x402 clients default to a $1 maximum. To buy the $30 pass, raise your client limit to at least $30.
  $0.99 day pass works with default x402 clients (<= $1 per payment); the $30 / 30-day pass needs your client's per-payment limit raised to at least $30.
  A lost answer (either pass): repeat the same request with the same payment header within 5 minutes (same answer, no second charge). NO REFUNDS.
  Replay is possible only from the paying IP or with the payer wallet signature. From another IP add the header X-Pass-Claim: <unix_seconds>:<0x signature>, an EIP-191 personal_sign
  by the paying wallet over the text 'Phoenix Zero stream pass claim: proof=<proof> time=<unix_seconds>' (proof = lowercase hex SHA-256 of the Payment-Signature header value you sent;
  unix_seconds not older than 5 minutes). Without either, the answer is 402 pass_replay_refused: no key is handed out.
  When the pass ends the stream sends {"type":"pass_expired"} and closes the connection; buy a new pass at the same address.
professional / enterprise keys with other terms: on request (aleksandrkent64@gmail.com).
A payer's wallet address is not a credential for the live feed. The stream is not sold per call: the per-call x402 prices below cover the REST API; live access is the pass above.

## Evidence behind every answer
- L1 kernel: eBPF measures the TLS round trip to each RPC node (SSL_write -> data returned) and reports it as kernel_tls_rtt in /api/v1/safe and /api/v1/health, next to the verdict (not part of it).
- L2 network: per-node JSON-RPC latency, p95/p99, divergence between nodes, lagging-node detection, anomaly score
  (head block per node), chain head age from the chain's own block timestamps, anomaly score.
- L3 execution: revert ratio from block receipts (Base, Arbitrum, Optimism), sequencer health.
Every raw record is signed (BLAKE3 + Ed25519). Paid responses are signed EIP-191 by
0xdac8adC44f621bC3A56E9DC108d2F76Be3142294 — verify offline.

## Payment
x402 v2, USDC via Coinbase CDP facilitator on Base (eip155:8453), Polygon (eip155:137),
Arbitrum One (eip155:42161).
Price $0.01. Surge: x3 ($0.03) when Base p99 > 500 ms or revert > 25%; x10 ($0.10) on stall >= 5 s
or revert >= 50%. Limit: 10 calls / 60 s per wallet.
The stream passes are separate: $30 (30 days) and $0.99 (1 day), fixed, Base or Arbitrum One only, never surged, not counted in that wallet limit.

## On HTTP 402 (how to pay)
1. Read the PAYMENT-REQUIRED response header: base64 JSON (x402 v2) with accepts[] = network, asset,
   amount (atomic units, 10000 = $0.01 USDC), payTo.
2. With an x402 client, sign a payment authorization for one accepts[] entry (USDC: EIP-3009
   transferWithAuthorization). Do NOT send an on-chain transaction yourself - the facilitator settles it.
3. Retry the same request with header Payment-Signature: <base64 payload> (v1 clients: X-PAYMENT).
Clients: x402 SDKs (TypeScript/Python/Go), or npm phoenix-zero-preflight. Terms: /.well-known/x402.

## Chains
base, arbitrum, optimism, zksync, mantle, scroll, blast, linea, mode, polygon_zkevm, taiko, casper (L1 reference)

## Caller labelling
Every request to the API is classified by the caller's behaviour (request rhythm, User-Agent and headers) as
HUMAN, LEGIT_AGENT, MALICIOUS_BOT, SYBIL or UNKNOWN. The label is returned in the X-Silicon-DNA-* response headers
and is not a block by itself; an address that keeps being classified MALICIOUS_BOT or SYBIL can be throttled,
paying agents and directories are not banned.
Recorded: the timing of recent requests per address (memory only); a journal line per request (hashed address,
endpoint, status, label); a request log (endpoint, address, User-Agent, referer, payer wallet); a ban list
(address, reason) for addresses that attacked.

## Node self-protection (Linux BPF LSM)
- The x402 payment gateway cannot start other programs: the kernel denies execve for every process of its service
  (children included), except the one start of the service by systemd. Switched on 2026-11-12 21:41 UTC.
  If this rule ever blocks the service's own start, the guard falls back to recording only and raises an alarm.
- The on-chain publisher: the kernel denies execve for its own process (guard by process ID; a child process has its
  own ID and is not covered), and its outgoing IPv4/IPv6 connections may go only to ports 53, 443, 7777 and 8545.
- The gateway's network connections are recorded, not restricted. Other services are not under this guard.
- Limits: this does not stop malicious code loaded inside the same process (for example a poisoned library import),
  and there is no guarantee if root is compromised. Software self-protection on a virtual machine, not hardware attestation.
- Live state: GET /v1/health-proof (paid) -> node.ebpf.lsm_mode (how many services run in each mode: enforce, enforce_exec,
  observe; counts only), node.ebpf.lsm_guard_basis, node.ebpf.lsm_links_attached.

## Not this
Not a price oracle (use Chainlink / Pyth for prices). Phoenix answers a different question:
should I execute right now?

## Links
API: https://rtt.phoenix-ai.work
GitHub: https://github.com/kant19801201behax5/x402-health-oracle
MCP: npm phoenix-mcp-server · MCP Registry io.github.kant19801201behax5/phoenix-mcp-server
Paper: https://doi.org/10.5281/zenodo.22239862