Upgrade Summit 🚀 ERC-6909 is the New Multi-Token Standard

Today, we're going to be talking about ERC-6909, the minimal multi-token interface. So, why like multi-tokens? Like why does this thing even matter to begin with, right? Well, the big, you know, obvious one is you can manage multiple tokens and NFTs within a single contract. Right?

So, you know, ERC-20, the the, you know, basically the de facto standard of like what fungible tokens are, like single fungible tokens. It's pretty straightforward, right? It's it's a single token where you can track a balance, allowance, total supply, decimals, etc., etc. Right?

Well, 6909 is similar, but it can actually track multiple in one, right? So, you know, you can have balances, allowances, total supplies, anything like that, but you can have an arbitrary number of them. I guess technically two to the 256 minus one of them. Um And so, just as like a quick like architectural comparison on this, right? You know, ERC-20 is our single token.

It's always fungible, right? ERC-721 comes along a bit later. This is the NFT standard. You know, this is it can be a single token or it can be multiple tokens managed in the same one, but they're always non-fungible, right? So, you can have token ID 1 2 3 4 5 6, but there's only ever going to be one of each one of those, right?

Um ERC-1155 comes along and it can do basically everything, right? Single token, I can do multiple tokens, they can be fungible, they can be non-fungible, right? And so, ERC-6909 is actually an iteration on what 1155 was, right? It's not backwards compatible. It's actually something new altogether, but you know, from this chart you can see like functionally they do the same thing.

And so, one of the like really big use cases and honestly the one that's that's probably most exciting here is DeFi singleton architectures, right? So, if we take a look at Uniswap V3, which this is also applicable to V2 and V1 and you know, plenty of other Dfire protocols that have some sort of factory pattern, each one of these markets, right? Each one of these these AMMs are own all their own contract, right? Each contract owns, you know, in Uniswap's case, a pair of tokens, right? And you know, every like if you want to, let's say you're doing arbitrage or maybe you're doing multi-hop swaps, right?

Things like this, you have to go between multiple markets. That's a pretty common thing to have to do, but you have to do so through external calls, right? Like these contracts have to call out to one another and this gets really expensive, you know, and even though all of the Uniswap pools individually have flash loan functionality, um you know, there's kind of a limit, right? To to what can be done with this. Like the the amount of tokens you can flash loan are limited to the amount of tokens in the individual pool, right?

So, there there's a bit of liquidity fragmentation there as well. But over here in Uniswap V4, this is still work in progress. You know, you'll notice that if if you looked into it, architecturally it's pretty similar to Uniswap V3, but everything's contained into a one singleton contract, right? Like every market is managed under the same contract and they actually use, you know, they're using ERC-1155 at the moment, you know, to handle this like multi-token you know, system. And recently I actually opened a pull request for this to try out ERC-699 just as just to take a comparison here and they are like, you know, functionally the same.

You don't lose any functionality by using either one, but there's some pretty big code size and gas efficiency savings, which we'll take a a quick look at some of that. You know, here in a little bit, but the big thing to to note here is that like more and more Dfire architectures are going to be trending towards this singleton pattern. You know, both for for liquidity reasons and for like gas efficiency reasons in the future. So, why not 1155, right? I've mentioned a couple of times that they're basically functionally identical, but why you know, why will be switch this out, right?

So, the biggest one is simplicity. So, if you want to make a simple transfer, you know, if if you're Alice and you want to transfer a token to Bob, you have this pretty complex flow chart. Obviously, you want to check, make sure they have balance because of the way that 1155 does its transfer system, you also have to check if the sender is the caller. You know, if if they're not the caller, we have to check if they're an operator. You know, is the receiver a contract?

If so, do they implement that? Do they revert? What do they do? I mean, it's it's a mess, right? ERC-6999, on the other hand, pretty straightforward, right?

Does the sender have balance? If so, send the tokens, right? Otherwise, we throw some kind of error. So, it's a pretty straightforward simple system here. Now, the other big thing is code size, right?

The reason that that this even came up with Uniswap is that Uniswap's getting pretty close to the code size limit, you know, for um you know, for their for their singleton contract. And so, um I just a quick side-by-side comparison, these guys come from the Soulmate repo. Um and these are just a mock like 1155 and 6999 contracts here. And you can see that the code size difference is is pretty drastic for something that's that's more or less functionally identical. So, what do we do about this?

Like, what what do we do with this information? Well, the simplest one is we can go ahead and start replacing these things, right? So, um you know, in terms of like what actually is like really like divergent here, right? Is there are I think two or three different things that 1155 does that, you know, we kind of found to be not necessarily useless, just they don't get used in production by many protocols, right? The big one is batching.

You know, so, creating like a a batching system in uh, in the specification itself requires that everybody implement the same batching scheme and uh, you know, for gas efficiency reasons, code efficient uh, code size efficiency reasons, like there are different variations you might want to take on something like this, right? Like different ways to um, a different ways to do the batching systems and I don't think, personally, um, yeah, that this is something that uh, EIP should constrain. This should be something that protocols individually can choose. The protocol teams can choose to constrain themselves. So, that was kind of the motivation behind removing uh, that bit.

The other one is callbacks, right? So, like I mentioned earlier in the flow chart, there's like this this back and forth of making sure like are they a contract, are they not, are they returning the right things? Um, there's a there's a lot of that there that isn't necessarily um, useful for for many use cases, right? And in general, when protocols want to create, you know, these kinds of systems, they tend to just build their own callback systems and um, you know, that like it the the the specified callback system is still there, but it doesn't get used. There's like a different callback system that gets used instead, so the idea is just remove that from the standard and let protocol teams kind of decide on how they want to do their callback systems.

Um, so as I mentioned earlier, you know, Soulmate has an implementation of this. Um, Vectorized also created one in Soul Lady, uh, super super optimized implementation of it and then um, yeah, I have a reference implementation. This is what's linked in the EIP. Um, just a pretty bare-bones. It's not really optimizing for gas efficiency or code size in this last one, the the reference implementation.

It's mostly just uh, for readability sake, so it's very clear, you know, what the standard is actually doing. So, uh, TLDR on everything, kind of summarizing stuff here. Uh, ERC-6909, it's gas and code size efficient. It's removing a lot of, you know, unnecessary things um, and reducing code size because of that. Uh, it's a drop-in replacement for ERC-1155.

You can manage multiple tokens in one contract. These can be fungible, non-fungible, it can be a mix of both, it can be semi-fungible, etc. etc. Um, and this can be used for like authentication schemes, right? You can do a token-based off system.

You can create NFT collections with this. There's a metadata extension in in the EIP as well. And it can also be used for singleton DeFi architectures for, you know, a pretty pretty wide range of problems.