One Request.
Up to 100 Chain Reads.

Where the Data Comes From

For each request, this service routes live JSON-RPC reads through dRPC public nodes and returns successful provider responses. It queries current chain state when your batch runs; it does not sell a precomputed archive. The free dRPC tier uses public nodes, which can be slower or less reliable than paid endpoints. The dRPC key stays server-side and is sent in the Drpc-Key authentication header.

Data quality: these are provider-reported chain reads, not cryptographic proofs. If an upstream read fails or is malformed, the batch fails as a whole; partial results are not delivered as a successful response.

Pick the Batch Size

Choose the smallest tier that fits. A 100-check request is one payment and returns all requested reads under one captured block per chain. The 100-check tier costs $0.15 instead of $0.20 for four separate 25-check purchases (25% less) and keeps one snapshot per chain. Larger-tier prices are launch hypotheses; live marketplace comparison supports the $0.05 entry point, not proven demand at higher tiers.

• Native token balance
• ERC-20 token balance
• ERC-20 allowance
• Whether an address has contract code
• Current block height
• Bounded read-only eth_call

The tiers support up to 25, 50, or 100 checks across the five listed chains. Reads are capped, timed out, and pinned to a captured block. The endpoint rejects state-changing transaction methods.

Payment and Delivery

1. Send a valid request to the route for its chosen tier. The service validates it and returns an x402 quote; the quote contains no result data.
2. Your wallet or agent reviews the exact Base USDC amount in the quote: 50,000 atomic units ($0.05), 100,000 ($0.10), or 150,000 ($0.15).
3. After payment verification, the service runs the live reads, saves the exact response, and asks the facilitator to settle.
4. Once settled, the response is available and can be recovered for 30 days using the same request ID.

Capacity or service error: the admission gate can return HTTP 503 with a retry delay before payment verification. That request is not settled. Keep the same request ID when retrying; if a payment outcome is unclear, recover first instead of paying again.

Request Shape

Use a fresh UUIDv4 as requestId, and give each check its own ID.

{
  "requestId": "12345678-1234-4234-9234-123456789abc",
  "checks": [
    {
      "id": "wallet-balance",
      "chain": "base",
      "type": "native_balance",
      "address": "0x0000000000000000000000000000000000000000"
    },
    { "id": "base-height", "chain": "base", "type": "block_number" }
  ]
}

Response fields include the request ID, each check’s result and block number, the per-chain snapshot heights, and a recovery URL. See the API Schema for required fields and validation limits.