The tradeoffs of soulbound token implementations

Transcript

[Music] okay hi everybody good morning um I'm Holly Atkinson amongst other things I'm blockchain architect at the sandbox and I'm going to be talking to you this morning about the trade-offs of soulbound token implementations why soulbound tokens well it's big news since last year right these are just some recent examples we have some retail drops using Soul bound

tokens with Louis Vuitton Nike we've seen kyc soulbound tokens through for instance binance and more recently than that we've seen ethereum France's membership nft um sobound tokens have come up for me as part of my like r d at the sandbox and other projects um but what is a soul bound token well in its most simple format it's a non-transferable token and if you go to the EOP website you can stick in the word soul and a bunch of different standards will come up

detailing various interfaces and options for implementing soulbound tokens in your project but what are the differences because they all relate to soul soul bound tokens or Souls but there are some very key differences between them that I I want to put across to you today so to kick off we have this very minimal Soul bound token interface that you find in 5192 and that lets you lock or unlock tokens under certain conditions so the idea here is that your admin role or your owner can lock or unlock someone's tokens and this relates to 721s

and if they try and transfer their token when it's locked it's going to fail you're going to get an error and that's that's pretty straightforward similarly we have other kinds of non-transferable tokens where they're non-transferable except for instance being burned we have this in the consensual Soul bound token standard 5484 but this also brings in this idea of consensual tokens where there's some form of agreement between the receiver and the issuer of the token we have other ideas that people have brought in so that other kinds of data can be attached to tokens so for

instance the semantic Soul bound token approach 6239 allows to to build on 5192 where you can add in rdf triple data and if for those of you like I did who didn't know what this is it's adding in kind of like social relationships which is actually super useful for building the the social layer um and that allows you to add in Uris with that social data as well in a different vein if you don't want to allow any sort of admin or owner functionality within your contract if you don't want any transfer flexibility you can look to 5114 for a focus more on immutable data so let's say you deploy a

contract and you don't want anybody to be able to transfer their tokens or change any data ever you can make sure that you're using decentralized platforms for your storage and don't simply don't allow any transfer mechanisms as part of that coming on to a different approach now with 5516 there's this idea of a handshake approach to receiving tokens um kind of similar to to a consensual idea where there needs to be consent um and there's this option to claim or reject and this also factors in um like recovery mechanisms

there are other drafts in the system at the moment and they may or may not change obviously semi-fungible soulbound tokens bring in this idea of soul-bound life cycle functions so imagine you don't just want to lock and unlock your tokens but maybe you want to have different features within your smart contract for different purposes throughout your Project's life or different governance stages and you also want to factor and recover recovery mechanisms you can you can look through those interfaces and choose what applies and this token standard can be applied to a bunch of different kind of kind of types so not it's not just necessarily limited to 721s or 1155 so I'm actually

interested to see what happens with this one um and lastly on the list there's a similar kind of standard to 5192 where again tokens can be locked and unlocked but in single and batches and that relates to 1155s but they're all called solvan token standards effectively so what's the difference so the distinguishing factors really at a higher level relate to things like owner and admin rights so how much flexibility do you as a project or a business want to factor into your project the token type obviously is is a key

difference so depending on the sort of token drop that you want to issue you may want to look for a standard that's 721 1155 or something that caters for for a number of different different things there and do you want to have any kind of structure around consent to transfer or do you want to you know spam your users with a token that they may or may not be able to burn um and then again this concept of token life cycle where maybe you want to add or remove properties from a token throughout its life cycle so really catering to business logic governance mechanisms recovery and varying levels

of fungibility one thing that I found interesting was as well was how much input do you want your users to have for instance if you agree a burn off with your user but what happens if they then don't want to burn the token what if they would receive a replacement token that is less favorable to them for the for the use case it's super important to think about the users and and their perception and engagement levels okay now a reminder of dsock everyone is familiar with this paper right from last year this paper like you're not supposed to

be able to read the details but this is where this concept of Soul bound tokens really came from last year it's it's the trigger for all of this this building and really the paper actually doesn't just talk about soulbound tokens it talks about how soul-bound tokens are these composable elements as part of a co-determined sociality so there's this idea of plural Network Goods where there's richer data provided by users through their soul-bound tokens and users might have multiple Soul bound tokens within one profile you might also be able to look at aggregated profiles so until very recently we've been

limited to one soulbound token per user as in an eoa an ethereum address but now with account abstraction we can have some very clever clever things being built so I think actually with all of these composable products we're really well on the way to a decentralized society we just need to build the stuff the fun stuff so I've put some some stuff on here we've got the soul bound tokens account abstraction we also have this reason AI explosion we have zero knowledge and let's not forget Digi physical Goods to actually tie this in with real life a bit more

and this really is quite exciting when you think about the possibilities for the future metaverse it's really going to be a very inclusive place in theory in this in this pluralist future really building on decentralized governance looking at your cross-platform reputation and not necessarily just your in Project or in-game reputation and really using this idea of richer data to enable share shared rights maybe fairer returns based on the properties relating to your tokens in your profile and that can really be used in this virtuous cycle of community engagement

in theory if it's done well we need to build this stuff now so how do we get to dsoc we get we are getting there we have so many composable elements we can layer those in in a project and we can aggregate across projects to give this pluralism as a feature and so as a result we can build on things like account abstraction and really enhance this near-term and near-term is important here because I think there's a lot of protocols there's a lot of vision but actually there are some quite I guess simple things that can be built

now that are worth within our grasp now that we have all of the composable elements I've touched on some here so thinking about proof of liveness so not just proof of humanity right so not just proving you're a human but actually checking in on for instance a gamer at various points during their kind of user life cycle you can check maybe stick a streaming link into a soul bound token profile and then then look at that with you know account abstraction um and stick in some AI you can actually have ai making your kyc process for instance a lot more fun you can make it relevant across profiles and you can

check that you're not being um that your game is being played by real players who continue to be alive um other things like getting new users involved in a system maybe your profile tells a lot about who you are as a user maybe you want that maybe you don't depending on on kind of how Anonymous you want things to be but nevertheless there are some data points here that can be aggregated in a richer way such that you can be guided more on your interactions and if you need help getting to know a system this guidance can be tailored more to the user and so on another hand how about in real life perks so thinking about you've got

all these um nfts in your wallet like nothing new there but now think about that with your profile at a broader scale and add in some nft chips into your physical items and you've got some really interesting collaborations that people can work on that are really relevant at multiple events multiple places with multiple ecosystems moderation is a key one for something like the sandbox where we have user generated content thinking about having a profile with a reputation score isn't anything new but using that to really get your users involved in moderating other users and providing raw rewards based on

reputation attached to a profile could be pretty pretty key here and similarly encouraging creation and gameplay curation you could do a similar thing with like scoring and going back to user generated content we have no code tools for creators to build in their lands but what if those creators don't just want to build in the sandbox we could have this idea of creatorship across multiple platforms and that provides incredibly Rich data from a royalties perspective and finally it would be remiss of me not to talk about 6551 where you can make this even more interesting by adding in

self-evolving assets and having those linked to a profile as well so to conclude I see so much iterative potential for us to build on and now it's just time to go and build thanks everyone for listening thank you any questions cool um thanks for the presentation

really interesting um a common question when talking about sbts can you maybe talk about privacy a little bit and also how reputation um Works across different platforms privacy is an interesting one because it depends on the application and actually there are a lot of legal implications right so depending on on what the project is um your profile will need to give away different kinds of data so you may or may not be able to be private by default you can actually tie in zero knowledge obviously with soul bound tokens so an interesting one here was the sismo badges um which it it can allow you to attach multiple

accounts effectively to your profile without doxing other accounts that might hold interesting assets for instance so there's a lot of functionality to be provided by zero Knowledge from a privacy perspective I think also making platforms a non-friendly is something that there's a lot of interest in but it's it's this fine balance of um yeah like privacy versus legal requirements thank you [Applause] thank you