A wallet looks like a balance screen and a send button. The engineering underneath is almost entirely invisible, which is why wallet projects are so consistently underestimated.
The custody decision shapes everything
Make it first, because everything downstream inherits from it.
Custodial means you hold the keys. Users get password recovery, fast transactions and someone to call. You take on the entire security burden and the operational weight that follows.
Non-custodial means users hold their keys. No recovery, no support for lost funds, complete sovereignty. Correct for DeFi-native audiences, and brutal for everyone else.
MPC splits the difference credibly. The user holds a share, the provider holds a share, neither can act alone. Users get recovery without the provider being able to move funds unilaterally. For consumer products this is increasingly the right answer.
Key management
The parts that matter:
- Generation with proper entropy, on-device where possible.
- Storage in the platform secure enclave, never in application memory longer than needed.
- Signing that never exposes the key to application code.
- Backup, which is where the product decisions live.
Recovery is the hardest product problem
Seed phrases are a security solution that creates a usability catastrophe. Users write them on paper, photograph them, store them in cloud notes, and lose them.
The alternatives:
Social recovery. A set of trusted contacts or devices can collectively restore access. No single guardian can act alone. Works well and requires users to nominate guardians up front, which many will not do.
MPC with provider share. The provider holds one share and can help restore. Convenient, and it means the provider is a party to recovery, which has to be disclosed plainly.
Hardware backup. A physical device holds the backup. Secure and the least convenient.
Whichever you choose, recovery is the moment users are most frightened and most likely to talk publicly about the experience. Design it as a first-class flow, not an edge case.
Multi-chain is not a feature toggle
Each chain brings its own address format, transaction structure, fee model, finality behaviour and failure modes.
The indexing layer is where this bites hardest. Showing a balance means tracking on-chain state across every chain and token the user holds, reconciling pending transactions, and handling reorgs. It is far more work than the signing layer and it never appears on a feature list.
Plan chain support deliberately. Three chains done properly beats twelve done approximately, and users notice the difference immediately when a balance is wrong.
Transaction simulation
Before a user approves anything, show them what it will actually do.
Simulation runs the transaction against current state and reports the outcome — which tokens move, which approvals are granted, what the balance looks like afterwards.
This is the single highest-value safety feature in a modern wallet. It catches unlimited-approval attacks and drain contracts before the signature, rather than explaining them afterwards.
Alongside it: known-scam address and contract detection, warnings on unusual approval patterns, and clear plain-language explanations of what a contract interaction does.
The surfaces nobody scopes
- The support console, where your team looks up an account, traces a transaction and understands a failure. They live in it daily.
- Monitoring and anomaly alerting across chains.
- Fee estimation that is right often enough to be trusted.
- Pending state handling, which is most of the perceived quality of a wallet.
Before it holds real value
Coordinate independent third-party review of the signing path and key handling. Run a penetration test against the clients. Rehearse what happens when a chain node goes down mid-transaction, because it will.
Your counsel sets what the product needs to satisfy where it operates, and that shapes key management, fund segregation and onboarding. Get their answer before the architecture, not after it.
Common questions
What does crypto wallet development involve?
Key generation and storage, transaction construction and signing across every chain you support, balance and history indexing, recovery flows, transaction simulation so users see what they are approving, phishing and scam detection, plus the client applications and the admin surfaces your support team uses. The signing interface is the small visible part; indexing and recovery are where the effort concentrates.
Should a wallet be custodial or non-custodial?
It depends on who your users are and what they came for. Custodial suits consumer products where recovery and support matter more than sovereignty, and where the authorisation flow needs to be fast. Non-custodial suits DeFi-native audiences who expect to hold their own keys. MPC-based designs sit between the two, giving users real control without a seed phrase they will eventually lose.
How do you handle wallet recovery without seed phrases?
Through social recovery, where a set of trusted contacts or devices can collectively restore access, or MPC designs where a share is held by the provider and another by the user device. Both remove the single point of catastrophic failure that a written seed phrase represents. Recovery design is the decision users judge you on hardest, because it is the moment they are most frightened.
How long does wallet development take?
Timeline is driven by chain count, custody model and how much of the recovery and support surface you need at launch. Each additional chain is its own integration, its own indexing and its own failure modes. What compresses a schedule most is deciding the custody and recovery model early, because both reach into every layer and are extremely expensive to change once real balances exist.
Does Corum8 build crypto wallets?
Yes. We build custodial, non-custodial and MPC wallets, with key management, recovery flows, transaction simulation, phishing detection, multi-chain indexing, mobile and web clients, and the operations console. We have built wallet infrastructure since 2016 with 95+ specialists.
