Building a crypto app begins with one decision that shapes everything else: whether you hold customer keys or they do. That choice determines your regulatory exposure, your security architecture, your support burden, and what happens when something goes wrong. This guide covers custody models, key management architecture, exchange and liquidity integration, and transaction handling on chain. It stays on architecture throughout, because the engineering decisions here are unusually unforgiving of being revisited later.
Custody Models
Custody is the first and most consequential decision. Non-custodial means users hold their own keys and you cannot recover them, which reduces your regulatory position and your liability while producing permanent losses when users make mistakes. Custodial means you hold keys, which is far better for usability and places you squarely within financial regulation in most jurisdictions.
Non-Custodial Architecture
Keys generated and held on the user’s device, with your systems never able to move funds. Lower regulatory exposure, and unrecoverable loss when a user loses their key material.
Custodial Architecture
You hold keys and control movement. Better usability with account recovery, and it brings licensing, safeguarding, and audit obligations that dominate the project.
Hybrid and Shared Control
Multi-signature and threshold schemes splitting control between user and provider. Enables recovery without full custody, at meaningful implementation complexity.
Wallet-as-a-Service Providers
Third parties handling key infrastructure under their own controls. Our custom software development scoping usually evaluates these before any in-house key handling.
Confirming the Regulatory Position First
Custody classification determines licensing in most jurisdictions. Establish this with legal counsel before architecture, because it constrains every subsequent decision.
Key Management Architecture
Key management is where crypto applications succeed or fail catastrophically, since a compromised key is an irreversible loss rather than a recoverable incident. The engineering standard here is higher than in ordinary application security, and the failure mode has no remediation path once funds have moved on chain.
Key Generation and Entropy
Keys generated with proper cryptographic randomness on the device or in a hardware module. Weak generation has produced real, exploited losses.
Secure Storage per Platform
Platform secure enclaves and keystores rather than application storage. Never in application memory longer than necessary, never written to logs or backups.
Hardware Security for Custodial Systems
Custodial key material belongs in hardware security modules with quorum approval for movement. Software-held custodial keys are not a defensible architecture.
Hot and Cold Separation
Operational balances in hot wallets with strict limits, the majority in cold storage requiring manual multi-party authorisation to move.
Recovery Without Undermining Security
Seed phrase backup, social recovery, or shared control schemes. Every recovery mechanism is also an attack surface and must be designed as one.
Exchange and Liquidity Integration
If your app lets users buy, sell, or swap, you need liquidity from somewhere, and that means integrating exchanges or aggregators. These integrations have unusual characteristics compared with ordinary payment APIs, since prices move continuously and settlement is not instantaneous.
Exchange API Integration
Order placement, status polling, and balance reconciliation against exchange accounts. Our API integration services work handles the reconciliation this demands.
Price Feeds and Quote Validity
Quotes expire in seconds. Show a time-limited quote and re-validate before execution rather than treating a fetched price as durable.
Slippage and Partial Fills
Orders may execute at a different price or only partially. Both need explicit handling and clear communication rather than being treated as errors.
On and Off Ramp Providers
Fiat conversion through licensed providers, each with their own verification requirements and regional coverage. Confirm coverage before assuming availability.
Reconciliation as a First-Class System
Balances across chains, exchanges, and your own ledger must reconcile continuously. Discrepancies are financial rather than technical problems.
On-Chain Transaction Handling
Blockchain transactions behave unlike API calls in ways that break assumptions carried over from conventional payment integration. They are asynchronous, they can be pending indefinitely, fees fluctuate, and they cannot be recalled once broadcast. Handling this properly is most of the backend work.
Fee Estimation and Adjustment
Network fees vary continuously. Under-estimating leaves transactions pending indefinitely, so support fee bumping rather than treating a stuck transaction as final.
Confirmation Depth and Finality
Decide how many confirmations constitute settlement for your risk tolerance, and reflect pending state honestly in the interface rather than showing success early.
Nonce and Ordering Management
Transactions from one address must be sequenced correctly. Concurrent submission without nonce coordination produces stuck or dropped transactions.
Address Validation and Verification
Wrong addresses lose funds permanently with no recourse. Validate format, verify checksums, and require confirmation on new destinations.
Chain Reorganisation Handling
Recent blocks can be reorganised, reversing apparently confirmed transactions. Our cloud consulting work covers the node infrastructure that must detect this.
Sequencing and Technical Pitfalls
Crypto projects fail on security and regulatory sequencing far more than on feature delivery. Establishing the custody position first, then building the key architecture properly, then adding functionality, is the order that works. The pitfalls below have all produced real, publicly documented losses.
Suggested Build Order
Regulatory and custody position, then key architecture, then read-only balance and transaction display, then transfers, then exchange integration, then fiat ramps.
Pitfall: Deciding Custody Late
Retrofitting custody changes rewrites the security architecture and often the regulatory position. This decision cannot be deferred past the design stage.
Pitfall: Custodial Keys in Software
Holding customer funds with software-managed keys is indefensible under any serious security review and has produced repeated large losses across the industry.
Pitfall: Treating Transactions as Synchronous
Assuming broadcast means settled produces incorrect balances and support incidents. Model pending state explicitly throughout.
Pitfall: No Reconciliation System
Without continuous reconciliation across chains, exchanges, and your ledger, discrepancies accumulate silently until they become material.
Pitfall: Building Before Legal Clarity
Regulatory position determines architecture. Building first and seeking clarity later frequently means rebuilding or being unable to launch in target markets.
FAQs
What is the difference between custodial and non-custodial?
Non-custodial means users hold their own keys and you cannot move their funds or recover access. Custodial means you hold keys and control movement, which improves usability and account recovery while bringing licensing and safeguarding obligations in most jurisdictions.
How should private keys be stored?
On user devices, in platform secure enclaves and keystores rather than application storage. For custodial systems, in hardware security modules with quorum approval for movement, split between limited hot wallets and cold storage requiring multi-party authorisation.
Why is key management the critical part of a crypto app?
Because a compromised key is an irreversible loss rather than a recoverable incident. Once funds move on chain there is no reversal, chargeback, or remediation path, which sets a higher engineering standard than ordinary application security.
How do crypto apps handle price quotes?
With short validity windows, since prices move continuously. Show a time-limited quote, re-validate before execution, and handle slippage and partial fills explicitly rather than treating a fetched price as durable or an altered fill as an error.
What makes blockchain transactions different from payment APIs?
They are asynchronous, can remain pending indefinitely if fees are underestimated, carry variable network costs, cannot be recalled once broadcast, and recent confirmations can be reversed by chain reorganisation. Each of those breaks assumptions carried from payment integration.
What should be built first in a crypto app?
The regulatory and custody position, before any code. It determines the key architecture, which determines everything else. After that, read-only balance and transaction display, then transfers, then exchange and fiat integration.
