AURORA staking and the community treasury

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

Can you share some tips about the importance of this staking method.

1 Like