This proposal is a rehearsal of the first AURORA staking discussion. We highly recommend reading through the previous proposal, if you would like to dive into the differences.
The goal of AURORA staking is to allow for the community treasury and governance use-case previously voted by the Aurora DAO. Many pieces of the previous proposal are conserved, however new ones are added to enhance the value add. A new forum thread is created to separate the discussion.
Though previous proposal was delivering the desired functionality, it was having several drawbacks, outlined by the community:
Seasonality. Though seasons are a great concept, they limit the velocity of operations of the Community Treasury platform. Indeed, there’s no possibility of ‘fast grants’ allocated through the community treasury.
Absence of compounding of AURORA. Compounding AURORA would decrease the dummy load on the network (users claims AURORA rewards and then immediately stakes it).
Complexity. Seasons and the need to implement VOTE token interface directly inside the staking contract increases its complexity, which leads to a bigger attack surface of the contract. It’s better to add functionality one step at a time to ensure robustness of the system.
Below is a description of staking mechanism, consumable even by the people who didn’t read the previous proposal.
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, including voting rights, represented as yet-to-be-designed VOTE tokens with their respective mechanics.
The staking mechanism works as follows: user deposits AURORA tokens in a contract and gets some shares of the total pool of AURORA tokens. In accordance with the shares of the pool, a user gets additional auto-compounding AURORA rewards and rewards in other tokens. That is, staked AURORA produces rewards in multiple tokens. Rewards are implemented as streams, which have their own distribution schedule, which is the same for all stakers. Users are able to claim the rewards and unstake AURORA, however there’s a period during which the respective tokens would be locked. This period prevents the spam of the network with constant claiming transactions.
Rewards streams are usually created by third parties, however, subjected to whitelisting by the admin of the staking contract. The admin is also able to close the stream in case it violates any applicable policies.
It is important to understand why 3rd parties would be willing to create streams. This mechanic is expected to be implemented by the community treasury. In simple words: the community allocates a grant to the builders, while, in return, they allocate a portion of their tokens back to the community through AURORA staking mechanism.
Locked AURORA (for example AURORA that should yet to be transferred to the private round investors) cannot be used for staking.
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 in the medium to long term. To preserve the high speed of the reaction to changes in the first phase, it is proposed that Aurora Labs holds the admin key for the staking contract.
*Every NEAR account has an implicit account in Aurora and is able to interact from NEAR runtime with Aurora runtime.
Multiple accounts should be able to temporarily seize the execution of staking, including paying out rewards. 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.
Users should be able to stake AURORA (deposit AURORA to the contract for some period of time).
During staking, the user gets rewards through streams. Depending on the moment in time when the user staked AURORA, a weighting coefficient is applied to the rewards that are not the default AURORA stream.
The weighting function is the following:
100% during the first month since deployment of staking contract (grace period)
Linear decrease from 100% to 25% within 4 years after the grace period
Constant 25% after linear decrease is executed
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 during the grace period. Their stake generates 100 TRI rewards in 5 years from the beginning of staking. If the user would unstake 10 AURORA and then immediately stake them, their reward would be decreased to ~25 TRI. Unstaking 1 AURORA and staking it back would result in the same rewards change.
In case a user has 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.
Aurora DAO should approve the default AURORA stream. In this particular 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.
The weighting function and its’ mechanics exists to support the early ecosystem of the project and long-time stakers. It is expected that Aurora Labs team won’t be able to utilize the advantage of grace period at all, and only a small amount of private round investors’ tokens would be unlocked during the grace period.
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.
A user should be able to claim 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.
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 pro rata. 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 allocation of the rewards in the stream.
Release time – time after which the claimed rewards are available for withdraw
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.
This method is called by the stream creator (only once) and it realizes the option that was set up during the whitelisting phase.
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.
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.
The contract that would hold staked AURORA and rewards from the streams should be separated in a minimum-functionality contract, while the complex staking behavior should be implemented in a main staking contract. This would do the separation of concerns and simplify the development and auditing work.
Once the mechanics of the community treasury platform the protocol governance will be determined, these mechanics may be implemented as a separate VOTE token stream. The basic functionality the more and the longer you stake, the more you get VOTE tokens is generic enough to be an efficient mechanism. VOTE token contract itself can implement additional features like quadratic staking, weighting based on the usage of the voting or decay of the voting rights.
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.
Some tokens might have restrictions. In the future it would be good to implement an ability for 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 the user an stAURORA token). There might be 3rd party projects evolving that provide the functionality of the liquid staking.