A working drawing set for the verified compute platform. The thesis is set. The architecture is anchored. What remains is to build, ship, and observe — in that order, on a timeline that matches the household.
Phase 1 is the engine. The moats — quantum-clean proving, IoT telemetry, medical compliance — come later. First the engine has to run.
Paxiom is a verified compute platform: agent-callable services that return cryptographically verifiable outputs. The deliverable is its own integrity check — buyers don't trust the platform, they verify what was sent. This is the structural property that distinguishes the category from every other agent service surface in the x402 ecosystem.
Phase 1 ships five services that overlap deliberately with what existing verified compute providers already sell. The strategy is not to out-Lagrange Lagrange as a general-purpose coprocessor. The strategy is to package verified facts as x402-payable, MCP-callable service responses with AO-anchored audit, permanent provenance, and no trust in the witness source. Revenue from the commoditized base funds the differentiated work that becomes the durable moat.
This sheet set covers Phase 1 only. Quantum-ready proving systems (Orion, Rokokko), HIPAA-grade ZK for personal data, IoT telemetry via SDF, and the broader marketplace integration via ERC-8183 are vision items referenced where relevant but not specified here. They are Phase 3 and beyond.
The framing shift from "API platform" to "agent-callable verified compute" resolves the long-running answer to what do you actually sell. APIs in the human-developer sense are commoditized. Agent-callable services in the x402 sense are a different product because the buyer is different, the discovery mechanism is different, and the pricing model is different.
Paxiom sells verifiable claims to autonomous agents over x402: small paid attestations, simulations, route checks, and proof packets that can be called through MCP, verified independently, and replayed from permanent evidence.
No marketing language. No investor pitch. No long-form competitive analysis. Those exist elsewhere or will be written when needed. This is a working drawing set for the build itself — what to ship, in what order, with what inputs and outputs, against what gates.
Every load-bearing dependency, named. The platform's architectural manifest.
HTTP-native payment protocol. Coinbase + Cloudflare + Stripe + AWS
backing. Reference facilitators on Base; community implementations
include x402-rs in Rust. V2 introduces lifecycle hooks
and plug-in chains/schemes. Linux Foundation x402 Foundation
announced as governance body.
v1 stance: Coinbase facilitator on Base. Single chain at launch.
Agent identity and reputation registry. Composes with x402 (payment) and ERC-8183 (escrow) as the Ethereum Foundation's agent commerce stack. KYA (Know Your Agent) is the broader category framing — RNWY, AgentFacts, Trulioo's Digital Agent Passport, Sumsub all building variants.
v1 stance: Naive primitive — signed responses, public key published, forward-compatible with ERC-8004 as standard matures.
Trustless escrow for agent-to-agent jobs. Job primitive with Client / Provider / Evaluator roles. Evaluator can be a smart contract that verifies cryptographic proofs — Paxiom is a candidate Evaluator for verification-gated jobs.
v1 stance: Don't integrate yet. Track the standard. Position Paxiom as a credible Evaluator candidate when the marketplace activates.
Erlang-based AO node implementation with device model. Devices used
by Paxiom: ~evm@1.0 (Revm-based EVM emulator),
~riscv-em@1.0 (RISC-V execution),
~greenzone@1.0 (TEE-attested execution).
v1 stance: HyperBEAM running locally is Phase 0 gate. All five services use it as substrate.
Permanent message log and storage. Every transaction Paxiom processes writes an audit record. This is the structural property that gives Paxiom audit-friendly compliance posture from day one without bolt-on infrastructure.
v1 stance: AO compliance process already deployed. Extend to log every Phase 1 service transaction.
Ethereum headers, proof packets, and encrypted witness bundles archived permanently on Arweave with Paxiom-controlled indexes and keys. Deterministic reconstruction of historical world state from archive. Eliminates blind RPC trust without publishing the full commercial proof corpus as a free public bypass.
v1 stance: Required for Service 5 (historical state). Useful enhancement for Services 1, 3. Load/Ultraviolet remains useful reference work, but this path does not wait on it.
Proving systems used or evaluated. Polyhedra Expander targeted for live recursion of state proofs. SP1 and RISC Zero remain as alternative proving backends. Quantum-clean alternatives (Orion, Rokokko) are Phase 5 — listed in vision, not Phase 1.
v1 stance: Pick one proving backend per service based on fit. Don't try to be polyglot at launch.
The agent commerce stack, with Paxiom located precisely. Not a substrate. Not a marketplace. A service operator with architectural advantages.
Three layers above Paxiom; three layers below. The layers above are the agent and its discovery surfaces. The layers below are the substrate that makes Paxiom's services possible. Paxiom occupies the service-provider slot in the middle, where verified outputs are produced and delivered to agents over x402.
Agent operators — the humans and organizations deploying agents. Configure which services agents can call, set spending limits, own the wallets agents transact through.
Agents themselves — autonomous software making real-time decisions about which services to call for which tasks. Not the marketing target. The runtime customer.
Discovery surfaces — MCP registries, x402 service indexes, agent framework plugin lists, AI lab default toolkits. Agents query these to find services that match capability requirements. Paxiom registers in the major ones at launch.
Five x402-gated endpoints. Each accepts a structured request, performs verified computation, returns a verifiable artifact, settles payment via facilitator. Wrapped in MCP for agent-framework discoverability. KYA-compatible through signed responses and published public key.
HyperBEAM compute — proof generation, simulation execution,
TEE-attested workloads. Devices: ~evm@1.0, ~riscv-em@1.0,
~greenzone@1.0.
AO messaging + persistence — orchestration between processes, permanent audit trail of every transaction, Arweave-backed log of all platform activity.
Paxiom proof archive — encrypted Arweave-resident Ethereum headers, proof packets, witness bundles, and archival evidence, indexed by Paxiom. The piece that makes state-related services replayable without turning public storage into a free bypass around the paid service.
Other verified compute providers prove things about RPC-sourced data. Paxiom proves things about archive-anchored data.
Other agent services produce outputs that buyers can't verify. Paxiom produces outputs that are themselves verification artifacts.
Other platforms add audit trails as a feature. Paxiom has them as a structural property of the substrate.
What happens when an agent calls a Paxiom endpoint, step by step. The same path for every service in the catalog.
If step 7 succeeds but step 9 fails (network drop, server crash), the agent will retry. The retry must return the same verified output without re-charging. Key off the payment ID — same payment, same response, no double-charge.
For services where compute can fail on bad input (Service 5 in particular), validate inputs before /settle. Refund or do not charge for failed proof generation. The deferred settlement scheme handles this elegantly — cryptographic commit at request time, actual settlement at end-of-period after success.
The substrate that exists before service work begins. Some deployed, some pending. Phase 1 cannot begin without these in place.
PaxiomOApp on Optimism Sepolia and Base Sepolia. LayerZero V2 OApp contracts, peered, with confirmed cross-chain messaging. From the prior arbitrage architecture; usable as cross-chain substrate for Service 3 if needed.
PaxiomPool on Optimism Sepolia. First loan cycle completed, protocol fees collected and distributed. Demonstrates protocol-fee revenue mechanism is operational. Not load-bearing for Phase 1 services but proven infrastructure.
AO compliance process. Logging contract deployments, cross-chain
messages, loan cycles. Process ID: w_MR7QlkfuRcfd3TQJPD1pzMwU5yEEyLMDjO0Ql8_5I.
Extend to log Phase 1 service transactions. Lowercase tag-name quirk documented.
AO opportunity monitor. Process ID:
JbsXrqoy26CAE8_agv9ZX2aeL8-ec06yGETP7-6IvUg. From arbitrage architecture;
not a Phase 1 proof service by itself, but relevant as a pattern for private
opportunity feeds: AO can coordinate cross-chain observation and settlement,
while x402/MCP can sell the resulting route, simulation, or attestation.
AO mainnet consensus process. Process ID:
b-SlkvSm8FnADwSupRxlAXN6rezSnosjVakMmpfd_w0. Stores Ethereum
consensus data (slot 13883119, state root confirmed). Substrate for Service 2.
rebar3 shell opens successfully. ~evm@1.0 device
executable. Confirmed message dispatch through hb_ao.
This is the first gate. Until HyperBEAM runs locally, nothing else
in Phase 1 is buildable. Estimated time: days, not weeks, if the
environment cooperates. Source: github.com/permaweb/HyperBEAM.
The Rust sync committee verifier exists on a local machine. It needs to be located, reviewed, and confirmed working before Service 2 can be the fast-launch path. If it's missing or broken, Service 2 timeline extends meaningfully.
One Ethereum L1 historical state query verifies end-to-end: an Erigon/Reth MPT witness, state root anchored by the sync committee verifier, and proof packet/evidence written to encrypted Arweave storage with Paxiom-controlled index metadata. Required for Service 5; useful for Services 1 and 3.
Stub endpoint that accepts an x402 request, forwards signature to Coinbase facilitator, receives verification, returns hardcoded response, settles payment. End-to-end on Base testnet. Validates the integration pattern before any real service logic ships.
Generate platform signing keypair. Publish public key on:
paxiom.org, GitHub k-luecke/paxiom, AO via dedicated
process, Arweave manifest. Sign every service response with private key.
Document verification procedure in service spec. Forward-compatible with
ERC-8004 when the standard matures.
ZK proof that a contract storage slot held a specific value at a specific block. The canonical "verified state" use case. Direct competition with Lagrange, Axiom, Herodotus.
Contract address, storage slot (bytes32), block number. Optional: chain identifier (default Ethereum mainnet, expand later).
Groth16 or Plonky-family proof artifact (depending on backend), verifiable on-chain at <400k gas. Public inputs: contract address, slot, block, claimed value. Response signed with platform key.
SP1 or RISC Zero guest program performing Merkle inclusion against the block state root. Witness data comes from Erigon/Reth for sovereign reads; any RPC-like transport is treated as convenience only, never as authority. Encrypted Arweave storage holds the header, proof packet, and evidence needed for cold replay.
Existing providers commonly depend on opaque RPC/indexer trust for inputs. Paxiom's moat is the composition: sync-committee-anchored state roots, MPT-verified witnesses, AO-replayable verification, and permanent encrypted Arweave evidence. Marketing: "the proof is replayable from the evidence trail, not just signed by a service."
Moderate. Proving math is well-understood; you're integrating components rather than inventing them. Estimated 4–6 weeks at focused pace once Phase 0 gates are clear.
Ethereum beacon chain consensus light-client primitive. The fastest path to first revenue if the existing Rust verifier code is recoverable.
Beacon chain slot number. Optionally: claimed header hash, claimed state root for verification rather than retrieval.
Proof that the sync committee for that slot signed the specified header. Public inputs: slot, header hash, sync committee root. Verifiable on-chain or in-application. Response signed with platform key.
Existing Rust verifier (40KB WASM), located in Phase 0. Wraps BLS aggregate signature verification over BLS12-381 with SHA-256 Merkle proof checks. Compact because it doesn't pull the full ark-relations stack.
The differentiator is packaging, not invention of the primitive. Telepathy, Helios, and Polyhedra serve this need but require SDK integration rather than paid, agent-callable HTTP. Paxiom wraps the capability as an x402/MCP service with evidence and audit attached.
Lowest of the five. Existing code wrapped in x402 endpoint, AO orchestration for audit, MCP server for discovery. Estimated 4–6 weeks at focused pace, conditional on locating working verifier.
Speed to first transaction matters more than perfection at launch. Service 2 reaches "first paying customer" fastest. Validates the x402 + AO + MCP integration pattern. Every subsequent service reuses what's built here.
Bridge-grade attestation. Higher complexity, higher price, narrower customer base. The Kelp DAO incident is the marketing case study.
Source chain ID, source transaction hash or message ID, destination chain ID, claim about the message contents.
Proof that the message exists in the source chain's canonical state with the claimed contents. Verifiable on the destination chain. Response signed with platform key.
Composes Service 1 (state proof on source chain) with destination-chain verification logic. Requires a verifiable witness source and permanent evidence trail for the source chain. Multi-chain support adds operational complexity beyond single-chain services.
The Kelp DAO attack on April 18, 2026 drained $292M because a LayerZero DVN was fed false data via compromised RPC infrastructure. Paxiom's witness-verification architecture is aimed directly at that failure mode. The marketing pitch writes itself: verification that doesn't depend on the trust assumption that just failed.
High. Bridges have strict correctness requirements; mistakes in this category lose hundreds of millions. Estimated 6–10 weeks. Ships last in Phase 1.
Reference: Chainalysis post-mortem of Kelp DAO incident, April 2026. "This was not a smart contract hack, but a sophisticated attack on off-chain infrastructure. The attackers compromised internal RPC nodes and DDoS'd external nodes to feed false data to a single-point-of-failure verification network."
High-volume, low-price. Agents simulating before they commit. TEE-attested execution via greenzone is the upsell.
Sender address, target contract, calldata, value, optional block number for state context. Optional: TEE attestation request flag.
Execution result, gas used, state changes, event logs. With TEE flag: attestation chain proving execution happened in genuine hardware running registered code. Response signed with platform key.
HyperBEAM ~evm@1.0 device for execution. Optional
~greenzone@1.0 wrapping for TEE attestation. The
platform's natural fit — HyperBEAM was built for this class of
workload.
Tenderly, Alchemy simulation API, Foundry tooling all exist but are RPC-based and not verified. TEE-attested simulation is a meaningful upsell over unverified alternatives. Volume economics work because per-simulation cost is genuinely low.
Moderate, gated entirely on HyperBEAM Phase 0. Once
~evm@1.0 is operational, wrapping it in x402 is
straightforward. Estimated 3–5 weeks after Phase 0 clears.
The differentiated companion to the commoditized base. Where verified witnesses, permanent evidence, and replayable answers matter most. Where Paxiom's identity gets established.
Initial query types (v1):
— ERC-20 balance for an address at a historical block.
— Contract storage slot value at a historical block.
— Event log presence and contents at a historical block.
Expand query catalog based on early customer demand. Don't try to be general at launch.
Verified answer plus proof artifact. Public inputs include the block number, block hash (canonically attested), and the claimed value. Response signed with platform key. Audit record on Arweave permanently.
Erigon or Reth provides the sovereign eth_getProof/MPT witness
path. The verifier checks the witness against a sync-committee-trusted
state root. Encrypted Arweave storage holds the proof packet, header, and
archival evidence so the answer can be audited and replayed later without
exposing the full archive as a public bypass.
This is where Paxiom is genuinely rare. Most existing providers can answer historical-state queries, but the derivation trail is not usually permanent and replayable by default. Paxiom separates live witness retrieval from trust: the archive node can provide data, but the MPT verifier and sync-committee header decide whether it is true, and the Paxiom proof archive keeps the evidence trail.
Higher than Services 1 and 2. Requires archive-node operation, MPT verification, evidence-packet design, and encrypted Arweave persistence. Estimated 6–8 weeks. Ships in middle of Phase 1, after Service 2 has validated the launch pattern.
Compliance teams, audit firms, regulatory reporting use cases, historical analysis for institutional buyers. These are higher-value customers than the average x402 traffic — willing to pay more, sign B2B contracts, integrate deeply. Service 5 is the primary bridge from Phase 1 commoditized revenue to Phase 4 enterprise sales.
Realistic case. Not best, not worst. The scenario for which the build plan is calibrated.
| ID | Service | Vol/Mo | Price | Gross | Var. Cost | Net |
|---|---|---|---|---|---|---|
| A-201 | Slot Storage Proofs | 800 | $1.00 | $800 | $246 | $554 |
| A-202 | Sync Committee Verification | 1,500 | $0.50 | $750 | $159 | $591 |
| A-203 | Cross-Chain Message Verification | 200 | $3.00 | $600 | $122 | $478 |
| A-204 | Simulation as a Service | 8,000 | $0.05 | $400 | $56 | $344 |
| A-205 | Verified Historical State | 300 | $2.00 | $600 | $122 | $478 |
| — | Phase 1 Total | 10,800 | — | $3,150 | $705 | $2,445 |
Fixed monthly infrastructure: $100. Net monthly profit at this scenario: $2,345. Annualized run rate: ~$28k/year.
This sits at the floor of "could go full-time." It does not provide comfortable margin above the floor. Reaching comfortable margin requires either traffic growth above the realistic case, the addition of a B2B contract, or expansion into Phase 2 services.
High-volume services drive upside. If sync committee and simulation traffic doubles, monthly gross ~$4,500.
Compute cost is the main expense. Spot GPU pricing can cut compute 30–50% with operational care.
Pricing is iterative. Launch numbers are starting points. Adjust based on observed customer behavior at month 3, month 6, month 9.
One B2B contract changes everything. A single enterprise customer at $5–10k/month doubles or triples the run rate.
What ships in what order, with what dependencies, against what decision points. The discipline: all five earning before runway is touched.
HyperBEAM running locally. Sync committee verifier located. L1 evidence/reconstruction path tested. x402 facilitator stub working on Base testnet. KYA keypair generated and public key published.
Estimated: 2–4 weeks at evening pace, faster with focused weekend blocks. Decision: If gates don't clear in 6 weeks, reassess. Either rebuild missing pieces, or pivot Phase 1 scope to what's actually achievable.
Sync committee verification operational on Base mainnet. x402-gated. MCP-wrapped. Registered in major directories. First paying transaction recorded.
Estimated: 4–6 weeks after Gate 0 clears. Decision: If realistic-case traffic materializes within 30 days of launch (50+ transactions/month from non-test sources), proceed with Service 4. If not, diagnose discovery problem before building further services.
Simulation as a service operational. ~evm@1.0 wrapped in x402.
Optional TEE attestation tier via ~greenzone@1.0. Together with
Service 2, two endpoints generating real (small) revenue.
Estimated: 3–5 weeks after Gate 1. Combined timeline from Gate 0: roughly 9–15 weeks.
Slot storage proofs and verified historical state both operational. The commoditized-and-differentiated pair that defines Paxiom's identity in the verified compute category.
Estimated: 6–8 weeks each, can run partially in parallel. Combined timeline from Gate 0: roughly 16–24 weeks.
Cross-chain message verification operational. The bridge-grade service. The Kelp DAO marketing case study activated.
Estimated: 6–10 weeks. Combined timeline from Gate 0: roughly 22–34 weeks. This is the all-five-earning trigger.
All five services operational and earning. 3+ months of traffic data on the earliest services, 1+ months on the latest. Run rate visible against realistic-case projections.
If run rate ≥ $30k/year annualized: leave the day job, full-time on Phase 2 expansion and B2B sales.
If run rate < $30k/year but trending up: continue side-pace, reassess in 90 days.
If run rate flat or declining: diagnose. Possible causes — wrong pricing, wrong category, wrong discovery channels, broader x402 ecosystem stagnation. Pivot or iterate based on diagnosis.
Known failure modes, watch-fors, and the planned response for each. Better to have these named on a sheet than discovered in production.
The Rust verifier on the local machine is incomplete, broken, or depends on libraries that have moved on. Service 2 launch timeline extends from 4–6 weeks to 12+ weeks while the verifier is rebuilt.
Mitigation: Locate and test the verifier in week 1 of Phase 0, before committing to Service 2 as the fast-launch path. If broken, swap launch order — Service 4 (simulation) becomes the fastest-ship instead.
Phase 1 launches on schedule but agents don't actually call the services at projected volumes. Pessimistic-case revenue persists through month 9. Run rate stays below $30k/year floor.
Mitigation: Outbound sales effort during build, not just after launch. Identify 5–10 specific organizations that would benefit from each service, reach out before launch, line up early customers. Treat traffic from cold inbound as a bonus, not a plan.
x402 transaction volume stays at current $28k/day instead of growing 5–10x as projected. The agent commerce thesis underperforms. Phase 1 services exist but the addressable market doesn't expand.
Mitigation: Architectural choices that work even if x402 itself stalls. The verified compute capabilities Paxiom builds are valuable to non-x402 customers via direct B2B integration. Phase 4 enterprise sales motion does not require x402 ecosystem growth to succeed.
Build pace at planned intensity is sustainable for weeks but not indefinitely. Errors in customer relationships, security decisions, or strategic choices compound when made under sustained fatigue.
Mitigation: Reserve weekends for the technical work where pace matters most. Slow down on the surfaces where errors are expensive — security audit before mainnet, customer contract terms, pricing decisions. Health check at month 3 and 6.
Lagrange, Succinct, RISC Zero, or another established provider decides to ship x402-native endpoints during Paxiom's Phase 1 build. The first-mover advantage in agent-native verified compute disappears.
Mitigation: The architectural moat is not x402 alone. It is the package: no trust in the witness source, AO-anchored audit, permanent evidence, KYA-compatible identity, and MCP-readable product packaging. Competitors can add payment endpoints faster than they can retrofit replayable evidence as a native property.
Regulatory framework or major customer demands force KYA compliance that exceeds the v1 naive primitive. Retrofit work delays Phase 2 or compromises customer relationships.
Mitigation: The naive primitive is forward-compatible with ERC-8004. Track the standards (Trulioo DAP, AgentFacts, Sumsub framework) quarterly. Upgrade path is incremental, not rebuild.
Used for x402, ERC-8004, ERC-8183, HyperBEAM, AO, Arweave proof storage, proving systems.
Used for technical requirements that must be met for Phase 1 to proceed.
Used for non-binding observations, references to other documents, or explanations of why a decision was made.
Used for things that will damage Phase 1 if not handled correctly. Read these carefully.
A-000 series: Architecturals (this set).
Future revisions may add S-000 for Structural (security audit
findings), M-000 for Mechanical (operational runbooks),
E-000 for Electrical (signing key management).
Rev. A — 2026.04.29. Initial Phase 1 issue. Five services specified. Pro forma at month 9 steady state. Build sequence with four gates. Risk register with six entries.
Subsequent revisions will be issued as Phase 1 build progresses. Rev. B expected at Gate 1 (Service 2 live).
Build journal — narrative record of what was built and when. Currently covers pre-Phase-1 arbitrage architecture and audit pass. Phase 1 entries forthcoming.
Build map (Phase 0–5) — strategic positioning across all phases. This Phase 1 blueprint sits inside Phase 2 of the build map's phasing. Build map covers vision; this blueprint covers execution.
Architecture document v0.4 — earlier substrate documentation from arbitrage-execution era. Relevant background; superseded for Phase 1 purposes by this set.
This is a working drawing. It is not the truth. It is the best plan available on the day it was issued, against the information then in hand. The platform that actually gets built will deviate from this set in ways that won't be knowable until the work begins. That is normal. The set's job is to make the deviations legible — when reality differs from the drawing, the drawing is what gets revised.
Build the engine first. The moats come later.