Pandora, the duality token of digital currency: Will it become a new paradigm of asset issuance?

Source: View on the chain

How to understand the "picture and currency duality" innovative token @Pandora_ERC404? 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 ERC404 standard? Is it a new paradigm of asset issuance? Will it be useful to combine @SmartLayer's TokenScript? Next, let me talk about my understanding:

First of all, it should be noted that ERC404 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 ERC404 is to solve the incompatible problem between the original ERC20 homogeneous token standard and the ERC721 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 user’s intention is to sell NFT rather than FT, even if the judgment is correct? Now, how can the contract distinguish and update different data states in the stored data state without making an error? Isn't it very abstract?

In layman’s terms, smart contracts only need to manage the balance status of tokens under the ERC20 token standard. The storage data logic for increasing and decreasing balances is simple and clear. If the smart contract is based on the ERC721 token standard, It is also very simple to manage the state balance. Whichever Token ID the Transfer points to will increase or decrease the NFT.

Now it is troublesome to let the smart contract process ERC20 and ERC721 at the same time:

The contract must first determine whether the user Transfer call is FT or NFT. In addition, it must also determine when the NFT state is to be changed. Which Token ID to choose? Since smart contracts such as Uniswap cannot directly process NFT transactions, it is necessary to establish a mapping mapping relationship between FT and NFT, so that the transaction of FT can be completed at the same time as the transaction of NFT.

The core black technology of the ERC404 (experimental) standard lies in this. It uses a lossy encoding scheme to allow the number of ERC20 tokens and the unique ID of ERC721 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 (ERC20) and 2 magic cards (ERC721, ID 101 and ID 102). Lossy encoding needs to manage two types of data at the same time. You can Directly store the number of magic beans 2.9 as a whole data. At the same time, you can add a special mark to the ID number of the magic card, such as 1000000000000. This mark even far exceeds the Token's Supply, so that the contract can easily distinguish ERC20 when calling the data. and ERC721.

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. However, 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 directly sell FT tokens. The contract will automatically record that the number of FTs 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 part sold is, and it cannot correspond to its corresponding NFT. Strictly speaking, this is actually a "flaw" of the ERC404 experimental standard.

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

A trick 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 of NFT tokens. And the new issuance operation 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, and at the same time refresh the rarity of new NFTs

< p>. 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 the 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 is likely to cause problems. 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 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 should be destroyed first and which rare NFT tokens should be retained when trading FT tokens. , which is exactly the function that @SmartLayer aims to achieve as I mentioned at the beginning.

Regarding Smartlayer, it actually has nothing to do with ERC404. It’s just that ERC404 aims to make tokens have the basic functions of corresponding NFT images, while Smartlayer is a set of standards that combines ERC-5169 and TokenScript. In essence, It is to achieve the programmable execution properties of FT tokens. The two coincide in capabilities, but the latter is more complex. To put it simply: TokenScript is an open source framework that aims to provide a standardized way for digital tokens to define the behavior and interaction logic of the token. Token issuers can design a programmable front-end for their tokens. For example, in the ERC404 scenario, users can choose which NFT to destroy first based on the Smartlayer front-end, mark rare NFTs to avoid being destroyed, and other personalized functions. For example, in a wider gaming scenario, users can feed and caress the NFTs in their wallets. Pets add upgrade, iteration and other attributes to their NFT. When I was researching what Smartlayer was doing, the concepts of programmable tokens, smart tokens, Token external executable scripts, etc. really burned my mind. When I saw the emergence of ERC404 standard tokens, I suddenly felt enlightened. It feels like the last issue of NFT differentiation in the ERC404 experimental state can be solved with Smartlayer’s smart token front-end? above After reading it, do you feel like "getting two bucks for one thing"? You not only have a general understanding of Pandora under the Token404 standard, but also have a deep understanding of the Smartlayer that is about to be TGE. It turns out that every 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 this time, in my opinion, it will It continues to generate all kinds of innovations and gameplay. I’m not sure how ERC404 will evolve next, and whether it will interoperate with Smartlayer to generate some sparks of innovation, but this management method of placing the original incompatible Token standards under a set of smart contracts is indeed called It is an innovation in the asset issuance paradigm.

Note: The ERC404 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.