Unified Network Architecture
How Paxeer X combines EVM and Cosmos execution with LayerX activities, identity, programs, cryptographic proofs, and asset settlement.
The Network Model
Paxeer X is one network with two execution domains. The Paxeer domain is a Cosmos SDK chain with a native EVM, account and bank modules, staking, governance, token creation, and asset custody. The LayerX domain is a deterministic execution and accounting system for autonomous agents, economic activities, and WASM programs. Their shared network identity binds evidence to the intended network; the EVM chain ID is 125.
The domains exchange proof-bearing information. Native precompiles verify LayerX signatures, receipts, inclusion paths, and state witnesses inside Paxeer execution. Execution results cross the boundary as canonical evidence; a network request or local service database cannot authorize an asset release.
State and Authority
| State | Authoritative owner | How applications use it |
|---|---|---|
| EVM contracts and Cosmos balances | Paxeer application state committed by chain consensus | Contract calls, transactions, native modules and registered token pointers |
| Agent identities and delegated authority | LayerX identity kernel | DIDs, primary keys, sessions, scoped grants, recovery and revocation |
| Economic activity and balances | Ordered LayerX history and deterministic state; 402LXP writes balances | Receipts, replay, module queries and Merkle witnesses |
| Custodied assets | Paxeer custody module or the configured settlement contracts | Deposits, proof-backed withdrawal claims, nullifiers and exits |
| Checkpoint finality | Paxeer anchor state under guarantor and challenge rules | Finalized state roots, receipt roots and authorized batch ranges |
| Indexes and user interfaces | Projections of committed evidence | Search, account history and operational views, with receipts retained for verification |
The merger preserves these authorities. An address binding identifies the same participant across domains, while grants still determine the actions that participant or its delegates can perform. A verified signature establishes who signed evidence; the trusted checkpoint, authorization range, and application policy establish whether that evidence is acceptable for a specific operation.
From Intent to Committed Activity
Canonical Signed Activities
A LayerX state change uses an LXC/1 binary envelope containing protocol and network identifiers, activity type, actor DID, authority, account sequence, timestamp bounds, idempotency key, fee limit, payload binding, and signature. Fixed-width integers and canonical decoding keep independent executors in agreement. Time checks use the batch timestamp.
The kernel resolves authority, checks sequence and payload integrity, computes the fee, and executes the module inside a state journal. Successful execution commits its effects. An admitted operation that fails rolls back module effects while still recording its fee, sequence, and receipt. An admission refusal consumes neither fee nor sequence. An idempotent retry returns the original receipt without repeating the economic effect.
One Financial Doorway
402LXP is the sole balance writer. Payments, holds, escrow, budgets, streams, service agreements, trading, and programs produce validated transfer sets. Program-owned accounts are derived from public program identifiers and seeds; deriving an account grants no spending authority. Program-to-program grants narrow the permitted source, destination, asset, and amount.
Receipts, Replay and State Roots
Every admitted activity receives a global sequence and a signed receipt linked to the previous and resulting state roots. Replicas and guarantors replay ordered batches deterministically. The append-only history is authoritative, and indexes can be rebuilt from it. Portable receipt proofs let a verifier check evidence against independently trusted batch facts.
Native Connections Between Domains
| Precompile | Address suffix | Role |
|---|---|---|
| Addr | 0x1004 | Resolve Paxeer and EVM identities; bind and resolve LayerX DIDs and unified accounts. |
| LayerXVerify | 0x1012 | Stateless verification of signatures, receipts, inclusion, state witnesses and program discovery evidence. |
| LayerXCustody | 0x1013 | Hold native and registered assets; queue and pay verified withdrawals and forced exits. |
| LayerXAnchor | 0x1014 | Register checkpoints, availability attestations, guarantor bonds and challenges. |
| LayerXExchange | 0x1015 | Record trading, cancellation, settlement and margin intents for LayerX execution. |
| LayerXBridge | 0x1016 | Mint and burn bridged assets under registered-chain, attestor, threshold and cap rules. |
| Launchpad | 0x1017 | Create token markets and execute a native constant-product AMM on Paxeer. |
Each suffix identifies a 20-byte address padded with leading zeros. See Precompiles for contract interfaces. Exchange intents execute through the LayerX market domain; the launchpad curve executes locally on Paxeer. External-chain bridging uses attestor evidence and registered vaults, while the LayerX custody path connects activity accounting to assets held on Paxeer.
Unified Identity
A LayerX identity is rendered as did:layerx: followed by its 32-byte Ed25519 public key in lowercase hexadecimal. The canonical main account name is agent:did:layerx:<public-key>:main. The address precompile resolves the EVM address, Paxeer address, DID key, and derived LayerX main account together.
Binding requires both keys: the DID signs the binding domain, EVM chain ID, EVM address, and nonce; the EVM account submits the transaction. Bindings are one-to-one. Unbinding consumes a nonce, and previously signed binding messages cannot be replayed as a fresh association.
Checkpoint and Settlement Lifecycle
- Execute: LayerX orders activities, updates state and issues signed receipts.
- Batch: A signed header commits the sequence range, state roots, receipt root and availability commitment.
- Attest: Bonded guarantors replay the batch and provide checkpoint and availability evidence.
- Submit: A self-verifying certificate registers the checkpoint on Paxeer. Anyone can relay valid evidence.
- Finalize: The checkpoint continues the finalized chain, meets the active guarantor threshold, clears challenges and passes its challenge window.
- Release: Custody verifies a receipt or state witness against finalized evidence and applies the claim delay before payout.
The anchor status codes are 0 unknown, 1 submitted, and 2 final. A successful LayerX activity receipt, a submitted checkpoint, and a completed custody payout are different milestones. Applications display the milestone required by the action they offer.
Bonds, Challenges and Exits
Guarantors register bonds, increase stake, and unbond through a delayed process that keeps funds slashable until completion. Conflicting attestations provide equivocation evidence. Fraud and data-availability challenges prevent affected checkpoints from finalizing until resolved by the configured authority.
Withdrawals prove a signed receipt included in a finalized batch. Forced exits prove an entire eligible balance under the latest finalized state root and bind the recipient through the account authority. Emergency exits provide the custody emergency path. Nullifiers reserve and consume claims to prevent repeated payouts.
Developer and Service Boundaries
EVM applications use Ethereum-compatible tooling and JSON-RPC. LayerX applications submit activities and consume protocol receipts through their developer interfaces. The Paxeer custody boundary provides a TLS-protected JSON-RPC surface, checks the intended chain through client chain-identity verification, and accepts externally signed transactions. Signing authority stays with the participant.
Cross-domain workflows carry the actor identity, intended action, and resulting evidence through routing, execution, indexing, and settlement. A unified experience can present one account and one history while retaining the domain-specific receipt, EVM transaction, checkpoint, and custody-claim identifiers needed to audit each step.
Build Across the Whole System
- Compose agent commerce from identity, budgets, escrow, delivery attestations and receipt-backed payment.
- Build programmable businesses with WASM programs, program-owned accounts and bounded spending grants.
- Connect Solidity applications to verified agent execution and finalized LayerX state.
- Combine token launches, exchange activity and external-chain assets with explicit custody and settlement evidence.
Continue with Paxeer X and LayerX, Modules, Contracts, and Consensus.