Our white-label crypto exchange creates every user wallet and address through MC Chain Infrastructure, and tracks every deposit and withdrawal through it. That is the shortest honest description of what this is: a node and API layer that is already carrying production traffic for a trading venue, offered to the teams who would otherwise build it themselves.
Underneath it is our own node infrastructure — Ethereum, Bitcoin, TRON, BSC and more — engineered for high availability with load distributed across nodes, running in our own data-centre cage space in Zurich, Frankfurt and Istanbul. On top of it sits one API to transact across all supported chains.
There is no signup button, and we do not publish public API documentation today. This is infrastructure we deploy with you, so the first step is a technical conversation with an engineer — not a sales call, and not a credit card.
MC Chain Infrastructure is two things that are usually bought from two different suppliers.
The node layer. We run our own blockchain nodes for the chains we support, in our own cage space, on our own hardware and network. Requests are distributed across nodes with health and block-height awareness, unhealthy nodes are drained from rotation, and workload classes are separated so that one expensive consumer cannot starve the path that credits a customer's deposit.
The API layer. On top of the nodes sits a generic gateway and framework: one interface for address creation, balance queries, transaction construction, fee handling, broadcast, confirmation tracking, event notification and reconciliation — across every chain we support, without a chain-specific SDK per network and without a separate mental model per team member.
Between them, they are the layer that most teams underestimate. Writing the first integration against a chain is a week's work. Operating it — through forks, client bugs, reorganisations, stuck transactions, fee spikes, chain halts, and the day a token contract does something the standard says it cannot — is the actual job, and it never ends.
Development teams building anything that has to hold, move or observe assets on more than one chain: exchanges and brokers, custody and wallet products, payment and settlement flows, token issuers, treasury systems, and fintechs adding digital assets to an existing product. It is also the foundation we build bespoke systems on for clients who would rather buy the outcome than the components.
We do not run the public blockchains. We do not publish a node count, an uptime percentage, a supported-chain count or a request-volume figure, and you should be sceptical of the ones you are shown elsewhere — each is measured against a definition the vendor chose. What we will do is answer the specific version of the question for your case: whether your chain is supported, what the deployment would look like, and what happens in the failure modes you care about. Those answers are checkable. Percentages are not.
Shared node providers are good products and they are the right answer for a great many applications. This section is not an attack on them. It is the list of things that change once your product has real money and real customers on it — the reasons we run our own, and the reasons you might want yours run rather than rented.
When a shared endpoint degrades, everyone on it degrades at the same moment, including your competitors, which is no comfort to your customers. You cannot look at the node, you cannot restart it, you cannot roll it back to the previous client version, and you cannot prioritise your own traffic. You can open a ticket and wait. For a product where a stalled deposit is a support case and a stalled withdrawal is a trust problem, that is an uncomfortable amount of your reliability sitting outside your control.
Shared access is metered — requests per second, burst allowances, credits or compute units, with the heaviest weights on exactly the calls that serious applications need: log and event scans, historical state at a past block, traces, large ranges. Teams end up designing around the quota instead of around the product: caching things that should be read fresh, batching things that should be immediate, sampling things that should be complete. And the bill grows with your transaction count, which means your infrastructure cost scales with your success in the one direction you cannot negotiate from strength.
Some things are not a pricing tier, they are an architectural boundary. Full mempool visibility as your node sees it. Trace and debug access without a per-call premium. Archive state at arbitrary height. The ability to run a non-standard client configuration, an additional index, or a second client implementation for cross-checking. The ability to observe the chain's behaviour — reorganisation depth, propagation, peer quality — rather than only the provider's summary of it. If your product's value depends on seeing something before or more completely than everyone else, renting the same view as everyone else is a strange place to start.
A shared endpoint load-balances your requests across a pool of nodes at slightly different heights. Two consecutive calls can therefore go backwards in time: you submit a transaction, then query for it and it does not exist; you read a balance, then read it again and it is older. Applications that handle money do not tolerate that quietly — they double-send, or they mis-credit, or they produce a reconciliation break that somebody spends a week finding.
Our routing is height-aware and, where a caller needs read-your-writes behaviour, sticky. A node that falls behind is drained from rotation rather than being served to you as though it were current. This is unglamorous and it is the single most valuable property of a node layer that handles money.
How many confirmations before you credit a deposit is not a technical constant. It is a risk decision that varies by chain, by asset, by amount and by your appetite, and it is different on a chain with probabilistic settlement than on one with explicit finality. Using a shared provider means inheriting its view of what "confirmed" means, and being unable to see the reorganisation that would have changed your mind.
On our own nodes, confirmation policy is configuration you own: per chain, per asset, and banded by amount so that a small deposit can be credited quickly while a large one waits. And when a reorganisation does occur below your threshold, the API layer emits it as an event you must handle, rather than quietly rewriting a balance and hoping nobody reconciles.
Running your own nodes is not free and it is not clever by itself. It is an operational discipline: client upgrades before every hard fork, fork-choice monitoring, disk growth that never stops, snapshot and rebuild procedures, peering, and someone awake when a chain does something unexpected at 04:00. That work is the reason most teams rent instead, and it is a rational choice. Our proposition is not that you should take that work on. It is that we already do it, for our own product, and you can use the result.
Nodes run in our own data-centre cage space and systems in Zurich, Frankfurt and Istanbul. Three sites that do not share a power grid, a metro fibre map or a jurisdiction, which is what makes geographic redundancy and disaster recovery a design decision rather than a region setting on someone else's console. Frankfurt carries a dense interconnection footprint for European reachability; Zurich is the Swiss site and the second independent failure domain; Istanbul is the third. More about Cloud & Infrastructure.
Each supported chain is served by a pool rather than a node. Requests are distributed across the pool by health and by block height, and health is not a ping — it is sync status, height against peers, peer count, response behaviour and error rate together. A node that is behind, syncing, reorganising or misbehaving is drained from rotation, allowed to catch up, and re-admitted only when it is provably current.
Not all requests are equal, and treating them as though they are is how a deposit gets credited late. Light, latency-sensitive reads on the hot path — balance checks, transaction status, broadcast — are served by different node pools than heavy historical queries, log scans and traces. A reporting job that walks a year of history cannot slow the path that credits a customer's deposit, because it is not running on the same nodes.
Archive capacity exists where historical state is needed — reconciliation, audit, forensic questions about what a contract held at a given block — and the hot path runs against nodes sized and configured for it. Which chains require archive capacity in a given deployment is part of the architecture conversation, because archive nodes are considerably more expensive to run and there is no reason to pay for one where nothing needs it.
The failure we design against is not one node dying; that is routine. It is the correlated failure — a client release with a consensus bug, a fork the fleet handles inconsistently, a site loss. Where a chain has more than one production client implementation, running more than one is a deliberate hedge against a single implementation's bug taking the whole fleet with it. Where a chain has only one, the mitigation is version staggering and a rollback path prepared before the upgrade, not after it.
Client upgrades scheduled and rehearsed ahead of hard forks. Fork readiness as a checklist rather than a scramble. Snapshot and rebuild procedures that are actually executed rather than documented. Disk growth planned rather than discovered. Peering maintained. Monitoring of chain-level conditions — reorganisation depth, block intervals, mempool congestion, fee regimes — because the first sign of trouble is usually in the chain's behaviour rather than in the server's.
The point of running our own nodes is defeated if the hot path silently falls back to a public endpoint under load. It does not. Where a public or third-party endpoint is used at all, it is for cross-checking rather than for serving, and the distinction is visible in the request record.
The framework's job is to absorb the mechanical differences between chains and to expose the ones that carry risk. A unified API that hides the fact that a chain can reorganise is not simplifying your integration. It is concealing a liability inside it.
Address generation and derivation. Balance and transaction queries. Transaction construction, including fee and gas estimation. Signing hand-off to whatever key management design the deployment uses. Broadcast. Confirmation tracking against your policy. Event notification. Reconciliation against chain state. The same shapes on every supported chain, so adding a chain to your product is a configuration and testing exercise rather than a new subsystem and a new on-call rotation.
Account-model and UTXO-model chains and the different bookkeeping each demands — nonce sequencing on one, input selection and change handling on the other. Chains where a deposit is identified by a destination tag or memo rather than by a unique address, and the accounting that follows from that. Token standards and their differences across networks. Decimal precision, address formats and checksum rules. The fact that moving a token requires the native asset for fees, on a chain-specific model — gas on one network, energy and bandwidth on another.
Every state-changing call takes a caller-supplied identifier, and a retried request with the same identifier returns the original result instead of creating a second transaction. This sounds like a detail and it is the difference between a network timeout being an inconvenience and a network timeout being a double withdrawal. Broadcast, nonce allocation and sweep instructions are all built on it.
Webhook delivery for the events an application cares about — incoming transaction seen, confirmation threshold reached, outgoing transaction confirmed, reorganisation affecting a credited transaction, transaction stuck or replaced. Delivery is at-least-once with retry and backoff, payloads are signed so your endpoint can verify them, and missed events can be replayed rather than lost.
And then the part most integrations get wrong: webhooks are a notification mechanism, not a ledger. Any system that treats a missed webhook as an event that did not happen will eventually mis-state a balance. The framework therefore also exposes a reconciliation path — re-derive state from the chain for an address, an account or a period, and compare it against what your system believes. Your books should be provable against the chain, not against our database.
Fee estimation per chain with configurable strategy. Replacement and acceleration for transactions that stall, handled correctly for each chain's model rather than by resubmitting and hoping. Stuck-transaction detection and defined remediation. Automatic funding of derived addresses with the native asset where a token sweep requires it — an unglamorous piece of plumbing that quietly breaks token deposits for teams who did not anticipate it. Batching and sweep scheduling where the economics justify them.
Every request is attributable: which node served it, at what block height, and what the chain state was at that moment. When a customer disputes a balance nine months later, the question is answerable from records rather than from reasoning.
MC Chain Infrastructure is bought as a platform, and it is also the foundation under the products we build for clients. These are the five things it most often becomes.
Wallet systems where the custody model is a decision made deliberately rather than inherited. Custodial designs with hot, warm and cold separation, an approval policy engine between the application and the signing layer, withdrawal allowlists, per-tier limits, quorum approval for movements above a threshold, and a key ceremony that is planned, executed and witnessed rather than improvised. Non-custodial designs where the user holds the key and the platform is structurally incapable of moving their funds — which is a different product with different obligations, and the difference belongs in the architecture rather than in the marketing.
Key management scheme, backup and recovery are designed per engagement against your risk and regulatory position. This is the decision with the longest consequences in the whole system, and it is not one to inherit from a vendor's default.
Contract development, review and deployment: token contracts, vesting and lock-up, staking, escrow and settlement logic, upgrade patterns and the administrative key policy behind them. Testing, deployment, verification and the operational runbook for what happens when the contract needs to be paused.
To be clear about scope: we write and review contracts, and we are not a security audit firm. Anything holding meaningful value should be independently audited by a specialist before it is deployed, and we will work alongside your auditor and remediate against their findings. A vendor who tells you their internal review is sufficient is telling you something about their risk appetite with your money.
Applications that operate across several chains at once, where the hard part is not any individual chain but the consistency between them — how state is reconciled, how a partial failure across two networks is resolved, how the user is shown one coherent picture of assets that settle on different schedules under different finality rules.
Checkout and invoice flows: address or tag issuance per payment, expiry and reuse policy, confirmation policy by amount, and the cases every payment system meets in its first month — underpayment, overpayment, late payment after expiry, payment on the wrong chain, and refunds. Then sweeping to treasury, settlement reporting and the reconciliation that lets finance close a period.
The technical layer of a token programme: issuance, supply and lifecycle management, transfer restrictions and allowlist logic where the instrument requires them, registry and holder records, corporate-action-style events, and reporting. The legal structure, the offering and the regulatory permissions are yours and your counsel's. We build the part that has to behave correctly.
The strongest thing we can say about this framework is not a feature. It is what depends on it.
Our White Label Crypto Exchange uses MC Chain Infrastructure to create user wallets and addresses and to track deposits and withdrawals. Not as an integration option. As the layer underneath.
A customer opens the deposit screen. The address is derived by the framework from a wallet structure designed for that deployment. The incoming transaction is seen by our own nodes rather than by a hosted endpoint with a request quota. Confirmations are counted against the policy the operator configured for that chain, that asset and that amount band. The credit is then the exchange's decision, made on an event the API layer emitted — and if a reorganisation invalidates that transaction, it emits that too, so the credit is reversed rather than silently wrong. Withdrawals run the same path in reverse: constructed, fee-estimated, signed under the deployment's approval policy, broadcast, tracked, replaced if they stall, confirmed, reconciled.
Because it means the failure modes have already been met. Stuck transactions during a fee spike. A chain halting. A hard fork requiring a client upgrade on a deadline set by someone else. Token deposits to addresses with no native asset to pay the sweep. Deposits arriving without a memo on a chain that requires one. A reorganisation deeper than the default policy. Sweeping at the volume a live venue produces rather than at the volume a test suite produces.
Every one of those is a support ticket, a reconciliation break or a loss the first time it happens to you. They have happened to us already, on our own product, and the handling is in the framework rather than in a document describing what should be done.
We have been building and operating crypto exchange infrastructure since 2017. The core team has worked together since the 1990s — more than thirty years in computing, programming, networking and large-scale systems. You can see the venue product this framework carries at the live exchange demo, which we open on request.
We run the nodes and the gateway in our facilities, and your application integrates against it. You get the node layer, the API, the operations and the connector maintenance without building any of it. Of the models below this is the least work to get to a working integration, and it is the one most product teams take.
Dedicated node capacity and a dedicated API gateway instance, on hardware and network segments that are yours alone, in one or more of our locations. Chosen where isolation is an internal-audit or regulatory requirement, or where the workload justifies dedicated resource. Which of our three sites it runs in is a decision you make, and it is how data residency is settled.
The framework deployed inside your own facility or your own cloud tenancy, with the node layer either ours, yours, or split — a common pattern is our nodes for chains you use occasionally and your own for the one your product lives on. Where you run it yourself, we hand over runbooks, upgrade procedures and fork playbooks, because infrastructure you cannot operate without us is not infrastructure you own.
Most engagements are not "give us API access". They are a wallet system, a payment flow, a token programme or a multi-chain application, built on this framework by the team that wrote it. Delivery follows the sequence described on the Blockchain & FinTech page: discovery, architecture, engineering, hardening, then operate. Discovery produces a written scope, the constraints your regulatory position imposes, and a plain list of anything we think is a bad idea or would not take on.
A technical conversation with an engineer who has operated this. Bring the chains and assets you need, your custody model or the fact that you have not chosen one yet, your confirmation and risk requirements, your existing systems, and the deadline you are working to. You will get a straight answer about whether we are the right supplier, including when we are not.
There is no self-serve signup and no public documentation portal today. We would rather say that plainly than build a page that implies a product you cannot buy with a credit card. The API reference and a walkthrough are shared with teams we are in conversation with — ask, and we will arrange it.
Not today. MC Chain Infrastructure is deployed through an engagement rather than sold from a pricing page, and we do not currently publish a public documentation portal or offer instant API keys. We are telling you that here rather than letting you discover it after filling in a form. What you can have quickly is the API reference and a technical walkthrough with an engineer who runs this infrastructure — ask for both and we will arrange them. If what you need is a free key in ninety seconds for a prototype, a shared node provider is genuinely the right tool for that job, and we would rather say so than waste your afternoon.
Ethereum, Bitcoin, TRON, BSC and more. We deliberately do not publish a chain count, because the number is a marketing metric rather than an answer: a list of ninety chains tells you nothing about whether the one you need is supported properly, with the right confirmation semantics, archive capacity and token handling. Ask about your specific chains and you will get a direct answer, including where support means production-grade today, and where it would be engineering work with a timeline attached. Adding a chain to the framework is normal work for us rather than a special project, because the framework was built to be extended.
That depends on the design, and it is the most consequential decision in the system, so we treat it as an architecture question rather than a product default. Custodial designs separate hot, warm and cold key material, put an approval policy engine between the application and the signing layer, and enforce allowlists, limits and quorum approval above defined thresholds. Non-custodial designs are structurally different: the user holds the key and the platform cannot move their funds, which changes both the product and your obligations. Where the deployment runs in your own environment, key material can remain entirely inside your boundary and we never see it. Key management scheme, backup, recovery and the key ceremony itself are designed with you, against your risk and regulatory position.
We detect them, emit them and expect the consumer to act on them. A reorganisation that invalidates a transaction you have already been told about produces an explicit event, so a credit can be reversed rather than left silently wrong. Confirmation policy is yours to configure — per chain, per asset, and banded by amount, so a small deposit can be credited quickly while a large one waits for a depth you are comfortable with. Because the nodes are ours, we can see the reorganisation happen and measure its depth rather than inferring it from an API's summary. What we will not do is present a chain with probabilistic settlement as though a fixed number of confirmations makes it final. That is a risk decision, it belongs to you, and the framework is built to let you make it explicitly.
Fork upgrades are scheduled work: client versions tested, staggered across the fleet, with a rollback path prepared before the upgrade rather than improvised during it. Where a chain has more than one production client implementation, running more than one is a deliberate hedge, so a consensus bug in a single implementation does not take the whole fleet. Chain-level conditions — reorganisation depth, block intervals, mempool congestion, fee regimes — are monitored, because the first sign of trouble is usually in the chain's behaviour rather than in the server's. And when a chain genuinely halts, no infrastructure can fix that; what the framework can do is stop crediting on it, surface the condition clearly, and give your operations team something better than customer complaints as a first indication.
Three differences that only matter once you have real money on the system. First, the nodes are ours, so you are not one tenant on an endpoint that degrades for everyone at once, and we can prioritise, restart, roll back and inspect. Second, consistency: shared endpoints route consecutive requests to nodes at different heights, so your reads can go backwards in time — our routing is height-aware and sticky where read-your-writes matters, and a lagging node is drained rather than served to you. Third, confirmation policy and chain data are yours to control rather than inherited. There is also a fourth difference that cuts the other way, and we will state it: a shared provider gives you an API key in minutes and we do not. For a prototype, that is the better trade.
Yes. The framework can be deployed in your own facility or cloud tenancy, with the node layer ours, yours, or split between the two — running your own nodes for the chain your product depends on while using ours for the rest is a common and sensible pattern. Where you operate it yourself, you receive the runbooks, upgrade procedures and fork playbooks with it. Infrastructure you cannot operate without the vendor is not infrastructure you own, and we would rather hand over the operational knowledge than keep you dependent on us for it.
We write and review them; we are not a security audit firm and we will not present ourselves as one. Anything holding meaningful value should be audited independently by a specialist before deployment. We will work alongside your auditor, remediate against their findings, and build the deployment, upgrade and administrative key policy around the contract properly. Treat any development vendor who tells you an internal review is sufficient as having told you something important about how they handle risk with other people's money.
The useful first conversation is specific. Which chains and assets. Whether you hold customer keys or the customer does. What your confirmation and risk policy needs to be. What has to reconcile against what. Which existing systems this has to fit into, and what deadline you are working to.
We will tell you what the deployment would look like, what we would build, what we would not take on, and whether a shared provider would serve you better for now. We do not publish client names — contact us and we will share relevant references under NDA.
You can also read about the White Label Crypto Exchange this framework carries in production, and about MC Trading Infrastructure, the aggregation, market making and hedging platform that sits alongside it.
We reply to enquiries within 2 business days.
