--- title: Web3, Crypto and Blockchain Development description: url: https://miracuves.com/industries/web3-crypto-blockchain date_modified: 2026-08-17 author: miracuves language: en_US --- # Digital asset platforms, built where a defect is a theft rather than an outage. Custody, contracts and settlement engineered for an environment with no chargeback, no reversal and no support queue that can undo a mistake. Twelve digital asset platforms already in production, eight dedicated engineering practices, and custom work for everything beyond them. [Talk to an engineer](https://miracuves.com/schedule-consultation/) [See what we've shipped](#shipped) Where this starts from **12**Platforms in production **8**Operator types served **2-8*wks***Custom build, scoped **6*days***Ready-made launch Assumed from week oneNo reversal, ever Source codeYours, in full DeploymentYour infrastructure Support, fixes, updates60 days, 6 and 12 months *Custody is the business* · everything else is an interface to it Custom build Starting from a shipped platform Custom build - 2 to 8 weeks, scoped Licence and custody Contracts Key management Audit Compliance Launch Ready-made platform - 6 working days Rebrand, deploy, live Six working days is the launch timeline for a ready-made platform as it ships - branded, deployed and live on infrastructure you own. Sector work beyond that, and the custom track above, is scoped and quoted in writing before anything starts. Both tracks are the same engineering team. Every figure on this page is defined on our [facts page](https://miracuves.com/facts/). ## What a digital asset build actually contains The sequence below is where digital asset platforms are won or lost. Every phase names what it requires and, where one exists, the shipped platform that removes it. This sector has a property that changes engineering practice rather than merely constraining it: there is no undo. A payments platform that sends money to the wrong account has a recall process and a bank on the other end. A withdrawal to the wrong address is gone, a contract with an error is exploited within hours of anyone noticing, and the customer's recourse is a support ticket you cannot resolve. Everything on this page follows from that. Three of the seven phases have no shortcut. What a shipped platform removes is the middle: contract architecture, key management and the trading or protocol engine. At a glance Phases7 With no shortcut3 Removed by a shipped platform3 Fixed regardless of trackLicence, audit, launch **01**Weeks 1-2 ### Regulatory position and the custody question Whether you hold customer assets is the first question and it decides everything after it. A platform where users retain their own keys is a software product with a support obligation. A platform holding assets is a custodian, which in most jurisdictions means licensing, capital requirements, segregation rules and an audit regime that resembles financial services rather than technology. Jurisdiction compounds it. Registration requirements differ sharply between markets, several restrict specific activities outright, and the answer changes what you can list, who you can serve and where your entity should sit. The output is a written position naming the custody model, the licences you hold or are pursuing, the markets you will serve and the assets you will support, because that last one carries its own regulatory weight. Custodial or notLicence positionMarket restrictionsAsset listing policy No shortcut here. Custody position is the same constraint on both tracks, and building before it is settled produces a platform you may not be permitted to operate. **02**Weeks 2-4 ### Chain selection and contract architecture Which chains you support is a product decision with heavy engineering consequences. Each brings its own finality assumptions, fee behaviour, node requirements and failure modes, and supporting four is considerably more than four times the work of supporting one. Where contracts are involved, upgradeability is the decision that deserves the most thought. An immutable contract cannot be fixed if it is wrong. An upgradeable one introduces an administrative key that is itself the largest attack surface on the platform, and users will reasonably ask who controls it. Reorganizations and finality are not theoretical. A deposit credited before finality can be reversed by the chain itself, and confirmation thresholds are set per asset with real money behind the judgement. Chain scopeUpgradeabilityFinality thresholdsFee handling **Already built**Multi-chain architecture with confirmation policy and contract patterns already proven.[Binance Clone](https://miracuves.com/binance-clone/) · [Coinbase Clone](https://miracuves.com/coinbase-clone/) · [Mexc Clone](https://miracuves.com/mexc-clone/) **03**Weeks 3-6 ### Key management, and the hot wallet as accepted loss Custody engineering is the discipline this sector actually runs on. Keys are split across signers, cold storage is genuinely offline, and the hot wallet holds only what you are prepared to lose in a total compromise, because that is the honest way to size it. Withdrawal is where the controls concentrate: allow-listed addresses, thresholds requiring additional approval, delays on first withdrawal to a new address, and velocity limits that catch a drained account before the balance follows. Every one of those costs user convenience and every one has prevented a real loss somewhere. Signing procedure is an operational design problem rather than a code one. Who can initiate, who approves, what happens when a signer is unavailable, and how the process survives a person leaving the company. Hot and cold splitMulti-signatureWithdrawal controlsSigner succession **Already built**Hot and cold separation with multi-signature approval and layered withdrawal controls.[Binance Clone](https://miracuves.com/binance-clone/) · [Paxful Clone](https://miracuves.com/paxful-clone/) **04**Weeks 4-6 ### The engine: matching, liquidity or protocol logic What sits at the centre depends on what you are building. A centralized exchange needs a matching engine with deterministic price-time priority and a ledger the engine cannot disagree with. A decentralized one needs pricing logic that behaves under adversarial conditions rather than only in normal markets. Ledger separation matters more here than almost anywhere. The engine matches, the ledger records, and the two reconcile continuously, because a platform where the trading system is also the accounting system cannot prove its own solvency. For marketplaces and launchpads the equivalent is escrow and settlement: who holds the asset during a trade, what releases it, and what happens when one side disappears mid-transaction. Price-time priorityLedger separationAdversarial pricingEscrow release **Already built**Matching, escrow and settlement engines with ledger separation across several models.[GMX Clone](https://miracuves.com/gmx-clone/) · [OpenSea Clone](https://miracuves.com/opensea-clone/) · [LocalBitcoins Clone](https://miracuves.com/localbitcoins-clone/) **05**Weeks 6-7 ### Audit, and what an audit does not cover External audit is expected in this sector and it is worth understanding precisely what it buys. An audit examines the code presented at a point in time. It does not cover what you deploy afterwards, your key management practice, your operational procedures or the economic design of the system, and most incidents involve at least one of those. We build to be auditable, which means the contract surface is kept small, the privileged functions are few and obvious, and the deployment that goes to production is verifiably the artefact that was reviewed. Our platforms arrive with a VAPT and compliance document so the external review starts from a documented baseline rather than a blank page. Bug bounties and monitoring belong here too, because the interesting attacks arrive after launch rather than before it. Small surfaceVerified deploymentBounty programmeRuntime monitoring No shortcut. An audit reviews code at a moment; your keys, your procedures and your economics remain yours to get right, and they are where most losses originate. **06**Weeks 7-8 ### Identity, screening and the travel rule Compliance in digital assets has converged toward financial services faster than many operators expected. Identity verification, sanctions screening, transaction monitoring and originator information accompanying transfers above a threshold are now standard expectations rather than differentiators. Chain analytics adds a dimension traditional finance lacks: an address can be screened against known illicit activity before a deposit is credited, which is a genuinely stronger control than anything available on a bank transfer. Using it well means deciding what happens on a match, and having that answer before the first one arrives. Where your platform is non-custodial, obligations differ, and getting that distinction wrong in either direction is expensive. Identity tiersSanctions screeningChain analyticsTransfer information **Already built**Tiered identity, sanctions screening and chain analytics integration.[Coinbase Clone](https://miracuves.com/coinbase-clone/) · [Remitano Clone](https://miracuves.com/remitano-clone/) **07**Weeks 7-8 ### Launch, incident readiness and day two Launch limits are a security control rather than a growth constraint. Deposit and withdrawal caps for the first period, a small asset list, and monitoring watched by people rather than by alerts alone, because the first weeks are when a platform is probed hardest. Incident response is designed before it is needed: who can pause what, how a suspicious withdrawal is held, how customers are told, and who speaks publicly. In this sector an incident is public within minutes whether or not you announce it. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. Launch capsPause authorityPublic commsDay two support No shortcut. Same on both tracks. The response plan is written before launch because writing one during an incident is how a recoverable problem becomes a reputational one. Want any of these phases costed against your custody model and asset list? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Where the assets actually sit Every custodial platform is this arrangement with different names on the boxes. The hot wallet is not a convenience, it is a quantity of money you have decided you can afford to lose, and sizing it honestly is the whole discipline. At a glance Tiers3 Hot wallet sized asAccepted total loss Cold storageGenuinely offline SigningSplit, never single **Custody tiers and the signing boundary**What sits where, and what it takes to move it HotWarmCold Online, automated Funds withdrawals without a human. Hold only what you can lose entirely. Approval required Multi-signature, humans involved. Replenishes hot on a schedule. Offline, ceremony Keys never touch a networked device. Moving it is a planned event. Controls on the way out Address allow-listing, with a delay before a newly added address can be used Value thresholds that escalate from automatic to approved to ceremony Velocity limits per account, which catch a compromised login before the balance follows Withdrawal pause, exercisable by named people who are reachable at three in the morning Every one of these costs convenience, and every one has prevented a real loss somewhere Protected by procedureExposed by design The honest test of a custody model is a simple question: if the hot wallet were emptied tonight, would the business survive tomorrow? If the answer is no, the hot wallet is too large regardless of how good the surrounding controls are. ### Why upgradeable contracts are a trade rather than an improvement Immutability is the property that makes a contract trustworthy: nobody can change the rules after you have committed funds to them. It is also the property that makes a bug permanent, and every team that has shipped a serious contract has wanted an upgrade path at some point. Adding one introduces an administrative key with the power to change what the contract does, which becomes the most valuable target on the platform and a fair question from every user. The mitigations are real - timelocks so changes are visible before they take effect, multi-signature control so no individual can act alone, and eventual renunciation once the design has settled - but the trade does not disappear. We build either, and we insist the choice is made deliberately with the consequences stated rather than defaulted into by a framework template. At a glance ImmutableTrustworthy, and permanent UpgradeableFixable, and a key exists MitigationsTimelock, multi-signature, renunciation DecisionDeliberate, never default Want your custody model or contract architecture reviewed before it holds value? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Eight operators, eight different builds "Crypto platform" is not one buyer. The custody position, the regulatory exposure and the engineering centre of gravity change completely between them. At a glance Operator types8 Can start from a shipped platform7 Need a custom build1 ### Centralized exchanges You hold the assets, which makes custody and licensing the business and the matching engine merely the visible part. Proof of reserves is increasingly expected rather than optional. 4 shipped platforms ### Decentralized exchanges Users keep their keys and the contract is the venue. Pricing must behave under adversarial conditions, and the governance arrangement is part of the product rather than a formality. 2 shipped platforms ### Peer-to-peer marketplaces Escrow between strangers trading across payment methods you do not control. Dispute resolution and reputation carry the risk that a matching engine carries elsewhere. 3 shipped platforms ### NFT marketplaces Ownership and royalty enforcement, metadata that must remain resolvable for years, and a moderation problem around what is listed that arrives immediately. 2 shipped platforms ### Launchpads and token issuance Sale mechanics, vesting and distribution at moments of extreme demand, where the contract is examined by thousands of people the minute it is published. 2 shipped platforms ### Wallets Non-custodial by definition, which moves the hard problems to recovery, signing experience and making a fatal mistake difficult for an ordinary person to make. 1 shipped platform ### DeFi protocols Lending, derivatives or yield mechanics where the economic design is as much an attack surface as the code, and both need adversarial review before launch. 1 shipped platform ### Institutional custody Holding assets for other businesses, with segregation, attestation and insurance arrangements that resemble a regulated financial institution more than a technology product. Custom build Seven of the eight can start from something already running. This is the deepest shipped catalogue we have in any regulated sector, and it exists because we have been building in this space since before it was a category. Not sure which of these you are, or you sit across two of them? [Book a scoping call](https://miracuves.com/schedule-consultation/) ## How the work actually runs Six stages, the same on both tracks. What changes between a custom build and a platform adaptation is how long stage three takes, not whether the other five happen. At a glance Stages6 Identical on both tracks5 Varies by trackStage 3 only 01Stage ### Scoping against custody and jurisdiction We start from whether you hold customer assets, which licences you hold or are pursuing, and which markets you intend to serve, because those three decide the architecture before any preference does. Custodial and non-custodial platforms share a front end and almost nothing behind it. **Ends with**Written scope: custody model, licence position, market restrictions and the asset listing policy. 02Stage ### Architecture around irreversibility Key management, confirmation thresholds and withdrawal controls are designed before features, because all three are cross-cutting and none can be retrofitted once assets are held. The ledger is separated from the engine at this point so the platform can prove its own position rather than assert it. **Ends with**A custody design with signing procedure, confirmation policy per asset, and a ledger independent of the trading engine. 03Stage ### Build against adversarial conditions Digital asset platforms are attacked rather than merely used, so test environments carry hostile shapes from the start: chain reorganizations after a credit, deposits of unexpected token behaviour, price manipulation against pricing logic, transaction replay, and a compromised account attempting rapid withdrawal. Testing the happy path proves nothing here. Length varies by track **Ends with**Test coverage for reorganizations, hostile token behaviour, price manipulation, replay and account takeover. 04Stage ### External audit and remediation Independent review of contracts and platform, remediation, then re-review of what changed. Our platforms arrive with a VAPT and compliance document mapping the OWASP Top 10, so an external auditor starts from a documented baseline and spends their time on your logic rather than on orientation. **Ends with**An external audit with findings remediated, and a deployment verifiably identical to the reviewed artefact. 05Stage ### Compliance integration and dry run Identity providers, sanctions screening and chain analytics connected and exercised, including what happens on a positive match. Deciding that during a real hit, with a customer's funds held and a clock running, is the wrong moment to design a process. **Ends with**Live screening and analytics integrations, with the match-handling procedure exercised end to end. 06Stage ### Capped launch and day two Deposit and withdrawal caps, a short asset list and human eyes on monitoring through the first weeks, because that is when a new platform is probed hardest. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. **Ends with**Sixty days dedicated support, six months priority bug resolution, twelve months of updates. Want this sequence mapped against your custody model and jurisdictions? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Twelve digital asset platforms already in production Every one ships with full source-code ownership, deployed on your infrastructure under your brand. Adapt one, or use it as the reference architecture for a custom build. They fall into four groups, and which group you start from matters more than which name you recognise. **Centralized exchanges** carry custody, matching and the compliance stack, which is the heaviest regulatory position here. **Peer-to-peer marketplaces** carry escrow and dispute resolution between strangers using payment methods you do not control. **NFT and marketplace** platforms carry ownership, royalties and listing moderation. **Launchpads and protocols** carry sale mechanics, vesting and pricing logic that is examined by thousands of people the moment it is published. At a glance Platforms already shipped12 Dedicated service practices8 DeploymentYour infrastructure, your brand [Binance](https://miracuves.com/binance-clone/) [Coinbase](https://miracuves.com/coinbase-clone/) [Mexc](https://miracuves.com/mexc-clone/) [Paxful](https://miracuves.com/paxful-clone/) [LocalBitcoins](https://miracuves.com/localbitcoins-clone/) [Remitano](https://miracuves.com/remitano-clone/) [OpenSea](https://miracuves.com/opensea-clone/) [Rarible](https://miracuves.com/rarible-clone/) [BSCPad](https://miracuves.com/bscpad-clone/) [PinkSale](https://miracuves.com/pinksale-clone/) [ICO Launchpad](https://miracuves.com/ico-launchpad-clone/) [GMX](https://miracuves.com/gmx-clone/) ## What this sector requires ### An honest hot wallet Sized as an amount you could lose entirely tonight and still open tomorrow. Every custody design is really an answer to that question, and the surrounding controls do not change it. ### Split signing Multi-signature approval with a documented procedure covering initiation, approval, unavailability and departure. A single key held by a single person is the failure mode that recurs most often in this sector. ### Confirmation policy per asset Deposits credited only after finality appropriate to that chain, because a reorganization after a credit is the chain reversing a transaction you already honoured. ### A ledger the engine cannot edit Separation between matching and accounting, so the platform can demonstrate its position rather than assert it. Proof of reserves is increasingly expected and impossible without this. ### Deliberate upgradeability Immutable or upgradeable chosen with the trade stated, and if upgradeable, a timelock and multi-signature control over the administrative key that users can inspect. ### A written incident plan Who pauses what, how customers are told, who speaks publicly, all decided before launch. An incident in this sector is public within minutes whether or not you announce it. Want to open any of these platforms and look inside before deciding? [See the live demos](https://miracuves.com/solutions/) ## Proof of reserves is an architecture, not a report Users increasingly ask custodial platforms to demonstrate the assets are there. Whether you can answer quickly depends on decisions made long before anybody asks. At a glance Two halvesAssets and liabilities The easy halfWhat you hold on chain The hard halfWhat you owe users Enabled byLedger separation, from day one **Demonstrating solvency**What has to be true before the question is asked Assets, the easy halfLiabilities, the hard half What you hold on chain Addresses published, balances readable by anybody. Signing proves control. What you owe every user Only provable if the ledger is authoritative and independent of the trading engine. What makes the second half possible A ledger the matching engine cannot write to directly, reconciled continuously Every balance derived from entries rather than stored and adjusted A commitment structure that lets a user verify their own balance was included All three decided at architecture, none of them addable afterwards Platforms that cannot answer are usually not dishonest - they simply never built for the question Readable by anyoneDepends on your architecture Publishing addresses is straightforward and proves only half of it. Without a ledger that can produce a verifiable total of user balances, the exercise demonstrates that you hold assets while saying nothing about whether they cover what you owe. Want your ledger reviewed for whether it could produce a proof of reserves? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Built custom when nothing off the shelf fits The same team, working from zero. Eight dedicated service practices sit behind this sector, more than any other on this site. At a glance Custom capabilities6 Dedicated service practices8 ### Smart contract engineering Contracts written to be audited: small surface, few privileged functions, and a deployment verifiably identical to what was reviewed. [Smart contract development](https://miracuves.com/service/smart-contract-development/) ### Custody and key management Hot, warm and cold separation with multi-signature procedure, signer succession and withdrawal controls layered by value and destination. [Crypto wallet development](https://miracuves.com/service/crypto-wallet-development/) ### Exchange engineering Matching with deterministic price-time priority, a ledger the engine cannot edit, and the reconciliation that lets you prove your position. [Crypto exchange development](https://miracuves.com/service/crypto-exchange-development/) ### DeFi protocol design Lending, derivatives and yield mechanics reviewed as economic systems as well as code, because the design is an attack surface in its own right. [DeFi development](https://miracuves.com/service/defi-development/) ### NFT and marketplace systems Ownership, royalty enforcement, metadata that stays resolvable for years, and the listing moderation that arrives with the first users. [NFT development](https://miracuves.com/service/nft-development/) ### Compliance integration Tiered identity, sanctions screening, chain analytics and transfer information, with the match-handling procedure designed before the first hit. [Blockchain development](https://miracuves.com/service/blockchain-development/) Need something this list does not cover? [Ask about custom work](https://miracuves.com/schedule-consultation/) ## What we built, and what it delivered Three deployments in this sector, described by what was actually built rather than by a metric we cannot show you the working for. At a glance Builds detailed here3 Exchange ### Centralized exchange with ledger separation Matching on deterministic price-time priority with an independent ledger, hot and cold custody split, and withdrawal controls layered by value and destination. Peer to peer ### Escrow marketplace across payment methods Escrow held through a trade between strangers, dispute resolution on captured evidence, and reputation weighted by completed volume rather than by count. Issuance ### Launchpad with vesting and distribution Sale mechanics under extreme concurrent demand, vesting enforced in contract, and a deployment published as the artefact that was audited. We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's. Want to speak to a reference operating a comparable platform? [Request a reference](https://miracuves.com/schedule-consultation/) ## Written on this sector Longer pieces on the problems above, written by the engineers who build these platforms. At a glance Articles4 [Custody ### Sizing a hot wallet as an amount you can lose](https://miracuves.com/blog/) [Contracts ### Upgradeable or immutable, and who holds the key](https://miracuves.com/blog/) [Solvency ### Why proof of reserves starts at the ledger](https://miracuves.com/blog/) [Audit ### What an audit covers, and what it never did](https://miracuves.com/blog/) If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your build. Want these as a briefing pack for your board or engineering team? [Request the pack](https://miracuves.com/schedule-consultation/) Our audit came back clean. Six weeks later we lost funds through a key procedure nobody had written down, which the audit was never going to look at. The failure pattern this page is built around That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented. [Read all forty](https://miracuves.com/client-testimonials/) ## Questions digital asset buyers actually ask The ones that come up in the first call, answered as we would answer them there. At a glance Questions answered12 Can we really launch in six working days? Yes, for a shipped platform as it comes, with a short asset list. It does not cover your licensing, which runs on a regulator’s timeline, or an external audit, which runs on the auditor’s. Do we own the source code? Yes, in full, deployed on your infrastructure. In this sector that matters more than most, because a custody platform you cannot inspect is a custody platform you cannot trust. How large should our hot wallet be? Small enough that losing it entirely tonight would not close the business tomorrow. That is the real test, and every other control is a way of making the event less likely rather than less severe. Should our contracts be upgradeable? It is a trade rather than an improvement. Upgradeable means a key exists that can change the rules, which is the most valuable target you will have. We build either, with timelocks and multi-signature control where you choose upgradeability. Can you support multiple chains? Yes, and it is worth pricing honestly: each chain brings its own finality, fee behaviour, node requirements and failure modes, so four chains is considerably more than four times the work of one. Do you handle KYC, sanctions and the travel rule? Yes, with tiered identity, screening and chain analytics integrated, plus the procedure for what happens on a match. Deciding that during a live hit with funds held is the wrong moment. Can we prove reserves? Only if the ledger is built for it: independent of the engine, balances derived from entries, and a commitment structure a user can verify. Those are architectural decisions rather than a reporting feature. What about an external audit? Expected, and we build to be auditable so the auditor spends time on your logic rather than on orientation. An audit covers code at a point in time; keys, procedures and economics remain yours and are where most losses originate. How do you handle chain reorganizations? With a confirmation policy per asset, so a deposit is credited only after finality appropriate to that chain. Crediting early is how a platform honours a transaction the chain later reverses. Can you build non-custodial? Yes, and the obligations differ significantly, which is why the custody question is settled in week one. Getting that distinction wrong in either direction is expensive. What does support look like after launch? Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates. New platforms are probed hardest in the first weeks, so that window is where it matters most. What if we are not ready to build yet? We will tell you where the risk sits. If the licence position is unsettled, we will still scope and build the platform around the position you expect to hold, and adjust as it resolves. Question not answered here? [Ask us directly](https://miracuves.com/schedule-consultation/) ## Tell us what you are building. Bring the custody model and the markets. We will tell you honestly which track is right, and we will build whichever it turns out to be. [Book a technical call](https://miracuves.com/schedule-consultation/) [Browse all solutions](https://miracuves.com/solutions/) A first call takes about thirty minutes and covers four things **01** ### Custody position Whether you hold customer assets, which decides everything after it. **02** ### Markets and licences Where you will operate, and under what permission. **03** ### Chains and assets What you will support, and what that costs to run. **04** ### Existing systems The wallet, compliance and banking stack a platform must fit into. Those four answers are usually enough for us to tell you which track fits, roughly what it costs, and where the custody risk actually concentrates. Whatever the model - exchange, marketplace, wallet, protocol or something none of those describe - we will build it.