DAO Governance

Astrono Council

The genesis of the Astrono project was a desire to make a collectible NFT game that was open, transparent, and governed by the community. Here we outline the mechanism by which the community of $ASTRONO holders will govern and maintain the protocol, via the Astrono Council, and what types of changes can be proposed. It’s worth noting we have modeled the governance process and had input from several Synthetix core contributors, who themselves modeled their governance on the Ethereum EIPs and early versions of change control in open-source software.

Council Vote Election

To elect council members, holders of $ASTRONO have the ability to nominate an individual for a council seat as well as delegate their vote to a nominee. Candidates for council members must be proposed before the due date of the election, followed by a formal voting period that lasts 72 hours to elect the 5 individuals best suited for the role of governing the platform. The eDAO will then collate all proposed members from the Astrono Discord Channel Astrono Council, and prepare the candidates to be voted on within Snapshot.

(The "eDAO" and "Astrono Council" is our initial governance model and is subject to change. We strive to implement the best models of decentralized governance).

Quadratic Voting

This mechanism will be utilized to reduce the voting power of large $ASTRONO holders and reduce plutocracy. This system is used successfully by a number of other protocols and used within Gitcoin Grants and we believe it is the fairest way to weight votes.

Specification Overview

There are two major components of the new governance system:

The Astrono Council will consist of nominees who are voted in by the $ASTRONO token holders, enabling the influence of community representatives who are able to debate and distill technical changes while also not directly providing large $ASTRONO holders a disproportionate voting weight in the outcome of proposals.

Astrono Proposals (changes in the protocol via ICCPs and IIPs) which are submitted to the IIP’s Github repository and will be posted on the Astrono Proposal space. Proposals must reach a supermajority agreement to be enacted.

Defining an ICCP

Astrono Configuration Change Proposals (ICCPs) are documents that put forth a case for modifying one of the System Configuration Variables of Astrono. The intent is to provide a clear and detailed history behind each configuration change and the rationale behind it at the time it was implemented. The author of the document is responsible for building consensus within the community and documenting dissenting opinions. There will be a separate blog posted later on how to correctly write an ICCP.

System Configuration Variables that can be changed via ICCPs may include:

• Configurable Council Values (see below)

• Marketplace fees

• Capture mechanics

• Balance changes

Defining an IIP

The purpose of Astrono Improvement Proposals (IIPs) is to ensure changes to Astrono are transparent and well-governed. An IIP is a design document providing information to the Astrono community about a proposed change to the system. The author is responsible for building consensus within the community and documenting dissenting opinions. There will be a separate blog posted later on how to correctly write an IIP.

Improvements made via IIPs may include:

• New contracts

• New systems

• Expansions

• Character sets

Council Epoch

The Astrono Council members will serve for an entire Council Epoch (Epoch length can be configured via an ICCP) and during the Council Epoch their main responsibilities include debating and voting on ICCPs and IIPs within a public forum on discord. If there is a case where a council member has to withdraw during an Epoch, the Council will continue to operate but the supermajority formulae will change (there must be a supermajority on each normal proposal).

Meta-Governance

There will be situations where changes to the $ASTRONO council will need to be decided. Any meta-governance proposals will need to be unanimously decided.

Council Stipend

Initially, $ASTRONO payments to Council Members will be paid manually by the AstronoDAO at the end of a Council Epoch. In the case of sufficient Council Member’s votes being pulled out before the end of a Council Epoch to remove them from the Council, they will receive $ASTRONO rewards proportionate to their time in the Council during that Epoch, up until the point at which their NFT is retrieved. The replacement Member will receive $ASTRONO rewards proportionate to their time in the Council after which their NFT is issued.

Supermajority

A supermajority is defined by the following formula: ⌈(N+1) / 2⌉ where N represents the number of council members.

Executioner DAO Discretion

Despite the council reaching a consensus on a proposal, the ExecutionerDAO still acts as a backstop for the protocol and can step in-case of an emergency.

Technical Specification

Executioner DAO (eDAO) will need to create a modified version (or custom contract) of an NFT which can be revoked and issued to EOA’s (Externally Owned Addresses), signifying a wallet is part of the Astrono Council. A new space on Snapshot will be created to house the Astrono Council Election process. (live at council.Astrono.io) Addition of a new “Atstrono Proposal” space that utilizes a new strategy to explicitly count the eDAO issued NFT. (in progress gov.Astrono.io)

Configurable Council Values (Via ICCP)

Council Nominations Deadline — initially set at 72 hours prior to when the Election Period begins. Election Period Length — The length of time of an election cycle. At the end of the Election Period, the council members will be issued their NFTs

Council Epoch — the period after which token holders must redelegate their votes to new and existing council members (to prevent stagnation and transitory power)

Timelock period — the period where the proposal is in review before being implemented, initially set at 24 hours.

Astrono Council seat numbers — the number of seats available on the Astrono Council and thus the number of votes required for a supermajority.

Balancing via Governance

Because of the data driven nature of the underlying Astrono codebase, balance patches can be executed much more dynamically than traditional games. Each patch will be a Neural Net Assisted update, that takes into account the thousands of expected matches in the game and is voted on by the council.