Token Design: Mental Models, Capabilities, and Emerging Design Spaces with Eddy Lazzarin

Transcript

so I'm Eddie Lazer and I'm the head of engineering for the crypto team and this talk is a pretty brief one I cover a bunch of topics in it but stay pretty high level and that's because I think a lot of people when they think about designing tokens there's some common pitfalls that I notice and I hope that these are useful in helping your design process so first I'll say that this topic was ostensibly about token design but the truth is that token design is a really early field and I think it's not correctly named the truth is this talk should be called protocol design because tokens are not the thing that you're trying to make what you're really trying

to make is a protocol and tokens are an incredibly interesting and useful and powerful and new type of tool that changes how protocols can be designed and what's even possible but they're still not the core object that we're trying to make I should say that a protocol design is more Alchemy than chemistry now in other words our understanding is far from comprehensive or scientific and most projects need to experiment in areas that few others have ventured so first mental models I'd like to start with sharing some simple models for the design process that smooth things over and the second part I'd like to talk more specifically

about what tokens actually are and how we can think about developing and enhancing their capabilities so first tokens serve protocols they're just a tool they're just a part of the design process and they shouldn't be the goal if you want to make something that's truly decentralized a real protocol stands the test of time a token is likely to be part of that because it's a great way to give ownership and Powers over a protocol as well as alignment to a wide group of people the token is likely to serve long-term decentralization here's a way to think about the design process that I've seen shared by successful projects I've seen in conversations with portfolio companies these three stages emerge

naturally from successful design processes the first is orienting around a goal a goal is just a concise description of the result of a functioning protocol what is it that you want to see out a goal should be unmistakable in terms of whether it has been achieved by a specific design so we should have a very clearly delineated success and failure condition that that goal describes if it's not clear what our goal is we need to start from the drawing board forget tokens we need to think about a few other things ideally a goal is measurable even if we aren't sure how to measure success just yet once we have a really clear goal for a

protocol for a system then we need to introduce constraints there's two kinds of constraints for generally endogenous constraints and exogenous constraints endogenous constraints are constraints that we choose to simplify the design process to commit to known trade-offs or they're just interesting things that we like it's totally possible to choose constraints just because you are familiar with that set of trade-offs in that area and you're playing through your strengths a really cool talk I saw that I can put in the recording notes was by subset games the team that designed a few really cool games like into the breach and fto and it talks about designing under constraints I

really recommend that talk for anybody designing a protocol they choose constraints just based on what's fun what they think makes fun in the game certain constraints are just delightful to consider so the point is endogenous constraints can come from many places but usually from you exogenous constraints are imposed On You by Nature by the state of Technology by regulations by all kinds of things we'll talk a little bit more later about exogenous constraints coming from technology it's a very interesting one once we have constraints and our goal now we can very cleanly and clearly think about mechanisms that can satisfy that goal according to those constraints

and I think this is where the substance of a protocol design happens right where we have we know what binds us we know where we're trying to go and now every time we consider a mechanism it should be really clear whether or not it violates those constraints and gets us closer to that goal or not and this can really simplify and make more systematic how you're reasoning at the end a protocol will be a family of mechanisms that all drive toward a specific goal According to some constraints so let me walk through a simple example maker protocol it's been around for a while and it's well understood there's a lot of wonderful documentation about it

if you aren't familiar their goal is to develop a stable asset native to ethereum and of course there's different ways to Define stable there's a couple ways to interpret native but that becomes clearer when we contemplate the constraints they accepted they decided that the price should be linked to the dollar it should be backed by fully native on-chain assets like if and a variety of other things some of those are endogenous some of those are exogenous some of them are just you need to choose a fork in the road and you commit to one and the whole family of systems of mechanisms that make up the maker protocol

are all pretty clearly intended to support some part of the design yeah some part of the goal this will be more useful for people who understand how Maker Works but I really recommend it as an example of an open protocol design that has very little fat on the bones although of course it was early in the history of on-chain protocols and we've learned a lot since then here's some common failure patterns the first is token first thinking I've already alluded to this a little bit but if you're thinking about Rewards or token allocations instead of Agents or how to preserve alignment among the participants in your system

you're probably not thinking about a protocol you're thinking about that token and the token is not the protocol the token shouldn't be uh your goal it should be just a tool how do you get out of this trap well besides the obvious maybe ask yourself how would the system work without a token I just remove the token altogether what fails if the system fails completely like it disappears without the token you're probably over emphasizing the role of the token if a few key parts of the system fail then you're in a slightly better place it's probably the case that your token is really important and necessary to balance it up holistically

but it's still coherent and explainable without the token you should still be able to have a conversation about the goals and functioning of the system without the token a second common failure pattern is having an unconstrained design space this is where you're trying to think about what the design what to build there's too many possibilities you don't even know where to start there's so much happening there's so much you could do this is usually the consequence of having an underspecified goal so go back and refine it it could also be because you lack an understanding of or you have not yet accepted constraints imposed upon you if you bring those constraints

in you will see that the design space will shrink and it'll become clearer what you what exactly you have to play with two questions that are helpful in constraining the design space is to ask yourself what's the powerful concept you're trying to build on usually if you're at this point in the first place there's a phenomenon out there that you as an entrepreneur as a protocol designer understand and you're trying to build on it you're trying to capitalize on something some an Insight some Advantage some change in the Zeitgeist what's that one powerful concept and how can you capitalize most on it focus on that thing focus on the strength as

opposed to the totality of the system the totality will come later another question is what's the biggest weakness of this design what's something that keeps you up at night about it or something that you think might not work or something that concerns you the key weakness and what constraint could you accept that would ameliorate it this can significantly limit the design space another common failure pattern is the community waste basket and this is where as a result of challenges in designing some part of the system you just say ah we'll offload it to the community like we're decentralizing anyway right so maybe rationalizing to yourself with a noble goal If You're Expecting unseen forces to

pick up the slack if you're expecting people to just kind of come in and see the problem and fix it you're taking a very risky bet although popular permissionless systems have incredible Innovation happening all the time and people build fascinating things that you would never expect using them you can't anticipate what they're going to do and you shouldn't expect that they'll fix the most obvious problems in your system a few key questions you should ask yourself you know what are we really expecting of the community like put that front and center instead of continuously tossing things into the waste basket just ask yourself what are we really expecting of them what are we giving them right I don't mean like are we giving them tokens

enough tokens I mean explicitly what powers are you giving them what capabilities are you giving them what ownership over what are you giving the community are they being given enough power to balance this responsibility if you really expect them to fix a thing and also ask yourself would you build here if you expect other people other ambitious people to come in and add some interesting new extensions or fix some component of the system would you if you wouldn't because it doesn't have enough upside or enough power or enough flexibility it doesn't make sense to expect others to do so next I wanted to present a little bit of a token taxonomy

this is not complete I've been talking with members of the team about this and I'm sure that we'll make modifications soon but this is just an attempt to enumerate all of the capabilities we've seen tokens exhibit so far and to connect that with some of the language I was using earlier tokens are an instrument in a protocol they're a tool and a protocol they're even more abstractly they're a data structure so how have we seen this data structure being used in different protocols I think you can separate them out into very generally speaking five categories of these five categories payment voting stakeholding metadata and claiming I'm

sure that there will be more resolution each over time and this grouping that feels at least to me more or less intuitive now will change but this this is how we have it I'll I'll walk through them really quickly and get some examples for payment uh we have three different noted capabilities one is an internal currency that's internal to a community or a project we haven't seen a ton of these yet but there are some examples for example Source cred was an interesting one FWB may be trending in this direction it's different from conventional payments like dollar payments because since it lives inside of a specific community and that Community has control

over that currency they could exhibit monetary policy type influences over that internal currency yeah maybe that currency is supposed to be stable maybe it's supposed to be linked to some other uh the value of some other specific asset maybe they Mint or burn it according to specific community-wide goals the point is that it just reflects payments internally a second probably the most commonly used and the most well understood way to use crypto for a kind of payment is as a network resource so eth falls under this bucket even Bitcoin falls under this bucket these are where you're paying for

computation or storage or some other crypto Network resource using this token we have eip1559 and we have you know staking and liquid say all these things where we reason about how this token can be used to renumerate different agents within a system specifically for computational resources the Third Kind of payment token is as an arcade token this is where there's a maybe a game a resource or some protocol resource that's meant to be stabilized meant to be priced more or less consistently where you're just being able you're able to use the system the

tokens price is meant to be more or less steady because you're getting a consistent amount of that resource or that you know opportunity to use that game or something like that the the key differentiating feature is that it's stable Supply doesn't matter and you're using it specifically to consume a specific part of an application you might say where do stable coins live in this realm certainly a stable coin could be used to pay for any of these you could use a stable coin as an internal current so you could use a stable coin as a to pay for network resources there's examples of that you can use a stable coin as an arcade token but what makes a stable coin a stable coin is the mechanism for stabilizing it you'll find that stable Quant examples

tend to fall into that last bucket claiming Loosely speaking there's two kinds of claiming there's Unchained claims which you're calling deposits and off-chain claims Retreat calling titles deposit tokens are tokens that represent a claim on another token it's purely an unchain thing an example would be like a uniswap LP token which in V2 was an erc20 and V3 is a an nft even die the stable coin that comes out of the maker protocol is a on-chain deposit because you use it or vault holder uses it to claim their underlying collateral so this is just

where one token's purpose the key functionality that we're discussing is to claim another token in an unchain context the second type of claiming token is where the token represents a title on some off-chain asset so that could be like a real world asset token or like a real estate token or something like that we haven't seen a ton of examples of this take off a more contemporary example would be what some people call redeemables right where the token represents a claim on a physical thing like a cool tradable sneaker or unisox from way back in the day there's some cool new contemporary ones where there's like a piece of art that trades with an nft and the nft represents a

claim over the yard and you can get the art delivered to you if you want there's even interesting ones where you can use the physical object to give you control over the nft so if you move that object around that object may have like some capability some digitally enabled capability like through a chip or something that allows you to take some controller ownership of the subsequent nft the voting capability is one that's been discussed quite a lot and really emphasized over the last couple years you know the so-called governance token there's three key capabilities for voting though you know voting is this often discussed but it of course has different specific meanings

you can vote to fund projects you can vote to allocate a treasury or other resources so that's where you vote just to make a payment or transfer as a group a second is where you vote to upgrade software this is kind of a key very crypto native very interesting one that is often debated tokens can be used to directly control the upgrade process for software which is really interesting you can also use it as a social consensus measure just people signaling what they think choosing a leader deciding the future plans for a project we see a lot of examples of this on

snapshot with off-chain votes then we have a stakeholding tokens tokens of course could be designed that are entitled to returns through a smart contract and so there's no legal agreement here but the functioning of the mechanism means that this token will benefit from some kind of on-chain activity an example could be maker right where if Maker Works and the maker voters that wide set of token holders do their job well and the system functions properly then they will benefit from some returns because that's the way that the smart contracts that's the way the protocol

was designed to reward good stewardship from the wide maker community you could also make tokens to be entitled to returns as a result of a legal agreement this would make it a security right you could you could make a token that represents an equity portion or equity share of a company of course there would be all kinds of legal requirements and restrictions and ways of this token would need to remain compliant with such laws but you could do that and there was a time when there were some people that theorized about security tokens by being its own interesting category of innovation although truthfully we haven't seen a lot of interesting development there you can also have a token that receives returns in exchange for underwriting risk maker does this too it's important

to say is that you know if there is a shortfall in the maker protocol then more maker tokens are created which dilute the maker holders two make the protocol whole so by holding maker tokens you hold some risk you take some risk in that asset and that is part of what drives a maker holder if they want to see their purchase appreciate that's what would drive them to support the system right it creates the alignment risk is distributed among the token holders and if they do their job the system should function and they may make some money or their asset May appreciate

metadata this bucket's a little crowded but I think you'll see why there's membership membership is where a token is used to decide or holding a token is used to decide whether or not you can access a specific space or whether you're in a specific Community or you know whether you're in some group that's deliberately a little bit vague because a protocol or some third party writing a tool can take advantage of that membership property in any way that they want right it's permissionless it's interesting of course some nft Community as an example could decide that only people who hold the token can join like the community group chat but someone else could do the same thing someone else could say I'd like to read that membership list and

I'd like to offer specific functionalities to the people who hold this token so the point is to say is that the membership your status is being in this group or not is an interesting type of metadata that having that token provides I haven't described whether any of these tokens are transferable or not fungible or not I see that as a parallel property some of these obviously work a lot better if they're fungible you know for example payments would be a little bit tough if they weren't fungible reputation is an interesting one some people talk about whether or not reputation should be transferable I personally think it probably shouldn't be but it probably should be fungible for certain cases and non-fungible for others an achievement or a badge right

where you have like a discrete measure that you've done something or achieved something or that you have some specific role that's a kind of a reputation that's non-fungible this Source cred or different types of credit scoring systems are a little bit more fungible just because it's a continuous range so that's one kind of metadata that a token can bear another is an identity or a reference ens is an example of this this is where the token provides a kind of metadata that simply points to something else so in this case an ens name can point to address or which can be updated not unlike the DNS system it's just a reference to

something else within the machine off-chain data of course can be a kind of metadata an example would be like a an off chain kyc or some sort of verifiable credential another good example like a diploma or academic qualification someone hands this to you and now this piece of information is available in public with approval lineage provable authenticity on chain so any kind of off-chain data a more subtle one different though that we haven't seen a lot of examples of I think I'm really excited to see more examples of is ways to represent permissions and capabilities on chain so this is where some entity explicitly grants you a permission like a ability

to call a function or change a piece of code or to transfer something on chain but potentially through levels of indirection so for example I could give someone in my Dow the capability to Grant other people temporary memberships it might make sense to do this with some type of token some sort of badge that has this metadata another really cool one that I think probably the party Dow team has had the most exciting conversations with me about is tokens that have their interface within them as a kind of metadata it's a really cool one we've seen examples of this where more than just having the SVG data in a

tokens URI you could also put a whole HTML web page you could even put a little JavaScript if you wanted you can put an interface and the control to the interface within the nft which means that an nft can bear with it the means of using it it's kind of a inversion of the way that we typically think about it but there's no reason that can't be the case all the people to talk about and think about rightly decentralized interfaces should think about that maybe you can embed the interface in the very object that people own and transfer or have so that wraps up the tour of token's capabilities I think it's exhaustive so

far actually maybe there's a couple small tweaks I'm already thinking about but if you have any that you'd suggest that don't quite fit in I'd love to hear from you about them just to make really explicit I've already talked about maker a couple times as a good example maker has two Tokens The mkr Token which has the capabilities on the left and the die token which is chiefly the capability on the right you can think of any token as having some set of these capabilities another cool example I saw really just neat because it's so different from maker and I think that it's creativity along these capabilities what makes it so delightful this Project's called beeper and uh you mint an nft with a text and

then you can broadcast text to other beeper holders only through having it and those texts get displayed on the entities representation like if you went to the openc page it actually renders on the little image of the Beeper when you have a beeper you can also message other beeper holders directly like individually using xmtb which is great so it's so what are the capabilities of this token like you have this token you can see the beeps on it presumably any wallet interface that can represent the animation URL properly can show you whatever beeps you have on there just just by supporting that standard what are its capabilities well

it's definitely a membership token because by being a beeper holder you receive all the Bieber messages and you can message other beeper holders right so this something only happens within that set it's also an identity token a reference because they message you using the token ID of your beeper nft I presume I actually don't know but it'd be kind of amusing if you traded or sold the beeprint Ft you might start getting someone else's messages which is funny and it contains within it an interface for viewing information relating to that nft like which messages have been broadcast to it pretty cool so here I'm showing the token capabilities again but kind of

highlighted them in slightly different colors the darker ones are ones that we've done more work on recently in crypto I don't feel very so I'm sure very happy to be wrong about this it's just kind of my squint taking a quick squint and looking type of view you know as an example we've thought very deeply compared to other things about how to think about a crypto token as a payment token for a network resource the analysis of efe 1559 is a great example all the interesting auctions MAV this is an area of deep research whereas by contrast you know interfaces and Views like representing the interface for a token or set of tokens

in the metadata is something that is brand new I I've heard very few projects talk or think about it even though people do think about decentralizing interfaces so if you take this view of the world you know some capabilities we've gone deeper in some capabilities we haven't why is that right and I I don't have a super complete answer but I want to gesture at it a little bit in part three where I talk about the tech tree theory of the world and the tech tree theory of protocol design uh here's like a little bit of a tree this is far from complete this is just me drawing like a kind of cool image where if you take D5 as an example D Phi is this whole interesting field that's been important in crypto

and kind of appeared seemingly very suddenly and has all these different sub-specializations and mechanisms that make it up why did they appear when they appeared and why have certain things been around longer than others well take lending protocols as an example it'd be really hard to imagine a lending protocol that functions without stable coins and that's because when you take out a debt in a lending protocol you want to denominate it in a stable asset whose price You can predict taking out a debt and a volatile asset is going to be very hard to reason about so we needed stable coins before we could really have lending protocols

similarly we kind of needed amms for Lending protocols too because if you want to take leverage using a landing protocol especially at early simple lending protocol you need to be able to take what you borrow which might be stablecoin if you want to have leveraged exposure to some other asset and you want to be able to trade that stable coin very quickly for the asset you want more exposure to like you kind of need an ant in other words you need an amm to lever up so we didn't really see lending verticals take off until we had functioning amms and stablecoins but how do you get functioning MMS and stable coins I think it would be really

difficult to do so without an erc20 token right without a interoperable token standard because the stable coins MMS and all the systems around them need to be able to make presumptions about the ways other projects will interface with them for there to be erc20 tokens you need fully programmable smart contracts you probably don't really really need them but that's how they emerged for the first time on ethereum because ethereum launched without an erc20 token standard and we needed full programmability to be able to leave the design space open enough so that people could make it at that point could be debated I'm willing to concede it but you can you get my idea that there's a little bit of a tech

tree and there's certain technologies that exist as prerequisites to other ones so here are two questions what are the key technologies that unlock the applications and Protocols of the future for example which Technologies do we need in order to develop useful reputation systems or decentralized and trustless interfaces and the second question kind of by inverting the first what are the applications and protocols that will be unlocked by nearby Technologies by nearby I mean technologies that have just been developed or will be developed very soon for example account abstraction eip4844 vertical trees zero knowledge machine learning like clients all these are

really cool nearby Tech many projects are thinking about taking advantage of them what will be the results one reason I think that these questions are interesting to ask is because technology can alleviate or introduce design constraints if we anticipate specific Technologies coming how does that change our design if specific Technologies would alleviate constraints we recognize that may be too restrictive for us should we spend effort developing them I think if we think of things as a tech tree it may help you reason about what's coming or what you need to arrive at a set of constraints that you want so to tie it back to my initial constraints point I think that new technologies alleviate constraints that we had before

and to give you a specific example if there was no erc20 standard then a constraint on any amm or stablecoin design would be that it would either need to introduce a standard or be able to cope with all kinds of different designs imagine designing an amm that is General but doesn't use a specific token standard for people who want to plug into it they'll be really really difficult I think that would be an almost insurmountable constraint but having that interoperability standard means we can take that for granted and say we're going to support the erc20 token and that limits the design space which makes it possible to implement such a thing

so if we anticipate specific Technologies coming down the line how does that affect the constraints for our protocol design if we have specific things goals we want to achieve with our protocol design or specific constraints that are limiting what are the technologies that we need that would alleviate those constraints and make those goals possible again with new mechanisms I hope these perspectives are helpful and thank you to everyone who helped me refine these thoughts or participated in the discussion of founder Summit