Quickstart — five minutes to first byte

Two paths. Pick one. Both settle in USDC on Arbitrum Sepolia today and Arbitrum One after audit. No API key, no signup, no token.

Path A — MCP in Claude Desktop (recommended)

If your agent runs through Claude, Cursor, Windsurf, or any MCP-aware client, this is the lowest-friction path. The server handles the on-chain mechanics; you just configure a single JSON block.

npm install -g byte-mcp-server@latest

Add this to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent path on your platform:

{
  "mcpServers": {
    "byte": {
      "command": "npx",
      "args": ["-y", "byte-mcp-server"],
      "env": {
        "PRIVATE_KEY": "0x...",                  // optional — read-only without
        "RPC_URL": "https://sepolia-rollup.arbitrum.io/rpc"
      }
    }
  }
}

Your agent now has these tools:

• byte_search_publishers, byte_list_feeds — discover
• byte_subscribe — open a recurring USDC-per-byte stream from a publisher
• byte_buy_data — one-off pay-per-call via x402, no subscription required
• byte_query_fact — verified factual Q&A through the on-chain fact-oracle
• byte_publish_data — for publishers; signs an EIP-712 PayloadAttestation

Try: “Use the BYTE tools to buy the latest weather feed and tell me the NYC forecast.”

Path B — Raw x402 HTTP (any language)

If you're building outside an MCP client, hit the gateway directly. The protocol is HTTP 402 + EIP-3009 USDC transferWithAuthorization.

curl https://x402.payperbyte.io/feeds

Returns the live catalog with per-feed pricing (e.g. weather is $0.021, earthquakes $0.0015, fact-oracle $0.001).

curl -i https://x402.payperbyte.io/feeds/weather

You get an HTTP 402 with an X-PAYMENT-REQUIRED header containing the EIP-3009 challenge — the asset, amount, recipient, and deadline.

The signing dance is gnarly to hand-roll; use an x402 client library.

TypeScript

import { x402HTTPClient } from "@x402/core/http";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`);
const client = x402HTTPClient();
registerExactEvmScheme(client, { account });

const res = await client.fetch("https://x402.payperbyte.io/feeds/weather");
const data = await res.json();
const txHash = res.headers.get("X-PAYMENT-RESPONSE"); // on-chain receipt
console.log(data, "settled in tx", txHash);

Python

import os, httpx
from x402.clients.httpx import x402Client
from x402.evm.accounts import LocalAccount

account = LocalAccount(os.environ["PRIVATE_KEY"])
client = x402Client(httpx.Client(), account=account)

r = client.get("https://x402.payperbyte.io/feeds/weather")
print(r.json())
print("settled in tx", r.headers["X-PAYMENT-RESPONSE"])

Why the on-chain receipt matters

Every settlement on PayPerByte's DataStreamLib emits an EIP-712 PayloadAttestation signed by the publisher — the typehash binds publisher, payloadHash, payloadLength, and deadline. The subscriber SDK can re-derive keccak256 over the received bytes and assert equality with the on-chain hash. Flip one byte in transit and the assertion fails closed.

Cite the tx hash in your audit log. When the regulator asks where did this data come from?, the answer is a cryptographic paper trail, not a screenshot.

Safety caps for autonomous agents

PayPerByte is built for agents that spend without human supervision. That means the wallet your agent uses should carry hard limits — both for normal operations and for the rare cases when the underlying L2 stalls and unsubscribe intents land late.

Prefer a finite USDC allowance over approve(max)

byte_subscribe defaults to a max-uint approve so subscribed feeds keep settling cleanly. That's fine for human-operated wallets, but for autonomous agents the safer pattern is an explicit finite allowance sized to your expected spend over a comfortable window:

TypeScript (viem)

import { parseUnits } from 'viem';

// Cap exposure at $10 USDC across all PayPerByte settlements
const USDC = '0x1c16659aeb3aE28467E90348fAAB8874a0D3A4d3';
const DataStreamLib = '0x44729bB148F46d8Db509E47b0453edc271e06e95';

await wallet.writeContract({
  address: USDC,
  abi: erc20Abi,
  functionName: 'approve',
  args: [DataStreamLib, parseUnits('10', 6)],   // $10 ceiling
});

// Then call byte_subscribe with skipAllowance: true so it doesn't
// overwrite your cap with approve(max):
await byteMcp.byte_subscribe({ feed: 'weather', skipAllowance: true });

Top up by re-running the approve when the agent's remaining allowance crosses a low-water mark. The cost of an extra approve tx is dwarfed by the protection against runaway-loop bugs.

Use an account-abstraction wallet with per-domain caps

Stronger still: route the agent's wallet through an AA stack that enforces spending policy at signing time. Safe Modules, Biconomy AA, Alchemy Account Kit, and Privy server wallets all support per-contract or per-domain rate limits — for example, "this agent can spend at most $0.05 USDC per minute and $5 total per day against 0x44729bB1…e06e95". The cap is enforced before the tx ever reaches Arbitrum.

This bounds two real edge cases that a bare EOA can't:

• Runaway-loop bugs. A scripted client stuck in a retry loop can't exceed its rate cap, even if the script logic is broken.
• L2 outage windows. Arbitrum's centralized sequencer has historically averaged hours-per-year of downtime. If an unsubscribe lands in a delayed batch after a backlog of broadcasts, an AA-capped wallet still won't exceed its per-minute / per-day ceiling — exposure is bounded by policy regardless of when settlement clears.

BYTE's contracts are standard ERC-20-compatible Solidity, so any AA wallet that enforces ERC-20 spending caps will work without protocol-side changes.