How to Design a Token System, Shermin Voshmgir, Token Kitchen | ETHSofia 2025

Hi. Um, thank you and thank you Vlad for inviting me here. The last time I was in Sophia was in 2016. I had just stepped up as a curator of the DAO because Gavin Wood had stepped down. Um, and uh, two days later the DAO was hacked.

Um, and I on boarded the flight, arrived in Sophia, and instead all my agenda plans uh fell short. Uh, I met Vlad in a Bitcoin cafe. Um, but basically the whole time I was in Sophia in 2016, we were in online chat, the curators who had no powers because it was supposed to be super decentralized and we were trying to figure out what we can do in the absence of any rights we had as curators. And um, nine years later, here we are again in Sophia. A lot has happened in the DAO space.

And recently people are saying Dows are dead. I don't think Dows are dead per se, the idea. Um, but I think the tokens, these protocol tokens of the Dows were flawed. They were not sustainable. and I'm here today to uh present a design thinking framework of how to design resilient token systems whether it's for simple asset tokens or more complex DAO uh or protocol tokens.

So um I started Blockchain Hub in Berlin in 2015. Moved on to uh create the research institute for cryptoeconomics. Now uh and in the pandemic I started co token kitchen in uh Portugal. Over the years I wrote the book token economy. It was just released in the third edition.

And in this third edition I worked on this design thinking framework which I'm presenting today. It's also an online tool and in the book I use the tool. It can be used to analyze token systems to make investment decisions but it can also be used to create your own token system. Um you don't have to read the book though I think it would give great background knowledge especially the analysis of the use cases. Um there's also a free online tool that you can download on the website um u the token kitchen site and it's basically um an Excel file that you can download and that will help you analyze or create um token systems.

This tool is qualitative. It's not quantitative. What does it mean? One of the downfalls of I think crypto especially with Dows and protocol tokens was that people uh jump to the quantitative questions like uh which formula to use uh do we need uh bonding curve? What type of bonding curve?

Quadratic wing? How many tokens to issue? These are important questions but they are not the first questions you have to ask yourself. You have to ask the soft questions first. And actually people I think don't do it because the soft questions are hard and they take time and um so this this framework I'm presenting uh is about these qualitative soft questions that are very easy and I as I said in the beginning you can use this to evaluate or create simple asset tokens for real world assets stable tokens uh whatever but uh it is um even more useful for creating more complex protocol tokens especially if you're thinking of designing uh protocol tokens with various token types.

So why are people saying Dows are dead? Why is it so hard to create a resilient token system? And I think there are several reasons. First of all, the design of your token depends on the purpose of what you're trying to create. Um, and is it is it a centralized or decentralized system?

Is it going to be capitalism on steroids or socialism on steroids? Do what you want, but be very clear about it. And your token design has to reflect your goal. Um, and very often the token designs do not reflect the goal. And this is when they fail.

Um, another issue is that I saw many people over the years, we studied many token systems and we spoke with many people, did some consulting, they want to go too fast in the beginning and they do too many mental shortcuts. Okay, so they they're like, oh, bonding curve, don't understand the mathematics behind it, think it's a magical formula and want to rec recreate it, maybe tweak it a little bit. very often they just take it copy paste it but it may or may not make sense for what they're trying to create. So the copypaste mentality in my opinion needs to be replaced with a more design thinking mentality um that would help to create more resilient token systems. Another issue is that um tokens can represent as many of you know many different rights.

At the time we're still in very early days of token adoption and most tokens represent some kind of asset, some kind of property right, but tokens can represent so much more. They can represent voting rights, management rights, information rights, um access rights. Information rights are a subclass of access rights. And we need to a understand the different types of rights the tokens we're designing represent. And very often for example voting rights are attached to property rights to to equity.

And this is when things go wrong because protocols are being designed that are being promoted as decentralized and everyone can collaborate but then it's attached to equity um and um the power structures are totally off 5% control everything. So when we design these systems we need to understand the different types of right and make sure that we don't attach them one to each other. So the framework presented comes from four different perspectives. Obviously technical engineering is very important but these questions shouldn't come first. When you're designing a token system you have to ask the non-technical questions first.

The technical questions and the legal compliance questions are very important. You have to ask them but the order of events should be reversed. The questions, the economic and the political orethical questions are more important if you want to create uh protocols where people keep contributing and consuming protocol services over time because if it doesn't make sense for them um they will just leave and we've seen it with many many protocols. Uh first and foremost, one of the use cases I analyzed in the book was Steemit. Um a social media um protocol that had over 1 million active users in 2017.

It was a great thing, but it failed because of really bad protocol design. it didn't make sense for people to contribute to the system anymore or to consume system services because the rich were getting richer and um reputation was being attached to equity and that didn't make sense. Um the headline questions in this framework are like first question what is the purpose of what you want to create? We'll go into the details. uh what are the principles upon which you want to build what you want to create and this is very important.

Why are the principles important? Because we live in a world of trade-offs. Trade-offs between privacy and institutional accountability and you need to know what your principles are when you make these trade-off decisions in your token design. Um positioning obviously is important but the functions once you know what what you want to create what is the purpose and what are the principles the question is what are the main functions of the system and what are the subfunctions then which stakeholders will participate in your protocol what are the roles and um only then can you start asking yourself the question about what type of token do you need and how many token do you need uh token type or different types of token types and then you look at the token design from an economic perspective, legal perspective, technical perspective and political perspective. Why political?

Because any system always has power structures. We can try to pretend that it doesn't, but it does. And the initial conditions matter and how the initial conditions and the rights you attach to the tokens unfold over time. How uh rights are attached to the tokens, how the tokens are distributed initially and over time will determine the power structures. And nobody wants to be part of a system where 5% control everything because you you don't have the guns.

If you're a protocol designer, you don't have to guns to keep the people. You don't have the IRS. You don't have the police or the army to keep the people in your system. If it doesn't work for them, if they can't make money, if they don't have any other benefit, they will leave. They will leave and play with another protocol.

So, you have to make sure that the power structures that will emerge won't derail the whole system. So, it's not a magical formula and it's not a fast thing to do. There is no oneizefits-all solution. The only thing that I can say is take your time. Time is your friend.

I know everyone is busy. I know investors are rushing. I know you have to pay your rent and obviously time is always an issue. But the more time you take in the beginning to to anticipate the issues that can emerge with power structures etc and with unexpected stakeholders that will emerge over time. how you will react when things happen that you didn't anticipate, what kind of governance mechanisms you have in place, the more time you will save later.

So time is your friend. We'll rush through. We have five minutes. So obviously it's it's like this whole questionnaire set of questionnaires that supposed to help you. We're not going to go through all the questions, but you download it.

You have some sheets. When it comes to purpose, I I I would like to spend some time talking about this. Very often I see people, they're very unclear about their purpose, what they want to do, or they have multiple purposes. Try to focus on one purpose, especially if you're designing protocol tokens because you're designing a protocol that is supposed to automatically align incentives of different stakeholders. And aligning incentives of people with different needs is already very very difficult if you have one purpose.

And if you have multiple purposes, this is when things get complex. So try to keep it simple. Do one purpose first and then if you have a minimum viable economy, if you have a critical mass, you can add layers on top. Maybe or maybe not, but keep it simple at least at first. um political principles as I said like the biggest questions here are regarding power structures anticipate power structures they always emerge and they're always the downfall of what we call Dows Dows are dead protocols right they they always become the downfall because people didn't anticipate power structures that emerge as a result of the token design um and there is a lot we can learn from all the protocols that have failed.

So I don't think as I said Dows are over. We need to learn from the best practices and the worst practices. Um and if you're interested in my book as I said I analyzed some of uh the Dows that have been uh there for a time. The biggest uh the other biggest tradeoff is regarding privacy versus accountability. Obviously blockchain networks there is a lot of institutional uh accountability a lot of data out there.

Privacy is an issue. So be very clear about the system you want to create like what is the what are the privacy principles you want to uh uphold and what are the privacy principles you have to uphold because you have to be legally compliant especially in in jurisdictions like the European Union where data protection laws are um very high but at the same time contradict blockchain networks so it's difficult um positioning this is not crypto related. Obviously, any system you create, you have to see is there any other system out there that already does the same thing. Functions, this is where many projects fail also because not thinking in functions. For developers, it's easier.

For non-developers, sometimes it's not that easy. Um like what are what is the main function and what are the sub functions and who is going to fulfill which function in your system. But first you need to list the main function, the sub functions, the priority of the functions. Um um how are they related to each other? Who should fulfill each other function?

How do you incentivized function fulfillment by different types of stakeholders? Uh vault owners in no um um um traders etc. And are the functions automated or nonautomated or semi-automated? Because not everything can be automated and we need to acknowledge this too. And then you identify the stakeholders.

And here it is very important to not only identify them but group them internal versus external like the people the the the stakeholders close to your system and at the fringes of your system. producers of infrastructure services, protocol infrastructure services, consumers, um, human versus automated. Humans have to be incentivized in a different way than bots because they make mental shortcuts and bots make less mental shortcuts, but they have the bias. So, uh, but understanding the differences private versus institutional is also a an important difference. And then you can list all these stakeholders um attach a role a function understand what their rights and permissions are and how do you incentivize them and how do you disincentivize them?

What are their rights and what are their obligations only then do you move on to asking yourself okay for for this what do I need to do? Do I need one type of token? Do I need several types of tokens? And then you go on designing these tokens from different perspectives. And this whole questionnaire is iterative.

So obviously you cannot fill this out in an afternoon or in an hour. You start filling it out, you circle back to it. Uh it's not necessarily linear. So identifying rights like is it a funible token then supply is an issue. Instability could be an issue.

Is it a nonf fungeible uh token? Then I need to think about pricing strategies um etc. Transferability is is an issue. What's the minting event? What's the burning event?

Is it convertible? Is it not convertible? The these are economic legal questions that you have to ask yourself. In the legal design, very often it's about compliance. We're not going to go into these details.

It's uh but you have to be able to more or less answer these questions for yourself. The technical design obviously is very very important. The mistake that I see many times is that people ask the test technical questions first. But you have to ask the what you want to do and whether it's legally compliant first and then obviously the question of which infrastructure you use, how privacy preserving is it, does it have the necessary scalability, interoperability, which token standards do you use? Very important.

Not the first question. Um, always keep in mind the power structures and I know I've been repeating it a few times. Power structures always exist, always unfold. Acknowledge them, anticipate them, work with them, or it's your downfall. Uh and here we have different types of powers policy who how what policymaking powers who has policym powers are there well distributed uh who has voting powers who has information powers who has market powers in which market powers mediation powers and account for the fact that when you're designing a token system there will be stakeholders you don't think of but will be part of the system later and then they influence this whole thing.

Um, yeah. So, you want if you want to create capitalism on steroids, be my guest. But don't sell it as socialism. Right? This is when you lose your users.

You want to create socialism then have the adequate token design where the people who use your system can actually influence the policym of your system or don't sell it as socialism and I call it socialism aka democracy aka decentralization. It's not decentralized when the people using it cannot influence the policym um because there are all these different. So be very clear, do what you want, but also understand that if you promise something you don't deliver, nobody will play with your system and playing alone is not fun. All right? So team composition needs to reflect what you're trying to do.

If you want to learn more, the theory is in the book. Uh you can download the tool from token kitchen. And if we have questions, time for questions. Um, we don't have time for questions, but I will be out there, so approach me if you have some. Thank you for your attention.