Settlement Model

Settlement model

LayerX uses a tiered settlement model that optimizes for speed on the happy path while preserving the ability to force high-value or time-sensitive transactions through immediate L1 finality.

Window-based net settlement

Most LayerX transfers are settled via net-batched windows. The sequencer accumulates transfers during a batch window (typically a few minutes), then at window close:

1. Compute net positions - for each DID, calculate the net inflow or outflow across all transfers in the batch.
2. Build Merkle tree - hash each transfer into a domain-separated leaf and construct a Merkle tree over all leaves in the batch.
3. Anchor to L1 - submit the Merkle root, batch sequence number, and metadata to the Paxeer L1 bridge contract.

This approach amortizes L1 gas across all transfers in a batch. A batch with 10,000 transfers pays one L1 transaction instead of 10,000.

Merkle root construction

Each transfer in a batch becomes a Merkle leaf:

leaf = keccak256(
  domain_separator || sender_did || recipient_did || amount || seq || timestamp
)

The domain_separator is a fixed string that prevents cross-domain replay. The tree is built bottom-up using keccak256 hashing with sorted pairs (so the tree is deterministic regardless of insertion order).

The resulting root is a 32-byte commitment to the entire batch. Anyone who has the root and a transfer's inclusion proof can verify that the transfer was committed - without trusting the sequencer.

L1 anchoring

The Merkle root is submitted to the LayerX bridge contract on Paxeer L1 (chain ID 125) via the settlement worker:

function anchorBatch(
    uint256 batchSeq,
    bytes32 merkleRoot,
    uint256 timestamp,
    uint256 transferCount
) external;

Once the anchor transaction is confirmed on L1, the batch is final. No one - not even the sequencer operator - can retroactively alter the transfers in that batch.

Force-settle

For transfers that cannot wait for the next batch window, LayerX supports force-settlement. A force-settled transfer is committed to L1 individually, outside the batch cycle.

When to use force-settle

• Large withdrawals - moving significant USDX back to USDL on L1.
• Time-sensitive settlements - when L1 finality is needed within seconds, not minutes.
• Dispute resolution - when a party wants immediate on-chain proof of a specific transfer.

How it works

1. Call POST /v1/force-settle with the transfer sequence number.
2. The settlement worker verifies the transfer exists and is unsettled.
3. The worker submits the transfer to L1 individually.
4. The L1 transaction hash is returned.

Force-settled transfers are still included in the next batch's Merkle tree for consistency, but their L1 finality does not depend on the batch.

Withdrawal settlement

When an agent withdraws USDX to USDL on L1:

1. The withdrawal request is recorded in the LayerX ledger.
2. USDX is debited from the agent's account immediately.
3. At the next settlement window (or via force-settle), the settlement worker releases USDL from the bridge contract to the agent's L1 address.

Withdrawals are always material-tier - they result in an L1 transaction regardless of the batch cycle, because the bridge contract must release USDL on-chain.

Tiered model summary

The tiered model lets LayerX handle millions of agent transfers at zero marginal cost, while preserving the option for immediate L1 settlement when the situation demands it.