Paxiom
Paxiom · Technical Architecture · Drawing Set
AO Dispatcher Architecture
AO as distributed dispatcher for verifiable Ethereum proof work.
Project No.
PXM-001-T
Issue
T.01 / Rev. A
Date
2026.05.01
Drawn By
K. Luecke
Sheet T-000 · Cover & Index

AO as
distributed dispatcher.

The MU/SU/CU separation maps onto a sharded proving graph. Coordinator partitions Ethereum work into N shards; MU pushes each shard job; SU orders and persists every interaction to Arweave; N CUs run in parallel to build witnesses, generate proofs, and verify results. Aggregator processes recursively combine valid proofs. The proof corpus and the coordination history are both first-class artifacts on Arweave.

Document Type
Architecture Referencetopology, schemas, build order
Audience
Engineers & protocol reviewersand operators of the dispatcher
Status
Reference · Rev. Av0.4 of the architecture sketch
Series
T · Technical Architecturethe layer underneath A-series Phase 1
Companion Set
A · B · CA · M · OPhase 1, Narrative, Compliance, Audit Relay, Ops
Boundary
Composability claim onlynot a total-cost claim — see T-600
T-000
Cover & Indexthis sheet
T-100
Architecture Diagramcoordinator → MU → SU → CU → aggregator
T-200
Componentsseven roles in the dispatcher graph
T-300
Message Schemasjobs, results, manifests, receipts
T-400
Build Order for Benchmarkssix steps from segmentation to scaling
T-500
What to Expectrough ballparks before measurement
T-600
Boundary of the Claimcomposability, not total compute
T-700
Minimum Viable Proving Paththree deliverables, end-to-end
T-100 · Architecture Diagram

Coordinator, MU, SU, CU,
aggregator, Arweave.

The full dispatcher topology in one figure. Coordinator partitions; MU pushes; SU orders and persists; N CUs run all three workloads — witness, proof, verify — in parallel; aggregator combines results recursively to a root proof.

Components
AO-native process (MU / SU / CU)
External prover (fallback only)
Arweave persistence
Arrows
AO message flow
Persistence to Arweave
Fallback to external prover
PAXIOM COORDINATOR AO process · partitions chain into ranges ProofShardJob × N MU · MESSENGER UNIT routes / pushes message × N parallel shard processes each shard runs on its own CU SU · SCHEDULER UNIT assigns ordered slot · persists slot + msg ARWEAVE message history witness manifests proof lineage CU · COMPUTE UNIT witness · proof · verify — all CU-native, parallelized across N CUs WITNESS GEN read state build manifest PROOF GEN run circuit emit artifact VERIFY + EMIT check result emit outbox if needed EXTERNAL PROVER FALLBACK ONLY when CU exceeds capacity untrusted until verified artifact (CU verifies) ProofShardResult AGGREGATOR PROCESS CU receives left + right child proofs checks boundary · runs aggregation circuit (CU-native) emits AggregationResult recurse: aggregation tree at root of tree PROOF[GENESIS, HEAD] compact verifier-checkable artifact SUBSCRIBER · RISK SYSTEM · CLEARING LAYER
FIG. T-100.1AO dispatcher topology · partitioning, persistence, parallel proving, recursive aggregation

Blue arrows are AO message flow. Amber arrows are persistence to Arweave — every AO message hits the SU and lands on Arweave with an ordered slot, which is the proof lineage. The shard process runs in parallel across N CUs; the stacked outline behind the SU and CU boxes is the visual cue for parallelization. Witness generation, proof generation, and verification all run CU-native — for large ranges, building the witness is itself significant compute that is parallelized the same way proving is. Red dashed arrows are the fallback path to external prover services for workloads that exceed CU capacity; those returned artifacts are treated as untrusted until the CU verifies them against public inputs.

T-200 · Components

Seven roles in the dispatcher graph.

Five AO-native processes, one external-prover fallback, one persistence substrate. Each named with its responsibility, classified as AO-native, fallback, or persistence.

Component Responsibility Class
CoordinatorAO process Owns the segmentation manifest. Partitions Ethereum history into deterministic ranges under a versioned segmentation rule. Emits one ProofShardJob per segment with input commitment, witness manifest pointer, target proof system, and expected output schema. AO Native
MUMessenger Unit Recursive dispatcher. Pushes shard jobs into the network, routes results to aggregators, propagates retries and verifier receipts. Not the ALU — the wire. AO Native
SUScheduler Unit Assigns an ordered slot to every message and persists it. The persistence guarantee is what turns the dispatcher's message graph into a tamper-evident proof lineage. This is the moat primitive. AO Native
CUCompute Unit · primary prover Evaluates shard process state and runs all three workloads CU-native: builds the witness from Ethereum state (read state, build MPT paths, package manifest), generates the proof, verifies the result, emits outbox. The architecture parallelizes all three across many CUs — each handling one bounded shard — rather than concentrating any of them on one large machine. CU-native parallelized work is the moat; external provers are a fallback for workloads that exceed what a CU can handle, not the default path. AO Native
External Proverfallback only Used only when a shard exceeds CU capacity — heavy custom circuits, very large witness sets, or backends not yet portable to a CU environment. Backends like RISC Zero, SP1, or Expander run on external hardware (CPU, GPU, FPGA). The CU calls out with a witness manifest and treats the returned artifact as untrusted until verified against public inputs. The design intent is to minimize reliance on this path. Fallback
AggregatorAO process Consumes valid sibling proofs, checks the boundary commitment match (left.end_root == right.start_root), runs the recursive aggregation circuit (or delegates to external prover), emits one parent AggregationResult. Builds the tree level by level. AO Native
Arweavestorage substrate SU writes every message to Arweave with its slot. Witness manifests, proof artifact pointers, and the segmentation manifest itself live here. The lineage is the value, not just the proofs. Persistence
T-300 · Message Schemas

Six messages,
typed and persisted.

Every AO message in the dispatcher conforms to one of six schemas. Each is persisted to Arweave with an ordered slot; the schema corpus is the protocol's typed surface.

ProofShardJob
range:               [start, end]
input_commitment:    bytes32
witness_manifest:    ar://...
proof_system:        risc0 | sp1 | expander
output_schema:       eth-range-v0
segmentation_ver:    paxiom.seg.v1
parent_job_id:       opt
ProofShardResult
job_id:              ref
range:               [start, end]
proof_hash:          bytes32
proof_artifact:      ar://...
public_inputs:       bytes
output_commitment:   bytes32
prover_id:           opt
status:              valid | failed
AggregationJob
left_proof:          ref
right_proof:         ref
required_boundary:   left.end ==
                     right.start
aggregation_ckt:     v1
parent_range:        [L.start, R.end]
AggregationResult
job_id:              ref
aggregate_range:     [start, end]
aggregate_proof:     ar://...
aggregate_inputs:    bytes
tree_level:          int
status:              valid | failed
WitnessManifest
range:               [start, end]
state_reads:         ar://...
code_blobs:          ar://...
mpt_paths:           ar://...
data_commitment:     bytes32
VerifierReceipt
proof_ref:           ref
verifier_key_id:    ref to registry
verified:            bool
verifier_id:         opt
timestamp:           slot
T-400 · Build Order for Benchmarks

Six steps from segmentation
to scaling measurement.

Sequenced so each step's measurement informs the next. No step skips ahead of its measurement; no claim is made that a later step has not yet been validated.

  1. Pin the segmentation manifest and verifier key registry

    Write paxiom.segmentation.v1 as a JSON document on Arweave: how ranges are partitioned, which proof systems are accepted at which tree levels, which verifier keys are canonical. Every shard process anchors against this. This is the smallest possible first artifact and it locks the protocol shape.

    arweave write latency · doc retrieval latency
  2. Build one shard process for one predicate at one block

    Start from uniswap_v3_slot0 at a single block — it's a predicate already shipped. Wrap it as an AO process that accepts ProofShardJob and emits ProofShardResult. The CU evaluates the process, builds the witness (storage slot value + MPT path), runs the proof, verifies the result, returns the artifact pointer. No external prover at this stage. For slot0 the witness is small; for range shards it will be the bulk of the per-shard compute.

    round-trip latency: job emit → result on Arweave
  3. Instrument the dispatch path

    Add timestamps at: coordinator emit, MU push received, SU slot assigned, CU eval start, witness gen start, witness gen done, proof gen start, proof gen done, CU verification done, result message persisted. Separating witness from proof is what tells you which workload dominates per shard size — and which one to prioritize when you start optimizing.

    AO coordination latency vs witness time vs proof time vs verify time
  4. Range-extend the predicate

    Move from single-block slot0 to slot0_range over [A, B]. Same process, larger witness, larger proof. This is the first real shard — directly monetizable, exercises the full path, and is the smallest unit the clearing house's netting layer actually consumes.

    prover time as f(range size) · witness size as f(range)
  5. Build the aggregator process and prove two ranges combine

    New AO process that consumes two sibling ProofShardResult messages, validates boundary match, runs the aggregation circuit (RISC Zero recursion receipt or equivalent), emits a parent AggregationResult. Test with two adjacent slot0_range proofs.

    aggregation overhead per level (typically 1.2–2x sum of children)
  6. Scale to a tree and measure depth

    Run 4 → 8 → 16 → 32 shards in parallel across that many CUs. Plot wall-clock vs shard count and aggregation depth. The headline number is whether parallel CU proving actually scales linearly (or near it) with shard count. If yes, the architecture works as advertised; if not, a bottleneck has been found that's worth solving before the public claim.

    parallel scaling factor · tree depth scaling · projection to full chain
T-500 · What to Expect

Rough ballparks,
before measurement.

Order-of-magnitude expectations, not commitments. The actual numbers come from T-400; these are what to expect when running the steps and what to flag as anomalous if observed values diverge significantly.

AO dispatch overhead

MU push + SU slot + CU eval start, no proving work. Wire-time of the architecture itself.

~hundreds of ms per hop

Single MPT shard

One uniswap_v3_slot0 proof at one block on commodity hardware. Existing baseline.

p50 0.69s · p95 1.22s (measured)

Witness generation per shard

Reading state, building MPT paths, packaging the manifest. Trivial for slot0; significant for range shards. Worth measuring separately so the dominating workload is known.

measure separately from proof time

CU-native range shard

1000-block slot0_range proof running in a single CU. Variability driven by witness size, predicate complexity, and CU compute class.

measure first · highly workload-dependent

Aggregation per level

Combining two child proofs into one parent. Roughly fixed cost per level regardless of children's coverage.

seconds to minutes

Arweave persistence

SU writing a message + slot. Bundled writes amortize cost. Witness manifest writes are larger.

seconds per bundle

Genesis-to-head projection

Don't extrapolate until step 06 of the build order is done. Numbers from a real tree depth measurement are the only honest projection.

measure first · claim later
T-600 · Boundary of the Claim

Composability,
not total compute.

What this architecture claims and — equally important — what it does not. Read this sheet before extrapolating from T-500 to a public statement.

The design intent is that proof work runs on AO CUs in parallel — many lightweight CUs each handling one bounded shard, with recursive aggregation compressing the result. External provers exist as a fallback for workloads that exceed CU capacity, not as the default path.

This page does not claim that every historical Ethereum transition can be cheaply proven on commodity CUs today; some workloads will require the fallback path until CU-side proving capability matures, until shard sizing improves, or until aggregation circuits absorb more of the heavy work.

Boundary What is being claimed, and what is not T-600 / B.01

The composability claim is about who can participate in proving — many CUs in parallel rather than one big prover or one bonded marketplace — not about reducing total proving compute.

Total compute is what it is for a given proof system and predicate. The architecture's contribution is that the compute can be distributed across lightweight participants, with the persistence and ordering substrate (SU + Arweave) providing the audit trail that makes the distribution coherent.

T-700 · Minimum Viable Proving Path

Three deliverables,
end to end.

The smallest set of demonstrations that show the architecture works without yet claiming the full genesis-to-head ambition. Each one stands on its own as a publishable milestone and as a credibility artifact.

  1. Prove one bounded Ethereum state predicate

    Storage inclusion or uniswap_v3_slot0 verification against a known block state root. The verifier accepts the public input and proof artifact.

    verifier accepts artifact end-to-end
  2. Persist witness manifest and receipt lineage through AO

    Store the job, witness pointer, prover receipt, verifier result, and output commitment via AO/Arweave. Anyone can replay the proving event from public data.

    auditable replay path exists
  3. Aggregate two bounded ranges into one parent proof

    Combine sibling results only when boundary commitments match. The parent proof has a deterministic lineage traceable back to the segmentation manifest.

    range proof has deterministic lineage
Cross-reference Where this lands in the broader build T-700 / N.01

The architecture described here is the substrate beneath the A-Series Phase 1 service catalog. Service 02 (sync committee verification) is the first product to ship; its primitive is documented in O-700 BLS Sync Committee Primitive. The verifiable records produced by every dispatcher action are specified in CA.01 Verifiable Records Architecture.