Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. Jaden Windle and Benny Zhang of NFT Studio Future Primitive joined me on this episode to discuss ERC-6551, non-fungible token-bound accounts, which they co-authored. ERC-6551 is a draft EIP that proposes a Create-2-based proxy contract scheme to give every ERC-721 its own address on Ethereum and other EVM chains. In short, this EIP turns every NFT into a smart contract wallet, which can hold NFTs and fungibles, have special access permissions on other contracts, and more. 6551's flexible yet simple design allows NFTs to own NFTs that own NFTs, and so on. In this conversation, we discuss the prior art for NFT-bound accounts and the specific technical choices that may make 6551 a more universally compatible and extensible option. We also consider NFT accounts' compatibility with account abstraction wallets like those covered by EIP-4337. Finally, we discuss the social process of writing and carrying a proposal through the EIP process. It was great sitting down with Jaden and Benny to discuss the ins and outs of their NFT account proposal. I hope you enjoy the show. This episode of Web3 Galaxy Brain is brought to you by Interface. Interface is an iPhone and Android app that allows you to follow Ethereum wallets and track their activity across Web3 through push notifications and a Twitter-like scrollable feed. Check it out at interface.social. My thanks to Interface for sponsoring the show. If you'd like to sponsor an episode, visit web3galaxybrain.com for details. It's as simple as minting an NFT. As always, this show is provided for entertainment and education purposes only and does not constitute financial advice or any form of endorsement or suggestion. Crypto is risky and you alone are responsible for doing your research and making your own decisions. And now, on to the show.

Jayden Windle: Hey, how's it going?

Nicholas: Hey Benny. Hey Jaden. How's it going?

Benny Giang: Oh, hello. Going well.

Nicholas: Thanks for coming on the show today. I'm excited to talk about ERC-6551.

Benny Giang: Yeah, for sure. Thanks for having us. Looking forward to it.

Nicholas: So maybe just to get started, could you give us a little bit of a background? I know, Benny, you worked on CryptoKitties. Is that right?

Benny Giang: Yeah.

Jayden Windle: So yeah, last six years, it's been a really fun journey. Started off, well actually, you know, started off in a venture studio launching a bunch of different startups that had nothing to do with crypto. But yeah, in the latter part of 2016, we had a blockchain exploration team at this venture studio and that's where CryptoKitties came out of. So yeah, 2017, we launched CryptoKitties and then formed Dapper Labs and then I continued working with the team on Cheese Wizards and then VietaShot. So it's been a really fun journey so far.

Nicholas: So you're part of that Vancouver NFT mafia?

Jayden Windle: Yeah, I don't know if it's a mafia, but yeah, we are certainly, me, Jaden and a bunch of us are based in Vancouver.

Nicholas: Cool. And Jaden, did you also work at Dapper?

Benny Giang: Unfortunately not. I never had the pleasure. A friend of mine went and interned at Dapper and I went other places. But then about a year and a half ago, that friend was like, hey, I got this friend named Benny who's doing some crazy stuff with NFTs. You guys might get along pretty well. So we started working on Future Primitive together.

Nicholas: Awesome. Yeah. So tell me a little bit about Future Primitive. Who is it? Is it based in Vancouver? What's the mission? Yeah.

Jayden Windle: So Future Primitive is a on-chain product studio. It was founded by me and Steve Chang, who is my co-founder on this studio. Steve is based in the Bay Area, San Francisco. He spends most of his time during the day actually as a VC for Kindred Ventures. So me and him met and I was on the way out of Dapper and he had this idea of a venture studio or product studio for a while now. We shared a lot of similar perspectives on culture and Web3. And yeah, pretty much like a week after I left, we formed Future Primitive and Jayden was one of the early founding team members that came on board and has been with us since nearly a year and a half ago. And yeah, so we're a team of seven, including me and Steve. And majority is based in Vancouver. We do have one team member in Florida and then Steve's in California, in San Francisco.

Nicholas: And so I want to get into the 6551 discussion, but I have to ask first. So having worked on Topshot, having worked on Flow, is Future Primitive focused primarily on Ethereum? Do you have thoughts about the expansion of NFTs to other chains, maybe more centralized chains or non-EVM chains? Do you have any reflections on this experience?

Jayden Windle: Yeah, we primarily right now, Future Primitive focus on EVM chains, specifically Ethereum mainnet as our main playground. As you all know, CryptoKitties started on Ethereum and same with Cheese Wizard. So yeah, I think it's good to be back. A lot of things have grown. I remember in 2017 and 2018, so many things were not built. And it's just tough for people to come on board. And so I think every step of the way these last six years, regardless if it was other alternative layer ones or big brands coming in, I think they all served a really important role in onboarding new people into this space. Many people don't know but NBA Topshot had more than a million signups. And early days of board apes, I remember I was in Clubhouse and a lot of these clubhouses or, I forget what they call them, but like spaces or sessions or whatever. A lot of it was. actually a lot of people were from NBA Topshot and they kind of got bored and wanted to hang out in Clubhouse. And then nearly 30 to 35% of the initial board apes community were from Topshot. So I think everyone served a really important role regardless if it was Flow or NBA Topshot. And at least for us, what's really fascinating is this huge amount of history that exists on Ethereum. And specifically, watching the live stream of the merge happen. I think that was to me was a really important moment in the history of all blockchains. And that was kind of like the moment that inspired me to be like, hey, you know what? Everyone talked a lot about scalability and pointing fingers and like, Ethereum is bad for this and all of that. Gas fees, all of that. And I think we got to take a step back and really give props to the Ethereum Foundation and everybody who worked so hard. And it worked. They successfully completed the merge. And so I think, I mean, what else could be a bigger proof than a team that can execute and deliver on that? So yeah.

Nicholas: Yeah, I definitely think we'll look back on this time and remember that as much more significant than any of the CEX failures, etc. I don't think they'll be nearly as memorable as the switch to Proof of Stake and the merge and all this. So I guess let's just jump into EIP-6551. I mean, I guess one way to transition is the return to Ethereum mainnet, the focus on the kind of NFT art and collectible value that's created on mainnet. You've chosen to, I take it, from reading the spec and doing some research into the prior standards that have been proposed, 6551 is a very simple and elegant solution for this non-fungible token-bound account problem. Would you like to take a stab at explaining what the problem is and how this solution works?

Benny Giang: For sure. Yeah, 6551 is super interesting. It came out of a lot of the projects that we were working on. And one of the things that we spent a lot of time at Future Primitive on is like, how can we take NFTs beyond just a static asset? How do we make this more than something that you just buy and sell and trade? But how do we build more things with NFTs? How do we give NFTs the ability to be more? And so we built a lot of crazy things in that regard. We've done like, we built like pager NFTs, like 90s pagers. And the only way you could get one was by texting your wallet address to a phone number and it would be airdropped to you. But then you were part of the pager network. So you got text messages whenever anybody sent text messages to that phone number. Kind of experimenting with what if NFTs could talk to each other? And a lot of these experiments we've done have been in that same vein. And really the challenge is, right now, if you want to do unique, creative things with NFTs, if you want to add additional on-chain utility to NFTs, most people just kind of roll their own solutions to it. Or they pick one of the existing kind of standards or projects or platforms to build on. They come with a lot of limitations. And part of the reason for that is a lot of these other projects and things that are trying to add the ability for NFTs to own other NFTs or NFTs to be able to take actions. They're kind of dancing around this concept that NFTs don't really have the capabilities to own things by default. Right? The 721 spec is really simple. It's this item that is uniquely identified that can be transferred between multiple wallets. And really on Ethereum, kind of the universal layer of compatibility between anything is a wallet. So we kind of after building a lot of things, we realized that like, if NFTs have wallets, NFTs get to participate in the Ethereum ecosystem at the same level that anyone can. And that means you can build unlimited utility for NFTs on top of this. And NFTs have all of the collective utility of the Ethereum space just at their disposal from day zero. So what 6551 does is it's super simple. It proposes a single registry contract that gives every single NFT that's ever existed from KrippleKitties to the project that launches tomorrow a unique wallet address, a unique smart contract wallet address that only the owner of that NFT will ever be able to control. So you can think of it like a token gated wallet. And so that means that every single NFT can now own assets. Every single NFT can now interact with applications. Every single NFT gets the full power of a wallet. And so for us, this represents a really big shift in the amount of things you can do with an NFT, the amount of things you can build on top of this primitive of NFTs.

Nicholas: Extremely cool. Yeah. So maybe you could go a little bit into the details of how 6551 actually works, because I think it's super interesting that you're able to use Create2 and counterfactual addresses to give tokens, give NFTs their own smart contract wallets even in advance of anything being deployed. I don't know if people, maybe they've heard of 6551, but they might not realize exactly how it works. I was taking a look at the, is it token.bound? Is that the, or tokenbound.org I should say?

Benny Giang: Tokenbound.org. Yeah. So that's a website that we've spun up. We're kind of, it's kind of like the Etherscan for these token bound accounts. You can see the account for every NFT. You can explore the assets it owns and you kind of have a window into this whole 6551 world there. But yeah, so for those that are familiar, there's a couple of ways you can deploy smart contracts in Ethereum. The normal way uses something called Create, which just create a contract and that contract gets a unique address based on some factors that are largely under your control. But there's a second way to create smart contracts using Create2. And what that lets you do is that lets you control the address at which your contract will end up being deployed. And so you can know ahead of time before you ever deploy that smart contract, which address it will eventually be deployed to when it's deployed. And people use the word counterfactual to describe it. So if you're counterfactual wallet or counterfactual smart contract, that's what they're describing is, you know, the address at which something will exist before it exists as a smart contract on chain. And so what 6551 does it? by proposing this single registry that, you know, nobody owns its public good, like anybody can deploy it at the same address across any EVM chain. By prescribing the single registry that contains the wallet addresses for all token bound accounts, you get that counterfactual ability for all wallets that are deployed via that one registry. So basically what it does is it says that the address that you get as an NFT holder, your token bound account address is a function of the contract address and token ID of the NFT. And so you as an NFT holder know that you get a unique address for your NFT, a unique wallet for your NFT. And that when that contract is deployed, no matter whether it's you who deploy it or the collection creator that deploys it or some random person who wants to pay your gas, whenever the contract comes into existence at that address, it will be securely owned by you, the NFT holder. And so that's kind of the magic of 6551. By separating the wallets from the NFT contracts themselves, we can give a wallet to every single NFT that's ever existed. And you as an NFT holder know that that wallet is secure.

Nicholas: And that fact that it applies retroactively to all NFTs, if I understood correctly, any NFT contract that has an owner of function is compatible. That means that's an improvement on like I saw in 998 was a previous proposal in this direction, which had a well, judging from my skim, at least a significantly more complex solution that's also not backwards compatible with prior NFT deployments as far as I understood it. So one of the big advantages here is that I could send ERC20s or other NFTs to an address that I know in advance belongs to a given NFT before the owner has interacted with these NFT owned accounts at all. And it'll be perfectly compatible as long as it's not like a CryptoPunk, especially.

Benny Giang: Yeah, exactly. So this will work with every NFT that supports owner of. But really, this can be extended to support existing things like CryptoPunks or other types of NFTs if you want to. Right now, the implementation that we've built and we're running with only supports 721s or really like any NFT that has an owner of. So name wrap, ENS names count under that. Yeah, essentially it's a token gated wallet. So as long as the wallet has some way of gating based on token ownership, it'll work out of the box or it'll work with 6551. But yeah, you can. you can know the address for any NFT ahead of time. You can start sending assets to these addresses before the contracts are deployed and those assets will be held securely on behalf of the NFT owner. And really, when we took a look like we've we've been building experiments on top of NFTs for a long time and and we've played around with all of the existing tooling that we've done some stuff with 9N8s. We've experimented with some of the newer proposals that are in that same vein, experimented with some of those centralized projects that have this. And ultimately, a couple of the big failure modes we've seen are that a lot of them make you write all of this logic into your NFT contract. So you as an NFT creator have to decide before you even launch your project, what utility you want to give to your NFT, what assets it's going to be able to own, how it's going to be able to own it. And because all that all that logic lives on the NFT contract, you can't really upgrade it in the future. I mean, you can do some things with upgradable contracts, but largely it means that you're stuck with what you have when you deploy the contract. The only way to get around that is to do crazy things like wrapping your NFTs, which comes with its own issues. And so by having by making everything inside the 721 contract, you're forcing creators to make this decision right up front about which type of utility they'd like to support. And right now, most of those are limited. Right. Like if you go and use 998 in your NFT, it will only support ERC721 tokens and ERC20 tokens. And the reason for that is it wasn't forwards compatible. Right. ERC1155 came along after ERC998 was created. So ERC998 doesn't have the ability to support ERC1155 tokens because it just predates it.

Nicholas: And so in general, it won't have arbitrary affordances for whatever might come in the future, not even just token standards. But my understanding is that 6551 would allow you to do anything that a contract can do. Right.

Benny Giang: Yes. Correct. Exactly. So if you stop short of giving an NFT a wallet and you just try and kind of create an NFT contract that has wallet like characteristics, you're kind of locking yourself in to not being able to support what comes in the future. Because if somebody launches a new token standard tomorrow that takes the Ethereum world by storm, you can be virtually guaranteed it will be owned by wallets. What you can't guarantee is that it will work with this custom NFT contract. So by giving every NFT a wallet, you really unlock a crazy amount of compatibility with the ecosystem. So it's fully forwards compatible with anything coming down the pipe.

Nicholas: Very cool. So if we jump back a little deeper into the contract. So there's a registry contract interface and an account interface described in the EIP. Maybe you could explain a little bit about how it works in terms of querying to find out what an NFT's address might be and also creating an account for an NFT.

Benny Giang: For sure. So the registry is the kind of single entry points across any chain for these token bound accounts. The registry is where you can go to deploy the smart contract account for an NFT. It's also where you go to query the address for that smart contract account. And so really the core of 6551 is let's all agree upon a single entry point contract across all chains. Let's make sure that entry point is publicly owned. It's not like nobody actually owns the smart contract. Anybody can deploy it and it can live at the same address across chains. If we can kind of come to consensus that that is a valuable thing. What we unlock is unlimited deterministic accounts for every NFT, which we think has a lot of power. So the registry is kind of the central entry point that you go to query the addresses for NFT token bound accounts and you go to deploy those accounts. The account interface is a separate thing I can go into if you have a question.

Nicholas: Yeah I just had a quick question. So there in addition to the interface for the registry that's provided in the EIP, there's also a reference implementation, I guess, in order for you to be able to get that deterministic address across all chains.

Benny Giang: Yeah, correct. Yeah. So the whole source code of the registry is in the EIP as well as the details for how to deploy it to the canonical address. So right now, until the EIP is finalized, that canonical address is a little bit in flux. But once the EIP is finalized, you'll have like just by reading through the EIP, you as somebody who wants to use this EIP on a chain that doesn't already have the registry deployed, you'll be able to go in there and deploy the registry yourself. And it will exist at the canonical address and it will just become part of the 6551 ecosystem out of the box. Anybody that supports 6551 things on that chain will know which address to look at. And so having a single entry point across all chains that's permissionlessly deployable is really important because it gives every NFT that deterministic account capability. If there were multiple entry points or multiple registries, then you know, accounts or sorry, applications looking to integrate with that would be like, OK, which registries do we want to support? You know, what are the different features of the different registries? And so, you know, instead of having just like a standard interface for registries, it actually prescribes the full source code of the registry and the way you deploy it to the canonical address. That means that everybody who wants to integrate with 6551 can go through one entry point.

Nicholas: So instead of having like in, I don't know, Uniswap V2, you're multiple instances of the same concept, but no canonical access point, the reference implementation solves that with its deterministic address. You were going to explain also the account interface and how it relates to the registry.

Benny Giang: Yeah, for sure. And so they're a little bit separate. You can have just the registry without the account interface. But what the account interface brings to the table is that, you know, that every contract deployed via the registry will have some minimal features in common. You'll know that any of these token bound account contracts that are deployed, you'll have a way to introspect the token that owns that account. You'll have a way to determine who owns that account, like who owns the token that owns that account. You have a very minimal way to execute transactions against that account. And so by coupling a central registry or a single registry through which all token bound accounts are deployed and a common language for interacting with all token bound accounts, regardless of the implementation behind the scenes, that means that you can have apps built on top of this concept that every NFT has a wallet by default. And you can just build that into your application knowing that no matter what wallet implementation they're using, no matter what chain they're on, no matter what NFT it is, you know how to query the wallet address and you know how to interact with that wallet.

Nicholas: Now, one thing that's maybe not as obvious for people who haven't taken a deep dive into the text of the EIP itself is that the registry allows you to pass your own implementation. So if I create a contract account or an account for an NFT using two different implementations, I will get two different addresses for it, correct?

Benny Giang: Yeah, correct.

Nicholas: So is there an expectation that, I mean, at least at first, I imagine you're using the same implementation across all accounts. And so they all behave the same and they have whatever additional interface affordances in excess of the account interface that you suggest in the EIP itself.

Benny Giang: Yeah, so for now, we've built an implementation that works out of the box with 6551. And so when you go and interact with tokenbound.org, that's what you're interacting with today. But anybody can build their own implementation and bring their own implementation. So if you want to customize your implementation to build some specific features that your DApp needs, you can use all of the tooling and specifically all of the platform support for ERC 6551, but with wallets that do something that you need them to do in your project. And so by making the implementation customizable across 6551 accounts, that means that both you as the NFT holder, you have full choice as to which type of implementation you'd like to run, kind of like choosing between whether you want a Metamask wallet or a Rainbow wallet or an Osus safe. You can do the same kind of thing with 6551 wallets if you're an NFT holder. And, you know, on the other side of things, DApps can build 6551 implementations that go beyond the spec and introduce new and interesting ways that you can use NFT wallets while still being able to be plugged into the ecosystem. So, you know, the ultimate thing we're working towards, which is if OpenSea supports the standard natively and you have this concept when you're trading your NFTs of this NFT has a wallet and all the assets in the wallet go with it on a sale. If your DApp goes out and builds a custom account implementation, you'll still be able to take advantage of that OpenSea support. And so by having a single entry point and a single language for communicating with these token-bound accounts, you unlock an unlimited amount of creativity on the side of the token-bound account implementations while still making it really easy for everybody to every app, every platform, every wallet and ecosystem to integrate with this concept of NFTs having wallets.

Nicholas: So it is conceivable then that the original implementation of the accounts that you've provided will be something that should this standard become popular, people can assume that NFTs have an easy route to instantiating the contract at that known address. This sort of OG implementation. But other people might have a reason to develop alternate implementations that would give multiple wallets to the same NFT smart contract wallets. That is. Can you imagine a scenario where that would happen? Or I'm trying to think of what it means for an NFT to have potentially multiple accounts, not only one.

Benny Giang: Yeah, so this is a really interesting part of 6551 that is kind of underexplored because right now we're kind of trying to get people used to the concept of, hey, your NFT has a wallet. That's enough of a brain explosion moment. But going too much further down the rabbit hole is kind of tough. So we've talked a lot about NFTs having a wallet. But what 6551 really does is it gives every NFT an infinite number of wallets. In the same way that you as a normal Ethereum user, you can have as many wallets as you want. You can just keep hitting add wallet and MetaMask all day long, where you can have different wallets across different applications. We think that NFTs should have the same rights. I think kind of the underlying thesis of 6551 is that NFTs are identities. They are their own self-contained identity. And what 6551 gives them is the ability to actually use that identity on chain. Right. Without a wallet, an NFT is just a thing that gets passed around from wallet to wallet. But with a wallet, an NFT is its own self-contained identity that can own things and do things. It has the same rights on Ethereum as you as a human user. And so that kind of philosophy of giving NFTs self-sovereign access to on-chain things drives a lot of things, including the ability to have multiple wallets. So if you as a normal Ethereum user can have multiple wallets, the same should be true for NFTs. They should be treated the same as any other user on Ethereum. But yeah, so the way we kind of see it playing out is we would love to see lots of experimentation with implementations. I think client diversity in any kind of an ecosystem is really important. And the custom implementation allows for a lot of client diversity among token-bound accounts while still maintaining a common interface for interacting with them. So you can do crazy stuff. You can have a token-bound account that only works on one day of the year. You have like a purge token-bound account, I guess. If you want to do that for your NFT collection or for some Dapp you're building, go for it. You can use a custom implementation. It'll still work out of the box with all the other tooling around it, around 6551. But you can do really weird, creative things with account implementations. So we see they'll probably be similar to how smart contract wallets are right now. There will probably be a number of implementations that are the most commonly used by apps implementing this. Like, you know, people think of smart contract wallets, they think of Safe, they think of Argent, they think of a couple of other ones. That'll probably be the same here, but with a very long tail of experimental, crazy, creative use cases for custom implementations.

Nicholas: Got it. Speaking of sort of compatibility with other things, and you mentioned some other contract wallets, I noticed that it is 4337 compatible. Maybe you could explain, especially for people who are not super familiar with 4337, what it means to be compatible with account abstraction in this context.

Benny Giang: Yeah, for sure. So 4337 is kind of a proposal that is proposing a way to do account abstraction without doing any changes to the underlying Ethereum protocol. So it's a way to structure your smart contracts, kind of a common way for smart contract accounts to work. that allows a whole ecosystem to be built up of like common ways of interacting with smart contract accounts. Because we've had smart contract wallets, smart contract accounts for ages, right? That's nothing new. We've had Gnosis for ages. We've had Argent for a while. We've had some other ones that predate this whole concept of 4337 style account abstraction. But what 4337 is doing is creating a standard way of interacting with those wallet accounts. It's really flexible, but allows for this whole ecosystem of tooling to pop up. that comes with a lot of really great user experience benefits. It kind of creates this whole new way of submitting transactions on Ethereum. And so you get things like smart contract wallets can pay for their own gas rather than relying on someone's wallet to pay the gas on their behalf.

Nicholas: Even for their own deploy, is that right?

Benny Giang: Even for their own deploys, yeah. It even like 4337 even abstracts away the concept of deploying a smart contract account in that because the first time you make the transaction, the account is automatically deployed. You as a user don't even need to think about it as a smart contract. You just think about it as a wallet and all of the kind of things that happen under the hood are taken care of for you. So 4337 brings a lot of really cool user experience and developer experience benefits to building and using contract accounts. And so that's really interesting when we're giving NFTs smart contract accounts. You know, one way to think about 6551 is it's account abstraction for NFTs. Every NFT gets an abstract account. And what that means is we're one step closer to NFTs being their own self-contained identities. It's not just you as the NFT holder. You don't have to pay gas to do things on behalf of your NFT. Your NFT can pay its own gas. Your NFT can be its own wallet, can be its own thing. So in the case of 4337 support, so the smart contract account implementation that we've released is compatible in a smart contract layer with 4337, which means that you can use it with the entry point and you can use it with a lot of this 4337 tooling that's coming down the pipe to do really cool things like, you know, you can have gas sponsorship for NFTs. So, you know, some NFT collector could say, hey, we're going to sponsor gas for every NFT in our collection to do something. Right now, if you're going to try and do that with like existing holder wallets, that would be really tough. You have to have all sorts of stuff around that. We know that because we've tried to do that. You end up the best you can do is really like retroactive gas sponsorships. But with token bound accounts, you can have these wallets that you know for sure are tied to given NFTs. And so you can sponsor gas for a certain subset of NFTs to take some on-chain action with like full programmability over that. And so because of that 4337 compatibility layer, these token bound accounts by being tied to an NFT gains to really cool properties like that.

Nicholas: I want to come back to applications later, but just what you're saying is making me think of things like in the simplest case of just an NFT owned account, something like Wolf Game or other kinds of farming games where the NFT is the thing that executes the farming rather than the wallet per se. The NFT could be the one accumulating, let's just say ERC20s or other NFTs. And then in the more complicated case, what you're saying with a 4337 compatible 6551 NFT could have something like,

Benny Giang: I don't know,

Nicholas: multiple people owning a single NFT and able to execute transactions on its behalf on token gated contracts that are aware of, you know, that are token gated to that NFT collection or that specific NFT even where execution still requires, for instance, like a multi-sig type setup or something like that.

Benny Giang: Yeah, for sure. Those are both great use cases. Yeah. Any kind of like, you know, character owning items or like, you know, your player having an inventory is a really great use case for 6551 because now your NFT can own anything. Right. So a lot of these games that are currently keeping track of GameState and like one central NFT contract, now they can keep track of GameState in like a way that's self-sovereign to the NFT. So the NFTs actually own their assets rather than them just, you know, there being a single contract that keeps track of all of it. And so, yeah, if you're having wallets and able to do those things, plus it just makes the mental model a lot similar. Right. If you're building a Wolf game style thing. Yeah, I've got an NFT and my NFT collects its own wool and my NFT does things with the wool. We're very used to this metaphor of like players in a game and having inventory. And that metaphor is like not quite the same as like I have a wallet. that wallet owns one NFT and it also owns another NFT and somehow they're related.

Nicholas: Do you think that there's other? because we're starting to touch on this account abstraction multiplied by NFT owned accounts? Because initially, I totally agree. The thing that seems most appealing to me is like a character that accumulates

Benny Giang: weapons

Nicholas: or whatever experience points or something that those might as well be allotted directly to the NFT rather than in a custom mapping or something on the contract that is not compatible with, you know, that interfaces can't easily represent across a variety of contracts. So to standardize that kind of thing makes a lot of sense. Whereas like transferring ownership of like for token gating some, let's say, access control on a contract to a specific NFT rather than to a specific EOA address or contract address, but instead to this address that can be controlled by an NFT is less obvious to me. why you why you would want that transferability with the NFT. But it seems like you kind of get it for free with this really convenient way to associate skill gains and other kinds of power ups and assets with a specific kind of NFT. Do you foresee people trading like access controls via that via the NFT as well? I suppose it makes sense for anything that's token gated, like, you know, something you can mint a claimable or something like that, especially.

Benny Giang: Yeah, no, I think that's going to be really big. Like I think the potential of token bought accounts as an access control mechanism is there's a lot to explore there. And the reason for that is right now when you do token gating for access control. You're dealing with dynamic data, right? So some random wallet calls into your contract and you have to go and check if that contract owns the NFT that they're claiming on behalf of. But then you also have to keep track of the state of that NFT, right? You have to make sure that user calling in and claiming on behalf of that NFT can't just transfer the NFT to another wallet and then claim from there again. Right. And so you have to have this concept of like a differentiation between the caller address and the actual asset that's being operated upon. Those are kind of two separate concerns versus the token bound accounts just based on the address that's calling into your contract. You can know which token is being operated on and you can just, you know, instead of having to worry about that token being transferred, you can just do your access control solely based on the address of the caller because the caller can prove that this account corresponds to a certain NFT. And then that's the entirety of your token gating. It's just check the wallet matches the expected wallet for NFT and you're good to go. You don't have to worry about, you know, time delta attacks or keeping track of which NFT is claimed or not. It's just based on the wallet calling in. And so you can totally trade like permissions on a Gnosis safe as an NFT, right? You have a Gnosis safe with five NFT signers and then you can buy and sell and trade access to that Gnosis safe by buying and selling and trading the NFT. And Gnosis safe doesn't need to know anything about NFTs. It doesn't need to know that it's token gated at all. From Gnosis' perspective, it's just five wallets.

Nicholas: That's very interesting because I'm a bit skeptical of the, and I'm sure it will happen in a way that I can't possibly foresee. But somehow there's something that makes me feel like it's unlikely that people will be auctioning off their keys to a safe or something. But I mean, you know, anything will happen. But it doesn't seem like it fits exactly. But what you're saying really is that the, especially if people, there's a shelling point around, let's say the reference implementation of the account, then we go from a world where you need to, let's say I want to create a, I want to let, you know, the top 50 collections claim a free NFT from my new NFT collection. If I rely on their token IDs being true,

Benny Giang: I

Nicholas: need to go and inspect the implementations of their token management system internal to each contract to be sure that the contract owner can't, I don't know, manipulate token IDs or issue multiple or maybe their transfer function allow, or they have a dev transfer function or something that would allow someone to manipulate, as you say, like tracking which tokens have claimed. So instead, what this allows is if I want to let people claim with, say, some large number of contracts where I don't want to diligence each contract, I can use their 6551 address as a more unique ID than the ID implemented in some NFT contract that I don't have time to read.

Benny Giang: Yeah, that's definitely one way you can do it. I think, you know, one, I'm not sure if this is a weakness, it's just kind of like table stakes case for token bought accounts. is your token bought account is only as secure as the NFT contract that's powering it. Right. So if you have an NFT contract where the developer can rug you, you can also rug all the token bought accounts of the NFTs. And so, you know, the token bought accounts are only as secure as the token mechanism is. But I think you make a really good point, which is you don't have to worry at all about the NFTs or the information behind the scenes. All you have to worry about is a static list of wallets anytime you want to do any sort of authentication. So you don't have to worry about, you know, calling into an external contractor saying, hey, is this NFT, is this wallet the owner of an NFT? You can just say, hey, is this wallet part of a list of static wallets? And then that's your authentication out of the gate. So you can do something like, hey, all top 50 projects, they all get to claim one NFT per token. All you need is a Merkle tree of the token bound addresses for all of those tokens. And your authentication logic gets really easy. And if you take it even further, right, you want to do an airdrop to all of these holders. You no longer have the time delta issues that you have with a normal airdrop where you have to take a snapshot of all the holder addresses, which immediately becomes out of date. And then you do the airdrop and all of a sudden you've airdropped, you spend all this money, you know, uploading data on chain to do the airdrop. And you end up airdropping to a bunch of people who don't even hold the NFT any longer. With token bound accounts, it's a static list of wallets, not a dynamic list of owners. And that shift from dynamic ownership to static identifiers is a really big shift. It opens up a lot of possibilities.

Nicholas: So if I wanted to, I could instead of doing the Merkle route, you suggest I could have the logic in my airdrop contract check in real time against the... I presume it can also look up by using the account, I guess it is, function on the registry. It can find the addresses for the tokens in a given collection, like at transaction time. Right. I don't need to load them in previously.

Benny Giang: Correct. And you can go a step further. You don't even need to call into the registry contract because token bound account addresses are statically computable. You can just run some math to compute the address without ever having to call into the registry and you'll get the same value back.

Nicholas: Wow. Very cool. OK. I want to ask some questions about transitive ownership. But before I do that, we have a sponsor for today's episode. It's Interface. Interface is an iPhone app for tracking. Basically, it's like a follow feed for Etherscan. It's you can follow people's wallets and keep up with their transactions. They didn't give me any kind of script of what to say. So they just said, say what you like about it. So the way that I use it primarily is I get a bunch of notifications on my watch and on my phone when Vitalik makes transactions or proves tokens and changes, save things and a bunch of other people that I follow. It's free. It's on iPhone. I don't think it's on Android yet, but you can check it out. Interface.social. They're very nice people and it's a cool app for tracking what's going on on chain on mobile phone, even on an Apple Watch, which is pretty cool. So my thanks to Interface.social. Check out the app. So I want to know about the transitive ownership properties of token-gated NFT. So if an NFT, I guess we don't even need to say an NFT with an account because we can presume that all NFTs now have an account, except for the rare few that don't have an owner of function. So if an NFT owns another NFT and that owned NFT has token-gated access permission to some contract out there, I can even access it from just the ownership of the primary NFT, the one that owns it. Is that right?

Benny Giang: Yeah. So you can prove transitive ownership very easily with the token-based account. So if you have an NFT in this case that owns another NFT and that owned NFT, that kind of sub NFT has token-gated access on another contract. If that contract wants to verify that any of the contracts, any of the accounts in that chain are valid to act on behalf of that sub NFT, you can. So it's very trivial to say, OK, my EOA now has access to claim on behalf of that sub NFT because it's owned by a token-based account, which is owned by my EOA. So you can prove like chains of ownership very trivially because, again, it's all statically computable.

Nicholas: You would compute that off-chain?

Benny Giang: Off-chain or on-chain. It's very cheap to compute on-chain.

Nicholas: Really? Even if it's like recursive a few layers deep, it's still like affordable enough to do inside of a transaction.

Benny Giang: So yeah, you can verify it very cheaply on-chain. You get to compute that ownership chain is best on-chain. You can do it on-chain, but it's like five layers of owner of calls.

Nicholas: Got it. OK. And then you'd have to be checking each time that the bytecode associated with the owned NFT has bytecode deployed for... or do you not even need to do that because they might not even be deployed yet, but they could still be already owned?

Benny Giang: Yeah. So when you're verifying, you don't need the accounts to be owned because you can just statically compute the... you can have like basically a proof would be a list of token IDs, contract addresses for NFTs that will resolve into token-based accounts. As you can prove that this NFT is owned by this account, which is owned by this NFT, which is owned by this account, which is owned by this NFT, which is owned by this account. And you can do that with a proof that you've generated.

Nicholas: Got it. Yeah.

Benny Giang: So you can do that proof pretty easily. Where it breaks down is if you're calling into the token-based account contracts to get the token information, then you rely on live deployed contracts. But you can prove like, say I have I own an NFT and then there's a non-deployed token- based account that's owned by it. And that non-deployed token-based account owns a sub NFT. I can still prove on chain that I, the root holder, own that whole chain of NFTs, even though that one account is deployed.

Nicholas: Very cool, because you can find out what their addresses are just by having the arguments that you need to pass to the account function. Or you said even the accounts directly, you might not even need to go to the registry.

Benny Giang: Yeah, exactly. As long as you have the data that would make up the account. So the token contract, token ID, implementation address and salt. If you have those four pieces of data for any account in a chain of accounts, you can locally compute and verify that. the ownership tree is as the proof says it is.

Nicholas: Very cool. I noticed that on tokenbound.org and also on OpenSea, is it? Sapiens is the one of the first collections that you've made with it. And you have this really cool thing at the bottom where you can see sort of in the NFTs image data, you can hover over the image and it reveals what NFTs are owned by that NFT. Can you explain a little bit about how that works?

Benny Giang: For sure, yes. So Sapiens is a project, Sapiens is actually the project that 6551 came out of. With Sapiens, the whole mechanic is you have a character PFP NFT and that character can own clothing items as NFTs and they can equip that clothing onto and off of their PFP. Like my PFP right now is a Sapien. And so we knew we wanted to do this mechanic of ownership of an NFTs owning clothing and then equipping and kind of how to do it was a bit of a question mark. And so after banging our head against the wall for a while, we arrived at what became 6551. So the way that we did it in Sapiens is we built a animation URL. So on OpenSea and some other big NFT platforms, you can actually embed full websites inside of the artwork of an NFT on the details page. And so when you click on the Sapiens and you see the details page, you'll actually see a website from our website that renders over top of the artwork. It renders the address that the token bound account address for that Sapien. And then it pulls in all of the items that that account address owns and it shows them in a little inventory bar at the bottom. That's made possible by OpenSea's iFrame support and there's a couple of other marketplaces that support it. And then because all of that data is easily computable, right? If you know the token, you know the token bound account address. If you know the account address, you can get all of the contents of it. And so all of that is just shown in the little artwork window on the OpenSea details page.

Nicholas: It's very cool. So this is like served from HTTPS and your backend is computing what what? NFTs are owned by this NFT.

Benny Giang: Yeah. So it's it's computing on the client side. Really? So it just loads the JavaScript page and then it uses like I think we're using Alchemy's API to pull in all of the ownership. So there is some indexer somewhere running to get the contents of the account address. But you could just as easily deploy the same static page onto IPFS and have like a fixed, you know, you could have it on IPFS with a pointing to the graph for indexing. and now you've got a fully decentralized version of the iFrame.

Nicholas: Now you just have to buy GRT.

Benny Giang: Yeah, exactly. You just have to make sure that one wallet still has GRT and then you're good to go.

Nicholas: Yeah. The Alchemy thing is pretty cool. Pretty cool for that. And there's actually a bunch of them that I just learned about. I know Sequence has a API that does something similar to Alchemy and Zora also, which can kind of have generous free tiers, which are handy at least, if not the most decentralized thing in the world.

Benny Giang: For sure.

Nicholas: So this is very cool. So you can then do you imagine what is the ultimate or maybe not ultimate, but what would you think would be a cool thing for OpenSea to do in order to increase their support for 6551? Here you've kind of jury rigged it so that you can see the things that it owns inside of its own image. But I guess ideally you wouldn't have to populate that in the image or in the animation URL. That would just be sort of on the OpenSea page.

Benny Giang: Yeah, I think that's kind of. the ideal is that this concept of every NFT owning an account is not a theoretical, right? As of today, every NFT has an account. You can take that for granted with every NFT collection. And so seeing platforms like OpenSea and wallets, wherever they show NFT data, also showing the NFT's wallet data so that you can see the contents of a token bound account wherever you're interacting with your NFTs. You know, in the case of OpenSea, if you go to buy an NFT on OpenSea and there's something really valuable in that NFT's account, you probably want to know about that when you're making the purchasing decision about that NFT. And so showing that data right natively in the OpenSea UI would be really cool. And, you know, we're chatting with them a lot about that and hoping to work with them to implement that. That's still a little ways off, but we think that there's a path forward to that. So, yeah, obviously, like anywhere that you deal with your NFTs, you see your NFTs, you interact with them. Being able to see the account for that NFT and the contents of that NFT's account becomes really important, not just for purchasing decisions, but also say you've got a wallet and you have a lot of NFTs in your wallet application. And, you know, I'm about to transfer this NFT. I should probably know what I'm transferring along with that NFT in the token bought account. So we see this as something that can be and will be built really deeply, natively into the experiences of all the applications, all the platforms, all the wallets you use when you deal with NFTs.

Nicholas: Makes a lot of sense. And I think they'll be perfectly happy to do it because it's just more NFT transactions. I don't know if they're back to charging fees yet, but one way or another, I'm sure they're happy to have more NFTs being transacted. This does bring to mind one of the sort of concerns or challenges of using NFT owned accounts, according to 6551, which is the possibility that someone like rugs what is contained inside of the NFT as they observe the mempool when you go to buy the NFT. Do you have any thoughts about that? Or maybe you can also just explain for people who are a little less familiar what the problem is and how you think about solving it.

Benny Giang: Yeah, for sure. So this is this is one of the big challenges with buying and selling NFTs on marketplaces that don't have any concept of stateful NFTs. Right. So right now, basically every marketplace is every marketplace for NFTs treats it as an NFT as its own little self-contained asset. When you buy an NFT, all you get is the NFT. You don't get anything else. And so, you know, even in the case of something as simple as an NFT having the ability to claim some additional asset, that's state for that NFT. That means that that NFT has some additional value beyond just the NFT itself. And so, you know, one one way to think about this attack that we've seen time and time again is that you have an NFT that has the ability to claim something. So the owner goes and claims it and then sells that NFT really low at a really low floor price. And that new user who bought this NFT expecting to be able to go and claim this cool thing buys the NFT and then can't go claim the thing. Right. They've just been robbed. Something they expected to get when they bought the NFT didn't come with it. And that's because the marketplaces just don't have any concept of NFT having state. And so when you give an NFT a wallet, you have the same problem, but just dialed up to 10, because now you can have like 10 ETH in that wallet. And, you know, you someone makes a bid on that NFT saying like, hey, I buy this NFT. I'm going to get 10 ETH as well. And so there's a malicious holder of that NFT. They could see that really big offer on the NFT, pull the ETH out and then accept the offer. And all of a sudden, the person who bought the NFT thought they were going to get an NFT plus 10 ETH, but all they got was the NFT. And so kind of. the root problem here isn't necessarily 6551 or the way that 6551 is structured. The root problem is that right now we treat all NFTs like statement assets, like just a single thing that changes hands in the transaction. As long as that NFT goes from point A to point B, then everything is kosher. And that's that's the way NFT marketplaces have basically always existed. But pretty much every project that's pushing the boundaries of what NFTs can do or adding utility to NFTs or continuing to build on top of the platform their NFTs have given them. introduce some kind of state to these NFTs, whether it's claiming an airdrop or, you know, being being given like being sent an airdrop or, you know, being able to take token gated. actions like these are all states applied to NFTs and 6551 just exacerbates that problem. So essentially the long term solution there is. marketplaces are going to have to adapt to this new model for NFTs where NFTs aren't just a static asset. They're not just a stateless asset. NFTs have things attached to them. And so far, that's been really hard for marketplaces to adopt because every single project builds their utility differently. Right. Like the claim contract for one NFT collection is different than the claim contract for other NFT collection. And so if OpenSea was going to go out and support all of the different ways that an NFT can possibly have state, it would be a huge mess. There'd be no way to do it. What 6551 does, it gives us a common language for representing state in an NFT. It says, hey, every NFT has a wallet. And with that wallet, you can represent any kind of state for that NFT that you want. And it also means that platforms like OpenSea now have a single way to look at the state of an NFT. It's like, hey, this NFT has a wallet. Based on the contents of this wallet, I know whether the state of this NFT has changed or not. And now I can start protecting users from state changes during NFT transactions. So the Seaport team has actually put a ton of effort and research into this in the last couple of versions of Seaport. And if you go read their docs on some of the more recent versions, you'll see comments specifically around trying to solve this problem of stateful NFTs and trying to find like a universal solution for the problem of stateful NFTs. So what OpenSea has come up with, or sorry, what Seaport has come up with in the context of the Seaport protocol is this concept of a zone. So a zone is just a smart contract.

Nicholas: I was going to say, right.

Benny Giang: Yeah. So just a smart contract to add some custom validation logic to orders. And so one way that marketplaces that use Seaport can protect their users from malicious trades using tokenized accounts is via a custom zone that checks that the contents of the 6551 account are still the same after the NFT transaction as they were before, that there was no rugging involved there. There's some nuances to that.

Nicholas: It would essentially require that OpenSea choose to use a specific zone in their use of Seaport and not honor transactions or not surface transactions to their users to be accepted or offers or listings to their users that they might accept if they don't adhere to a certain zone. Something roughly like that.

Benny Giang: Yeah, I don't think they need to restrict it. I think they just need to give users the ability to choose their own zone, which right now OpenSea doesn't. If you make a transaction on OpenSea, you use the OpenSea zone. I think if OpenSea opens up the ability to use custom zones and then, you know, you have a little drop down, you get to choose the zones that are a little. explainer that, hey, if you want to trade an NFT that has a 6551 account, you can use this zone and you'll be protected. I think just giving users that choice, like that choice already exists at the smart contract level. If you want to just go direct to contract on Seaport, you can use those kinds of custom zones today. You just can't do it through the UI yet.

Nicholas: I wonder if there is EIP in the oven for NFT contracts, you know, explaining with some kind of interface what zone they prefer, what restraints they would prefer to be applied to their zones when trading those NFTs so that you don't have to maybe even just support interface somehow. Maybe it's not enough information, but it seems like something the NFT contract itself would want to express to markets if they care to listen.

Benny Giang: Yeah, no, I think that would be great. There is like the whole, there's besides the EIP process, there's also the SIP process, which is like Seaport improvement proposals. And so I think this would make a great Seaport improvement proposals, like how do NFTs give a marketplace some inclination that they want to use a certain zone? or how can users of a certain wallets give an inclination if they want to use a certain zone. I do think there's some things that can be solved by that at a protocol level, but at a protocol level, it's pretty much solved. Like Seaport has the ability to handle these cases already. It's just up. It's just about getting that protocol level support down to the level of users. And that's kind of the challenge right now.

Nicholas: Makes sense. There's one other concern that is mentioned in the EIP, which is like cyclical ownership. If you transfer an NFT to the address corresponding to a particular implementation, maybe could you explain a little bit about that problem and how to avoid it?

Benny Giang: Yeah, that's another problem. And we're looking into some ways that we can work around this. This might not be as big of a problem as we originally envisioned. But if you just take the concept of an NFT owning an account at its most basic value, that means an NFT can own an NFT that owns an NFT. Right. You can kind of go as deep into this graph of NFTs or this tree of NFTs as you want to. But if you have an NFT that owns an NFT that owns the original NFT, then you have like a loop, right? The original NFT owns the other NFT and the other NFT owns the original NFT. So the question is, who owns those two NFTs? And basically nobody owns those two NFTs because they own each other. Because NFTs can't act on their own behalf, right? They need to be controlled by an owner. You've introduced a situation where two NFTs, they each own each other and neither of them is able to take any actions using their token bound accounts. That means that not only are those two NFTs permanently inaccessible, but all other contents of the token bound accounts of those two NFTs are rendered permanently inaccessible. And this happens with both, you know, N equals one where an NFT owns itself, but N equals 100. You can have a loop of 100 NFTs where if you transfer one at the top into the wallet of one of the bottom, you've just rendered all 100 of those accounts inaccessible. And yeah, so obviously you don't want to do that. Obviously you want to avoid that. And there are some ways around this, right? This is something that's tough to do. This is tough to prevent on-chain, right? It's very difficult to prevent you from getting into that situation on-chain because basically you would make every single NFT transfer to a token bound account really expensive because you would have to check all the way up the ownership chain that you're not creating a cycle. And so then it means that the more tokens you add to a chain, the more expensive it is to add new tokens to a chain until you hit the gas limit. So preventing this on-chain is tough. We plan to prevent this off-chain at the client level. So making sure that whenever you go and transfer an NFT on the token bound site, we do a cycle check like, hey, actually, if you do this transfer, you're going to lock up all these assets. Are you sure you want to do that? We didn't do anything at the EIP level to prevent this. And we did that for a reason, because it's very similarly to how 721 has the possibility that you can burn an NFT. This is kind of like the 6551 burn mechanic. If you have an NFT that owns itself, you've essentially burned the NFT and burned the wallet. And people have built really cool experiences on top of the burn mechanic of NFT. So we think there's a possibility that people could build really cool experiences on top of the burn mechanic of 6551 accounts. But yeah, as it stands now, if you transfer an NFT to its own account, you functionally are burning both the NFT and the contents of the account.

Nicholas: Very cool. And you're right, the contents and anything that the contents owns also potentially.

Benny Giang: Exactly. Yeah. Basically anything that's a subtree of that loop will be burned.

Nicholas: There is another application that we didn't mention yet, which I think you mentioned in your talk in Lisbon, the NFT's owning lens profiles. So I think there's something maybe here around like authentication, token gating, not just for claiming a mint or something like that, but even for a really creative platform. Can you talk a little bit about that? And maybe is there anything beyond lens that makes sense in that vein also?

Benny Giang: Yeah, I think the lens integration is a really good use case or a really good example use case of how just having a wallet opens up all sorts of access to existing systems. Right. If you have a wallet today, a normal Metamask wallet, you can go and get a lens profile and that gives you access to the lens social network, social ecosystem. Right. By giving NFTs wallets, we didn't even try to give NFT lens profiles, but now NFTs can interact on a social network just because that social network supports wallets and NFTs now support wallets. We basically built a bridge between NFTs and social networks and without even trying to do so. And I think that's really the power of giving wallets to NFTs is you give them the ability to participate in these existing platforms and these existing networks. So you can use wallet to wallet messaging services as your NFT. You can use wallet based social products as your NFT. You can use wallet based DAO tools as your NFT. Anything that has the capability to be acted upon by a wallet now also has the ability to be acted upon by an NFT. And so, you know, the social aspect is super cool. You've got an NFT that is its own self-contained identity. That it's not just you owning the NFT, it's the NFT itself that has its identity. So your NFT can post on lens as its own identity. Your NFT can have its own social handle, its own presence on the Internet, its own presence on social media and interact as the NFT, not just as you, your wallet.

Nicholas: So in the future, we'll have NFTs farming Blur rewards directly.

Benny Giang: Yeah, I think so. Benny can speak a little bit to this because Benny is doing some crazy thinking around like, what does this look like in the future? But this concept of like self-contained agents on chain as represented as an NFT, but able to take any action on chain means you can have NFTs that are doing MED. You can have NFTs that are doing like liquidity pooling. You can have NFTs that are doing like high frequency NFT trading. Like Benny, you could probably give a better pitch on this than I can. But this is something we've been kind of thinking. and like expanding the time out of like, how much crazy stuff can you do with this?

Jayden Windle: That's going to be part two of the episode. We're going to go deep down the rabbit hole of NPCs, network playable characters.

Nicholas: Dang, yeah, lay it on me. Wow. That sounds great. It's making me realize that you can sell like any kind of, I don't know, even like a deployer address. You could potentially use an NFT to deploy something and then sell the deployer. Would that work?

Benny Giang: Yeah, totally. Like you could deploy a smart contract account using your NFT's wallet. And then that NFT could be the owner of that smart contract. And so when you sell the NFT, you're selling ownership of the smart contract just in one transaction.

Nicholas: So it requires a little bit of belief, but you can kind of start thinking about tokenizing blockchain history by selling the account that executed some transactions or was involved in something. It feels to me like maybe less light of hand than like ordinals even. It's pretty real.

Benny Giang: Yeah, totally. I think like you, you essentially are giving the ability to the Ethereum ecosystem, being able to sell wallets, which is something that you can't just do right now, right? You can't sell your EOA wallet unless you really trust the person not to rug you when you give them your private key. Even selling like an ownable wallet, right? Like selling a smart contract, somebody has to execute that transfer ownership. And because you don't have the mechanics for trustless sales like NFTs do, like we don't really have an open sea for smart contracts, right? Where you buy and sell and trade smart contracts just because we don't really have the infrastructure for it or the standards for it. But we do have that for NFTs. What that means is we can represent using NFTs any type of sellable wallet. And so you can have you can now use NFT to sell anything, not just NFTs.

Nicholas: Very cool. Benny, do you want to share any alpha on this? or should we wait for a future episode?

Jayden Windle: I think part two, you know, ETH Waterloo is coming up. So we're going to be doing some crazy experiments and we're doing a talk or we'll be doing a talk after Vitalik. So it's going to be heavy on 6551 and this future of like what happens when you program them to perform on-chain actions. So, yeah, I think one thing that we like to say is like right now in this space, there are two problems, right? One is the hyper speculation of NFTs, which we're not a big super fan of. And then number two is this whole metaverse thing that hasn't been going on for the last one or two years. And most of the metaverses are like ghost towns, like they have an empty world problem. So I think on a 10,000 foot level, it's like we want to populate these empty worlds with NFTs that have token bound accounts and maybe some AI in there. So, yeah, that could be a good part two for sure.

Nicholas: Definitely. Well, I'll see you at ETH Waterloo. I'd be remiss if I let you go before asking just a couple of questions if you have a few minutes to spare. I'm just curious what the process is like of creating an EIP. There's like a bunch of authors on this project, some folks from where you're working at, there's some folks from Manifold and even some others I'm not as familiar with. Can you just give me a little bit of insight into what it's like to write an EIP? Because I think this is a pretty great EIP. So I think people would benefit from understanding a little of the anthropology of how these things actually come together.

Benny Giang: Yeah, for sure. And this is our first time writing, or my first time, Benny was kind of involved in the writing of ERC 721. Yeah, EIPs are one of the coolest aspects of the Ethereum ecosystem because it's a really neat way for like bottoms up innovation to happen. If you have an idea of something you think would meaningfully improve the Ethereum ecosystem, like something that you think that the community should rally around, a common pattern or a common way of doing things, you can put that out into the world and gather feedback on it. And eventually it can work its way to the point of becoming just a standard pattern that everyone uses. But for EIP specifically, there's a forum called the Ethereum Magicians Forum, which is where a lot of the kind of developments of Ethereum, both at a really low core protocol level and at a really high standards level happens. You've got a lot of really talented developers and people in the Ethereum ecosystem all hanging out in this forum and are chatting about improvements to the Ethereum ecosystem. And so if you have an idea for something you think would be really cool in the ecosystem, you can create a post on this forum and be like, hey, I think this thing should exist. In our case, we're like, hey, we think NFTs should have wallets and we think that they should be able to work like this. We think it's really important that the wallets be counterfactual and a few things like that. And just solicit feedback on us and get people's thoughts on it. And eventually, once there's some kind of community consensus around like, hey, there actually might be something here. Why don't you write it up? You can write it up as a proposal. There's kind of like a formal template for how to write up an EIP proposal and you can submit it there as a pull request on GitHub. It'll get some light review, mostly just around some conventions. And at that point, if it looks like the EIP is well formatted and there's some beginning emerging consensus around it, it'll get merged in as a draft EIP, which is what EIP 6551 is right now, which you can continue to work on, continue to refine. And then eventually it'll go to a review state where it's kind of like everybody piles on with all the feedback and tries to kind of really do the last mile of coming to consensus on it. And after that, it goes to last call and it goes to finalize. And so kind of. the goal of the EIP process is to gather community consensus around a common idea. It's not like a patent. It's not a claim of invention. It's a tool to rally the community around a common pattern for doing things. In our case, we think it's really important for NFTs to have wallets and NFTs to have counterfactual wallets and for that to be something that works for every NFT on every chain that's ever existed. And so if we can find community consensus around that idea and specifically how that idea should be implemented, then this EIP will come from the draft state it is now to the state of being a final EIP.

Nicholas: Were there concepts that you had to give up or that changed? How did it evolve from when you first proposed the concept to what's actually in the, I guess it's still draft, but more developed 6551 that we know?

Benny Giang: Yeah, for sure. This is actually a really good question. We chatted with Sam Wilson in particular, who was super helpful as we were kind of going down this path. But an early version of the EIP didn't have the central registry contract. It had like an interface for a registry and kind of assumed that there would be many registries and it had an interface for accounts assumed that would be many account implementations and that each registry would only deploy one type of account. So you would have one type of account per registry, but you'd have a million registries you'd have to integrate with. And Sam was like, hey, you know, this is really cool, but what if there was like a known like a known bytecode that could be deployed by a single registry? And then you get a lot of benefits around the counterfactual thing. And you also get a single entry point for everybody to gather around rather than having like many entry points in the ecosystem. And so we're like, wow, that's actually really good. That takes this idea from where it was, which was pretty good to like a lot of cool things you can do with counterfactual addresses. And so that was one of the early pieces of feedback that was super helpful.

Nicholas: I guess that also helps with multi-chain deployment.

Benny Giang: Exactly. Yeah. So we had in the original version of the EIP that we had, we had counterfactual addresses, like every registry would deploy counterfactual addresses. But there was. it was kind of assumed there would be a lot of registries and there wouldn't be one canonical address. You would just deploy a registry to wherever and then somebody somewhere would have to index all of the registries if they wanted to integrate with the EIP. But Sam was like, hey, you can use a permissionless non-owned registry contract that can be deployed on any chain using Nix method or using the factory that we're using now. And then that would have like, you know, we would be kind of coming to consensus around should this be the single factory that everyone uses. And so that was a really good piece of feedback.

Nicholas: I see there's eight people listed as authors on the EIP. I'm curious, what's the bar for being included as an author on the EIP versus just participating in the ETH magicians conversation? And also, do all of those people, did they have kind of similar design goals for working on this project with you or did people come from very different perspectives?

Benny Giang: Yeah, so the original set of authors were people on the Future Affirmative team. This is a really collaborative thing on our team around kind of dancing around these different ideas of how we're going to give every NFT's wallet. So we put everyone who was kind of meaningfully involved in those conversations on our team on there. But since then, the additional people who've been added is just merging a PR into the reference implementation repo. So if you've like meaningfully contributed at a code level to the 6551 and will be eventually deployed and permanently on chain, then we've been pretty generous with adding authors. So if you'd like to be an author, we'd love your contributions to the proposal, both at the idea level and specifically like merging PRs into the existing thing to help improve it.

Nicholas: I saw there's a typo. There's a the the somewhere. Is that enough to get me to be an author?

Benny Giang: If you'd like to. I think like EIP authorship is like EIP authorship is not really that big of a thing. I think Pedro from Wallet Connect had a tweet about this recently. Like, you know, everybody who's contributed anything ideally should be an author on an EIP. Right? Like if you've if you've like contributed in the smallest way to an idea like in an ideal world, you should be there. Like there's only so much space up there. But like it shouldn't be like this exclusive like club type thing. Like if you've been involved in this, you should be a part of it. And so we'd like to be pretty lax on the requirements. I think the thing that we've come to is like if you can ship code to the repos or ship code, ship updates to some of the stuff we're working on, we'd be happy to include you as an author.

Nicholas: That makes sense. I saw someone tweeting recently about some people treating EIPs a little bit as a vanity project and not necessarily about improving the chain or making affordances that are useful for other people. But it seems to be a project that I think is really going to be pretty cool and way better than all these different specific and especially requiring that you deploy new code solutions to solving this problem. So it's exciting to see. I think that's all my questions about the EIP process. Benny, is there anything that we've forgotten to talk about here about this project? What makes it interesting?

Jayden Windle: No, this is good. Yeah. I think Jayden does a great job and kind of going through all the details. So I think we covered a lot of things. And if folks have other questions, we have a developer working group that's on Telegram. You could find it on tokenbound.org. And then we also have weekly dev calls on Thursdays. So, yeah, we definitely encourage folks, both developers and designers and people with ideas. I think we don't want to isolate people. If you don't know how to write a solidity contract, you don't belong here. Like I think everyone who, you know, even if you're an artist or creative, you belong here because this affects everybody. Very cool.

Nicholas: Where can they find those resources?

Jayden Windle: Yeah, tokenbound.org is where all the resources are.

Nicholas: Yeah. And my last question for you is, what is it about Canada that all of the NFT standards are written? There's so many Canadians involved in writing the NFT standards. It's really, I mean, it's pretty crazy. Have you noticed this?

Jayden Windle: Yeah.

Nicholas: 721 and 1155, both, you know, and now 6551 also.

Jayden Windle: We couldn't tell you our secret. Otherwise, you know, I don't know. I think it's because there's like a, I think being at Dapper and a lot of people kind of stemming from there, I think that there's a lot of folks here who care a lot about NFTs and Manifold is here, Dapper is here and a lot of the biggest NFT artists are located in Vancouver or elsewhere in Canada. So y'all should move up here.

Nicholas: Also, 0x, or I guess that's their handle, but Horizon Games did 1155. I don't know. Is Engine in Canada? I'm not sure. But 1155 has also got a huge Canadian developer aspect to it. So it's pretty, I don't know, it seems over-represented. I'm curious if you have any theories. I've always thought that maybe Ethereum and blockchain development in general kind of unlocked talent in Canada and around the world that maybe wouldn't have been able to get an H1B or something and go move to the States. But given that it's a global network, just any talented people around the world now have access to making, you know, chain changing contributions. Is that your experience?

Jayden Windle: Yeah, I mean, Vitalik went to school here in Waterloo and I was listening to another episode like Liam, who was the CEO of Optimism. You know, it was classmates of Vitalik. So there's certainly like a lot of notable Canadians to kind of form the initial basis of thinking. And I think it inspired like other people here. So, yeah, I think it continues to be that way.

Nicholas: Very cool. Benny, what about you? Jaden, thank you so much for explaining 6551. This has been really educational.

Benny Giang: Thank you so much for having us.

Nicholas: Also, I got an update. You're very welcome. I got an update from somebody on Twitter and Interface is available on Android. So if you have an Android, you can go check it out.

Benny Giang: Thank you. Also, plus one for Interface. Yeah, you're a fan. Yeah. Yeah. Also, you can now follow NFTs on 6551 on Interface. Just out of the box.

Nicholas: So that's very cool. OK, you got to send me like an NFT that I should follow. I guess tokenbound.org people can find ones, but that's pretty interesting, actually. So now we need to set like avatars on ENS text records for the NFTs as well.

Benny Giang: That's a whole rabbit hole. Have fun going down.

Nicholas: All right. Thank you both. And thank you everybody for coming to listen. Another episode next week, Friday, 5 p.m. Eastern Time. Thanks, everybody. Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter at Nicholas with four leading ins. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at Web3GalaxyBrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC on Twitter Spaces. I look forward to seeing you there. Transcription by ESO. Translation by —.