When you withdraw from the LayerX agent domain, you send the withdrawal receipt, its inclusion proof and the sequencer-signed batch header, and the chain checks the sequencer's authorisation and the finalised roots before it queues your claim. Finalisation pays it after the delay. If checkpoints stop arriving past the liveness bound, you prove your whole account balance under the last finalised state root and sign the recipient yourself. Every claim reserves a nullifier, so it pays once.

What it does

Paxeer settles every exit from the LayerX agent domain as a claim the chain verifies for itself. A withdrawal carries the LayerX withdrawal receipt, its inclusion proof and the sequencer-signed batch header; the chain checks that the sequencer was authorised for that batch and that the header's state and receipt roots match the finalised checkpoint it already holds before it queues anything. A forced exit instead proves the whole account balance under the latest finalised state root, together with an Ed25519 signature from the account's authority key naming the Paxeer recipient. Each claim reserves a nullifier derived from the network, withdrawal id, account, asset, amount and anchor, so it can pay out only once.

Key capabilities

• Verifies receipt inclusion, sequencer authorisation and finalised roots before queuing a claim.
• Reserves a nullifier per claim; it is consumed on payout or terminally cancelled.
• Forced exits prove a full account balance plus the authority's signed recipient.
• Exits open on an emergency declaration or a checkpoint gap past the liveness bound.
• Two-step payout: the request queues a claim, finalisation pays it after the delay.
• Native module and Solidity contracts derive the same claim ids and nullifiers.

Differentiators

The native Go path and the Solidity contracts derive claim ids, withdrawal ids and nullifiers from the same domain strings, so one claim means the same thing on both. A forced exit needs only a finalised state root and the account authority's signature; no sequencer, operator or governance action takes part in it.

Outcomes

• Exit without cooperation from the agent domain, sequencer or governance.
• Each claim pays exactly once, guarded by a reserved nullifier.
• Native Go and Solidity paths derive the same claim ids.

Technical notes

• Defaults: withdrawal delay 3600 seconds, forced-exit delay 0 seconds, liveness bound 86400 seconds. The liveness bound has a one-hour floor and both delays are capped at 90 days; EmergencyExit and StaticConfig enforce the same one-hour floor on the Solidity side.
• Anyone may send RequestWithdrawal, FinaliseWithdrawal, RequestForcedExit and ExecuteForcedExit. Registering a checkpoint, declaring the emergency and cancelling a pending claim are authority-only.
• Deposits are deliberately absent from the custody message service: they enter only through the custody precompile at 0x0000000000000000000000000000000000001013, so every deposit carries an EVM log.
• On the Solidity path a claim becomes payable when the checkpoint's challenge window closes, and finaliseClaim also requires the checkpoint to still be claimable. The native module uses the fixed params delay plus the authority's cancel instead.
• EmergencyExit.executeExit reads balanceConsumed under the caller-supplied checkpoint but writes it under latest. Both overloads require the two to be equal, so the guard holds, but the key expressions differ.
• The native ExitEligible has no equivalent of the Solidity firstInvalidatedBatch() != 0 trigger, so an invalidated batch on its own does not open exits on the native path.

More in Paxeer chain