Ethereum Cat Herders PEEPanEIP, 14 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #89: EIP-5192: Minimal Soulbound NFTs with Tim Daubenschütz

Description

Topics covered
----------------------------
00:56 - Proposal intro
01:32 - About the guest
02:14 - EIP-5192 presentation
04:00 - Motivation/back history
13:57 - This is why 5192 is created
14:55 - Other solutions to implement soulbound tokens
16:33 - How to communicate about 5192 solution to the world
18:05 - Why use Magicians for proposal submission
23:00 - An extension of ERC-721 - Contract Interface
23:45 - Feature detection for Marketplace
26:00 - Project implementation
28:43 - Conclusion
31:50 - Q&A
31:52 - How is Sol immutability (community?) doing recovery?
34:40 - Is Lock & unlock functionality expandable?
38:20 - Labeling NFT as Soulbound
41:11 - How do you see this implemented by a project? Do you expect smart contract developer to overwrite the transfer function?
42:43 - What are the implications of 5192 accidentally permanently locking tokens?
45:42 - Thoughts on other soulbound proposals (EIP-5484)
49:25 - Thoughts on EIP-5114
52:58 - General experience with EIP documentation
57:17 - Anything for the community

Resources:
-----------------
Proposal - https://eips.ethereum.org/EIPS/eip-5192

Discussion - https://ethereum-magicians.org/t/eip-5192-minimal-soulbound-nfts/9814

Slides - https://ethereum-magicians.org/t/final-eip-5192-minimal-soulbound-nfts/9814/20

ERCs Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K

PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

Questions for Guests - https://docs.google.com/forms/d/e/1FAIpQLSdsmujnH_ncIlSEJ23s9jzXAKwfpTGNeJqjREWPloBbkJVQTA/viewform

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Follow at Twitter
-----------------------------------------------
Tim Daub @timdaub | Blaine Malone @blainemalone | Pooja Ranjan @poojaranjan19

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/

A

Non-Fungible tokens can be treated or given away for free. That means it may or may not have different owners. But what, if your project demands to be a non-transferable? Well, nothing to worry for app developers of ethereum blockchain. We have a standard to help you with want to know more about Soul bound nft standard continue watching.

A

Thank you, foreign.

A

A series dedicated to ethereum Improvement proposal and protocol upgrade I'm your host Puja ranjan. In this nft special episode, we will learn about EIP, 5192, minimal Soul, bound nfts about the proposal. Eip-5192 is a standard track. Erc created on July 1st is in final status and is now available for project developers to implement in their respective projects to provide an overview of this proposal. We are joined by today's guest and one of the co-author of The Proposal Tim derbyshires.

A

Welcome to the show Tim hi.

B

Thank you for having me.

A

Maybe kick off this with a quick introduction, your way to Ethan community and the journey so far.

B

Yes, my name is Tim domschutz I go by the handle Tim doubt usually on Twitter I'm, a blogger and a freelancer um I work right now in music, nfps I've been historically working a lot with nfts, even like I, some people would say, like prehistoric, nfts and most recently, I've been focusing a lot of my attention on uh Soul Bond tokens account tokens and new types of like properties, and so on that.

A

Sounds so interesting, thank you so much for the introduction and without further Ado, let's peep in.

B

Nice yeah thanks for the intro, um basically I'm I'm, doing a talk where essentially, the the entire talk is also an ethereum magician's post, because we have this uh nice uh way of doing slideshows in here and then also for me, it's better to to kind of formulate a story around, and so this talk is uh going to be about EIP 5192, minimal, Soul, Bond, nfts and um and essentially it's I I'm. Basically, I have structured.

B

This talk as kind of like a story um that is not very long or very complex or anything, but it starts at 2 am in the morning and with me kind of like sitting in front of the computer and hammering into like the keys this uh this proposal. This idea I, have because essentially I I couldn't sleep and I was like okay, maybe I. Just you know, I need to like get this out of my head and into the document, and so I can stop thinking about this, and so so really yeah.

B

It's about so really. This starts like with kind of sketching this idea and um as Puja already mentioned, the and now it's it's a final proposal. It reached uh status. Final I think sometime in September, um and so this is now like really a thing, but um but I think it.

B

In order to describe this proposal, it would not be failed to go back to the original creation date, which was the um first of of July, because I think the work that we ended up doing with this proposal starts were already way earlier, and it starts with this uh specification of um eip4973 account bound tokens and even and even Way Beyond it I.

B

Actually I ended up having to draw like this almost like a timeline of the different events that ended up, leading to me, proposing this minimal solvon token design and I want to walk you through kind of this entire Journey, because I think it's important um for everyone to understand kind of like where I'm I'm, where I and we are like coming from this- and what were the the previous challenges that we were facing so um essentially I think it all starts in a jam anywhere even vitalik posts this.

B

This now famous blog post called Soul bound where he basically describes this asset class in World of Warcraft. That is genuinely new. It's non-scheuomorphic in the sense that it doesn't derive from like old types of uh you know: property like uh private property or public goods and as a like, a basically as a an ex-world of Warcraft, a player myself. It immediately resonated with me and I I seem to like immediately understand what he meant by that proposal.

B

Where you know um in World of Warcraft you had uh you had like the standard items that would comply to the general rules of uh private property. But then you also had these like stole Bond items that you could only acquire when you were doing some really challenging and like also coordinational or socially challenging tasks like, for example, going into a like joining a raid group. And then uh you know entering a Dragon's Lair, and you know uh you know, like everyone, had to coordinate via like a TeamSpeak server with their voices.

B

And you know, people had to stay like in this uh in this configuration for many hours, and you know, like every character, would have to like walk a certain way and do like a certain spell or whatever, and only then the dragon could be could be slain by these 40 people and so uh event like when that happened.

B

The the dragon dropped like a very valuable loot that you would not get if you were like uh slaying, basically, like you know, like smaller beasts or whatever, and so um the the game designers were then exposed to this problematic of people selling uh these items that you could only get when you were doing these social things on the on the auction house right so and and- and that was the reason why- then uh a special item was introduced.

B

That was called a soul bound item and the the idea of the Soul bound item is one where um once picked up from the character from The World of Warcraft character. It binds to the soul of the character, and so, while you can just irregularly use it, you can destroy it. You can put it in your bank account. You can put it in your bag or whatever, or you can also you know, use it um you, you cannot sell it on the marketplace, and so this item can will never within the World of Warcraft.

B

It will never have really a financial value, and this is really something that inspired me, especially uh when I then went to uh to Colorado to if Denver in February and I heard. uh You know, people are telling point and other events like talk about. You know um you know like this non-scheuomorphic property I think a lot of people at the time were also talking about.

B

um You know: harberger taxes, harburger property. It is like ideals from uh from Glenn Wales book, uh radical markets and so I. Think after coming home from East Denver I had this idea of you know: building a new type of property that was kind of in between private and and public property, and so I think, um when I then committed to the ethereum eip's GitHub on April Fool's Day, my first version of account Bond tokens, which is, as I said, the precursor to EIP 5192.

B

It was really with this intention of solving um kind of non-transferable token, as I think Nicola Greco had initially outlined in in the GitHub issue 1238 um and while that was uh that was kind of like really uh you know in the beginning, like really widely discussed, and we were like you know, having having our fun I was I'm a freelancer, so I was also you know, engaging with with clients that that started to be interesting in this I.

B

Think the pivotal moment in this entire Journey was when then uh like roughly a month later, uh Glenn whale the person that uh had also you know talked about Harbor attacks and so on, and vitalik and Puja old Harbor then published their decentralized society paper. That was specifically talking about Soul Bond tokens in a kind of a new context where you know they framed it. uh They framed it more around like claims and as a as a means to make.

B

You know a test at the stations and and move them, for example, on chain or uh you or to use them with uh you, use them with zero knowledge, proofs and- and you know they- they also I, which I think I I understand at the time they were not pointing to any necessary like a a proposal that was already existing, because I think they had like a specific Vision that they they thought this was this.

B

Should this should be somehow and so far, but for us I think what this really meant with uh EIP 4973 was that we ended up. Getting bombarded with, like engagement essentially like here, is a screenshot that I took in preparation for a talk at Defcon, where you can see that at the lower uh uh at the bottom of the screen. So you can see um the amount of views that account bound tokens uh created in terms of use uh actually, and this is on a yearly basis right.

B

So um so this this is like one of the most viewed proposal in the entire forum, and then um it it's also actually the most controversially discussed, one as well and and so I. Think for us, though, what is what that really meant is like, since we were really not prepared to uh to work with this kind of Engagement was that we were basically like uh yeah I guess overwhelmed in communicating uh the vision that that we ended up.

B

Having also uh with with regards to this, you know framing it kind of like more from this perspective of World of Warcraft and, like uh you know, as like this new type of property, like the like, like a more like World of Warcraft um style, um Style, Style, Style approach, and so so I think so.

B

I think you know like after that and being in this, like Soul Bond summer kind of scenario, where there was a lot of attention around this uh thing, I think at the end of it, in in July, I I I had grown also a bit like frustrated with with the work on account or on tokens and I.

B

Think necessarily, you know, um because for once, like we just had seemed to have have hit like a local uh Maxima with with what we were doing and, and the thing is you know, like I, think one of the superpowers- and this is also something that I want to highlight in my talk here today- is that you know The ethereum Magicians. It's really like it's truly a magical place because it, basically you can post your idea on there and you get like all of this feedback that you would have never thought about it.

B

But in the case of account, Bond tokens I, think the you know the controversy um or, like the discussion in general I, think pointed quite heavily to one of the uh to like one point of contention which was around.

B

um You know this idea that account binding, really limits uh and also basically demotivates people to rotate their crypto Keys, which is like you know, considered, then to be like really an anti-pattern in the space where you know, if, um technically you should rotate your keys every now and then to you know prevent kind of the the worst uh things from happening uh in case you're.

B

Your colleagues, and so this is like a standard, uh operational security practice and if we are issuing accounts, if we're issuing nfts to accounts and we make them permanently look to those accounts right then uh there there starts to be this problem where people uh either not rotating their keys anymore or they get like a bit demotivated or like they don't really know what to do and for us you know, while we potentially on a on a you know on a theoretical level, we were like arguing um against it and we said something like you know.

B

You don't have to issue a countdown tokens against uh eoa accounts. You can also issue them against. uh You know contracts, and then you know the contract can proxy, basically the account which I guess you know. Nowadays, uh people genuinely understand this. You know account abstraction as I guess like or account abstraction based on uh contracts, I, I and I end up also accepting or I had to accept myself that you know this is more of like a theoretical argument. Then it is a.

B

You know really something practical that um people then also accept in the context of defining a uh a solidity interface, and so so I think- and this is and now we're like already 10 minutes in or whatever and now I'm mentioning. Finally uh 51.92. This is the moment. This is my state of mind.

B

Basically, when 50 5192 is created at night and I'm, like you know, maybe we like hit a dead end with a countdown tokens, and you know like I'm, trying to basically figure out the solution space- and you know maybe it's a good hedge um to address this problem in a really different way than I had initially thought. With a compound tokens and- and so there there I was, you know basically typing this new proposal that would solve the problem in a different way and I.

B

Think an additional motivation for this um is also one where uh you know I saw basically, you know, since the diesel paper came out, and people got like really interested in uh implementing Soul Bond tokens on ethereum right and nobody really like knew how to do that, and so people were Googling around and I was also keeping track of the space and so on and I ended up finding like all of these uh yeah, like simple, uh medium tutorials, on how to implement solvent tokens, and they were suggesting that uh you know what you can do is you can use the ERC 721 standard for nfts and that you, then you know, you revert on all of the transferring functions because then you make the you know, you make the token non-transferable, and that means you are binding it to the soul, and this got me really frustrated because you know that that was like in August right and we already had started working on account bound tokens in in April.

B

So we had already like known a lot of like we were real, like had already solved a lot of the problem that uh you know this. This reverting on the transfer would create, because, essentially for us how we thought about uh how we thought about this in the very beginning was that we, we said you know, wallets indexes, marketplaces and other ecosystem.

B

um Other peripheral ecosystem that has to deal with the token also needs a way for the machine or yeah the machine to interpret uh what a certain token is and so, for example, a wallet.

B

um If they receive a solvent token, then it would actually be nice if the wallet would be able to hide the you know the transfer button, if it recognizes that you know the token currently cannot be transferred or if you can permanently not be transferred, and so I think you know. For us, this was frustrating to see that people were reverting on the transfer because we were like, like we had already solved it.

B

So so you know like how were we able to then basically like communicate uh this to others and so, and so that was I, think one of the leading motivations and it was also while you know I was not a big fan of people. uh You know reverting on the transfer and and here's that a function also again like spelled out I, think in a very simplistic term. uh You know why we weren't a big fan of of that. For me, it was also a uh kind of like a just an Acceptance.

B

In that moment, like I was, like you know, like people are doing this, anyways like there are medium articles.

B

uh You know this is uh this is bound to happen, so we might as well also make it composable uh by you know having an Erp right, and so uh so so then, basically, what what I ended up like typing it to it now two at night is, is really just a screenshot, where the entire gist of the um of the of the proposal- and this is actually quite different from from what we have today- uh is that we have this magic value that we can insert into the support interface uh function with uh that that takes this four byte interface ID.

B

That then signals that you know there is like this feature of Soul binding, which means that you cannot call The Transfer function so uh by the way that that still says eip55 and that had been a. This is like really the first commit ever so I we I didn't even have the uh the EIP number is assigned to it yet but um yeah so so that I think was the first proposal.

B

But but the thing was that- and this I mean it also goes back kind of to uh to what The Magicians are great at and and why it makes so much sense to submit uh proposals to The Magicians, which is that uh I ended up getting feedback immediately, that you know this opinionated approach of uh you know uh account binding uh permanently with with this identifier and by you know, reverting on all transfers was really a problem because it would discourage people from rotating their uh crypto, Keys responsibly and regularly, and so on, and some of us uh I guess I was really frustrated.

B

I was like, oh my God. You know, like I've, been like trying to solve this problem. For you know four months, and here I am like falling into the same trap. Again I was like this is so stupid and and whatever and and so I I think I was quite like discouraged.

B

Somehow by that comment, even though I think it pointed out something really important, that I think then later kind of someone else pointed out and made the contract, uh you know much more stronger and much less opinionated, and that was this user error, which also in the discussion thread then basically said you know what about if, instead of permanently binding to an account, we can have this view, function called locked and then for each token that exists.

B

We basically allow this to be input as a as a parameter, and we return the status if the the token is um is locked with a Boolean or not so I think that was. That was just really interesting, uh because is it- and this is such a beautiful um uh fix to the problem of account binding because essentially it took the opinion of you know whether account binding is good or bad.

B

It took that essentially out of um out of the standard definition, and it said you know this is anyways a thing that the implementer that that lies within the discretion of the implement or to decide, because I also I, think as an EIP Creator editor, whatever it's not uh it's not on me to really disciple people are supposed to do uh in their solidity contracts and then additionally, I also uh had previously, uh you know published a blog post where I said that you know EIP 721 is uh you know, can can enable these so-called, like sleep minting attacks where, where we have this convention of uh you know, in an nft contract to Mint, always from the zero address to uh you, know the Creator or the mentors address in the first transfer, and then only uh you know we may we we do a transfer between like two existing addresses to signalize a you know, a transfer between two parties.

B

uh You know, while this is a convention that is clear to everyone that is reading the interface definition on the EIP um on the EIP document, a uh a solidity interface cannot achieve uh or enforce the implementation of that right and, and people have taken that as a people have also. Then uh you abuse this this situation where, for example, they minted a they. They implemented an nft contract that then uh minted this uh famous uh nft of people and in the trip you know in the mint and transfer function they quickly minted.

B

They emitted the event admitted to uh people's original address, and then they transferred it out to people, and so, while the the while, the nft was never really on uh on people, people's account and people never really minted.

B

That piece uh through when checking through the event uh log history of ethereum it uh and- and it's done in in a certain conventional way, then it can still look like people had already or originally minted that uh that nft and so for me it was clear we can anyways not enforce uh implementation with an interface definition, and so um so so I think like uh Aaron's Aaron's suggestion here was very nice and um Aaron I think also uh really submitted a PR then, and basically uh changed kind of this uh change.

B

This logic now before I before I, uh continue with the with the story: I I.

C

B

I need some also a moment of just like defining, essentially what EIP 5192 eventually has become, then, so uh we still want to uh solve this problem in the sold one token space, but we do it a bit differently now, uh where the fundamentally The Proposal is an extension of uh ERC 721, the the oldest nft standard, and then we have two events, one that we are emitting when we are locking the token and given a token ID one that we're emitting when we're unlocking and then this uh before mentioned uh log function and I think uh yeah.

B

It's I think it's just important. So we also have a the support, interface, uh identifier or EIP 100 and 65 as well, so that we can have a feature detection, for example, in marketplaces and so on, and and just to give an overview of what that then means for uh for for people using this EIP. It means that uh the token is right. Like there's an now, we have an nft token, that is recognizable by machines, marketplaces, wallets, and so on that you know it is potentially uh it has.

B

Potentially this changeable functionality in terms of being uh transferable or not, and potentially I've forgotten to say that if the token is locked, then all transfer functions are supposed to throw right. They. So we're essentially like we're essentially like uh implementing the suggestion from the from this like uh uh medium tutorials, but we're saying you know like there's the necessary metadata for a machine to interpret also what is going on in this uh in this case. uh So so, basically yeah we're allowing this and then I.

B

Think what's really interesting is that basically, we are also allowing um such a token to be both permanently bound to a car, to an account and on the other side of the spectrum, we're also allowing potentially permanently transferable nft tokens with this standard and anything in between and I. Think in uh just to contrast, this I think with the account bound tokens um specification where you know we had like. We were going down a very specific path and a very opinionated path.

B

I think uh by having this like unopened way, an opinioned native way of you know specifying this interface.

B

We are now also you know allowing use cases from, for example, within the DSO paper, where you know we could have like some more elaborate Community recovery and where you know the locked function and the you know, the the you know when something is is locked and so on has a bit more like complicated uh Logic, for you know like or like a social logic or whatever um so so, I think in a nutshell, that's kind of Erp 5192 and that's I think that that was the time you know when the when the, when the standard also got in last call and finalized, and then what happened after that and what I I think I have not documented anywhere so far is that um you know I also think it's then important to follow up and to uh you know, find also uh companies or projects or protocols or whatever, that that end up also using this and finding it Implement finding it.

B

You know uh useful for implementing and so I I had been Loosely, collaborating with a project called public assembly that is like I think slightly related, uh somehow to also Zora and I had seen that they essentially had implemented a non-transferable token, very much or very similarly, to how these uh like, how a medium, how this medium article would describe it. So uh you know reverting on the transfer essentially, and you know account binding to whoever means the the token and I was like wow.

B

That's so you know that's like so interesting, because I think this could be like a very simple way of demonstrating the the you know, Simplicity and power, and the flexibility of implementing this and so I went ahead actually and sent a PR where you know I in basically I imported. The interface I inherited from the interface I, implemented the required locked function and actually I made it uh static where I just returned true.

B

So this is actually an account Pawn token and we are emitting a uh a locked event on the mint uh on on the on the mint function and also we are returning the interface I D.

B

When calling sorry, we are returning true when calling uh support when calling the support interface uh functionality with the with the 5192 interface, ID and so I think the what was encouraging in that process is that this ended up getting merged and I also liked the I'm also very happy to see the there's like a feedback from Ian Nash one of the contributors here which, where they say uh you know, don't see a harm in integrating this and I think. This was also kind of the intention like this.

B

This you know idea of accepting that people they anyways want to do this, so we might as well have like a standard to you know, improve a little bit the the composability in the in the future of these uh of these things.

B

So it doesn't really like intercept with you know how they want to do as a how they want to do a certain thing, but you know, potentially, if, uh if there's like 5192 gets these more adoption, then you know it could be really useful for them and for everybody else having to deal with their tokens and so I. Think.

B

Finally, I think this is a for me. I see this as a win, because it means also that we I went not only in terms of you know the specifying this thing uh from from uh zero to one I also went from zero to one in terms of you know getting this at least adopted by one protocol, because they ended up a filed as far as I know like shipping this to mainnet, and so it's actually like being used right now.

B

um It only I mean for now. It only validates the non-transferable uh token use case and like how you know, like account, binding works and so on and I, of course, I hope that we can Implement many more um uh use cases, but just uh non-transferable and and account binding in general. But um to conclude this, uh this talk that I have been doing now.

B

I think the the message that I want to bring across in general and that I wanted to point out with this entire uh uh talk that I have written uh is essentially that working in The Magicians is like almost like this magic experience of asynchronous teamwork, where you know I type, something on the GitHub Forum at two at night, and it's like very far from being perfect. And then you know, someone else sees it and gives the feedback and someone else gets inspired and ends up.

B

uh You know like uh sending a PR for for adding a function or changing something, and we end up with something that you know.

B

A protocol team then later implements and ships to mainnet and so I think that's such a great and and cool like story of how The Magicians work and I think I also want to say that I think it should also serve kind of as a as a motivation for more people to submit their ideas to The Magicians in order for yeah to just have more composability, more dialogue about how we are solving things and also for each and everyone to have this uh Magic Moment of you know uh you know being given like meaningful feedback and constructive feedback on on the Forum and so on, and so yeah.

B

That's uh that's essentially my talk. Thank you for um having me.

A

Thank you. It's really informative presentation. It was a great talk from draft to standard in less than three months is fairly quick for a proposal, but you did mention about the background that justifies it either way, congratulations for reaching it into the final status.

A

You really very well presented. I love the story and the way you have put it like generally, the format of this talk is more technical oriented, but getting the back history added a lot of value.

A

I'm sure this presentation will be helpful to developers so who are willing to have a quick overview, though we already have a project implementing it. So that's always great.

A

Maybe uh we can open the floor now for people on the call to have their questions with you.

B

C

So I've been doing research on the white paper and possible use. Cases to like you know, expand the use cases so that we can actually um better Implement and improve the The Proposal.

C

So my question is that a white paper states that spts may allow Community recovery and where the souls it Seoul is an intersectional vote of its social network and I. Guess: I wonder how do you solve immutability during recovery phase and um yeah.

B

Yeah, that's a great question. I. Think the the like the community recovery aspect is so important to Soul, Bond tokens and I. Think um we, the the 5192, does not address it at all right. um We are basically just providing the interface that I guess. Technically you could build an implementation that does community recovery with it and then it would still allow indexes and wallets to to also understand uh you know the the current like locking state so like I could see. I mean a very naive way of you know.

B

Community recovery would be where let's say we have we, you know a person designates uh five friends of of them. uh You know to to be able that you know if all five of them vote, that uh this uh otherwise permanently locked soul-bound token should move accounts. You know know that only then the log function goes from a locked function goes from. Yes, this is being locked to know. This is for one transaction not being locked, but there's like I.

B

Think, there's I'm not exactly sure what the uh like how the white people describes uh specifically how they want to do a community recovery, I'm, pretty sure, there's like different ways of doing it.

B

I also I am aware, of course, of, for example, how the nurses, safe, multi-signature wallet, frames, I, I, think that you know that's also, essentially a kind of a community recovery or like a safety mechanism or or I guess you can even say like an eoa account abstraction mechanism um so but I think the the motivation with 5192 was really to uh to like fix this problem of people, just reverting on the transfer and so the the most immediate solution that came to mind was.

B

You know, to provide like the minimum, viable uh interface uh definition to just like to solve that.

C

I guess I understand your like ideation process, but I was wondering again. uh This unlock and locking uh function like the functionalities are is: is it like expandable to the to to some extent for Community recoveries in the near in the in the like near future, because I feel like there's a potential there, but also I was reading the magician forum and I realized that there are some like Community feedback around that this is this flexibility isn't really supporting The credibility of sbts and uh what are your thoughts about that.

B

Yeah yeah that that that's a great question, I think that goes back to my argument in the presentation on uh being able to enforce implementation with uh with ERC standards, where you know, I think some people would take the would take the opinion, and this this is like I, think the feedback that we're referring to that you know the the interface standard should not provide a conditional function for whether the token is locked or unlocked, and rather it should.

B

The the interface definition should kind of like uh you know, outline uh this this uh this signifier. That something is you know that a talk like that that an nft collection permanently locks, all the tokens so similar I think similar to how I first framed The Proposal. uh You know in in the very beginning of the talk where I said uh you know we could have this EIP 165 identifier. That then uh basically attains all of the nft collection that are permanently bound to an account and I.

B

Think the where this line of reasoning reason uh stops. Making sense is this argument of uh of that the the interface cannot achieve in enforcing the implementation, because, uh because we are merely like writing a document right and whatever the uh the developers then end up like being able to put into function, bodies is uh really not in my control or uh or anyone else's control, and so essentially I mean, even though I think that speaks against a lot of the composability rhetoric in ethereum I.

B

Think, most of the time when people are interacting with uh you know, erp20s Erp 720s, then uh there should not really be an expectation that you know uh you know one token behaves really like the others, because they are both part uh where they are both compliant to the same. You know token standard, because I mean people can really build. Like uh you know, different mechanics under you know into this uh into this um uh interfaces and, uh as I have documented with this, uh with this attack with sleep minting on nfts I. Think this.

B

This kind of also shows the the abuse potential of that. So so for me, it's um it was then not really a criteria to uh and I I would reject. The argument to say you know that this undermines The credibility um because in the end, like uh someone has to look at the solidity code and has to uh I guess like look into the transfer function and see if it really reverts.

C

Yeah, so so uh your idea, Catholics the user user experience like how it's compatible with the user experience on on a greater end, I see.

B

I think yes, I I think there is a there's. Another aspect to this that is, is potentially worth highlighting here, which uh you know. People have also criticized outside of the ethereum magician this approach of uh labeling, an nft as a soul-bound token, where uh you know they said this is entirely unnecessary because you know if you are reverting on the transfer function and the user in you know like assume, you are like this developer and you're building this like Soul Bond token for your community and you control the entire uh user interface.

B

uh You know the entire flow, then the assumption is that once the user hits the transfer button in, for example, a wallet like metamask, then they get back. This um revert error message. Custom error message that you know the token is uh Soul bound, and so actually you know the argument of of a person uh that that argues for that is. Essentially, you know. Why do we need an ER people that, right, if like this seems to be, you know, implementable on an application, Level and I.

B

Think uh I think the I think that's also important to mention I think from an ideation perspective, because I think uh you know exposing the user to such an unhappy path where you know they have to. Basically you know, click the transfer button.

B

They get like this red scary error message and then only then like if they're like enough technically sophisticated, then they don't lose money and they like immediately understand that this error message also means that, like some blog posts from vitalik in general, like not everyone, I think has you know the this like expert context, I think and so I think it's more important to you know, give like wallets marketplaces and other people and also, frankly, like other contracts.

B

The uh you know, the opportunity to uh you know like interpret the the features on a machine level and to you know, really understand and fix these interfaces where you know, for example, if we are issuing a solvent token to a wallet then also, maybe the transfer button is completely hidden or you know maybe there's also like I don't know. Now there could be like a pop-up saying, hey.

B

You received your first Soul Bond token, and you know here are the the ways you can interact with it or you can do a record Community recovery or something like this. They don't have to go through like this uh very unhappy path.

C

D

Hey Tim yeah, that was a great presentation, uh I'm glad to see some movement on the eips for solvan tokens. I I had um I had one question about about how you see this kind of being implemented by projects right. So if, if the premise is the 721 contract signals this support for 51.92 and then we kind of pushed the non-transferability logic to the client or by their check whether or not the token's locked, and if it's locked, the client won't attempt to transfer. So that's great, but do you ex?

D

Do you expect the small contract developers to also kind of override that transfer function? Is there some like just as a backstop if they really want to make sure so they get the ux improvements, but they also get that kind of like on chain enforcement.

B

Yes, so so um in 51 92 you are supposed to. If, if you basically, if the token is locked, then you are supposed to revert on all uh transfers essentially so this is uh I mean depending on the implementation, but this is what, uh on the interface level, what we mandate, what you should do and.

D

Then, um like I, by the way, I totally agree with your your point around like when you make an interface, you can't enforce the implementation details that it. It was a similar situation with uh EIP 2981, which was the nft royalties, like obviously you'd love to be able to enforce royalty payments, but it's just kind of not possible right now.

D

um What what I wanted to ask about was.

D

What what if um the 721 contract someone wraps it so you've you've, basically locked the token using 5192 to the 721 contract, and then someone wraps that 721 contract? What are the kind of like implications there.

B

It depends like basically, if the let's say we implemented a 5192 that permanently locks. All tokens and the transfer functions are reverting. Then I think you could not hack it I think on the level of of the transfer functions. Now you could I guess if you somehow got access to be able to emit an event. uh You know on behalf of that contract and you also were able to change the storage of the mapping. Then I. Guess you transferred it.

B

You know, while it should technically be locked, so that's not good um yeah, I I, don't really have an answer beyond that. I just think it's well yeah I I, hope. The um implementations for this are good I. Think, though, um I mean, at least from the non-transferable token case, I think we're getting technically rid of a lot of code from from the EIP 721 contract, and thank you for talking in terms of um creating more advanced functionality. You know where we have like Community recovery and so on, I think yeah.

B

Then it becomes uh more difficult. I felt like a couple of proposals you know of people like when they say you know how, when should we allow non-transferable tokens to be transferred between accounts and, for example, I've heard? You know someone say that um maybe only all of the tokens should be transferred at one.

B

You know should be transferable at once, so so that uh you can't really like sell one of them on the market or whatever, but but that really only if you have to do like account, recoverability account recovery, then you transfer them in bike, but I think in that case, uh that would also be kind of challenging and I.

B

Don't really see a solution for that yet and um yeah I I think really it's up to to us now, since this is also vinyl I, think people can rely on this and that it's not changing and so I think some experimentation can happen, and we can, uh you know, find things that work and that don't and yeah.

D

Yeah, this is really cool. Thanks for everything.

A

Thank you, yeah I, think most of the questions are now asked and answered. Yet I have a couple of more for you. So my first question is the thoughts on other Soul bound proposal. So 5192 is the first soul-bound proposal in the final status. There are five more at different statuses and they're, proposing slightly different use cases. I would like to talk specifically about two proposals. Number one is EIP 5484, consensual, Soul, bound token. This is uh currently in the last call and the deadline is November 5th.

A

uh This proposal basically suggests an interface for a special entity with immutable ownership and predetermined imitable burn authorization. I wonder what are your thoughts on this proposal and um do you think this may help the lock and lock for bone feature which was not initially considered for 51.92 yeah.

B

So actually, I have a I I ended up, sending a very strong feedback very strongly opinionated feedback to that proposal in the discussion thread that I I may regret. Also now the way I phrased it I think the proposal is actually very strong and I think it also implements essentially uh what the gsop paper really calls out, where you know they say the um the issue of a sold.

B

One token should actually be able to also revoke it um as well uh and- and you know like it even goes beyond that- where, where it allows to specify who should be able to burn the tokens, I think net, it's a net positive this. uh This proposal, I think um I, I, guess where, where my my feedback came in uh and where I was like critical or let's say there was like uh wanting to add like more more feedback to it was on the uh on the part of also potentially basing this on 50 5192.

B

Where you know uh 5192 uh would would then have this um this this base layer for for metadata, identification and feature detection, and then you know, on top of that, uh you, you would also have the the bone functionality and right now um the uh so 54 84 essentially has a bit of like undefined uh kind of like undefined Behavior around the non-transferability and, and uh it also uh binds to uh accounts and and there's also where this rhetoric comes into about.

B

Like uh you know, um uh you know a log function not being credible to the ideal of permanently binding a token to an account and I think so I think in general it would I mean I speak as the author of 5192 that it would have been stronger if that proposal made use of 5192, but I guess yeah, that's how it is so I'm, okay, also with it like this.

A

Right, ultimately, it is up to the editors to like Let The Proposal, be as standard or not, but I really appreciate you adding your feedback on Fellowship of ethereum magician, as you have mentioned it multiple times in your presentation. That fem is a really good forum where we can collect feedback from entire Community project developers, so we can come up with good set of proposals which can be considered as a standard.

A

Thank you so much for that and my next uh question um I mean like the part. Two of this question is about eip5114, that is, soul, bound bash. It is currently in the draft status. However, it was proposed before 51.92.

A

um The Proposal proposes a batch that is attached to a soul at mint time and cannot be transferred after that. So, if you could talk about the difference of the two proposal and you think that 5192 may have any advantage in terms of specs that may have helped it move faster in the final status.

B

Yeah, so in terms of the history as 51 14 is from uh we cut soil too, and so uh Mika was very influential in the beginning of the account bound token specification and uh Mika also brought up some very valuable points, especially with regards to uh you know, like account binding being this uh anti uh pattern and other things and so I think uh 5114, I I would assume is also a way like an expression, basically of you know, saying, like here's.

B

A an entirely different way of you know dealing with a compound tokens where you know, instead of binding to ethereum accounts that can hold balances. Now we would be binding to uh you know other nfts, so what uh 5114 does is? Essentially it allows you to. You know if, like consider, you have like this profile picture where you are I, don't know like a cat or whatever, and then uh what this proposal would allow you is to uh to buy you a to buy this character.

B

Also, sunglasses that you can then Soul bind onto the onto the nft, so it um I think in the in kind of the yeah. This I think what I also ended up saying what I said in the beginning is like there there's a diverse set of ideals.

B

People have around this concept of solvent tokens and I, don't think, there's like necessarily one really like right idea or whatever I actually I, really like the proposal myself um but coming uh you know my my background has been to build more Primitives for this new type of property class, and so for me uh it's it's just personally, not uh that useful in in, like you know how I need to work with clients but I think in general. It's it's very interesting and I. Think um if that ends up also getting uh standardized.

B

I can see that having like a broad range of application, especially in the nft pfp world, where I think already um people are doing this composition of different nfts with uh you know, like other tiles, where you can. Basically, you know you can buy, buy merch for your other time, so on um and and in gaming and so and and so on so I think it's a it's a nice proposal. I mean Mika also has a very uh nice way of writing and laying these things out so I yeah absolute recommendation. Of course thank.

A

You, oh, my God, has been a great contributor for ethereum repository. He was an editor who had made a lot of impacts and proposal coming from them, I'm happy to hear that people think positively about it and we hope to have it in a standard form one day.

A

Well. My last question is about the current EIP process. um You already mentioned about one other proposal, but I know there is one more interview status, so I'd be curious to hear your general experience with EIP documentation and if you may have any suggestion to improve the current process. Yeah.

B

It's a tough question, I think there's uh I mean this is a. This has been like quite an experience for me over the last six months. It's important to highlight that the opportunity that this gives to into the hands of people that are motivated to to do like a bit more long-term work. So, like none of my proposals, is really useful. Today, most of them are aspirational and the adoption time frame is probably like few years like three to five to ten years whatever.

B

If, if any adoption end up ends up happening anyways my work in the magician's Forum I have really liked it I think as I as I pointed out in the in the talk. Basically, it's it's essentially like a pipeline to get your idea validated to get other people to look at it and feedback. um I.

B

Think where people probably are unhappy with the uh with the ERC proposal specifically, is that there is no uh like or or authoritative, like uh you know, a stamp or whatever that that you know people say you know this is law or something official that everyone should be using, but that instead it's this and I have I've said this in my my lightning talk at Defcon 2., it's it's more like this.

B

You know stream of different threats that end up like finding consensus very slowly over time, and this takes uh just way longer in in terms of adoption than for example.

B

If you have a you know, an expert committee making a quorum decision on on, you know like uh implementing a certain thing right where I think you this much more actionable than if, um if people uh you know is each person individually makes a value judgment on whether they should adopt a thing or not, and so I think, while I'm I'm not suffering from the uh you know, the pessimism or the impatience, I have heard other people uh kind of like suffering for all, like I've heard, the the concerns and and I always like try to point out and that you know.

B

Maybe this is like a long, more long-term thing, but um yeah I think in like also other places. It's like this and yeah it's in the end, we're working on standards, so yeah foreign.

A

That's very valuable to us um Just for information. We are trying to like have a forum for people to who are proposing standard on a similar topic, be in in the same room and talk about it in this direction. Recently we started URL and URI meeting, which is now I'll move towards volunteer meeting, which happens once a month and led by Sam Wilson, um but cat headers are supporting that as well.

A

So we are hoping to have small working group created around a certain topic, so we can streamline the process and let the best proposal be your standard.

B

Yeah, that's that sounds like a good idea. I think the the I think in the Soul Bond token realm at least uh probably uh engaging the community in a working group would have uh yielded a more uh uni unified result where, where each and everyone was would be pulling on, you know on one rope instead of many somehow uh yeah I don't know, I'm, also a kind of like uh I, also like the idea of everyone just working by themselves and then like having this chaos.

B

Somehow that ends up like bubbling up the best solution, so yeah, I, I, don't know I I think both is valuable in the end and.

A

Right this is an experiment, let's see, if, if accept well, it's time to wrap up any final thing that you would like to add or share the daily implementary.

B

I yeah I just wanted to uh thank you for giving me uh the chance to speak here and yeah I'm, just very happy that this got finalized and I hope people find it useful and uh yeah. If people have information like information feedback uh questions, then yeah you can find me on the serial magicians forum and there's emails and telegram handles and whatever all included. So. Thank you very much.

A

Tim thanks for joining us today to talk about eip-5192 uh the latest nft standard. We appreciate your contribution to ethereum's EIP repository and I, look forward to have increased adaptability of this standard and maybe have you on the show again with another proposal to discuss.

B

Thanks yeah I hope so.

A

And on this note, thanks to everyone watching or listening to the special episode on nft standard, should you have any questions? Let us know in the form available in description or leave a comment or reach us at eatcad. Herdist is God check out description for link to useful resources and guest Twitter to follow. We will be back with another interesting ERC proposal, so stay tuned and keep sharing your love with Italian cat headers have a good one.