Peer Cash Order

Create Safely

1. Call peer_cash_capabilities. Use only the returned rails, currencies, assets, and bounds.
2. Call peer_cash_estimate. Tell the operator the Chainlink estimate is approximate.
3. Call peer_cash_prepare with the Base USDC amount as a 6-decimal base-unit string and the required receive legs.
4. Present the ordered unsigned transaction plan and obtain approval for its exact destinations, values, calldata purposes, and effects.
5. Have the host wallet submit each transaction in order. Confirm the createDeposit receipt.
6. Call peer_cash_finalize with the confirmed transaction hash.
7. If accessPolicyRequired is true, prepare, approve, and submit that follow-up transaction with the depositor wallet.
8. Persist the returned depositId; use peer_cash_order to resume.

Manage The Order

• Use peer_cash_orders to list a maker's orders.
• Use peer_cash_prepare_withdraw to prepare a full or partial withdrawal of unmatched funds.
• Use peer_cash_prepare_top_up to add funds.
• Apply the same ordered-plan review and wallet-confirmation rules to every mutation.

Recover Uncertain Outcomes

• Retry ORDER_NOT_FOUND only as a read; an immediate post-finalization miss can be indexer lag.
• For TRANSACTION_SUBMISSION_UNKNOWN or TRANSACTION_STATUS_UNKNOWN, inspect the named hash, wallet activity, and existing orders before resubmitting anything.
• For ACCESS_POLICY_CONFIGURATION_FAILED, repair the policy step; the deposit already exists.
• Retry INDEXER_UNAVAILABLE and ORACLE_READ_FAILED only as reads.

If evidence cannot prove whether a mutation occurred, stop and require wallet or block-explorer confirmation. Never request a private key or seed phrase.