How to set up Crossmint Agent Wallets for USDC

Crossmint Agent Wallets let a user own a smart wallet while a backend server acts as a delegated signer that can send stablecoins on the user’s behalf after email approval. The flow requires a wallet created at login, a server signer registered from the backend with prepareOnly set to true, an email one-time passcode the user must enter, and a revoke path that runs with the user’s recovery signer.

Developers should run the Crossmint quickstart on base-sepolia for staging and on base mainnet for production. Required tools are Node.js 20 or newer and pnpm. The project needs a Crossmint staging console with a client API key and a server API key, plus a 32-byte CROSSMINT_SIGNER_SECRET stored only on the server. Staging keys and flows are intended for development only.

To register the server signer, the backend calls wallet.addSigner with a server signer and prepareOnly true. That call returns a locator and a signatureId. The client activates the email recovery signer and calls wallet.approve with the signatureId, which triggers an email OTP. Only after the user enters the OTP does the server signer gain permission to sign transactions for that wallet.

On staging, developers can mint test USDXM into the wallet with wallet.stagingFund(5). Production funding requires real USDC via Crossmint’s onramp or a transfer to the Base mainnet USDC contract at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. The backend performs sends by calling wallet.useSigner with the server secret on the wallet handle, then wallet.send(recipient, type, amount) where type is usdc in production or usdxm in staging. On supported chains Crossmint may sponsor gas, removing the need for user ETH in those paths.

Activation of the server signer is per wallet handle. If the application fetches or creates a wallet handle again, it must call useSigner again before signing. Developers should treat stagingFund as a lab faucet and fund production wallets with an onramp or treasury transfer. Implement server-side spend limits and policies before live use.

Security requirements include never exposing CROSSMINT_SIGNER_SECRET to client code, browsers, or external prompts. Anyone holding that secret can sign transactions for every wallet that secret has been authorized on. The addSigner call returns a locator that is unique per wallet; developers must persist that locator to enable later revocation.

Revocation must run with the user’s recovery signer active. The client activates the email recovery signer and calls wallet.removeSigner with the locator. The server signer cannot revoke itself and removeSigner will fail if the server signer is active at the time of the request. The Crossmint quickstart repository contains a reference implementation showing create-on-login, addSigner with prepareOnly, staging funding, backend sends, and per-wallet revocation.