Paxiom
Paxiom · Public Index
Paxiom
A verification layer for the agent economy.
Project No. PXM-001· Issue: Public / Rev. A· Status: Testnet Hardening· Updated 2026.05.10

The substrate is being laid right now.

Paxiom is a verification layer for the agent economy. Phase 1 is hardening paid proof services that return signed response envelopes, verify state against Ethereum commitments, and keep payment/notary truth fields explicit.

The long-term direction is a Paxiom-owned historical proof archive: encrypted evidence on Arweave, AO-assisted proof work where safe, and no RPC provider treated as the authority.

Current Build State 2026.05.10
Designed
  • Phase 1 service map
  • Audit relay mechanics
  • Key custody model
  • Operations runbook
  • Build sequence
  • RPC trust boundary
In Progress
  • Reference implementation
  • AO dispatcher experiments
  • Proof job routing
  • Public repo structure
  • Service metadata
  • A-202 subprocess proof path
  • Encrypted proof archive design
  • Local Erigon proof warehouse sync
  • A-201/A-205 Erigon proof-source adapter
Not Claimed
  • Production uptime
  • Regulated custody
  • Mainnet-scale reliability
  • Enterprise deployment
  • Fully autonomous service market
What is being built

Verified facts, not unverifiable claims.

The agent economy needs a substrate where machines can transact across chains, services, and trust boundaries without inheriting blind trust in the service that answered. Paxiom is one specific bet on that substrate: x402-payable, MCP-callable attestations whose inputs are verified, whose computation can be replayed, and whose evidence trail is permanent.

The current build is explicit about what is and is not proven. Phase 1 services are testnet/reference software. Mock paths are refused in strict deployments, disabled payments are not called settled payments, and A-202 rejects device responses whose slot does not match the customer's request before the platform signs an envelope.

Paxiom's local historical-state path is now being exercised with Erigon running against a Google Drive-backed cold warehouse and a local hot tier. That path is allowed to be slow; it is not allowed to be trusted blindly. A-201 and A-205 are being wired to consume local eth_getProof witnesses and verify them before signing customer-facing envelopes.

The drawing set goes deeper. The Project Narrative explains the territory and the bet. The Phase 1 Blueprint details the five services that ship first. The Operations Runbook covers what happens on the days things go wrong, and the days they don't.

Phase 0 substrate. HyperBEAM bring-up scripts and the ~bls-sync-committee@1.0 device are written and tested in their companion repos; S.01 and S.02 are operator-evidence gates, while S.03 is being rebuilt around Paxiom-owned Ethereum L1 reconstruction. Load/Ultraviolet remains useful context, but the working direction is encrypted Arweave proof storage, AO-assisted compute, and local verification against Ethereum roots. See the gate status →

View the Drawing Set →
Why this exists

The proof is the point.

Most agent infrastructure being built today asks the consumer to trust the operator. Paxiom is built on the opposite assumption: data sources can be useful without being trusted. Every serious output should carry the evidence needed to verify it later.

This is a slower way to build. It requires substrate decisions — HyperBEAM dispatch, AO/Arweave audit, archive-node witnesses, encrypted proof storage, and signed response envelopes — that commodity API services don't make. The bet is that as agents begin paying for routes, proofs, simulations, and private opportunity feeds, the winning services will be the ones whose claims survive replay.