Make wallets part of your product architecture.
We design wallet systems around control, signing, recovery, transaction policy and operations — from embedded user wallets to programmatic deposit accounts and treasury infrastructure.
Custody and control are architecture decisions. We define the operating model first, then select the wallet provider, signing technology and chain integration.
POLICY / ACTIVE
CONTROL MODEL
User / product / treasury
SIGNING LAYER
MPC · passkeys · policy
OPERATIONS
Ledger · sweep · audit
PRODUCT SOURCE OF TRUTH
Wallet models
Embedded + programmatic
User-controlled, developer-controlled and treasury models selected around the actual ownership and authorization boundary.
Signing
MPC / smart accounts
Integrate provider signing, MPC, passkeys, EOA or smart-account execution without leaking key-management complexity into product logic.
Operations
Policy-driven
Limits, approvals, allowlists, withdrawal states, recovery and incident paths become explicit product workflows.
Financial state
Wallet ≠ ledger
On-chain balances remain execution evidence while the internal ledger explains customer, business and treasury state.
What wallet infrastructure actually includes
A wallet address is an endpoint. The product needs the system around it.
Production wallet infrastructure combines key-control decisions, account creation, transaction authorization, blockchain execution, indexing, internal ledger state, treasury movement, recovery and operator tooling. The wallet provider can secure keys; your product still owns the business rules around value.
We separate wallet control, blockchain execution and product accounting so each layer can evolve without turning the entire product into one custody-specific implementation.
01 / CONTROL
Custody and control boundary
Decide whether users approve transactions, the backend executes programmatically, or treasury operators control movement under policy.
02 / ACCOUNT
Wallet and address lifecycle
Create, assign and map wallets or deposit addresses deterministically to users, accounts, invoices or operating entities.
03 / SIGN
Signing and transaction policy
Model who can initiate, approve and sign each operation, including limits, destinations, gas policy and recovery paths.
04 / OPERATE
Ledger, treasury and observability
Connect deposits, withdrawals, sweeps, fees and exceptions to an internal ledger, reconciliation and searchable audit trail.
Control models
Who controls the wallet determines most of the architecture.
The right model depends on whether the wallet is a user-owned product surface, a backend-controlled operational account or part of institutional treasury. Providers and chains come after this decision.
MODEL A / USER
User-controlled & embedded wallets
Wallet experience lives inside the product while the user retains transaction approval and key control through provider-managed MPC, passkeys or other supported mechanisms.
CONTROL BOUNDARY
End user approves value movement
BEST FOR
Consumer products, loyalty, gaming, creator platforms, embedded finance
Authentication and wallet onboarding
Signing UX and transaction approval
Recovery and device-change flows
Gas sponsorship / smart-account UX
Backend identity and wallet mapping
MODEL B / PROGRAMMATIC
Developer-controlled wallets
Backend services create and operate wallets for deposits, payouts, automation or business flows without requiring users to manage blockchain interactions directly.
CONTROL BOUNDARY
Product backend executes under policy
BEST FOR
Deposit collection, payouts, payment orchestration, automated treasury workflows
Wallet sets and account mapping
Server-side authorization
Transaction policy and limits
Idempotent execution
Reconciliation and exception handling
Treasury & institutional operations
Digital asset movement is governed through controlled vaults, approval policies, allowlisted destinations, operational roles and separate hot/warm/cold or provider-specific security boundaries.
CONTROL BOUNDARY
Business operators + policy engine
BEST FOR
Treasury, exchanges, high-value settlement, institutional asset operations
Vault/account segmentation
Approval and signer policy
Allowlist and counterparty controls
Sweep and liquidity routing
Audit, recovery and incident procedures
Do not choose an embedded-wallet SDK, MPC vendor or custody platform before defining who can move funds, under what policy, and how recovery works.
Wallet lifecycle
Design the lifecycle before writing the first transfer call.
Every wallet needs explicit states and ownership. Creation, funding, signing, movement and recovery should be observable workflows rather than SDK side effects.
01
IDENTITY_LINKED
Identity mapped
Connect the product user, account or business entity to a canonical wallet record before any blockchain action.
02
WALLET_READY
Wallet provisioned
Create or assign the wallet/account using the selected provider or key-management architecture and persist provider references.
03
AUTHORIZED
Policy evaluated
Validate asset, network, destination, amount, permissions, risk checks and approval requirements before signing.
04
SUBMITTED
Transaction executed
Sign, submit and track the on-chain transaction with idempotency, provider correlation IDs and chain evidence.
05
POSTED
Business state updated
After the relevant confirmation/finality policy, post the accepted economic event into the internal ledger or business workflow.
06
RECONCILED
Reconciled & recoverable
Reconcile external evidence with internal state and preserve the recovery/audit path for operations.
Signing success is not business success.
A successfully broadcast transaction still needs product-state rules, finality handling, accounting evidence and downstream treasury logic. We keep signing, chain state and business state as separate concerns.
Where wallet projects fail
Most failures happen outside the cryptography.
MPC and custody providers can secure key material, but product failures usually appear in authorization, mapping, recovery, operational policy and reconciliation.
RISK / 01 / CONTROL
Custody model chosen too late
The team starts with an SDK and discovers later that transaction approval, asset ownership or regulatory responsibility does not match the product model.
Architecture rewrite around the most sensitive boundary
RISK / 02 / MAPPING
Wallets are not mapped to business entities
Addresses exist, but identity, account, invoice or treasury ownership is inferred from logs and spreadsheets.
Operational ambiguity and weak audit trail
RISK / 03 / POLICY
Signing equals authorization
A backend that can sign is allowed to sign without a separate business policy for destination, limits, role and transaction intent.
Security boundary collapses into API credentials
RISK / 04 / RECOVERY
Recovery is treated as an edge case
Device changes, lost credentials, provider outages and signer recovery are designed after launch.
Users or operators can become locked out of assets
RISK / 05 / TREASURY
Deposits and treasury share one lifecycle
Customer deposit acceptance, internal sweep and treasury movement are treated as one transaction state.
Treasury incidents contaminate customer payment state
RISK / 06 / LEDGER
On-chain balance becomes product balance
The application derives customer balances directly from wallet state instead of posting accepted business events to a ledger.
Refunds, adjustments and reconciliation become fragile
Wallet infrastructure should be operable by the business under defined policy — not only understandable by the engineer who integrated the SDK.
Engineering scope
Wallet infrastructure from product UX to treasury operations.
We work across wallet SDKs/APIs, backend orchestration, blockchain data and operational systems so the integration has a clear source of truth and failure model.
Wallet architecture & custody boundaries
Control model, provider selection criteria, account types, chain strategy and recovery boundaries documented before implementation.
User vs developer vs treasury control
EOA / smart-account decisions
Provider and chain abstraction
Signing & authorization workflows
Separate the ability to sign from the business permission to move value.
Limits and approval rules
Destination policy
Idempotency and request authorization
Wallet orchestration backend
Canonical wallet records, provider adapters, transaction state machines and APIs connected to the product domain.
Wallet/account provisioning
Provider correlation IDs
Deposit and withdrawal workflows
Blockchain observation & finality
Index deposits and outgoing transfers independently from provider callbacks when the operating model requires chain-level evidence.
RPC/indexer integration
Checkpointing and replay
Confirmation/finality policy
Treasury & sweep automation
Separate customer-facing wallet state from downstream treasury movement and liquidity routing.
Sweep state machine
Hot/treasury boundaries
Fee and gas management
Operations, recovery & reconciliation
Give operators the controls and evidence needed to investigate, retry and resolve value movement safely.
Exception queue
Recovery procedures
Audit trail and reconciliation
Delivery process
Start with control and risk. Integrate the provider second.
Our discovery process prevents the wallet SDK from defining the business architecture by accident.
Wallet architecture discovery
Map actors, asset ownership, custody/control, transaction types, recovery expectations, jurisdictions and operational roles.
OUTPUT / Control model + architecture decision record
Provider & account model selection
Compare provider capabilities, account types, network support, signing model, recovery and operational APIs against the requirements.
OUTPUT / Provider shortlist + integration boundaries
Lifecycle & ledger design
Define provisioning, deposit, withdrawal, approval, finality, sweep and ledger state machines plus correlation identifiers.
OUTPUT / Domain model + event/state specification
Integration & policy implementation
Build wallet orchestration, signing authorization, chain/provider adapters, webhooks/indexers and operator APIs.
OUTPUT / Production wallet infrastructure
Failure-mode verification
Test duplicate events, provider timeout, partial failure, rejected signing, wrong network, recovery and treasury exceptions.
OUTPUT / Runbooks + failure test suite
Operational launch
Ship monitoring, reconciliation, role-based tools, alerts and a controlled migration/rollout plan.
OUTPUT / Operable production system
Technology & providers
Provider-neutral architecture with explicit integration boundaries.
We can integrate wallet infrastructure providers while keeping wallet records, business permissions and ledger state inside your product architecture instead of coupling the domain to one SDK.
WALLET
Wallet & key infrastructure
Provider APIs/SDKs selected around custody and signing requirements.
CHAIN
Blockchain execution
EVM and non-EVM execution with chain-specific confirmation and fee strategy.
PRODUCT
Product orchestration
Wallet mapping, permissions, workflows, ledger and APIs remain product-owned.
OPS
Operations & observability
Investigate and control value movement from one operational layer.
Proof layer / NDA projects
The wallet is only credible when the failure paths are designed too.
Our digital-asset case studies focus on system boundaries, state and operations rather than publishing confidential client identity or transaction volume.
CASE / CUSTOM WALLET
Dedicated wallet infrastructure for on-chain stablecoin payments
Payment intents, dedicated addresses, chain observer, confirmation engine, internal ledger, exception handling and a separate treasury sweep workflow.
CASE / MANAGED RAIL
USDC payment system with CoinGate-managed settlement
Product-owned payment state connected to a provider rail, hosted checkout, idempotent callbacks, settlement and finance-grade reconciliation.
Commercial proof / operating model
Wallet UX is only one layer. Control, recovery and operations are the product risk.
We make ownership, signing authority, recovery and ledger boundaries visible before selecting a wallet SDK or custody vendor.
CONTROL / FIRST
Control model before SDK selection
User-controlled, developer-controlled and treasury models create different product, security and operating responsibilities.
KEYS / PROVIDER
Signing technology is an implementation choice
MPC, passkeys, EOA and smart-account execution are evaluated against the required control and recovery model rather than used as marketing labels.
Circle Wallets — account typesLEDGER / SEPARATE
Wallet balance is not customer balance
Deposits, withdrawals, adjustments, fees and treasury movements are posted through accepted product events and reconciliation instead of inferred from raw wallet state.
PROOF / NDA
On-chain payment infrastructure in production architecture
Our NDA payment case study documents dedicated deposit addresses, observation, finality, internal ledger, exception handling and a separate treasury sweep workflow.
Wallet and custody providers can secure keys or execute transactions. Softech designs the product identity, authorization, ledger, treasury workflow, observability and operator experience around those capabilities.
BOFU / wallet architecture guides
Technical content for teams already planning wallet infrastructure.
These guides focus on the decisions that appear during architecture discovery and vendor selection: control model, custody, MPC, deposit-address design and implementation budget.
PILLAR / WALLET
Crypto Wallet Infrastructure Development
A production architecture guide for embedded wallets, programmatic wallets, backend orchestration, signing policy, ledger and treasury operations.
DECISION / CUSTODY
Custodial vs Non-custodial vs Embedded Wallets
Choose a wallet control model by product responsibility, signing authority, recovery and operating model instead of UX terminology alone.
SECURITY / MPC
MPC Wallet Integration Architecture
How MPC fits into key management, signing authorization, policy, recovery and provider integration — and what it does not solve for the product.
PAYMENTS / ADDRESS
Dedicated Deposit Addresses for USDC
Architecture for wallet provisioning, address mapping, chain observation, finality, ledger credit and downstream treasury sweeps.
BOFU / COST
How Much Does Crypto Wallet Infrastructure Cost?
A scope-first cost model covering embedded-wallet integrations, programmatic wallet systems, treasury controls, provider costs and operational tooling.
Implementation paths
Choose the commercial entry point, then design the control model.
Wallet infrastructure often starts as a payment, deposit or embedded-account requirement. These paths connect the intent to the deeper architecture.
WALLETS / BOFU
Crypto wallet development
A focused page for embedded wallets, developer-controlled accounts, MPC integrations, deposit addresses and treasury workflows.
USDC / DEPOSITS
USDC payment integration
Use dedicated addresses or a provider rail when the wallet architecture exists to collect and reconcile stablecoin payments.
PAYMENTS / SERVICE
Crypto & Stablecoin Payments
Compare managed gateways and custom on-chain payment infrastructure before committing to a custody or wallet model.
FAQ
Wallet infrastructure questions we resolve during discovery.
The correct answer depends on control, asset ownership, operating model and jurisdiction — not only the blockchain network.
Usually no. Production systems typically integrate a wallet/key-management provider, MPC infrastructure or other specialized signing solution. Softech designs the product and operational architecture around that provider rather than recreating cryptographic key custody unnecessarily.
In an embedded user-controlled model, the wallet experience sits inside your product but the user authorizes transactions and retains the relevant control. In a developer-controlled model, your backend can initiate and execute transactions under your business policy. The difference changes custody, authorization, UX and operations.
Yes, depending on the selected provider, network and account model. The important part is deterministic mapping between product identity and wallet/address records, plus a scalable provisioning and reconciliation process.
MPC is one key-management approach, not a complete wallet architecture. We evaluate signing control, recovery, approval policy, provider operations, chain support and compliance requirements before recommending a specific MPC implementation.
No. Smart accounts can add programmable features such as batching, sponsored gas or delegated permissions, but the ownership, signer and recovery model still has to be designed explicitly.
Yes. We can integrate provider APIs/SDKs and build the product-owned orchestration, identity mapping, state machines, ledger, treasury workflows and operational tooling around them. Provider suitability is evaluated per use case.
We model accepted customer/business events in an internal ledger and treat treasury sweeps or provider transfers as downstream movements. A failed sweep should not retroactively invalidate a correctly accepted customer deposit.
Softech provides software and architecture engineering. We do not replace licensed custody/CASP services or legal and tax advice. Where regulated services are required, the architecture should integrate appropriate providers and be reviewed for the target jurisdiction.
Wallet architecture discovery
Before choosing a wallet SDK, define who controls value.
We can review your payment, embedded-wallet or treasury use case and produce a practical control model, provider boundary, wallet lifecycle and implementation roadmap.