LayerX Kernel
The deterministic C17 execution core of Paxeer X: one signed activity, one canonical history, and one reproducible result.
The LayerX kernel executes agent activity across payments, escrow, budgets, streams, services, trading, governance, assets, bridges, and programs. It resolves authority, applies state transitions, produces receipts, and binds each result to the next state root. Paxeer provides the EVM settlement and custody layer on chain ID 125; ordinary LayerX operations run through the activity protocol without requiring a separate Paxeer transaction.
Three execution invariants
| Invariant | Meaning for applications |
|---|---|
| One canonical history | Global sequences order admitted activities. State roots chain per activity. The append-only log is authoritative; query indexes can be rebuilt. |
| One financial doorway | 402LXP alone writes balances. Economic modules and programs propose validated transfer sets, preserving a common accounting boundary. |
| One reproducible result | Independent replay produces identical receipts and roots from the same ordered input, parameter versions, and batch time. |
Canonical activities: LXC/1
Each state-changing action uses a signed lxp_activity envelope. LXC/1 is a canonical binary encoding with fixed-width big-endian integers, explicit fields, and no floating point or maps. A valid decode must re-encode to the same bytes; extra trailing bytes are rejected.
| Field | Purpose |
|---|---|
protocol_version, network_id | Select the enabled protocol rules and prevent cross-network replay. Protocol 1 is legacy, 2 adds occupancy, and 3 adds state commitment. |
activity_type | The high 16 bits identify the module; the low 16 identify the operation ordinal. |
actor_did, authority | Identify the principal and primary key, session, or capability grant authorizing the action. |
account_sequence | Must exactly match the actor’s next sequence; gaps and stale sequences are refused. |
timestamp_bound | Bounds validity using the sealed batch timestamp. |
idempotency_key | Retries return the original receipt without repeating the economic effect. |
fee_limit | Caps the deterministic execution fee the actor authorizes. |
payload, payload_hash, signature | Bind the operation body and its Ed25519 authorization to the canonical signing preimage. |
From admission to state transition
- Decode and check the envelope, including protocol version, network, payload binding, and module enablement.
- Resolve the actor and authority, verify the signature, and enforce the exact account sequence.
- Evaluate timestamp bounds against batch time and check the idempotency key.
- Compute the fee against the active schedule and the activity’s fee limit.
- Open the state journal; dispatch module validation and execution.
- Commit successful module effects or roll them back on execution refusal.
- Apply required fee and sequence bookkeeping, record idempotency, and produce a receipt chained to the resulting state root.
Admission refusal and execution failure
Malformed envelopes, wrong-network requests, and payload-hash mismatches fail admission without consuming the account sequence or charging an execution fee. An admitted action that fails execution still occupies its global sequence and consumes its account sequence; the applicable deterministic fee is charged within the authorized limit. Module effects roll back, while protocol bookkeeping persists. Applications must inspect the receipt’s result code before treating an action as successful.
Identity is part of execution
Agent DIDs are native accounts. The kernel enforces primary and session keys, scoped grants, rotation, recovery, revocation, and expiry. Delegation can narrow authority without widening it. Incrementing an identity’s revocation sequence invalidates grants referring to an older value; retirement requires a zero balance sheet.
Determinism across machines
Consensus execution uses C17 and deterministic protocol types. It excludes floating point, local wall-clock reads, unstable database iteration, and pointer-derived hashing. Time-dependent rules—including grant expiry, escrow deadlines, stream accrual, funding intervals, and governance activation—read the committed batch timestamp. Oracle observations arrive as signed ordered activities; execution never fetches an external HTTP response.
Programs share the accounting boundary
Module 0x09 executes deterministic WASM programs under the invoking activity’s authority. Program-owned accounts derive from public program identifiers and seeds. Derivation alone grants no debit authority. Nested spending grants narrow the permitted source, destination, asset, and amount. Program monetary effects pass through 402LXP, and persisted namespace occupancy is metered and settled as replayable transfer legs.
Receipts and replay
A lxp_receipt binds the activity identifier, global sequence, previous and resulting state roots, activity root, result code, effects, fee charged, batch identifier, and module and parameter versions. Program outcomes additionally bind terminal results, runtime and ABI versions, resource metering, transfer evidence, and call-graph commitments. Clients supply activities; the protocol produces receipt evidence.
Replicas replay the append-only history using its committed parameters. A root or receipt disagreement stops acceptance of that replay. Portable layerx-receipt-proof-v1 evidence lets a verifier authenticate a receipt against independently trusted batch facts. A receipt proves execution at its declared evidence level; settlement requires the corresponding checkpoint evidence.
Native integration surfaces
The native interface exposes lxp_kernel_execute_activity, lxp_kernel_dispatch, and lxp_kernel_replay. Prepared-batch APIs separate preparation, commit, and publication; batch-boundary and publication-digest interfaces bind the records being published. Protocol-3 batch maintenance runs escrow deadlines, budget rollover, service defaults, and occupancy finalization within the batch journal.
Application workflow
- Build the canonical activity using the correct network, authority, next sequence, fee limit, and validity bounds.
- Sign once and retain the exact bytes and idempotency key for retry and recovery.
- Submit with the evidence level required by the business operation.
- Verify receipt identity, result, fees, effects, and state-root binding.
- Require matching batch and checkpoint evidence before releasing a resource that needs settled assurance.