Original author: Haotian (X: @tmel0211)

How to understand the Picture and Coin Duality innovative token @Pandora_ERC 404? It allows FT and NFT to have a symbiotic relationship to solve the problem of poor liquidity of NFT. From a technical perspective, allowing the two native contradictory tokens of FT and NFT to be mixed and applied is novel and interesting.

What is innovative about the ERC 404 standard? Is it a new paradigm of asset issuance? Will it be useful to combine @SmartLayers TokenScript? Next, let me talk about my understanding:

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

For example, a user holds both FT tokens and NFT tokens. When the user chooses to sell NFT tokens, how does the contract determine that the users intention is to sell NFT rather than FT? Even if the judgment is correct, how does the contract store data? State-differentiated update of different data states without errors?Isnt it very abstract?

Generally speaking, smart contracts only need to manage the balance status of tokens under the ERC 20 token standard. The storage data logic for increasing and decreasing balances is simple and clear. If the smart contract manages the status balance under the ERC 721 token standard, it will also Its very simple, whichever Token ID the Transfer points to will increase or decrease the NFT.

Now it’s troublesome to have smart contracts handle both ERC 20 and ERC 721:

The contract must first determine whether the users Transfer call is 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.Then the transaction of FT is realized and the transaction of NFT is also completed.

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

For example, suppose you have 2.9 magic beans (ERC 20) and 2 magic cards (ERC 721, ID 101 and ID 102). Lossy encoding needs to manage two types of data at the same time. You can directly convert the magic beans to The quantity 2.9 is stored as a whole data. At the same time, a special mark can be added to the ID number of the magic card, such as 1000000000000. This mark even far exceeds the Supply of Token, so that the contract can easily distinguish 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 additional NFT, but when your FT balance is less than 1, the contract will destroy your NFT. This set of correspondences is not difficult to understand.

So, how to enable NFT tokens to be traded in a protocol like Uniswap that only supports FT tokens?Answer: Use Mapping correspondence. Just let Uniswap handle the FT tokens normally, and the NFT tokens will automatically change their ownership status accordingly. For example, if you want to sell NFT tokens, you can sell the FT tokens directly. The contract will automatically record that the FT in your wallet is reduced by 1 and destroy an NFT in your wallet.

Attentive friends should have discovered the problem. If the user holds 2.9 FT tokens and 2 NFT tokens,When a 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 part sold is, and it cannot correspond to its corresponding NFT. Strictly speaking, this is actually a flaw of the ERC 404 experimental standard.

But when technology meets Tokenomics, a magical chemical reaction occurs.

A clever way is to design a set of NFT rare refresh mechanisms to encourage users to continuously transfer superimposed FT tokens. Each transfer of FT is equivalent to the destruction and new issuance of NFT tokens, which is also It is equivalent to refreshing the rarity once, so users tend to separate FT tokens, and then use this to prevent rare NFTs from being destroyed, while refreshing new NFT rarity.

You see, it was originally a technical logic bug, but through a layer of rarity operational design, it can really be effectively resolved.Of course, if a user insists on being serious and wants to stack multiple FT tokens in a wallet, and also wants the existing NFT tokens to be destroyed according to their own wishes (non-randomly), what should they do?

There are two existing methods. 1) Execute sequentially according to Token ID, which is likely to destroy NFTs with rare characteristics; 2) Specify NFTs whose Burn is close to the floor price, but this is actually a layer of off-chain logic, which may cause Oracle price feed delay problem leads to involuntary destruction. Moreover, if the NFT is close to the floor price, it actually requires users to place orders in advance to define it, which is equivalent to accessing the data of the NFT market.

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

Then we must introduce a TokenScript solution to implement a programmable front-end for FT tokens.In this way, users can choose on the wallet side which NFT token to destroy first and which rare NFT token to retain when trading FT tokens. This is exactly the function that @SmartLayer aims to achieve as I mentioned at the beginning.

Regarding Smart Layer, it actually has nothing to do with ERC 404. It’s just that the goal of ERC 404 is to allow tokens to have the basic functions of corresponding NFT images, while Smart Layer is a set of standards that integrates ERC-5169 and TokenScript, which essentially aims to achieve Programmable execution properties of FT tokens. The two coincide in capabilities, but the latter is more complex.

simply put:TokenScript is an open source framework that aims to provide digital tokens with a standardized way to define the tokens behavior and interaction logic. 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 Smart Layer front-end, mark rare NFTs to avoid being destroyed, and other personalized functions. For example, in a wider game scenario, they can feed and caress the items in their wallets. NFT pet, add upgrade, iteration and other attributes to its NFT.

When I was studying what Smart Layer was doing, the concepts of programmable tokens, smart tokens, Token external executable scripts, etc. really burned my mind. When I saw the emergence of ERC 404 standard tokens, I felt a sense of relief. Feeling cheerful, can’t the last issue of NFT differentiation in the ERC 404 experimental state be solved with Smart Layer’s smart token front-end?

After reading it, do you feel like getting two bucks for one thing? You not only have a general understanding of Pandora under the Token 404 standard, but also have a deep understanding of the Smart Layer that is about to be TGE.

It turns out thatEvery innovation around asset issuance will have a narrative fermentation effect for a long time. Whether it is the inscription of the Bitcoin ecosystem or the hybrid standard token or programmable token of the Ethereum ecosystem, in my opinion, it will continue to derive All kinds of innovations and gameplay.

I’m not sure how ERC 404 will evolve next, and whether interoperability with Smart Layer will generate some sparks of innovation, but this management method of placing the original incompatible Token standards under a set of smart contracts is indeed It can actually be called an innovation in the asset issuance paradigm.

Note: The ERC 404 standard is still in the experimental stage, and there may still be many logical iterations. This article is only for popular science to help everyone understand it initially, and does not serve as the final explanation of this type of technical standard. For more information, I will follow up the analysis further.

Original link