Replies: 1 comment
|
将 Aleo 的总信用供应量限制在 1 亿 |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
arc: 0047
title: Limit Aleo’s Total Credits Supply to 5 Billion
authors: @raychu86
discussion: #101
topic: Protocol
status: Accepted
created: 11-26-25
Abstract
This ARC proposes establishing a hard cap of 5,000,000,000 Aleo Credits (ALEO). The cap will be enforced by halting block rewards and proving rewards at a predetermined block height (based on theoretical maximum issuance).
Motivation
Under the current Aleo emission schedule, rewards continue indefinitely and total proving emissions are tied directly to network proving activity. This creates several long-term economic challenges:
Establishing a 5 billion ALEO maximum supply addresses these issues by providing:
Specification
The Aleo network launched with an initial supply of ~1.5 billion ALEO. All subsequent issuance occurs through block rewards and proving (puzzle) rewards. This ARC does not modify the emission rates of these rewards; instead, it introduces a deterministic point at which both reward streams terminate.
Deterministic Block Height Cap
We define a block height H such that, even if every block from genesis to H paid out the maximum possible proving reward, total issuance could reach, but never exceed 5 billion ALEO.
At block height H, the following MUST occur:
Because actual proving activity is consistently below the theoretical maximum, realized supply will almost certainly fall below 5B ALEO at the cut-off.
Properties of this approach:
Emission Profile
NOTICE: The upper-bounded total supply shown here is not an emission forecast. It is a theoretical maximum calculated by assuming every block receives the maximum possible mining and block rewards, solely to establish a conservative block-height bound for 5B credits. In practice, actual emissions will be significantly lower than this theoretical cap.
Reference Implementations
An implementation can be viewed here for your review - ProvableHQ/snarkVM#3042
Backward Compatibility
This ARC introduces a new cryptoeconomic mechanism and will require a simple network upgrade. Because this change is planned far in the future, it does not require specifying an explicit consensus-version activation. It is sufficient that node operators upgrade at some point within the ~25-year timeframe. In practice, many other consensus upgrades will occur long before then.
Future Work
Because the changes are not expected to occur until ~Q4 2049, there is flexibility for adjusting the limit height in the future to be more accurate if there are major changes to network assumptions in the future.
All reactions