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.

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.

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 proposed to 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 would 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 promised 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 stated a goal of becoming a liquidity beacon in the zkSync ecosystem by surpassing existing DEX offerings and supporting new protocols launching on zkSync.

Merlin had just recently passed its second audit by Certik and was in the middle of a 3-day “Liquidity Generation Event” as part of its token (MAGE) launch.

About Merlin DEX Developers

The reported backend development team of Merlin DEX consisted of three different developers, which were reportedly all individuals from Serbia.

pos-ninja

pos-ninja reports himself as a "BlockChain Engineer" and "Certified Blockchain Developer". As of the last time his profile was online, he had made "1,366 contributions in the last year". It appears that at some point prior to May 14th, his Github profile was deleted.

OneDev0411

OneDev0411 describes himself as a "Full Stack Web Engineer". He put together an impressive 7,116 contributions through Github in 2022.

DotNetStar82

DotNetStar82 describes himself as "A Full-stack .Net & Blockchain Developer". He is "ready to start your project anytime" with an extensive list of skills advertised on his Github.

About Me

• Like to make a development document with developing content to use that in the future.
• Delivering perfect results at any time.
• Keeping good communication and work on the client's time zone.
• Ability for working with any team and prefer to share much knowledge with many developers.
• Looking for an opportunity to build a long-term relationship with great clients all over the world.

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. This information was only available inside the audit report itself, and many users likely didn't understand the implications of trusting the project.

What Happened

The Merlin DEX drained their liquidity pool where users were depositing as part of the MAGE token sale.

Key Event Timeline - Merlin DEX Liquidity Pool Drained

Date	Event	Description
April 10th, 2023	Merlin DEX Requests First CertiK Smart Contract Audit	The Merlin DEX first requests a smart contract audit from CertiK.
April 14th, 2023	First CertiK Smart Contract Audit Revisions Completed	The Merlin DEX completes the addressing of the feedback from the CertiK audit. The major centralization issue and one control flow issue are resolved, however other issues are merely acknowledged.
April 17th, 2023	Merlin DEX Requests Second Smart Contract Audit from CertiK	Merlin DEX requests a second audit from CertiK.
April 24th, 2023 9:47:00 AM MDT	Completion of Second CertiK Smart Contract Audit	The Merlin DEX acknowledged the feedback from the second CertiK audit, which found only issues of a Medium and Minor nature. The Merlin DEX platform announces the news on Twitter.
April 25th, 2023 5:58:00 PM MDT	Liquidity Pool Draining	One of the transactions involved in draining the liquidity pool. TBD - figure out what this transaction is:
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.
April 25th, 2023 10:11:00 PM MDT	PeckShield Posts On Twitter	PeckShield posts an alert on Twitter. TBD details.
April 25th, 2023 11:09:00 PM MDT	MerlinDEX Acknowledges Incident	The Merlin DEX acknowledges the exploit on Twitter. TBD more details.
April 26th, 2023 1:21:00 AM MDT	Beosin Alert on Twitter	Beosin Alert publishes a warning on Twitter about the exploit.
April 26th, 2023 11:47:00 AM MDT	MerlinDEX Releases Post-Mortem	The Merlin DEX provides a post-mortem of the exploit on Twitter. They also announce that they have contacted the Serbian authorities. TBD more details.
April 27th, 2023 1:13:00 PM MDT	Rekt Publishes Article	The situation is published on Rekt. TBD more description.
May 3rd, 2023 1:26:24 AM MDT	CertiK Updates Security Score	CertiK updated the security score of the Merlin DEX project to a status of "Exit Scam". TBD - This happened prior and it would be good to get the real date.

Technical Details

This is not an advanced type of attack. The liquidity pool where users were depositing funds as part of the MAGE token sale was directly drained.

Normally, a liquidity pool maintains two assets which are traded against one another. There were two lines of code added in the initialize function of the smart contract which granted approval for the "feeTo" address to transfer an unlimited amount of both tokens from the liquidity pool.

function initialize (address _token0, address _token1) external {

require(msg.sender == factory && !initialized, 'MerlinSwapPair: FORBIDDEN');

// sufficient check

token0 = _token0;

token1 = _token1;

IERC20(token0).approve(IMerlinSwapFactory(factory).feeTo(), type(uint256).max);

IERC20(token1).approve(IMerlinSwapFactory(factory).feeTo(), type(uint256).max);

...

The new code granted a maximum unlimited approval for the owner of the "feeTo" address to pull as much money as they wanted from the liquidity pool.

While the original CertiK audit did originally reject the first version of the smart contract due to a centralization issue, this was resolved by the implementation of a multi-signature wallet. However, there was no way to verify that the multi-signature address were, in fact, owned by separate individuals acting autonomously.

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."

Furthermore, the back-end team who also have access to our web-host had unknowingly manipulated our code to achieve their goal.

We had submitted all intended contracts to be used on our platform to Certik who carried out a full audit. However there has been a clear oversight on the overarching power the _owner had of the pools.

They chose to carry out several on-chain transactions to drain all of Merlin's pools, public sale and manipulate our front-end contracts. This was done by implementing a function that allows a Call action to all Merlin Pairs alongside hidden Front-End Contracts.

Total Amount Lost

Rekt reports the amount drained from the liquidity pool as $1.8m.

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

Immediate Reactions

The initial alarm was raised by community member wasgiventhatday, before blockchain research firm Peckshield spread the message. Merlin then acknowledged the incident the following day, advising users to revoke permissions as a precaution.

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

The Merlin DEX released a post-mortem a couple of days after the incident.

Merlin DEX Releases Post-Mortem

The Merlin DEX provided a post mortem of the exploit on the following day.

it is with deepest regret that we have to notify you of a major fault in the structural integrity and controls of the Merlin Platform.

In the early hours of this morning the several members of the Back-End Team drained all of our Contracts.

Back-End Technical Team Committers:

https://github.com/pos-ninja

https://github.com/dotnetstar82

https://github.com/OneDev0411

Notable Prior Projects:

@DynoChainNet

@discoverilla (Technical Leads Project)

@InterFiNetwork (KYC + Audit)

They chose to carry out several on-chain transactions to drain all of Merlin's pools, public sale and manipulate our front-end contracts. This was done by implementing a function that allows a Call action to all Merlin Pairs alongside hidden Front-End Contracts.

We had submitted all intended contracts to be used on our platform to Certik who carried out a full audit. However there has been a clear oversight on the overarching power the _owner had of the pools.

Furthermore, the back-end team who also have access to our web-host had unknowingly manipulated our code to achieve their goal.

Our unwavering priority is to return all funds to effected parties and participants on the Merlin platform at the earliest opportunity. To that end, we are working alongside @Certik (Team DOXX by both Prospero & Alatar Recovery Plan) to reimburse all effected users.

We have also notified relevant authorities in Serbia (Region of back-end Team) and work alongside on-chain analysts to monitor the movement of the stolen funds.

These have been tracked to two wallets which can be found below :  https://debank.com/profile/0xa7d481944730a88b862eb57248cb1b2c8aa358ad

The wallet _owner/deployer of all effected contracts on ZkSync Mainnet at source are :   

https://explorer.zksync.io/address/0xc0D6987d10430292A3ca994dd7A31E461eb28182  

https://explorer.zksync.io/address/0xc7fD785f81Fe6bBb499009746a2BCbbdd895f5b0

We are deeply saddened by the actions of the technical team, whom we put a high degree of trust in. Merlin will continue to support our community and resolve the issue.

Attempts At Recovery

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

"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."

Total Amount Recovered

It doesn't appear that any funds were recovered. It was reported that the funds were bridged back to Ethereum, swapped for ETH, and transferred to other addresses.

Ongoing Developments

Merlin’s post-mortem places the blame on the back-end development team. The thread includes links to developers’ Github profiles and states that Serbian authorities have been contacted. It's reported that the withdrawn funds were bridged back to Ethereum, swapped for ETH and transferred to other addresses.

Merlin released a statement describing how they plan to move forward.

We are deeply saddened by the actions of the technical team, whom we put a high degree of trust in. Merlin will continue to support our community and resolve the issue.

Individual Prevention Policies

Avoid the use of smart contracts unless necessary. Minimize the level of exposure by removing or withdrawing assets whenever possible. Aim to choose smart contracts which have obtained third party security audits, preferably having been audited by at least three separate reputable firms. Pay attention to the audit reports, which smart contracts are covered, and whether the smart contract has been upgraded or modified since the report. Ensure that any administrative functions with the ability to remove funds from the smart contract are under the authority of a multi-signature wallet which is controlled by at least three separate and reputable entities.

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

Platform Prevention Policies

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

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

Regulatory Prevention Policies

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

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