Token Supply Overview

Whiteboard Session

Token Supply Overview

`m` for measurement. This is the red line and it represents the raw (positive) of the KPI.

`k` is the cumulative sum. It is purple and represents the positive monotonic (going up) cumulative sum of the KPI over time.

`f` is an intuition of a measure of value (measuring)

`g` enforces a limiting factor and is derived from the property being enforced (`g` is not fixed, dependent on what is being limited) (minting)

`allocation` is the distribution policy (harvest). This is up to the community, but if `f` and `g` are right this is fine because we already figured out how many tokens to mint (the hard part)

Note: `p` is not price, it is a mapping between signals


Token Supply Overview

Coming soon!

How much do we mint and how often?

Goal: make tokens represent the value created by the community.

The process of minting tokens is arguably the most important part of the system. Mint too much and inflation kills the market. Mint too little and people aren't incentivized to contribute. How do we figure this out?

If the goal is for tokens to be representative of the value created by the community, then the cumulative sum of all tokens minted needs to represent the cumulative amount of value created by the community.


TL;DR: Real-world process of noisy signals β‡’ processing β‡’ number go up.

The goal of AraCred is to recognize and reward contributions. What is valuable will be different for each project. As such we need a system that generally tracks engagement and activity, but also allows the community to decide what is the most important to them.

More concretely this looks like creating metrics for all of the complex things that humans do. These metrics can then be combined to create a cumulative KPI that represents "value," as it's defined by that community. This reduces the "what is value" problem into a "number go up" problem. As the thing we care about goes up, we can then mint tokens proportionately.

While it would be great if this was simple, it is not. It requires clearly stating an objective and knowing what you want to have happen. This is often the hardest part. The world, or at least your slice of it, needs to want the "value KPI" to be high otherwise the token isn't going to be valuable.

If you construct this correctly:

  • The KPI should represent what the community views as valuable.
  • The token should be directly connected to that KPI.
  • The policy should enforce the relationship of the token supply to the KPI so that when value creation goes up, the KPI goes up, and more tokens are minted.

A few words of warning:

  • If F is gamable and/or M is not valuable, then the token will not be super valuable.
  • The "spirit of F" is essential. This way you'll be able to clearly recognize an exploit vs the game itself. This way you'll know if you need to adjust the game, or if there's a bad actor that needs to be adjusted.
  • It's essential that you can change the system if/when someone figures out how to game it or if/when what the community views as valuable changes.

So... how do we actually do this? Well first, we need to start to figure out what we consider to be "valuable." What signals do we want to drive the token minting policy?

  • new users?
  • money in the DAO?
  • SourceCred activity?
  • etc...

Note: you can use a single signal for your "value KPI" or you can use a combination of signals. The important part here is that they represent the things that the community cares about. Once you determine what you think is valuable and why, then the challenge is using the best tools available to measure that value creation. We really like SourceCred for this task, however, there are many other tools you may want to use in this process.


How do we maintain a relationship between our measure of value and our continuous token supply?

The control problem (g) is where we actually mint tokens.

  1. f is a business problem (see linked video)
  2. g is a math problem
  3. allocation is a governance problem

This system isolates 1 from 3 via 2 (the minting policy). 1 and 3 can express subjective preferences, but 2 needs to be rooted in a solid cryptoeconomic policy.

We're solving a control theory problem. We want a policy that goes to 1 in the limit, but is not at 1 at any given time. This gives the system properties where it can be modeled as if the minting relates to the "value KPI," but doesn't quite... allowing it to oscillate around the "value KPI" in a way that makes it harder to game.

Minting is a statement about a limit.

  • You can get a mixture of flexibility and assertion through limiting properties.
  • Keeping the limiting factor as a limiting policy gives it the flexibility to oscillate around the real value, giving the system the ability to modulate as things change.
  • Limiting behavior gives the system more dynamic evolutionary properties that will allow it to adapt to real-world fluctuations.


How do we want to allocate tokens after we mint them? This is really up to each community. You could just give people their tokens, you could have a vesting schedule, or something else entirely.