Custody, deposits & exits

One settlement boundary, distinct identities

Paxeer X combines the EVM settlement network with LayerX activity execution. Assets remain in Paxeer custody while LayerX records the balances and economic activity backed by those assets. Internal transfers do not require an EVM transaction. Deposits, withdrawals, and exits cross the settlement boundary and carry evidence that binds both sides.

Linking an EVM wallet grants no authority over LayerX balances. The browser does not hold the Human protocol identity's private key. The signing service checks that a structured disclosure re-encodes to the exact canonical bytes it is asked to sign. Withdrawal, exit, wallet rebind, and secret reveal operations require step-up authorization.

Native custody precompile

The layerxcustody module exposes its EVM interface at 0x0000000000000000000000000000000000001013 on chain ID 125. Funds reside in the native module account. Release requires verified LayerX withdrawal or balance evidence; an attestor key cannot authorize a payout.

Use the complete precompiles/layerxcustody/LayerXCustody.sol interface for generated bindings. Amounts are bank base units, matching LayerX's unsigned 128-bit amounts one to one. Native payable deposits require a whole number of base units: one base unit corresponds to 10^12 wei. The beneficiary is a 32-byte LayerX account ID, not an EVM address.

Deposit example

interface ICustodyDeposit {
    function deposit(bytes32 beneficiary)
        external payable returns (bytes32 depositId);
}

// beneficiary is the recipient's LayerX account identifier.
// Example: 1,000,000 bank base units = 10^18 wei.
bytes32 depositId = ICustodyDeposit(
    0x0000000000000000000000000000000000001013
).deposit{value: 1 ether}(beneficiary);

From deposit to spendable credit

1. Resolve the recipient's LayerX account and registered asset. Inspect asset enabled/paused state, minimum deposit, and custody cap.
2. Submit the Paxeer deposit and retain its transaction, CustodyDeposit event, deposit ID, amount, and nonce.
3. Construct a Tendermint light-client proof of the custody module's committed deposit record. The signed custody genesis profile pins the module identity, asset, network, reserve, validator trust root, and trusting period.
4. Submit the signed native custody-credit activity through authenticated activity ingress. The native verifier checks the proven record and every bound field, including beneficiary identity and expected amount.
5. Verify the resulting receipt and account state before spending the credit.

The LXBC3 profile seeds validator trust. A valid LXLB1 evidence bundle has more than two thirds of the header's validator power; changed validator sets also require more than one third overlap with the trusted set. Expired trust is refused. A LXDC3 credit binds the profile digest, deposit, asset, beneficiary, amount, nonce, state height, signed header, application root, and evidence digest.

Conservation and replay protection

Credit issuance, reserve funding, the conserved reserve-to-beneficiary transfer, account creation, sequence updates, and replay evidence commit together. Failure rolls back the complete transition. The committed issued total equals the sum of balances for the asset. Deposit replay uses SHA256("LX:DEPOSIT:NULLIFIER:v1" || deposit_id); changing an activity sequence cannot credit the same deposit twice.

Withdrawals

A withdrawal first commits a LayerX debit and a recipient-bound withdrawal fact. A signed receipt and inclusion proof bind it to a finalized batch. Requesting queues a claim; finalizing verifies the evidence again and pays only the named recipient after the configured delay. Finalization can queue a previously unrequested claim, but it still enforces the delay and all evidence checks.

Track ClaimQueued, ClaimFinalised, and CustodyRelease. A nullifier reserves and then consumes the authorization so a valid receipt cannot release custody repeatedly.

Emergency exits

An emergency exit proves a whole account/asset balance under the latest finalized state root. The account authority signs the recipient binding, and the module checks exit eligibility and claim availability before payment. The path preserves access to settlement custody when ordinary sequencing is unavailable. It requires actual native state evidence; a UI balance or unsigned database row is insufficient.

Use exitEligible() before preparing an exit and retain the witness, batch number, account, asset, recipient, and recipient signature through request and execution. Both exit paths consume the proven account/asset/inclusion balance once, preventing distinct signed anchors from spending the same balance again.

Inspect assets and claims

Show evidence accurately

Human journeys progress through unverified, receipt-verified, checkpoint-finalised, and paxeer-finalised. Evidence returned by GET /v1/evidence/{evidence_id} includes its class, verification level, content type, and encoded bytes. A wallet acknowledgement alone does not establish settlement finality.

Continue with checkpoint settlement and proof verification, the precompile reference, and Paxeer JSON-RPC.