Slides are here: https://drive.google.com/file/d/1tT9v2Ib-ymx9I-_PnC0eFGtDxH_MCOco/view?usp=sharing

Jayden from Future Primitive (https://www.linkedin.com/in/jayden-windle-79b0bb68/) delivered a talk on ERC 6551: https://eips.ethereum.org/EIPS/eip-6551

My name is Peter Robinson and today at the end, you know, this is the Ethereum Engineering Group Meetup.

And today we've got Jayden who's going to talk about ERC 6551.

And so Jayden, why don't you tell us a bit about yourself and tell us and then maybe present your slides and tell us all about ERC 6551.

Let me know when y'all can see my screen here.

Excited to chat with you guys a little bit about ERC6551 and some of the things we're working on.

I work with a company called Future Primitive, where we are a on-chain product studio.

We do a lot of weird experiments in web through, build products, we build NFT collections, we build tooling, we do a lot of stuff.

And recently, we've spent a lot of time building experimental NFTs.

We've been thinking a lot about what does an NFT look like when it's more than just an asset that sits in your wallet and when it can do more than that.

So we've done some weird experiments, like what if you had 2 NFTs that could talk to each other?

We've done some experiments with burn mechanics.

Benny, 1 of our founders, was on the founding team of CryptoKitties and, you know, later went on to launch Cheese Wizards and NBA Top Shot and worked at Dapper building a lot of these kind of new novel NFT experiences that brought a lot of people to the Web3 ecosystem.

And so we've got a lot of experience playing with NFTs and ERC 6551 came from that.

We've been working on some projects where we wanted to build out some equippable features into an NFT project.

And we went down all these different rabbit holes of using all sorts of different tools to build that.

And we hit on this idea that really resonated with us.

We were like, what if we just gave every single NFT out there its own wallet?

What if NFTs could own wallets just like you or I could own a wallet.

That would mean that every single NFT out there would be able to own other NFTs or own ETH or own ERC20s.

When you give an NFT a wallet, you let it own any assets that exists on chain just out of the box.

It also means that you give NFTs the ability to take actions on chain.

So if I, as a user that has a wallet, can go and mint another NFT, my NFT can now go and do that same action as itself, as its own self-contained identity.

Or my NFT could go swap coins on Uniswap or whatever action you wanted.

And third, it means that the NFT has its own identity on chain, its own wallet address and its own transaction history.

It records on chain a history of all the actions that NFT has ever taken.

And so as we were building out this project, we kind of stumbled on this idea of what if we just gave every NFT a wallet?

And for us, it solves a lot of a lot of our use case.

We're like, oh, what if the NFT just owned its own clothing and then you could equip the clothing onto and off of the NFT.

It just seemed like a really good mental model.

And so we shared it with some other folks, friends who are building experimental NFTs as well.

And they're like, wow, this is really cool.

And so that's when we were like, there's more to this than just some toy NFT projects we've been working on.

This is something that has the potential to be really powerful as a standard, because when every NFT has this capability, not just some NFTs, it gets really powerful.

It gives every single NFT on Ethereum from the very first NFT ever created to the NFT project you launch next week.

Every NFT already has a wallet address, reserved, unique, and assigned to that NFT.

So I'll get a little bit tactical in this talk if folks are interested in that.

If I'm going too tactical at any point, please feel free to have me pull back and I could focus a little bit more on use cases or things like that.

But how 6550 works under the hood is, oh, actually, let me just show you a demo.

I'm a visual person, visual demos are, you know, easy for me to understand.

So let me pop open another tab here and show you what I mean.

CryptoKitties helped form the ERC721 standard.

If I go to the URL bar and I change the URL to tokenbound.org, which is a ether scan like Explorer we built for tokenbound accounts.

You'll see this CryptoKitty has this wallet address.

This wallet address is reserved for this CryptoKitty.

It's permanently bound to this CryptoKitty.

If you know about soul bound tokens, this is kind of like the inverse of a soul bound token.

Instead of a token permanently tied to a wallet, it's a wallet permanently tied to a token.

And ownership of this wallet goes wherever the token goes.

So if the owner of this CryptoKitty sells the CryptoKitty, the new owner will have ownership over this wallet and ownership over all the assets inside of it.

And so you can see this CryptoKitty owns a Coinbase Shield, a Zora NFT that it has collected.

And so this NFT is able to own any assets, even if that other asset has no concept of being owned by an NFT.

This is the collection that we originally had the idea with.

We wanted to build an NFT collection where each character could collect clothing and equip those clothing onto and off of it.

And so you can see this little sapien has its own wallet address and owns these different assets on Ethereum.

So giving an NFT a wallet lets NFTs own anything on-chain.

Right now, we're all used to NFTs existing in smart contracts, right?

There's lots of NFT smart contracts out there, and I can own a token with a specific ID, right?

For this ERC721 contract number B, there could be a token 456 and someone owns that NFT.

What 6551 does is it proposes a registry, a single contract that gives every NFT a smart contract address.

And the way it does that is by deploying these smart contract addresses using the Create-To opcode.

The Create-To opcode lets you deploy contracts to predetermined addresses, to deterministic addresses, using a salt.

And so what 6551 does is it derives that salt from the token contract address and token ID of the NFT among some other metadata.

So that means that every NFT has at least 1 account but actually has a whole address space of accounts reserved for it.

And so this registry both gives you query access to those account addresses, so that you can start sending assets to any NFT even before the smart contract for its wallet is deployed.

But it also lets you deploy the addresses at those or deploy the contracts at those addresses, which lets the owner of the NFT then control that wallet.

So in this case, token number 456 owns this account C which has a unique address on Ethereum.

And it owns this account because it owns the token.

If it ever transfers the token, the token changes hands.

But under the hood, this registry just deploys proxies, deploys normal EIP 1167 proxies, minimal proxies to implementations that implement a certain minimal interface.

Basically, it gives you the ability to own assets, execute transactions, kind of the minimum viable definition of what an account is on Ethereum.

By specifying a registry and a very minimal interface for accounts, this is what lets NFTs have wallets out of the gate.

It lets every single NFT, everything that's ever implemented the ERC721 interface to now have its own unique wallet address, its own unique address space, and the ability to own any type of asset and do any type of on-chain action.

So I'll dive in a little bit into the code here.

There is, these are the functions you can call on the 6551 registry.

You can get the account address, which is the second function here, or you can create an account.

There's 5 pieces of data that go into an account's unique address.

It's a contract that implements the account interface and is what provides the functionality for that tokenized account.

The next 3, the chain ID, the token contract, and the token ID uniquely identify a given NFT.

So that lets you know which NFT this account is bound to.

And the final called Assaults, lets you have multiple accounts for a given NFT implementation combination.

And so this registry gives you insight into every single token bound account deployed and it also lets you deploy those accounts.

Every account implements a very small interface.

By default, you have to allow the receiving of ETH because being able to own an asset is what makes a smart contract account.

It gives you an interface for executing arbitrary transactions using this token bound account.

If you are the owner of the token that owns this account, it gives some read only functions for returning the token that owns his account, the account that owns that token, and then a nonce function, which tracks changes to that account over time.

And so as long as the implementation address you pass to the 6551 registry implements this interface, then you'll be able to use the created accounts as wallets.

You'll be able to use them to interact on chain.

So there's a couple of companies that are building really, really interesting things with this.

When you give an NFT a wallet, you give it the ability to own assets, do things on chain, and do anything that you as a user could do.

And so There's an NFT company called Parallel.

They've been doing an NFT trading card game for quite a while.

They're working on this game called Colony, which is like a space mining colony simulator where all of the players in the game are actually AI agents running around doing actions.

The character is represented as an NFT on chain.

And every time it runs around and mines some new ore or trades ore for another resource, or goes and pays for something at the market, it's using a token bound account under the hood to do those actions.

So that your character NFT that you're playing the game as is actually collecting new resources over time.

It's collecting ERC20s, it's collecting NFTs.

It's actually creating new NFTs in real time while I was playing the game.

So by giving NFTs the ability to own accounts, you let NFTs play games like this as their own character.

And if you go through, you play this game a bunch, you collect all of these assets for your character.

If you go and then sell your character on a marketplace, all of those assets you've collected go with it.

So by playing the game, you're actually increasing the inherent value of the NFT you're playing the game with.

Another cool project that's using it is a company called IYK.

So they do a physical NFTs, where you embed chips and pieces of clothing or garments or physical objects.

And those objects are then permanently tied to an NFT.

What this means is all of those physical objects not only are tied to an NFT, but they're also tied to a unique account.

So IYK lets people come up to you, tap your hat, sign a signature on their phone using their finger and then mint that NFT to the token bound account of your hat.

So your hat is collecting other people's signatures over time as you're interacting with it.

Another really interesting use case people are using it for is being able to support NFTs as users of your protocol.

So Lens announced this at ECC that they're planning to support ERC-6551 accounts as users on Lens so that your NFT can have its own Lens profile and post as its own identity on this decentralized social media network.

It also means that anything representative as a NFT can now own assets and do things.

So your lens handle, which is itself an NFT, can now own assets.

So there can be things inside of your lens handle within a protocol.

So when every NFT comes with an account, that means protocols can start to adopt this pattern.

So adopt this assumption that your users might be NFTs and the NFTs that you use inside your protocol can actually own things.

It can actually collect additional assets on chain.

We've been building this for a little while.

The standards has been out for or the proposal has been out for a few months in draft form.

And we get a couple of common questions over and over again.

1 of them is, isn't this just, you know, fill in the blank.

Isn't this just some, you know, centralized company that I've heard about before that does something similar?

And the answer is kind of, but not quite, right?

We didn't invent the idea of NFTs owning assets.

You know, the earliest example that we know of was Kitty Hats, where there was a Chrome extension early on where your Crypto Kitty could collect hats and could equip the hats on your CryptoKitty.

And there's been lots of things since, like ERC-998 proposed a standard for NFTs owning other NFTs, and NFTs owning ERC-20s.

There's been a few other standards since.

I talk a little bit about why those are different than ERC6551, but to start with, there were a couple of things that we thought were really important when we were designing this for our own use case.

That we think 6551 is the only thing that satisfies all of these criteria when it comes to building a solution for NFTs to own assets and take actions on chain.

First is, if it doesn't work with every single NFT, including existing NFTs where the contracts are immutable, then it's never gonna be as valuable as it could be.

Part of the problem with earlier standards like ERC998 was that the NFTs involved in that ownership relationship, they had to both implement the standard.

And that means that most NFTs couldn't own things, but some NFTs could.

It's part of the assumption of what makes an NFT now.

The second was that not only should every NFT be able to own things, NFT should be able to hold anything, any kind of token, ETH, ERC20s, LEM55s.

If somebody creates a brand new token standard tomorrow and it's the next big thing, it will just work out of the box with ERC6551 because ERC6551 uses the Ethereum account model.

So it's just compatible with everything that's compatible with wallets.

The third was that there should be any wrapping contracts.

So some other solutions let you wrap an existing NFT, and then that wrapped NFT can be owned, rather than the actual NFT itself being owned by another NFT.

And this is a fine solution, but you lose some of the provenance of that NFT when you wrap it or when you burn it.

So, ERC-6551 works without any wrapping of NFTs.

The fourth 1 is that it had to work with existing platforms.

If your NFT can own other NFTs, but nobody knows about it, right?

The wallet you're using doesn't know about it.

Then it's a little bit, doesn't really own the assets.

But with 6551, because ownership is represented using an account, you can go and look at the contents of an NFT's account on OpenSea.

And they'll work just like any other account because OpenSea supports indexing of account contents.

So by using that native Ethereum account model to represent NFT's owning items, you get pretty much instant support with most platforms and a really easy path forward for them to support the standard more deeply.

And finally, 1 of the reasons we felt this was really important to propose the standard was that this should be fully decentralized.

There's a lot of solutions out there that let NFTs own other assets, but they're centrally managed.

There's a white list of NFTs that can use them, or there's really strict rules about what your NFT can and can't do with its account.

By specifying a registry in the actual EIP that's deployed to a known address, the whole implementation is a part of this EIP.

Anybody can deploy it at the same address across any chains and it can be a trusted source to use rather than relying on somebody's centralized registry to give you access to this.

So as far as we know, ERC6551 is the only solution that fit all of these criteria.

So yeah, I can chat a little bit more about some of the other standards if you guys would like to go into the very nitty gritty of them, but otherwise can move on.

Another question we've gotten is, why put the registry in the EIP?

If you read the EIP, the whole registry contract, the entire source code is in there, as well as deployment instructions and a canonical address at which this contract will live on any EVM chain.

Some folks have asked, why not just have an interface for registries so that anyone can deploy their own registry, rather than having 1 place that everyone points to?

1, it's a lot of fragmentation for applications wanting to integrate the standard.

You then have to go out and discover all of the registries and all of the address namespaces for all of the NFTs, then aggregate them and index them, and that's tough.

The other thing is it means that there's 2 trusted contracts in the system.

You have to trust the registry and you have to trust the implementation in order for you to trust the account contract.

Because if a registry is upgradable or ownable, then somebody could censor counterfactual accounts or something like that.

So by turning the registry into a trusted permissionless immutable contract.

The only trusted contract in the system is the implementation address that you as an NFT holder choose to use.

It also lets you have cross-chain NFT accounts.

And Peter, with the cross-chain bridge things, I'm sure you'll have some opinions on this to be interested.

But what this allows you to do is it allows your NFT, which exists on a single chain, right?

It allows the account for that NFT to potentially exist across multiple chains.

So the same wallet address that's assigned to your NFT on main net can also be deployed on Polygon or Optimism or any other chain you want to use.

If the implementation supports cross chain execution using some kind of bridge or message passing service.

And so this allows you to use your NFT on multiple change without having the asset itself cross over chains or over a bridge, which introduces an interesting new model for building NFT utility.

But There's a lot of benefits from having a single registry that's permissionless, that's deployed at a single address that anybody can deploy and can deploy on an HA.

Finally, what are the problems that exist?

There's this whole world of cool new use cases that we can have for NFTs.

There's 2 kind of things that come up when thinking about this.

If an NFT can own other NFTs, that means that an NFT could own an NFT that owns an NFT that owns an NFT.

And you've essentially created a tree of NFTs, a graph of NFTs.

But what that means is you could potentially introduce a solution where this NFT owns this NFT, whoops, and this NFT owns this NFT, but this third NFT owns the first NFT.

So now all the NFTs own each other in a loop.

Well, technically, None of the NFTs own each other because with token bound accounts, the owner of an NFT has execution permissions on the accounts.

But if the owner of the NFT is caught in this cycle, nobody's able to initiate those transactions.

And essentially this is a burn mechanism.

All of the NFTs and all of the assets and all the token bank accounts tied to these NFTs get locked up and burned, which is obviously not great, right?

If you're a user innocently transferring your NFTs around, you don't want to introduce this scenario of having an ownership cycle.

We didn't specifically try and rule this out in the spec for a specific reason.

With ERC721, there's this concept of burning an NFT, where you can destroy an asset that you own.

That's your right as an asset owner to destroy that asset.

If we're gonna build a system where NFTs can self-sovereignly do things, you should have a right to burn your token-bound account as well.

Even if that's a destructive action, probably not what you really want to do, it's still your right if you want to introduce this.

So account implementations can mitigate this.

It's really easy to mitigate this in a depth of n equals 1.

But any time n is greater than 1, so if you have 3 NFTs like this, it becomes more difficult to actually prevent this because the search space on chain is infinite.

There are some other solutions we've explored with this.

What if you could have a token-bound account implementation that, if it detects a cycle has been created, allows you to eject the NFT from that cycle and regain access to it?

There's some other potential solutions there.

But this is 1 unsolved problem that we've purposely left unsolved.

People have already built interesting mechanics using this kind of burn mechanism of

And implementations that want to prevent against this, there's a couple of paths forward for them.

The other thing is the potential for fraud.

And 1 of the things that is a marker of the ability for NFTs to allow fraud on a marketplace is NFTs having state.

So anytime an NFT has state beyond just the token itself, whether that's the ability to claim an airdrop or the ability to change the artwork or the ability to adjust the rarity of the NFT.

Anytime there's something other than the token itself that represents the value of that NFT, there's the potential for fraud in the marketplace.

See all Ethereum Engineering Group transcripts on Youtube

ERC 6551: Non-fungible Token Bound Accounts