StartLearnBuildTokensResourcesConverseBlogLibrary

    Table of contents

    • Teaching Tokens
    Teaching Tokens

    Simplicity is worth more
    than any token amount
    you might magic out of
    an imaginary ability
    to model reality.

    Tokens can be tricky to understand because the way people use them influences how useful they are. We call this a "feedback loop". Designing a token is not only a computer science or economic endeavour. It also includes psychology, sociology, cultural anthropology, literature, and advertising. All that said: you don't need be an expert to start playing with token designs today. Indeed, no-one can be an expert in all these diverse fields at once. What matters most - much like the gift - is that you are aware of the scope of the fields in which you're playing. Most importantly:

    It is the feedback loop that is complex, not the token itself.

    This is the first litmus test we can offer you. Understanding how a token works in terms of the code which creates and directs it ought to be possible in a few hours of dedicated study. If this is not the case, it is likely that the designers either (i) don't fully understand their own work, (ii) are trying to appear more intelligent than they are, or (iii) are purposefully trying to hide something.

    Moreover, if a token designer tells you what the effect of deploying a token in the world will be, and assures that you that they "know" how and why it will unfold as they predict, you can also be sure that they have not fully understood the domain in which they are working. This is not a slight on anyone's intelligence. Feedback loops create "complex systems", whose behavior is intrinsically difficult to model due to the dependencies and relationships between their parts, and between the system and its environment.

    💡 Tokens are economic code which create psycho-social cultural systems that both depend upon and create narratives of use.

    With that established, we can begin this section with an exploration of what not to do when designing tokens. This via negativa approach is one we commonly employ in Kernel when beginning to learn about a new and potentially complex domain.

    The Cost Of Decisions

    Using assets to govern others merges the worst of capitalism with tyranny.

    The above is true when you do not need to spend your asset to exercise governance rights. Taking snapshots or tallies literally dissociates meaningful speech from the movement of economic value which is the primary mechanism by which blockchains might serve as (pro)social media.

    Kernel's position is premised on economic code running consensus. It's radical: forget quora, participation, and all the other “nice” social outcomes people are trying to design for with ill-conceived tools that disassemble a potentially prosocial aspect of blockchains by allowing you to vote without spending your tokens. If you insist on programming your token to be an asset given the psychological pull this exerts over most people, then this is our advice:

    Any governance proposal must specify the budget needed to fulfill itself. No quorum is necessary: all that is required to begin work is enough “votes”, in the form of valuable tokens, actually being sent to the proposal in order to fund work.

    This is the promise of decentralized organisation: we don't need a single person or group to decide what we work on. We work on whatever we can fund, and we craft the incentive structures such that those with the perspective and/or experience and/or skills to do the work tend to accrue the funds to direct ongoing work in a transparent fashion.

    The cost to make a decision must be directed to those responsible for enacting the decision. This is the best way to align incentives in any organisation over the long term.

    If governing the system requires spending tokens, then governance becomes the kind of token sink required to ensure equitable wealth distribution in the long term. Requiring that tokens literally fund decisions creates a profound feedback loop: value accrues (or dissipates) as an effect of what we collectively choose to spend our tokens on.

    Proposals are not about permission and so governance must be the literal means by which distribution of funds happens, rather than funds flowing after a decision has been taken.

    Well-funded development of mutually helpful software is the outcome; governance is the means by which tokens are distributed by anyone who owns them to signal their support meaningfully. This doesn't preclude innovative bootstrapping programmes like quadratic matching from shared funding pools or communal treasuries, but it does bind economic value to meaningful speech, which is the primary manner in which we can make more (literally) effective collective decisions.

    Defender's advantage and thinking in terms of penalties is critical. However, this way of costing decisions illuminates how well-designed tokens take what is superficially a “penalty” - i.e. spending your money to support a proposal you think is significant - and turn it into the very (rewarding) act which ensures that the tokens you retain become more valuable.

    The penalty is the reward when we build governance systems that distribute funds by virtue of how they work, rather than as the outcome of their work.

    Won't people with the most tokens get to dictate work?

    If we create more prosocial and less tyrannical forms of governance, tokens are valuable to the extent that they are used fund mutually beneficial work (so, if you have a lot of tokens, you're incentivized to spend a majority funding others - consider Joe Lubin and Consensys in the early days of Ethereum). Also, you can program your incentives any way you like (consider dap.ps, which explicitly makes it cheaper to vote on projects that have more initial resources).

    How does any token get its initial value?

    By being brought to life by and in a community whose members already trust each other to transact with it, and by employing quadratic fund matching (and other methods) from shared communal treasuries, if possible.

    References

    As always, we recommend you read more of Vitalik's blog if this is a topic you want to understand further.

    Votes as buy orders

    Prices

    Moving beyond coin voting governance

    Next
    Case Studies