ERC20721, the origins of the ERC404, interview with its developer Serec Thunderson
ERC20721, the origins of the ERC404, interview with its developer Serec Thunderson interview 16/02/2024 16:06 In this captivating interview, we delve into the innovative realm of ERC20721, a pioneering smart contract that merges the functionalities of ERC20 and ERC721 tokens to enhance liquidity and distribution of Non-Fungible Tokens (NFTs). This groundbreaking approach addresses the challenge of liquidity in NFT markets by allowing seamless exchange and liquidation of assets without the waiting periods typically associated with NFT transactions. The inception of ERC20721 has paved the way for the development of ERC404, with the first token under this new standard launched on February 1st, followed closely by the Pandora project on February 5th. Through this dialogue, we explore the motivations, challenges, and aspirations behind ERC20721, its impact on the NFT and DeFi spaces, and its role in the broader evolution of trustless systems and decentralized virtual machine services. Interview with Serec Hello Serec, before we start, could you introduce yourself? How long have you been in the ecosystem? How do you see it evolving since you joined? Well, how long depends on what you mean by in. My first bitcoin transaction was in 2012, my first EVM transactions were in 2021. My first smart contract deployment was in 2021 as well, but it would be some time from then before I started making more interesting things. I can’t speak too much on the evolution of decentralized virtual machine services and free exchange since I’ve been actively participating, as I am spending most of my time “catching up” on my ignorance. To me, the future seems marked by fritction-reduction, and continued application of trustless systems to new concepts, and old web2/paper concepts where trust has previously failed the masses. Can you explain what ERC20721 is? What is it used for, and how can the liquidity of ERC20s improve the exchange of NFTs? “ERC”20721 was the first iteration of what is now many, of a smart contract that (intends to) seamlessly blend the shared functions of ERC20, and ERC721 in order to massively reduce participant friction, and increase liquidity/distribution of NFTs. Liquidity is inherently improved for NFTs in the sense that there is never a waiting period should one need to liquidate their asset. I hope to see more projects that are launching in the future, opt to use fair launch methods via Uniswap V3 concentrated pool options, though. In which use cases can this new standard be revolutionary? I think the concept makes interacting with NFTs fun and easy in a way that it wasn’t quite before. The applications are limitless! But, no more or less so than the rest of EVM. I expect to see a number of really cool applications to and iterations upon the idea of fungible NFTs (sorry erc1155) in the near and medium future. I hope all of this has sparked at least a few people’s interest in learning to understand smart contracts or code, even if it can seem so daunting. What about gas costs? It seems to me that the cost of an ERC20721 exchange is much higher than an NFT exchange or an ERC20 exchange. Do you think this can be reduced? Gas costs can and have been reduced. You can see the work of the DN404 team which has been incredible so far (and they seem inclined on continued improvement), the Pandora team has recently posted some optimization stats, and our own in-house developments are looking quite optimal as well thus far. There’s so much work left to be done with the spec(s). It’s been just a week. How long have you been working on this project? Have other projects inspired you? sEReC20721 was a joke for a long time; “What if I put the NFT in the token? :^)”. But I was always at least half-serious about it. The thinking around it arose from my initial project(s) being related heavily to ERC20s, NFTs, and blurring the lines. It’s only as I have continued to learn that I realized it was actually possible, in the way I wanted (one smart contract). I spent a lot of time writing, iterating upon, making modules for ERC20 and ERC721 separately; it was one day (December 11th) I was doing both, that the function overload method revealed itself to me. I laughed a lot, it was the funniest smart contract I could possibly make. I already had some pieces to work with from prior attempts. Unisocks is a historic and major inspiration. Unisocks are fungible NFTs, it’s simple as. ERC1155 is another huge source of inspiration; the ideas behind it are amazing, fungibility, nonfungiblity, semifungibility all in one system. Unfortunately not many user-end dapplications work too well with them yet, nor do many devs do so either. ERC20 and ERC721 are earnest inspirations. Another facet that made this come to fruition is my first project being a runescape-inspired, 1000 supply ERC20 with 0 decimals back in 2021. The contract is so bad. Ever since launch, I started thinking of NFT conversion methods, and we released one soon after. We too, had our “fungible NFTs”, though the system was kind of awful and you had to click so many buttons and wait — it was not and is not a good or easy system for anybody to participate in. Years of this awful system and thinking about related topics, fungible NFTs were inevitable. Unfortunately, the first ERC20721, the one you deployed on Ethereum, the Emerald, was hacked. Can you explain what happened? Unfortunately yes, the first deployment was exploited in a way that let the attacker(s) effectively drain tokens from liquidity, to be sold immediately to liquidity. This was due to a small additional exclusion involving liquidity address in a very, very convoluted transfer function. Desperate to fix things, and compelled by external and internal forces, I deployed a V2 which I had faith in, to have no exploit whatsoever of that sort. Unfortunately, the V2’s exploit enabled a greyhat to break the parity of “the list” of