Table of contents
Here, we present carefully selected case studies of tokens which we think illustrate principled patterns for understanding what economics practiced as a branch of wisdom might look like. We do not intend to be exhaustive, and this is certainly not financial advice. Our goal here is to illustrate inventive designs and to try and tease out what aspects of them are virtuous so that we may improve our own ability to craft prosocial incentive structures.
Economies of Flow¶Remember that we began this overall section of the website with the claim that:
It is the feedback loop that is complex, not the token itself.
This implies that any meaningful token design will necessarily be contextual, because different communities and their differing goals will produce feedback that makes some designs virtuous in one instance and manipulative in another. It is therefore 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:
The non-exhaustive list Matt lays out for this kind of work includes gathering wisdom about:
- Existing market dynamics
- How to credibly describe a future industry sector (for example: who planned out 3G before anyone bid for the spectrum?)
- The theory of protocol design: what allows for attributes like growth, interoperability, and permissionless innovation?
- The practicalities of protocol design: how to be simple, readable, adaptable
- Contract engineering with subject-matter expertise: to consider how to build the reference implementation
- Operations and fundraising: to consider how to run and scale the reference implementation
- 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
- Lobbying: how to write policy whitepapers and get them discussed by the right people
- A convening function: from facilitating to goal-setting
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 steadily and calmly at the situation and seen it whole. 'Stop, look, and listen' is a better motto than 'Look it up in the model'."