Designing the Aleph Zero Governance

Aleph Zero Governance is designed to mitigate vote-splitting and ensure that only the most robust, widely supported ideas prevail. Dive into the proposed voting structure around the AZERO economy and get ready to vote on August 30th!

Update: The test vote is live – the actual vote to start on August 30th

You can already get to know the voting platform – participate in the test vote on gov.alephzero.org!

The “Logic extracted from community proposals” has been updated with more detailed descriptions.

If you’re using multisig account–head over to docs.alephzero.org to get to know how you can participate.

A multi-staged voting system for the Aleph Zero economy

The proposition below has two goals in mind: align all community efforts around future project growth and help design a decision-making process that is both inclusive and effective. 

Below, you can find a visualization of a proposed decision-making process for the Aleph Zero Governance vote on the AZERO economy:

The suggested design is based on careful analysis of all relevant community suggestions and proposals shared on the Aleph Zero Discord, as well as incorporating findings behind general science of choice-making. 

This article describes the rationale that led us to this particular proposition. 

Making the right calls—fast

The Arrow’s Impossibility Theorem highlights that there is no perfect protocol to choose between multiple proposals where each has a different underlying logic and lacks a standard structure. Initially, it might seem sufficient to pose a multiple-choice question and select the most popular answer, but this approach is far from optimal; essential ideas can be diluted across similar proposals, leading to vote splitting and cannibalizing the healthiest concepts. As a result, a less popular proposal may be chosen simply because it is less divided. 

Reducing vote-splitting with staged voting

To avoid the above, we’ve begun with a more nuanced, carefully designed voting protocol—but one that is still simple to use. Specifically, a short sequence of voting rounds to reduce the vote-splitting problem by focusing on a few fundamentally different proposals that, by definition, do not cannibalize each other. 

This process can be envisioned as a decision tree where each vote corresponds to traversing a single branch. The most straightforward approach is to structure the voting so that the general logic is chosen first—for instance:

• Introducing a maximum issuance cap of AZERO, and having a constant amount of AZERO minted each year;
• Selecting specific parameters for the winning scheme in subsequent rounds. 

The above has been designed to address the Aleph Zero Economy, and should not be taken as a framework for general governance. We would suggest, however, to keep this particular model for core decisions going forward, pending the community’s feedback.

Logic extracted from community proposals

Among the popular proposals submitted in the Aleph Zero Discord, four distinct underlying logics have emerged: 

AIP01 (as introduced by sc0t)

This proposal seeks to establish a maximum supply of AZERO, referred to as MAX, along with a constant annual minting amount of AZERO, referred to as MINT. Both MAX and MINT will be determined by a community vote if this proposal is approved.

Note: The original proposal included the concept of distributing the fee pool across various destinations. However, this idea has been excluded from this vote as it falls outside the scope of this proposal, which focuses on the core principles of the tokenomics. A separate vote addressing the allocation of minted tokens and fee destinations will be held no later than Q1 2025.

AIP02 (as initially proposed by the Aleph Zero Foundation)

This proposal introduces a maximum supply of AZERO, referred to as MAX, combined with an exponentially decreasing annual minting schedule–modeled after the Bitcoin system, although intended to decrease . The exponential decrease will be governed by a rate parameter, referred to as LAMBDA. Both MAX and LAMBDA will be determined by a community vote if this proposal is approved.

AIP03 (as originally proposed by Freshman)

This proposal implements a percentage-based inflation model in which the inflation rate decreases linearly until it reaches a predefined minimum. The parameters governing the rate of decrease, referred to as SPEED, and the minimum inflation rate, referred to as MIN, will be determined by a community vote if this proposal is adopted.

AIP04 (as originally proposed by Martin)

This proposal establishes an inflation model that adjusts based on predicted validator costs, with a hard cap at MAX_INFLATION. MAX_INFLATION will be determined during the initial community vote. The inflation rate will be calculated using key parameters—MONTHLY_VALIDATOR_COST and TARGET_VALIDATOR_ROI—which will be subject to annual re-evaluation through a community vote if this proposal is approved.

The system will adjust the inflation rate for each era to ensure validators receive an average return of TARGET_VALIDATOR_ROI, based on the specified MONTHLY_VALIDATOR_COST. If the calculated inflation rate exceeds MAX_INFLATION, the rate will be capped at MAX_INFLATION.

AIP00

In addition to the AIP01-AIP04 proposals, this proposal includes an option to maintain the current system of minting a constant amount of AZERO each year. The specific amount to be minted, referred to as MINTED_AMOUNT, will be determined by a community vote if this option, referred to as AIP00, is selected.

While these proposals differ in their underlying logic, the risk of vote-splitting is still very relevant. And this brings us to the next point: 

The rationale behind the decision process

It appears that one of the fundamental decisions is whether to introduce a maximum AZERO supply cap or not. To address this, we propose splitting the voting process into two rounds. The first round would be as straightforward as possible and yet extremely important:  

Voting #1

If #1A were to win, the second vote would then be designed about how the community would want to reach the maximum supply of AZERO:

Voting #2A

If #1B from Voting #1 were to win, the second vote would then be designed about how the community would want to tackle the inflation in the ecosystem: 

Voting #2B

The above should effectively help to move to the next phase of the vote on the Aleph Zero economy, which is choosing the exact hyperparameters supporting chosen decisions. 

Choosing the exact hyperparameters

Depending on which proposal is the community’s favorite, several hyperparameters may need to be decided upon. 

Both AIP01 and AIP02 require setting a maximum AZERO supply cap, with AIP01 and AIP00 also needing the specification of the annual minting amount. AIP03 necessitates determining the target minimum inflation rate. And although AIP04 is not initially based on specific hyperparameters, we propose introducing one: the original proposal uses the current inflation rate (10.46%) as a hard cap, but this choice seems arbitrary. Therefore, we suggest putting this cap to a vote, too.

But how should these hyperparameters be chosen? Fortunately, one of the community proposals addresses this issue: “Determine Inflation via a Sequence of Votes” by olivierkx. A slight modification to this approach might benefit the Aleph Zero community, as the original relies on a series of yes/no votes; a multiple-choice vote seems more appropriate and efficient, with the core idea remaining the same.

A multiple-choice vote would be conducted to choose the value of a hyperparameter, with several potential values for the parameter. After the voting concludes, the parameter is set to the lowest value that secures the most votes. We recommend reading olivierkx’s original rationale for further insight.

Arriving at the final design

The rationale outlined above gets us to visualize the decision tree, which we trust to be an optimal way to make decisions around the AZERO economy. 

We invite all community members to express their feedback before voting – scheduled to begin on August 30th!