Wallets and movement of funds

Each managed trading account maps your stable user ID to a managed trading wallet. Your users sign in through your product. CRISP provisions the wallet and performs authorized trading and withdrawal operations through its custody infrastructure.

Who controls what

CRISP uses Privy-backed wallet infrastructure with CRISP-controlled server signing authorization. Partner API credentials authorize permitted requests; they do not expose wallet signing keys. An external wallet connected to your app can fund an account, but does not thereby become the managed wallet's signer.

Your backend authenticates the user and checks their authority for every trade, claim and withdrawal. Your frontend obtains the user's approval for the amount, asset, network and recipient before a transfer. An external contact address stored during onboarding is not withdrawal consent.

Deposits

User's external wallet or sending service
  → Returned deposit instructions on a supported network
  → Polymarket Bridge
  → pUSD in the managed trading wallet on Polygon

The funding APIs return the account's instructions, supported networks/tokens and quotes. Availability and minimum deposits are asset-specific and can change; display the current response rather than a fixed list copied into your app. A shared EVM address format does not imply support for every EVM chain.

The deposit quote estimates output and bridge costs. The source wallet sends the transfer and pays applicable source-network gas. An API quote does not move funds. Show a deposit as complete only when destination delivery and the account balance reflect it, not when the source transaction is submitted.

pUSD and buying power

The current trading collateral is pUSD on Polygon, with six decimals. Some historical API field names end in Usdc; follow the endpoint's documented token and units rather than interpreting the field name as a different asset.

Cash balance and available buying power are different: open orders, fee obligations and other reservations can reduce what a user may spend. A missing or temporarily unavailable balance is not zero. The execution service validates funds again when an order is submitted.

pUSD is USDC-backed collateral with 1:1 wrapping and unwrapping enforced onchain. The documented CollateralOnramp.wrap() and CollateralOfframp.unwrap() contracts currently convert USDC.e on Polygon to pUSD and back. See Polymarket's pUSD documentation. These describe the underlying collateral contracts, not additional Partner API methods.

Withdrawal costs are separate from the conversion ratio. For withdrawals through the funding integration, use the current quote for the selected destination network and token to display estimated output and route costs. There is no single fixed withdrawal fee across all routes.

Withdrawals

Withdrawals require an explicitly granted permission and environment enablement. The user chooses a supported destination network/token and recipient. Your app gets a quote, confirms the details, and submits one durable withdrawal intent. CRISP signs the source transfer from the managed wallet to the bridge route.

There is no universal fixed bridge fee to hardcode. Show the quote's costs and estimated output. Source-transfer confirmation and delivery to the user's final destination are separate milestones. If the outcome is uncertain, preserve the original request and reconcile it rather than creating another withdrawal.

Referral rewards first arrive in the managed wallet; they do not bypass this withdrawal process. Funding integration explains the quote, submission and transfer states.

Account changes and recovery

Use permanent external IDs. The public contract does not offer account merging, external-ID renaming, account deletion or end-user key export. Revoking access does not erase funds or financial history. Coordinate account closure, merged identities and data-erasure requests with CRISP before changing your mappings.

The current integration has no documented independent end-user withdrawal path during a CRISP outage. An outage affecting your application also requires an agreed alternative support or access process. Establish recovery responsibilities and user-facing communications during onboarding; do not advertise an independent recovery feature that the integration does not provide.

Next: plan access and launch responsibilities or implement balances and buying power.