🥕
Token incentives
TLDR: Protocols distribute their native governance tokens to both the supply-side and demand-side of the protocol. We account only for tokens that are claimed by end users.
In traditional companies, Uber could have incentivized its early users (drivers and riders) with their early Uber stock and/or by paying dollars for each ride. In practice, token incentives are extra rewards that are being paid for the core usage of the protocol, many times focusing on the supply-side participants of the protocol.
Depending on the protocol, different business-related actions can be incentivized:
- 1.Uniswap: doesn’t pay token incentives
- 2.Compound: pays token incentives to the lenders and the borrowers
- 3.SushiSwap: pays token incentives to the liquidity providers
The following recommendations aim to make our definition of token incentives as comparable across projects as possible:
- Exclude all airdrops
- Include all native token distribution programs (e.g. staking rewards)
- Prioritize tracking claimed tokens. Note that in select cases (when the project’s smart contract architecture does not make this possible) we may have to track distributed tokens (see “Onchain tracking considerations”, below)
The figure below shows a contract X that sends tokens to a token distributor contract Y which then sends tokens to each user eligible for token incentives.
There are two main ways we use to track token incentives:
- Using events: most likely preferred, but not always available.
- Tracking transactions to/from the contracts involved: doable, but may require filtering out transactions that are not related to token incentives
You might then ask: should I track the movement of tokens from X→Y or from Y→users? Here are some aspects to take into consideration when we choose either of the approaches.
🔴 Some of the tokens transferred to Y may actually never be distributed to users (e.g. because the users did not claim them for any reason).
🟡 Related to the point above: could there be mechanisms by which governance decides to actually not distribute some of the tokens already in Y (and therefore, already counted as incentives)? If so, we may end up counting tokens as incentives that end up not being distributed.
🟢 If the majority of tokens end up being claimed, this is an accurate metric and is time-insensitive (we don’t have to wait for all the claims to be done to get the most accurate value for the incentives).
🔴 We may get large spikes in the charts (e.g. if X transfers a huge amount of tokens to Y in a single day, which are then distributed across a period of time).
🟡 Depending on the smart contract architecture, this may not be available/hard to track.
🟢 These are realised distributions. The tokens have been irreversibly distributed. We will never track tokens as incentives that end up not being distributed.
🔴 If users are “slow” to claim their tokens (e.g. due to gas costs), the incentives figure may be smaller compared to the expected amount of tokens that will be distributed, so our token distribution numbers may differ from the theoretical distribution schedule (in project’s docs).
🟡 Depending on the smart contract architecture, this may not be available/hard to track.
Last modified 5mo ago