One critical aspect of token design is to ensure that any token you create is intrinsically required for the protocol to function as expected.

The classic example of this is Maker. The system requires humans to make decisions on what kinds of collateral to accept, how much of it to accept, at what rate(s) to do so, as well as what the overall “interest rate” (or DAI Stability Rate) is at any given time. MKR holders vote regularly on these parameters.

If you–as an MKR holder–vote well, the system flourishes, extra DAI accrues and is used to buy back and burn MKR, which is good for you. If you make poor choices, there is a chance that the system becomes undercollateralized, at which point it prints MKR and sells it to pay down the debt, which means your holdings are diluted. This means that the intrinsically critical role MKR plays is as the “lender of last resort”.

All these financial terms might make it seem like the only way to weave your token and protocol together is through deep financial engineering. However, this is not necessarily true. Let’s look at the decentralised ETH staking service, Rocket Pool, as a good example of a token which is required for the protocol to work as expected without resorting to overly complex financial gymnastics.

To become an Ethereum 2.0 validator, you need to stake 32 ETH, which is out of reach for a lot of people. Therefore, many projects have emerged that enable people to participate in the upside of securing our shared network without needing to put down so much money initially. Rocket Pool–for reasons largely centred on their multiparty compute (MPC) setup–is likely the most interesting and values-aligned example of such projects.

Rocket Pool enables you, someone with less than 32 ETH, to participate in the upside of validating Ethereum 2.0 in two different ways. Firstly, you can simply stake your ETH with them and receive rETH in return. This rETH represents the performance of the Rocket Pool protocol. As everyone running validators as a part of the protocol earns rewards, the value of rETH increases, which is good for you.

Who runs validators? This is the second way to participate, because anyone who has at least 8 ETH can run a Rocket Pool node.

The flow is simple: cut the amount required to run a validator, then ensure that you match the ETH anyone puts up personally with ETH from the shared pool of those who have staked small amounts of ETH in order to hold rETH. This gets us up to 32 ETH required by Ethereum 2.0 and we can run a node. Node operators receive all the rewards for their staked ETH, and a small percentage of the rewards from the protocol-provided share.

Of course, that is only half the story, because Ethereum 2.0 validators can be slashed for various reasons. So, how does the protocol insure itself against any potential losses, which would be reflected in the value of rETH?

Enter RPL, the Rocket Pool token. If I want to become a Rocket Pool node operator, I also need to stake RPL tokens equal in value to at least 10% (and at most 150%) of the initial value of my ETH stake. These act as insurance in the case my validator gets slashed and they determine the amount of rewards I earn from the protocol for running a node (the more I stake, the higher my portion of RPL rewards).

These rewards are paid out in addition to the direct revenue I receive in ETH for running a validator. How are they generated? Protocol inflation. The RPL token is inflated automatically by 5% per year. 70% of that 5% inflation is allocated to node operators. 15% of it is allocated to the “Protocol DAO” who are responsible for development and maintenance of the software and services, and 15% of it is allocated to the “OrcaleDAO” who provide information on validator balances and the RPL:ETH ratio.

These percentages are subject to change, and there is active debate about whether OracleDAO members deserve 15%. It’s likely we’ll see that change in the short term, which will happen through a ProtocolDAO vote determined by RPL tokens (as they also represent governance power).

This is what it all looks like mapped out visually:

The final point is a fascinating one if you really reflect on it. My own experience at Status here is instructive to share. We ran one of the early ICOs and went from a community of 200 highly technical, very values-aligned people hacking Ethereum light clients onto any resource-restricted device we could get our hands on to a slack group of 20,000 people in 3 days. Almost immediately, we tried to split the "token and trading talk" into its own channel and effectively began ostracizing the people interested in that stuff because it somehow sullied our pure and noble technical motivations for starting the project.

This was an enormous mistake, brought about largely by the fact that SNT had very limited utility at launch and certainly was not intrinsically required for the operation of the mobile app we had launched. Instead, what you see in communities like Maker and Rocket Pool is people interested in trading and financial engineering having generative, wholesome, and interesting discussions with those more focused on the engineering challenges of MPC at scale, or creating node software for retail users, or any of the other highly technical topics Rocket Pool has made great progress on.

This cannot be overstated, because it is the epitome of a positive feedback loop in social space. You do not want to separate your community into those talking about the price and those "doing the real work" or however you phrase it. If those two groups are distinct, it is generally a sign that you have a badly designed token which is not intrinsically useful in your shared protocol(s) and so is only useful for the purposes of extractive speculation.

If the people crafting the software and those creating the markets are totally distinct, you cannot play infinite games with one another.