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.
  • 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:
    1. 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.
    2. 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.
    3. On 2023-07-06, unauthorized transactions began moving locked assets out of Multichain MPC-controlled custody into unknown EOAs.
    4. Public traces highlighted at least six major recipient addresses, including 0x9d5765ae1c95c21d4cc3b1d5bba71bad3b012b68, 0xefeef8e968a0db92781ac7b3b7c821909ef10c88, 0x418ed2554c010a0c63024d1da3a93b4dc26e5bb7, 0x622e5f32e9ed5318d3a05ee2932fd3e118347ba0, 0x48bead89e696ee93b04913cb0006f35adb844537, and 0x027f1571aca57354223276722dc7b572a5b05cd8.
    5. 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.
    6. 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.
    7. 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 0x1eed63efba5f81d95bfe37d82c8e736b974f477b and 0x6b6314f4f07c974600d872182dcde092c480e57b.
    8. 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-M signer 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 visible route custody is just moving marker in public timeline reconstructions.
    • Large wBTC outflow highlighted by later timeline reporting at 18:33:11 UTC: 0x448f2a6a6c071cdce254937e06305a033538e1aeb9339227d0e59e0458e6185c — about $30M in wBTC leaving 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.7M in DAI, LINK, USDT, and CRV at rekt.news review time
      • 0xefeef8e968a0db92781ac7b3b7c821909ef10c88 — about $30.1M in USDC
      • 0x418ed2554c010a0c63024d1da3a93b4dc26e5bb7 — about $13.4M in wETH
      • 0x622e5f32e9ed5318d3a05ee2932fd3e118347ba0 — about $30.9M in wBTC
      • 0x48bead89e696ee93b04913cb0006f35adb844537 — about $7.5M from Moonriver routes
      • 0x027f1571aca57354223276722dc7b572a5b05cd8 — about $27.7M in USDC
    • Publicly disclosed July 9 “asset preservation” addresses controlled by Zhaojun’s sister per team statement:
      • 0x1eed63efba5f81d95bfe37d82c8e736b974f477b
      • 0x6b6314f4f07c974600d872182dcde092c480e57b
    • Initial abnormal-transfer acknowledgement: X post 1677096839731097600
    • Service-stop announcement: X post 1677180114227056641
    • Operations-cessation / custody-disclosure statement: X post 1679768407628185600
  • 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 nominal SMPC story.
    • 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

  1. 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.
  2. 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 set story before the July 6 drain.
    • The bridge nevertheless kept treating signatures from that environment as money-good route authority.
  3. 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 withdrawals and this route should still be allowed to empty large custody pools right now were 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-secured claim: 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 SMPC story?
  • 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-secured is 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-secured is 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

Control surface