Executive summary
Crypto wallet infrastructure is the product layer that determines who controls assets, who may authorize a transfer, how signing occurs, how blockchain transactions become product state and how operations recover when something fails. Generating an address is the easy part.
Modern wallet platforms expose several control models. Circle, for example, separates developer-controlled wallets, user-controlled wallets and modular wallets. The engineering decision is therefore not simply “which SDK?” but “which economic and authorization boundary should exist in the product?”
Choose the control model before choosing the wallet provider.
Three production wallet models
User-controlled and embedded wallets
Use this model when the user should own and approve transactions. The application can provide Web2-style onboarding and a branded wallet UX, while transaction approval remains at the user boundary. This is common in consumer fintech, loyalty, gaming and embedded on-chain products.
Developer-controlled and programmatic wallets
Use programmatic wallets when backend services need to create accounts, collect deposits, automate payouts, move treasury funds or execute other server-side flows. Circle documents this class specifically for backend-controlled creation and transaction execution.
Treasury and institutional operations
Business reserves and operating funds require a different control plane: roles, transaction policy, approvals, allowlists, recovery, segregation of duties and audit evidence. Platforms such as Fireblocks position vault and policy infrastructure around these operating requirements.
The five layers of wallet infrastructure
- Identity and wallet registry — map product users, accounts and business entities to canonical wallet records.
- Authorization policy — decide whether the operation is allowed before any signer is invoked.
- Signing — MPC, passkeys, keys or smart-account ownership execute the cryptographic authorization.
- Blockchain execution — submit, observe and classify transaction finality.
- Ledger and operations — post accepted business events, reconcile balances, operate treasury and preserve recovery evidence.
Signing is not authorization
A backend credential that can request a signature should not automatically have permission to move any amount to any address. Product policy should evaluate actor, asset, network, amount, destination, transaction purpose, limits and required approvals before the signing layer is called.
This separation is especially important for programmatic wallets because automation makes both legitimate operations and implementation mistakes faster.
Wallet balance is not product balance
On-chain state answers “what assets are at this address?”. It does not answer why funds arrived, whether they belong to a customer deposit, whether they were accepted, whether an adjustment was made, or whether treasury already moved them. That business interpretation belongs in an internal ledger.
For payment use cases, continue with Dedicated Deposit Addresses for USDC Payments and the stablecoin ledger guide.
Recovery belongs in architecture discovery
Recovery is not only “restore a key”. Production recovery includes lost user authentication, device migration, signer unavailability, provider outage, stuck transaction, incorrect policy, compromised operator access and safe reactivation. The correct path differs by user-controlled, programmatic and treasury models.
Provider abstraction without pretending providers are interchangeable
We normally keep a product-owned wallet registry and transaction model around provider-specific IDs. This reduces vendor coupling, but it does not pretend providers are identical. Custody model, signing guarantees, chain support, recovery and policy capabilities remain explicit architecture decisions.
When smart accounts matter
EOAs are simple and broadly compatible. Smart accounts can introduce gas sponsorship, batching and programmable authorization on supported EVM networks. Circle’s current account-type documentation distinguishes these capabilities and recommends selecting account type after the wallet product/control model.
Production checklist
- Define economic ownership and custody/control boundary.
- Define who can initiate, approve and sign.
- Keep wallet IDs and addresses mapped to canonical business entities.
- Use idempotency for wallet creation and transaction execution.
- Separate transaction submission from business posting.
- Separate customer deposits from treasury sweeps.
- Design provider outage and recovery procedures.
- Reconcile provider/chain evidence with the product ledger.
- Give operators a searchable transaction timeline.
Conclusion
The strongest wallet architecture does not start with a vendor feature matrix. It starts with control. Once ownership, authorization, signing and operating responsibilities are explicit, the provider and chain become implementation choices rather than accidental definitions of the business model.