Written in May 2023
In the emerging realm of DeFi, Merlin DEX stands as a novel, community-centric Decentralized Exchange (DEX) built on ZkSync, aiming to tackle the persistent "liquidity problem". By creating a robust liquidity environment, Merlin is paving the way for more efficient and accessible liquidity solutions.
Pushing the limits of Automatic Market Makers (AMMs), Merlin DEX has developed a unique mechanism to focus liquidity around target prices, optimizing speed, reliability, and reducing fees.
Merlin DEX's strong commitment to decentralization and its unique approach to Liquidity Generation Events (LGEs) stands as a testament to its innovative vision. Allowing users more control and transparency, Merlin is dedicated to creating an open, borderless DeFi environment.
In April 2023, the Merlin DEX unfortunately fell victim to a hack, resulting in an estimated loss of $1.8 million from the protocol. The hack occurred amidst a Liquidity Generation Event for the launch of its MAGE token.
The attacker exploited excessive permissions granted to the Feeto address used during deployment, enabling them to drain the pool of assets. This event highlights the potential risks of overly centralized control in a DeFi protocol and emphasizes the importance of implementing decentralization best practices.
Merlin DEX: Hack Explained
Step 1: Factory Contract Creation
The pool creator (address: 0xc0D6987d10430292A3ca994dd7A31E461eb28182) created a Factory Contract (0x63E6fdAdb86Ea26f917496bEEEAEa4efb319229F). In the process, the creator set the Feeto address, which is meant to collect transaction fees, to their own address. This essentially means the creator holds excessive control over the protocol.
Step 2: Pool Deployment
Next, a USDC-WETH pool was deployed using the Factory Contract. During initialization, the pool’s USDC and WETH tokens were given max approval to the Feeto address of the factory contract. This is risky because whoever controls the Feeto address can move all the tokens from the pool.
Step 3: Attack Execution
Leveraging this excessive permission granted to the Feeto address, the attacker (same as the pool creator in this case) transferred all tokens from the pool to their own address.
Step 4: Obfuscation
Interestingly, the owner and Feeto addresses of the Factory Contract had been changed before the attack. While this step was not necessary to execute the hack, it served to confuse observers and potentially divert attention away from the real exploit.
In Layman's Terms:
To simplify, imagine the Factory Contract as a vending machine factory and the pool as a vending machine. The vending machine factory was set up such that all vending machines it produces would give all the money inside them to the factory owner. The attacker created a vending machine (pool), which was programmed to give all its money to the factory owner, and took all the money out of it. Then, to confuse people, they changed the owner of the factory, even though it had nothing to do with their ability to empty the vending machine.
Recommendations for enhanced security
Permissions should be the least required to fulfill functionality. If a contract or a particular address doesn't need the ability to move all tokens, it shouldn't have that power. Always implement "principle of least privilege."
Regularly Monitor Contracts:
Continuously monitor contract activity, especially for contracts holding substantial value. Rapid detection and response can mitigate damage if an attack happens.
If possible, using multi-signature wallets for critical operations or ownership changes could provide an additional layer of security. This requires multiple people to agree on a transaction before it's processed.
Transparency and Open Source:
Transparency in code helps the community to verify the contract's operation and provides an additional layer of security through community auditing.
Time Locks for Critical Operations:
For crucial contract functions, consider implementing time locks. Time locks require a waiting period before certain functions can be executed, giving the community time to react if something appears malicious.
Emergency Shutdown Mechanisms:
Implement an emergency shutdown or pause mechanism to stop contract operations in case of detection of malicious activities.
Factory Contract (0x63E6fdAdb86Ea26f917496bEEEAEa4efb319229F):
The factory contract was created by the pool creator (0xc0D6987d10430292A3ca994dd7A31E461eb28182). This contract is where the USDC-WETH pool was deployed from. During initialization, the Feeto address was set to be the same as the creator's address, presenting a centralization risk.
This is the Ethereum address of the individual or entity who deployed the factory contract and the USDC-WETH pool. They initially had control over the Feeto address, which was later changed, presumably to avoid suspicion or confuse investigators.
USDC-WETH Pool (0x82cf66e9a45Df1CD3837cF623F7E73C1Ae6DFf1e)
This pool was created through the factory contract and granted maximum approval to the Feeto address of the factory contract. Essentially, the Feeto address had complete control over the funds within this pool, leading to the theft.
This incident demonstrates the critical importance of secure smart contract design and the necessity of rigorous auditing. The attack on the Merlin DEX on ZkSync, which resulted in a loss of $1.8M, exploited the centralization of power in the factory contract's Feeto address, leading to the unauthorized transfer of tokens from the USDC-WETH pool.
A comprehensive security audit, such as those provided by BlockApex, can greatly enhance the security posture of a DeFi protocol. Such audits can identify and address vulnerabilities before they are exploited, protecting users and ensuring the sustainable growth of the protocol. Smart contract audits are a key defensive measure, and their importance cannot be overstated in the rapidly evolving and highly competitive DeFi landscape.