One network, two execution domains

A network built for software that transacts has two jobs that pull in different directions. It needs a general-purpose base layer where contracts, custody and markets live. It also needs a place where agents can submit many small, signed activities and get a receipt back without waiting on a block.

Paxeer X does not force both jobs into one runtime. It runs two execution domains under one network identity: the Paxeer X chain and LayerX.

The Paxeer X chain

The chain is the EVM base layer. It is a Cosmos SDK chain with CometBFT consensus, run by the paxd node, and it executes EVM bytecode through go-ethereum’s state transition. Its EVM chain ID is 125, bound to the Cosmos chain identifier hyperpax_125-1 and nothing else.

What that means in practice:

• Ethereum toolchains address the chain over the standard JSON-RPC namespaces, so contracts, wallets and libraries need no translation layer.
• Consensus is BFT, so each committed block is final.
• Native modules sit behind precompiles at fixed addresses. A Solidity contract can call staking, governance or LayerX custody directly, with no bridge contract in between.

The chain holds custody, disputes and emergency exits. Its state can be replayed independently of anything that happens in the agent domain.

LayerX, the agent domain

LayerX is where ordinary agent activity executes. Its kernel, layerxd, is written in C17 and built to be deterministic: consensus execution forbids floating point, local clocks and unstable iteration, so two honest machines running the same batch reach the same bytes.

Every action in LayerX is submitted as the same signed envelope and returns a signed receipt. A single sequencer orders activities into batches. Each sealed batch header commits to the activities, receipts, events, data availability and oracle inputs of that batch, along with the state root before and after.

The domain is shaped around what agents need:

• Typed accounts per agent: main, budget, escrow, stream, margin and per-asset holdings.
• Spend budgets with period caps, session keys bounded by scope and expiry, escrow holds and payment streams.
• Per-call HTTP payments through 402LXP, with x402-compatible middleware.
• Idempotent submission, so a retry returns the original receipt rather than executing twice.

How the two domains meet

Two runtimes are only useful if they can trust each other’s evidence. Paxeer X joins them with native precompiles running inside the Paxeer X chain, not with a message queue or a bridge contract.

Seven precompiles at fixed EVM addresses verify LayerX receipts, proofs, checkpoints and account bindings. The packages they rely on are pure: no clock, no network access, no database. They see only chain state and calldata.

Settlement flows in one direction. LayerX batches roll up into checkpoints. A checkpoint carries the state root, receipt root and data-availability root of a contiguous run of activity, signed by the sequencer and attested by a quorum of bonded guarantors. The chain verifies both, records the checkpoint, and finalizes it once its quorum, continuity and challenge rules hold. A contract on the chain can then read a batch’s finalized state root and receipt root directly.

One account across both

A person should not have to keep two unrelated accounts to use one network. Paxeer X binds an EVM address to a did:layerx identity, and both keys must consent: the EVM side by sending the transaction, the DID side by signing a domain-separated message over the chain ID, the address and a nonce.

Once bound, a single read returns the EVM address, the DID key and the LayerX main account together. A wallet can show chain balances beside agent activity from one call.

It is worth being exact about what this is. It is a binding plus a joined view. Each domain still keeps its own balances and its own state.

One endpoint, method name picks the domain

The hosted gateway serves LayerX methods (lx_*), cross-domain reads (px_*) and relays the standard eth, net and web3 namespaces. A caller talks to one endpoint and the method name decides which domain answers. That gateway opens with the limited beta.

Why keep them separate

Putting both domains in one network does not give either authority over the other. Validator sets, deployment authority and custody semantics stay separate. Each domain keeps its own build system, release line and qualification gates.

The separation is deliberate, and it buys three things:

• Each runtime does what it is good at. The chain runs general contracts and holds custody. LayerX runs a narrow, deterministic set of agent modules.
• Failures stay contained. If the LayerX sequencer is unavailable, new agent activities stop rather than being ordered out of band. Custody and exits remain on the chain.
• Evidence is checkable from either side. A LayerX receipt can be verified offline, and the checkpoint that covers it can be read by any contract on the chain.

What it means for builders

If you write Solidity, you deploy to chain ID 125 with the tools you already use. If you build agents, you work against LayerX through the SDKs, the CLI or MCP. If you build both, one bound account and one endpoint cover the whole network.

The documentation describes each domain in detail, and the source is public on GitHub.