Wrapping up our series on the Design Phase, we discuss considerations when designing specific incentives in your network.
By Geoff LeFevre
In previous posts, we discussed the importance of stakeholder mapping and creating a taxonomy of actors, and setting your network’s objective function. These steps set a strong macro foundation for starting to build out specific incentives across your network, but now the focus turns to the microeconomics of specific roles within your network.
More and more networks are emerging with increasingly complex sets of participants, network roles, and incentive mechanisms. As we have pointed out in a previous post Analysing Incentives for Arbitrage and Market Maker Keepers in MakerDAO, designing incentives needs to be approached role by role to ensure that key network roles are properly incentivised. As networks start to compete for adoption, a key indicator of success will be how well the incentives on the network can overcome initial switching costs and bootstrap user adoption and traction.
But how can you ensure that your token design and incentive structures can overcome these initial switching costs? Being able to build a business case not just for a network as a whole, but for specific roles within the network is key. In our post on Arbitrage and Market Maker Keepers in MakerDao we built a static business case showing simulated returns for these keepers over a fixed time window. The objective of any incentive design should be to build up to a business case for specific roles within the network. This exercise is useful for comparative analysis between other networks and can help a designer create attractive opportunities for potential network participants. Building these static business cases can ensure roles are initially attractive and help drive early adoption. But what about long term traction?
In reality, these business cases are very dynamic with multi-agent interactions and continuous games being played. For example, as discussed in Philip Daian’s paper Flash Boys 2.0, arbitrage agents compete in gas auctions in a front-running competition with other agents to get their transactions executed first. Other complex behaviours have emerged such as arbitrage agents arbitraging the cost of gas over time to help fund their gas auctions to front-run their pure token arbitrage transactions. The point is that as these networks are launched, incentive economics will evolve as more complex behaviours emerge, some good and some bad. To understand these emergent and sometimes unplanned behaviours, game theory, mechanism design and behavioural economics are particularly useful tools.
Game theory is the study of multi-person decision problems and a crucial tool in the token design process since it helps us determine the outcomes from strategic interaction of players given their preferences and incentives. Unlike decision theory that is concerned with the individual’s own preferences and constraints, game theory is about interactive decisions and shows us how players can make decisions in competitive and/or cooperative environments.
In our MakerDao Keeper example, Game Theory can be used to model out these business cases in terms of multi-agent games to determine potential equilibrium gas prices and revenue.
Mechanism Design is the art of designing the rules of a game to achieve a specific desired outcome. While game theory takes the rules of the game as given and helps us determine outcomes based on them and the strategic interaction of players, mechanism design uses the framework of game theory with incomplete information and asks about the consequences of different rules and chooses the game structure rather than inheriting one. Therefore, in our context, mechanism design allows us to look at the overall design of the network and participants’ incentives as a way to influence the outcomes of the network game in addition to determining the optimal design of the network itself.
For our MakerDai Keeper example, Mechanism Design is very helpful lens to analyse Ethereum’s gas model (auction mechanism) and can help identify potential solutions to the risk presented by front-running.
Behavioural economics studies economic questions while incorporating learnings from psychology, and experimental economics. Psychological findings have shown us that human beings have limited cognitive abilities, lack motivation and self-control. Additionally, their preferences, choices and behaviour maybe non-standard, meaning human beings may not always behave efficiently, and in fact, their behaviour may change based on a reference point, as well as the context they are in. This means that the way the token’s functionality is presented to participants is perhaps equally important as the actual mechanisms themselves.
For our MakerDao example, Behavioural Economics is a useful lens to uncover the preferences of individual Keepers operating on the network. Keepers are autonomous, but their actions are pre-coded by developers and are representative of the developer’s unique set of preferences. Although the source code can be hard to obtain, analysing a set of Keepers behaviour over-time can help uncover the range of preferences present on the network, and can help design more targeted mechanisms.
As mentioned before, incentives aim to induce network participants to act in a particular way in an economic or business setting and hence play a crucial role in any economic or contractual relationship. In a setting where participants in the network have differing goals and possess varying degrees of knowledge, optimal allocation of resources and mutual gains are only attainable with the right design of incentive mechanisms.
One should denote that, participants can partake in the token ecosystem either via interacting with each other at the market layer or by becoming nodes to sustain the ledger layer, or both. Relying on correct assumptions about the possible types and designing the right incentives matter at both those layers. Accordingly, it is important to remember the rationality level of different types of participants in the network can vary greatly (for example, rationality of AI versus different types of individuals may differ significantly) and its effects on the ecosystem should be tested or simulated.
DESIGNING FOR ATTACK VECTORS
Token models are dynamic complex systems that produce unpredictable (stochastic) and predictable (deterministic) outcomes. The issue is that many of the (Nash) equilibria determined in the design phase using the economic lenses described above are simply proofs of existence and in practice, this does not mean that a particular state will actually be the outcome in real life.
What is important to flag is the set of possibilities within any given model, not the likely equilibrium. By knowing what is possible, as opposed to focusing on what is likely, the token architect can then eliminate the possibility of certain behaviours, and limit the action space. By knowing the set of all possible actions, also known as the action space, the designer can then focus on incentive engineering efforts only towards those states which are possible.
This general approach of incentive design can also be a very useful lens for designing consensus mechanisms and token distribution strategies. For consensus mechanisms knowing the business case for a miner, and how miners compete for rewards over time can help uncover potential attack vectors leading to better incentive structures that support efficient network operations. Similarly for token distributions, knowing the preferences of potential token purchasers (something that is easier said than done!) can be instrumental in developing a distribution strategy that gets tokens into the hands of the right people.
As a closing thought, it is important to build up from simple incentives to more complex incentive structures only after observing real network behaviours. In the case of MakerDao, Keepers were first managed by the MakerDao team internally. It was only relatively recently when sample codebases for Keeper roles were made open source, and the number and variations of Keepers within specific roles exploded. Since then Keeper behaviour has become much more complex but has also made the system more robust. Complexity naturally emerges from simple states so keep it simple initially. It is important to design incentives that already exist. You can’t force behaviours but you can incentivise them.
To learn more about our phased strategic process for token ecosystem creation, please download the full report.