What is the NFT-FT duality？

Currency generally refers to native tokens of a blockchain or fungible tokens similar to the ERC20 protocol, such as BTC, ETH, USDT, etc.

Image refers to non-fungible tokens (NFTs) that comply with the ERC721 protocol, such as CryptoPunks, Bored Apes, mfers, etc. The 3D model assets issued by domestic digital collectible platforms (like Whale Explorer) are also considered images.

Tokens and NFTs each have their limitations, for example, tokens have strong liquidity but no speculative value in themselves, whereas NFTs have rarity and uniqueness but often suffer from poor liquidity and are usually either blue-chip projects or concentrated at floor prices.

The liquidity depth chart of a certain NFT project

The NFT-FT duality refers to a standard that mixes tokens and NFTs in some way.

Taking Ethereum as an example, a project that supports the NFT-FT duality should be both fungible and non-fungible. It can enjoy the high liquidity brought by Tokens and can also achieve rarity and uniqueness, possessing speculative value.

But does such a thing truly exist? The price of an NFT is tied to its rarity; how can it be made fungible?

ERC404 Opens Pandora’s Box

During the Spring Festival of 2024, an experimental protocol called ERC404 and its first project, Pandora, quickly became a sensation.

ERC404 pioneered a way to mix image-currencies, which can be simply described as:

• Buying 1 Pandora Token automatically grants 1 Pandora NFT
• If the balance is less than 1 Pandora Token, your NFT will automatically be destroyed
• Buying 1 Pandora NFT will automatically add 1 Token to your wallet, and conversely, selling will automatically decrease it by 1

Here’s a diagram to illustrate the current mixing logic of ERC404:

ERC404 game rules

The following are the current 5 types of Pandora’s Box, each with different rarity. Based on the contract implementation, we can calculate the probabilities:

Implementing an ERC404

The first version of the ERC404 code was not very well written, or to put it mildly, it was subpar. However, it solved the main problem — how to implement both the ERC20 and ERC721 interfaces within a single contract.

Comparison of three protocols

We screened out the unrelated parts of the two interface definitions and compared which interfaces overlap or conflict:

interface IERC20 {
 // Query the balance based on an address
 function balanceOf(address account) external view returns (uint256);
 // Transfer to a certain address
 function transfer(address recipient, uint256 amount) external returns (bool);
 // Transfer to a certain address on behalf of a third party (based on authorization)
 function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
 // Authorize token allowance
 function approve(address spender, uint256 amount) external returns (bool);
}

interface IERC721 is IERC165 {
 // Query the NFT quantity based on an address
 function balanceOf(address owner) external view returns (uint256 balance);
 // Transfer within the NFT standard is included in transferFrom

 // Transfer an NFT to a certain address on behalf of a third party (based on authorization)
 function transferFrom(address from, address to, uint256 tokenId) external;
 // Authorize NFT
 function approve(address to, uint256 tokenId) external;
}

It can be seen that all four conflicting interfaces are related to transfers. In ERC20, the semantically last parameter is the amount, which is the token’s limit, while in ERC721, the parameter’s semantic is tokenId, representing the NFT’s number.

In the contract implementation of ERC404, the semantics of this parameter are changed to amountOrId. The method to distinguish whether it’s an amount or a tokenId is quite simple: based on the value’s size.

Similar to 1 BTC = 10^9 Sats, in the ERC404 world, we say that 1 Token actually corresponds to a value of 10^18, while NFT’s tokenId is generally a sequentially increasing integer starting from 1. So although amount and tokenId are both integers, the actual orders of magnitude are quite different.

For example, the Pandora contract records how many NFTs have currently been minted (currently 68180). If the value of amountOrId is less than or equal to this, it is considered a tokenId; otherwise, it is considered an amount.

Is this logic useful? Yes. Is it reasonable?

Besides, when transferring >= 1 Token, the logic for NFTs is not transferring but rather the original account destroys, and a new account mints. This method has the advantage of matching liquidity and is simple to implement (consider the scenario of transferring less than 1 token), but it results in an exaggerated gas consumption.

Take this transaction as an example, transferring 4 Tokens resulted in the destruction of 4 NFTs and the minting of 4 new NFTs:

The transaction consumed $64 in GAS

New narratives and opportunities

The gameplay of ERC404 introduces several implicit rules:

1. The price of a Token on a DEX and the price of an NFT in the Marketplace won’t differ much.
2. There is only one situation when an NFT is minted: 1 Token is collected. In other words, the only method to exchange an NFT of lower rarity for one of higher rarity is through continuous trading of Tokens.
3. The total supply of Pandora Tokens is 10,000, signifying that the maximum number of NFTs is 10,000, and this number will decrease as the number of holders increases (the more holders there are, the more common the scenarios of less than 1 Token will be).

If I mastered the magic of consistently minting the ‘Red Pandora’s Box,’ could I buy Tokens on the exchange and then sell them at a high price in the NFT market for unlimited arbitrage?

Let’s look at the price of Pandora; these data provide the theoretical basis for arbitrage:

Bought Tokens for 4.7 ETH

The floor price of NFTs has been over 5 ETH for the past week

The above data does not filter by the rarity of the NFT; under this condition, the profit after accounting for wear and tear is around 0.2 ETH. Referring to the above implicit rules, if we can always mint NFTs of high rarity like the red Pandora’s Box, wouldn’t there be an even larger profit margin?

Let’s examine Pandora’s contract and see how the ‘random generation’ often described by KOLs is actually implemented:

pragma solidity ^0.8.0;

contract Pandora is ERC404 {
 function tokenURI(uint256 id) public view override returns (string memory) {

 // Hash the id once, taking the first digit as the random number
   uint8 seed = uint8(bytes1(keccak256(abi.encodePacked(id))));
   string memory color;

   // Determine the rarity based on the range of values for a uint8 [0, 255]
   if (seed <= 100) {
       color = "Green";
   } else if (seed <= 160) {
       color = "Blue";
   } else if (seed <= 210) {
       color = "Purple";
   } else if (seed <= 240) {
       color = "Orange";
   } else if (seed <= 255) {
       color = "Red";
   }
 }
}

By reading the contract, we can see that the rarity of the Pandora Box is pseudo-random, similar to our previous CryptoFish project, where the tokenId is incrementally increasing, so the rarity of the next minted NFT is entirely predictable.

We can make a purely local guess using a piece of JavaScript code, and after verification, this logic is completely correct:

const ethers = require('ethers');

const calcSeed = (id) =>
 parseInt(ethers.solidityPackedKeccak256(['uint256'], [id]).substr(2, 2), 16);

const getColorBySeed = (seed) => {
 let color;
 if (seed <= 100) {
   color = 'Green';
 } else if (seed <= 160) {
   color = 'Blue';
 } else if (seed <= 210) {
   color = 'Purple';
 } else if (seed <= 240) {
   color = 'Orange';
 } else if (seed <= 255) {
   color = 'Red';
 }
 return color;
};

console.log(calcSeed(1)); // 177
console.log(getColorBySeed(calcSeed(1))); // Purple

At present, the minted increment value of Pandora is 68180, which means we can predict the following 100 NFT IDs that will hit the red rarity: 68186/68201/68213/68227/68228/68257/68259/68262

If we ignore the current decrease in liquidity of the Pandora project, this could be a very popular financial behavior.

Conclusion

ERC404 and Pandora are not the first to explore NFT liquidity protocols. There have been discussions about NFT fractionalization before, including ERC1155 as an innovative approach to NFTs.

But why is the sentiment so high this time with ERC404? I believe it’s because of the good name.

Unfortunately, the first version of the ERC404 contract was poorly implemented, so the officials are actively promoting a V2 version, and the community also has a third-party implementation DN404. Some even created a new protocol called ERC911 , which is fully loaded with features in its naming.

Liquidity reached its peak during the New Year period, and it has since seen a significant decline.

The story of Pandora V1 may come to a quick end; the current version has countless flaws enough to bring it down, and liquidity and holders have also fallen significantly. However, at present, more and more project teams are trying out the ERC404 model, with 25 already listed on CoinMarketCap.

It is believed that there will be more solutions to NFT liquidity problems in the future, and ERC404 could truly bring about the next NFT summer.

Disclaimer：

1. This article is reprinted from [medium], All copyrights belong to the original author [ZAN]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.