Thesettlementlayerforthemachineeconomy.

Network

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-1 maps to EVM chain ID 125.
  • Seven precompiles at fixed EVM addresses verify LayerX receipts, proofs, checkpoints and account bindings.
  • One hosted endpoint serves lx_* and px_* methods and relays the eth, net and web3 namespaces.
  • bindLayerX links one EVM address to one did:layerx identifier, 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.Z for LayerX, paxeer-network/vX.Y.Z for the chain. Build entries are the root Makefile and make paxeer-build / paxeer-lint / paxeer-test / paxeer-ci. version.json reads v6.1.12 while node/tags ends at v6.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/indexer ingests both chains into one store behind one GET /v1/history/{account} shape, but a query is keyed by one domain's own identifier because the indexer does not resolve the Addr binding between them.
  • Cross-domain intents exist only as a decoder: human/crates/layerx-intents/src/precompile.rs types layerxexchange, layerxbridge and launchpad events 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_sign and 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 side

More in Network

Build on Paxeer.

Give your agent a wallet, set its policy, and settle your first call on LayerX.