Digital Asset Infrastructure for Exchanges and OTC Desks: The 6 Layers That Protect Customer Funds

Most exchanges don't lose money because someone broke their cryptography. They lose it on the way to the key.

Digital asset infrastructure for an exchange, often called crypto exchange infrastructure, is everything between a customer's deposit and a signed transaction: how you watch the chain, where funds sit, who signs, what rules decide a signature, how money moves between wallets, and how you prove the books match. The key matters. The path to the key matters more. That is the core idea behind self-hosted MPC wallet infrastructure: you control the whole path, not only the key.

To keep this concrete, we will follow one business through the post. Picture a mid-sized exchange in Southeast Asia that also runs an OTC desk, a team that trades large amounts directly with clients instead of through the public order book. The numbers are illustrative: about $45 million in customer withdrawals a month, and an OTC desk that settles around 25 block trades a month at roughly $2 million each. Both run on the same infrastructure. They put very different pressure on it.

Key takeaways

• An exchange's digital asset infrastructure has six layers. We call this the Six-Layer Exchange Stack.
• The largest exchange hack of 2025 broke no key. Signers approved a transaction that looked routine and was not.
• The approval layer deserves more attention than the choice between MPC and multisig. Rules must check the transaction itself, not the screen.
• OTC desks run the same six layers, but their risk sits in a few large transfers, so verification matters more than automation.

The Key Is Rarely the Weak Point

The biggest crypto theft of 2025 did not break any cryptography. It changed what three signers saw on their screens.

On February 21, 2025, Bybit's signers approved what looked like a routine move from its Ethereum multisig cold wallet to a warm wallet, The Block reported. About $1.5 billion left the exchange as a result.

Investigators traced the attack to Safe{Wallet}, the multisig provider. Attackers had compromised a Safe developer's machine and injected malicious code into its web app. According to BleepingComputer, the forensic review found no evidence that Bybit's own systems were breached.

The detail that matters most is what the signers actually approved. The transaction sent no money. It was a delegatecall, an instruction that lets another contract run its code inside the wallet, and it replaced the code that controls the wallet with the attacker's version, as BlockSec's analysis shows. Once that swap went through, the multisig rules no longer applied, and the attacker emptied the wallet.

That one incident made up about 44% of the more than $3.4 billion stolen across crypto from January to early December 2025, according to Chainalysis data.

Notice the pattern. The attack did not defeat cryptography. It went around it, through a vendor's laptop, a web page and the people reading it.

What Digital Asset Infrastructure Does a Crypto Exchange Need?

An exchange needs six layers of digital asset infrastructure, and each one fails in its own way. The table below is the Six-Layer Exchange Stack, with the usual failure and a default choice for each layer.

For our example exchange, the hot wallet choice in layer 2 shows the stack at work. At $45 million a month, withdrawals average about $1.5 million a day. If a busy day runs three times that, a hot wallet sized for six hours of a busy day holds about $1.1 million, and the rest sits in warm and cold storage. That number is a risk decision: it caps what one bad hot wallet signature can lose.

If you want the step-by-step version of deposits, withdrawals and refills, we walked through it in how money moves inside a centralized exchange.

Why the Approval Layer Matters Most

The approval layer decides which transactions get signed, so it is the last point where a bad transaction can be stopped. Signing only does what approval allows.

Many teams spend months choosing between MPC, HSM and multisig. Fewer spend a week on the rules that sit in front of the signer. Yet that is where Bybit broke: the signers trusted what a screen showed them.

A good approval layer doesn't rely on a human reading a screen. It reads the raw transaction, works out what it will actually do, and checks it in code before anyone signs. Is this a plain transfer or a contract call? Is the destination in our address book? Was the address added in the last 24 hours? Is this wallet already over its outflow limit for the day? Is it 3 a.m. on a Sunday?

These checks are boring. That is the point. Rules like these do not get tired or rushed. The example below is illustrative, not the syntax of any one product:

DENY     tx.wallet_tier == "cold" && tx.type != "transfer"
DENY     withdrawal.address_age_sec < 86400
APPROVE  withdrawal.value_usd >= 250000  -> treasury group, 2 of 3
ALLOW    withdrawal.is_whitelisted && withdrawal.value_usd < 1000

The first rule is the one that matters for a Bybit-style attack. The cold wallet may only send plain transfers, so a contract call that rewrites the wallet is refused, whatever the screen says. The second blocks withdrawals to an address added less than a day ago. The third sends large transfers to a named approval group. The fourth lets small transfers to known addresses through without a human. Everything else waits for review.

One condition makes this work. The rules must run on the exact transaction the signers will sign, in a system the screen cannot rewrite. If the policy check reads the same web page the approvers read, it gets fooled the same way they do.

The question is not "MPC or multisig?" Both can be safe. The real question is "what checks run before anyone is asked to sign?" If you are still weighing the signing model itself, start with how an MPC wallet splits signing authority.

How OTC Desk Infrastructure Differs From an Exchange

An OTC desk needs the same six layers as an exchange, but its risk sits in a few large transfers instead of thousands of small ones. That moves the work from automation to verification: each large transfer is checked more slowly, by more people.

Our example makes the difference plain. The desk's average trade of $2 million is almost twice the exchange's entire hot wallet. A single OTC payout cannot come from hot storage at all. It has to be planned: funds come out of warm or cold storage, a senior signer joins the approval, and the client's side of the trade is confirmed before anything moves.

Three controls carry most of the weight for an OTC desk.

Counterparty allowlists set at onboarding. Clients register their settlement addresses when they are onboarded and verified (KYB, the business version of know-your-customer), not on trade day. This keeps the 24-hour address-age rule from slowing urgent trades. It also defeats address poisoning, where an attacker sends a tiny payment from a lookalike address, hoping an operator later copies the wrong one from the transaction history.

A test transfer before the full amount. Send a small amount first, have the client confirm receipt, then send the rest. It costs one extra network fee and a few minutes. Against a $2 million transfer to a wrong address, that is cheap.

Deposit finality before release. It is common to hear that deposit detection matters less for OTC. It matters more. A desk sees fewer deposits, but each one is large, and releasing your side of the trade before the client's deposit is final can lose the whole trade. A large deposit deserves more confirmations than a retail one, not fewer.

Then there is settlement risk itself: who sends first, and what happens if only one side delivers. We cover pre-funding and other settlement models in OTC settlement risk in large-block trades.

Because regional desks and exchanges often face data residency rules, which require customer data to stay in-country, many keep the whole stack on their own servers. We explained why in why exchanges and OTC desks still matter.

Why These Layers Break

The layers rarely fail on their own. They fail at the seams between them, for three reasons.

People sit in the middle. Approvers, support staff and developers all touch the path to the key. Every one of them is a target, and as Bybit showed, so are your vendors' developers.

The stack is split across vendors. Approvals live in one tool, signing in another, monitoring in a third. When no single place enforces the rules, each tool assumes another one checked.

The books are checked too late. If you reconcile your ledger against the chain once a day, a problem can run for a day before anyone sees it. For our example exchange, that is a full day of withdrawals, about $1.5 million on an average day, moving against books that no longer match.

What to Do When Something Goes Wrong

Every exchange and OTC desk needs an incident plan before the incident. Prevention eventually fails, and the plan decides how much that costs.

Three questions cover most of it. Who can pause all outflows, and can they do it at 3 a.m. without waking five people? Can you pause one wallet, so cold storage freezes while normal withdrawals keep running? And if a server holding one key share fails, can you still sign with the others, and how long would recovery take?

Write the answers down and rehearse them. A pause button nobody has tested is a guess.

How to Evaluate Your Exchange or OTC Infrastructure

Take a large withdrawal and follow it from request to signature. Then ask these questions.

• Who can start it?
• Which checks run in code, on the transaction itself, and which run in someone's head?
• Can one person, one laptop or one vendor move funds alone?
• How fast would you notice if your ledger and the chain disagreed?
• Who can pause outflows, and how fast?
• If a vendor went down tomorrow, could you still sign?

For an OTC desk, add two more. Are client settlement addresses registered before trade day? Does every transfer above your threshold get a test transfer and a senior signer?

If any answer is "we're not sure," that layer comes first.

Treasury work deserves the same honesty. Manual sweeps and hot wallet refills work at low volume and break during a busy day. That is why most teams end up with stablecoin treasury automation sooner than they expected.

Where Fystack Fits

Fystack builds self-hosted custody infrastructure that runs most of this stack on your own servers.

• Signing (layer 3): runs on mpcium, our open-source MPC engine. The default self-hosted setup uses three nodes, any two of which can sign. An MPC wallet is a normal account, not a smart contract, so there is no wallet code to swap. That removes the exact path used against Bybit. It does not remove blind signing in general, which is why the next layer matters.
• Policy and approvals (layer 4): a policy engine checks amount, destination whitelist, address age, outflow velocity and time windows before signing, and approval groups handle anything above your limits. Cosigner, a self-hosted participant that holds one key share, checks an approval callback before it adds its part of a signature.
• Treasury (layer 5): sweep tasks and a Gas Station keep deposits consolidated and gas wallets funded.
• Compliance (layer 6): withdrawal addresses are screened for risk, and signed webhooks for deposits and withdrawals feed your own ledger for reconciliation.

The trade-off is real. Self-hosting means you run and secure the servers, and the reconciliation logic stays yours to own. Setup details are in the Fystack docs.

FAQ