--- title: EasyCryptoLand case study description: MXCRYPTO Case study · 2024 A crypto exchange delivered in 6 working days. EasyCryptoLand needed a crypt url: https://miracuves.com/portfolio/easycryptoland date_modified: 2026-08-19 author: miracuves language: en_US --- MXCRYPTO Case study* · 2024* # A crypto exchange delivered in 6 working days. EasyCryptoLand needed a crypto exchange. The Binance Clone base already carried the mechanics, so the engagement went where their product was actually different. We built the product; they launched the brand. - **Binance Clone** · MXCrypto - **6 working days** our build time on the base - **Source code transferred** to EasyCryptoLand’s own account [Read the case study](#summary) [Start a project](https://miracuves.com/schedule-consultation/) *E***EasyCryptoLand***Binance Clone · 2024* *E***EasyCryptoLand** SolutionBinance Clone ProductMXCrypto Delivered2024 StackJS Build time6 working days Blocks reused20 of 25 Source codeTransferred **4**applications shipped **20**blocks reused unchanged **5**built for this client **9**integrations, each isolated **100%**source code transferred [Summary](#summary)[Scope](#scope)[Brief](#brief)[Discovery](#discovery)[Challenges](#challenges)[Strategy](#strategy)[Market](#market)[What we built](#built)[Architecture](#architecture)[Reused](#reused)[Decisions](#decisions)[Process](#process)[Product](#surfaces)[Security](#security)[Integrations](#integrations)[Stack](#stack)[Timeline](#timeline)[Scale](#scale)[Results](#results)[Handover](#handover)[FAQ](#faq)[Related](#related) Spot*Listed markets*Futures & forex*Your token*P2P with escrow*KYC & AML policy*Binary & practice*Fee schedule*API gateway*Brand & theming*Spot*Listed markets*Futures & forex*Your token*P2P with escrow*KYC & AML policy*Binary & practice*Fee schedule*API gateway*Brand & theming* ## What already existed, and what did not. The distinction that decides a project like this: the mechanics were proven before the engagement started, so the time went into the part that was theirs. We build the product; the client launches the brand. That is the arrangement, and it only works if the handover is real: EasyCryptoLand owns the source code, had a launch date in writing before work started, and can check every figure on this page against a public ledger. Matching, custody and the trading UI were already there. We brought our pairs, our onboarding and our regional compliance requirements. Live in weeks with no settlement incidents since. EasyCryptoLand Team, Founding team · EasyCryptoLand Reuse on this build Blocks reused20 of 25 Built for EasyCryptoLand5 Solution familyBinance Clone Other builds on it5 ## The line between reused and built. The work sat where it always sits on this base: listed markets, your token, kyc & aml policy. Everything else on the list below arrived already built and proven on other engagements running the same base. **4**Applications and consoles shipped, each with its own permissions and release path*Delivered* **20**Platform modules reused unchanged from the Binance Clone base*Delivered* **5**Decisions built for EasyCryptoLand: listed markets, your token, kyc & aml policy*Delivered* **3**Environments: development, staging and production*Delivered* **100%**Source code transferred to EasyCryptoLand’s own account*Contractual* ## What EasyCryptoLand actually needed. A crypto exchange is not one feature. It is 25 distinct pieces that all have to work together before a single customer can be served, and most of them already existed and had been proven elsewhere. That distinction decides the shape of a project like this. A business does not need a dispatch engine or a settlement ledger to be invented again; it needs one that already works, then it needs the handful of decisions that make the product theirs rather than anyone else’s. The four below are the load-bearing pieces EasyCryptoLand would otherwise have spent months building before proving anything to a customer. Every platform of this kind has the same shape underneath: a set of load-bearing parts that must be correct before a single customer can be served, and a much smaller set of decisions that make it one business rather than another. Building the first set from zero would have consumed the window before the second was even discussed. That is the decision this engagement turned on, and it was taken before any code was written. **Spot**order book, pairs, charts **Futures & forex**leverage, margin, **P2P with escrow**peer trades, dispute hold **Binary & practice**paper trading, options ## What we settled before building. Which of the 25 pieces were already solved, and which were genuinely EasyCryptoLand’s to decide. Getting that line in the right place before any code is written is what keeps a Binance Clone engagement short, and it is the conversation we would rather have honestly than optimistically. Where a scope genuinely does not fit a proven base, we say so during scoping and quote it as a custom build instead, even when that costs us the larger and more comfortable project. *01* #### Read the requirement back to first principles What must exist at launch, separated from what a business can add once it has customers. Those are different lists and conflating them is what makes projects run long. *02* #### Base versus build, capability by capability Each of the 25 capabilities assessed against the existing base as covered, partial or absent. Partial is treated as absent, because a half-fitting module costs more than a new one. *03* #### Mark what only EasyCryptoLand could decide 5 decisions were commercial or jurisdictional rather than technical. Those were theirs, and the engagement is where they got implemented. *04* #### Agree the line before writing anything 20 pieces reused unchanged, 5 built. Fixing that line up front is what turns a platform of this size into a six-working-day build. ## The parts that are genuinely hard. Not marketing difficulty, actual difficulty. These are the problems any serious Binance Clone has to solve properly, and the reason building one from a blank page is a multi-quarter commitment rather than a sprint. Each was solved once, on the base, and has been under load on other builds since. EasyCryptoLand inherited the solutions rather than the problems. 01 ### Matching under load Price-time priority has to hold when the book is moving fastest, which is exactly when the infrastructure is under most stress and mistakes are most expensive. **Already solved in the base:** Spot 02 ### Custody is the whole risk Hot, cold and custodial balances must reconcile continuously against on-chain reality. A ledger that drifts from the chain is an incident, not a bug. **Already solved in the base:** Futures & forex 03 ### Compliance is not a feature KYC, AML screening and jurisdictional limits decide whether the exchange may legally operate, and they touch every flow rather than sitting beside them. **Already solved in the base:** P2P with escrow ## What we did not have to build for EasyCryptoLand. Every platform is made of the same mechanics underneath. This is the account of which of them EasyCryptoLand paid attention to, and which were already solved. Built from nothing, EasyCryptoLand would have meant paying for the mechanics again: the accounts, the sessions, the payments, the admin, the permissions. That work is real, it is slow, and none of it is what makes this product different from the next one. Starting from the Binance Clone base moved that cost out of the project entirely, and the platform itself was deployed in 6 working days. What that bought is attention. The engagement went into the 5 parts that were actually different, instead of being spread thin across 25 of them. **Shipped ready-made***20 of 25* *01***Spot**order book, pairs, charts *02***Futures & forex**leverage, margin, *03***P2P with escrow**peer trades, dispute hold *04***Binary & practice**paper trading, options *05***API gateway**auth, rate limits, *06***stream**order book, tickers, *07***Event bus**async fan-out, retries *08***Settlement ledger**append-only double-entry *09***Matching engine**price-time priority, *10***book**spot, margin, futures *11***Risk & liquidation**exposure caps, margin *12***control**hot, cold, withdrawal *13***Chain integration**deposits, confirmations, *14***disputes**holds, release, appeal *15***screening**tiers, watchlists, case *16***Fees & rewards**maker, taker, referrals *17***trading**strategy execution, API *18***store**ledger, orders, *19***realtime**order book, tickers, *20***Object storage**identity documents, **Made for EasyCryptoLand***5 of 25* *01***Listed markets**your pairs and tokens *02***Your token**issuance and utility *03***KYC & AML policy**your regulator's rules *04***Fee schedule**maker, taker, withdrawal *05***Brand & theming**web and app Build all 25 from nothing, mechanics included 20 already solved, so the effort went to the 5 that were not The account Shipped ready-made20 Made for this client5 Parts in total25 Build window6 working days The ready-made side is not a shortcut taken on quality. It is work that was already finished, and finished work does not get charged for twice. ## What this market demanded. An exchange operates under whichever regime it is licensed in, and that decides listed markets, KYC depth and how custody must be held. None of it is cosmetic. None of that is optional, and none of it is something a platform can guess on a client’s behalf. It is precisely why the 5 decisions listed further down sat with EasyCryptoLand rather than with us: they are commercial and jurisdictional questions, and the base exists so that answering them is the whole job rather than the last ten per cent of it. ## Everything that shipped with it. The full working set EasyCryptoLand took delivery of. Each piece was already built and proven on other engagements before this one started, which is the only honest reason a platform of this size stands up in six working days rather than months. None of it is a demo or a scaffold. These are the same components running under other businesses in other markets, which means the failure modes are already known and already handled rather than waiting to be discovered by EasyCryptoLand’s first real customers. ### Reused from the Binance Clone base **Spot**order book, pairs, charts **Futures & forex**leverage, margin, **P2P with escrow**peer trades, dispute hold **Binary & practice**paper trading, options **API gateway**auth, rate limits, **stream**order book, tickers, **Event bus**async fan-out, retries **Settlement ledger**append-only double-entry **Matching engine**price-time priority, **book**spot, margin, futures **Risk & liquidation**exposure caps, margin **control**hot, cold, withdrawal **Chain integration**deposits, confirmations, **disputes**holds, release, appeal **screening**tiers, watchlists, case **Fees & rewards**maker, taker, referrals **trading**strategy execution, API **store**ledger, orders, **realtime**order book, tickers, **Object storage**identity documents, ### Built for EasyCryptoLand **Listed markets**your pairs and tokens **Your token**issuance and utility **KYC & AML policy**your regulator's rules **Fee schedule**maker, taker, withdrawal **Brand & theming**web and app ## The base this was built on. The same architecture carries every Binance Clone on this page. The filled blocks are the parts built for EasyCryptoLand. **Binance Clone architecture** MXCrypto / filled = built for this client Binance Clone: the architecture, and one trade traced through it 4 client surfaces reach an edge of gateway, realtime channel and event bus. The base holds 10 services, of which Settlement ledger is the source of truth, and 5 blocks are built for each client. Partner services sit behind a boundary and are chosen by the client. Underneath, one trade is traced across 5 steps. 20 of 25 blocks are reused unchanged. .fdiag{--dg-ink:#1c1618; --dg-sub:#6e6264; --dg-rule:#e3d2d5; --dg-rail:#faf5f6; --dg-card:#ffffff; --dg-accent:#a70d2a; --dg-track:#efe9ea; --dg-made:#a70d2a; --dg-made-ink:#ffffff; --dg-zone:rgba(28,22,24,.028); --dg-zone-core:rgba(167,13,42,.05); --dg-zone-line:#e3d2d5; --dg-zone-core-line:#f0c9d1} .lbl{font-size:13px;font-weight:700;fill:var(--dg-ink);letter-spacing:-.014em} .sub{font-size:10.5px;fill:var(--dg-sub)} .note{font-size:10px;fill:var(--dg-sub);font-style:italic} .mono{font-family:'JetBrains Mono',ui-monospace,monospace;font-size:10px; letter-spacing:.14em;text-transform:uppercase;font-weight:500;fill:var(--dg-accent)} .zn{font-family:'JetBrains Mono',ui-monospace,monospace;font-size:10px;font-weight:500; letter-spacing:.13em;text-transform:uppercase;fill:var(--dg-sub)} .zn.zh{fill:var(--dg-accent)} .tag{font-family:'JetBrains Mono',ui-monospace,monospace;font-size:7.5px;font-weight:500; letter-spacing:.1em;fill:var(--dg-accent)} .h2{font-size:30px;font-weight:800;fill:var(--dg-ink);letter-spacing:-.034em} .deck{font-size:13px;fill:var(--dg-sub)} .zone{fill:var(--dg-zone);stroke:var(--dg-zone-line)} .zone-core{fill:var(--dg-zone-core);stroke:var(--dg-zone-core-line)} .card{fill:var(--dg-card);stroke:var(--dg-rule)} .auth{fill:var(--dg-card);stroke:var(--dg-accent);stroke-width:2} .made{fill:var(--dg-made);stroke:none} .made-l{fill:var(--dg-made-ink);font-size:13px;font-weight:700;letter-spacing:-.014em} .made-s{fill:var(--dg-made-ink);font-size:10.5px;opacity:.95} .step{fill:var(--dg-card);stroke:var(--dg-rule)} .dot{fill:var(--dg-accent)} .dotn{fill:#fff;font-family:'JetBrains Mono',ui-monospace,monospace;font-size:11px;font-weight:500} .flow{stroke:var(--dg-rule);stroke-width:1.5;fill:none;marker-end:url(#mxcrypto-ar)} .hot{stroke:var(--dg-accent);stroke-width:2;fill:none;marker-end:url(#mxcrypto-ah);opacity:.55} .cnt{font-family:'JetBrains Mono',ui-monospace,monospace;font-size:10px; letter-spacing:.1em;fill:var(--dg-sub)} Binance Clone MXCrypto Six documented builds run on this base. Only the filled blocks are built for you. Ships ready-made Built for this client Surfaces Edge The base - already built Partner boundary Data Spot order book, pairs, charts Futures & forex leverage, margin, liquidation P2P with escrow peer trades, dispute hold Binary & practice paper trading, options API gateway auth, rate limits, idempotency Market data stream order book, tickers, fills Event bus async fan-out, retries Settlement ledger append-only double-entry postings SOURCE OF TRUTH Matching engine price-time priority, fills Order & position book spot, margin, futures Risk & liquidation exposure caps, margin calls Wallet & custody control hot, cold, withdrawal approval Chain integration deposits, confirmations, sweeps P2P escrow & disputes holds, release, appeal Identity & screening tiers, watchlists, case queue Fees & rewards maker, taker, referrals Algorithmic trading strategy execution, API keys Built for this client Listed markets your pairs and tokens Your token issuance and utility KYC & AML policy your regulator's rules Fee schedule maker, taker, withdrawal Brand & theming web and app chosen by the client Custody their custodian Market data their price feed KYC & screening their provider Fiat on-ramp their banking rail Push & email their sender Transactional store ledger, orders, identities Cache & realtime order book, tickers, sessions Object storage identity documents, statements one trade, end to end every step below runs on blocks that already existed 1 Place pair, side, size 2 Reserve funds held, limits checked 3 Match price-time priority, fill 4 Post double-entry, both accounts 5 Settle balances final, fee taken NODE.JS · MYSQL · FULL-NODE BLOCKCHAIN INTEGRATION 20 of 25 blocks reused unchanged 5 built for you This is the Binance Clone base, drawn as it was actually assembled for EasyCryptoLand. The plain blocks are the ready-made platform and shipped as they are. The filled blocks are the ones we built for this client. 20 of 25 blocks were reused, 5 were built. ## Why none of this had to be written again. Each of these was already running on other builds of the same base before EasyCryptoLand started. That is the whole reason the platform was standing in days rather than months. **Spot**order book, pairs, charts **Futures & forex**leverage, margin, **P2P with escrow**peer trades, dispute hold **Binary & practice**paper trading, options **API gateway**auth, rate limits, **stream**order book, tickers, **Event bus**async fan-out, retries **Settlement ledger**append-only double-entry **Matching engine**price-time priority, **book**spot, margin, futures **Risk & liquidation**exposure caps, margin **control**hot, cold, withdrawal **Chain integration**deposits, confirmations, **disputes**holds, release, appeal **screening**tiers, watchlists, case **Fees & rewards**maker, taker, referrals **trading**strategy execution, API **store**ledger, orders, **realtime**order book, tickers, **Object storage**identity documents, ## The decisions that were actually theirs. A ready-made base does not remove these; it removes everything underneath them. Each one below is a choice EasyCryptoLand had to make, and the engagement is where those choices got implemented. **01** ### Listed markets The pairs and tokens the exchange lists, and the liquidity behind them. **Why it sat with them**The markets they sell into decide this. Adding one later is configuration rather than a rebuild, which is exactly why it is exposed as a decision. **02** ### Your token Issuance, utility and how it moves inside the platform. **Why it sat with them**What a customer gets for their money is the offer itself. The base enforces it; they define it. **03** ### KYC & AML policy What the regulator requires, and the evidence trail that proves it. **Why it sat with them**Where the line sits is theirs to draw, and it moves with their audience. We built the controls and left the thresholds to them. **04** ### Fee schedule Maker, taker and withdrawal pricing. **Why it sat with them**Take rate and pricing are the business model itself. We implement the numbers they set; we do not choose them. **05** ### Brand & theming The identity carried across every surface, so it reads as the client’s product rather than a template. **Why it sat with them**The base has to disappear behind their identity, so this is applied across every surface rather than skinned on one. ## What the six days actually cover. Our build time on a ready-made base, and nothing else. The parts that sit with the client are named plainly. Phase 01Phase 02Phase 03Phase 04 01 ### White-label The base is rebranded to the client’s identity across every surface. 02 ### Deploy Stood up on the client’s own hosting, not ours. 03 ### Publish Apps submitted from the client’s own developer accounts. 04 ### Handover Source, schema, deployment configuration and architecture notes transferred. The client supplies the hosting and domain, a verified developer account we publish from, branding and business details, an onboarded payment gateway with KYC complete, and any third-party API keys. Store review and merchant onboarding are controlled by Apple, Google and the payment provider, so those sit outside our window. [Every figure here is defined on the facts page](https://miracuves.com/facts/#fact-005). ## Who uses it, and for what. Rather than screenshots of a product that has moved on since delivery, this is the set of surfaces that shipped and what each one is for. EasyCryptoLand received every one of them, with the source behind each. Every role here is a separate application with its own permissions, its own state and its own release path. Building them to work as one system is most of the engineering in a platform of this kind, and it is the part that was already finished before this engagement began. Spot order book, pairs, charts Futures & forex leverage, margin, P2P with escrow peer trades, dispute hold Binary & practice paper trading, options ## What guards the platform. Built into the base and hardened across every engagement running it, rather than bolted on at the end of this one. Security added late is security that has to be argued for; the controls below were load-bearing from the first deployment. We claim the process, not a certificate. Miracuves does not hold ISO 27001, and we do not say otherwise: we build to the controls those frameworks require, and the evidence trail is there for an auditor who asks. #### P2P with escrow peer trades, dispute hold. Part of the base, so it was proven before this engagement started. #### Settlement ledger append-only double-entry. Part of the base, so it was proven before this engagement started. #### Role separation Each surface sees only what its role permits, enforced server-side rather than hidden in the interface. #### Audit trail Who changed what and when, retained so a dispute can be answered with a record rather than a recollection. #### Transport and storage TLS end to end, credentials hashed, and anything sensitive at rest encrypted rather than merely obscured. #### Secrets handling Keys live in environment configuration on their own infrastructure, never in the repository we hand over. #### Card data stays out Payment details go to the gateway directly. The platform holds a reference, not a card number. #### What an auditor can actually see We claim the process, not a badge. Everything below was handed to EasyCryptoLand with the source. - Commit history for every change in the build window - Environment configuration separated from application code - Database schema with the migration that produced it - Deployment steps written down rather than remembered - Named team and a daily written progress record ## What it connects to. The connection points are part of the base and were already written and tested. Which providers sit behind each one was EasyCryptoLand’s decision, because those choices are commercial and jurisdictional rather than technical. This is also where the client-side dependencies live. Gateway onboarding, KYC approval and merchant review are controlled by the provider, not by us, which is why they sit outside the build window rather than inside it. Every one of these was already wired and tested in the base. What changed for EasyCryptoLand was which account sat on the far side of it. **Payments and payouts**gateway of their choosing **Identity and KYC**provider per jurisdiction **Object storage and CDN**their bucket, their region **Media pipeline**transcode and delivery **Market data feeds**rates and reference prices **Calendar and scheduling**availability and reminders **Push and transactional email**sent under their sender identity **App store developer accounts**published from their own accounts **Error and uptime monitoring**handed over with the source ## What it runs on. The platform stack for MXCrypto. This describes the base as it stands today; EasyCryptoLand took delivery of the source and has owned it since. **Platform**JS The stack the MXCrypto base runs on, already in production elsewhere **Surfaces**SpotFutures & forexP2P with escrowBinary & practice Each a separate application with its own permissions and release path **Client decisions**Listed marketsYour tokenKYC & AML policyFee scheduleBrand & theming Configured for EasyCryptoLand during the engagement **Handover**SourceSchemaDeployment configArchitecture notes Transferred at the end of the build ## Where the six days went. Our build time only. Store review and merchant onboarding are controlled by Apple, Google and the payment provider, so they sit outside this window and we do not count them as ours. Stating that plainly is the difference between a build time and a promise we cannot keep. [Every figure here is defined on the facts page](https://miracuves.com/facts/#fact-005). The six working days are guaranteed. If a ready-made platform is not live in six, we keep working free until it is. A deadline nobody is accountable for is not a deadline, and a guarantee nobody pays for is not a guarantee. Throughout, a named team worked the build and sent EasyCryptoLand progress on WhatsApp every working day. There was never a week where nobody knew where it stood, which is the part clients tell us they notice more than the date itself. **6 working days** our side of the window The bar below is that window, day by day. Nothing outside it is counted as ours, and nothing inside it waits on someone else. #### What EasyCryptoLand supplied A build window only holds if both sides arrive ready. These sat with them, and the clock does not start until they are in place. - Hosting and a domain, on their own account - A verified developer account we publish from - Branding and business details - A payment gateway onboarded, with KYC complete - Third-party keys for the services they chose **Day 1**Base stood up and white-labelled*Base stood up and white-labelled* **Days 2-4**5 client decisions implemented*5 client decisions implemented* **Day 5**Deployed, apps submitted*Deployed, apps submitted* **Day 6**Source, schema and config handed over*Source, schema and config handed over* ## This base has done this before. EasyCryptoLand was not the experiment. The base underneath this build had already carried other businesses in other markets before it carried theirs, which is the whole argument for reuse: the risk was retired by somebody else’s project, not by this one. Across everything delivered since 2010 that is more than 9,000 products for over 6,000 businesses across 35+ industries. The eighty-four documented on this site are the ones with a named client and permission to show the work; most of the rest sits under NDA or white-label and is deliberately not here at all. Every number on this page is defined and sourced on a public facts ledger. That is the whole instinct behind how this company is run: most vendors ask you to trust them, and we would rather you checked us. If we cannot back a claim, we do not make it, which is why you will not find a satisfaction percentage or an unnamed award anywhere on this site. **20 of 25** Blocks reused unchanged on this build, each already under load on other engagements. *Architecture* **6** Documented builds running on the Binance Clone base, in different markets. *Portfolio* **9,000+** Products delivered for more than 6,000 businesses across 35+ industries since 2010. *Company record* **3,900+** Apps published under clients’ own brands, counted per store release. *Company record* ## What we can state plainly. No client figures were supplied for this build, so these are architectural and contractual facts rather than outcomes. **Source code transferred** blocks reused unchanged Full repository history, to the client’s own account Miracuves delivery record **6 working days**Our build time on the ready-made base **MXCrypto**A base already running on other engagements **6 working days**Our build window on this engagement.Miracuves delivery record E > Matching, custody and the trading UI were already there. We brought our pairs, our onboarding and our regional compliance requirements. Live in weeks with no settlement incidents since. > > > **EasyCryptoLand Team**Founding team, EasyCryptoLand ## What EasyCryptoLand holds now. The same on every engagement. What happened to the platform after handover was theirs to decide. *GIT***Application source**Full repository history, transferred to their account*Delivered* *APP***Mobile projects**Sources with signing documented*Delivered* *SQL***Schema and migrations**Reproducible from empty, not a dump*Delivered* *ENV***Deployment configuration**Another team can run it unaided*Delivered* *MD***Architecture notes**What was chosen, what was rejected, why*Delivered* *60d***Support window**Sixty days included, six and twelve month options*Delivered* ## The questions that decide this. Answered for this build. The same answers hold for every Binance Clone in the portfolio. Do we own the code? Yes. The full repository history transferred to EasyCryptoLand’s own account at handover, with deployment configuration and architecture notes. It is not a licence and it is not held against a support contract. How is six working days realistic? Because 20 of the 25 pieces were built and proven before the engagement started. The six days are our build time on that base, not a calendar promise. What sat with EasyCryptoLand? Hosting and domain, a verified developer account we publish from, branding and business details, an onboarded payment gateway with KYC complete, and any third-party API keys. Will it look like everyone else’s? No. The base supplies mechanics, not identity. Branding, flows and every customer-facing screen were built for this product. Is this what the platform looks like today? This describes what was delivered in 2024. What happened afterwards was EasyCryptoLand’s to decide; the source transferred at handover. Clients move on, rebuild, or sell up, and none of that changes what was delivered or how it went. Would you have said no to this project? We are a good fit for a founder who wants a proven model launched fast, a deadline they can hold us to, and code they own outright. We are a poor fit for anyone who needs a team embedded in their office full-time, or who wants a blank page and a six-month roadmap. Being straight about that up front saves everyone a call. Who actually worked on it? A named team, not a rotating pool. Our leadership is public with real profiles rather than a stock-photo team page, and progress went to EasyCryptoLand on WhatsApp every working day of the build. ## Others on the same base. Different clients, different markets, one proven platform underneath. [**Annurax Exchange**Binance Clone - a crypto exchange](/portfolio/annurax-exchange/) [**Blue Silent Exchange - Spot**Binance Clone - a spot crypto exchange](/portfolio/blue-silent-exchange-spot/) [**BRC20**Binance Clone - a crypto exchange](/portfolio/brc20/) ## Building something like this? Tell us what you are building and we will say plainly whether a ready-made base fits it, including when the answer costs us the larger project. [Book a technical call](https://miracuves.com/schedule-consultation/) [See all case studies](/portfolio/) - Ready-made platform deploys in 6 working days - Custom builds run 2 to 8 weeks - Source code transfers on every engagement - [Every figure here is defined on the facts page](https://miracuves.com/facts/#fact-005) (function(){ var reduce=matchMedia('(prefers-reduced-motion: reduce)').matches; /* read-progress bar */ var bar=document.getElementById('progbar'); if(bar){ var prog=function(){var h=document.documentElement.scrollHeight-innerHeight; bar.style.width=(h>0?(scrollY/h)*100:0)+'%';}; addEventListener('scroll',prog,{passive:true}); prog(); } if(!('IntersectionObserver' in window)) return; /* reveal on scroll */ if(!reduce){ document.documentElement.classList.add('js-anim'); var io=new IntersectionObserver(function(es){es.forEach(function(e){ if(e.isIntersecting){e.target.classList.add('in');io.unobserve(e.target);}});}, {rootMargin:'0px 0px -8% 0px',threshold:.06}); [].forEach.call(document.querySelectorAll('.rv'),function(el,i){ el.style.setProperty('--d',(i%4*80)+'ms'); io.observe(el);}); } /* numeric counters - text metrics are left alone (no data-count) */ /* no count-up on trust figures: it dropped the thousands separator and showed a wrong number while running. The markup already holds the formatted value. */ /* sticky sub-nav scroll-spy */ var links=[].slice.call(document.querySelectorAll('.snav a')); var sio=new IntersectionObserver(function(es){es.forEach(function(e){ if(!e.isIntersecting) return; links.forEach(function(a){a.setAttribute('aria-current', a.getAttribute('href')==='#'+e.target.id?'true':'false');});});}, {rootMargin:'-30% 0px -60% 0px',threshold:0}); links.forEach(function(a){var t=document.getElementById(a.getAttribute('href').slice(1)); if(t) sio.observe(t);}); /* kinetic headline + gantt bars + line reveals */ var kio=new IntersectionObserver(function(es){es.forEach(function(e){ if(e.isIntersecting){e.target.classList.add('in');kio.unobserve(e.target);}});}, {rootMargin:'0px 0px -10% 0px',threshold:.18}); document.querySelectorAll('.kin,.reveal,.gr').forEach(function(el){kio.observe(el);}); /* drag-to-scroll rails + progress thumb */ document.querySelectorAll('.rail,.hstrip,.strip').forEach(function(r){ var down=false,sx=0,sl=0; r.addEventListener('pointerdown',function(e){down=true;sx=e.clientX;sl=r.scrollLeft; r.classList.add('drag');}); r.addEventListener('pointermove',function(e){if(!down)return;r.scrollLeft=sl-(e.clientX-sx);}); ['pointerup','pointerleave','pointercancel'].forEach(function(ev){ r.addEventListener(ev,function(){down=false;r.classList.remove('drag');});}); var thumb=r.parentElement&&r.parentElement.querySelector('.rthumb'), track=r.parentElement&&r.parentElement.querySelector('.rtrack'); if(thumb&&track){ var upd=function(){var max=r.scrollWidth-r.clientWidth,p=max>0?r.scrollLeft/max:0; thumb.style.transform='translateX('+(p*(track.clientWidth-thumb.clientWidth))+'px)';}; r.addEventListener('scroll',upd,{passive:true}); addEventListener('resize',upd); upd(); } }); /* custom cursor */ var cur=document.getElementById('cur'); if(cur && matchMedia('(hover:hover) and (pointer:fine)').matches && !reduce){ var cx=0,cy=0,tx=0,ty=0; addEventListener('mousemove',function(e){tx=e.clientX;ty=e.clientY;},{passive:true}); (function loop(){cx+=(tx-cx)*.16;cy+=(ty-cy)*.16; cur.style.transform='translate3d('+(cx-17)+'px,'+(cy-17)+'px,0)'; requestAnimationFrame(loop);})(); document.querySelectorAll('a,button,summary,.sdev,.hdevice,.rcd').forEach(function(el){ el.addEventListener('mouseenter',function(){cur.classList.add('on');}); el.addEventListener('mouseleave',function(){cur.classList.remove('on');});}); } /* process spine fill + node activation */ var sf=document.getElementById('sfill'), phs=[].slice.call(document.querySelectorAll('.pdeck .phase')), nds=[].slice.call(document.querySelectorAll('.snode')), nls=[].slice.call(document.querySelectorAll('.snl')); if(sf&&phs.length){ var deck=document.querySelector('.proc .pdeck'); var upd=function(){ var r=deck.getBoundingClientRect(),h=r.height-innerHeight*0.5; var p=Math.min(Math.max((innerHeight*0.5-r.top)/(h||1),0),1); sf.style.height=(p*100)+'%'; var act=Math.round(p*(nds.length-1)); nds.forEach(function(n,i){n.classList.toggle('on',i<=act);}); nls.forEach(function(n,i){n.classList.toggle('on',i<=act);}); }; addEventListener('scroll',upd,{passive:true}); addEventListener('resize',upd); upd(); } /* architecture tabs */ var tbs=[].slice.call(document.querySelectorAll('.tb')), pns=[].slice.call(document.querySelectorAll('.tpane')); tbs.forEach(function(t,i){t.addEventListener('click',function(){ tbs.forEach(function(x,j){x.setAttribute('aria-selected',i===j?'true':'false');}); pns.forEach(function(x,j){x.classList.toggle('on',i===j);});});}); /* product screen gallery */ var thumbs=[].slice.call(document.querySelectorAll('.thumb')), shots=[].slice.call(document.querySelectorAll('.shot')); if(thumbs.length&&shots.length){ var show=function(n){shots.forEach(function(x,i){x.classList.toggle('on',i===n);}); thumbs.forEach(function(t,i){t.setAttribute('aria-selected',i===n?'true':'false');});}; thumbs.forEach(function(t,i){ t.addEventListener('click',function(){show(i);}); t.addEventListener('keydown',function(ev){ if(ev.key==='ArrowRight'||ev.key==='ArrowDown'){ev.preventDefault(); var n=(i+1)%thumbs.length;thumbs[n].focus();show(n);} if(ev.key==='ArrowLeft'||ev.key==='ArrowUp'){ev.preventDefault(); var p=(i-1+thumbs.length)%thumbs.length;thumbs[p].focus();show(p);}});}); } })(); /* Everything pinned at the top of the viewport, measured rather than assumed. The theme header is position:fixed and its height is not constant (70px wide, 93px at 1280 where its own nav wraps). When an editor is logged in, the WordPress admin bar sits above it and the header is pushed down, so the top of the window is a STACK of fixed bars, not one. Probing only y=1 finds the topmost bar and nothing else - which pinned the section nav at 32px, directly behind the header, for every logged-in user while looking perfect logged out. So walk down the top edge until we run out of bars and take the deepest. A measurement of 0 means "not found yet" - the theme does not make its header fixed until the first scroll - and must never be written, or it would override the CSS default and pin the nav at the very top. */ (function(){ var scope = document.querySelector('.mcvcs,.mcvhub') || document.documentElement; var nav = document.querySelector('.snav'), last = -1; function measure(){ var h = 0, cx = Math.round(innerWidth / 2), maxY = Math.min(300, Math.round(innerHeight * 0.4)), y, i, e, c, b, found, stack; for (y = 1; y <= maxY; y += 4){ found = 0; stack = []; try { stack = document.elementsFromPoint(cx, y) || []; } catch (err) {} for (i = 0; i innerWidth * 0.6 && b.height > 12 && b.height < innerHeight * 0.4 && b.top = y){ found = 1; if (b.bottom > h) h = b.bottom; } } } if (!found && h) break; // past the bottom of the bar stack } h = Math.round(h); if (!h || h === last) return; last = h; scope.style.setProperty('--site-h', h + 'px'); var navH = nav ? Math.round(nav.getBoundingClientRect().height) : 0; document.documentElement.style.scrollPaddingTop = (h + navH + 14) + 'px'; } measure(); addEventListener('load', measure); var t; function later(){ clearTimeout(t); t = setTimeout(measure, 120); } addEventListener('scroll', later, {passive:true}); addEventListener('resize', function(){ last = -1; later(); }); })();