The MegaETH pre-deposit event was expected to go live on 25 November with a straightforward promise. Users would bridge USDC on Ethereum into USDm on the Mega mainnet Frontier with a $250M cap.
Instead of a smooth launch, the event quickly turned into a complicated sequence of technical bottlenecks, misaligned parameters, timing problems, and unexpected user behaviour.
Although no funds were ever at risk, the process exposed several operational gaps. This article breaks down what happened, why it unfolded the way it did, and how the team is responding.
MegaETH Pre-Deposit Conundrum
The pre-deposit bridge was designed as a controlled and fair process. The setup involved three essential components working together.
First was the pre-deposit website operated directly by MegaETH. This interface sent a request to the Sonar API to verify whether a user’s KYC status was valid for the sale.
Second was the pre-deposit contract operated through a Safe multisig requiring four out of six signatures.
This contract defined the sale parameters, including timing, cap limits, and the unique SaleUUID used to match KYC verification.
Only deposits that came from the website and carried a valid signature were intended to be accepted, which meant botting was not possible. Third was Sonar, operated by Echo, which was responsible for verifying KYC information for the sale.
The process looked clean on paper. However, the moment the sale opened, the system encountered the first major issue. Transactions began to fail because the SaleUUID set inside the pre-deposit contract did not match the one communicated to Sonar.
This mismatch meant that Sonar could not validate deposits. Since the value was stored on chain, the fix required a multisig transaction, which also required coordination among four signers.
That delay set the first domino in motion and created a backlog of users attempting to deposit without success.
Once the SaleUUID mismatch was corrected, the next issue emerged almost immediately. Sonar began receiving heavy traffic as users tried to deposit at once.
Unfortunately, its rate limit was misconfigured and set far too low. As a result, Sonar began blocking incoming traffic, which stopped users from funding their deposits.
It took 23 minutes to identify the cause and deploy a fix. During this period, users were repeatedly refreshing, which created even more pressure. Although all deposits were safe, the experience deteriorated rapidly.
When Sonar returned to normal operation, the system resumed in the way the team had initially designed it. The opening time was automated and randomised to maintain fairness.
However, that randomness created another unintended consequence. Because some users were spam refreshing the pre-deposit website, they caught the exact moment deposits opened and filled the $250M cap almost instantly.
The cap was supposed to provide a controlled entry, but instead, it created a wave of instant deposits from only the most aggressive refreshers.
In response, MegaETH decided to raise the cap to $1B at the next hour mark, which required another multisig signature cycle. The signatures were gathered in advance, and the team prepared the transaction.
However, a misunderstanding about a basic Safe feature led to another unexpected turn. Once a Safe transaction has the required signatures, anyone can execute it. You do not need to be a signer.
Someone executed the cap increase around 30 minutes early. This was not malicious behaviour. It was simply a misunderstanding about how Safe operates. Even so, it created another imbalance.
Users who were refreshing aggressively discovered the early cap lift and resubmitted their deposits. Meanwhile, users following official channels did not realise the cap had already changed.
The team attempted to adjust the situation by lowering the active cap. First, they tried to bring it down to $400M.
However, by the time the transaction reached the chain, deposits had already exceeded that threshold. A second attempt raised the cap to $500M. That one landed in time, and the cap currently sits at $500M filled.
At this point, the intended increase to $1B was paused. The team decided not to proceed further because there were still unresolved issues, including ongoing KYC verification bugs that prevented some users from participating.
It would not have been responsible to continue raising caps while the system was not functioning evenly.
The retro shared by MegaETH takes full responsibility for the experience. The team emphasised that although no assets were ever at risk, the user experience did not meet their own standards.
The combination of contract parameters, Sonar configuration, Safe execution behaviour, and unpredictable user interaction created a perfect storm.
They have committed to releasing a withdrawal page for users who want to reclaim funds, especially those who entered under the assumption of a $250M cap.
The story of the conundrum is largely a story of small issues merging one after another. A mismatched identifier created delays. A misconfigured rate limit blocked deposits. A random opening time rewarded refresh spamming.
A Safe execution misunderstanding lifted the cap earlier than planned. All of these pieces interacted in a way that could not be predicted easily, even with testing. What was meant to be a structured onboarding process became a race between users and the system itself.
The Current Condition
At present, the pre-deposit contract sits at a filled $500M cap. The planned cap increase to $1B has been cancelled. The system is paused from further expansion until the remaining technical issues are fully resolved.
The team has acknowledged the shortcomings openly and has begun preparing a withdrawal page for users who want to exit their deposits. This is particularly important for those who allocated capital based on the original $250M cap expectation rather than the later expanded conditions.
The main components involved in the event are now stable. The SaleUUID has been corrected. The website is functioning normally. Sonar has resolved its rate limit and downtime issues.
The Safe multisig stands ready, but future actions will be executed with more caution and more internal coordination to avoid repeat misunderstandings.
Even so, the system will not resume with new caps or further activity until the team completes additional checks on consistency and KYC pathways.
The community response has been a blend of support, frustration, and curiosity. Some users appreciate the transparency and detailed explanation. Others are understandably disappointed, especially those who followed the official opening times rather than aggressively refreshing.
The imbalance created by the randomised opening and the early Safe execution is still a point of discussion. MegaETH has acknowledged that fairness must be more than a design principle.
It must also be reflected in practical execution, especially when large amounts of capital move quickly in a short window.
The decision to halt the planned $1B expansion reflects a more cautious stance. Instead of pushing forward with unresolved issues, the team is focusing on restoring clarity and next steps.
This includes improving the KYC verification flow, improving internal coordination for contract updates and reassessing the overall experience. The withdrawal page will serve as a way for users to make informed decisions rather than being locked into an unintended state.
For now, the system sits in a reflective phase. The pre-deposit achieved significant participation despite the problems, and the cap lock at $500M shows the level of interest.
Yet interest alone cannot justify moving ahead without operational stability. The team is prioritising user experience, communication, and consistent performance ahead of any further expansion.
Conclusion
MegaETH’s pre-deposit event became a complex sequence of issues rather than the smooth launch users expected. None of the problems involved lost funds, but the experience revealed clear operational weaknesses.
The system now sits capped at $500M with withdrawals arriving soon and fixes underway. The team has taken a transparent position and is working to restore balance before the next step.