Case Study — Multichain (Anyswap), July 2023

“MPC describes a cryptographic pattern; it does not describe an operational reality. If the M parties are all one human, you have not built a bridge — you have built a custodian with extra steps.” — Auditor’s gloss.

“All operations of Multichain rely on Zhaojun’s servers… When Zhaojun was taken away by the police, the team lost access.” — Multichain official statement on X / Twitter, July 14, 2023, paraphrased from the team’s account. [verify exact wording against archived tweet]

Tags: web3-security case-study bridge cross-chain operator-risk mpc custody key-management insider-risk governance trust-model Course position: Tuan-10-Bridge-Cross-Chain-Security §4.2 (MPC trust model) + §7.6 (Multichain one-pager) — read those first. Related cases: Case-Ronin-Bridge-2022 (validator key compromise — different shape of same family) · Case-Wormhole-2022 (signature-verification bypass on Solana) · Case-Nomad-Bridge-2022 (initialisation hazard) · Case-Poly-Network-2021 (cross-chain dispatcher access control) Vault context: this is the canonical “trust-model mismatch” case. Unlike Nomad (a Solidity bug) or Wormhole (a signature-check bug), there is no on-chain bug to point at. The vulnerability is the gap between what the protocol claimed its trust model was (MPC, decentralised, threshold-signed) and what it actually was (one CEO with sole effective control of operational keys). Pair this with Tuan-04-Threat-Modeling §3 (“trust boundaries are the audit”) and Tuan-10-Bridge-Cross-Chain-Security §4.2.

1. At a glance

Field	Value
Date of “drain”	July 6, 2023 (UTC ~19:00–22:00, primary outflow window)
Date the human failure occurred	Late May 2023 — CEO Zhaojun He detained by Chinese authorities (Shanghai). Operations silently degraded for ~5 weeks before the public outflow [verify exact detention date; reporting varies from May 21 to May 30]
Protocol	Multichain (formerly Anyswap; rebranded December 2021)
Chains affected	Fantom, Moonriver, Dogechain, Kava, Conflux, Polygon, Cronos, and others (≈12 chains reported anomalous outflows). Fantom’s MultichainPool was the largest victim
Loss (primary July 6 event)	~ $126 M -$ 130M USD (varies by source / token mark)
Loss (cumulative through wind-down)	~$200M+ USD when later “anomalous” transfers and the subsequent July 13–14 anyToken contract issues are aggregated [verify exact totals against Chainalysis / Elliptic]
Attack class	Operator key compromise / centralised custody disguised as MPC — not a smart contract vulnerability
On-chain bug exploited	None. The transfers were validly signed under the bridge’s own trust model. There is no Solidity flaw to point at.
Trust-model break	The “MPC” key material was, per the team’s own public statements, under the operational control of a single individual (the CEO, Zhaojun He) whose hardware was seized by Chinese law enforcement
Recovered	Effectively none through normal protocol channels; some chains (Fantom, Moonriver) implemented post-hoc recovery flows for canonical assets [verify]
Outcome	Bridge permanently paused July 14, 2023; entity wound down; team announced shutdown of customer services; affiliated firm Fantom Foundation took partial recovery action [verify]
Significance	The clearest “trust-model mismatch” lesson in DeFi history. The bridge did not fail because of code; it failed because the human governance behind the supposedly cryptographic trust model collapsed. This is the case auditors cite when they say “`MPC’ on the marketing page is not a finding I can rely on.”

The whole case in one line: a “decentralised MPC bridge” turned out to be a single individual’s keys on his own servers, and when that individual was unavailable, the protocol was indistinguishable from a custodial wallet whose custodian had vanished.

2. Background — what Multichain was, and what it claimed to be

2.1 From Anyswap to Multichain

Multichain’s lineage is important because the rebrand is part of the deception (whether intentional or not).

Phase	Dates	Identity
Anyswap launch	July 2020	Cross-chain DEX-and-bridge using Fusion Network’s DCRM (Distributed Control Rights Management) — a multi-party threshold-signature scheme. Built by a small Chinese / Singapore team, with Fusion Network as a technical sponsor.
Anyswap V2 / multi-chain expansion	2021	Expanded to ~20 chains. Token bridge (`anyToken`) and router (`AnyswapV6Router`) contracts became dominant cross-chain plumbing.
Rebrand to Multichain	December 2021	”Universal cross-chain router”. Funding rounds with Binance Labs, Sequoia China, IDG, etc. Reported $7.9 M s t r a t e g i cro u n d a t a$ 1.2B valuation.
Operational peak	2022	TVL ~$10B at peak; supported >80 chains; the most-used bridge by transaction count for much of 2022. The “Multichain bridge” was the default cross-chain rail for many smaller EVM chains (Fantom, Moonriver, Cronos, Dogechain, etc.) without competing canonical bridges.
Quiet decline	Q1 2023	TVL bleed; ongoing user-support friction; team communication degraded.
The break	May–July 2023	CEO detained; bridge halted; eventual drain; wind-down announced July 14, 2023.

2.2 The claimed trust model

Multichain’s public messaging from 2021–2023 (white paper, blog, dev docs, conference talks) consistently described the bridge as:

MPC-secured — Threshold Signature Scheme (TSS); a key is generated as a set of shares; M-of-N nodes co-sign without ever reconstructing the full private key.
Decentralised operator set — nodes run by “SMPC network” operators, distributed across jurisdictions and entities.
Non-custodial — no single party can sign on behalf of the bridge; the M-of-N threshold makes unilateral asset movement impossible.
Audited — third-party audits of the on-chain contracts (router, anyToken) by reputable firms.

In auditor-speak, the trust model presented to users and integrators was: “to drain this bridge, you must compromise M independent operators across jurisdictions; no single point of failure exists.”

2.3 The actual operational reality (as revealed)

After the July 6, 2023 drain, Multichain’s own team issued a public statement (Twitter/X, July 14, 2023) acknowledging — in markedly different language from years of prior messaging — that:

The CEO, Zhaojun He, was the sole party with operational control of the MPC servers.
The MPC nodes were physically running on infrastructure controlled by him.
When Zhaojun was detained by Chinese police (late May 2023, location: Shanghai), the team lost access to those servers and key shares.
The team had been operating in a degraded state — using router maintenance privileges, manual interventions — to keep service running for several weeks without their CEO.
The July 6 outflows were not authorised by the team; the team itself was watching the chains drain.

The follow-up reporting (Chainalysis, Elliptic, on-chain forensics threads on Twitter from researchers including PeckShield, Beosin, and 0xfoobar-style independents) added that funds moved into addresses never previously associated with Multichain operations, then began consolidating through CEX deposit patterns suggesting either (a) an adversary who obtained the seized keys, or (b) someone within the founder’s circle attempting “asset preservation” — Multichain’s later statements referenced the CEO’s sister retrieving some funds; this narrative is contested. [verify primary source for sister-led “asset preservation” claim against Chainalysis/Elliptic write-ups]

Auditor’s frame: there are two competing narratives for the July 6 transfers — external adversary with seized keys vs internal “preservation” by family. Both narratives confirm the same root cause: a single individual’s control of the cryptographic material was the protocol’s only real security boundary. Whichever explanation is correct, the lesson is identical.

2.4 Why “MPC” was a verbal-only property

A clean MPC deployment has these properties — observable, in principle, to an external auditor:

Key generation ceremony with multiple independent parties, attested cryptographically, ideally with public artefacts (commitments, transcripts).
Key shares physically distributed across non-colocated hardware controlled by distinct legal entities under distinct jurisdictions.
Threshold signing triggered by independent quorum logic where the quorum is verifiable (logs, telemetry, sometimes on-chain “signers proof”).
Operator independence proofs — different humans (verifiable on LinkedIn or corporate filings), different infrastructure providers, different OSes, different cloud regions.
Recovery / share-rotation procedure runnable by N-of-N or N-1-of-N without any single individual being in the critical path.

Multichain advertised (1)–(4) verbally but, per their own July 2023 statements and subsequent reporting, none of (1)–(5) was operationally true. The MPC architecture was a configuration running on Zhaojun’s machines, with no genuine distribution, no shared ceremony with independent parties, and no recovery without him.

This is the “MPC theatre” anti-pattern: the cryptographic protocol is real, but its parties are not independent. Cryptographic decentralisation requires party decentralisation. Multichain had the former and not the latter.

flowchart LR
    subgraph Claimed["Multichain — Claimed Trust Model"]
        N1[Node 1<br>Entity A · jurisdiction X]
        N2[Node 2<br>Entity B · jurisdiction Y]
        N3[Node 3<br>Entity C · jurisdiction Z]
        N4[Node 4<br>Entity D · jurisdiction W]
        N1 -- "M-of-N TSS" --> Bridge["Multichain Router<br>on each chain"]
        N2 --> Bridge
        N3 --> Bridge
        N4 --> Bridge
    end

    subgraph Actual["Multichain — Actual Trust Model"]
        Z[Zhaojun He<br>CEO · Shanghai]
        Z -- "controls all infra" --> S1[Server 1<br>his data centre]
        Z --> S2[Server 2<br>his data centre]
        Z --> S3[Server 3<br>his data centre]
        S1 -- "MPC shares all here" --> ABridge["Multichain Router<br>on each chain"]
        S2 --> ABridge
        S3 --> ABridge
    end

    style Bridge fill:#cce5ff
    style ABridge fill:#f8cecc
    style Z fill:#f8cecc

3. The vulnerability — the trust-model mismatch is the vulnerability

3.1 There is no Solidity bug

Pause here, because this is the most important sentence in the case study and the most counter-intuitive for code-first auditors:

The Multichain contracts did not have a bug. The vulnerability was that the contracts’ authorisation gate — a single MPC-derived signature — was controlled by a single human, contradicting the protocol’s claimed trust model.

If you grep for an exploit primitive in AnyswapV6Router.sol, you will not find one. The anySwapIn and anySwapOut functions are gated by an mpc address that the contract treats as a privileged signer:

// AnyswapV6Router.sol — simplified shape
contract AnyswapV6Router {
    address public mpc;
 
    modifier onlyMPC() {
        require(msg.sender == mpc, "AnyswapV6Router: FORBIDDEN");
        _;
    }
 
    // Outbound: user locks/burns; off-chain MPC observes and mints on dest.
    function anySwapOutUnderlying(address token, address to, uint256 amount, uint256 toChainID) external {
        IUnderlying(token).deposit(amount, msg.sender);
        emit LogAnySwapOut(token, msg.sender, to, amount, block.chainid, toChainID);
    }
 
    // Inbound: MPC submits a previously-locked transfer; tokens are released.
    function anySwapIn(
        bytes32 txs,
        address token,
        address to,
        uint256 amount,
        uint256 fromChainID
    ) external onlyMPC {
        // ... checks for replay (txs hash) and chain id ...
        IRouterMintBurn(token).mint(to, amount);
        emit LogAnySwapIn(txs, token, to, amount, fromChainID, block.chainid);
    }
 
    function changeMPC(address newMPC) external onlyMPC {
        mpc = newMPC;
        emit LogChangeMPC(mpc, newMPC, block.chainid);
    }
}

The onlyMPC modifier behaves exactly as designed. Whatever party owns the mpc address can:

Mint wrapped tokens on the destination chain (anySwapIn).
Drain liquidity-pool-style routers via authorised transfers.
Rotate the MPC address itself (changeMPC).

If the cryptographic discipline holds, that address is only ever signed by a 5-of-7 (or whatever the threshold) of independent operators. If the cryptographic discipline collapses — because the operators were always one person — that address is signed by whoever holds the seized hardware.

3.2 The “exploit” as a single sentence

Someone in possession of the MPC signing material (whether the CEO, the seizing authorities, an insider acting on his behalf, or an external adversary who obtained the material) produced valid MPC signatures and submitted normal-looking anySwapIn transactions that released tokens to non-Multichain recipient addresses.

There is nothing more technically interesting than that. The process() function did what it always did. The bridge cleared the transfers because, from its perspective, they were legitimate.

3.3 Anatomy of the “vulnerability” as auditors must learn to describe it

For an audit report, “the CEO was arrested” is not a vulnerability statement an engineering team can act on. Translate it into the deliverable shape:

Finding axis	Multichain statement
Title	Centralised effective control of the privileged MPC role; trust model claimed in documentation is not enforceable by the on-chain code
Severity	Critical — the protocol’s entire asset base is gated by an off-chain process that has no on-chain verification of operator independence
Root cause	The on-chain contract authorises any signature accepted as “MPC”, but cannot verify how many parties signed or which parties they are. The operational layer that produces those signatures is opaque to users and to the contract
Trigger condition	Compromise, coercion, incapacitation, or unilateral decision by the single party controlling MPC infrastructure
Exploitability	100% — no cryptographic break required; standard signing-key custody risk applies
Recommendation	Replace verbal “MPC” with verifiable distribution — hardware-attested signing logs, multi-jurisdiction operator KYC made public, on-chain proof-of-operator-set, ceremony transcripts, periodic share rotation with public ceremony. Until these exist, classify the bridge as a single-signer custodial wallet for risk-modelling purposes

This is the exact pattern: a senior auditor must be willing to write a Critical finding that says “the trust model on the marketing page is not the trust model on chain.” Multichain is the canonical example of why.

4. The attack flow — operational chaos, not a heist

4.1 Phase 1 — pre-incident degradation (March–May 2023)

Most retrospectives focus on July 6, but the operational rot was visible for months if you knew where to look. Public signals that an auditor / due-diligence team should have flagged:

March–April 2023: User complaints (Reddit r/Multichain, Discord) about delayed transfers, stuck withdrawals, and unhelpful support replies became a flood. Transaction throughput on certain anyToken contracts dropped intermittently.
April–May 2023: Routine maintenance posts from official Multichain accounts referenced “node connectivity issues” without explanation. Validators dropped in and out.
May 21–30, 2023 (window): CEO Zhaojun He arrested by Chinese police. [verify exact date; the team’s later July statement gave a vague window and subsequent reporting has converged on late May 2023]. Family / colleagues reportedly did not have access to his hardware, passwords, or share material.
June 2023: Bridge operations continued in a brittle state — the team has admitted using whatever residual access existed. Routes for several chains (Kekchain, Dyno, etc.) were paused without public explanation.

4.2 Phase 2 — the July 6 outflow

The on-chain pattern that researchers documented (PeckShield, BlockSec, on-chain Twitter sleuths) on July 6:

Time (UTC, July 6 2023)	Event (approximate)
~19:00	First anomalous large withdrawal from Fantom MultichainPool to an unrelated EOA — ~$30M+ USDC equivalent
~19:30	Outflows propagate to other anyToken contracts on Fantom; WBTC, WETH, DAI, USDC, LINK, MIM, FRAX moved out
~20:00	Outflows begin on Moonriver, Dogechain, Kava, Conflux
~22:00	Aggregate primary-event loss reaches ~$126M; outflows stabilise
Hours later	Some recipient addresses begin consolidating to new wallets; some bridge to other chains; some sit untouched

The destination addresses did not match historical Multichain operations addresses, did not match any known whitehat patterns, and (per Chainalysis) were freshly funded with small amounts of native gas before the large transfers — consistent with newly provisioned addresses for an unusual operation, but consistent with both “thief preparing” and “team performing emergency move”.

4.3 Phase 3 — the team’s silence and statement

July 6: No official communication from Multichain for several hours. Community discovered the outflows.
July 7–9: Multichain’s official Twitter posted vague messages about “investigating anomalous transactions.” Bridge front-ends started rejecting some transfers; many remained live.
July 13–14: A second wave of “anomalous” transactions hit anyToken contracts on Polygon and other chains; aggregate loss climbs.
July 14: Multichain posts the now-infamous statement on X / Twitter announcing that:
- The CEO (Zhaojun) has been “taken away by the police” since May.
- All “operation and runtime servers” are accessed via Zhaojun.
- The team has been unable to contact him or access these servers.
- The team is announcing shutdown of all services.
- Users should not deposit any further assets.

This is the moment the trust-model mismatch was finally made public — by the protocol itself, in a statement that, in retrospect, contradicted years of marketing.

4.4 Phase 4 — the “sister narrative” and continuing reporting

In subsequent weeks, additional statements (some from accounts affiliated with the founder’s family, some from law-enforcement sources cited in Chinese-language press) indicated that the founder’s sister had also been detained, and that some funds had been moved “for asset preservation” before her detention as well. The provenance of these claims is mixed; treat with caution. [verify Chainalysis “Multichain Exploit July 2023” blog post for the consolidated forensic timeline]

Whatever the true narrative, the on-chain economics ended the same way:

Multichain ceased operations.
Affiliated chains (Fantom Foundation, Moonbeam Foundation) issued statements distancing themselves; some pursued recovery flows for canonical-asset users where they could.
Significant funds remain unaccounted for in adversary-controlled addresses [verify current status].
The Multichain front-ends went offline; the routers on most chains became “do not use” with team-pushed warnings.

5. “Reproduction” — what to model in a lab, since there’s no on-chain exploit

5.1 Why traditional Foundry-style reproduction is the wrong frame

You cannot write a forge test that proves Multichain “exploitable” because the contract does what it is supposed to do given the assumption “the mpc address signs honestly.” To reproduce the actual case, you must model the off-chain operator system, not the contract.

5.2 What to reproduce instead — a tabletop exercise

The pedagogical “lab” for this case is a tabletop trust-model decomposition. Run this exercise on every bridge you audit. The deliverable is a written artefact, not a PoC.

Step 1 — Enumerate the privileged on-chain roles. For Multichain-shape contracts, this is straightforward:

Roles in AnyswapV6Router (per-chain instance):
  - mpc                : currently set MPC signer address
  - vault              : token-vault permissions where applicable
  - admin              : router admin (parameter changes)

Step 2 — For each role, draw the off-chain dependency graph. For the mpc role, ask:

Who, as humans named on paper, is in the threshold quorum?
Who, as legal entities, are those humans associated with?
Who, as infrastructure operators, hosts the signing nodes?
Who, as administrators of those hosts, can interfere with the signing process?

For Multichain, the answer at every layer collapses to one person: Zhaojun He.

Step 3 — Stress-test scenarios.

Scenario	Trust model claim	Reality?
One signer hardware fails	Other M-1 still sign; rotate share with N-of-N ceremony	All shares on his servers; one host failure could cascade
One signer is incapacitated	M-1 still meet threshold; ceremony to add new signer	Operations halt entirely; this is exactly what happened in May 2023
One signer is coerced / law-enforcement seizure	Cannot produce threshold alone	Seizure of his hardware gives access to the entire key material
One signer turns rogue and signs unilaterally	Cannot meet threshold alone	If the M signers are one person, “unilateral” is meaningless — every signature is unilateral

When all scenarios converge to a single human, you have a custodian, not a bridge.

Step 4 — Write up.

Produce a one-pager that includes:

Diagram of on-chain roles ↔ off-chain operators ↔ legal entities.
Per-role risk: what does compromise of this role do?
Per-operator independence proof: what evidence exists, in public, that the parties are distinct?
Failure-mode table: what happens if N-M parties are unavailable? Coerced? Compromised?

A clean version of this artefact for Multichain in mid-2022 — had any auditor produced it and published it — would have shown the case before it happened.

5.3 The minimal Solidity sketch — for risk-modelling clarity

To anchor the concept in code for your notes, here is the abstracted shape of the trust-model risk. This is not a “reproduction of the exploit”; it is a faithful sketch of what the contract enforces vs what users believed:

// src/CentralisedBridge.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
 
/// @title  CentralisedBridge — what Multichain's router actually was, structurally.
/// @notice This contract is the minimal honest expression of a Multichain-shape
///         trust model. It calls itself "MPC" but is enforced as a single signer.
contract CentralisedBridge {
 
    /// @dev The single address treated as the "MPC threshold signer". The contract
    ///      cannot distinguish "1 signer" from "M-of-N threshold-signed result".
    address public mpc;
    mapping(bytes32 => bool) public processedTx;
 
    event Deposited(address indexed token, address indexed from, address indexed to, uint256 amount, uint256 toChainID);
    event Released(bytes32 indexed txHash, address indexed token, address indexed to, uint256 amount);
    event MPCRotated(address indexed oldMPC, address indexed newMPC);
 
    modifier onlyMPC() {
        require(msg.sender == mpc, "BRIDGE: only MPC");
        _;
    }
 
    constructor(address _mpc) {
        require(_mpc != address(0), "BRIDGE: zero mpc");
        mpc = _mpc;
    }
 
    function deposit(address token, address to, uint256 amount, uint256 toChainID) external {
        // user locks/burns; off-chain operator observes and credits on dest chain
        IERC20(token).transferFrom(msg.sender, address(this), amount);
        emit Deposited(token, msg.sender, to, amount, toChainID);
    }
 
    function release(
        bytes32 txHash,
        address token,
        address to,
        uint256 amount
    ) external onlyMPC {
        require(!processedTx[txHash], "BRIDGE: replay");
        processedTx[txHash] = true;
        IERC20(token).transfer(to, amount);
        emit Released(txHash, token, to, amount);
    }
 
    function rotateMPC(address newMPC) external onlyMPC {
        require(newMPC != address(0), "BRIDGE: zero new mpc");
        emit MPCRotated(mpc, newMPC);
        mpc = newMPC;
    }
}
 
interface IERC20 {
    function transferFrom(address, address, uint256) external returns (bool);
    function transfer(address, uint256) external returns (bool);
}

Note for your notes: mpc here is an EVM address. The contract cannot tell whether this address’s msg.sender came from a threshold signature, a multisig wallet, an EOA, a smart-contract wallet, or a hardware wallet sitting on someone’s desk in Shanghai. On-chain authorisation is identity-of-address-only. Everything else is verbal claim.

5.4 The teaching exercise — write the audit report Multichain never got

As homework, write a 2-page trust-model finding for Multichain dated January 2022 (when TVL was ~$8B and the rebrand was fresh). You have access to:

The on-chain code.
The public marketing.
The team’s LinkedIn / Twitter footprints.
The set of node operators (or non-set) named publicly.

Your finding should be:

CRITICAL — Operator independence not verifiable; trust model not enforceable on-chain.

The Multichain protocol authorises asset release through a privileged role denoted mpc (AnyswapV6Router.anySwapIn and family). The protocol’s public materials describe this role as backed by a threshold signature scheme operated by a distributed set of independent parties. However, no public artefact (key-generation ceremony attestation, operator identity disclosure, infrastructure attestation, on-chain proof-of-quorum) substantiates the independence claim. Our review of the team’s public footprint found that named cryptographic operations are attributed to a single individual (CEO Zhaojun He, prior Anyswap signer-of-record); no other named individuals have public attestation as signing-share custodians. The on-chain code cannot distinguish a true M-of-N threshold-signed transaction from a transaction signed by a single party impersonating the threshold output. We recommend the protocol publish (a) independent operator identities under public KYC, (b) ceremony transcripts, (c) on-chain signer-set state and rotation logs, (d) infrastructure attestations from third parties (e.g., AWS / GCP enclaves with attestation), before classifying the bridge as anything other than a single-signer custodial wallet for risk-modelling purposes. Until such artefacts exist, every user deposit should be modelled as a deposit into a hot wallet under one operator’s effective control.

This is the finding that would have prevented this case study from needing to exist. No firm produced it publicly. That is the lesson.

6. Aftermath

6.1 Bridge wind-down

July 14, 2023: Multichain announces complete shutdown.
Mid–late July 2023: All Multichain front-ends taken offline; team services discontinued. Per the team’s statement, they could not maintain operations without the CEO’s hardware. Several affected chains issue user warnings.
Through Q3 2023: Fantom Foundation publishes recovery plans for canonical assets they themselves can re-issue (e.g., FTM-side handling of bridge-burnt tokens); Moonbeam, Conflux, Kava, and others follow with chain-specific user-protection paths where they can. [verify recovery program specifics per chain]
Through 2023–2024: Bridge contracts on most chains remain deployed but unused; researchers periodically document residual movements of un-drained funds; some contracts remain compromised and ownerless.

6.2 Forensics

Chainalysis publishes the July 2023 forensic analysis (“Multichain Exploit July 2023”) consolidating on-chain flows and identifying the cluster of destination addresses. [verify URL — see references §9]
Elliptic, TRM Labs, PeckShield, Beosin publish parallel analyses, generally agreeing on the destination-address clustering but diverging on motive attribution.
The founder’s sister narrative — that some transfers were “asset preservation” by Zhaojun’s family — appears in Chinese-language press and in Multichain-affiliated statements but is contested in English-language forensic literature. Treat it as one of two plausible motive narratives, not a conclusion. [verify]

6.3 Law-enforcement context

Chinese authorities’ role in the case is opaque to Western researchers. Public reporting in Chinese-language outlets confirms Zhaojun’s detention but does not detail charges, jurisdiction, or current status. [verify current case status]
No public extradition or U.S. DOJ action analogous to the Nomad case has been documented [verify].
The case sits in the gap between (a) crypto-protocol forensics (which can trace the funds) and (b) Chinese domestic law enforcement (which is the only body that knows what actually happened to the founder and his hardware).

6.4 Industry response

Change	Cause
”MPC theatre” became a recognised anti-pattern	Multichain’s confession that “MPC” was one person’s servers made the term shorthand for operator-independence failures industry-wide. Audit RFPs now routinely ask for proof-of-operator-independence.
Bridge due-diligence frameworks added “single individual / single jurisdiction” checks	DeFiSafety, L2Beat (for bridges), bridge-risk dashboards explicitly score operator decentralisation; Multichain became the cautionary tale.
On-chain proof-of-quorum patterns gained traction	Newer bridges (LayerZero V2 DVNs, Wormhole’s Guardian set publicly enumerated, Hyperlane’s ISM model) prioritise on-chain visibility of the operator set. The lesson is that “off-chain claims” are not auditable.
MPC custody vendors (Fireblocks, Copper, BitGo) drew clear lines	They now distinguish their production-grade MPC (with hardware-attested ceremonies, named legal entities, geographic dispersal) from “MPC-as-marketing-term.” Several vendors published explainers using Multichain as the negative example.
Auditor’s “trust-model section” became a first-class artefact	Top firms (Trail of Bits, OpenZeppelin, Halborn, Spearbit, Code4rena) now expect a “trust model” or “trust boundaries” section in any bridge audit, separate from code findings.

6.5 Broader implication: jurisdictional risk as a smart-contract concern

Multichain forced auditors to consider a class of risk that pure-code reviews never touched:

Single-jurisdiction operator concentration is a smart-contract-equivalent vulnerability when the jurisdiction has unilateral ability to compel infrastructure custody (China, but the principle generalises).
Legal action against a key principal must be modelled as a “key compromise” event — the cryptographic effect is identical whether the keys were stolen, lost, or seized.
The bridge’s threat model must include the failure mode “the founder is unavailable” — for medical, legal, or other reasons. This is now a checklist item on bridge due-diligence frameworks post-Multichain.

7. Lessons — checklist form

7.1 The single most important lesson

“MPC” on the marketing page is not a finding I can rely on. Until I have written down, per operator, who they are, what entity they belong to, what jurisdiction they’re in, what infrastructure they run on, and what recovery process survives any one of them being unavailable — I am modelling this bridge as a single-signer custodial wallet.

Burn this in. The seniority of an auditor on bridges is largely measured by their willingness to write this finding before it becomes a case study.

7.2 Cryptographic decentralisation requires party decentralisation

Has	Requires
Threshold signature scheme (TSS / FROST / GG18 / GG20 / DKLs)	Real party independence: distinct humans, entities, infrastructure
M-of-N quorum logic	Each of the N parties must actually be independent at the operational layer
On-chain check `msg.sender == mpc`	Knowledge that `mpc` is reached only via legitimate quorum, which the contract cannot verify

The contract enforces identity-of-address. The operators must enforce independence-of-party. Multichain conflated the two and got away with it until the operational layer collapsed.

7.3 The auditor’s “where are the keys?” catalogue

When auditing any bridge / custody / cross-chain system, fill out this table for every privileged role. If you can’t fill it out from public information + team interviews, the audit is incomplete.

Role (on-chain)	What it can do	Who holds the key (humans, named)	Legal entity	Jurisdiction	Infra (HSM? cloud enclave? bare metal?)	Rotation policy	Recovery if 1 holder is unavailable	Recovery if N-M holders are unavailable
`mpc` (signing)	release funds, mint wrapped tokens	?	?	?	?	?	?	?
`admin` (params)	change limits, pause	?	?	?	?	?	?	?
`upgrader` (proxy)	replace implementation	?	?	?	?	?	?	?
`pauser` (emergency)	halt operations	?	?	?	?	?	?	?

For Multichain pre-July 2023, every column collapses to “Zhaojun / his company / China / his servers / unclear / no public recovery if he’s unavailable.” That is a Critical finding.

7.4 Trust-model questions to ask every team

Run these questions in every kick-off call for a bridge audit. The team’s answers (or refusal / vagueness) are themselves the finding.

Who, by name, holds each key share?
What entity employs each of those individuals?
Are any two of them in the same chain of command? Same office? Same jurisdiction?
What happens if your CEO / founder is unavailable for 30 days?
What hardware does the signing run on? Who has root access to that hardware?
Is there a key-generation ceremony transcript? Public? Audited?
What is the rotation schedule? When was the last rotation? Was it ever exercised, including the “remove an operator” path?
If law enforcement in any operator’s jurisdiction seizes their hardware, can the protocol continue to operate? Can it release funds with the remaining quorum? Can it rotate that operator out?

Vague answers, “we’ll get back to you”, or “we trust our team” are themselves Critical findings.

7.5 What you would have caught in 60 minutes of public-info review (January 2022)

Imagine you took Multichain on as a paid retainer in January 2022. You spend one hour doing public-information due diligence before touching the code.

Minute	Action	Finding
0–5	Pull the Multichain whitepaper / docs. Search for “MPC”, “operator”, “signer”, “threshold”.	Note: “decentralised MPC” claimed; specific operators not named.
5–15	LinkedIn search “Multichain operator”, “Anyswap operator”, named team members.	Cannot find independent operators publicly attesting to running signing nodes. Only core team.
15–25	Read prior Anyswap audits. Do they cover operator independence or only contract correctness?	Audits are scoped to the contracts only. No firm assessed operator independence.
25–40	Check the on-chain `mpc()` address history for `AnyswapV6Router` on multiple chains. Are the rotation events frequent? Same wallet across chains?	Same shape across chains, infrequent rotation, no public ceremony around any rotation.
40–55	Twitter / Discord forensics: who actually deploys, who actually pushes upgrades, who responds to incidents? Always the same handful of accounts?	Yes — small, tight team. No independent operator presence visible.
55–60	Write up: Critical. Trust model not verifiable from public information; the bridge should be treated as custodial pending operator-independence proof. Audit cannot proceed without team-side disclosure of operator identities and infrastructure.	Find and email the team.

You did not need to read a single line of Solidity to produce this finding. That is the entire point of this case study.

7.6 The optimistic-bridge case (Nomad) vs the MPC-bridge case (Multichain)

It is worth contrasting these two adjacent case studies in your notes, because they fail in opposite ways:

Dimension	Nomad (2022)	Multichain (2023)
Bug surface	On-chain Solidity bug (init-default collision)	None — contracts behave as specified
Trust model claim	”Optimistic, one honest watcher"	"MPC, threshold of independent operators”
Trust model reality	Logically sound if the verifier code is correct (it wasn’t)	Logically sound if operators are independent (they weren’t)
What auditors should catch	Read upgrade calldata; check zero-key paths in mappings	Read team org chart; check operator independence
Tooling for detection	Slither/Mythril/manual code review	OSINT / interviews / KYC of operators / infrastructure attestation
Catastrophic outcome	Public mempool free-for-all	Quiet drain by single party with seized keys
Lesson cluster	”Defaults are part of the threat model"	"Trust models are part of the threat model”

Senior bridge auditors carry both lenses simultaneously. Junior auditors carry only the first. The progression from junior to senior is largely the addition of the second.

7.7 The meta-lesson

Every bridge case study — Poly, Wormhole, Ronin, Nomad, Harmony, Multichain — turns out to be a trust-model finding, not a Solidity-syntax finding. The Multichain version is the purest case: there is no Solidity finding to be made at all. The entire failure is in the gap between the claimed and actual operational layer.

If you finish this case study and walk away thinking “I need a better static-analysis tool”, you have missed the point. What you need is the discipline to write a Critical finding without a code snippet to back it up. That is auditor seniority.

8. What you would have caught — the concrete checklist

Pin this to the wall above your monitor, next to the Nomad checklist.

Multichain was not caught — before or after — by reading Solidity. There was no Solidity to read. It was caught, finally, by the team’s own confession that the trust model was a fiction. The cost was ~$130–200M. The cost of producing the operator-independence audit beforehand would have been a few weeks of OSINT and interview time. The asymmetry — again — is the entire reason you study to be an auditor.

9. References

Primary — Multichain team’s own statements

Multichain official Twitter / X thread, July 14, 2023 — protocol shutdown announcement; first public confession that CEO controlled all operational infrastructure. [verify archived link; original handle was @MultichainOrg, suspended / inactive post-shutdown — check the Wayback Machine and Twitter archival services for the original thread]
Multichain Medium / blog (historical) — prior marketing claims about MPC and operator decentralisation; useful for “what they said vs what they did” comparison. [verify exact URLs; many were taken down or de-indexed after the wind-down]

Forensic and incident analyses

Chainalysis — “Multichain Exploit July 2023” — consolidated forensic analysis. https://www.chainalysis.com/blog/multichain-exploit-july-2023/ [verify URL still resolves]
Elliptic — Multichain incident write-up — flow tracing and address clustering. [verify URL]
TRM Labs — Multichain analysis — operator-key-compromise framing; useful for the “treat as key compromise” lens. [verify URL]
PeckShield — on-chain analysis tweets and follow-up blog, July 6–14, 2023.
Beosin — Multichain incident analysis, July 2023.
REKT — Multichain — REKT — narrative summary with on-chain transaction references. https://rekt.news/multichain-rekt [verify]
The Block — coverage of the July 6 outflow and July 14 shutdown, multiple articles.
Cointelegraph / Decrypt / CoinDesk — coverage of the founder detention narrative and team statements.

Trust-model and bridge-security context

L2Beat — Bridge Risk Framework — explicitly scores operator decentralisation; cites Multichain as cautionary baseline.
DeFiSafety — bridge process-quality reviews — Multichain became an “F” reference post-incident.
Wormhole post-incident blog series — for contrast, Wormhole’s Guardian-set disclosures became more explicit post-Multichain.

Tuan-10-Bridge-Cross-Chain-Security §4.2 — MPC / threshold signatures trust model.
Tuan-10-Bridge-Cross-Chain-Security §7.6 — one-paragraph Multichain summary.
Tuan-10-Bridge-Cross-Chain-Security §11 — trust-model checklists for bridges.
Tuan-04-Threat-Modeling §3 — trust-boundary modelling fundamentals.
Case-Ronin-Bridge-2022 — validator key compromise (different shape, same family).
Case-Nomad-Bridge-2022 — initialisation hazard (opposite-failure-mode contrast in §7.6 above).
Case-Wormhole-2022 — signature verification bypass (yet another bridge failure mode).

Open questions / items to verify

Exact detention date of Zhaojun He: reporting varies (May 21 vs May 30 vs “late May”). The team’s July 14 statement was deliberately vague.
Current legal status of Zhaojun He: unknown to public English-language sources as of last research pass. [verify current Chinese-language press]
“Sister narrative”: provenance and accuracy contested; treat as one of two plausible motive explanations, not a conclusion.
Exact aggregate loss across all incidents (July 6 + July 13–14 + residual): ranges from $126 Mt o$ 200M+ depending on source and token mark. Use ~ $130 M f or t h e p r ima rye v e n t an d$ 200M for the cumulative figure unless a tighter source is available.
Per-chain recovery program outcomes (Fantom, Moonriver, Kava, Conflux, etc.): each chain’s foundation handled the aftermath differently; consolidate per-chain when writing future updates.

Last updated: 2026-05-16 · Course: Web3 Security Mastery · Author: vault owner · Status: complete · Flags: multiple [verify] embedded above for items requiring primary-source confirmation. This case study is deliberately “code-light” because the failure was not in code; it is the canonical trust-model-mismatch teaching example in the course.

lthieu's notes

Explorer

Case-Multichain-2023