DAO Governance
#
Illuvinati CouncilThe genesis of the Illuvium 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 $ILV holders will govern and maintain the protocol, via the Illuvinati 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 ElectionTo elect council members, holders of $ILV 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 Illuvium Discord Channel Illuvinati Council, and prepare the candidates to be voted on within Snapshot.
(The "eDAO" and "Illuvinati Council" is our initial governance model and is subject to change. We strive to implement the best models of decentralized governance).
#
Quadratic VotingThis mechanism will be utilized to reduce the voting power of large $ILV 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 OverviewThere are two major components of the new governance system:
The Illuvinati Council will consist of nominees who are voted in by the $ILV token holders, enabling the influence of community representatives who are able to debate and distill technical changes while also not directly providing large $ILV holders a disproportionate voting weight in the outcome of proposals.
Illuvium Proposals (changes in the protocol via ICCPs and IIPs) which are submitted to the IIP’s Github repository and will be posted on the Illuvium Proposal space. Proposals must reach a supermajority agreement to be enacted.
Defining an ICCP
Illuvium Configuration Change Proposals (ICCPs) are documents that put forth a case for modifying one of the System Configuration Variables of Illuvium. 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 Illuvium Improvement Proposals (IIPs) is to ensure changes to Illuvium are transparent and well-governed. An IIP is a design document providing information to the Illuvium 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 EpochThe Illuvinati 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-GovernanceThere will be situations where changes to the $ILV council will need to be decided. Any meta-governance proposals will need to be unanimously decided.
#
Council StipendInitially, $ILV payments to Council Members will be paid manually by the IlluviumDAO 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 $ILV 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 $ILV 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 Illuvinati Council. A new space on Snapshot will be created to house the Illuvinati Council Election process. (live at council.illuvium.io) Addition of a new “Illuvium Proposal” space that utilizes a new strategy to explicitly count the eDAO issued NFT. (in progress gov.illuvium.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) — initially set at 3 months with the genesis election being 18th February 2021 (0:00 UTC)
Timelock period — the period where the proposal is in review before being implemented, initially set at 24 hours.
Illuvinati Council seat numbers — the number of seats available on the Illuvinati Council and thus the number of votes required for a supermajority.
#
Balancing via GovernanceBecause of the data driven nature of the underlying Illuvium 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.