PAXEER NETWORK · LAYERX
PROTOCOL WHITEPAPER · LXP1
Sidiora Labs INC.
BUILT FOR TRUST. DESIGNED FOR SCALE.
PAXEER NETWORK · LAYERX
PROTOCOL WHITEPAPER · LXP1
Paxeer
LayerX
PROTOCOL WHITEPAPER
PROTOCOL TAG LXP1  ·  VERSION 1

LayerX: the canonical activity, execution and accounting layer for autonomous agents

A deterministic activity protocol where every monetary effect moves through a single authenticated doorway, and millions of agent activities settle to Paxeer through bonded, availability gated checkpoints.
PUBLISHED BYVERSION
Sidiora Labs INC.
BUILT FOR TRUST. DESIGNED FOR SCALE.
PUBLISHED BY · VERSION
Sidiora Labs Inc.  ·  v2.0 · August 2026
AUDIENCE
Protocol engineers · Institutional partners · Ecosystem developers
NORMATIVE SPECIFICATION
spec/layerx-protocol  ·  C17 reference implementation
DECLARE.  EXECUTE.  SETTLE.
ABSTRACT

Autonomous agents do more than pay each other. They commit to tasks, attest to tool executions, deliver artifacts, accept or dispute what was delivered, trade, stream, escrow and delegate, at a frequency and granularity that no settlement chain was built to carry. LayerX makes that entire lifecycle canonical. It is an ordered, authenticated, replayable record in which every action is an activity, every activity produces a signed receipt, and every receipt can be proven against a state root that bonded, independent parties have recomputed from first principles.

The division of responsibility is strict. LayerX owns identity and delegated authority, activity ordering, payments and balances, escrow, budgets, streams, service agreements, perpetual markets, deterministic execution, receipts, and data availability. Paxeer owns custody, checkpoint registration, guarantor bonds, slashing, dispute settlement and emergency exits. Paxeer never processes an ordinary agent activity. Thousands to millions of LayerX activities collapse into one periodic Paxeer checkpoint.

Two commitments organize everything else. First, 402LXP is the only financial doorway. Every monetary effect in the system, whether a payment, an escrow capture, a liquidation or a fee, compiles into one or more authenticated balance transfers executed by a single kernel function, and no module may write a balance directly. Second, execution is deterministic to the byte. Canonical binary encoding, integer arithmetic, batch supplied time and versioned transition functions guarantee that any node replaying the same history produces the same state root on any machine, forever.

This paper specifies the activity protocol, the 402LXP financial kernel, the deterministic state machine, the batch and checkpoint pipeline, the guarantor model and its economics, the data availability layer that gates finality, the threat model, and the migration path from the existing implementation. The guarantees are stated plainly throughout. Threshold attestation is an economic bound, not a validity proof, and the final backstop of the design is an emergency exit that requires no LayerX liveness at all.

CONTENTS
01Introduction08Guarantors
02Design principles09Data availability
03System architecture10Economics
04The activity protocol11Security and threat model
05402LXP: the financial kernel12Migration and genesis
06Deterministic execution13Comparative analysis
07Batches, checkpoints, finality14Roadmap · Conclusion · Appendix

01Introduction

1.1 The economics of machine work

Human commerce is coarse. Purchases are large, frequency is low, and the cents of cost and seconds of latency in the rails disappear as overhead. Machine commerce inverts both variables. An agent resolving a single task may call dozens of priced services worth fractions of a cent each, open an escrow against a delivery it has not yet received, meter a streaming data feed, and adjust a hedging position, all inside one turn. Across a fleet the volume is enormous. Taken one at a time, each action is smaller than the fee that would carry it on a public chain, and faster than the block that would order it.

Payments are only half the problem. When agents do consequential work for one another, the record of that work matters as much as the money: who committed to what, which tools ran, what was delivered, who accepted it, what was disputed. Today that record lives in provider logs. It is unilateral, unordered, unportable, and the party who paid cannot audit it. Version 1 of LayerX therefore covers the complete agent work lifecycle rather than only the economically meaningful actions. Task commitments, tool execution attestations, deliveries, acceptances and disputes are first class ordered, authenticated activities in the same log as the payments they justify.

1.2 The division of responsibility

LayerX is the canonical activity, execution and accounting layer for autonomous agents. Paxeer provides custody, checkpoint finality, economic guarantees and dispute settlement, and does not process ordinary agent activity. An ordinary LayerX action never requires a Paxeer transaction. Thousands or millions of activities collapse into one periodic checkpoint.

LAYERX HANDLES
Agent identities and delegated authority · activity ordering · payments and balances · holds, escrow, budgets and streaming payments · service agreements, deliveries and attestations · trading, positions, funding and liquidation · deterministic execution · receipts and inclusion proofs · data availability · replay and state reconstruction · sequencer operation · fees and resource metering
PAXEER HANDLES
Asset custody · deposits and withdrawals · checkpoint registration · guarantor bonds · checkpoint attestations · slashing for conflicting attestations · emergency exits · dispute resolution · final settlement between LayerX and external assets
Figure 1 — The division of responsibility. Paxeer holds value and verifies certificates. It never parses an activity.

1.3 Contributions

1. A canonical activity envelope and wire format (LXC/1) with exactly one valid encoding per value, domain separated hashing throughout, and authorization expressed as state machine logic rather than transport middleware (§4).

2. 402LXP, a single financial doorway through which every monetary effect in the system compiles into authenticated, conservation checked, atomic transfer sets. Locked funds are real accounts, never hidden columns (§5).

3. A deterministic state machine built on canonical bytes, integer arithmetic, batch supplied time and versioned transition functions, specified down to the C17 hazards that have forked real systems (§6).

4. A checkpoint pipeline with an explicit finality ladder, no fork choice rule, and recovery procedures in which ambiguity halts the chain rather than resolving it (§7).

5. A bonded guarantor model whose economic security is sized to the withdrawal rate limit rather than to total custody, with an honest account of what threshold attestation does not prove (§8).

6. Availability gated finality: a checkpoint cannot finalize on the strength of state roots alone, and an emergency exit lets any agent withdraw against the last finalized root with no LayerX liveness at all (§9, §11).

The hierarchy fits in one sentence. 402LXP compiles intent into authenticated transfers; transfers become deterministic transitions; transitions become receipts; receipts become batches; batches become checkpoints; checkpoints become Paxeer guarantees.

02Design principles

Six principles governed every trade off. We state them first so the architecture that follows reads as their consequence.

P1 · EVERYTHING IS AN ACTIVITY

One envelope, one log, one receipt shape. A payment, a key rotation, an oracle observation, a delivery attestation and a governance vote are all the same object: an ordered, signed, fee metered activity. There is no side door into state.

P2 · ONE FINANCIAL DOORWAY

Every monetary effect compiles into one or more authenticated balance transfers executed by a single kernel. No module writes a balance. Escrow, margin and budgets are real subaccounts moved by real transfers, so every unit is traceable through one ledger.

P3 · DETERMINISM IS THE PROTOCOL

A node must produce identical results from identical activity history on any machine, architecture and build, forever. The canonical binary form is the protocol. JSON and HTTP are conveniences and may never define consensus behaviour.

P4 · CUSTODY NEVER LEAVES PAXEER

Paxeer contracts hold assets and understand as little LayerX business logic as possible. They verify certificates, proofs, nullifiers, counters and windows. Everything they check is a hash, a signature or a Merkle path, never an order, an agreement or a transfer.

P5 · SAFETY OVER LIVENESS

There is no fork choice rule. Two conflicting histories are never adjudicated. They are evidence, and the chain halts. A halted chain can be recovered by governance and, in the worst case, by emergency exit. A silently reorganized chain would destroy the accounting guarantee the design exists to provide.

P6 · HONEST GUARANTEES

Threshold attestation is a bonded economic guarantee, not a validity proof, and no document, interface or SDK may describe checkpoint finality as proven. Every limitation in this paper is stated plainly, along with the mechanism that bounds it and the backstop that survives it.

03System architecture

3.1 Roles and the pipeline

One sequencer is active at a time. It admits activities, assigns each a global sequence, applies the transition function and seals batches. Any number of replicas replay history and serve data. A bonded quorum of guarantors independently downloads, verifies, replays and attests each batch, and their attestations are what Paxeer accepts. Paxeer holds custody and never sees an individual activity.

01 ACTIVITY
An agent signs a canonical envelope. The sequencer admits it and assigns a global sequence.
02 RECEIPT
Deterministic execution yields a signed receipt with before and after evidence and both state roots.
03 BATCH
A gapless sequence range seals under one signed header committing six Merkle roots.
04 CHECKPOINT
Guarantors replay every batch, attest possession and validity, and a threshold certificate forms.
05 SETTLEMENT
Paxeer verifies the certificate. After the challenge window, withdrawals against the root are payable.
Figure 2 — The pipeline: activity → receipt → batch → checkpoint → Paxeer settlement. Steps 01–03 run at machine speed. Steps 04 and 05 amortize across thousands of batches.

3.2 Kernel and modules

The activity kernel understands only universal concepts: identities, accounts, assets, authority, sequences, fees, state transitions, events, receipts, checkpoints and modules. Everything domain specific, from payments and escrow to streams, service coordination, perpetual markets, governance, bridging and oracles, is a protocol module built on that kernel. A module builds a transfer set and hands it to the 402LXP kernel. It never touches a balance itself.

MODULEIDOWNSFINANCIAL AUTHORITY
asset (402LXP)0x01SEND, RECEIVE, grants, atomic transfer setsThe only balance writer
escrow0x02Holds, capture, release, timeout, disputesVia 402LXP transfer sets
budget0x03Recurring limits, allowances, delegated spendingVia 402LXP transfer sets
stream0x04Metered and time based paymentsVia 402LXP transfer sets
service0x05Offers, commitments, tool attestations, deliveries, acceptances, disputesNone. Writes settlement preconditions only
perps0x06Markets, orders, positions, funding, liquidationVia 402LXP transfer sets
governance0x07Parameters, asset registry, halts, guarantor setParameters only
bridge0x08Paxeer deposits, withdrawals, exits, nullifiersVia 402LXP transfer sets
oracle0x09Signed observations, feeds, publisher registryNone
identity0x0ADIDs, key rotation, session keys, capability grants, payout bindings, recoveryNone
Table 1 — The module registry. Activity type codes are u16 values: high byte names the module, low byte names the action. A direct balance write anywhere outside the asset module is a conformance failure.

3.3 The reference implementation

The reference implementation is pure C17. There is no C++, Go, Rust or JavaScript in the protocol runtime. It uses a canonical binary codec, Ed25519 for agent identities and secp256k1 for Paxeer facing certificates, domain separated SHA-256 commitments, a canonical append only activity log as the sole authority, SQLite for rebuildable indexes, a single deterministic state writer, and checked fixed width arithmetic with 128 bit intermediates. Worker threads handle only signature verification, networking and non consensus work. External observations such as oracle prices enter exclusively as signed activities. Once accepted, their exact payload bytes are replayable history, and no network call ever occurs inside a state transition.

A JSON over HTTP gateway may exist for convenience. It re-encodes to canonical binary, and only the binary bytes are signed, hashed, logged and replayed. A gateway compromise cannot change an outcome the agent authorized, because the agent's signature covers the canonical bytes and nothing else.

04The activity protocol

4.1 The envelope

Every action becomes the same canonical envelope. Only the payload varies by activity type. The envelope binds the protocol version, the network, the actor, the authority under which the actor acts, an exact account sequence, a validity window measured against batch time, an idempotency key, a fee ceiling, and the payload, all under one Ed25519 signature.

Activity envelope · receiptC
Activity {                     ActivityReceipt {
    protocol_version               activity_id
    network_id                     global_sequence
    activity_type                  previous_state_root
    actor_did                      resulting_state_root
    authority                      activity_root
    account_sequence               result_code
    timestamp_bound                effects
    idempotency_key                fee_charged
    fee_limit                      batch_id
    payload_hash                   sequencer_signature
    payload                    }
    signature
}
Figure 3 — The activity envelope and its receipt. There are no floating point values, platform dependent encodings or ambiguous numbers anywhere in consensus critical execution.

4.2 The canonical wire format

LXC/1 is governed by six rules. One valid encoding: for every logical value there is exactly one accepted byte string. Schema driven: fields are positional per the declared version, with no type tags, so none of the tag ordering ambiguities that make CBOR and Protobuf canonicalization fragile. Validate, never normalize: the decoder rejects non canonical input and repairs nothing. No trailing bytes. Bounds before allocation. Round trip assertion: debug and fuzz builds prove encode(decode(b)) = b for every accepted structure.

All integers are unsigned, fixed width, big endian. Amounts are integer base units with decimal placement carried as asset metadata. Consensus visible strings are printable ASCII only, because Unicode normalization differs across libraries and versions, and a normalization difference between two nodes is a consensus fork. Free form text travels as opaque bytes that consensus code never interprets. Map and set keys must be strictly ascending bytewise. Duplicates and non ascending order are decode failures, never merged or sorted.

Every hash is domain separated: H(T,B) = SHA-256( len(T) ‖ T ‖ B ) with an ASCII tag beginning LXP1/, so no two structures can ever share a pre-image, and a protocol version bump changes every digest by construction. Merkle trees use distinct leaf and node tags and never duplicate the last leaf to pad, which structurally excludes the classic two trees, one root collision. Signatures are always over tagged pre-images. Ed25519 verification rejects non canonical S and small order keys, and secp256k1 rejects high s, so malleability cannot manufacture a second encoding of one authorized activity.

4.3 Authority classes

Authorization is state machine logic, never transport middleware. Every activity resolves its authority against live state before execution, and scope checks are cumulative through the delegation chain: type allow list, per asset cap, per window cap and expiry of every link, to a maximum depth of four.

CLASSNAMESEMANTICS
A0PrimaryThe signature key equals the identity's live primary key
A1SessionExpiring, scope limited, revocable session key
A2CapabilityDelegated action and spend scopes, sub delegable to bounded depth
A3Payer grantRequired for RECEIVE. The state record, not the presented bytes, is authoritative
A4ModuleModule minted, module scoped debit rights over one subaccount
A5GovernanceParameters, assets, halts, guarantor set. Quorum plus timelock
A6OracleA key in the feed's publisher registry. Fails closed on unknown publishers
A7KeeperPermissionless crank gated by a deterministic precondition: expiries, funding, liquidation
A8Bridge proofProof carrying. A finalized Paxeer proof travels in the payload and the submitter's identity is irrelevant
Table 2 — The nine authority classes. Every debit in the system names exactly one of them.

4.4 Result classes: failure is history

Every outcome falls into one of three classes, and the distinction is normative. Reject: a malformed, mis-signed, wrong network or wrong sequence activity never enters the log. No sequence, no fee, no receipt, and a batch containing one is invalid in its entirety. Fail: an admitted activity whose execution fails is real history. It is sequenced, receipted, its account sequence consumed and its fee charged, with all other effects rolled back atomically. Fatal: a violated invariant the code believed impossible halts the node, because divergence is worse than downtime. Failure being paid for, provable history is what makes idempotency exact. One key yields at most one economic result by construction, not by convention.

The service module deserves its explicit caveat here. The protocol orders and attests lifecycle claims such as commitments, tool executions and deliveries as timestamped, non repudiable assertions by their signer. It does not verify that a tool ran, that an artifact matches its hash off protocol, or that a deliverable is fit for purpose. The truth of those claims is a matter for the counterparty, the arbiter, or a future proof system. The record establishes exactly who claimed what, when, and in what order.

05402LXP — the financial kernel

5.1 One doorway, one law

Every feature may carry richer metadata and rules, but every monetary effect must compile into one or more authenticated balance transfers. For a transfer of amount q from account x to account z:

bal(x) ↦ bal(x) − q ,   bal(z) ↦ bal(z) + q   subject to
q > 0  ∧  bal(x) ≥ q  ∧  authorization controls x  ∧  seq = next_seq(x)
asset(x) = asset(z)  ∧  no overflow  ∧  Σ balance changes = 0

The protocol computes the new balances. Clients are never trusted to submit authoritative new balance values. Internally there is exactly one balance mutation primitive, lxp_apply_transfer_set(), which is structurally the only code in the system permitted to write the account tree. Continuous integration greps for any other unit touching it.

5.2 SEND, RECEIVE and payer grants

Two public operations exist. SEND pushes value from payer to recipient under the payer's own authority: primary key, session key, capability, budget allowance or module authority. RECEIVE lets a recipient pull value using authorization the payer previously issued, in the form of a signed payer grant naming the authorized recipient, asset, per draw maximum, total or recurring allowance, expiry, permitted purpose and revocation sequence. The grant is state, not a bearer document. Each draw decrements the remaining allowance atomically inside the same transfer set, and revocation is an ordinary activity after which later draws deterministically fail. Both operations execute the same internal transfer function. The only difference is who initiates and which authorization proves permission to debit.

5.3 Locked funds are real accounts

The protocol represents reserved value as real accounts, never hidden balance columns: agent:<did>:main, …:budget:<id>, …:escrow:<id>, …:margin:<position>, and system accounts for liquidity, funding, insurance, fees and the Paxeer reserve mirror. Opening a position does not set a reserved_margin flag. It moves 100 USDX from the agent's main account into a margin subaccount. Every unit is traceable through one ledger, and reserve reconciliation (§10.5) becomes a sum over accounts rather than an audit of scattered counters.

Complex operations execute as atomic transfer sets. A liquidation's loss leg, fee split, insurance draw and margin refund are legs of one set with one authorization context, one sequence and one receipt. All legs validate before the first write, with Σ debits = Σ credits per asset, and if any leg violates an invariant, no leg is written. Ordinary modules never mint or burn. Only the bridge moves aggregate supply, and only against finalized Paxeer proofs.

5.4 The receipt

Every successful operation returns a signed receipt carrying the operation, global sequence, asset and amount; the payer's and recipient's before and after balances as evidence read out of state; the transfer set root, authorization hash and context hash; and both state roots, so every activity is individually provable. Once checkpointed, the receipt gains an activity inclusion proof, a state inclusion proof, the checkpoint identifier, the guarantor certificate and the Paxeer settlement reference: a chain of custody running from a single micro payment all the way to an on-chain guarantee.

5.5 The HTTP 402 flow

For machine to machine service payment, 402LXP occupies HTTP's reserved status code. A priced endpoint answers an unpaid request with a 402 challenge carrying the network, recipient, asset, amount, invoice, purpose hash and expiry, all under the service's signature. The client either pays first with SEND and presents the receipt, or returns a signed payment authorization the service claims through RECEIVE. No checkout, no stored payment instrument, no session, no human.

402LXP exchangeHTTP
GET /v1/index/query?q=... HTTP/1.1

HTTP/1.1 402 Payment Required
LX-Network:   7791
LX-Recipient: did:pax:svc:retrieval-index
LX-Amount:    2500 uUSDX
LX-Invoice:   8f3c...b1
LX-Purpose:   85f3...51
LX-Expires:   2026-08-13T14:02:11Z
LX-Signature: (service signature)

GET /v1/index/query?q=... HTTP/1.1
LX-Receipt: (402LXP receipt, L1-sealed)

HTTP/1.1 200 OK
LX-Settled: seq=8214413 batch=51022
Figure 4 — A 402LXP exchange over the JSON/HTTP gateway. Header names are illustrative. The normative encoding is the canonical binary activity the client signs.

5.6 Core invariants

The kernel asserts, per activity, in debug and guarantor builds: every monetary mutation runs through the transfer kernel; every debit carries explicit resolved authority; RECEIVE consumed a live payer grant; no balance is negative, which is structurally impossible because balances are unsigned and debits are checked before write; every transfer set conserves per asset; sets are all or nothing; exactly one durable receipt exists per success; at most one economic result exists per idempotency key; every account sequence is consumed exactly once; no module wrote a balance; oracle data never altered a balance without a module authorized transfer set; no deposit credited without a finalized Paxeer proof and an unspent nullifier; no withdrawal nullifier was spent twice; and replay from the previous state root reproduces the resulting root exactly. A violation is fatal. The node halts rather than continue diverged.

06Deterministic execution

6.1 State

State is a fixed vector of fifteen sparse Merkle trees covering identity, account, sequence, idempotency, authority, escrow, budget, stream, service, perps, oracle, bridge, governance, asset and metering, each of depth 256 over domain separated key paths, with absent keys hashing to precomputed empty subtrees so non membership proofs come for free. The global state root commits the layout version and every tree root in fixed order, and because the governance parameters and the active transition version table live inside committed state, a replayer needs only the genesis manifest and the log. No external configuration file may influence execution.

The append only activity log is the authority. Every tree is a projection rebuildable from genesis plus the log, and SQLite indexes are projections of projections, never consulted by the transition function. State roots are materialized after every activity, since each receipt carries its previous and resulting root, after every batch, and at every checkpoint, where guarantors recompute all of it from batch bytes.

6.2 The evaluation order

A single activity evaluates in fifteen normative phases, and reordering any two changes observable behaviour. Decode and structural validation; context admission against the batch clock; signature verification; actor resolution; authority resolution against live state; exact sequence consumption, equal to the expected next value and never within a window, consumed exactly once and before any effect can fail; idempotency check; fee reservation through a real escrow leg; then a journal savepoint, module execution against a nested journal, atomic transfer application, outcome fixing, receipt and event emission, and root update. One consequence is worth stating on its own: a failed activity still changes the state root, because its sequence and fee committed before the effect region. Failure is a real, paid for, provable event, not a no-op.

Rollback is exact and total or the node halts. Undo entries restore every value in reverse order, absence included. Roots are recomputed only after the outcome is fixed, so an intermediate root is never signed, stored or shown. A transfer set validates completely before its first write, so atomicity never depends on the undo path being bug free at exactly the moment the code is already in an unexpected state.

6.3 One clock, versioned rules

Execution has exactly one clock: the batch timestamp, monotonically non decreasing, bounded in advance, supplied as input rather than read from any operating system. Every time dependent rule, including expiries, budget windows, stream accrual, escrow deadlines, oracle staleness, funding intervals and acceptance windows, reads this field and nothing else. A call to time() inside the state machine is a conformance failure.

Transition functions are versioned and immutable once activated. Bugs are never fixed in place. A new version activates at a governance named epoch boundary, and old versions stay in the binary permanently, because historical batches must re-execute under the code that first executed them, forever. Replay dispatches on the version recorded for the batch's epoch, never on the newest version the binary implements. Any change to encoding, hashing, ordering, rounding or even error classification is a version change, since error codes move the state root through fees and sequences.

6.4 Determinism as engineering discipline

The obligations translate into specific C17 rules, each of which has forked a real system when violated: unsigned fixed width types only, with checked helpers replacing every bare arithmetic operator; no floating point in any consensus translation unit; no hashing or comparing structs by their bytes, because padding is implementation defined; byte data as uint8_t, ordering as memcmp over encoded bytes, never locale sensitive functions; no pointer value influencing output; no unbounded recursion; exactly one deterministic state writer, with worker thread results crossing into it in canonical order; and allocation failure as fail stop, because a machine with less memory must not produce different history. Qualification requires byte identical replay across architectures over millions of activities, crash recovery at every write boundary, and fuzzing clean under address, undefined behaviour and memory sanitizers.

07Batches, checkpoints and finality

7.1 Batches

The global sequence starts at 1 and increases by exactly one per sequenced activity, forever, across epochs and sequencer handovers. It never resets, skips or repeats. A batch is a contiguous, gapless range of sequences under one signed header committing the previous and resulting state roots, Merkle roots over activities, receipts and events, the data availability manifest root, the oracle root, and the deterministic timestamp. Batches seal on the first of: 65,536 activities, 64 MiB, a 250 ms interval, or a 10 second heartbeat on an empty mempool. The seal procedure is crash safe and ordered, writing log segment, receipts, then header, each fsynced, and no receipt is published to a client before the header is durable, so crash recovery never invalidates a value a client saw.

7.2 Checkpoints and what Paxeer verifies

A checkpoint covers a contiguous run of batches, up to 2,400, which is about ten minutes at the 250 ms target. Its body is deliberately lean: batch range, start and end state roots, a Merkle root over batch identifiers, a root over the per batch availability manifests, and the guarantor set version that must attest. Each guarantor signs the 55 byte statement checkpoint_id ‖ attest_flags with secp256k1, where the flags assert two things jointly: I replayed every transition and matched every root, and I hold the complete availability data. Both bits must be set for a signature to count. An attestation without possession is not weaker. It is invalid.

Paxeer stores the head checkpoint, the guarantor and sequencer registries, spent withdrawal nullifiers, rate limit counters and open challenges. It verifies that the body decodes and its id recomputes; that the checkpoint number and state roots chain from the stored head; that every signature recovers to a distinct active, fully bonded member; that the threshold is met; and, for a payout, a membership proof against the end state root plus an unspent nullifier. It must not parse an activity, a receipt, an order or an agreement. Everything it checks is a hash, a signature, a counter or a Merkle path. That is what keeps millions of agent activities off the settlement layer.

7.3 The finality ladder

LEVELREACHED WHENWHAT A HOLDER MAY RELY ON
L0 · AcceptedSequencer admitted itNothing. A courtesy acknowledgement
L1 · SealedInside a signed, fsynced batchOrdering is fixed and the sequencer is cryptographically accountable
L2 · DistributedAvailability data held by the guarantor thresholdAnyone can replay and reproduce it, and it survives sequencer loss
L3 · AttestedThreshold guarantor signatures existBonded capital stands behind the state root
L4 · SettledCertificate accepted on Paxeer and challenge window elapsedWithdrawals and exits against this root are payable
Table 3 — The finality ladder. Clients are told the level of every receipt. Anything at or below L1 is revocable by sequencer loss. Nothing at L2 or above is.

Finality at L4 guarantees an immutable sequence, a root independently recomputed by bonded parties, retrievable data, no double payout, and an inclusion proof for every receipt. It does not guarantee validity, since a colluding super threshold can settle an invalid root (§8). It does not guarantee censorship resistance, since finality says nothing about what was excluded. It does not guarantee the truth of inputs: an oracle observation is final as data, not as price, and a tool attestation is final as a claim, not as evidence the tool ran. It does not guarantee liveness. Every client SDK states this.

7.4 No reorgs — halts, and recovery

LayerX has no fork choice rule by design. Headers chain by state root. A second certificate at the same checkpoint number is not a competing branch that could win. It is rejected on arrival, and it is evidence. Two signed batches at one number are sequencer equivocation: guarantors stop attesting, submit both headers, and halt. A guarantor whose independent replay disagrees must refuse to sign and publish its own root. If the threshold cannot be reached, the chain stops advancing. Ambiguity halts the chain. It never resolves it.

Sequencer loss triggers a specified recovery. Guarantors freeze and establish the resume point, which is the highest batch at L2 or above. The tail above it is discarded. It was at most L1, so no distributed receipt is invalidated, and discarded activities return to the mempool and resubmit safely. Governance promotes a pre-registered standby that must replay from the last settled checkpoint and reproduce every root exactly before producing. The epoch increments, and batch numbers and global sequences never reset. If no successor appears within seven days of the last settled checkpoint, Paxeer enters emergency exit mode and agents withdraw directly against the last settled root, a path that needs no LayerX liveness at all.

08Guarantors

8.1 Not validators

A guarantor is not a validator in a BFT consensus. It proposes nothing, orders nothing and votes on no fork. It answers exactly one question per checkpoint: does this state root follow deterministically from data I hold in full? Its six duties are absolute. Download the complete batch, all five availability sections, since header only following is forbidden. Verify every signature with no sampling. Replay every transition under the header's protocol version with the batch clock. Recompute all six roots. Store and serve the availability data for its retention period. Sign only on full agreement across the entire checkpoint range. There is no close enough, and no signing on another guarantor's word. A guarantor that signs a root it did not itself compute has committed the only fraud this design cannot survive. Guarantors must be operationally independent, meaning separate entities, keys, infrastructure and network paths, because five co-located signatures are one signature wearing five hats.

8.2 Bond sizing: bounding extraction, not custody

The attack that matters is a colluding sequencer plus a threshold of guarantors signing a fabricated root that credits attacker accounts, waiting out the challenge window, and withdrawing. Naively, safety demands T·B ≥ TVL. At 50M custody with T = 5 that is 10M per guarantor, which is capital inefficient to the point of unusable. The protocol instead bounds the extractable amount per challenge window with a per asset withdrawal rate limit W, enforced by the state machine at withdrawal request and independently re-enforced by the Paxeer contract per settled checkpoint:

max extraction per window = min( TVL , W )
requirement: T · B ≥ SAFETY_MARGIN · W   ( SAFETY_MARGIN ≥ 2 )
example: W = 2M/day, T = 5 ⇒ B ≥ 800k per guarantor

Because a fabricated root cannot pay out faster than W, and equivocation evidence or a withholding honest minority halts the chain within a checkpoint or two, the loss from a successful collusion is bounded by the rate limit rather than by custody. Stated honestly, this is a bounded loss argument, not a no loss possible argument. Bonds are denominated in an asset Paxeer custodies, never a token the guarantors control, and remain fully slashable through a 32 day unbonding period that strictly exceeds the challenge and slash evidence windows.

8.3 Threshold, slashing, rotation

The threshold obeys T ≥ ⌊2N/3⌋ + 1, with initial parameters N = 7, T = 5. Two guarantors may be down without halting checkpoints, and five independent operators must collude to settle a false root. The threshold is not a majority vote on truth. It is a bonded cost floor. Four honest guarantors that all disagree with the sequencer cannot force a correct root to settle. They can only withhold and halt, and halting is the intended behaviour.

Equivocation, meaning one key signing two conflicting attestations at the same checkpoint number, is proven mechanically on Paxeer from the two bodies and signatures alone, with no LayerX business logic. The full bond is slashed, a tenth of it goes to the reporter, the member is ejected, and any checkpoint that needed the signature is marked contested. Attested unavailability, an unanswered data challenge, draws a partial slash escalating to ejection. Liveness faults jail without slashing. A member missing more than 20% of an epoch is excluded from the threshold count and forfeits rewards. If active membership would fall below the minimum, checkpointing halts rather than continuing at a weakened threshold. Set changes take effect only at epoch boundaries and only after the identical set is registered on Paxeer. Divergence between the two registries halts checkpoint acceptance.

8.4 What threshold attestation does not prove

Because the design depends on nobody being confused about it: it is not a validity proof. A colluding threshold, or a quorum running the same buggy binary, can settle a wrong root, and no cryptographic object in v1 makes an invalid transition unrepresentable. It is not a fraud proof. An honest minority cannot force a rollback. It can withhold, halt, publish its own roots and escalate. It does not bound loss to zero. It bounds loss to roughly the withdrawal rate limit per window, backed by the aggregate bond. It says nothing about censorship, and it certifies no off chain fact. The real correlated risk is monoculture, whether one cloud region, one distro image or one libc bug, which is why independence is audited at onboarding and re-audited, and why the upgrade path to validity proofs (§14) changes the certificate and never the activity protocol.

09Data availability

9.1 A state root is not a witness

A state root proves that someone claims a state exists. It proves nothing about whether anyone can construct it. If the sequencer publishes roots and withholds the batch, no agent can compute an exit proof, no replica can rebuild state, no fraud is detectable, and every receipt becomes unverifiable. An economically backed attestation degrades into an unfalsifiable assertion. A checkpoint therefore must not be finalizable on the strength of roots alone. Finality is gated on attested possession of a defined availability set by the bonded quorum.

The availability set per batch is exactly five sections: activities, receipts, oracle inputs, state diffs with both pre and post image so transitions can be checked and state synced incrementally, and recovery metadata. The set is chunked into 64 KiB pieces under a manifest whose root is committed in the batch header. The Merkle construction promotes odd nodes rather than duplicating them and commits chunk counts, so tree shape collisions are impossible. Empty sections still appear with the empty tree root, and commitments are over uncompressed canonical bytes, so compression can never change a hash input.

9.2 Attested possession and the finalization gate

A guarantor signs its availability attestation only after downloading every section, verifying every signature, replaying every transition, recomputing every root, and fsyncing the full set to durable storage. The attestation embeds a possession digest: a pseudo random self probe over sixteen chunks whose indices derive from the manifest root and the guarantor's own identity, so each guarantor proves possession of a different, unpredictable sample it cannot fabricate. A blind signature is useless. Availability and validity ride on one signature precisely so they cannot be decoupled. A state root with fewer than the threshold of possession attestations is not finalizable, however many parties signed the root itself.

Replicas sample continuously as an early warning system, pulling eight random chunks per new batch from a random attester. Withholding 5% of a batch survives eighty independent samples with probability under 2%. Suspicion escalates to a challenge game on Paxeer, where the bonds live. A challenger posts a small bond naming one chunk. The guarantor has an hour to publish the chunk bytes and Merkle path, which the contract verifies without parsing. A valid response forfeits the challenger's bond, which makes griefing costly, and silence slashes the guarantor and marks the batch faulted, which blocks finalization of every checkpoint containing it. An honest guarantor always wins at trivial cost. One that attested without possessing cannot respond at any price. Pruning is journalled and legal only after finalization, elapsed windows, elapsed retention and verified archive coverage, and a journal is not a defence against a challenge.

9.3 When data goes missing

The subsystem is a three state machine that every node evaluates independently from finalized evidence. DA_OK is normal operation. DA_DEGRADED, reached on escalated sampling faults or a quorum within one of the threshold, pauses checkpoint submission, raises sampling fourfold and puts perps markets into reduce only. DA_STALL halts finalization outright and fails closed. The sequencer stops sealing beyond a bounded backlog rather than extending the chain on top of unavailable data, and no withdrawal settles, because settlement needs a finalized root.

A persistent stall arms the Paxeer contract's emergency exit mode, provable from the contract's own registry and timestamps. Agents withdraw directly against the last finalized root by Merkle membership proof and nullifier. Those proofs are always constructible, because that root passed the gate, so the threshold attested possession and archive nodes can rebuild any account path. Subaccounts exit to their owner of record, open positions settle at the last finalized mark, and pools exit last and absorb residuals, in a fixed, deterministic order. Withholding data cannot steal assets. It can only stop the system, and stopping the system releases assets to their owners against the last root everyone could verify. At v1 loads, availability storage costs a guarantor on the order of dollars to low hundreds of dollars per month. The bond dominates by three orders of magnitude, and it does so on purpose. The bond, not the disk, is what makes the attestation meaningful.

10Economics

10.1 Units and the rounding law

All value is integer micro units (1 USDX = 10⁶ µUSDX), with prices in cents, funding rates in parts per billion, and ratios in basis points. Every intermediate runs in 128 bit checked arithmetic. The rounding law applies without exception. Amounts the protocol collects round up. Amounts it pays out round down. Signed PnL and funding truncate toward zero. Every residue is a real transfer leg credited to the insurance pool, never dropped, never left in a floating remainder, never silently absorbed. That fourth rule is what makes conservation exact rather than approximate.

10.2 Metering and fees

Fees are metered from the activity and the pre-state only: bytes, signature verifications, state reads and writes, hash blocks, transfer legs and module steps, each with a governance weight, and never from wall clock time or I/O latency. The total is scaled by a congestion multiplier recomputed once per epoch from the previous epoch's usage with truncating integer division, bit identical on every architecture. The base fee defaults to 5,000 µUSDX, half a cent, so ordinary agent activity is metered in fractions of a cent while state growth is always paid for.

The fee ceiling is enforced through real accounts, not bookkeeping. An escrow leg moves the actor's full fee_limit before any module code runs, the module executes against a live meter that aborts if the ceiling would be crossed, and closing legs return the unused remainder. The fee escrow account holds zero at every commit boundary. A failed activity still costs its actor, consumes its sequence and yields its receipt. Fee handling is not an exception to 402LXP. It is a demonstration of it. The treasury distributes each epoch by one atomic set: 30% sequencer compensation, 30% guarantor rewards, split equally among live members rather than bond weighted to avoid rewarding capital concentration, 20% insurance, and 20% governance treasury.

10.3 Insurance and market capacity

The insurance pool is a real account funded by its fee share, all rounding residues, slash proceeds and liquidation fee cuts. It drains only through liquidation deficits and governance gated remediation, and every drain is a visible transfer leg in the same receipt stream as any payment. Below its floor, perps markets go reduce only. At zero, they pause. A drain exceeding the balance caps at it and records the shortfall as an explicit bad debt object. The pool never goes negative and bad debt is never hidden inside a balance. Market capacity is gated by integer arithmetic over usable liquidity and stress loss parameters, and the effective open interest cap is a minimum against the configured cap. Capacity can lower advertised exposure. It can never silently raise it.

10.4 Funding and liquidation, conserving by construction

Funding rates combine an oracle supplied external rate, already in history as a signed activity and never read live, with a skew term, clamped and truncated. Because truncation makes naive per position sums unequal, conservation is restored explicitly. Payers are computed and capped at available margin, receivers get floor divided pro rata credits, and the non negative residue goes to insurance in the same atomic set. The per market funding account holds zero at every commit boundary. Funding never mints. Liquidation is permissionless. Eligibility uses the latest oracle mark in history, the first valid liquidation in sequence order wins, race losers pay only the base fee, and the waterfall, running loss to liquidity, fee split to keeper and insurance, insurance covering any deficit, remainder to the owner, is one atomic set in fixed leg order. Stale oracles fail closed. Liquidations suspend rather than guess, a liveness cost accepted deliberately.

10.5 The reserve invariant

Proposition (one to one backing). Let A be all accounts, agent subaccounts and system accounts included, and custody(t) the Paxeer vault balance at the last processed bridge event. Then at every commit boundary:

INVARIANT R:   Σa∈A bal(a) = custody(t)

The proof is induction over transfer sets. Genesis mints exactly the attested custody reading into the reserve mirror and distributes it by one atomic set. Every ordinary set conserves per asset, checked before commit, leaving the sum unchanged. Only the bridge moves the sum, either a mirror mint against a finalized deposit proof with an unused nullifier or a mirror burn against a finalized payout, and each moves the sum and custody by the same amount in the same direction. Nullifiers make double credit and double payout impossible.

Reconciliation is cheap per batch, since conservation holds per set and pass through accounts sit at zero, and full per checkpoint: sum thirteen disjoint account buckets from state, compute custody from the finalized bridge event log, compare with tolerance zero, and have an auditor check the custody figure against the vault at the referenced block out of band. Any mismatch halts sealing, attestation and checkpointing, and arms emergency exit. A mismatch is never reconciled by adjusting a balance. It is diagnosed by replaying to the first set whose legs did not sum to zero.

11Security and threat model

11.1 Trust, stated per actor

Every actor is trusted for something narrow and distrusted for everything else. The agent is trusted for custody of its own key and the meaning of its payloads, never for encoding correctness, sequence monotonicity or the truth of any balance it asserts. The sequencer is trusted for proposing an order and supplying a bounded timestamp, never for validity, fair inclusion or non equivocation. It cannot mint, cannot forge a receipt for an unsigned activity, and cannot reorder a distributed range. The guarantor is trusted for the six duties, never for individual honesty, independence or liveness. It can only attest or withhold, never alter state. The oracle signer is trusted for the authenticity of its own observations, never for their truth. A service is trusted to deliver its own resource, never to debit anyone. The Paxeer contract is trusted for custody and certificate verification. Its correctness is a root assumption, and its only defence is minimality.

11.2 The attack catalogue

ATTACKMECHANISM THAT BOUNDS ITRESIDUAL
Sequencer censorshipForced inclusion requests posted to Paxeer: include or produce a deterministic rejection within the window, or the checkpoint is invalid and guarantors refuse to attestLatency up to the window, then emergency exit
Sequencer equivocationChained, signed headers. Two conflicting headers at one number are a self contained slashing proof on PaxeerPre-checkpoint receipts are provisional and presented as such
Invalid state transitionEvery guarantor recomputes every root from batch bytes and refuses on mismatch. Kernel invariants asserted per activityA wrong rule correctly implemented is reproduced by every honest node (§11.3)
Guarantor collusionIndependence audits. Bonds sized to the withdrawal rate limit. Challenge window with permissionless disagreement submissionThe primary residual risk in the system (§11.3)
Data withholdingAvailability gated finality, possession digests, sampling, on-chain chunk challenges, fail closed stallSelective refusal to one requester, backstopped by exit
ATTACKMECHANISM THAT BOUNDS ITRESIDUAL
Oracle manipulation / stalenessSigned observations bound to market and sequence. Median over a registered quorum. Staleness and deviation clamps. Fails closedPublisher majority collusion within one batch. Outage suspends liquidations
Replay / double spendSigning preimage binds version, network, type, actor, exact sequence and validity window. Sequence consumption is a state writeNone for exact replay
Grant over-drawGrants are state with caps, windows, purpose and revocation epoch. Draws decrement atomically inside the transfer setDraws ordered before revocation are final. Exposure bounded by the cap
Double withdrawal / forged depositNullifiers binding amount and asset, marked spent atomically with payout. Deposits credit only from the reserve mirror against finalized proofsConditional on contract correctness and source chain finality depth
Overflow / non canonical encoding / DoSChecked arithmetic with no bare operators. One valid encoding with round trip fuzzing. Size limits before allocation. Metered fees price state growthA well funded attacker raises fees for everyone, which is the intended economic response
Table 4 — The attack catalogue. Every mitigation names an enforcement point in the reference implementation. A mitigation with no enforcement point is a release blocker.

11.3 Residual risks, stated honestly

Six risks survive every mitigation, and the design's answer to each is disclosure plus a backstop. Threshold attestation is not a validity proof, which is the most important limitation in the system (§8.4). A correct implementation of a wrong rule: determinism guarantees agreement, not correctness, and the mitigations are versioned transitions, shadow replay before cutover, and reserve reconciliation at every checkpoint. A single active sequencer: liveness has a single point of failure in v1, and forced inclusion, slashing and exit bound the damage without restoring low latency during an outage. Trust in the Paxeer contracts: unmitigable except by minimality. Agent key custody: the protocol cannot distinguish an agent from an attacker holding its key, and session key scoping and revocation bound the damage. Off chain semantics: ordered attestations prove who claimed what and when, never that the deliverable was good.

11.4 Emergency exit: where every mitigation terminates

No combination of sequencer misbehaviour, guarantor unavailability or data withholding can trap custodied value indefinitely. The Paxeer contract evaluates its triggers independently of LayerX, whether a checkpoint stall, an unanswered forced inclusion, proven equivocation, or a governance declaration, and in exit mode an agent submits a balance membership proof against the last finalized root plus an unspent nullifier. Four properties are non negotiable, and any change that weakens one is rejected regardless of its other benefits. Exit depends only on a finalized checkpoint, a proof and a nullifier, never on sequencer or guarantor cooperation or LayerX liveness. Exit is possible from data an agent can hold locally. Exit never requires the contract to interpret module semantics, because positions resolve to account balances first. Emergency mode halts deposits and ordinary withdrawals so the same reserve cannot be paid twice while exits drain it.

12Migration and genesis

12.1 Posture

The protocol starts from an explicit genesis manifest, not a silently inherited database. Three rules govern the migration from the existing implementation. Nothing is imported implicitly: every unit of value and every state object appears in a named, typed, individually Merkle rooted section or it does not exist. Nothing unbacked is imported: the manifest total must reconcile against Paxeer custody with tolerance zero, with no partial import and no pro rata haircut mode. The old system is read only from freeze until retirement. Ten import sections cover balances, vault reserves, open holds, queued withdrawals, pools, open positions, pending orders, funding state, identity bindings and anchored historical roots, each with explicit per entry rejection rules. Genesis itself obeys 402LXP: one mirror mint of the attested custody balance, then one atomic transfer set distributing it, so the reserve invariant holds from the first commit.

12.2 Shadow replay and cutover

Before cutover, the new implementation must reproduce the old system's accepted outcomes. Its operation history is exported in commit order, translated into activity envelopes, and replayed with per operation comparison of acceptance, balances, conservation, fills, liquidations, funding and receipt semantics, all at exact tolerance. Acceptance requires at least thirty consecutive days and a million replayed operations covering every activity type, zero unexplained divergences, a written justification and pinning test for every allowlisted one, and byte identical state roots between independently built nodes on different architectures.

The cutover runbook freezes the old system through an ordered, verified procedure. Markets go to reduce only and then pause, in flight work drains, funding settles to a clean boundary, writes are revoked, and a signed freeze certificate is produced. Custody is then read at one finalized block, the manifest is built and independently re-verified, the genesis root is registered on Paxeer, and modules open in stages with verification gates at each step. Three rollback windows are specified in advance, from a cost free reversal before registration to an explicit reverse migration after the first finalized user activity. In every window agent funds stay reachable: through the old system, the new one, or the Paxeer emergency exit.

13Comparative analysis

The comparison is made against the specific workload this paper addresses, meaning high frequency, low value, machine initiated economic activity with a consequential work record, not against general suitability.

APPROACHMARGINAL COSTPERCEIVED LATENCYSETTLEMENT GUARANTEEWORK-LIFECYCLE RECORD
Direct L1 transferPer transaction, and it may exceed the paymentBlock intervalBase chain consensusNone. Payments only
General rollupReduced but material, with per transaction data costSub-second soft, minutes to hours hardFraud or validity proofs over general executionPossible via contracts, at general execution fees
Bilateral payment channelZero in channelImmediateCounterparty liveness plus watchtowersNone. Pre-funded pairs only
Prepaid API creditsZero, but the funds are not moneyImmediateFull custodial trust with no external auditProvider logs, unilateral
LayerXMetered micro fee (~0.005 USDX base), no per activity L1 costMilliseconds to a receipt, with an explicit ladder to settledBonded threshold attestation, availability gated, with unassisted exitFirst class: commitments, attestations, deliveries, disputes in the same log as payments
Table 5 — Positioning against neighbouring designs for the agent economy workload.

The honest summary is that LayerX trades generality for auditability and cost. A rollup can run anything and pays for that in fees and in the size of its trusted computing base. A bilateral channel achieves zero cost but confines an agent to counterparties it has pre-funded. Credits are free and instant but are not money and leave no portable record. LayerX fixes the operation vocabulary, ten modules and one financial doorway, and in exchange gets deterministic replay cheap enough for bonded parties to re-execute everything, fees measured in tenths of cents, and a work record that is ordered, signed and provable rather than logged. Its trust model sits deliberately between a rollup's proofs and a sidechain's committee: stronger than multisig attestation, because finality is availability gated and exits are unassisted, and weaker than a validity proof, stated as such, with the upgrade path specified.

14Roadmap

The roadmap is stated as capability milestones, each gated on the previous phase's invariants holding under production load. The central property is that the activity protocol never changes. Determinism, canonical encoding, integer arithmetic and fixed Merkle construction already give the transition function everything a prover needs, so the entire migration to validity proofs is confined to the checkpoint acceptance path.

PHASE I
Qualification
Byte identical replay across architectures over millions of activities. Crash recovery at every write boundary. Fuzzing, overflow and rounding proofs. Guarantor disagreement, equivocation and data unavailability drills. Emergency exit executed on a Paxeer testnet for every account class. Shadow replay against the legacy system to its acceptance criteria.
PHASE II
Cutover
Freeze, genesis with zero tolerance custody reconciliation, staged module opening, meaning transfers first, then escrow, budgets, streams and services, then perps after one clean funding interval, and a canary with real agents before the old system retires.
PHASE III
Prover in shadow
A prover produces succinct proofs that each state transition correctly executes the committed activity root under the recorded version. The certificate gains an optional, version gated validity proof field. Guarantors keep attesting, and every proof is checked against their conclusion, which is how prover bugs get caught before anyone relies on them.
PHASE IV
Dual acceptance
Paxeer accepts a certificate carrying a verified proof or a threshold of attestations. Old certificates stay valid and the field is additive. No activity type, receipt field, state machine rule or agent facing signature changes.
PHASE V
Proof primary
A valid proof alone suffices for the state root. The threshold drops toward an availability only quorum, and the challenge window shortens because validity no longer depends on it. Guarantors persist for data availability, since someone must still hold and serve the history, with bonds sized to availability failure rather than custody theft.

15Conclusion

The agent economy needs more than a payment rail. It needs a canonical record of machine work: who committed, who executed, who delivered, who accepted, who paid, ordered once, executed deterministically, and settled to a custody layer that verifies certificates rather than trusting operators. LayerX is that record. Its discipline is architectural, not aspirational. One envelope for every action. One doorway for every monetary effect. One clock, one balance writer, one chain of state roots with no fork choice rule to argue about.

The guarantees are plain on purpose, and they are checkable. Conservation is an induction anyone can re-run. Finality is a ladder with named rungs, not an adjective. The guarantor quorum is a bonded cost floor whose failure mode is a halt, and the halt's failure mode is an exit that works with the whole system offline. Where the design cannot prove something, whether validity, censorship, or the truth of an attested claim, it says so in the specification, in the SDK and in this paper, because an agent economy will be built on what its participants can verify, not on what its operators assert.

Paxeer provides the consequence. Matrix provides the cognition. LayerX provides the canonical account of the work between them: every action ordered, every effect conserved, every receipt provable.

References

1. Sidiora Labs Inc. LayerX Protocol — Architectural Brief and 402LXP Gateway Design. spec/layerx-protocol, 2026.
2. Sidiora Labs Inc. LayerX Canonical Wire Format (LXC/1). spec/layerx-protocol/docs/wire-format.md.
3. Sidiora Labs Inc. LayerX State Machine. spec/layerx-protocol/docs/state-machine.md.
4. Sidiora Labs Inc. LayerX v1 Activity Type Catalogue. spec/layerx-protocol/docs/activity-types.md.
5. Sidiora Labs Inc. LayerX Batches, Checkpoints and Finality. spec/layerx-protocol/docs/checkpointing.md.
6. Sidiora Labs Inc. LayerX Paxeer Guarantors. spec/layerx-protocol/docs/guarantors.md.

7. Sidiora Labs Inc. LayerX Data Availability. spec/layerx-protocol/docs/data-availability.md.
8. Sidiora Labs Inc. LayerX Economics. spec/layerx-protocol/docs/economics.md.
9. Sidiora Labs Inc. LayerX Threat Model. spec/layerx-protocol/docs/threat-model.md.
10. Sidiora Labs Inc. LayerX Migration. spec/layerx-protocol/docs/migration.md.
11. S. Josefsson and I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032, 2017.
12. B. Laurie, A. Langley and E. Kasper. Certificate Transparency. RFC 6962 (Merkle tree construction), 2013.
13. W3C. Decentralized Identifiers (DIDs) v1.0. W3C Recommendation, 2022.
14. R. Fielding et al. Hypertext Transfer Protocol — HTTP/1.1. RFC 2616, §10.4.3 (402 Payment Required), 1999.
15. R. C. Merkle. A Digital Signature Based on a Conventional Encryption Function. CRYPTO '87.

Appendix A — Selected protocol constants

PARAM_BATCH_INTERVAL_MS 250. Target batch cadence, with a heartbeat batch every 10 s on an empty mempool.
LX_MAX_BATCH_ACTIVITIES 65,536 activities or 64 MiB per batch, whichever seals first.
PARAM_CHECKPOINT_BATCHES 2,400 batches (≈ 10 minutes) or 600 s per checkpoint.
PARAM_CHALLENGE_WINDOW_MS 86,400,000. One day between attested (L3) and settled (L4).
N / T 7 guarantors, threshold 5. T ≥ ⌊2N/3⌋ + 1, N ≥ 4, T ≥ 3.
LX_GUARANTOR_BOND_MIN 100,000 USDX minimum bond. Sequencer bond 250,000 USDX. Sized to T·B ≥ 2W.
PARAM_UNBOND_MS 32 days, strictly exceeding the challenge window plus the 30 day slash evidence window.
LX_FEE_BASE 5,000 µUSDX base fee. Congestion multiplier 1× to 64×, epoch recomputed.
Fee split 3000 / 3000 / 2000 / 2000 bps for sequencer, guarantors, insurance, treasury. Must sum to 10,000.
LX_DA_CHUNK_SIZE 64 KiB availability chunks. Five sections per batch. 16 chunk possession probe.
PARAM_DA_RETENTION_DAYS 90 days guarantor retention past finality. Archive nodes retain forever.
PARAM_LIVENESS_TIMEOUT_MS 30,000. No new batch for 30 s triggers sequencer loss recovery.
PARAM_EXIT_INACTIVITY_MS 604,800,000. Seven days without a successor arms emergency exit.
LX_MAX_TRANSFER_LEGS 64 legs per atomic transfer set. Delegation depth ≤ 4. Payload ≤ 65,024 B.
Paxeer
PAXEER NETWORK · LAYERX
Declare. Execute. Settle.
Sidiora Labs INC. · PAXEER NETWORK    V2.0 · AUGUST 2026
PROTOCOL TAG LXP1 · SPEC/LAYERX-PROTOCOL