PayPerByte

{
  "name": "PayPerByte",
  "description": "Per-byte USDC data feeds + oracles for AI agents \u2014 pay-per-call via x402, settled in USDC on Base. Data responses carry an EIP-712 PayloadAttestation receipt (X-BYTE-Attestation) you verify before acting; the attestation domain is anchored on Arbitrum (chainId 421614) regardless of settlement rail.",
  "url": "https://x402.payperbyte.io",
  "version": "0.3.0",
  "provider": {
    "organization": "PayPerByte",
    "url": "https://www.payperbyte.io"
  },
  "capabilities": {
    "payments": {
      "protocol": "x402",
      "asset": "USDC",
      "network": "eip155:8453",
      "payTo": "0xffFf4B8Da8C165B556326453446F6940C8AFE0DB"
    },
    "streaming": false
  },
  "receipt": {
    "header": "X-BYTE-Attestation",
    "scheme": "EIP712-PayloadAttestation",
    "domain": {
      "name": "BYTE Library",
      "version": "1",
      "chainId": 421614,
      "verifyingContract": "0x44729bB148F46d8Db509E47b0453edc271e06e95"
    },
    "attester": "0xB48CCc9e3ab67041e3b5D09700138E45cda6AeA8",
    "retiredAttesters": [
      {
        "address": "0x77c86a5367d941091a31BC97104609F2Db33C472",
        "retiredAt": "2026-08-19T23:03:00Z",
        "reason": "planned rotation following a confirmed key exposure"
      }
    ],
    "verify": "keccak256(responseBody) === payloadHash AND recoverTypedDataAddress(domain, {PayloadAttestation}, message, signature) === attester",
    "anchorNote": "domain.chainId 421614 = Arbitrum Sepolia, a TESTNET \u2014 it is a FROZEN signing namespace for EIP-712 signature recovery, NOT a settlement rail. Payments settle in USDC on Base mainnet (eip155:8453); no funds move on testnet. The chainId is a consensus constant: it stays 421614 regardless of where you pay, so every receipt verifies against the same domain. (Mainnet re-anchoring is audit-gated.)",
    "embedded": {
      "scheme": "EIP712-PayloadAttestation",
      "domain": {
        "name": "BYTE Library",
        "version": "1",
        "chainId": 421614,
        "verifyingContract": "0x44729bB148F46d8Db509E47b0453edc271e06e95"
      },
      "verify": {
        "broadcast": "recover the publisher's EIP-712 PayloadAttestation from the on-chain BroadcastStreamed event at responseBody.txHash; confirm responseBody.publisher === signers[feed] and responseBody.payloadHash matches the broadcast.",
        "live": "canonical(x) = the EXACT byte substring of x as delivered in this response \u2014 the gateway forwards the live-query companion's bytes VERBATIM (never re-serialized), so extract responseBody.data.answer directly from the raw response text, NOT by JSON.parse-ing then re-serializing it: a JSON writer that normalizes numbers (e.g. renders 3.0 as 3) will not reproduce the bytes the publisher signed, and the recompute mismatches on otherwise-valid data. keccak256(canonical(responseBody.data.answer)) === responseBody.data.attestation.payloadHash AND recoverTypedDataAddress(domain, {PayloadAttestation}, message, responseBody.data.attestation.signature) === responseBody.data.attestation.signer AND confirm responseBody.data.attestation.signer === signers[feed]. (responseBody.payloadHash mirrors the same value at the top level for parity with the broadcast shape. Publisher-side note: avoid trailing-.0 float literals where possible \u2014 a common source of this exact cross-implementation mismatch.)",
        "oracle": "canonical(x) = the EXACT byte substring of x as delivered \u2014 same defect and same fix as the `live` recipe above (FD 2026-07-28: this recipe mismatches for a JS buyer that re-serializes today): extract `answer` from the raw response bytes, never by JSON.parse-ing then re-serializing the parsed object. keccak256(canonical(answer)) === attestation.payloadHash AND recoverTypedDataAddress(domain, {PayloadAttestation}, message, attestation.signature) === attestation.signer (the feed's own per-feed key \u2014 NOT the gateway attester); if signers[feed] is present, also confirm attestation.signer === signers[feed]."
      },
      "note": "A distinct per-feed key, separate from the gateway X-BYTE-Attestation header. First-party PayPerByte (not an independent third-party data source), NOT a correctness guarantee. `signers` maps feed id -> that feed's expected signer, independently of what any single response claims: for eip712-attested broadcast feeds it's the on-chain-registered publisher address; for POST oracles (where configured \u2014 see ORACLE_SIGNERS) it's the oracle's own key, published here so the `oracle` verify recipe above isn't just checking a response against itself. A feed id absent from `signers` (an oracle whose address isn't configured yet) still embeds its own `attestation.signer` in the body \u2014 verifiable for tamper-evidence, just not yet pinnable against an independent expected value.",
      "signers": {
        "weather": "0xa820763c023a929e83c59e4fd5a623e5a8efe941",
        "earthquakes": "0xa1a55406de233901257aec7b499a26f040ba3cfa",
        "runtime-eol": "0x17a67d0d18f9b93f064a23d2076074ea8802216f",
        "threat-intel": "0xb90b00f891dc534a5b59c60170661b868f3c26de",
        "address-reputation": "0x670444bE8515C63c50166EbcD0E5b23c578BbE04",
        "sanctions-screen": "0x344ECaCDe6566294c31397445c98b62a3EEEA456",
        "reasoning-verdict": "0xe6447AfD82A5E119B5250220Ab6ac2ae7d7f65ab",
        "merchant-screen": "0x86e67978B5DaE33d134c431A47c1B73365440b54",
        "cctp-attestation-latency": "0xBC8cB1A828a0d8dCc4a1092C622D12C0b24736F5"
      }
    }
  },
  "skills": [
    {
      "id": "weather",
      "name": "Weather (US, multi-city)",
      "description": "NWS weather forecasts for 5 US cities (NYC, LA, Chicago, Houston, Miami)",
      "url": "https://x402.payperbyte.io/feeds/weather",
      "method": "GET",
      "signer": "0xa820763c023a929e83c59e4fd5a623e5a8efe941",
      "tags": [
        "general",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "earthquakes",
      "name": "Earthquakes",
      "description": "USGS recent earthquakes worldwide (M2.5+)",
      "url": "https://x402.payperbyte.io/feeds/earthquakes",
      "method": "GET",
      "signer": "0xa1a55406de233901257aec7b499a26f040ba3cfa",
      "tags": [
        "general",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "runtime-eol",
      "name": "Runtime EOL",
      "description": "End-of-life dates and status for language runtimes, frameworks, OSes (endoflife.date)",
      "url": "https://x402.payperbyte.io/feeds/runtime-eol",
      "method": [
        "GET",
        "POST"
      ],
      "signer": "0x17a67d0d18f9b93f064a23d2076074ea8802216f",
      "tags": [
        "general",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "threat-intel",
      "name": "Security Advisories Digest",
      "description": "Recent CVE highlights + CISA known-exploited-vulnerability entries, relayed from public sources (NVD, CISA KEV)",
      "url": "https://x402.payperbyte.io/feeds/threat-intel",
      "method": [
        "GET",
        "POST"
      ],
      "signer": "0xb90b00f891dc534a5b59c60170661b868f3c26de",
      "tags": [
        "general",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "address-reputation",
      "name": "Address Reputation Oracle",
      "description": "Know-Your-Agent (KYA) counterparty screening \u2014 reputation pillar. Agentic-payments go/no-go verdict: synchronous signed ALLOW/WARN/BLOCK for (domain, receiving address, amount, chain) BEFORE releasing USDC. ar-v1 ruleset over RDAP/TLS/DNS/Wayback domain signals + on-chain receiving-address signals + curated known-bad blocklist. The verdict carries an embedded EIP-712 PayloadAttestation \u2014 recompute keccak256(answer) and recover the signer before acting. Scope: screens the counterparty tuple you supply \u2014 not identity verification of the calling agent.",
      "url": "https://x402.payperbyte.io/feeds/address-reputation",
      "method": "POST",
      "tags": [
        "commerce",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "pkg-verdict",
      "name": "Package Verdict Oracle",
      "description": "Signed ALLOW/WARN/BLOCK on installing a package@version: OSV.dev malicious-corpus + typosquat distance + registry signals. Verify before you install.",
      "url": "https://x402.payperbyte.io/feeds/pkg-verdict",
      "method": "POST",
      "tags": [
        "general",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "sanctions-screen",
      "name": "Sanctions Screen Oracle",
      "description": "Know-Your-Agent (KYA) counterparty screening \u2014 sanctions pillar. Signed, version-pinned OFAC SDN + Consolidated screening on an address or name; every answer embeds the pinned list-state (date + sha256) it was judged against. Primary source: official U.S. Treasury Sanctions List Service exports incl. the digital-currency address annex, parsed and content-sha256-pinned first-party \u2014 not a resold vendor list. Scope: screens the counterparty you supply \u2014 not identity verification of the calling agent. Receipt deadline: this feed's EIP-712 receipt is minted with a 10-year freshness window (not the platform's usual 300s), by design \u2014 evidence-grade compliance records need to stay independently verifiable long after the screening decision itself has aged. This is a durability choice, not a licence to act on stale data: the receipt still proves only which key signed which exact bytes \u2014 it carries no signed observation time, so it never establishes WHEN the screening ran (an external existence-in-time anchor is what would), and never that the screening result is still current. Re-screen before relying on an old answer for a new decision.",
      "url": "https://x402.payperbyte.io/feeds/sanctions-screen",
      "method": "POST",
      "tags": [
        "legal",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "reasoning-verdict",
      "name": "Reasoning Verdict Oracle (local LLM)",
      "description": "Verify-before-act risk oracle: POST an action context (message, payload, proposal, payee, tool-call) and get a signed ALLOW/WARN/BLOCK/ABSTAIN verdict + 0-100 safe-to-proceed score + reasons from a LOCAL model (no data egress). The verdict carries an embedded EIP-712 PayloadAttestation \u2014 recompute keccak256(answer) and recover the signer before acting. Advisory: the receipt proves provenance/integrity, not correctness.",
      "url": "https://x402.payperbyte.io/feeds/reasoning-verdict",
      "method": "POST",
      "tags": [
        "general",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "merchant-screen",
      "name": "Merchant Screen Oracle",
      "description": "Know-Your-Agent (KYA) counterparty screening \u2014 merchant pillar. Pre-settlement merchant screen: signed ALLOW/WARN/BLOCK on a (domain, payTo, observed price) BEFORE an agent settles an x402 payment. ms-v1 ruleset over first-party signals measured at query time \u2014 RDAP domain age, live TLS handshake (cert age, issuer, SAN match), off-domain redirect probe, brand-similarity distance vs a committed known-brand corpus, and the merchant's own advertised x402 manifest price. Method disclosed per field; unmeasurable signals report unverified and only lower confidence. The verdict carries an embedded EIP-712 PayloadAttestation \u2014 recompute keccak256(answer) and recover the signer before acting. Trust boundary: the payTo and price are values you assert, not values we observe on your payment \u2014 the verdict is a point-in-time snapshot of the exact tuple you supplied, and it neither sees nor constrains the address you ultimately settle to. Before releasing funds compare answer.query against the 402 challenge you are about to pay (answer.query.address is lowercased \u2014 compare case-insensitively). The receipt proves provenance and integrity, not correctness. Every query is logged and retained: the domain, the payTo address and price you supplied, the verdict, and a summary of the signals behind it. Producing a verdict requires live outbound requests against the screened domain itself \u2014 the merchant may observe this traffic; screening is not covert.",
      "url": "https://x402.payperbyte.io/feeds/merchant-screen",
      "method": "POST",
      "tags": [
        "commerce",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "positioning-snapshot",
      "name": "Positioning Snapshot Oracle",
      "description": "Cross-venue perp positioning (funding + open interest) from Hyperliquid, dYdX v4, Aevo; raw fields, abstains honestly where a venue lacks data.",
      "url": "https://x402.payperbyte.io/feeds/positioning-snapshot",
      "method": "POST",
      "tags": [
        "financial",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "cctp-attestation-latency",
      "name": "CCTP Attestation Latency Oracle",
      "description": "Measured Circle CCTP v2 attestation latency, reported as separate Fast and Standard distributions \u2014 never blended, since the two settlement paths differ by roughly two orders of magnitude (~8s vs ~15-19min) and a single percentile would describe neither. Built from first-party polling of real burns on Base, Arbitrum, and Optimism: every figure is a BOUNDED observation (burn -> first poll that saw the attestation complete), never an exact measurement, and the bound width ships alongside every distribution. Percentiles are withheld below an 8-measured-sample floor per (chain, path) bucket \u2014 a p95 over a handful of samples is arithmetic, not evidence. Unclassifiable samples are excluded, never bucketed; empty is reported as no_data, never as a low latency. The embedded EIP-712 PayloadAttestation proves which key signed these exact answer bytes \u2014 recompute keccak256(answer) and recover the signer before acting \u2014 never a claim that the measured latency will hold for your own transfer.",
      "url": "https://x402.payperbyte.io/feeds/cctp-attestation-latency",
      "method": "POST",
      "tags": [
        "general",
        "x402",
        "usdc",
        "base"
      ]
    },
    {
      "id": "regime-signal",
      "name": "Receipt-Anchored Regime Signal",
      "description": "BTC/ETH regime classification (trend_up/trend_down/range/high_vol) and a realized-vol above/below call, horizon 4h or 24h. Every response is bound to a signed EIP-712 DeliveryReceipt anchored on Base via EAS; the scoring rule is published and deterministic against public Chainlink rounds, independently recomputable by anyone \u2014 see https://x402.payperbyte.io/methodology and https://x402.payperbyte.io/track-record \u2014 v1-baseline model: a deterministic persistence/threshold rule, not a trained model \u2014 see https://x402.payperbyte.io/methodology for the exact published formula.",
      "url": "https://x402.payperbyte.io/feeds/regime-signal",
      "method": "POST",
      "tags": [
        "financial",
        "x402",
        "usdc",
        "base"
      ]
    }
  ],
  "endpoints": {
    "catalog": "https://x402.payperbyte.io/feeds",
    "openapi": "https://x402.payperbyte.io/openapi.json",
    "x402": "https://x402.payperbyte.io/.well-known/x402.json",
    "mcp": "https://mcp.payperbyte.io/mcp"
  },
  "documentationUrl": "https://www.payperbyte.io/docs/quickstart"
}