
One network, two runtimes, one account
One network, two execution domains
The Paxeer EVM chain holds custody while the LayerX agent domain executes activity.
You address one network: EVM chain ID 125, one account that resolves to both an EVM address and a did:layerx identifier, and one endpoint that answers lx_* and px_* methods. Your agents execute inside the LayerX domain, while custody, disputes and emergency exits stay on the Paxeer EVM chain. Seven native precompiles at fixed addresses verify LayerX receipts, proofs, checkpoints and account bindings, so no bridge contract or message queue sits between the domains.
What it does
Paxeer X is one network whose work is split across two execution domains that run in different runtimes. The Paxeer EVM chain is a Cosmos SDK chain with a native EVM at chain ID 125, written in Go and built from node/, modules/ and precompiles/. LayerX is the agent domain, written in C under src/ and cmd/layerxd and in Rust under agent/, platform/, human/ and programs/; it produces signed receipts, batch headers, state proofs and checkpoint certificates. The two are joined by native precompiles running inside the Paxeer EVM that verify that evidence, rather than by a message queue or a bridge contract.
Key capabilities
- Both domains share one network identity; the Cosmos chain id
hyperpax_125-1maps to EVM chain ID 125. - Seven precompiles at fixed EVM addresses verify LayerX receipts, proofs, checkpoints and account bindings.
- One hosted endpoint serves
lx_*andpx_*methods and relays the eth, net and web3 namespaces. bindLayerXlinks one EVM address to onedid:layerxidentifier, requiring consent from both keys.- Ordinary agent activity executes on LayerX; periodic checkpoints settle custody and finality on Paxeer.
- Each domain keeps its own build system, release tag line and qualification gates.
Who it's for
Developers and operators who need to know which domain executes their code and which one holds the funds.
Why it matters
A caller addresses one network: one chain ID, one account that resolves to both an EVM address and a did:layerx identifier, and one endpoint that answers both domains' methods. Agent activity runs and is ordered inside LayerX, while custody, disputes and emergency exits stay on an EVM L1 whose state can be replayed independently of the LayerX sequencer.
Differentiators
The connector between the domains is a set of native precompiles inside the Paxeer EVM, not a bridge contract or a message queue. LayerXVerify, Addr, LayerXCustody and LayerXAnchor see only Paxeer state and calldata, and the layerxproof/codec and layerxproof/verify Go packages they use are pure, with no clock, no network and no database. Co-location in a single repository grants neither domain authority over the other: validator sets, deployment authority and custody semantics stay separate.
Outcomes
- Query both domains from one endpoint and one chain ID.
- Bind one EVM address to one did:layerx with consent from both keys.
- Keep funds on an L1 you can replay without the sequencer.
Technical notes
- EVM chain ID 125 is derived only from the Cosmos chain id
hyperpax_125-1. The hosted bring-up refuses any other value: "paxd derives EVM chain id 125 only from hyperpax_125-1". - Separate release tag lines:
vX.Y.Zfor LayerX,paxeer-network/vX.Y.Zfor the chain. Build entries are the rootMakefileandmake paxeer-build/paxeer-lint/paxeer-test/paxeer-ci.version.jsonreadsv6.1.12whilenode/tagsends atv6.6, so the two lines are not in step. - Three of the four named unification pieces are not implemented: a single account page that merges both domains automatically, end-to-end cross-domain intent routing, and light-client verification of Paxeer deposits on the LayerX side.
platform/hosted/indexeringests both chains into one store behind oneGET /v1/history/{account}shape, but a query is keyed by one domain's own identifier because the indexer does not resolve theAddrbinding between them.- Cross-domain intents exist only as a decoder:
human/crates/layerx-intents/src/precompile.rstypeslayerxexchange,layerxbridgeandlaunchpadevents into LayerX intents, and nothing in the tree calls that router outside its own tests. - The unified endpoint refuses node-side signing methods (
eth_accounts,eth_sendTransaction,eth_signand the rest) and EVM subscriptions rather than relaying them.
import { PxClient } from "paxeer-xdk";
const px = new PxClient({ endpoint: process.env.PAXEER_RPC_URL! });
const joined = await px.getAccount(process.env.ACCOUNT!);
console.log(joined.account.bound); // EVM address bound to a did:layerx
console.log(joined.paxeer?.balance); // Paxeer EVM chain side
console.log(joined.layerx); // LayerX agent domain sideMore in Network
Node distribution, registry and fleet staking
Install a node and find peers
ExplorePerformance as measured in repo artifacts
Every performance figure cites its file
ExploreSecurity policy and project governance
Report privately, read the residual risks
ExploreStaged finality ladder L0 to L4
Five finality steps, each with a liable party
ExploreBuild on Paxeer.
Give your agent a wallet, set its policy, and settle your first call on LayerX.