AURORA staking and the community treasury


  • 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


  • add pictures to support the flow


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


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.

Comments from the discussion with Aurora Labs and NEAR Inc team.

  1. Grace period to postpone the start of the decay for a day / several days
  2. Commit-reveal scheme for the voting + protection from the selling the votes
  3. Separation of the VOTE token contracts per season <=> make a factory from the staking contract
  4. Liquid staking

“Farms” is a well established term in DeFi, and I believe would be confusing if used in this context. As described, the terms “Faucet” or “Streams” seems more appropriate.


Will there be a quorum or threshold on each proposal? What the number should it be?

The info about the mechanisms of the Jet will be separate from this topic. I’m working on finalising it.


There’re three additional ideas:

  • The rewards from the farms/streams should be deposited on the demand account (auto-staked with the season 0). This would simplify the interaction with the staking contract and stakers won’t loose compounding.
  • There should be a minimum amount of AURORA to stake for more than 0 seasons: like 1 AURORA or so. This would prevent spamming the contract by bots that would withdraw rewards and sending them to stake for more seasons. The main problem of such a spam would be a bloat of the storage in the staking contract
  • The distribution of AURORA to the farm owner should be not immediate, but according to the same distribution schedule that is applied to the farm itself

I’m planning to incorporate the ideas in the final document over the next days and add some images to simplify the reading


gm. it might even be worth raising the minimum number to 5-10 AURORA, so that it would be more economically costly to maintain an army of bots :upside_down_face:


maybe it would also be good to add a bit of GOV tokens as a reward for liquid staking aurora/near and some other pairs on etc.

1 Like

Hi, @denz !
It would be quite problematic to allocate VOTE tokens through any other mechanism rather than native AURORA staking for multiple reasons.

First, staking contracts as you can see, is a VOTE token. In other words, it implements the VOTE token ERC-20 interface, and naturally it can mint VOTE tokens, implement decay mechanics, etc.

Second, liquidity rewards assume that there are pre-mined transferrable VOTE tokens, which is not true at the moment. The proposal is around providing VOTE tokens only to those who support Aurora ecosystem, without unsymmetrical programs: all to make the governance as decentralized and as democratic as possible.

1 Like

What a exciting staking mechanism, claim rewards by multiple times will give people a sense of happiness, but because some rewards are too small, it is very troublesome to collect them repeatedly. In general, I recommend setting an upper limit for batch claim reward tokens, such as 5. This not only eliminates the trouble of repeating small rewards, but also retains the sense of surprise when receiving it.


And I think that some introduction information about the project should be added in the claim stream rewards interface (can be provided by the project official, may it can be used web3?), so as to let the stakers know what they have received and increase their understanding of the project.

Batching claims can happen, sure. Moreover, the claim functionality is not requiring the necessity of the user to send a transaction on his own. So, a backend code can run a script, to claim all rewards, once the user is hitting the button ‘claim all rewards’. Which would be nice. Moreover, such a backend script can work periodically, like once every day or so, so there won’t be a lot of unclaimed rewards.

And I think that some introduction information about the project should be added in the claim stream rewards interface

Definitely, it’s a good idea to have some description; however, the question is where to store it: on a blockchain or outside. Perhaps, a community can make a separate contract where it would upload the detailed info about the streams.


There is a separate staking proposal with a focus on simplicity, that stem out of this discussion.

Hi team,

I’m not sure if this thread is the best one to address this question, but I have some concerns around the tokenomics of Aurora.

Aren’t you worried about the Tokenomics of Aurora?
20% Team
16% Team
9% Insider investors
3% Eco
2% Contributors
1% Team
1% Public IDO
48% Team

It’s a concerning how much the team has allocated for themselves.

How do you justify this? I’m asking because I genuinely want to understand better the reasoning behind it.

Thanks in advance,

1 Like

20% community treasury - it’s not for the team, read more about a possible use case for the treasury here.
48% DAO balance - it’s not for the team, but for other activities, such as this proposals for grants.

1 Like

Stats are wrong. But 1 percent for community via ido was a bad decision imo.

Adding to that 5 months already gone after this thread and still we have no use case of this token.

what is the current network inflation in Aurora plus due to staking rewards?

I agree

Hello. Just curious: how to find out the number of stakers on Aurora+?

1 Like

Anyone? How can i find out the numbers of stakers?

1 Like