ERC20721, the origins of the ERC404, interview with its developer Serec Thunderson

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 owned NFTs from actual ownership of liquidity, which means uniswap buys are disabled for any amount over .99 tokens (as more would require transfer of NFTs from the pair). With buys disabled and developer asleep, the only thing that could happen are sells.

It’s been over a week since then, and we have simply been developing the best systems that I can, addressing (some of the) problems of current live instances.

The PANDORA project, which has a daily trading volume of $25 million as we speak, was inspired by your work. They called their token an ERC404. Can you explain the difference between ERC20721 and ERC404? and the history of events?

The differences are vast, yet narrow at the same time. In terms of narrowness, their fork method remails quite true to the original implementation in regards to the logic, events methods, and pair/whitelist systems. But it’s very, very different (at least their current iteration) in that there is no permanence to NFT IDs — that is to say if you have a token-NFT that is a certain ID, when transferred that ID is burned and lost forever. I’m sure they’ll patch it if they haven’t already. It’s also drastically different from our in-house contract that I’ll opt to withhold.

The history of events is quite convoluted, nasty, and probably worth a piece in it’s own right. Here’s a simple quote from the Pandora founder for some condensed framing: “You don’t need to buy it. What’s important here is that @SerecThunderson gets mogged and doesn’t get his rent money out of this. It’s also important that his idea sees the light of day without him getting literally any credit for it whatsoever.”

We had private calls before their launch, and my V2, where they offered to help. On the phone call, it slowly became apparent to me that this team and I were not a good fit. I had told them there was a fair chance I wouldn’t go with the plans they had laid out for me, but had asked for their socials so I could research them. It’s at this time they launched their smear + promotional campaign, and closed communications channels.

I’m happy for the success of the idea of fungible NFTs and hope for its continued development.

According to Foresight News, Etherscan should soon fully support ERC404 contracts. Are you in contact with any of the big players in the ecosystem, CEX, DEX, scans, etc. to integrate this?

No, I’m not in contact with any big players or anything like that, just quietly building. I think it might would be an unfortunate rush on Etherscan’s part to mould its system to 404 so soon, with the “standard” not yet remotely reaching standard levels. There are ways that 404 and its forks do not work with Etherscan, that can and should be fixed contract-side, before changing the Etherscan system.

DN404 has a two-contract system for fully fungible NFTs that solves a lot of the issues, and will work with Etherscan with no issues. It’s been a week. Let’s build the softer layers out a little bit before changing the firmer ones, maybe.

That being said, it’s very exciting news for the awareness and adoption for fungible NFT specs.

Looking ahead, are there specific areas within the NFT or DeFi space that you believe require further innovation, and do you foresee ERC20721 playing a role in addressing those needs?

Yes, and yes, at least to some degree. I won’t be calling my next contract release ERC20721, nor do I expect it to have adoption. I expect fungible NFT spec, and the ideas behind it to stick around, and lead to new fun developments.

There’s so much room for innovation overall in the space that I stay stunlocked in option-paralysis. My mind, coming from old economy system MMOs, is always on gamification and virtual commodity/value at scale.

Are you going to continue working on this project? Do you plan to improve it?

Definitely. It’s apparent that credit or not, the things I make get propagated if useful. In the last week I think we’ve made some amazing improvements in our complete rewrite of the single-contract ERC20+ERC721 spec. There are a lot of improvements and explorations left with these systems, and I intend to play my part. Many systems can be built off of these ideas.