Funding and money movement

Understand the boundary

Paxeer X combines LayerX account execution with Paxeer settlement. Deposits, withdrawals, and emergency exits cross the custody boundary. Moving funds between accounts or into an agent is an internal move. Internal movement does not open a wallet or select a settlement domain.

The Human API uses paxeer as its settlement domain. Boundary requests may specify settlement_domain; internal moves do not. Money-moving mutations require an Idempotency-Key. Retain the key when retrying the same intended operation, and reconcile its journey before starting another movement.

Deposit from a linked wallet

1. Check the bound payout wallet and the asset and amount you intend to deposit.
2. Start with POST /v1/deposits, supplying money and an optional settlement domain.
3. Review the journey's wallet request and sign the requested custody transaction.
4. Submit wallet_transaction to POST /v1/deposits/{journey_id}/confirm.
5. Follow the journey through confirming on Paxeer and crediting the account.

The wallet request supplies the stage, explanatory copy, sending address, and exact signing bytes. First deposit can incorporate wallet linking. Account credit follows finalized custody proof; a submitted transaction or wallet acknowledgement alone does not establish a credited balance.

Move money and fund an agent

Quote the source, destination, and amount first. The resolver selects fund, allocate, return, or transfer from the account relationship. Users choose what they intend to move; they do not choose a lower-level mechanism to bypass those relationships.

POST /v1/moves/quote

{
  "source": "acct_01j2gxq0aab1c2d3e4f5g6h7j8",
  "destination": "acct_01j2gxq0aak9m0n1p2q3r4s5t6",
  "money": { "amount": "500000", "currency": "LXP" }
}

POST /v1/moves
Idempotency-Key: <unique-key-for-this-move>

{ "quote_id": "<quote_id-from-response>" }

These request fields follow the Human API golden wire example. Amount is an integer string in the asset's precision, not a floating-point number. Obtain the quote ID from the response; the placeholder is not a real quote.

Commit returns a journey. A refused movement reports the refusing authority, explanatory copy, remaining money, and optional change path. Agent funding uses this same quote-and-commit surface. Reclaim uses POST /v1/agents/{agent_id}/reclaim with money and returns a move with return semantics.

Spending and fee budgets

Agent monthly limits govern spending. Native fee budgets independently constrain per-activity fees, aggregate fees, and period fees. Read GET /v1/sessions/fee-policy for the native fee asset, currency, and decimals. Present the principal movement and the execution fee separately so an agent's funding amount is not confused with its ability to pay fees.

Withdraw to Paxeer

1. Review the destination, amount, and withdrawal authorization.
2. Start POST /v1/withdrawals with money, destination, and optional settlement_domain.
3. Track processing and waiting-for-settlement.
4. When ready-to-claim, sign the claim and submit claim_signature to POST /v1/withdrawals/{journey_id}/claim.
5. Follow paying-out and verify the resulting settlement evidence.

Withdrawal debits LayerX and pays on Paxeer with a nullifier that prevents duplicate redemption. Withdrawal is a sensitive authorization class and requires step-up evidence. Human verification advances from receipt-verified to checkpoint-finalised and paxeer-finalised only as the corresponding evidence arrives.

Emergency exit

Check GET /v1/exit/eligibility first. The response includes eligibility, explanatory copy, and an optional path to ordinary withdrawal. When eligible, start POST /v1/exit with the explicit confirmation phrase get my money out and optional settlement domain. The exit journey gets ready, requests its wallet claim, and follows confirmation on Paxeer.

Exit uses its own authorization class and step-up evidence. Treat a wallet signing request as one stage in the journey, then inspect finality evidence for the payout outcome.

Card, bank, and real-time payment rails

The fiat interop adapter connects provider callbacks for card, bank, and real-time payments. Provider evidence distinguishes authorised, clearing, settled, reversed, and chargeback events. Credit and corrective movements require accepted provider evidence and a receipt-gated LayerX result.

These are provider integration endpoints, not consumer deposit or card-entry endpoints. Callbacks carry token references only; PAN-shaped input is refused. A provider's authorisation is distinct from settlement, and reversal or chargeback is represented as its own verified event.

Independent market-maker ramps

Market-maker ramps let ordinary LayerX principals offer external conversion through quote terms and receipt-gated orders. Their toolkit compiles payer grant draws and operator sends, verifies order receipts, and journals orders. External custody is explicitly labelled so users can distinguish a ramp operator's custody from the Human account custody boundary. This ramp role is separate from the fiat callback adapter.

Reconcile the result

Read balances through GET /v1/account/balance, journey status through GET /v1/journeys/{journey_id}, and proof material through GET /v1/evidence/{evidence_id}. Journey states preserve still-checking, refused, and waiting-for-you alongside completion. The API response envelope is { ok, result?, error?, trace }; retain trace and evidence references for support.

See the Human interface for passkeys, wallet binding, approvals, and agent controls, and interop for external system boundaries.