Further decentralisation of the governance

Decentralisation of the governance

Aurora was developed with the decentralisation as a core principle. This is supported by the fully trustless architecture of the Rainbow bridge and the launch of DAO at the early stage of the project.
This writeup is opening a discussion about the future of the governance of Aurora protocol. Below is the proposal for the refinement of the governance process with an approach to decentralise it even further.

Current state of the governance

Currently the agreed approach to the governance of the Aurora protocol consists of two separate mechanics: DAO and community treasury.

DAO Councils

Aurora DAO utilises SputnikDAO framework for operations (works on NEAR blockchain). Aurora DAO currently has 13 councils. Councils are voting on the proposals and according to the simple majority of the votes they got approved or rejected (one seat – one vote). Proposals include council management, DAO smart contract upgrades, contract calls and payouts (any NEP-141 tokens or $NEAR). Using this functionality Aurora DAO can perform any actions with respect to Aurora protocol.

It is important for future reading to note that SputnikDAO allows to specify policies – the rules that govern the decision process for specific proposals. Say, the DAO might require the 66%+ votes for membership management proposals and 90%+ votes of the technical committee (the subset of the DAO members) for the DAO contract upgrades. Management of the policies and member roles (result in creation of committees) is also available to the DAO council decision.

All the above is already implemented and is available right now.

Community treasury

By the decision of the AuroraDAO (council votes) a portion of the AURORA token supply is allocated to the community treasury (CT). The treasury is used to fund existing projects and project proposals through a Kickstarter–type platform (current version of the name for it is Jet): projects are submitting the applications, while token holders are voting for them. Thus, community treasury is implementing a much more decentralised governance in comparison to the current setup of the AuroraDAO.

The above mechanics is not yet available, it’s in the process of the implementation.

There’re multiple reasons for limiting token holders voting to community treasury only:

  • Participation in the voting on Jet is typical for the token holders: an average person that is interested in crypto is investing in projects on a constant basis.
  • Other decisions might be quite complicated or require additional deep knowledge (upgrades of the contracts)
  • Initial set of the token holders might be quite limited / uneducated to implement the management of the DAO councils

Evolution of the governance

Below is the proposal to refine the governance process and decentralise it further. It consists of multiple parts with the timeline for implementation.

VOTE tokens

This section is to be discussed in detail within the community treasury mechanics. However, for the sake of clarification, it’s worth noting some aspects.

It is expected that every token holder receives VOTE tokens for staking AURORA. These VOTE tokens are expected to be used in Jet. VOTE tokens are non-transferable and are separated from AURORA to resist Sybil attacks: if AURORA staking is not necessary for the governance purposes, a user may transfer AURORA from account to account and vote multiple times. Staking AURORA is the only way to receive VOTE tokens.

DAO council elections

We believe that the setup with the separation of the councils for everyday tasks and token holders for major decisions is efficient and is working in the full alignment with the democracy paradigms: DAO councils act similarly to Parliament, while token holders voting is close to the referendum of the citizens. However, one thing is missing: the election process for the councils.

The proposal is to fix the amount of DAO council seats, say 25. Once per year token holders should be electing councils to the DAO. An account may apply for the council seat in case it passes the minimum requirements (to be discussed further; these may or may not include KYC, amount of staked AURORA, account activity / rating computed using the publicly known approaches). It is expected that a wide number of accounts may apply for the DAO Council seats, while minimum requirements are used to resist Cybil attacks (same entity trying to get multiple council seats). Both individuals and Organizations may apply for the DAO Council seats.

The election process should consist of two stages: candidate submissions and election. Candidate submissions should happen within a month before the election stage. Election stage should take 1 week. The weight of a vote of a token holder should be equal to the amount of VOTE tokens that this holder acquired within the previous year.

Community proposals

At the moment any NEAR account can submit the proposal to Aurora DAO with a requirement to lock 1 NEAR. Though this mechanic is useful, it is expected that in most cases community wants to be heard through the simplest means.

The proposal is to manage community proposals in two separate tracks: informal and formal.
Informal track encompasses token holders creating proposals on the Aurora Governance Forum. Any token holder is able to take part in the discussions around the proposal. Councils are free to comment and suggest changes. At any point when a council member is agreeing with the proposal, he can create a voting for the DAO councils to support the proposal. Any decision of the councils is deemed final for the proposal. It is expected that this track would be suiting most of the proposals.

However, since in the informal track there’re no forced restrictions on the DAO councils, there should be a way for the community to force the council voting. The proposal is to allow community members to create special community proposals, which should be voted by the token holders. In case 1% of the circulating supply of AURORA is supporting the proposal, it is moved to the voting of Councils.

Council resignation and early elections

A council is able to unilaterally resign. It is expected that such resignation would occur only in cases when a council is principally against decisions that are made by the multiple council votes. In case more than 33.3% of the councils resign, the early elections should be scheduled in 1 month. Until the elections are finished, councils are not able to make any decisions.

The idea behind the resignation threshold come from the BFT consensus: 1/3 of the participants can halt the execution.

This mechanics is viewed as a countermeasure to the situations when councils are not supporting crucial community proposals.

DAO Council compensation

Since the DAO councils should devote their time to create and analyze proposals, it is expected that the load on them will be substantial and the proper compensation for their work should be established. The compensation should be paid out monthly as unlocked AURORA tokens. The compensation should be decided by the councils as a separate voting decision. The compensation should be high enough for the council members being able to devote enough time to their responsibilities and be resistant to bribery. As a point of guidance for the compensation level, it is proposed to take the salaries of the members of the European parliament, which is around $120k per year.


It is proposed to start the development of the described mechanics (changes in the Aurora DAO contract) as soon as possible. Informal track for community proposals should be implemented immediately.

As soon as the above mechanics are developed, the DAO contract should be updated with enabling the Council resignation and early elections, and formal track for community proposals.

The first scheduled council elections should take place during the week of 14th of November 2022 to celebrate the anniversary of AURORA inception. Council compensation should be enabled after the first elections (either early or scheduled).


I agree with you,this‘s the best way


Agree it,but which token should we own to vote?

Agree it,but which token should we own to vote?

Agree,we should actively participate

I agree,looking forward to participating in

On behalf of Pantera Capital, thank you @Alex for raising this for the Aurora community’s feedback. We agree with this overall direction of progressive decentralization via parliamentary system and the accompanying checks & balances via community voting.

A couple of thoughts as we discuss:

  1. Council compensation (or a portion thereof) should vest over time (range of 2-4 years) and with a cliff (1 year or so) to align council members with the long-term health of the DAO. What does the community think about this?

  2. Should compensation be denominated in AURORA token, effectively as a % of token supply, or as a fixed / stable amount as proposed? The benefit of AURORA-denominated compensation is that it naturally adjusts compensation up or down in alignment with the health of the DAO and the impact of Council decisions.

  3. The ability for the community to remove council members “mid-term” is an important check / balance. Should there be an established, standalone process for this or would the formal / informal proposal process be the main conduit for this kind of action (if needed)?

  4. A Security Guardian-type capability may be useful to implement. In emergency cases, there’s value in having a pre-established voting process with a lower time delay & quorum and narrowly-defined set of actions. Maybe this is a topic for later discussion, but worth articulating that this would be another key function for Council members.


@mergod @akxakxll it is proposed that people who stake AURORA will receive VOTE tokens that will be required to vote.


I very much agree with your point of view. But I think there should be a better solution. I can’t think of it temporarily

Sounds great,l am pleasure to see that

I’m agree with what you said

A w question that you ask

@franklin-pantera - Agree for DAOs elected after 11/22- but original DAO will do/is doing its foundational work to enable long term health during Year1. May need further consideration.

@franklin-pantera , thanks for the ideas raised!

My personal reaction to your suggestions:

  1. Locking of the compensation + denomination. IMO, if we treat the council compensation as a salary then it’s worth fixing the EUR / USD amount and keep it unlocked. However, the compensation should be high enough, as a protection from bribery.

  2. Mid-term council removal. If we go deeper with analogy with the parliament, naturally there’s no such thing as impeachment of a parliament member. But in goverments it’s compensated with different branches of the law. So, perhaps, implementation of such procedure might make sense as an extreme solution.

  3. Security guardians. I’m with this idea and wanted to have is as a separate topic: the committees in the Aurora DAO Council. SputnikDAO allows to crease committees (where not all the councils are included) and specify policies which regulate what proposals committees are capable of voting. So, fo security guardians council, we can specify a policy for being able of issuing the contract freezing transactions for some of the important contracts that Aurora develops. This will allow to quickly stop the attacks, while bounding the impact that the committee is able to make.


The token is already out months back and we are still unclear of governance.
Fully centralized with community having almost zero say.
Had high hopes few months back from aurora but most of the hopes were shattered with the results by now.

1 Like

Thanks for your opinion, Darkseid.
Do you think that this proposal is good as a way of decentralizing the governance further?

I feel timing is the main key.
I was here when the proposal was put in here. Didnt created account as was thinking team will do the needful with so much expertise.
Recently saw bridge attack which was secured. Kudos

I have moved on to optimism and arbitrum with over 90 percent funds from aurora as i see them more focused on the community.
Like op releasing tokens for the purpose of governance after the ecosystem got built up with some desired outputs. But here the case seems opposite.

I will say again. Proposal is good. But now it seems the date of 14th november is too late seeing no use case of tokens.
I read about staking usecase too. But still no implementations on the same.


Frankly I felt very excited to have come across such a thorough proposal, and was tempted to chime in with my two cents, to complement further. But I got equally surprised and perhaps more concerned about the lack of follow up it so richly deserves, and it has been so long !!


It is in discussion and development. Such things need time to implement, but rest assured this proposal is not forgotten.

1 Like

I see… I thought it would first go for voting, before development, and implementation !