Modules

Modules

This page lists the modules registered in the LayerX kernel with their IDs, and shows how every monetary effect flows through a 402LXP transfer set.

A module ID is assigned at genesis, stable and never reused. It occupies the high 16 bits of activity_type; the low 16 bits are the activity ordinal. An unknown or disabled module is refused before execution.

Registered modules

ID	Module	What it does
0x01	asset	Asset registry, sends, receives, payer grants, mint and burn; emits 402LXP transfer sets and never calls set_balance
0x02	escrow	Terms live in module state; money moves only as 402LXP legs into and out of agent:<did>:escrow:<id>
0x03	budget	A funded ceiling, not a second wallet; delegation is a grant over that ceiling
0x04	stream	Pays continuously by time or by a signed meter; draws are 402LXP legs from agent:<did>:stream:<id>
0x05	service	Offers, agreements, attestations, delivery and disputes are module state; payment walks through 402LXP, typically an escrow the agreement names
0x06	perps	Positions, margin, funding, liquidation and insurance; losses and fees are transfer legs, and prices enter as signed ORACLE_PUSH activities
0x07	governance	Identity onboarding, key rotation, recovery-root updates, session-key grants, grant revocation, delegated allowances and sequencer handover
0x08	bridge	LXP_BRIDGE_CREDIT credits a proven Paxeer X chain deposit from system:paxeer-reserve; withdraw requests are asset ordinal 9
0x09	programs	Guest WASM execution (LXP_MODULE_PROGRAMS); monetary effects leave as 402LXP transfer sets
0x0A	spot	Two-asset limit and market orders on the shared perps price-time book (LXP_MODULE_SPOT); each fill settles both legs immediately through the asset module as 402LXP legs

Governance activities follow the same envelope, authority, ordering, fee and receipt rules as every other activity. The kernel's bridge module is separate from the chain's layerxBridge precompile (0x1016), which serves the bridge to Ethereum with layerx-bridge-relayer and PaxeerXVault.

Two surfaces have no module ID. Identity and authority are kernel state. Crossverse is an oracle adapter outside the kernel; its observations enter only as signed oracle activities.

The transfer-set rule

402LXP is the single financial doorway. lxp_apply_transfer_set is the only balance writer, and lx_ctx_emit_transfer_set is a module's only monetary capability.

A transfer set has 1 to LXP_MAX_LEGS legs. Each leg names from, to, asset, a non-zero amount, reason, module_id, leg_ordinal, context_hash and authority_hash. A set carries one authorization context, one actor sequence, one idempotency key and one receipt. It is atomic: if any leg violates an invariant, the whole set rolls back.

The ledger checks, in a fixed order so the failure code is deterministic: leg-count bound, non-zero amount, asset registered and unpaused, matching source and destination asset, neither endpoint frozen, authority over every debited account, exact actor sequence, unseen idempotency key, batch timestamp within expiry, net debit within balance, overflow-free credit, and per-asset conservation (Σ debits == Σ credits). No balance ever goes negative, and ordinary modules never mint and never burn. Every activity also pays its fee as a leg from agent:<actor>:main to system:fees.

Locked funds are ordinary named accounts, so every movement is a leg:

Action	From	To
Payment	payer agent:<did>:main	payee agent:<did>:main
Open escrow	agent:<did>:main	agent:<did>:escrow:<id>
Capture	agent:<did>:escrow:<id>	provider agent:<did>:main
Spend budget	agent:<did>:budget:<id>	recipient agent:<did>:main
Stream payment	agent:<did>:stream:<id>	recipient agent:<did>:main
Perps margin	agent:<did>:main	agent:<did>:margin:<position>
Deposit	system:paxeer-reserve	agent:<did>:main
Withdrawal	agent:<did>:main	system:paxeer-withdrawals

system:paxeer-reserve mirrors custody on the Paxeer X chain as an ordinary account, so deposits and withdrawals conserve value too.

Programs

Programs run guest WASM under the authority of the activity that invoked them and can never widen it.

• A program account is derived from program_id and a seed under a domain-separated hash. Derivation is not registration, funding or debit authority.
• A principal funds a program account through an ordinary Transfer402 grant; spending uses the separate, bounded ProgramSpend capability.
• Across a program-to-program call, a spending grant may only be narrowed.
• Every monetary effect a program produces is a 402LXP transfer set; programs never write balances.

See programs/README.md and the Programs reference.

Kernel boundary

Each module implements genesis, decode, validate (read-only), execute (effects to a buffer only), deterministic epoch hooks and state_root. Its context handle is its complete capability set: namespaced state, emit transfer set, emit event, batch timestamp and charge gas. There is no now(), random(), http() or set_balance().

Source: protocol design. See also Protocol, Finality, Payments and Fees.