Merlin DEX Liquidity Pool Drained

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' and 'General Prevention' sections to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Merlin DEX

Merlin is a decentralized exchange (DEX) based on ZkSync and designed to support both volatile and stable exchanges with minimal fees and fast speed. The platform introduces dynamic directional fees that allow for various fees to be set for each pool and different fees based on the swap direction. Earnings from the protocol will be partially redistributed to stMAGE users and used to maintain a continuous buying pressure on MAGE. However, despite passing its second audit by Certik, Merlin suffered a rug pull during its Liquidity Generation Event, resulting in the loss of $1.8 million. The incident was caused by max approvals granted to the Feeto address upon deployment of the pools, which allowed the individuals in control to drain the pool of all assets and bridge them to ETH. Merlin's post-mortem places the blame on the back-end development team, and the rugged funds were bridged back to Ethereum, swapped for ETH, and transferred to other addresses.

This is a global/international case not involving a specific country.

About Merlin DEX

Merlin is a community-focused decentralized exchange (DEX) built on zkSync, a protocol for scalable and secure Ethereum transactions. The platform is designed to offer unique liquidity features, including an innovative yield strategy based on non-fungible staked positions that enhances capital efficiency. Merlin will use two tokens: MAGE, a liquid emission token, and stMAGE, an escrowed governance token that cannot be transferred, to incentivize participants in the ecosystem. Earnings from the protocol will be partially redistributed to stMAGE users in the form of yield and used to maintain a continuous buying pressure on MAGE. stMAGE will be allocated to special contracts known as Plugins, providing additional functionality to the protocol. The platform will have a dynamic automated market maker (AMM) capable of supporting both volatile and stable exchanges with various fees set for each pool and different fees based on the swap direction. Merlin aims to become a liquidity beacon in the zkSync ecosystem by surpassing existing DEX offerings and supporting new protocols launching on zkSync.

"Merlin had passed its second audit by Certik just two days before the attack."

"$1.8M disappeared in a puff of smoke as Merlin pulled the classic DeFi magic trick."

"Merlin, a DEX native to the recently-launched zksync L2, was in the middle of a 3-day “Liquidity Generation Event” as part of its token (MAGE) launch."

"The alarm was initially raised by a community member before Peckshield spread the message. Merlin then acknowledged the incident, advising users to revoke permissions as a precaution."

"The rug mechanism was a straightforward case of draining the liquidity pools into which users were depositing as part of the MAGE token sale."

"This was made possible via max approvals granted to the Feeto address upon deployment of the pools. The individual/s in control of the Feeto address could then drain the pool of all assets, which were then bridged to ETH."

"Merlin’s own post-mortem places the blame squarely on the back-end development team. The thread includes links to developers’ github profiles and states that Serbian authorities have been contacted."

"The rugged funds were bridged back to Ethereum, swapped for ETH and transferred to other addresses."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

Merlin's audit contained the following warning:

"We advise the client to carefully manage the privileged account's private key to avoid any potential risks of being hacked. In general, we strongly recommend centralized privileges or roles in the protocol be improved via a decentralized mechanism or smart-contract-based accounts with enhanced security practices, e.g., multisignature wallets."

However, this issue was marked as ‘Resolved’ by Certik, who stated that the Merlin team had promised to use a multisig. Enough users apparently didn’t read the audit fully, or simply didn’t care about the implications of trusting the project.

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - Merlin DEX Liquidity Pool Drained

Date	Event	Description
April 25th, 2023 5:58:00 PM MDT	Liquidity Pool Draining	One of the transactions involved in draining the liquidity pool.
April 25th, 2023 7:44:00 PM MDT	Exploit Warning on Twitter	An alarm that the liquidity pool had been drained was initially posted on Twitter by Twitter user wasgiventhatday.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

Total Amount Lost

The total amount lost has been estimated at $1,800,000 USD.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Initial Warning On Twitter

Twitter user wasgiventhatday originally posted on Twitter to warn about the exploit.

@circle 0xb72200739d557ce12b41876772e1e434af896644 has rugged @TheMerlinDEX of $147k . Can you please freeze his USDC on main net?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

General Prevention Policies

Reliance on a single firm for auditing, and audit being done before the multi-sig was actually set up.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.