Cryptocurrency Development: Wallets, Exchanges and Crypto Payments
How we approach wallets, exchange features and crypto payments: custody decisions first, security throughout, compliance designed in with your counsel, and no token hype.
You’re building a product that holds or moves digital assets. It might be a wallet, a trading feature inside a financial app, or a way for merchants to accept crypto payments. Done well, cryptocurrency development looks a lot like good FinTech engineering. It settles who holds the keys and protects them as if attackers are already looking. The ledger always reconciles, the compliance requirements your counsel defines are built in, and users see prices and fees they can trust.
It doesn’t look like launching a coin and hoping the market does the rest. This article covers the products we build, the decisions that matter most and how we approach security. It also points out where a simpler option would serve you better.
Cryptocurrency development: what we build and what we avoid
The products we work on fall into a few groups:
- Non-custodial wallets for iOS, Android and the web, where users hold their own keys.
- Custodial accounts inside FinTech apps, usually built on a regulated custody or brokerage partner.
- Trading and brokerage features, from portfolios and order entry to deposits, withdrawals, statements and price alerts.
- Merchant payments with locked-quote invoices, stablecoin checkout and settlement to fiat through a licensed provider.
- Portfolio, reporting and treasury tools that combine exchange accounts with on-chain data.
- Smart contracts and integrations where a product needs them, following the approach in our blockchain development article.
We’re deliberately cautious about new coins and tokens. Copying an existing blockchain’s code to create your own coin takes little effort. Making that network secure is another matter, because a small chain with few miners or validators is cheap to attack. Issuing a stablecoin is a regulated financial activity in major markets, and it requires reserves, audits and licensing long before it requires code. We don’t do token-launch campaigns, or projects built on promises of returns.
Custody models: the decision that shapes everything
Before anyone designs a screen, you need to decide who controls the private keys. That choice sets your security burden and your regulatory exposure, and it determines how users get their access back when something goes wrong.
| Model | Who controls the keys | Main trade-off |
|---|---|---|
| Self-custody | The user, backed up with a recovery phrase | Usually a lighter regulatory load for you, but lost keys mean lost funds and your support team cannot help |
| Custodial | Your company, on behalf of users | A familiar experience with account recovery, but heavy security, licensing and operational obligations |
| MPC or multisig | Several signers, or shares of a single key, split across parties or devices | No single point of compromise and flexible recovery, at the cost of more complex engineering |
| Custody partner | A regulated institutional custodian, integrated through APIs | The partner carries much of the security and licensing work, in exchange for fees and dependency |
Many products combine models, for example a custodial account for beginners with the option to withdraw to self-custody. If you hold funds yourself, keep most of them in cold storage and limit the hot wallet to what day-to-day withdrawals need. Moving funds between those tiers should be an automated process with limits and multiple approvals.
Security that assumes you are a target
Anything that holds crypto attracts attackers, from automated scripts to organized groups. Every project starts with a threat model, and we design controls for the attacks that actually happen:
- Server-side keys live in hardware security modules or equivalent managed services, never in configuration files. On phones, the Secure Enclave and Android Keystore don’t support secp256k1, the curve Bitcoin and Ethereum use, so wallet keys are encrypted with a hardware-protected key, not stored there directly.
- SMS codes are vulnerable to SIM swapping. To prevent account takeover we favor passkeys, authenticator apps and hardware keys, with step-up checks for sensitive actions.
- Withdrawals are guarded by allowlisted addresses (new ones have a waiting period), velocity limits, cooling-off periods after security changes and manual review of unusual patterns.
- Address poisoning and clipboard malware trick users into sending funds to lookalike addresses, so we show full addresses, support address books and warn about near matches.
- Insider risk is handled with separation of duties, multi-person approval for treasury movements and complete audit logs.
- Wallet software is a prime target for malicious dependencies, which is why packages are pinned, reviewed and monitored.
Money handling has its own rules. Amounts never pass through floating-point arithmetic. We store integers in each asset’s smallest unit, since assets use different numbers of decimal places, even on the same network. An independent penetration test is part of the plan before launch, along with a smart contract audit wherever contracts are involved.
Ledgers, reconciliation and market data
For any product that shows balances, your internal ledger is the source of truth, and it should be double-entry. Every movement debits one account and credits another, so value can’t appear or disappear without a trace. This is where our backend development discipline matters most:
- Deposits are credited only after the confirmation threshold you set for each network, and the system handles reorganizations that reverse recent blocks.
- Every operation is idempotent, so a retried request can never pay out twice.
- Reconciliation jobs regularly compare the ledger with on-chain balances and partner statements. Any difference raises an alert for a person to investigate.
Market data needs the same rigor. We aggregate prices from more than one source, discard stale or outlying values and show when a price was last updated. Order book feeds usually arrive as a snapshot followed by incremental updates with sequence numbers. Miss a single update and the book is wrong, so clients detect gaps and resynchronize. We also keep the indicative price on a chart separate from an executable quote, which should expire and should show fees, spread and expected slippage before the user confirms.
Compliance awareness, without pretending to be your lawyer
We’re engineers, not lawyers, and nothing in this article is legal advice. What we bring is experience building FinTech products and a habit of designing systems that can meet the requirements your counsel defines. Crypto products commonly touch on:
- Licensing or registration of crypto-asset service providers, which many jurisdictions now require. The EU’s MiCA regulation is one example.
- KYC and AML, meaning identity verification, sanctions screening, transaction monitoring and suspicious activity reporting.
- The travel rule, which requires originator and beneficiary information to accompany transfers between service providers.
- Data protection law such as the GDPR in Europe and KVKK in Turkey, including how long identity documents are kept.
- Consumer disclosures, marketing rules and tax reporting.
Your legal team decides the rules. Our part is a system that can enforce them, which in practice means integrating identity verification and blockchain analytics providers, screening deposit and withdrawal addresses and keeping audit logs that stand up to review. Limits and features are configurable per country, so entering a new market is a configuration change rather than a rewrite.
How an engagement works
Discovery comes first, and most of the important decisions get made there: business model, target jurisdictions, custody model, the threat model, and partners for custody, identity verification, liquidity and fiat on- and off-ramps. Our business analysts document requirements alongside your compliance team.
Design is mostly about trust. Onboarding, deposits, withdrawals and every error state have to explain what’s happening with someone’s money, especially while a transaction is pending. Development covers mobile, web and backend. QA runs on testnets and includes deliberate failure testing for stuck transactions, reorganizations, partner outages and gaps in price feeds. Our mobile app development team also prepares for app store review, which has specific rules for crypto apps. We launch with conservative limits and a staged rollout, then run the product with monitoring, alerting and runbooks. You receive the source code, architecture and threat-model documents, test and security reports, and operational runbooks.
Sometimes the right advice is to build less. If you only need to accept crypto occasionally, a payment provider’s hosted checkout is faster and safer than your own integration. If you want trading in your app, a licensed brokerage partner’s API is usually a wiser choice than running your own exchange, with the matching engine, custody and market surveillance that come with it.
Frequently asked questions
Can you create our own cryptocurrency or token?
Technically, yes, and the code is the easy part. The hard parts are security, legal classification and whether the token serves a real function in your product. We only take on token work with a clear use case and your counsel’s sign-off, and we don’t run launch campaigns.
Should we build a custodial or non-custodial product?
That depends on your users and your appetite for regulation. Non-custodial suits users who want control and keeps your obligations lighter. Custodial gives people a familiar, recoverable experience but brings licensing and serious security duties. Many teams start by integrating a regulated custody partner.
Do you give legal or regulatory advice?
No. We work with your legal and compliance advisers, turn their requirements into system behavior and help them understand how the product works technically.
Which blockchains should we support?
The ones your users and partners actually use. Every network brings its own nodes or providers, indexing, fee logic, confirmation rules and failure modes, so we add them one at a time, based on demand.
How do you keep user funds safe?
In layers: a clear custody model, keys in hardware-backed storage, strong authentication, withdrawal controls, a reconciled double-entry ledger, independent security testing and continuous monitoring. No single control is enough on its own.
With a wallet, a trading feature or crypto payments, the cheapest time to settle the architecture is before anyone writes code. Send us an outline of the product, your target markets and the partners you have in mind, and we’ll help you find a setup that’s secure and realistic.
