NFT

Dudu House NFT Minting Mishap! Where Did the Smart Contract Go Wrong?

share
Dudu House NFT Minting Mishap! Where Did the Smart Contract Go Wrong?

As the concept and discussion of NFT gradually gain popularity in Taiwan, many local businesses and teams have expanded their scope of operations to this area. However, since the industry is not yet mature, tasks such as writing smart contracts and managing Discord communities are not things that traditional businesses can handle in the usual way. As a result, many controversial issues have arisen. Today, the focus is on the leading parking platform in Taiwan, "Dudu House," and the contract issues it faced during the NFT issuance. What exactly went wrong that led to a large number of failed mintings?

Table of Contents

As the concept and discussion of NFT gradually become popular in Taiwan, many local businesses and teams have expanded their operations into this field. However, since the industry is not yet mature, tasks such as writing smart contracts and managing Discord communities cannot be handled in the same way as traditional businesses, leading to many controversial issues. Today, the focus is on the contract issues during the NFT issuance by Taiwan's leading parking lot provider "Dudu House". What exactly went wrong that resulted in a large number of failed minting?

This article is reprinted from Rex Chen, the founder of FULY.AI Intelligent Investment Robot. Original article can be found here.

Dudu House NFT Incident

Dudu House opened the whitelist for minting at 10:00 on 3/11, but almost everyone on the whitelist failed to mint!

This is the smart contract address of Dudu House:
https://etherscan.io/address/0xae122962331c2b02f837b2aa501d3c5d903ed28a#code

According to the contract, it can be seen that their preSaleMint checks whether isWhitelisted.

This is the core issue of this incident, the isWhitelisted function.

The variable actually stored on the blockchain is whitelistedAddresses, which is an array filled with all the whitelisted addresses.

Checking each data in the array using a for loop within the smart contract is manageable when the array is small, but it becomes a problem as the whitelist grows.

According to the contract transaction, it can be seen that there are 898 whitelist entries, costing 0.689 ether in gas fees, which is quite high.

If you are lucky to be at the front of the whitelist, congratulations, you can mint with a very low gas fee. If you are at the back, you are out of luck.

These are the initial records of all failed transactions. It's unclear why some people tried to mint ahead of time when they were already on the whitelist XD. However, this project is slightly better than the previous one, Yolocat 09, as it has set preSaleStart <= block.timestamp, making it almost impossible to mint ahead of time.

Since they have set preSaleStart <= block.timestamp

This time corresponds to 10:00 in Taiwan time.

This is the first failed transaction record, with entry number 258 on the whitelist, relatively in the middle. The Gas Limit was set at 420,000, but due to a too low Gas Limit, it ran out of gas.

This is the first successful mint, with entry number 4 on the whitelist. They were lucky and only spent $16.93 in fees to mint, as the Ethereum network was not congested at that time.

Later, the project team manually adjusted the Gas Limit to two million, but some still failed. For example, entry number 869 on the whitelist spent $144.99 in fees and still ran out of gas.

So, what are the issues?

  1. Setting the Gas Limit too low is one issue, but users can manually adjust this in MetaMask, so it shouldn't be a major problem.
  2. The real issue lies in using a for loop to iterate through the array, causing the gas fees to increase for those at the end, creating a geometric progression of costs, which is quite alarming.

The simple solution to this problem is to avoid using an array to store data and instead use a mapping to store whitelist addresses.

Then, direct judgment can be made without the need for a for loop.

Although setting the whitelist is still costly, it will prevent users from facing high costs when minting!

Therefore, the mainstream practice now is to use a merkle tree to implement whitelists, which makes list modifications easier and reduces the need for high fees. I have just researched this recently, so any feedback or corrections are welcome.