Multichain MPC-Custody Compromise / Unauthorized Bridge Withdrawals (2023-07-06)
- Name: Multichain MPC-custody compromise / unauthorized bridge withdrawals
- Date: 2023-07-06
- Protocol: Multichain
- Chain: multichain bridge custody, with the largest losses on Fantom and Moonriver routes
- Category: bridge verification failure / signer-quorum compromise / MPC custody centralization / operator compromise
- Loss: more than $125M in unauthorized withdrawals on 2023-07-06, with later July custody movements deepening the wider Multichain collapse
- Summary: On 2023-07-06, Multichain’s bridge-controlled custody addresses began sending more than $125M of user-locked assets to unknown EOAs without any corresponding legitimate cross-chain release flow. The biggest losses hit Fantom bridge custody, with additional major withdrawals from Moonriver and Dogechain routes. Public analysis initially framed the event as an MPC-key compromise or insider-controlled drain. Multichain’s own 2023-07-14 operations statement later said CEO Zhaojun had been taken into custody on 2023-05-21, that operational access to MPC node servers and cloud infrastructure ultimately sat under his personal control, and that all computers, phones, hardware wallets, and mnemonic phrases accessible to him had been seized. Whether the July 6 transfers were an outside compromise, an insider event, or unauthorized use of operator-side access after that seizure, the preserved lesson is the same: once control of the bridge’s real MPC custody path was captured, Multichain’s branded trust model collapsed into straightforward unauthorized withdrawals from lockup addresses.
- Trigger / entry point:
- Multichain’s public documentation described the system as a threshold-signature / SMPC bridge where a set of independent nodes collectively signed transactions, no complete key was ever assembled, and threshold sets looked like
(9,15),(15,21), or(21,31)rather than like a small visible multisig. - The same documentation said those nodes were run by “different organisations, institutions and individuals” and presented the result as a decentralized, trustless service.
- The later 2023-07-14 team statement materially undercut that story: operational access keys to MPC-node servers had been revoked, the servers were running under Zhaojun’s personal cloud account, and no other team member could access that account.
- The same statement said all of Zhaojun’s computers, phones, hardware wallets, and mnemonic phrases had been confiscated by authorities, while all operational funds and investor funds had also remained under his control.
- Multichain’s later timeline also said the team was reduced to operating through whatever access still existed on some non-MPC servers, and that even after Zhaojun’s family regained limited cloud access on 2023-06-04 they only allowed engineers physical access to his home computer to fix specific router issues on Router2 and Router5.
- On 2023-07-06, Multichain publicly acknowledged that lockup assets on MPC addresses had been moved to unknown addresses abnormally and recommended users suspend use of the bridge and revoke approvals.
- Multichain’s public documentation described the system as a threshold-signature / SMPC bridge where a set of independent nodes collectively signed transactions, no complete key was ever assembled, and threshold sets looked like
- Root cause:
- Multichain’s effective authenticity boundary lived in operator control over MPC infrastructure and the lockup addresses it governed, not in a publicly inspectable, independently distributed trust model.
- The protocol’s safety depended on continued exclusive control of MPC-server access, cloud accounts, and associated signing environment by a tiny real-world operator set centered on one individual.
- Once that operator-side custody boundary was breached or repurposed, bridge contracts and locked-asset routes behaved like ordinary hot custody: assets moved because the system still treated the controlling party as authentic.
- The most important failure was therefore hidden centralization of bridge authority. The exact actor behind the July 6 transfers remains disputed, but the trust assumption that failed is clear.
- Exploit path:
- Multichain continued operating after 2023-05-21 even though founder-centered custody, cloud access, and operational continuity were already unstable and, by the team’s later account, partly inaccessible to the remaining staff.
- On 2023-05-30 the team had already warned publicly that it could not contact Zhaojun and was facing technical problems on several routes, but the protocol kept running with limited remaining access.
- On 2023-07-06, unauthorized transactions began moving locked assets out of Multichain MPC-controlled custody into unknown EOAs.
- Public traces highlighted at least six major recipient addresses, including
0x9d5765ae1c95c21d4cc3b1d5bba71bad3b012b68,0xefeef8e968a0db92781ac7b3b7c821909ef10c88,0x418ed2554c010a0c63024d1da3a93b4dc26e5bb7,0x622e5f32e9ed5318d3a05ee2932fd3e118347ba0,0x48bead89e696ee93b04913cb0006f35adb844537, and0x027f1571aca57354223276722dc7b572a5b05cd8. - The largest immediate losses came from the Fantom bridge, which lost roughly half its holdings, while Moonriver lost roughly 80% of bridge funds and Dogechain also suffered a substantial drain.
- Multichain halted service on 2023-07-07, warning that bridge transactions would remain stuck on source chains and that there was no confirmed resume time.
- On 2023-07-09, according to the later team statement, Zhaojun’s sister moved remaining user assets from router pools into EOAs she controlled for what the team described as “asset preservation,” specifically
0x1eed63efba5f81d95bfe37d82c8e736b974f477band0x6b6314f4f07c974600d872182dcde092c480e57b. - By 2023-07-14, Multichain said it had lost the remaining access and operational funds needed to continue, lacked access even to the domain account needed to disable
multichain.org, and announced cessation of operations.
- What the attacker needed to be true:
- The bridge’s real authority had to remain concentrated in a small offchain custody and server-access perimeter rather than in a meaningfully independent signer set.
- Control of the MPC environment had to be enough to move user-locked assets directly, without an additional hard onchain guard limiting abnormal withdrawals.
- The protocol had to keep substantial route-level custody on chains such as Fantom and Moonriver.
- Monitoring and incident response had to be slower than the withdrawal sequence, with users and integrators still relying on Multichain routes while the custody situation was already unstable.
- Technical anatomy worth remembering:
- Multichain is a bridge-authenticity failure where the key lesson is not a clever proof-verifier bug, but the gap between decentralization branding and actual operational control.
- The bridge advertised TSS / SMPC threshold security with examples like
(9,15)and(21,31)and emphasized that the complete key was never assembled, yet the later team disclosure described a system whose cloud access, MPC-node administration, hardware-wallet custody, mnemonic recovery material, and even domain-account control were effectively bottlenecked through one founder-centered operator domain. - The June timeline matters because it shows the system had already degraded into a partial-maintenance state before the visible drain: the team said it was surviving on leftover non-MPC-server access, while cloud access to the main MPC environment depended on family-mediated access to one founder-controlled home computer.
- That makes the incident a strong companion to Ronin and Harmony, but with a different flavor: instead of a clearly disclosed
N-of-Msigner compromise, Multichain appears to have had an opaque effective threshold that may already have been functionally one administrative domain. - The July 9-14 follow-on transfers matter because they show how bridge collapses can blur the line between exploit, emergency asset movement, operator seizure, and insolvency; once the real custody boundary is lost, every subsequent movement becomes a governance and trust crisis.
- Fantom’s dependence on Multichain-wrapped assets amplified the blast radius beyond the raw stolen amount, because a bridge-custody failure also destabilized the pricing and usability of non-native assets across an entire ecosystem.
- Representative transactions, addresses, and custody surfaces:
- First publicly tracked abnormal outflow on 2023-07-06 at
16:21:23 UTC:0xde3eed5656263b85d43a89f1d2f6af8fde0d93e49f4642053164d773507323f8— useful as the first visibleroute custody is just movingmarker in public timeline reconstructions. - Large wBTC outflow highlighted by later timeline reporting at
18:33:11 UTC:0x448f2a6a6c071cdce254937e06305a033538e1aeb9339227d0e59e0458e6185c— about$30MinwBTCleaving bridge custody. - Moonriver-route drain marker at
19:46:23 UTC:0xf830239f39ff21b8634e28cf3fea730069982478465ee5c3ba8e8706d0cef50f— useful for showing the incident was not confined to Fantom custody. - Dogechain-route drain marker at
20:05:35 UTC:0x6bbc867004b4c6650f2b55131955075c4109c32138753147eb142fa431cc84c9— useful for showing the same operator-boundary failure cashing out across another route. - Fantom bridge custody highlighted by rekt.news:
0xc564ee9f21ed8a2d8e7e76c085740d5e4c5fafbe - Moonriver bridge custody highlighted by rekt.news:
0x10c6b61dbf44a083aec3780acf769c77be747e23 - Major destination / recipient addresses publicly tracked in the initial drain:
0x9d5765ae1c95c21d4cc3b1d5bba71bad3b012b68— about$16.7Min DAI, LINK, USDT, and CRV at rekt.news review time0xefeef8e968a0db92781ac7b3b7c821909ef10c88— about$30.1Min USDC0x418ed2554c010a0c63024d1da3a93b4dc26e5bb7— about$13.4Min wETH0x622e5f32e9ed5318d3a05ee2932fd3e118347ba0— about$30.9Min wBTC0x48bead89e696ee93b04913cb0006f35adb844537— about$7.5Mfrom Moonriver routes0x027f1571aca57354223276722dc7b572a5b05cd8— about$27.7Min USDC
- Publicly disclosed July 9 “asset preservation” addresses controlled by Zhaojun’s sister per team statement:
0x1eed63efba5f81d95bfe37d82c8e736b974f477b0x6b6314f4f07c974600d872182dcde092c480e57b
- Initial abnormal-transfer acknowledgement: X post
1677096839731097600 - Service-stop announcement: X post
1677180114227056641 - Operations-cessation / custody-disclosure statement: X post
1679768407628185600
- First publicly tracked abnormal outflow on 2023-07-06 at
- Response / mitigation:
- Multichain told users on 2023-07-06 to suspend use of the service and revoke approvals related to Multichain.
- On 2023-07-07 the team said bridge service had stopped and all bridge transactions would remain stuck on source chains.
- Circle and Tether later froze a large share of the stolen stablecoins, limiting the attacker’s ability to exit some positions.
- On 2023-07-14 the team published its extraordinary disclosure about Zhaojun’s detention, the seizure of devices and mnemonic material, loss of access to cloud servers, and the project’s forced cessation of operations.
- That same statement also said the team could not access the domain account needed to redirect or take down
multichain.org, reinforcing how much of the real operating boundary sat outside the nominalSMPCstory. - The incident effectively ended Multichain as a live bridge and left downstream ecosystems, especially Fantom, dealing with depegged bridge assets and route migration.
Pattern tags
- bridge-verification-failure
- signer-quorum-compromise
- operator-boundary-opacity
- Advertised
(9,15)/(15,21)/(21,31)SMPC security could not survive the later disclosure that MPC nodes, cloud administration, recovery material, and even domain control were bottlenecked through one founder-centered operator shell - The bridge kept full route-level custody authority alive after that operator shell had already entered a visibly degraded and partly inaccessible state following Zhaojun’s detention
- Large Fantom-, Moonriver-, and Dogechain-side custody pools remained directly withdrawable once the hidden operator boundary failed, so bridge-authenticity collapse and uncapped balance-sheet release were almost the same event
Three bridge-authority promotions this incident collapsed
-
Multichain could produce route-valid MPC-signed custody actions
- At the weakest layer, the bridge still had an operational path that could emit whatever signatures or custody transactions the routes recognized as authentic.
- That only proved
the bridge can still speak in its own voice, not that the voice remained independently governed or even exclusively controlled by the people users thought were behind it.
-
Those MPC outputs were still being promoted into trustworthy bridge truth even after the real operator boundary had obviously degraded
- By Multichain’s later account, founder detention, seizure of devices and mnemonic material, loss of normal cloud access, and family-mediated access to production machines had already broken the clean
independent SMPC operator setstory before the July 6 drain. - The bridge nevertheless kept treating signatures from that environment as money-good route authority.
- By Multichain’s later account, founder detention, seizure of devices and mnemonic material, loss of normal cloud access, and family-mediated access to production machines had already broken the clean
-
That accepted bridge truth still retained immediate full-route reserve authority
- Once the hidden operator shell was breached, repurposed, or otherwise no longer exclusive, the resulting withdrawals could still move major Fantom-, Moonriver-, and Dogechain-side reserves directly.
This route can still authenticate withdrawalsandthis route should still be allowed to empty large custody pools right nowwere separate promotions, and Multichain collapsed them together.
Why the exploit worked
- Multichain’s public security story focused on threshold cryptography, but the later team statement said the harder control question lived above the math: who owned the cloud account, the MPC node servers, the hardware wallets, the mnemonic phrases, and the residual operational access needed to keep the bridge speaking as custody authority?
- The bridge was already running in an obviously degraded state before the July 6 drain. By the team’s own account, Zhaojun had been unreachable since May 21, the remaining team lacked normal access to the main MPC environment, and some continuity work depended on family-mediated access to his home computer. A healthy bridge should have treated that as a live trust-model downgrade, not as ordinary ops turbulence.
- Once the hidden operator boundary was breached, repurposed, or otherwise no longer exclusive, Multichain’s routes behaved like straightforward hot custody. There was no harder onchain proof layer, no route-local settlement delay, and no meaningful lane cap stopping direct withdrawals from the lockup addresses.
- The incident also worked because too much value sat behind one authenticity surface. Fantom and Moonriver route custody had systemically important balances, so one bridge-operator failure immediately propagated into ecosystem-wide wrapped-asset and liquidity stress.
- The muddled public aftermath is part of the lesson, not a reason to soften it. When an operator can explain only that access, devices, or infrastructure changed hands—but cannot preserve one crisp authority map—users are learning that the real bridge trust boundary was never the one marketed to them.
Detection and audit pivots
- Ask the operator-topology question directly against every
MPC-securedclaim: who controls the cloud tenant, MPC node deployment, hardware wallets, mnemonic recovery material, DNS or domain accounts, and emergency routing rights that sit above the threshold-signature story? - Treat loss of contact with a founder, seizure of operator devices, family-mediated access to production machines, or similar continuity failures as automatic degraded mode for bridge trust. The route should lose release authority before a drain proves why that mattered.
- Reconcile source-side custody, destination-side liabilities, and live route health from systems that do not depend on the same operator shell as the bridge itself. If the same hidden boundary can move funds and report health, the bridge is auditing itself.
- Monitor for direct lockup-address outflows that do not correspond to user-visible bridge exits, and for route-wide anomalies arriving across several custody pools at once. Multichain was not one isolated lane bug; it was a shared custody-boundary failure showing up on multiple routes.
- Review bounded-release policy alongside verifier policy: if one operator-boundary collapse can still empty major route reserves before humans react, then the bridge has not separated authenticity failure from balance-sheet failure.
Failure-prevention checklist
- Maintain a live operator-topology map for every bridge route that includes MPC-node hosting, cloud-account ownership, hardware-wallet and mnemonic custody, recovery workflows, DNS / domain control, and any emergency or maintenance paths above the nominal threshold-signature story.
- Treat custody-continuity failures as bridge-security events, not just operations noise. Loss of contact with a founder, seizure of operator devices, family-mediated access to production machines, or loss of cloud-account control should automatically force route quarantine or full halt until the trust model is rebuilt.
- Remove founder-centered or single-tenant dependencies from the bridge-control plane. No one person should quietly own the cloud account, device set, recovery material, and domain surface that together define bridge authenticity.
- Put route-local blast-radius brakes under custody authority: per-route reserve caps, delayed large withdrawals, slower release lanes for high-value assets, and fast pause controls that still work when the main operator shell is suspect.
- Separate bridge-health reporting and liability reconciliation from the same boundary that can move funds. If the same hidden operator domain can both drain reserves and report
all clear, the bridge is auditing itself. - Rehearse custody-compromise response as a class: pause routes, communicate route-specific backing status, coordinate stablecoin freezes, and publish which operator surfaces are still trusted versus already disputed.
Audit prompts
- Who actually owns the cloud tenants, MPC-node deployment accounts, hardware wallets, mnemonic backups, DNS / domain accounts, and incident-communication channels that sit above the public
SMPCstory? - How many independent organizations would have to cooperate to recover, rehost, or reconstitute MPC signing authority if the primary operator disappears, is detained, or loses device custody?
- What objective condition forces the bridge into degraded mode when operator control becomes uncertain? Is there a hard rule, or does the bridge keep full release authority until humans decide the crisis is bad enough?
- If abnormal direct outflows begin from route custody addresses, what caps, delays, or route-local pauses stop the bridge from losing most reserves before users can exit or issuers can freeze assets?
- Can users or integrators independently verify route solvency and route health from telemetry that does not depend on the same hidden operator shell that controls withdrawals?
- Do public docs still describe the real trust boundary after emergency workarounds, maintenance shortcuts, founder-centered recovery practices, or operational degradation?
Lessons that should already be standard
MPC-securedis not a complete security story. If one founder-centered operator shell still controls hosting, recovery, and maintenance, then the real threshold is that shell.- Founder availability, cloud-account custody, and recovery-material ownership are bridge-security properties, not merely business-continuity details.
- A bridge already in continuity crisis should not keep full custody authority alive. If the team no longer controls or can even fully describe the signer environment, the safe default is route quarantine.
- Hidden operator centralization is doubly dangerous because users price the advertised threshold while the real risk lives somewhere else.
- Bounded release is part of bridge correctness. Even if the custody boundary collapses, one operator failure should not be able to empty route-level reserves at once.
- Domain control and incident-communications control matter because they shape whether users learn the truth quickly enough to respond. If the same hidden boundary controls assets and the public warning surface, the crisis is already deeper than
key compromise.
Why this incident matters
- It is one of the clearest examples of a bridge whose marketed trust model and real authority model diverged sharply.
- It shows that
MPC-securedis not an answer by itself. The real question is who controls the nodes, the cloud accounts, the operational access keys, and the recovery material. - It is also a strong degraded-mode lesson, not only a hidden-centralization lesson: by the team’s own later description, Multichain was already operating after its real verifier / custody boundary had materially deteriorated, yet the bridge kept behaving as though full custody trust still existed.
- It is also a strong bounded-release failure companion: once Multichain’s real operator boundary collapsed, large Fantom-, Moonriver-, and Dogechain-side custody pools were still directly spendable, with no route-local cap or slower settlement rail meaningfully containing the July 6 outflows before users were told to halt usage.
- It widens the bridge-incident corpus beyond neat exploit categories. A bridge can catastrophically fail through hidden custody centralization even when the public never gets a clean attacker-by-attacker postmortem.
Internal linkages
- Core recurring patterns: bridge-verification-failure, signer-quorum-compromise, and operator-boundary-opacity.
- Positive-design companions: operator-topology-map-and-effective-threshold-discipline, operator-continuity-loss-as-immediate-authority-degradation, bridge-verifier-independence-inventory-and-degraded-mode-discipline, and bridge-bounded-release-design — the first is the sharper
how did an advertised SMPC threshold collapse into founder-centered cloud, device, and recovery authority?companion, the second is the sharperwhy should founder detention, seized devices, and family-mediated access already have downgraded route authority before the visible drain?companion, the third is the sharperwhy did the route keep full trust after that operator boundary had already degraded?companion, and the fourth is the bounded-loss question once bridge truth is captured. - Closest companion incidents: ronin-bridge-validator-quorum-compromise-2022-03-23, harmony-horizon-bridge-multisig-compromise-2022-06-23, and orbit-chain-ethereum-vault-operator-compromise-2023-12-31.
Control surface
-
The leverage sat in Multichain’s MPC-server access, cloud-account ownership, operator custody over devices and mnemonic material, and the lockup addresses those systems could move.
-
The fatal question was not whether the bridge used threshold signatures in theory or even whether its published threshold examples looked large on paper. It was whether enough genuinely independent people and systems had to agree before custody moved in practice.
-
The loss size was a second design failure layered on top of the authenticity failure: once the effective operator threshold collapsed, very large route-level custody remained immediately withdrawable instead of living behind tighter lane caps, staged release, or another blast-radius brake.
-
Multichain’s collapse is a reminder that hidden operator topology can be more important than visible contract architecture.
-
Sources:
- https://docs.multichain.org/getting-started/how-it-works
- https://twitter.com/MultichainOrg/status/1677096839731097600
- https://twitter.com/MultichainOrg/status/1677180114227056641
- https://twitter.com/MultichainOrg/status/1679768407628185600
- https://www.chainalysis.com/blog/multichain-exploit-july-2023/
- https://dn.institute/research/cyberattacks/incidents/2023-07-06-multichain/
- https://rekt.news/multichain-rekt2
- https://rekt.news/multichain-r3kt
- https://www.certik.com/blog/multichain-collapse-the-private-key-leak-that-drained-usd125m
-
Last reviewed: 2026-08-01 UTC