Tokens are a powerful new primitive that can be defined in many ways; I’ve argued why we ought to consider the study and design of tokens as much broader than just “tokenomics” here.

Tokens clearly allow for a very rich design space. But we’re still in the early stages of exploring, let alone improving token design. The holy grail to attain here would be the modern equivalent of what’s commonly referred to as “the Dragon Book” by computer scientists. This book, which refers to Compilers: Principles, Techniques, and Tools (by Alfred Aho, Monica Lam, Ravi Sethi, and Jeffrey Ullman; and could sometimes also refer to earlier editions of that book or Aho’s and Ullman’s older work Principles of Compiler Design) — unified, defined, and influenced the study of compiler design for generations of computer scientists. So much so that two of the authors were named ACM Turing Award winners just a few years ago “for fundamental algorithms and theory underlying programming language implementation” and “for synthesizing these results and those of others in their highly influential books, which educated generations of computer scientists”.

We are far from the Dragon Book for token design — it is too early to produce a definitive text on tokens. Our Head of Research Tim Roughgarden notes though that we are likely a little under a decade away from this, it’s an ongoing body of work. Because the Dragon Book helped turn the “impossibly messy”, big computer science problem of the 1950s — of compiler design — into a more well-solved problem that could be tackled in stages, applying rigorous principles at each stage.

But some of the early opportunities, and pitfalls, are already becoming clear — so I thought it would be helpful to builders out there if I curated a list of some of the sanity checks our team often discusses when working with others on token design. I also encourage you to watch this recent talk on token design by Eddy Lazzarin, which covers mental models, common patterns and pitfalls, current token capabilities, and many design spaces left to explore.

The practical reality is that many teams endeavoring to find the “right” token design for their projects are often working without a tested framework for design — and thus run into the same challenges others have encountered before them. Fortunately, there are also early successes and examples of “good” token design. Most effective token models will have elements unique to their objective, but most flawed token designs share a number of common pitfalls. So here’s a list of instructive tips to avoid the most common failure modes.

#1 Have a clear objective

The greatest pain in token design comes from building a complex model before explicitly stating an objective. There is no such thing as a good token model or a bad token model — there is only a token model that achieves your objective, or a token model that doesn’t.

The first step should always be to rigorously interrogate the objective, and ensure you (and your team) fully understand it: what is it, why does it matter, and what are you really trying to accomplish? Failure to rigorously define an objective usually results in a redesign and lost time. Clearly defining an objective also helps avoid the “tokenomics for the sake of tokenomics” issue that’s a common (and not unfair) criticism of some token designs.

Furthermore, the objective should be specific to the token. This may seem obvious, but is often overlooked. Examples of such objectives could include:

…the list could go on and on. Tokens can support any use case and objective — not the other way around.

So how do you start to define a clear objective? Well-defined objectives often arise from a mission statement. While a mission statement tends to be high level and abstract, an objective should be concrete and reduced to the most elemental form.

Let’s consider EIP-1559 as an example. One clear objective of EIP-1559 is perhaps best stated by Roughgarden as: “EIP-1559 should improve the user experience through easy fee estimation, in the form of an ‘obvious optimal bid,’ outside of periods of rapidly increasing demand.”

He continues by codifying another clear objective: “Could we redesign Ethereum’s transaction fee mechanism so that setting a transaction’s gas price is more like shopping on Amazon? Ideal would be a posted-price mechanism, meaning a mechanism that offers each user a take-it-or-leave-it gas price for inclusion in the next block. We’ll see … that the transaction fee mechanism proposed in EIP-1559 acts like a posted-price mechanism except when there is a large and sudden increase in demand…”

What both of these examples share in common is stating a high-level objective; offering a relatable analogy (possible in this case) to help others understand that objective; and then proceeding to outline the design that best supports that objective.

#2 Evaluate existing work from first principles

When creating something new it’s always a good idea to study what already exists. As you evaluate incumbent protocols and existing literature, you should evaluate them objectively on the basis of their technical merits.

Token models are often evaluated based on the price of the token or the popularity of the associated project. These factors can be unrelated to the ability of the token model to meet its stated objectives. Valuation, popularity, or other naive ways of evaluating a token model can lead builders astray.

If you assume other token models function correctly when they don’t, you can create a broken token model. If you repurpose a token model with a different objective, you can implicitly inherit assumptions that don’t make sense for your token model.

#3 Articulate your assumptions

Be explicit about articulating your assumptions. It’s easy to take basic assumptions for granted when you are focused on building a token. It’s also easy to incorrectly articulate the assumptions you’re really making.

Let’s take the example of a new protocol that assumes that its hardware bottleneck is compute speed. Using that assumption as part of the token model — by bounding the hardware cost required to participate in the protocol, for instance — could help align the design to the desired behavior.

But if the protocol and token designers don’t state their assumptions — or are wrong in their stated assumptions — then it’s possible that participants who realize that mismatch will be able to extract value from the protocol. A “hacker” is often someone who simply understands a system better than the people who built it in the first place.

Articulating your assumptions makes it simpler to understand your token design and ensure it works properly. Without articulating your assumptions, you also can’t validate your assumptions…

#4 Validate your assumptions

As the popular saying goes, “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” [Often attributed to Mark Twain and others, this quote evolved incrementally over time.]

Token models often make a set of assumptions. This approach comes in part from the history of Byzantine system design as an inspiration for blockchains. The system makes an assumption and builds a function where, if the assumption is true, some output is guaranteed. For example: Bitcoin guarantees liveness in the synchronous network model, and consistency if 51% of hashpower in the network is honest. Several smaller blockchains have been 51%-attacked, violating the honest majority assumption Nakamoto consensus requires for a blockchain to function correctly.

Token designers can validate their assumptions in a variety of ways. Rigorous statistical modeling, often in the form of an agent-based model, can help test those assumptions. Assumptions about human behavior can also often be validated through talking with users, and better yet, by observing what people actually do (vs. say they do). This is possible especially through incentivized testnets that generate empirical results in a sandbox environment.

Formal verification or intensive audits will also help ensure that a codebase acts as intended.

#5 Define clear abstraction barriers

An “abstraction barrier” is an interface between different levels of a system or protocol. It is used to separate the different components of a system, allowing each component to be designed, implemented, and modified independently. Clear abstraction barriers are useful in all fields of engineering and especially software design, but are even more a requirement for decentralized development and large teams building complex systems that a single person can’t grok.

In token design, the goal of clear abstraction barriers is to minimize complexity. Reducing the (inter)dependencies between different components of a token model results in cleaner code, fewer bugs, and better token design.

Here’s an example: Many blockchains are built by large engineering teams. One team might make an assumption about the cost of hardware over time, and use that to determine how many miners contribute hardware to the blockchain for a given token price. If another team relies on token price as a parameter, but isn’t aware of the first team’s assumptions about hardware cost, they could easily make conflicting assumptions.

At the application layer, clear abstraction barriers are essential for enabling composability. The ability to adapt, build on top of, extend, and remix will only grow more important as more protocols compose with each other. Greater composition leads to greater possibility but also greater complexity. When applications want to compose, they have to understand the details of the protocol they compose with.

Opaque assumptions and interfaces have occasionally led to obscure bugs, particularly in early DeFi protocols. Murky abstraction barriers also extend development times by increasing the required communication between teams working on different components of the protocol. Murky abstraction barriers also increase the complexity of the protocol overall, making it difficult for any single person to fully understand the mechanism.

By creating clear abstraction barriers, token designers are making it easier to anticipate how specific changes will affect each part of the token design. Clear abstraction barriers also make it easier to extend one’s token or protocol, and to create a more inclusive and expansive community of builders.

#6 Reduce dependence on exogenous parameters

Exogenous parameters that are not inherent to the system, but that affect overall performance and success — such as the cost, throughput, or latency of a computing resource — are often used in the creation of token models.

Dangerously, unexpected behavior can arise when a token model only functions while a parameter remains in a limited range. For example, consider a protocol that sells a service and provides a rebate in the form of a fixed token reward: If the price of the token is unexpectedly high, the value of the token reward could be greater than the cost of the service. In this case it’s profitable to purchase an infinite amount of service from the protocol, leading to either the reward being exhausted or the service being fully utilized.

Or to take another example: Decentralized networks are often reliant on cryptographic or computational puzzles that are very hard, but not impossible, to solve. The difficulty of these puzzles is generally dependent on an exogenous variable — like how fast a computer can compute a hash function or a zero knowledge proof. Imagine a protocol that makes an assumption about how fast it’s possible to compute a given hash function and pays out token rewards accordingly. If someone invents a new way to compute that hash function more quickly, or simply has outsized resources to throw at the problem disproportionate to their actual work in the system, they can earn an unexpectedly large token reward.

#7 Re-validates assumptions

Designing a token should be approached like designing an adversarial system. Assume Byzantine behavior. Users’ behavior will change with changes to how the token works.

A common mistake is to adjust one’s token model without ensuring that arbitrary user behavior still results in an acceptable outcome. Do not assume user behavior will remain constant for variations in your token model. Usually this mistake happens late in the design process: Someone has spent a lot of time defining the objectives for the token, defining its function, and validating to ensure it works as intended. They then identify an edge case and shift the token design to accommodate for it… but forget to re-validate the overall token model. By fixing one edge case, they created another (or several other) unintended consequences.

Don’t let the hard work be for naught: Anytime a project changes its token model, re-validate that it works as intended.

If you find a better way to design tokens or like to think creatively and solve problems, I’d like to talk with you.

A big thank you to Scott Kominers, Tim Roughgarden, Sam Ragsdale, Ali Yahya, Eddy Lazzarin, Elena Burger, Carra Wu, Michael Blau, and especially to Sonal Chokshi and Stephanie Zinn for their feedback on this piece.

Editors: Sonal Chokshi & Steph Zinn

—

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

Read more: https://a16zcrypto.com/content/article/designing-tokens-sanity-checks-principles-guidance/