BOFU / crypto wallet development

Build the wallet experience around control, not SDK demos.

We design and implement embedded, user-controlled, developer-controlled and treasury wallet systems around identity, signing, recovery, ledger state and operations.

Scope wallet developmentCompare wallet control models

Current wallet platforms expose different control models. Circle, for example, distinguishes developer-controlled, user-controlled and modular wallets; the correct choice depends on who can move value and how recovery works.

COMMERCIAL / DELIVERY MAP

1

business obligation

2

integration boundary

3

accepted product state

4

operations / evidence

Embedded wallets
MPC / passkeys
Ledger + treasury

Control

User / backend / treasury

Choose who authorises transactions before selecting account type, signing SDK or custody provider.

Signing

MPC / passkeys / policy

Integrate the mechanism that fits the ownership and recovery boundary rather than exposing raw key-management complexity.

State

Wallet ≠ ledger

Product balances and business obligations are represented through accepted ledger events, not inferred from addresses alone.

Operations

Observable

Deposits, withdrawals, approvals, failed transactions, sweeps and recovery states are visible to operators.

Control model

A wallet project starts with one question: who is allowed to move the funds?

That answer determines authentication, signing, recovery, product UX, compliance boundary and treasury operations.

01 / USER

User-controlled / embedded

Users own and approve transactions through an embedded experience using provider-supported authentication, MPC or passkeys.

Outcome

User ownership

02 / BACKEND

Developer-controlled / programmatic

Backend services create wallets and execute transactions for deposits, payouts or automation under your policies.

Outcome

Automation

03 / TREASURY

Business-controlled treasury

High-value operations use explicit approval roles, policies, destination controls and segregated operating accounts or vaults.

Outcome

Governed movement

Delivery scope

What turns a wallet SDK into a production product capability.

The SDK handles part of key or transaction infrastructure. Your product still needs identity, authorization, accounting state, recovery and operations.

Wallet identity & lifecycle

Map users, organisations or payment accounts to wallet records deterministically.

Provisioning

Account mapping

Network/account types

Deactivation / recovery

Signing & authorization

Define who can initiate, approve and sign each transaction.

MPC/passkey integration

Policy checks

Limits and allowlists

Idempotent execution

Ledger & deposits

Translate external chain events into accepted product/accounting state.

Deposit addresses

Confirmation/finality

Internal ledger

Reconciliation

Treasury & operations

Separate customer-facing wallet workflows from downstream liquidity movement.

Sweeps

Payouts

Approval workflows

Audit and alerts

Proof

The difficult wallet work appears in our on-chain payment case study.

The implementation documents dedicated addresses, chain observation, finality, ledger posting and treasury as separate states instead of collapsing everything into wallet balance.

CASE / CUSTOM

Custom wallet stablecoin payment infrastructure

Dedicated deposit addresses, blockchain observer, confirmation engine, internal ledger, exception handling and treasury sweep.

Wallets
Finality
Ledger
View wallet case study

GUIDE / MPC

MPC wallet integration guide

How to select and integrate MPC around signing authority, recovery, policy and product responsibility.

MPC
Signing
Recovery
Read MPC guide

Architecture facts / verified August 2026

We use current wallet primitives, but keep product responsibility explicit.

Circle's current wallet documentation separates developer-controlled, user-controlled and modular wallet products, with different signing and ownership models. We use provider capabilities as implementation building blocks, not as the product architecture itself.

MODEL / DEV

Developer-controlled wallets

Circle documents programmatic backend-controlled wallets for payouts, automation, deposit collection and similar server-side use cases.

Circle Wallets

MODEL / USER

User-controlled wallets

Users retain control and approve transactions inside the application, with provider-supported authentication and MPC key management.

Circle Wallets

MODEL / MODULAR

Modular wallets

Passkey-based smart accounts provide a different model for user control, gas sponsorship and account modules.

Circle Wallets

If your product holds or controls assets on behalf of customers, custody and regulatory responsibilities may change materially. The control model should be reviewed before production rollout.

Related commercial paths

Wallets often exist because the product needs payments, deposits or treasury.

Use the adjacent paths when the buying intent is narrower than a full wallet platform.

USDC

USDC payment integration

Use provider or dedicated-address architecture for stablecoin payment acceptance and reconciliation.

Payments
Deposits
Ledger
Explore USDC

COINGATE

CoinGate integration

Use a managed payment provider when checkout and supported settlement belong outside the wallet layer.

Gateway
Settlement
API
Explore CoinGate

SERVICE

Wallet & Digital Asset Infrastructure

The full service covering control models, lifecycle, signing, treasury, recovery and operations.

Architecture
Control
Treasury
Explore service

Wallet development FAQ

Questions to resolve before choosing a provider.

The main cost and risk driver is usually the control and operating model, not the number of screens in the wallet UI.

Usually not unless key infrastructure is a deliberate core competency and regulatory/security responsibility of the product. Most teams should evaluate established wallet/custody providers and focus custom engineering on product state, policy and operations.

Yes in suitable wallet/provider models. The architecture also needs deterministic identity mapping, provisioning, monitoring, confirmation/finality policy and reconciliation at scale.

No. MPC describes a key/signing technique. Custody and control depend on who controls the signing credentials/shares and who can authorise transactions. The product operating model must be evaluated separately.

Not always. EOA-based wallets can be sufficient for many deposit, payout and treasury flows. Smart accounts are useful when you need programmable account behaviour such as gas sponsorship, batching or modules.

Wallet architecture discovery

Define control and recovery before committing to a wallet vendor.

Tell us who owns funds, who should approve transactions, whether you need deposits/payouts, target chains and treasury requirements. We will map the wallet control model and first production slice.

Scope wallet development[email protected]
Control model first
Provider-neutral architecture
NDA-friendly
Product + operations