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