Updates:
5-Feb-2021
- Update the description in accordance with the new ideas of implementation of the rewards claims
- Add automatic compounding of AURORA
- Combine multiple stakes into a single stake
30-Dec-2021
- add pictures to support the flow
29-Dec-2021
- add some features from discussions and user comments
- Rename farms into streams
TODO: finalise the weighting function and release times
This proposal is an in-depth description of the staking approach of the AURORA token that allows for the community treasury use-case previously voted by the Aurora DAO; implements the protection from the Sybil attacks and also some additional use cases. Though the major focus of the proposal is the staking mechanism, the main functionality of the community treasury platform is also described.
General thoughts about staking
AURORA is envisaged as a governance token through which the decentralized governance (voting) of the Aurora protocol should be implemented. To resist Sybil attacks (a token holder votes, transfers AURORA to another account and then votes again), a staking mechanism should be implemented. Through staking users are getting rewards and VOTE tokens.
VOTE tokens are ERC-20 in-transferrable tokens that are used to vote for the allocations of funds from community treasury through the community treasury platform (Jet). Besides this use case, aggregated historical info on the VOTE tokens accrual and usage should be available for the higher-level governance (see Further decentralisation of the governance: DAO council seats may be elected every year; the voting power of the user should be determined based on the year-long info on the earned and used VOTE tokens).
Staking is closely coupled with the logic of the Jet platform, which includes the notion of a Season. A season is a period during which projects can apply for the funding and users would vote for them, and, as a result, would distribute the allocated funding among these projects. Seasons support agile-style evolution of Jet functionality, but generally are not different from one another. The length of the season is 2 months, so there are 6 seasons per year. Each season has two major stages: application and voting, each lasting around a month (in between these stages there would be technical periods that would last days). During the application phase the developers / project teams may apply for the funding in this season; during the voting phase the AURORA token holders vote for the projects using VOTE tokens.
Besides the VOTE tokens, staking of AURORA is generating rewards to the users. Rewards are generated by streams that might be created by third parties, however, subjected to whitelisting. All the allocations of the streams are made pro-rata depending on the total weighted stake.
Locked AURORA (for example AURORA that should yet to be transferred to the private round investors) cannot be used for the staking.
Relying on the generic info about the governance tokens staking, we should anticipate that the staking contract would host around 30-50% of the circulating supply of AURORA, which would make this contract the most important contract in the Aurora ecosystem.
Functionality of the staking contract
1. Proxy / Upgradability
The staking contract should be manageable and with the highest probability it would be updated in the future. An admin for the contract should be an implicit account* of the Aurora DAO on Aurora.
*Every NEAR account has an implicit account in Aurora and is able to interact from NEAR runtime with Aurora runtime.
2. Pausability
Multiple accounts should be able to temporarily seize the execution of staking, including paying out rewards and usage of VOTE. This is required for the fast reaction to the threats. The admin should be able to manage the list of these accounts and unfreeze the staking contract.
3. Staking functionality
Users should be able to stake AURORA (deposit AURORA to the contract for some period of time).
During staking, the user gets rewards and VOTE tokens. Depending on the moment in time when the user staked AURORA, a weighting coefficient is applied to both rewards and the amount of VOTE tokens allocated.
Example:
| Season of stake | 0-2 | 3-4 | 5-6 | 7-12 | 13-18 | 19+ |
|---|---|---|---|---|---|---|
| Weighting coefficient | 1 | 0.9 | 0.8 | 0.7 | 0.6 | 0.5 |
Coefficients should be able to be set and updated by the Admin of the contract. It is expected that the coefficients will naturally decrease to some constant value.
The user is able to unstake AURORA at any time, however in such a case, the weighting coefficient is reapplied to the stream rewards for the whole AURORA stake.
Example: A user stakes 10 AURORA at season 2 from the example above. Their stake generates 100 TRI rewards during the season 20. If the user would unstake 10 AURORA and then immediately stake them during the season 20, their reward would be decreased to ~50 TRI. Unstaking 1 AURORA and staking it back would result in the same rewards change.
In case a user have AURORA staked and adds additional AURORA to the stake the weighting coefficient is applied only to the newly staked AURORA. Thus, staking additional AURORA to âoldâ accounts and ânewâ accounts results in the same rewards generated by this stake. This eliminates the secondary market of early AURORA stakers accounts.
It is expected that Aurora DAO might approve the default AURORA stream. In such a case, AURORA rewards would be compounded with staked AURORA (so thereâs no need to claim rewards and stake them back) and the weighting coefficient wonât be applied for the rewards through this stream. Thus weighting would be applied only to the rewards from the non-AURORA streams.
Unstaking transfers AURORA tokens in pending release stage. The duration of release time is configurable by the admin of the contract. After this time lapses, the unstaked AURORA can be withdrawn.
4. Claim functionality
A user should be able to claim VOTE tokens and rewards. The rewards may be generated by different streams (see next), so a user should specify the stream that he claims.
Claiming transfers stream rewards in pending release stage. The duration of release time is configurable by the admin of the contract and might be different for different streams. After this time lapses, the claimed rewards can be withdrawn.
Claimed VOTE tokens are released immediately.
5. Stream whitelisting
An admin of the staking contract can whitelist a stream. Whitelisting of the stream provides the option for the stream creator (presumably the issuing party of a specific token) to deposit some ERC-20 tokens on the staking contract and potentially get in return some AURORA tokens. Deposited ERC-20 tokens will be distributed to the stakers over some period of time. Here are the parameters of the whitelisting method:
- Amount of the AURORA deposited by the Admin. AURORA should be transferred through transferFrom method of the AURORA ERC-20
- Stream creator address â only this account would be able to create a stream
- Rewards token address â the address of the ERC-20 tokens to be deposited in the stream
- The upper amount of the tokens, that should be deposited by the stream creator. In case the creator deposits less than the specified amount, the amount of released AURORA is decreased proportionally. All the rest of AURORA is transferred back to the admin.
- Max block height, until which the option to create the stream is active
- Rewards schedule, specified as an array of tuples (block height, amount of reward tokens that is kept on the staking contract at this block height). This array specifies the piecewise-linear dependency of the decay of the reward in the stream.
Note: the release of AURORA tokens to the stream creator is subjected to the same schedule as rewards. Thus if for a specific moment in time 30% of the rewards are distributed, then it means that 30% of the AURORA deposit can be withdrawn by the stream creator too.
Important: the allowed mechanics of the streams might be useful for two use cases.
First, the investment from either the community treasury or the Aurora DAO directly. One of the KPIs of the project that has received the investment might be the deposit of the specified amount of project tokens to the staking contract once the tokens are issued / released.
Second, staking contract implements the native way of doing an airdrop to the Aurora community. Any project that would like to do an airdrop now is able to use the staking contract.
6. Creating the stream
This method is called by the stream creator (only once) and it realizes the option that was set up during the whitelisting phase.
7. Remove the stream
This method can be called only by the admin and cancels the reward allocations of the stream to the staking users and the distribution of the AURORA to stream creator. This is a blacklisting functionality that is intended to be used only in emergency situations. The remainder of the rewards tokens and AURORA should be able to be transferred by the admin to any Aurora account.
8. Management of the weighting function and release times
Weighting function and release times should be updatable by the admin of the contract.
9. ERC-20 interface of the VOTE token
Staking contract should implement the ERC-20 interface of the VOTE token. It should be a non-transferrable token that can be consumed only by the set of the whitelisted addresses (Jet contract in the beginning). transfer method should always fail and transferFrom method should fail if itâs not called from the whitelisted contract.
10. VOTE token management (add or remove VOTE from the user)
Admin of the contract should be able to add or burn VOTE tokens. This is a safety method with an intention to use only in emergency situations.
11. Collecting the stats on the accrual and usage of the VOTE tokens
For every season and every user we should record and give a public access to the two numbers: the amount of VOTE tokens that was obtained by the user (is set during the call of claim VOTE tokens); and the amount of used VOTE tokens in this season (updated every time when transferFrom is called from the whitelisted contract)
12. VOTE decay and grace period
VOTE tokens should become available for claiming at the beginning of the season. However, starting with the voting phase of the season, VOTE tokens should linearly decay to zero at the end of the voting phase. Thus in the middle of the voting phase, the user should have only half of the VOTE tokens available for the voting in Jet.
In the beginning of the voting phase there should be a grace period (24-48h) before the decay start. Grace period prevent excess load on the network in the beginning of the voting phase.
Decay mechanic is used to mitigate the following problem. A voting in Jet due to the short development timeline may be implemented only in an open way. Which means that with the usage of indexers anyone would be able to figure out what is the current amount of VOTE that was used and what projects have been voted for. This gives an unfair advantage to the users that vote at the end of the season, since they can most certainly determine which projects will win and vote for them. This is important since the mechanics of the rewards, distributed to the Jet users, should depend on the results of the voting and whether the project received the grant or not, in particular: the community should be motivated to dive into projects instead of just voting for the first random application.
13. Deposit AURORA on behalf of the other user
Staking of AURORA tokens should be possible to the other accounts: Alice should be able to create a stake to Bobâs account. Stake that is created for the other account is irrevocable.
This functionality will be useful to allow for the staked drops of AURORA: anyone would be able to create a stake of AURORA to the user, thus motivating him to take part in the governance of Aurora. Similar solution in the NEAR runtime is very popular.
Open questions
- AURORA staking contract should be deployed to Aurora; but Aurora DAO is located in NEAR runtime. The functionality of the interaction with Aurora from the NEAR account is implemented, though it is not yet thoroughly tested.
- Maybe we should remove the necessity of approve for VOTE tokens for the whitelisted contracts. If so, the user wonât need to send an additional transaction to the staking contract before voting.
- To simplify the staking contract and the management of the VOTE tokens, one can separate the token and staking functionality, turning staking contract into the factory of the VOTE token contracts that are specific to each season. These contracts would store the info on the usage and should be used for the voting purposes.
Ideas for the future
- Delegation of the VOTE tokens. Delegation mechanics has shown itself quite sustainable and result-oriented. It allows people to form cohorts, spend less time on making decisions and embraces the trust in between them.
- A good direction of the development would be to introduce a delay for the upgrade of the staking (and thus governance) mechanism. Such a delay will give more power to the token holders, since in case they are disagreeing with the upgrade, they have a time to leave the system.
- Implementation of the commit-reveal scheme for the voting in Jet might remove the necessity of VOTE decay in the future. Most probably this upgrade should come in hand with the advanced voting mechanics that protect the system from malicious behaviour, like selling votes (voting may happen multiple times with inability to prove that the vote was final).
- Some tokens might have restrictions. In the future it would be good to implement an ability to the stream creator to specify the contract that will do the check of whether the user is eligible for the rewards from the stream or not.
- Thereâs always a possibility to make staking liquid (give user a sAURORA token). There might be 3rd party projects evolving that provide the functionality of the liquid staking.
