Why multisig can still fail at one point: how Ronin's 5 of 9 came together

A 5 of 9 multisig need not mean five independent targets. Ronin’s announcement and later postmortem describe how access to Sky Mavis’s environment gave the attacker enough signatures to forge withdrawals in March 2022. They report five of nine validator private keys as compromised: four at Sky Mavis and one at Axie DAO. The design question is how many signatures become available when one environment fails.

Ronin is the main case, with Harmony Horizon as a shorter comparison. BNB Token Hub illustrates a failure in proof verification. The recommendations ask what an attacker can reach after taking over an environment. Binance 2026 supplies a related observation about signed authorisations, but the public material does not establish its full intrusion path.

Ronin 2022: the attack path and subsequent changes

Ronin’s official X account declared a security breach at 15:29 UTC on 29 March 2022, and the second post in the thread said the Ronin bridge had been exploited for 173,600 Ethereum and 25.5M USDC, and that the bridge and Katana DEX had been halted.

The same day’s “Community Alert: Ronin Validators Compromised” (Wayback snapshot of 29 March 2022, 22:08) sets out the threshold: Ronin had nine validator nodes, five of the nine signatures were needed to recognise a deposit or withdrawal event, and the attacker had managed to get control over Sky Mavis’s four Ronin validators and a third-party validator run by Axie DAO. The breach was discovered on 29 March after a report that a user was unable to withdraw 5k ETH from the bridge. The short-term fix was to raise the validator threshold from five to eight, with the node count still nine. The post also said most of the hacked funds were still in the hacker’s wallet, and gave the address.

“Back to Building: Ronin Security Breach Postmortem” of 27 April (Wayback snapshot of 6 December 2022) adds dates and an entry point. The hack occurred on 23 March 2022 and was discovered on 29 March by the Sky Mavis team, which did not have a proper tracking system for monitoring large outflows from the bridge. Sky Mavis employees faced sustained advanced spear-phishing attacks. After compromising one employee, the attacker used that access to enter the company’s IT infrastructure and reach the validator nodes. The employee had since left Sky Mavis.

The postmortem repeats that five of the nine validator private keys were controlled, four Sky Mavis and one Axie DAO, to forge withdrawals. It reports a loss of signing control without explaining whether private keys were exported.

Six days passed between the attack and its discovery. The Community Alert says a failed 5k ETH withdrawal led a user to report the problem; the postmortem says missing outflow monitoring prevented earlier discovery.

The Community Alert’s main account explains the route to the fifth signature. In November 2021, Sky Mavis asked Axie DAO to help distribute free transactions during heavy user demand. Axie DAO allowlisted Sky Mavis to sign on its behalf. The arrangement ended in December 2021, but the access remained. After entering Sky Mavis’s systems, the attacker used its gas-free RPC node to obtain the Axie DAO validator’s signature.

The immediate response and later expansion were separate measures. The Community Alert reported raising the threshold from five to eight. The postmortem’s expansion section says Sky Mavis had nine validator nodes, whereas the Community Alert assigns nine to the Ronin chain as a whole. The postmortem also says Sky Mavis controlled 4/9 validators, so its expansion wording cannot establish ownership of all nine keys. It reports an increase to 11 nodes, three more being onboarded, a three-month target of 21 and a long-term goal of over 100.

“Securing Ronin” of 5 April said Nansen, Delphi Digital, Stable Node, Animoca Brands and Dialectic were being onboarded to the validator pool, with a three-month goal of at least 21 independent validator nodes collectively securing the network. The announcement does not give the full distribution of control after expansion. Adding 9 and 5 would not establish that 14 nodes were live.

Back to Building expected a mid-to-late May reopening if the work went to plan. The reopening notice, The Ronin Bridge Is Open, is dated 28 June and reports one internal audit and external audits by Verichains and Certik. It specified withdrawal tiers requiring 70% of validator signatures, 90%, or 90% plus human review, with a 7-day review process for the last tier. Its initial daily cap could be reset early by an administrator, and Tier 3 withdrawals were excluded from it. Recommendation 3 gives the amounts and exceptions.

Governors could vote to add or remove validators, upgrade contracts and change thresholds. Each governance vote had to finish before the next began. The notice compared a governor to a cold wallet and a validator to a hot wallet; that analogy does not establish where the keys were stored.

The Ronin docs page Withdrawal limits, last updated on 12 May 2026, uses token quantities rather than the 28 June dollar tiers. It says larger withdrawals need more bridge operator approvals. Tier 3 requires manual review, carries a fee of around 0.001% and is excluded from the daily limit per token. These two rows reproduce the documented quantities:

Token	Daily limit	Tier 1	Tier 2	Tier 3
WETH	4,500	Below 1,000	At least 1,000	At least 4,000
USDC	2,500,000	Below 1,000,000	At least 1,000,000	At least 2,000,000

All values are token amounts. This article has not checked them against on-chain parameters.

The attribution has several sources. The postmortem says the FBI attributed the breach to North Korea-based Lazarus Group and that the Treasury Department sanctioned the address that received the stolen funds. The FBI’s statement of 14 April 2022 says Lazarus Group and APT38 are responsible for the theft of US$620 million in Ethereum reported on 29 March; it does not mention Ronin, Axie or 173,600 ETH.

The Treasury press release of 6 May 2022 says that on 23 March 2022 Lazarus Group carried out a theft worth almost US$620 million from a blockchain project linked to the online game Axie Infinity, and that Blender processed over US$20.5 million of the proceeds; the word Ronin does not appear in its text, and no hexadecimal address is printed.

OFAC’s designation update of 14 April 2022 added the ETH address 0x098B716B8Aaf21512996dC57EB0615e2383E2f96 under LAZARUS GROUP; that is the same address the Community Alert gave for the hacker’s wallet, differing only in letter case, and the OFAC page is a list of identifiers with no narrative of the incident.

The postmortem says Sky Mavis engaged CrowdStrike and Polaris Infosec for internal surveillance and forensics. That is Sky Mavis’s account of the engagement.

Drawing the nine keys as a control graph

Group the nine keys by the environment from which their signatures can be obtained. The announcement describes access through Sky Mavis to four validators’ signing powers and, through the gas-free RPC node and allowlist, to the Axie DAO signature. That made five, enough to meet the threshold. The remaining four validators are outside that described route; the arithmetic does not establish that they were untouched.

The graph represents reachable permissions, not a claim that the nodes shared a host. Its single edge from the employee to the IT infrastructure and validator nodes reflects the detail available in the official account.

The allowlist preserved delegated signing access, making the fifth signature reachable from one environment. The business reason ended in December 2021, but access remained. A useful acceptance check must test both the expiry and whether requests are actually refused afterwards.

A multisig wallet requires at least m valid signatures from a specified set of n keys; m is the threshold in m of n. More keys need not mean more independent organisations. Threshold cryptography can instead distribute one key across n shares, with at least t participating in signing without first reconstructing the full private key. Ronin’s account describes multiple signatures and private keys, so it does not establish the use of secret sharing. A single point of failure is a component whose failure can defeat the system. Here, the concern is a shared dependency that gives an attacker enough signing power.

A shared cause can defeat several redundant components at once. If two components always fail together, adding the second does not reduce the probability of joint failure. The common-mode failure section of the encyclopaedia entry Common cause and special cause (statistics) discusses this idea, but carries an original-research warning and is used here only as background. Applied to multisig, the design check is whether a shared operator or approval path can still supply enough signatures after the threshold rises. Physical separation can reduce shared environmental risks; it does not establish separate access controls.

Separation of duties divides authorisation, custody, record keeping and reconciliation among people. The encyclopaedia entry Separation of duties quotes Botha and Eloff’s 2001 IBM Systems Journal paper, using a cheque requiring two signatures as an example. Only that quotation was checked, not the IBM paper or NIST SP 800-53 AC-5. For a multisig design, the practical question is whether one environment controls enough of those roles to authorise a transfer. That check also applies to the governor and validator roles described by Ronin. NIST’s Multi-Party Threshold Cryptography project page gives the cryptographic context: threshold schemes use MPC to distribute trust in cryptographic operations.

Shared dependencies across chains and services

When one signing system signs for hot wallets on several chains, adding chains need not make the signing controls more independent. Binance 2026 provides a related public observation. Chainalysis wrote on 30 October 2026 that on Ethereum the attacker used an operational wallet funded through Tornado Cash to submit valid signed authorisations that allowed a Binance hot wallet to run attacker-deployed code. That account covers Ethereum; it does not say one signer served several chains, and it does not say how authorisations on other chains were obtained. This observation does not establish that Binance used one shared signer. For checks at the signer, see Once the key is safe, who gets to ask for a signature? Custody lessons from Binance in 2019.

RPC, relayers, signers and monitoring may be separate services yet still expose one another through delegated rights or credentials. Ronin’s account identifies its gas-free RPC node as the route to the fifth signature. For a different failure around signing infrastructure, see Valid signatures, wrong transaction: the Bybit and Safe signing supply chain.

Ronin expanded from 9 nodes to 11, with a target of 21. On 17 August, New Ronin Validators! named Efficient Frontier, Community Gaming and Nansen, taking the reported total to 17. The 9 September Google Cloud Ronin Network Validator notice quoted Sky Mavis co-founder Aleksander Larsen calling Google Cloud the 18th validator. Nansen appeared on the 5 April onboarding list and again as a new validator in August, so the lists cannot simply be added together. These notices do not provide a complete allocation by organisation; the node count alone cannot establish whether isolation improved.

Two short comparisons

Harmony Horizon, June 2022. Harmony’s official forum summary of 3 August 2022 says the perpetrators compromised at least two out of four private keys of the bridge validators, gained control of the bridged assets, and from 11:06:46 UTC on 23 June 2022 began funnelling them into new wallets and eventually into Tornado Cash; Harmony said it had no evidence at that time that the bridge contracts or chain had been breached.

The source says “at least two out of four”; the post does not state the bridge’s threshold parameter as 2 of 4, and the “4 keys, threshold 2” case in the example below is a model parameter, not Horizon’s official setting.

Update #2 of Harmony’s Horizon Bridge Hack, dated 25 June 2022, relayed founder Stephen Tse’s account: Harmony stored the private keys under two layers of encryption, using a passphrase and a key management service, and no single machine could access multiple plaintext keys. This was an interim account. The same update reported a move to 4-of-5 multisig on the Ethereum side after the incident; 4-of-5 therefore does not establish the threshold in force on 23 June. The article promised a full explanation after the investigation. Its last numbered update, #9 of 14 July, described work on reimbursement options that had yet to be presented. The 3 August forum summary still qualified its entry-path account with “we believe” and said the trojan’s capabilities remained under investigation.

The 3 August 2023 Governance Report: HIP-30v2 described a separate recovery-custody proposal. It envisaged a 5-out-of-7 Harmony Gnosis Safe with elected custodians holding newly issued network tokens and making monthly transfers to burn partners for depegged assets. The report was still inviting votes. It does not establish that the arrangement was operating, or that it was a later configuration of the 2022 bridge keys.

BNB Token Hub, October 2022. BNB Chain’s posts describe a forged low-level proof and 2 million BNB effectively minted. That account identifies a proof-verification flaw without describing a compromise of signing authority. The shared dependency examined here is the verification code. BNB Chain’s technology update of 8 November 2022 proposes upgrading IAVL proof verification to ICS23 under BEP171; the two incident posts do not use the term IAVL.

Recommendations with acceptance checks

These are design recommendations drawn from the cases. Adapt the checks to the system being assessed.

Check which signatures can fail together. Label every key with the organisation, infrastructure and identity system whose compromise makes it usable, and include every shared dependency in the compromise scenario. Different label combinations do not by themselves establish independence. Ronin’s four Sky Mavis keys plus one signature reachable from Sky Mavis’s environment were exposed through one environment. Check: treat every environment of any one organisation (hosts, CI, cloud accounts, staff devices) as compromised; count each reachable signing key once, whether reached directly or through delegation; the total must remain below the threshold.
Give every delegation and allowlist an owner and an expiry. Ronin set up its allowlist in November 2021 to distribute free transactions. The arrangement ended in December, but the access was not revoked before the breach. Check: list every “A may sign for B” edge with its business reason and expiry; after the business stops, send a request and it must be refused.
Require independent additional approval for large withdrawals. The postmortem said withdrawals at that scale would require human intervention after the new bridge was deployed. It also planned a validator dashboard for approving large transactions and adding or removing validators, without giving an approval amount in the 27 April post. The 28 June notice, The Ronin Bridge Is Open, supplied the tiers: Tier 1 required signatures from 70% of validators; Tier 2, at or above US$1 million, required 90%; Tier 3, at or above US$10 million, required 90% plus human review, with a 7-day review process. The initial daily limit was US$50 million, resetting at 00:00 UTC. An administrator could reset it early if it was exhausted, so withdrawals in one day could exceed US$50 million. Tier 3 withdrawals were excluded from the daily limit because they already required administrative action. The notice also described a circuit-breaker to halt suspicious large withdrawals. The later token-quantity tiers are set out above. Check: a threshold’s worth of signing keys must not allow withdrawals above the configured cap without independent human approval. Test every exception, including early resets and tiers excluded from the cap. A compromised signing environment must not also be able to grant the extra approval, reset the cap or change tiers to bypass it. For caps and the failure direction of a kill switch, see the post on Treat Unset as Zero: Hard Caps, Approval Thresholds and Which Way a Kill Switch Fails.
Monitor large outflows from outside the signers’ environment. Ronin had no large-outflow monitoring, and the breach surfaced six days later through a user report. Check: simulate a withdrawal above the alert threshold; the alert must reach someone outside the signing environment within the agreed time, and compromising the signing environment must not be able to silence it.
Count controllers before adding nodes. Ronin went from 9 to 11 with a target of 21, and the official texts do not say how many keys each organisation holds. Check each organisation in turn: compromising it must yield fewer signatures than the threshold, while excluding it must still leave enough signatures for legitimate operation.
Verification logic can also be a single point. BNB’s account of the 2 million BNB describes a forged-proof attack. Check: assume the proof verification library is bypassed; a separately enforced minting or withdrawal cap must still bound the loss. It must not fail through the same path as proof verification.
When several chains share a signer, each chain gets its own policy and cap. This is a design scenario for a shared signer. The cited Ethereum observation does not establish it as the cause of the Binance incident. Check: the signer’s ability to issue an authorisation on one chain must not extend to unlimited transfers on another.

Example: counting what a compromise reaches

The count_controllers.py below illustrates part of check number 1. Label each key with its holding environment, add the delegation edges, then supply the compromised environments. The function counts the reachable signatures and compares that count with the threshold. It is a model for comparing control arrangements, not an account of how Ronin, Harmony or any other chain stores keys.

It follows direct key access and single-step delegation only. It does not follow chains of delegated access or check whether signing remains possible after an organisation is excluded. A real acceptance test needs those cases too.

# A control-graph model for threshold signing.
# Every key is labelled with the environment that holds it. A separate set of
# "delegation edges" says: once environment X is compromised, the signature of
# key Y is obtainable even though Y lives elsewhere.
# Input: the set of compromised environments. Output: reachable signatures and
# whether the threshold is met.
# This is a model only. It shows that "count keys" and "count controllers" give
# different answers. It does not describe how Ronin, Harmony or any chain
# actually stores keys.

from dataclasses import dataclass, field

@dataclass(frozen=True)
class Scheme:
    threshold: int
    keys: dict[str, str]                      # key -> holding environment
    delegations: frozenset[tuple[str, str]] = field(default_factory=frozenset)
    # (environment, key): that environment can obtain this key's signature

def reachable(scheme: Scheme, compromised: set[str]) -> set[str]:
    direct = {k for k, env in scheme.keys.items() if env in compromised}
    delegated = {k for env, k in scheme.delegations if env in compromised}
    return direct | delegated

def report(name: str, scheme: Scheme, compromised: set[str]) -> None:
    got = reachable(scheme, compromised)
    verdict = "threshold met" if len(got) >= scheme.threshold else "not met"
    print(f"{name}: compromised {sorted(compromised)} -> reachable {len(got)} / threshold {scheme.threshold}, {verdict}")

# Case 1: 9 keys, threshold 5. Company A holds 4, organisation B holds 1,
# the other 4 belong to four more organisations. B's key also has an
# unrevoked delegation edge that lets A's environment obtain its signature.
keys9 = {f"a{i}": "A" for i in range(1, 5)}
keys9["b1"] = "B"
keys9.update({"c1": "C", "d1": "D", "e1": "E", "f1": "F"})
case1 = Scheme(5, keys9, frozenset({("A", "b1")}))
report("case 1 delegation not revoked", case1, {"A"})

# Case 2: same layout, delegation revoked.
case2 = Scheme(5, keys9)
report("case 2 delegation revoked", case2, {"A"})

# Case 3: 11 keys, threshold 6, delegation revoked, but the 2 new keys also
# sit in A's environment.
keys11_same = dict(keys9, a5="A", a6="A")
case3 = Scheme(6, keys11_same)
report("case 3 more nodes, same environment", case3, {"A"})

# Case 4: 11 keys, threshold 6, the 2 new keys go to new organisations G and H.
keys11_split = dict(keys9, g1="G", h1="H")
case4 = Scheme(6, keys11_split)
report("case 4 more nodes, new organisations", case4, {"A"})

# Case 5: 4 keys, threshold 2, two of them in one environment. These are model
# parameters, not the published threshold of any bridge.
case5 = Scheme(2, {"p1": "P", "p2": "P", "q1": "Q", "r1": "R"})
report("case 5 four keys, two share an environment", case5, {"P"})

# Acceptance usage: run once per environment; every line must read "not met".
print("---")
for env in sorted(set(case4.keys.values())):
    report("case 4 per-environment check", case4, {env})

case 1 delegation not revoked: compromised ['A'] -> reachable 5 / threshold 5, threshold met
case 2 delegation revoked: compromised ['A'] -> reachable 4 / threshold 5, not met
case 3 more nodes, same environment: compromised ['A'] -> reachable 6 / threshold 6, threshold met
case 4 more nodes, new organisations: compromised ['A'] -> reachable 4 / threshold 6, not met
case 5 four keys, two share an environment: compromised ['P'] -> reachable 2 / threshold 2, threshold met
---
case 4 per-environment check: compromised ['A'] -> reachable 4 / threshold 6, not met
case 4 per-environment check: compromised ['B'] -> reachable 1 / threshold 6, not met
case 4 per-environment check: compromised ['C'] -> reachable 1 / threshold 6, not met
case 4 per-environment check: compromised ['D'] -> reachable 1 / threshold 6, not met
case 4 per-environment check: compromised ['E'] -> reachable 1 / threshold 6, not met
case 4 per-environment check: compromised ['F'] -> reachable 1 / threshold 6, not met
case 4 per-environment check: compromised ['G'] -> reachable 1 / threshold 6, not met
case 4 per-environment check: compromised ['H'] -> reachable 1 / threshold 6, not met

Cases 1 and 2 differ by one delegation edge; removing it leaves the attacker below the threshold. Case 3 raises the threshold to 6 and the key count to 11, but the two new keys sit in the same environment, so compromising that environment is still enough. Case 4 keeps 11 keys and a threshold of 6 but places the new keys at new organisations, leaving each environment below the threshold in this model. Case 5 has four keys, two in one environment, and a threshold of 2: that environment alone is sufficient. The last eight lines test each environment separately. Every line must read “not met” to pass this check.

Still unclear

How the attacker controlled four keys after entering Sky Mavis’s IT infrastructure, including whether any private keys were exported. The official accounts do not explain this, and the retained forensic firms’ full reports have not been verified.
The exact mechanism behind the fifth signature. The Community Alert’s body describes delegated signing; its Q&A says the Axie DAO validator was allowlisted in November 2021 and its IP remained listed after the arrangement ended in December 2021. Another answer describes five private keys as hacked, four Sky Mavis and one Axie DAO. The document does not reconcile these three descriptions, so it cannot establish that the private key was copied.
The 28 June 2022 post, The Ronin Bridge Is Open, has been read in full. It places the outflow of 173,600 ETH and 25.5M USDC “on March 29, 2022”, which is that reopening notice’s own dating. This article still takes 23 March as the attack date from the Community Alert and from Back to Building, and 29 March as the discovery date from those same two posts. The reopening notice states neither the validator total on the day the bridge reopened nor how many each organisation held. Those two figures remain unchecked.
The distribution of controllers across Ronin’s 11 validators and the target of 21. The 5 April post names five organisations being onboarded and gives no per-organisation count. The total of 17 in the 17 August New Ronin Validators! notice, and the 18th validator in the 9 September Google Cloud Ronin Network Validator notice, likewise come without a per-organisation count.
Harmony’s proposed entry path. Its 3 August 2022 summary says it believed phishing led a developer to install malware, giving access to chat threads or private bridge infrastructure code and a server backdoor. A trojan from 17 June remained under investigation; server logs from 2 June were insufficient on their own to explain the compromise. A later forensic conclusion has not been verified. A search of Harmony’s blog and forum did not establish a later official forensic account confirming the full intrusion path. That does not show that no such report exists.
How the Binance 2026 signing authorisations were obtained. Binance’s Security Incident | Recovery Update #5 of 2 November 2026 covers verification of the 31 October proof-of-reserves snapshot, replenishment and withdrawal progress, and it does not set out signing authorisations, hot-wallet keys or a root cause. The statement that Binance has yet to publish a root cause is TRM’s. TRM dates the page 29 October 2026, and its figures run to 30 October 2026 at 00:30 UTC. This review has not verified an official report that fully explains how the authorisations were acquired.
Axie Infinity’s user numbers and the bridge’s scale. Contemporaneous official figures remain unverified.
Numen’s IAVL analysis of the BNB incident describes its work as unfinished. The case discussion relies on BNB Chain’s own account of a forged proof.

A later post will look at what an exchange should publish so that outsiders can keep checking assets, liabilities and the ability to deliver.

Notes

Ronin’s 5 of 9 was assembled from one company’s four keys plus a fifth signature reachable from that same environment. A threshold has to count the signatures one compromised environment can reach; counting keys or nodes alone is not enough.
A delegation needs an expiry, and the permission must stop when the business reason does.
Six days passed before discovery. The official accounts describe a user report and missing large-outflow monitoring; this post recommends monitoring outside the signers’ environment.
The June reopening notice set a daily cap alongside its withdrawal tiers, with exceptions: an administrator could reset the cap, and Tier 3 was excluded. Acceptance checks must test those exceptions and ensure a compromised signing environment cannot use them to bypass approval.
Harmony’s account says at least two of four private keys were compromised, and the Ethereum side was later set to 4-of-5; the threshold parameter at the time is not stated. BNB’s account describes a forged proof.
Acceptance starts from “this environment is wholly compromised” and runs once per environment.