Building RRC-404 with Scrypto:
First, if you want to see my thoughts on ERC-404, check out my post from yesterday here:
nitter.app/aus877/status/17615352…
Building this standard with Scrypto allowed me to think about the problem of nonfungible liquidity from a different angle. Scrypto provides very easy to use native resources that are not smart contracts like the ERC-20 and ERC-721 tokens. These native resources have basic and reliable behaviors that resemble physical money you would have in your wallet. With these basic behaviors, it is easy to mimic the desired actions of ERC-404 and maybe even make a few simple improvements along the way.
Instead of risking randomly losing an NFT if you transfer part or all a fungible, why not design it in a way where the user only has 1 NFT OR 1 fungible at any given time? If the user only owns either 1 NFT or 1 fungible instead of both at the same time, you stop having issues where invisible mapping can burn an NFT you may want to keep.
If the goal is to provide liquidity, it is quite easy in Scrypto to link a fungible resource with a nonfungible resource by writing logic capping their supply to a single number.
Instead of tokens themselves being smart contracts, users on Radix can interact with a dedicated smart contract to convert between fungible and nonfungible state when they want. This way, there are two very distinct resource states where you are not concerned about accidentally making a mistake. If you have an RRC-404 fungible, you can freely send it, swap it, add it as liquidity without consequence to any NFTs. Likewise, with RRC-404 nonfungibles, you can send them, swap them, list them on a marketplace without any consequence to your fungibles.
This RRC-404 blueprint is not random, and doesn't pick the next NFT rarity based on the id's hash value like ERC-404. Instead I thought it would be interesting to write logic that aimed to maintain a constant percentage for each rarity (for example 42% Green, 30% Blue, 16% Red, 8% Orange, 4% Purple). You could technically monitor the circulating supply of each NFT to have an idea of which NFT would be minted next in this scenario, but you would not be able to control anyone else from minting/burning other NFTs and changing these ratios.
This model also makes fractional ownership of NFTs quite easy. If you want to convert fungibles to an NFT, it just requires a whole fungible token. If you call the freeze method with 1.5 water tokens, you will just receive 1 Ice NFT and .5 water tokens in change. Converting Ice NFTs back into Water fungible tokens always results in a whole number of fungibles.
Here is the RRC-404 code:
github.com/aus87/ice_rrc404v…