Paxiom emits permanent, public records of every coordinated protocol action. The architecture produces an audit trail as a byproduct of cross-chain coordination, not as a separate compliance overlay. This document specifies what is recorded, where, and how to verify it independently.
Coordination needs first; audit trail second. The two requirements are satisfied by the same artifact, and that is what makes the architecture work.
Paxiom coordinates state across multiple chains. To do so, every protocol action must produce a record that is durable, structured, and recoverable by parties who do not share Paxiom's runtime. The records described here exist for the protocol's own coordination needs first, and as a public audit trail second.
This document is intended for readers who need to verify Paxiom's behavior independently: counterparties, auditors, integrating protocols, and operators of the system itself. It assumes familiarity with EVM events, Arweave's permanence model, and the AO actor runtime; readers who need that grounding should reference the related documents listed in CA-700.
The implementation specified here is a proof of concept on public testnets. It demonstrates the recording and verification surface against the simplest viable loan structure ahead of more complex loan structures, verifiable chain access via HyperBEAM, ZK verification of execution traces, and mainnet deployment. The forward sequence is given in CA-600 Roadmap.
Two sources of record exist in the Paxiom system. The value of the architecture is the verifiable correspondence between them.
On-chain transaction logs on each operating chain are the canonical source of truth. Every protocol action that mutates state — pool borrows, repayments, fee distributions, OApp message sends and receipts — emits one or more events to the chain on which it occurred.
AO process state on Arweave is a permanent, structured mirror of those events. Each AO message records the originating chain, contract, transaction hash, block, timestamp, and event-specific fields, indexed for retrieval.
A reader queries either source independently and confirms the records agree. The procedure is specified in CA-500.
The first limitation — selective omission — is the substantive one and is addressed in the Paxiom roadmap by ZK verification of execution traces. CA.03 (forthcoming) will specify that layer. The remaining limitations are inherent to any on-chain system and are noted here for completeness rather than as defects of this architecture.
Five live components on public testnets. Two contracts on each operating chain, plus the AO Compliance Process and AO Consensus Process on Arweave. Mainnet equivalents pending per CA-600.
| Component | Network | Address / Process ID | Status |
|---|---|---|---|
| PaxiomOApp | Optimism Sepolia | 0x5fE0c2d112cf4E579271DD1f864C86dC193a1d0F | Live |
| PaxiomOApp | Base Sepolia | 0x607DB3774343Abc650Ef31d9414bCA9D24b0C254 | Live |
| PaxiomPool | Optimism Sepolia | 0x28321b5030B4E03ACCBD4236D1a97E01A7a9fc92 | Live |
| AO Compliance Process | Arweave / AO | w_MR7QlkfuRcfd3TQJPD1pzMwU5yEEyLMDjO0Ql8_5I | Live |
| AO Consensus Process | Arweave / AO | b-SlkvSm8FnADwSupRxlAXN6rezSnosjVakMmpfd_w0 | Live |
All addresses are testnet. Verification procedures in CA-500 use these addresses directly; readers should substitute mainnet addresses once D.01 (mainnet deployment) is complete.
The reference event is the first cross-chain loan settlement coordinated by Paxiom. Capital is deployed on both chains in parallel; execution is synchronized via the AO Compliance Process; a final data frame is written to Arweave as the permanent record.
The diagram below shows the architectural shape only. Concrete contract calls, message contents, and the per-chain execution sequence are pending and will be specified in Rev B.
The cycle proceeds in three phases.
The AO Compliance Process initiates execution by dispatching coordination signals to both chains. The two legs of the cycle are scheduled to execute in parallel rather than sequentially, removing the latency window in which one leg could complete without the other.
Each chain executes its leg locally, exchanging cross-chain messages via the LayerZero OApp where state on one chain depends on confirmation from the other. AO observes both legs as they progress.
Once both legs are confirmed, AO writes a single consolidated data frame to Arweave summarizing the cycle: the chains involved, the contracts called, the transaction hashes on each side, and the final state. The data frame is permanent and queryable independently of Paxiom-operated infrastructure.
AO normalizes custom tag names to lowercase on receipt. EventType becomes eventtype; TxHash becomes txhash. Queries against AO process state must use the lowercased forms. This is a property of the AO runtime, not of Paxiom; documentation that asserts the mixed-case tag names will fail to match.
A reader who does not trust Paxiom-operated infrastructure can verify any recorded event using only public infrastructure. The procedure is independent of any single block explorer or AO front-end.
Four steps. Both records must exist and agree for the event to be considered verified.
Query any RPC provider or public block explorer for the relevant chain using the contract address and transaction hash. Decode the event using the published contract ABI.
Query Arweave's GraphQL endpoint at https://arweave.net/graphql, filtering by the AO process ID and the event type tag (lowercased per CA-400 / N.01). The endpoint returns the AO message and its tags.
The txhash tag of the AO message must equal the on-chain transaction hash retrieved in step 1. If the values differ, the AO message does not correspond to the claimed on-chain action.
The event-specific fields in the AO message must equal the decoded fields of the on-chain event. If both sources exist and agree, the event is verified.
Both records exist and agree. The event is verified. This is the expected outcome for a healthy system.
Only the on-chain record exists. The AO mirror was not written. The event is treated as a recording gap. Operationally this should trigger an investigation into the AO Compliance Process; from a verification perspective the on-chain record stands as canonical.
Only the AO record exists. No corresponding on-chain transaction. The AO record is unverified and should be disregarded. An AO message without an anchor in chain state is, by definition, a claim about an action that did not occur.
A worked example with concrete tx hashes, AO message IDs, and a runnable GraphQL query will be added in the next revision. Until then, the procedure above can be exercised against any of the components listed in CA-300.
The implementation specified in this document is a proof of concept on public testnets. The following items are planned in sequence; each will be specified in its own document as it is implemented.
Companion documents in the Paxiom drawing set and external infrastructure this architecture depends on.
A-Series Phase 1 Blueprint. The build specification for the current phase. Service 02 (sync committee verification) is the first product to ship; this compliance architecture is the audit substrate it lands on. Open the Phase 1 Blueprint.
B-Series Project Narrative. The broader project context. Verifiable records sit within the larger Paxiom thesis at the level of architectural commitment. Open the Project Narrative.
O-Series Operations Runbook. Procedural infrastructure for incident response and routine operations. The recording surface specified here is the source of evidence for post-incident review per O-900. Open the Operations Runbook.
E-Series Key Custody & Identity. How signing authority is partitioned and rotated. Off-chain identity is explicitly out of scope for this architecture (per CA-200); the E-series specifies the layer that handles it. Open the Key Custody Blueprint.
F-Series Phase 2 Vision Brief. The forward arc. Phase 2 customers in regulated industries are the primary consumers of the audit posture this architecture establishes. Open the Phase 2 Vision Brief.
LayerZero OApp. The cross-chain messaging primitive used between operating chains. docs.layerzero.network.
AO & Arweave. Permanent storage and autonomous compute substrate that hosts the AO Compliance Process and AO Consensus Process. cookbook.arweave.dev.
Source code and deployment artifacts. github.com/k-luecke.
Rev. A — 2026.05.01. Initial issue. Seven sheets covering purpose, scope and limits, components, the cross-chain reference cycle, the independent verification procedure, the forward roadmap, and references. Status: testnet proof of concept.
Rev. B will add the worked verification example with concrete tx hashes, AO message IDs, and a runnable GraphQL query. Subsequent revisions will track mainnet deployment and the introduction of CA.02 (HyperBEAM-mediated chain access) and CA.03 (ZK execution-trace verification).