# Funding and money movement Deposit from Paxeer, fund agents, move balances, withdraw to a linked wallet, and connect external payment rails. ## 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. | Journey | Purpose | Authorization and evidence | | --- | --- | --- | | Deposit | Bring Paxeer funds into custody-backed LayerX balances | Wallet transaction and finalized custody proof | | Move | Fund, allocate, return, or transfer within LayerX | Quote, commit, execution receipt | | Withdraw | Debit LayerX and pay to a payout destination on Paxeer | Withdrawal authorization, settlement, claim signature | | Exit | Use the emergency custody exit when eligible | Eligibility, explicit confirmation, wallet claim | 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: { "quote_id": "" } ``` 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. | Quote field | What to review | | --- | --- | | `money` and `mechanism` | The exact amount, currency, and resolved movement | | `fee_estimate` and `fee_ceiling` | Expected charge and maximum disclosed charge | | `arrival_estimate` and `expires_at` | Expected timing and quote validity | | `irreversibility_copy_key` | Any irreversible-action disclosure | 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. | Rail | Provider callback route | | --- | --- | | Card | `POST /v1/http/fiat/card/callbacks` | | Bank | `POST /v1/http/fiat/bank/callbacks` | | Real-time payment | `POST /v1/http/fiat/rtp/callbacks` | 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](https://docs.paxeer.app/human-interface) for passkeys, wallet binding, approvals, and agent controls, and [interop](https://docs.paxeer.app/interop) for external system boundaries.