This is a chapter from **Tokenomics for Builders: The Practitioner’s Guide to Token Design.*
This document and all resources, threads, models, and materials linked to within are for informational purposes only. None of this document’s contents, nor the contents linked to within, should be construed as legal advice, financial advice, technical advice, investment advice, accounting advice, or representations in any way regarding legal, technical, financial, investment, or accounting matters by the author. The author is not a lawyer or financial advisor in any jurisdiction, and highly encourages readers to engage with registered professionals to ensure compliance with any and all relevant laws and regulations.*
As discussed in Part One of this guide, tokenomics is a builder’s best tool for coordinating user behavior.
This is achieved through carefully balanced incentives - both rewarding desired behaviors and punishing undesired behaviors (or at least not inadvertently rewarding them). This sounds obvious at a high level, but the specifics of well-balanced incentives are highly nuanced and require not only a sound qualitative design but also the right quantitative parameters.
Even the slightest oversight or imbalance can change a sustainable equilibrium to a death spiral vulnerability.
For instance, it’s one thing to say “Miners should be rewarded”, but it’s another thing entirely to answer “This is how much miners should be rewarded”.
Coordinating user behavior comes down to answering these questions:
CoinMarketCap and CoinGecko are littered with failed projects whose builders fell into the trap of only answering these questions at a surface level due to laziness or hubris.
In complex systems, conflicting or misaligned incentives, and the exploit vectors they create, are hard to identify at first glance. Without explicitly thinking through the incentives in your tokenomics (and modeling them in later steps), you are blindly assuming your design will just happen to work out with no unexpected, emergent, or unintended user behaviors.
Every builders likes to think they know better. As the saying goes, pride comes before a fall.