Sync Committee Verification as a paid API.

It turns a beacon-chain verification into a machine-payable fact.

The API accepts a slot, block root, parent root, sync-committee bits, and aggregate signature. It validates the request shape, verifies the sync-committee evidence through the A-202 device path, records an evidence packet, and returns the verification response.

The commercial point is not that Paxiom replaces every RPC or data source. The point is that an agent, tool, or compliance workflow can pay for a specific verified claim and receive enough evidence to audit the answer later.

The first customer is Paxiom's own clearing layer.

Paxiom needs verified Ethereum consensus attestations before it can settle cross-chain obligations. A-202 is the first rehearsal interface for that internal need: HTTP for integration, x402 for payment, MCP for agent discovery, and a Paxiom platform signature for downstream audit trails.

The second customer is an outside agent, monitor, service, or compliance workflow that wants a paid, signed, replayable Ethereum sync-committee attestation without integrating BLS verification. This is not for light clients, consensus client operators, or teams that only want commodity BLS arithmetic.

Payment gates the work, not the mock.

The service refuses to start with both REQUIRE_X402=1 and MOCK_DEVICE=1. Mock responses are useful for local testing, but they are never billable. The paid path starts with BLS_DEVICE_VIA_SUBPROCESS=1 and moves to the HyperBEAM-hosted ~bls-sync-committee@1.0 device after registration is proven.

Success is defined before the wallet is configured.

The Base Sepolia rehearsal only counts as successful when a public unpaid call returns a valid 402 challenge, an MCP client can discover the tool metadata, a funded testnet wallet produces a real PAYMENT-SIGNATURE, the paid retry returns 200 with PAYMENT-RESPONSE, and the returned platform signature verifies against the published well-known key.

Partial outcomes are not treated as launch success. A working 402 challenge without settlement is only a gate test. A signed local response without a facilitator PAYMENT-RESPONSE is only a service test. A paid response without X-PAXIOM-SIGNATURE is not an A-202 attestation.

Unavailable is safer than fake.

If malformed traffic crashes the subprocess path, the rollback is to remove public routing or disable x402 exposure, restart the service under its supervisor, preserve logs and request hashes, and reproduce the crash locally. The rollback is never MOCK_DEVICE on a billable route.

If facilitator integration is broken, the symptom is concrete: a paid retry does not produce 200, PAYMENT-RESPONSE, and X-PAXIOM-SIGNATURE together. That state blocks the rehearsal. It is not papered over as a partial success.

The public surface is intentionally small.

POST /v1/sync-committee/verify
GET  /healthz
GET  /mcp/tools.json
GET  /mcp/paxiom-sync-committee.json
GET  /.well-known/paxiom-platform-pubkey.json

The paid route uses x402 v2 headers: PAYMENT-SIGNATURE on the retry, PAYMENT-REQUIRED on the challenge, and PAYMENT-RESPONSE after settlement. Unpaid calls receive 402 with payment requirements. Disabled or stubbed payment paths are labeled as not settled; MCP metadata remains public so agents can discover the tool before payment.

The product is the attestation, not the arithmetic.

Every paid 200 response includes a signed_payload, platform_signature, X-PAXIOM-SIGNATURE, and X-PAXIOM-SIGNED-PAYLOAD-HASH. Paxiom signs sha256(canonical_json(signed_payload)) with Ed25519. Before signing, the service rejects a device response whose slot does not match the request, preventing a verifier result for one slot from being wrapped as a response for another. The public key is published at /.well-known/paxiom-platform-pubkey.json.

The well-known key is the verification anchor. If it rotates, the replacement key is published with a new key_id, a rotated_at timestamp, and the previous key retained for old response verification.

// JavaScript
const keyDoc = await fetch('/.well-known/paxiom-platform-pubkey.json').then(r => r.json());
const b64 = s => Uint8Array.from(atob(s), c => c.charCodeAt(0));
const canonicalJson = v => Array.isArray(v) ? `[${v.map(canonicalJson).join(',')}]`
  : v && typeof v === 'object'
    ? `{${Object.keys(v).sort().map(k => `${JSON.stringify(k)}:${canonicalJson(v[k])}`).join(',')}}`
    : JSON.stringify(v);
const key = await crypto.subtle.importKey('spki', b64(keyDoc.public_key), 'Ed25519', false, ['verify']);
const digest = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(canonicalJson(response.signed_payload)));
const ok = await crypto.subtle.verify('Ed25519', key, b64(response.platform_signature), digest);

# Python
import base64, hashlib, json
from cryptography.hazmat.primitives import serialization
canonical = json.dumps(response["signed_payload"], sort_keys=True, separators=(",", ":")).encode()
digest = hashlib.sha256(canonical).digest()
pub = serialization.load_der_public_key(base64.b64decode(key_doc["public_key"]))
pub.verify(base64.b64decode(response["platform_signature"]), digest)

A-202 is packaged as an agent-payable attestation endpoint.

Boundless proves Ethereum consensus through a serverless ZK marketplace. Paxiom A-202 is a narrower product surface: pay per HTTP call, discover it through MCP, receive a Paxiom-signed attestation, and inspect the evidence packet. Boundless could package this shape too; A-202's claim is that it is being hardened now for agent and compliance workflows.

A modest endpoint is still a meaningful first revenue test.

A-202 is not the whole Paxiom quest. It is the smallest credible paid proof service: narrow input, clear output, existing real verification evidence, low price, and a route to MCP/x402 consumption. If it can take a real payment and return a real verified result, Paxiom has crossed from project narrative into revenue-capable infrastructure.