Aurora DAO Approves $AURORA Staking Contract

To be able to launch its decentralized governance safely and to reward its long term token holders, Aurora needed a staking contract for the $AURORA token.

Through staking, users will receive $AURORA rewards and voting rights, represented as yet-to-be-designed VOTE tokens with their respective mechanics.

The staking mechanism works as follows: user deposits AURORA tokens 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 additional rewards in other tokens.

Users are able to claim the rewards and unstake AURORA, however there’s a period during which the respective tokens will be locked to prevent spammy claiming transactions.

Additional rewards streams are usually created by third parties, like Aurora’s ecosystem projects, upon the approval of Aurora Labs.

Additional features

Allowing third parties to create such streams will allow us to create the community treasury in the future, on which the community will vote to allocate a grant to the builders, while, in return, they allocate a portion of their tokens back to the community through the additional rewards distributed by staking $AURORA.

The staking contract also 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.

Locked AURORA (for example AURORA that should yet to be transferred to the private round investors) cannot be used for staking.

Deeper insights on contract functionalities

1. Proxy, Upgradability and Pausability

The staking contract is manageable and will probably 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, 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 will be able to temporarily seize the execution of staking, including paying out rewards.

This is required for the fast reaction to external threats. The admin will be able to manage the list of these accounts and unfreeze the staking contract.

2. Staking functionality

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.

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.

The weighting function and its mechanics exist 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.

3. Rewards stream whitelisting, creation and removal

If you want more details on how rewards streams are managed, please check out the DAO proposal.

4. 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.

Some thoughts on governance procedures

Once the mechanics of the community treasury platform will be set up and 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.