Repository navigation
Protocol
This page covers how the LayerX kernel, the agent-native execution domain of Paxeer X Network, admits, orders and executes activities, returns receipts, and connects to the Paxeer X chain.
Paxeer X Network is one network with two execution domains behind one interface. Both live in the Sidiora Labs monorepo, and each keeps its own build, release and trust boundary.
| Domain | Node | Responsibilities |
|---|---|---|
| Paxeer X chain |
paxd (Go), EVM chain ID 125
|
EVM JSON-RPC, Tendermint consensus and an OCC parallel executor; asset custody, deposits and withdrawals, checkpoint registration, guarantor bonds, slashing, emergency exits and dispute resolution |
| LayerX kernel |
layerxd (C17) |
Agent identities and delegated authority, activity ordering, execution, balances (402LXP), receipts, data availability and replay |
EVM precompiles join the domains on the chain side. layerx-guarantor submits checkpoints to layerxAnchor (0x1014) with submitCheckpoint. layerxCustody (0x1013), layerxExchange (0x1015), layerxBridge (0x1016) and launchpad (0x1017) front the chain's custody, exchange, bridge and launchpad modules, and layerx-intents decodes exchange intent logs into activities. On the platform side, layerx-gateway relays eth_* calls to the chain and serves px_* and lx_* reads.
An ordinary action in the LayerX kernel never requires a Paxeer X chain transaction. Thousands or millions of activities collapse into one periodic checkpoint, which settles on the chain (Finality).
Every state-changing operation enters as one signed activity: a payment, an escrow capture, a budget spend, a service delivery, a perps order, a governance change, a bridge credit or a program call. The envelope carries exactly these fields; a missing, repeated or undeclared field is a malformed envelope.
| Field | Rule |
|---|---|
protocol_version |
Supported by the executing transition version; beta envelopes use protocol 3 |
network_id |
Equals the executing network's ID, so an envelope is valid on one network only |
activity_type |
High 16 bits are the module ID, low 16 bits the activity ordinal |
actor_did |
Resolves to an identity that is active or recovering and not frozen |
authority |
Resolves to a live authority whose scope admits activity_type, whose not_after has not passed and whose revocation_sequence is current |
account_sequence |
Exactly the actor's next sequence; lower is a replay, higher is a gap |
timestamp_bound |
not_before and not_after; the batch timestamp must fall inside, and no node clock is consulted |
idempotency_key |
A repeat returns the stored receipt with no new effect |
fee_limit |
Ceiling for the computed fee |
payload_hash, payload
|
Module-specific body; the hash is checked before the payload is parsed |
signature |
Ed25519 over the domain-separated canonical encoding of every other field |
The wire format is LXC/1, a canonical binary encoding: fixed-width big-endian integers, no optional fields, no maps and no floating point. Decoding is total, trailing bytes are an error, and re-encoding a decoded value yields the same bytes.
Identity and authority are kernel state, not a module. Agent DIDs are the native account identity, and authorization is part of the state machine: primary keys, session keys, scoped capability grants, rotation, recovery, revocation and expiry. An amendment may only narrow a grant, bumping revocation_sequence invalidates every grant issued under the old value, and retiring an identity requires a zero balance sheet. Crossverse is an oracle adapter outside the kernel: observations enter only as signed oracle activities, and no state transition contacts an external source.
One sequencer is active at a time and assigns one global sequence. It starts at 1 in the genesis batch and increases by exactly 1 for every sequenced activity; it never resets, skips or repeats. Exactly one writer assigns sequences and applies transitions. Order inside a batch is assignment order, with no reordering pass and no fee auction in v1.
- An activity that fails admission (bad version or network, unknown type, bad payload hash or size, invalid signature, unknown actor, wrong account sequence, or a timestamp bound outside the batch) gets no sequence, no receipt and no fee, and never appears in history.
- An admitted activity that fails during execution still receives a sequence, a receipt with a non-zero
result_code, a consumed account sequence and a charged fee. Its module effects roll back.
Execution sees one clock: the batch timestamp.
Per activity the kernel, in fixed order:
- Decodes the envelope.
- Checks
network_id,protocol_versionand module enablement. - Resolves
actor_didandauthorityand verifies the signature. - Checks
account_sequenceagainst the actor's next sequence. - Checks
timestamp_boundagainst the batch timestamp. - Checks the idempotency key; a hit returns the stored receipt.
- Computes the fee and tests it against
fee_limit. - Opens a state journal.
- Runs the module's
validate, thenexecute. - Commits the journal on success or rolls it back on failure.
- Charges the fee as a
402LXPtransfer, consumes the sequence, records the idempotency key and emits the receipt, on both paths. - Recomputes the state root and chains it into the receipt.
402LXP is the single financial doorway: no module, including programs, writes a balance directly; modules emit transfer sets (Modules). Consensus code uses no floating point and never consults a wall clock. The append-only activity log is authoritative; SQLite indexes are rebuildable projections of it and never authoritative.
Every executed activity returns an ActivityReceipt with activity_id, global_sequence, previous_state_root, resulting_state_root, activity_root, result_code, effects, fee_charged, batch_id and sequencer_signature. The protocol computes every value itself and rejects any client-supplied result, effect, balance or state root. State roots chain per activity: the receipt at a global sequence names the resulting root of the preceding sequence.
A successful 402LXP operation also returns a 402LXPReceipt with protocol-computed balances before and after, the transfer-set root, authorization and context hashes, chained state roots, batch ID, timestamp and sequencer signature. A failed operation returns only a failure result with its result code and unchanged balances.
Once the covering checkpoint is finalised, a receipt can carry a proof extension: inclusion proofs, checkpoint_id, the guarantor certificate and a Paxeer X chain settlement reference. A receipt without the extension is a sequencer promise; one with it is backed by bonded guarantors and anchored on the chain.
The limited beta has not opened yet. The gateway API becomes available when it does. This is a mainnet beta on real value, so there is no faucet for general use; approved developers receive test allocations from the team. See Status.