Custodial wallets support transferring assets using the /transfer endpoint — the same interface used by non-custodial wallets. This provides a simple, chain-agnostic way to move funds without needing to encode raw transaction data.
All transactions from custodial wallets are executed server-side.
For custodial wallets, only assets that are supported by the custodian can be transferred.Supported assets: OUSD, USDC, USDB, and EURCSupported chains: Tempo, Base, and Solana
Like non-custodial wallets, custodial wallets with an owner or additional_signers require an
authorization signature for transaction
requests.
Payment initiation context. This should be provided depending on SCA requirements for
the custodial wallet. This context is passed to Bridge. Learn more about
Strong Customer Authentication
(SCA).
How the payment was initiated. Use p2p_mobile_payment for peer-to-peer transfers initiated
on a mobile device; other_mobile_payment for non-P2P mobile-initiated payments (e.g. a
merchant payment via a mobile app); other for payments not relying on a mobile device.
Whether the payment was made remotely or in person. Use remote for payments initiated
from a distance (mobile app, online banking, or e-commerce checkout); non_remote for
payments made in person (physical card, payment terminal, or contactless tap).
Authentication factor metadata. Optional when outcome is sca_used; if provided,
it must contain at least two entries from different category values (e.g. one
possession factor and one knowledge factor). Omit this field for any other outcome.
The type of authentication factor used: knowledge (something
only the user knows, e.g. a PIN or password), possession (something only the
user has, e.g. a phone receiving an OTP or a hardware token), or inherence
(something the user is, e.g. a fingerprint or face scan). When outcome is
sca_used, the two factors in auth_factors must belong to two different categories.