Four Signatures, Zero Oversight: MegaETH's Pre-Deposit Unravels Into a $500M Scramble

On November 25, 2025, MegaETH — a Layer 2 network backed by Ethereum co-founders Vitalik Buterin and Joe Lubin's MegaLabs, which had just closed a $450 million token sale and carried audits from Zellic and SlowMist — opened a pre-deposit campaign that spiraled into hours of confusion, ending with roughly $500 million stuck in a contract nobody had planned to lock that tightly.

No hack occurred. No exploit was found. Instead, a routine multisig procedure went wrong when a signer collected one more approval than intended, triggering an outcome the smart contracts executed exactly as written.

The setup

MegaETH bills itself as a real-time Ethereum scaling layer capable of 100,000 transactions per second with sub-10-millisecond blocks — fast enough, in theory, to make Ethereum's roughly thirteen-second block times feel archaic. The project traces back to a 2022 concept by Yilong Li at Stanford, and by October 2025 it had pulled in $450 million from more than 50,000 participants in an oversubscribed auction ahead of its planned December mainnet launch.

To seed liquidity for that launch, the team scheduled a pre-deposit window opening at 9:00 AM ET on Monday, November 25, with a $250 million cap, first-come-first-served access, USDC deposits on Ethereum, and KYC handled through Cobie's Sonar platform via Echo. Governance over the pre-deposit contract sat with a 4-of-6 Safe multisig — four signatures required out of six possible signers, a standard configuration.

Two failures before the deposits even landed

The bridge went live at 9:00 AM and was effectively unusable by 9:01. Sonar's KYC infrastructure buckled almost immediately under demand it hadn't been load-tested for, hitting rate limits and locking up servers. MegaETH's first public acknowledgment came 24 minutes later, attributing the outage to "our 3rd party provider" receiving "too many requests."

Compounding that, deposits were already failing for a separate reason: the SaleUUID parameter in the pre-deposit contract didn't match what Sonar expected, so requests were being routed against the wrong sale identifier entirely. Fixing this required its own 4-of-6 multisig transaction, coordinated across signers in different time zones while users hammered a broken interface. The team reportedly needed 23 minutes just to diagnose the mismatch, plus additional time to gather signatures and push the fix live.

An instant sellout

Once the contract was working, the $250 million cap filled in 156 seconds — not 156 minutes, 156 seconds — as refresh-spamming users and pre-positioned bots caught an unannounced resumption window. Deposit data later showed extreme concentration at the top: one wallet put in $40 million, another $25.5 million, turning what was billed as a fair, automated launch into a speed contest favoring whoever had the fastest connection and the largest balance.

As users who missed the window complained about their lack of allocation, the team's response was to announce, at 10:15 AM, a plan to raise the cap to $1 billion. Early depositors pushed back immediately, pointing out this would quadruple the pool and dilute their expected yield with no warning and no way to withdraw. By 10:30 AM the team was walking it back somewhat, promising the increase would not affect existing participants and scheduling a reopening for 11:00 AM.

The multisig quirk that broke the schedule

Raising the cap required yet another multisig transaction to update the contract's parameters. MegaETH used the same 4-of-6 Safe setup — a configuration where, per Safe's documented design, once a transaction accumulates the required number of signatures, it becomes executable by anyone, not just the signers themselves. As an analyst known as YAM explained, this is not a bug: it's a deliberate feature of trustless multisig systems, meaning fully-signed transactions can be broadcast by any outside observer, and treasuries rely on this intentionally.

The MegaETH team collected all four required signatures ahead of time, intending to hold the transaction and execute it cleanly at 11:00 AM. They should have stopped at three. At 10:26 AM — 34 minutes before the planned reopening — a user known as chud.eth spotted the fully-signed transaction sitting in the public queue and executed it themselves. There was no vulnerability involved; it was a public transaction, made executable by the team's own signing decision, run by someone who understood Safe's mechanics better than the team deploying it.

Chaos resumes, caps flip twice

The premature execution reopened deposits with zero warning to users following official channels, while bots and refresh-spammers caught it instantly. Totals climbed past $300 million, then $400 million, forcing the team to scramble for control. Their first attempt to cap deposits at $400 million failed outright — by the time it landed on-chain, deposits had already exceeded that figure, and the contract rejected a cap set below the current total. A second attempt, setting the cap at $500 million, went through, freezing deposits at exactly that amount.

The team then queued a fresh transaction to push the cap to $1 billion again, before abandoning the idea altogether. Around noon, MegaETH announced it was scrapping the $1 billion plan: "We've encountered unexpected issues throughout the process and are no longer moving forward with the $1B cap. We will be sharing a retro shortly. We'll also be including the ability for users to withdraw who no longer wish to participate. Apologies for the turbulence."

Where the numbers landed

The final total came to $500 million locked across 4,589 unique addresses, with a median deposit of $3,100, an average of $102,396, and the top 10 wallets accounting for 29% of the total — concentration figures essentially unchanged from before the chaos, just reached through a far messier path.

MegaETH's Frontier mainnet beta remained on track for December, with the MEGA token launch targeted for early 2026 and pre-market pricing estimated at $2 to $3. Despite the option to exit, fewer than 5% of depositors withdrew once it was offered — 95% chose to stay in the pool.

The aftermath

MegaETH published a detailed post-mortem hours later, laying out the SaleUUID mismatch, the 23-minute delay identifying the Sonar rate-limiting issue, and the multisig error — attributing the last one to the fact that "the party responsible for executing the raise tx was unfamiliar with the specific safe feature." The team maintained that "at no point were assets at risk," noting that the contracts, audited by Zellic and SlowMist, performed exactly as coded throughout.

YAM's public breakdown became one of the most-cited explanations of what happened: "Live now. Don't sign all required signatures on a multisig and expect it not to be executed." and, in a follow-up post, "When required signatures on a transaction in a safe are reached, ANYONE (even people not on the multisig) can execute the transaction. It's a core feature and it can't be turned off."

The hashtag #MegaETH trended with more than 50,000 mentions, and sentiment split roughly 60/40 bearish. Critics called the episode a "clown show" and demanded refunds; supporters countered that locking in $500 million demonstrated genuine demand regardless of the execution problems. Developer and DAO founder AzFlin argued that a single careful engineer double-checking the process "would've" prevented the entire incident, while commentator olimpio summed it up as "PURE CINEMA" and "insane ride."

As for chud.eth, the individual behind the early execution described the situation with a mix of quips — calling it simply "Oops," joking that they were "simply building a rich onchain history," and adding: "If you don't manage your caps, chud will manage them for you." No further public statements followed the initial posts.

The broader takeaway

Safe's own reputation emerged intact — the mechanism behaved exactly as documented, and the Ethereum Foundation continues to rely on Safe for a treasury exceeding $650 million. What the episode exposed instead was an operational gap: a team with credentials from Stanford, MIT, and Harvard collected all four required signatures on a fully-signed transaction well before its intended execution time, apparently without fully accounting for the fact that any outside party could trigger it the moment the threshold was met.

No funds were stolen, no contract was exploited, and the audits held up. The failure sat entirely in process — infrastructure that wasn't load-tested, a misconfigured identifier, and a multisig collected too early by a team that otherwise moved with clear technical competence. Ninety-five percent of depositors stayed put after the dust settled, suggesting the market treated the incident as an embarrassment rather than a red flag.