Earn Model
How new RAIR is created
Last updated
How new RAIR is created
Last updated
The goal of RAIRprotocol is to distribute majority ownership of RAIRprotocol to developers contributing to furthering our open source. This happens via a task-based emissions model.
As explained in the onboarding section, developers earn off-chain points by submitting issues and merging code to our official repositories. Event listening logic is employed to keep track of developer activities, and reward their wallets tied to their developer accounts.
Below is a list of initial state value accretive activities to the network. New tasks can be proposed or existing tasks removed for modified by DAO members at at time via a vote + a grace period to allow for smooth transition.
Task Creation: This is the process of assiging a new points generating activity to the system. After initial set of tasks are voted in by the DAO, new tasks are subject to DAO approval.
Task Removal: This is the process of removing a task as a valid points generating activity. This can be to prevent abuse in the system, or to sunset tasks no longer valuable to the network. Removal process is subject to a grace period to ensure tasks mid completion will continue to receive rewards.
Abstracted Points: This is the process of assigning a difficulty level to each task. Abstracting the raw point value from each task prevents abuse potentially from a fully published points algorithm, but still gives the community insight into the approximate reward for completing the task.
Maximum Actions per User: Each task as a cap on the amount of activities that will generate points. This prevents primarily automation abuse for tasks that are more linear in nature. E.g. points for adding references and past experience to user profiles, etc.
Maximum Users per Task: This sets the maximum team size for a given task. Some tasks in the system are very large (E.g. integrate a non EVM network) and likely require multiple developers working together to accomplish. All developers working in teams (included in the issues and pull requests) receive a porportional share of rewards)
Point values are at the discretion of the RAIRprotocol DAO and are kept hidden inside of the official incentive dApp database.
Below is a guide for our difficulty tiering system 1-5 from extremely easy to extremely difficult.
| Difficulty | Points Range | Time | Criteria |
|---|---|---|---|
Extremely Easy (1) | 50-250 | Seconds | No coding experience, simple tasks. Complete profile, like, subscribe, etc. |
Easy (2) | 250-1000 | Minutes | Basic Github interactions (no coding) Comments and issue creation |
Medium (3) | 1000-5000 | Hours | Mainline coding tasks (scripting, bug reporting, deployments, etc) |
Difficult (4) | 5000-25000 | Days | Requires code review and merging PRs |
Extremely Difficult (5) | 25000-150,000 | Weeks | Code review + major platform level enhancements |
Point accumulated convert into levels in the incentive dApp. To prevent the publishing of the complete points algorithm, level formula is also at the discretion of the DAO. Unlike the points system, the leveling system is fixed and cannot change to ensure fairness in the distribution of developer incentives.
Below is a guide for how the leveling system is implemented internally. Levels may be assigned at new interval between these values.
| Levels | Points Range (per level) |
|---|---|
1-10 | 500-2000 |
11-50 | 1000-5000 |
50-99 | 2500-15000 |
100+ | 15000+ |
All developers in the incentive system are force ranked 1 through the Nth user.
Each 20% cohort is seperated into their respective tiers 1 through 5. Rewards are distributed exponentially to encourage top developers to compete for high position in the rankings.
Points are initially rewarded offchain and can be claimed for ERC20 Fungible RAIR tokens at TGE. Post TGE the same points to token conversion process applies.
There is an offchain holding period after receiving points that can be colloquially referred to as "staking". The are 4 default staking period that may be updated per the discretion of the DAO.
| Holding Period (Days) | Rate | Effect |
|---|---|---|
0 | .5 | 50% tax on immediate liqudity |
90 | 1 | Holding period to receive full reward |
180 | 1.25 | 25% incentive for lockup |
365 | 1.5 | 50% incentive for lockup |
Beyond 365 there is no additional staking rewards. Rewards are designed as cliffs. E.g. hold 179 days does not equal 1.2455 reward. Equals 1.
Incentive period is designed to last until the entire 1.8b maximum supply is reached at which point the system must be self sustaining without an incentive reward.
TGE will be triggered once a threshold number of qualified developers join the network. DAO to determine qualiifcations (minimum level and number of devs required to trigger the TGE countdown timer.
Once the countdown timer is triggered, TGE will initiate 45-90 days from the trigger date per the discretion of the DAO.
Upon TGE the earn model will continue to function in the same manner as the initial points generation period but under a new epoch.
All current developers in the system will compete to rank highest in any given epoch (or rewards period). At the end of Epoch 0 (the points campaign prior to TGE) all rewards will be distributed and the developers levels will be reset to Level 1.
This ensures new developers entering the ecosystem have a fair shot at receiving maximum rewards for any given epoch.
Total rewards up for distribution to be determined by the DAO prior to the start of a new epoch. Each new epoch is triggered by the total number of qualified new developer signups.
Below is a guide for ranges to trigger each subsequent epoch and approximate rewards. Rewards from each subsequent epoch must be less than the previous epoch. Qualified new developers from each new epoch must be greater than the subsequent epoch.
| Epoch | Qualified Developers | Rewards (RAIR) |
|---|---|---|
0 | 21000 | 50m |
1 | 22000-32000 | 25m-50m |
2 | 32000-50000 | 10-25m |
3 | 50000-100000 | 5m-10m |
