Skip to main content
This page explains how signing and authorization work across Circle Wallets products: who initiates transactions, who approves them, where keys live, and how the transaction lifecycle differs by wallet type. The main difference between products is who initiates each transaction and who approves (signs) it. For details on how keys are secured (MPC, passkeys, node hosting), see Key management.

​
Who initiates and who approves

Every onchain transaction must be initiated (requested) and then approved (signed) before it is broadcast. The wallet type determines who does each step. In developer-controlled wallets, your backend does both. In user-controlled and modular wallets, your app initiates but the end user must approve (authenticate and authorize signing). Keys are never shared with Circle in a way that lets Circle sign without that approval.
Wallet typeInitiates requestWho moves fundsKeys
Developer-controlledYour backend (API/SDK). Users can also start the action in your app after you authenticate them and assign a wallet.Your backend (entity secret). Circle treats your server as the approver, not an end-user Circle sign-in.MPC; you hold the entity secret; Circle hosts MPC nodes, or you host them (for example, on-premises).
User-controlledYour app calls user APIs or SDKs (client or server) for the signed-in user.End user. Funds can only move after user authorization.MPC; key is split into shards so only the user can finish signing.
ModularYour app (SDK), on behalf of the user.End user (passkey). Funds can only move after the user authorizes.Passkey on the user’s device (or cloud backup).
Step-by-step flow for user-controlled wallets: SDK architecture.

​
Signing request lifecycle (high level)

  1. Initiate: A client (your backend or your app) calls Circle APIs to create a signing request (for example, transfer, contract call).
  2. Authorize: The party that controls the key approves the signing. In developer-controlled wallets, your backend approves using the entity secret. In user-controlled and modular wallets, the user authenticates and approves in your app.
  3. Sign: Circle (with MPC or passkey participation) produces the signature.
  4. Broadcast: The signed transaction is sent to the blockchain. For supported chains, Circle can handle broadcasting; otherwise use Signing APIs with your own node.
Submitted vs finalized. Sending the transaction to the chain (submitted) and the chain processing it to finality (complete) are two separate moments. The process is asynchronous between Circle and each blockchain: Circle does not block your API until the chain has finalized. Circle communicates state changes (for example, sent, confirmed, failed) asynchronously. You receive these updates by setting up Webhook notifications.

​
How authorization differs by wallet type

  • Developer-controlled: Authorization is programmatic. Your backend approves each request with the entity secret (or keyguard). Use when you need full programmatic control (payouts, automation, custodial flows).
  • User-controlled: Authorization requires the end user to approve the action (for example, in a confirmation UI). The user’s key shard credential is used with Circle’s MPC to complete signing. Use when users must custody their own assets and approve every transaction.
  • Modular: Authorization uses the user’s passkey on their device. The user approves in your app; the passkey never leaves the device. Use when you want passkey-based custody and flexible account logic (for example, gasless, recovery modules).
Choosing the right model depends on who should control funds and who should approve transactions. See the Wallets overview to compare products and pick one.

​
See also