NewsFlash Articles Data Fundraising BlockBeats Pro

How to understand the "image-coin duality" innovative token PANDORA

Read this article in 13 Minutes

"ERC-404, which is still in the experimental stage, can indeed be regarded as an innovation in the asset issuance paradigm"

Original author: Haotian, crypto researcher

How to understand the innovative token PANDORA, which is a duality between image and currency? It allows FT and NFT to have a symbiotic relationship, so as to solve the problem of poor liquidity of NFT. From a technical point of view, it is novel and interesting to allow the two native contradictory tokens of FT and NFT to be mixed and applied.

What is the innovation of the ERC-404 standard? Is it a new paradigm for asset issuance? Will the TokenScript combined with SmartLayer be useful? Next, let me talk about my understanding:

First of all, it should be noted that ERC-404 is currently only an experimental standard and has not been included in the formal Ethereum EIP proposal. Pandora is the first token created based on this new experimental standard. ERC-404 aims to solve the problem that the original ERC-20 homogeneous token standard and the ERC-721 non-homogeneous token standard are incompatible.

For example, if a user holds both FT tokens and NFT tokens, when the user chooses to sell NFT tokens, how does the contract determine that the user's intention is to sell NFTs rather than FTs? Even if the judgment is correct, how does the contract distinguish and update different data states in the storage data state without making mistakes? Is it very abstract?

In layman's terms, under the ERC-20 token standard, smart contracts only need to manage the balance status of tokens. The storage data logic for increasing and decreasing the balance is simple and clear. If smart contracts are allowed to manage the status balance under the ERC-721 token standard, it is also very simple. The NFT is increased or decreased according to the Token ID that the Transfer points to.

Now it is troublesome to let the smart contract handle ERC-20 and ERC-721 at the same time:

The contract must first determine whether the user Transfer calls FT or NFT. In addition, when changing the NFT status, it must also determine which Token ID to choose. Since smart contracts such as Uniswap cannot directly handle NFT transactions, it is also necessary to establish a mapping relationship between FT and NFT, so as to realize the transaction of FT and NFT at the same time.

The core black technology of the ERC-404 (experimental) standard lies here. It uses a lossy encoding scheme to allow the number of ERC-20 tokens and the unique ID of the ERC721 token to use the same data structure in the contract storage while maintaining their distinction and independence.

For example, suppose you have 2.9 magic beans (ERC20) and 2 magic cards (ERC-721, ID 101 and ID 102). Lossy encoding manages two types of data at the same time. You can directly store the number of magic beans 2.9 as a whole data, and add a special mark to the ID number of the magic card, such as 1000000000000, which is even higher than the Supply of the Token. In this way, the contract can easily distinguish between ERC-20 and ERC-721 when calling data.

After completing this step, to effectively manage the symbiotic relationship between FT and NFT, you need to write a set of mapping logic relationships for the contract. For example, if you have 1 FT token, the contract will automatically mint an NFT to you. When you hold 2 FT tokens, the contract will automatically issue 1 NFT. However, when your FT balance is less than 1, the contract will destroy your NFT. This set of corresponding relationships is not difficult to understand.

So, how to make NFT tokens traded in a protocol like Uniswap that only supports FT tokens? Answer: Use the mapping relationship. Just let Uniswap handle FT tokens normally, and NFT tokens will automatically change their ownership status.

For example, if you want to sell NFT tokens, you can directly sell FT tokens. The contract will automatically record that the FT in your wallet has decreased by 1 and destroy an NFT in your wallet.

Careful friends should have discovered the problem. If a user holds 2.9 FT tokens and 2 NFT tokens, when the user sells 1 FT, which of the two NFTs should the contract destroy?

This is actually a very complicated problem, because the contract cannot determine which FT token the sold part is, and it cannot correspond to its corresponding NFT. Strictly speaking, this is actually a "defect" of the ERC-404 experimental standard.

But technology meets Tokenomics to produce a magical chemical reaction.

A clever way is to design a set of NFT rare refresh mechanism to encourage users to transfer the superimposed FT tokens continuously. Each transfer of FT is equivalent to the destruction and issuance of NFT tokens, which is equivalent to refreshing the rarity. In this way, users tend to separate FT tokens, and then use this to avoid the destruction of rare NFTs, while refreshing the rarity of new NFTs.

You see, it was originally a technical logic bug, but it can be effectively resolved through a layer of rarity operation design. Of course, if users really want to stack multiple FT tokens in a wallet, and want to destroy the existing NFT tokens according to their own wishes (non-randomly), how to do it?

There are two existing approaches: 1) Execute according to the order of Token ID, which is likely to destroy NFTs with rare characteristics; 2) Specify Burn of NFTs close to the floor price, but this is actually a layer of off-chain logic, which is likely to cause involuntary destruction due to the delay of oracle price feed. Moreover, the NFT close to the floor price actually needs to be defined by the user in advance, which is equivalent to accessing the data of the NFT market.

Instead of being so complicated, it is better to let users edit and select directly on the wallet side.

Then it is necessary to introduce a TokenScript solution that implements a programmable front end for FT tokens, so that users can choose on the wallet side which NFT tokens to destroy first and which NFT tokens of which rarity to keep when trading FT tokens, which is exactly the function that the SmartLayer goal I mentioned at the beginning is to achieve.

As for Smartlayer, it actually has nothing to do with ERC-404. It’s just that the goal of ERC-404 is to make the token have the basic functions of the corresponding NFT image, while Smartlayer is a set of standards that integrate ERC-5169 and TokenScript. In essence, it is to achieve the programmable execution properties of FT tokens. The two coincide in terms of capabilities, and the latter is even more complicated.

In short: TokenScript is an open source framework that aims to provide a standardized way for digital tokens to define the behavior and interaction logic of tokens. Token issuers can design a programmable front end for their tokens.

For example, in the ERC-404 scenario, users can choose which NFT to destroy first based on the front end of Smartlayer, and give rare NFTs personalized functions such as marking to avoid being destroyed. For example, in a wider range of game scenarios, you can feed and caress the NFT pets in your wallet, and add upgrades, iterations and other attributes to your NFTs.

Originally, when I was studying what Smartlayer was doing, some concepts such as programmable tokens, smart tokens, and token external executable scripts were really confusing. When I saw the emergence of the ERC-404 standard token, I felt enlightened. The last link of the NFT distinction problem in the ERC-404 experimental state can be solved by Smartlayer's smart token front-end?

After reading the above, do you feel like "eating two birds with one stone"? You have a general understanding of Pandora under the Token404 standard, and a deep understanding of Smartlayer, which is about to TGE.

It has been proven that every innovation around asset issuance will produce a long-term narrative fermentation effect. Whether it is the inscription of the Bitcoin ecosystem, or the hybrid standard token or programmable token of the Ethereum ecosystem this time, in my opinion, it will continue to derive various innovations and gameplay.

I am not sure how ERC-404 will evolve next, and whether it will interact with Smartlayer to generate some innovative sparks, but this management method of placing the previously incompatible Token standards under a set of smart contracts can indeed be called an innovation in the asset issuance paradigm.

Note: The ERC-404 standard is still in the experimental stage, and there may be many logical iterations. This article is only for popular science to help everyone's initial understanding, and it is not the final interpretation of this type of technical standard.