You commit the network id, module parameters, guarantor set, opening accounts and state roots in one signed manifest, and every node re-verifies it at start. Bring state in through eleven fixed import sections, each reporting item counts and per-asset totals so you reconcile against a signed custody attestation before the manifest is accepted. Snapshots record a digest, and a snapshot that moves state across a migration loads only with a signed migration authorization.

What it does

Paxeer X starts a network from a signed genesis manifest that fixes the network id, the module parameters, the guarantor set, the opening accounts and the genesis state root. State carried in from an earlier system arrives through eleven fixed import sections, each of which reports its own item counts and per-asset totals so the result can be reconciled against a signed custody attestation before the manifest is accepted. Running nodes checkpoint into snapshot files whose digest must match the recorded manifest, and a snapshot that moves state across a migration is accepted only with an explicitly signed migration authorization. On the EVM base layer, the custody section of the chain genesis is generated separately and merged into the Paxeer genesis before the chain starts.

Key capabilities

• Signed genesis manifest with parameters, guarantors, accounts, module values and both state roots.
• Eleven import section kinds carrying items with per-asset totals for reconciliation.
• Custody attestation reconciliation that names the mismatching asset and the difference.
• Snapshot write and load with digest, state-root and module-blob checks.
• Signed migration authorization binding a new snapshot to the source snapshot digest.
• Custody genesis generation for the chain, with sequencer authorization and asset map.

Differentiators

A snapshot that changes state across a migration carries a 315-byte authorization signed by the genesis signer, covering the source global sequence, the source canonical and receipt state roots and the source snapshot digest; the node verifies it against the genesis manifest's signer public key and its own configured network id before the snapshot is used.

Outcomes

• A node cannot join a network built from different inputs
• Reconciliation names the mismatching asset and the difference
• A snapshot that misses the recorded roots is refused, not loaded

Technical notes

• Manifest bounds: 64 parameters, 32 guarantors, 256 accounts, 128 module values of up to 256 bytes each, 126 asset records, 262,144 bytes encoded. lxp_genesis_parse accepts only the manifest input kind and rejects a manifest whose envelope version and declared protocol version differ.
• Parameters, guarantors and accounts must be canonically sorted and de-duplicated. Every genesis account must be zero-balance, not locked, parentless, on the same asset, and its id must derive from its system name. Three fresh system accounts are required: system:fees, system:paxeer-reserve and system:paxeer-withdrawals.
• Modules are registered through a plan resolved from the manifest under four gates: always on, state-commitment version, custody profile, and an explicit enable flag.
• Import section kinds are fixed at eleven: balances, vault reserves, open holds, queued withdrawals, liquidity pools, insurance pools, perps positions, pending orders, funding state, DID-to-EVM bindings and historical commitments. Each holds at most 256 items and 32 asset totals.
• Snapshot files are written per global sequence as %020llu.lxs and are never overwritten. The store refuses a write whose rebuilt digest differs from the manifest (LXP_ERR_SNAPSHOT_MISMATCH, −902) and a legacy snapshot that omits the module-blob section while a Programs module is registered (LXP_ERR_SNAPSHOT_BLOBS_MISSING, −906). Headers are tagged LXS2 without a migration authorization and LXS3 with one.
• The genesis builder exposes two migration commands, --migrate-asset-v2 and --migrate-snapshot-issuance, alongside building artifacts with an optional --custody-profile.
• Chain-side, platform/hosted/paxeer/custody-genesis.py writes the layerxcustody genesis section that init-chain.sh merges: network id, one sequencer authorization with a batch range, withdrawal delay (default 3600 s), forced-exit delay (default 0 s), liveness bound (default 86400 s, minimum one hour), both delays capped at 90 days, and an asset map of ASSET_ID:DENOM[:POINTER]. deposit_root_authority is required and must be a nonzero 32-byte value; init-chain.sh refuses a custody genesis without it, because nothing sets that parameter after genesis in this bring-up. Paxeer-side genesis import can be streamed with genesis.stream-import and genesis.import-file, both off by default.
• Not yet in the node: the shadow divergence comparison and the legacy stream reader are built from tools/, not src/. Shadow comparison records up to 128 divergences across seven kinds (acceptance, ordering, balance, fee, result code, receipt, time source); the legacy reader opens a regular file read-only and refuses paths containing :// or .sql. Both are offline comparison tools, not node code paths.

More in Network