Advancing Beyond Solidity: How Scrypto Perfects the Vision of ERC-404 | The Radix Blog | Radix DLT
What is ERC-404?
A brand new experimental standard on Ethereum has emerged recently, generating a great deal of hype and excitement across many chains. This standard, named ERC-404, creates a sort of hybrid of other popular Ethereum standards, allowing for interesting things such as increased NFT liquidity and a form of fractional ownership.
Building towards these goals in the traditional Solidity way creates problems like unpredictable token behaviors and the need for integration with other dApps. The Radix and Scrypto approach solves all of the same problems ERC-404 aims to solve, but more intuitively, without the need for any new “standard”, and no need for integration with other dApps.
What does ERC-404 set out to achieve?
ERC (Ethereum Request for Comment) is a process used on Ethereum to propose and agree to new smart contract standards. The most popular ERC standards are ERC-20 and ERC-721, which are the most popular implementations of fungible and nonfungible tokens, respectively, on the Ethereum ledger.
Fungible tokens are tokens that are identical and mutually interchangeable, such as Bitcoin. Nonfungible tokens (NFTs) are unique tokens that cannot be subdivided. The creation of ERC-404 blurs the lines between both fungible and nonfungible tokens.
The two main goals of this new standard are:
- Allowing a non-fungible collection to have access to fungible liquidity
- Allowing for fractional ownership of an NFT in a collection
These goals create excitement because NFTs are traditionally illiquid assets in nature, and some collections can be so expensive that the price of a single token can exclude a large portion of the market. Pandora was among the first projects to implement ERC-404, creating a collection of 10,000 tokens that can be minted into NFTs with five different rarities. Allowing an NFT collection to have a portion of its supply added to a DEX like Uniswap also helps set and maintain a floor price for the collection, which is a benefit in itself. Owning a part of a Pandora fungible token allows you to own a fraction of one of these NFTs.
These goals are great to have and I think are useful to create more interesting NFT use cases; however, the way this idea is implemented with the ERC standard creates confusion and inefficiency when it doesn’t have to.
Problems with ERC-404 on Ethereum
The initial version of this standard created a situation where if a user owned a single ERC-404 token, it existed as both a fungible token and an NFT in the user’s wallet at the same time. This also came with an invisible mapping of these fungibles to the non-fungibles in the user’s account.
If an ERC-404 fungible token is sent to another address, swapped on a DEX, or the total balance is otherwise reduced below a whole token, an NFT in that account would suddenly be burned. If you happen to have multiple NFTs, you could end up losing one that you would prefer to keep!
ERC-404 users would need to split tokens to different wallets as well as be very careful about moving any fungibles in order to keep any rare NFTs safe from being burned accidentally. This sort of extra headache renders the early version of ERC-404 not very useful because no serious fintech products would accept this level of unpredictability and risk of loss for their customers. If there is potential to use ideas from ERC-404 for things such as RWA, users need a reliable and intuitive experience using the tokens.
When ERC-404 was first released, NFT marketplaces did not innately understand what these 404 tokens were or how to deal with them. Blur was very quick to integrate the standard, but is it good to require another dApp to perform work to make sure the platform is compatible to work with your new token or dApp idea? This inefficiency is due to all dApp logic being crammed in with the code that also defines what the token is and can even do.
Solving the Problem in a Better Way
With Scrypto, all of your dApp logic is entirely separate from the logic defining token behaviors so this is never the case. If a builder innovates an interesting new idea, it is already guaranteed to integrate with the rest of the dApps on ledger without any sort of ERC process.
Building the “Ice token” with Scrypto allowed me an opportunity to approach the problems of NFT liquidity and fractionalized ownership from a different perspective. When building a dApp on Radix, developers don’t need to write code to define what a token is and what physics this token is allowed to have because Radix’s platform native “resources” already include that. Instead, developers can write logic purely dealing with manipulating these predictable assets with dApp-specific logic outside of the resource itself.
The question I kept asking myself while researching ERC-404: Why not just make distinct fungible and nonfungible states for the tokens and create a simple smart contract that will facilitate an easy transition between these states that a user can call when it is convenient for them?
Using Scrypto, it is straightforward to create a fungible and a nonfungible resource and write logic that caps their combined supply to whatever number is needed. By linking these two different resources in a 1:1 relationship, the dApp takes in a number of tokens and mints and returns only the exact same amount back to the user thus ensuring no deviation from maximum supply.
There is no longer any need to possess these tokens at the same time which removes a lot of headache. Instead of a smart contract triggering strange behaviors when a user decides to use tokens they should rightfully own, users only need to worry about converting tokens between states when interacting with the specific smart contract built for that task.
Using Scrypto, I decided to try to solve the goals of ERC-404 differently, which I call an “Ice token.” With this method of solving the application problem on Radix, users can do whatever they wish with their NFTs. Send them, trade them, list them all with no issues or the need to ‘dynamically mint’ fungibles in different places. Likewise, users can do whatever they wish with their fungibles. Send them, trade them, add them as liquidity without fear of losing any NFTs.
This approach also makes fractional ownership of NFTs quite easy. Converting fungibles to NFTs requires a whole fungible token. If a user decides to convert 1.5 fungibles to NFTs, they will receive 1 NFT and .5 fungible tokens change. Converting NFTs back into fungible tokens always results in a whole number of fungibles.
An added benefit is that none of this requires a “new standard” on Radix at all. The ice token is really just a pattern of building a dApp that uses the tools that Radix provides and will work “out of the box” without the ecosystem having to agree to new special treatment, like ERC-404.
Ice token happens to have slightly different logic than Pandora’s for minting. Ice minting logic is set to maintain constant percentages of rarity for each possible metadata. This could easily have used the same methods that Pandora used. The point is that any desired business logic can be inserted to manage minting and manipulation of these non-fungible and fungible tokens.
I think once this newer more intuitive and asset oriented paradigm of building reaches the masses, it will be quite obvious that standardizing behaviors at the resource level is the correct design choice for building smart contracts for many reasons including safety and compatibility. This is just the beginning of the NFT tech on Radix expanding and working towards building things that are only possible on the Radix ledger.
Ice component repo: https://github.com/aus87/ice_rrc404v1