Original title: 7 Sanity Checks Before Designing a Token
By Guy Wuollet
Compiled by: Katie Gu, Odaily Planet Daily
Tokens are a powerful new primitive that can be defined in many ways. The token design space is very rich, but we are still in the early stages of exploration.
In practice, many teams struggle to find the “right” token design for their project. However, the industry lacks a tested design framework, so the same challenges are repeatedly encountered by later generations. Fortunately, there are (a few) early examples of successful token designs. Most effective token models have unique elements for their goals, but most flawed token designs have some common bugs. Therefore, this article will discuss why we should think about token research and design, not just “token economics”, and list seven tips to “avoid pitfalls”.
#1 Clarify the goals of your token design
The biggest problem in token design is how to build a complex token model before clarifying the goal. The first step should be to identify the goal and make sure the whole team can fully understand: what is it, why is it important, what do you really want to accomplish? Failure to strictly define the goal often leads to redesigns and wasted time. Clarifying the goal also helps avoid the problem of "making up a token economy for the sake of designing a token economy", which is a common phenomenon in some token economic designs.
Additionally, goals should be centered around the token itself, which is often overlooked. Examples of clear goals include:
Design a game with a token model that allows for optimal scalability and support modeling.
A DeFi protocol hopes to design a token model that reasonably distributes risks among participants.
Designing a reputation protocol that secures money cannot be a direct substitute for reputation (e.g., by decoupling liquidity from reputation signals).
Design a storage network that ensures files are available with low latency.
Design a staking network that provides maximum economic security.
Design a governance mechanism that elicits true user preferences or maximizes participation.
The list goes on. Allow tokens to support any use case and achieve any goal, not the other way around.
So how do you start defining a clear goal? Well-defined goals often come from the "project mission." While the "project mission" is often high-level and abstract, goals should be specific and reduced to their most basic form.
Let’s take EIP-1559 as an example. Roughgarden states a clear goal for EIP-1559: “EIP-1559 should improve the user experience by providing simple fee estimates in the form of an ‘obvious best bid’ outside of periods of rapid demand.”
He went on to offer another clear goal: "Can we redesign Ethereum's transaction fee mechanism to make setting transaction gas prices more 'smooth' like shopping on Amazon? The ideal would be a price publishing mechanism, which means providing each user with a mechanism to accept or give up the gas price."
What both of these examples have in common is stating a high-level goal, providing a relevant analogy to help others understand your goal, and then going on to outline the design options that best support that goal.
#2 Evaluate existing work based on first principles
When creating something new, it’s a good idea to start with something that already exists. When you evaluate existing protocols and existing literature, you should evaluate them objectively based on their technical merits.
Token models are often evaluated based on the price of the token or the popularity of the associated project. These factors may have nothing to do with the ability of the token model to achieve its stated goals. Valuation, popularity, or other simplistic ways of evaluating a token model may cause the Builder to take detours. If you assume that other token models work well when in fact they do not, you may create a token model that is inherently flawed.
#3 Clarify your assumptions
Articulate your assumptions. When you’re focused on building your token, it’s easy to take basic assumptions for granted. It’s also easy to mis-express the assumptions you’re actually making.
Take, for example, a new protocol that assumes that its hardware bottleneck is computation speed. Making that assumption part of the token model (e.g., by limiting the cost of the hardware required to participate in the protocol) can help align the design with the desired behavior.
However, if protocol and token designers do not clearly express their assumptions, or if the assumptions they express are wrong, then it is possible for actors who are aware of this mismatch to extract value from the protocol. Hackers are often those who understand the system better than those who originally built it.
Articulating your assumptions makes it easier for people to understand your token design and ensure it works properly. Without making your assumptions clear, you also can’t validate your assumptions.
#4 Validate your assumptions
There’s a saying: “It’s not what you don’t know that gets you into trouble. It’s what you’re sure isn’t so.”
Token models often make a series of assumptions. This approach comes in part from Byzantine system design, which is the inspiration for blockchains. The system makes an assumption and builds a function that guarantees a certain output if the assumption is true. For example, Bitcoin guarantees liveness in a synchronous network model, and consistency if 51% of the hashing power in the network is honest. Several smaller blockchains have been 51% attacked, violating the number of honesty assumptions that Nakamoto consensus requires for a blockchain to function properly.
There are a number of ways that token designers can validate their assumptions. Rigorous statistical modeling, often in the form of agent-based models, can help test these assumptions. Assumptions about user behavior can also often be validated by talking to users, or even better, by observing what people actually do (rather than say they do). This has a higher chance of success, especially through incentivized testnets that produce empirical results in a sandbox environment. Formal validation or intensive auditing will also help ensure that the codebase behaves as expected.
#5 Identify the “Abstract Barrier”
An abstraction barrier is an interface between different layers of a system or protocol. It is used to separate different components of a system, allowing each component to be designed, implemented, and modified independently. Clear abstraction barriers are useful in all areas of engineering, especially software design, but are even more necessary for decentralized development and large teams building complex systems that cannot be understood individually.
In token design, the goal of removing abstraction barriers is to minimize complexity. Reducing (inter)dependencies between different components of the token model can result in cleaner code, fewer bugs, and better token design.
For example, many blockchains are built by large engineering teams. One team might make assumptions about hardware costs over time and use that to determine how many miners contribute hardware to the blockchain at a given token price. If another team relies on token prices as a parameter but doesn't know the first team's assumptions about hardware costs, they could easily make conflicting assumptions.
At the application layer, clear abstraction barriers are critical to achieving composability. As more protocols are composed with each other, the ability to adapt, build, extend, and remix will only become more important. With greater composition comes greater possibilities, but also greater complexity. When applications want to compose, they must understand the details of the composed protocols they use.
Opaque assumptions and interfaces occasionally lead to obscure bugs, especially in early DeFi protocols. Obscure abstraction barriers also increase the efficiency of communication required between teams working on different components of the protocol, thereby extending development time. Obscure abstraction barriers also increase the complexity of the protocol, making it difficult to fully understand its mechanics.
By creating clear abstract barriers, token designers can more easily predict how specific changes will affect each part of the token design. Clear abstract barriers also make it easier to scale a token or protocol and create a more inclusive and expansive Builder community.
#6 Reduce reliance on external parameters
External parameters are not intrinsic to the system but can affect overall performance and success, such as the cost of computing resources, transaction volume, or latency in the early stages of a token model’s creation.
However, unexpected behavior can occur when a token model only works when the parameters remain within a limited range. For example, a protocol that sells services and provides kickbacks in the form of fixed token rewards may have a value greater than the cost of the service if the price of the token is unexpectedly high. In this case, it is quite cost-effective to purchase an unlimited amount of the service from the protocol, which fully utilizes both the token reward and the service.
Or to take another example, decentralized networks often rely on cryptographic algorithms or computational puzzles that are difficult, but not impossible, to solve. The difficulty often depends on an exogenous variable, like how fast a computer can compute a hash function or a zero-knowledge proof. Let's say there's a protocol that makes assumptions about how fast a given hash function can be computed, and pays token rewards accordingly. If someone invents a new way to compute a hash function faster, or just has outsized resources to solve the problem that are disproportionate to the actual work they're doing in the system, they can get an unexpectedly large token reward.
#7 Revalidate your assumptions
Designing a token should be like designing an adversarial system. User behavior will change as the way the token works changes.
A common mistake is to adjust the token model without ensuring that arbitrary user behavior still produces acceptable results. Don’t assume that user behavior will remain unchanged by changes to the token model. Often this mistake happens late in the design process, after someone has spent a lot of time defining the goals of the token, defining its functionality, and validating to ensure it functions as intended. They then identify a special case and change the token design to accommodate it, but forget to revalidate the entire token model. By fixing one special case, they create another (or several other) unintended consequences.
Remember not to let your hard work go to waste, and whenever a project changes its token model, revalidate that it is functioning as intended.