HomeBuildToken Case Studies

    Table of contents

    • Token Case Studies
    Token Case Studies

    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, and perhaps the most useful, 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.

    Economies of Flow

    Any meaningful token design will necessarily be contextual, and so it is not possible to provide a set method by which to proceed. However, we can give you one piece of specific guidance when thinking about token design: be economic. By this we mean both that you need to specify exactly how value flows; and that you need to write it in as few lines, and as simple a manner, as possible. Here is the general program we try to follow in our own work:


    Ask "Why?" five times. Why am I really interested in working on this problem? Why is it a problem? For whom is it a problem and why does that matter to me?


    Having established why you are motivated to work on this problem, specify the exact incentive structure you think is broken. Write down why it doesn't work. Identify as many specific features as possible.


    Write down how you think it can be solved. Let the words sit. Come back tomorrow and edit it for simplicity. Do this as many times as it takes to get to three sentences or less. If you don't like words, draw a picture and follow the same process until it is maximally simple. Often doing both together can help. The core idea is not to use complicated software you have to learn about, because that clouds your thought and takes up valuable resources. Just reach for what is closest and use that. Napkins are a hundred times better than models at this stage. They have the added benefit of being easy to throw away, and they don't give you false confidence.


    Explain it to your friends in person or on a video call (preferrably with cameras on). Have them critique it fully. Do this repeatedly for as long as you can, ideally throughout the whole process.


    Make a spreadsheet in Excel or some other simple program you feel comfortable with to illustrate the shape you want your solution to have. This is often complemented by creating a "skeleton contract" which only has the names of the functions you think you'll need (no logic yet!). Again, let these sit, come back to them tomorrow, edit for simplicty and clarity. Show them to your friends, get more critique and questions.


    Write the questions you are asked down and use them to build a FAQ page over time. Re-read the FAQ page every ~two weeks and edit it for clarity.


    Ask yourself if there is anything you can take out of the contract such that those who use it have more freedom to choose how to do so while remaining within your overall shape and structure. Do this repeatedly.


    Find a friend and write the proper logic you need, all the while trying to reduce the number of functions required to a bare minimum. There are many different approaches to this phase of actual software development, so use the one closest to you: TDD often works best for us.


    Once written, talk to as many people as you can and show them your work. Trust us, if you are building prosocial protocols, no-one will "steal" it because your work will be properly contextual. Having more eyes and perspectives can only help. Moreover, if you really are intent on creating prosocial incentive structures, it should not matter who deploys a given solution, so long as people truly benefit from using it.

    If you are able to follow this process, you will likely also get great inspiration from:

    Protocol Fiction For Speculative Infrastructure

    The non-exhaustive list Matt lays out for this kind of work includes gathering wisdom about:

    1. Existing market dynamics
    2. How to credibly describe a future industry sector (for example: who planned out 3G before anyone bid for the spectrum?)
    3. The theory of protocol design: what allows for attributes like growth, interoperability, and permissionless innovation?
    4. The practicalities of protocol design: how to be simple, readable, adaptable
    5. Contract engineering with subject-matter expertise: to consider how to build the reference implementation
    6. Operations and fundraising: to consider how to run and scale the reference implementation
    7. Storytelling: visualising the future and how we get there. Vital for alignment and enrolling support, but also (the vital work of design fiction) to test, in thought experiment form, against unintended consequences
    8. Lobbying: how to write policy whitepapers and get them discussed by the right people
    9. A convening function: from facilitating to goal-setting
    See It Whole

    There are other places online to learn about how to model different kinds of tokens. Implicit in the very structure of such teaching and work is the idea that models have predictive power. We'd like to question this assumption when it is applied to tokens. Models may be useful for discovery and exploration. They are very, very rarely proof or evidence of something that will happen. We go into more detail about this claim here, but we're not alone in thinking this way. E. F. Schumacher in an essay entitled A Machine to Foretell the Future? puts it thus:

    "If I hold a rather negative opinion about the usefulness of 'automation' in matters of economic forecasting and the like, I do not underestimate the value of electronic computers and similar apparatus for other tasks, like solving mathematical problems or programming production runs. These latter tasks belong to the exact sciences or their applications. Their subject matter is non-human, or perhaps I should say, sub-human. Their very exactitude is a sign of the absence of human freedom, the absence of choice, responsibility and dignity [...] Great damage to human dignity has resulted from the misguided attempt of the social sciences to adopt and imitate the methods of the natural sciences. Economics, and even more so applied economics, is not an exact science; it is in fact, or ought to be, something much greater: a branch of wisdom."

    We will attempt to proceed with our studies by placing human freedom and dignity and the very forefront of our work, so that we can study different designs and discover together what in them in wise, and what is misguided. Rather than teaching you how to model imaginary projections, we will set out various actual case studies and encourage open discussion, so that we might ask "Why?" enough times to understand deeply what incentive structures we live within are really broken, and how it might be possible to create alternatives with the appropriate humility and perspective. As Schumacher says:

    "The best decisions will still be based on the judgments of mature non-electronic brains possessed by humans who have looked stedily and calmly at the situation and seen it whole. 'Stop, look, and listen' is a better motto than 'Look it up in the model'."

    Ocean Curves
    Free Learn