diff --git a/docs/blockchain/raw/bedrock-anonymous-leaders-reward.md b/docs/blockchain/raw/bedrock-anonymous-leaders-reward.md
index e55344300..372f8fd9f 100644
--- a/docs/blockchain/raw/bedrock-anonymous-leaders-reward.md
+++ b/docs/blockchain/raw/bedrock-anonymous-leaders-reward.md
@@ -26,6 +26,7 @@
| --- | --- | --- |
| 1.0.0 | Initial revision. | 2026-03-30 |
| 1.1.0 | Round the leader share downwards and align the voucher commitment and nullifier domain separation tags with Mantle | 2026-08-05 |
+| 1.1.1 | State the leader share of the epoch settlement, plus the epoch's Execution priority fees. | 2026-08-27 |
# Introduction
@@ -52,7 +53,7 @@ Key properties of the protocol:
- **Anonymity**: Block rewards are unlinkable to the blocks they originate from (avoiding deanonymization).
- **Soundness**: No reward can be claimed twice.
-In parallel, the blockchain maintains the value `leaders_rewards` accumulating the rewards for leaders over time. Each voucher included in the Merkle tree represents the same share of `leaders_rewards`. Just like for voucher inclusion, more rewards are added to this variable on an epoch-by-epoch basis, which guarantees a stable and equal claimable reward for leaders over an epoch.
+In parallel, the blockchain maintains the value `leaders_rewards` accumulating the rewards for leaders over time. Two streams credit it, both epoch by epoch: the leader share $`\Pi^{leader}_e`$ of the epoch settlement defined in [Block Rewards](block-rewards.md), which is 40% of the pooled Execution base fees, Permanent Storage fees and reserve release; and the Execution priority fees of the epoch in full, which take no Blend share (cf. [Execution Market](execution-market.md)). Each voucher included in the Merkle tree represents the same share of `leaders_rewards`. Just like for voucher inclusion, more rewards are added to this variable on an epoch-by-epoch basis, which guarantees a stable and equal claimable reward for leaders over an epoch.
# Protocol
@@ -84,11 +85,11 @@ This Operation increases the balance of a Mantle Transaction by the leader rewar
This means that a leader may use their funds directly, getting their reward and using them atomically.
-Note that every leader will receive a reward that is independent of the block content to avoid de-anonymization. This means that the fees of the block cannot be collected by the leader directly, or need to be pooled for all the leaders.
+Note that every leader will receive a reward that is independent of the block content to avoid de-anonymization. This means that the fees of the block cannot be collected by the leader directly, and are pooled for all the leaders instead. This applies to the priority fee as much as to the base fee: paying a tip to the proposer in its own block would tie the amount received to that block's contents and defeat the unlinkability this protocol provides.
### Leaders Reward
-At the start of epoch **N+1**, validators aggregate the leaders rewards of epoch **N** into the leader rewards variable. The amount of the reward claimable with a voucher corresponds to a share of the `leaders_rewards`. This share is equal to the total value of rewards divided by the size of the anonymity set of leaders, rounded down, that is:
+At the start of epoch **N+1**, validators aggregate the leaders rewards of epoch **N**, that is $`\Pi^{leader}_N`$ together with the Execution priority fees of that epoch, into the leader rewards variable. The amount of the reward claimable with a voucher corresponds to a share of the `leaders_rewards`. This share is equal to the total value of rewards divided by the size of the anonymity set of leaders, rounded down, that is:
$$
share = \begin{cases}
diff --git a/docs/blockchain/raw/block-rewards.md b/docs/blockchain/raw/block-rewards.md
index 8d87e0dc0..7d5c19218 100644
--- a/docs/blockchain/raw/block-rewards.md
+++ b/docs/blockchain/raw/block-rewards.md
@@ -21,8 +21,9 @@
| Version | Changes | Date |
| --- | --- | --- |
-| 1.0.0 | Initial revision. | 2026-04-24 |
-| 1.1.0 | Changing from burning/minting to pooling/distributing/releasing, removing $`S_{tge}`$ | 2026-08-25 |
+| 1.0.0 | Initial revision. | 2026-08-12 |
+| 1.1.0 | Changing from burning/minting to pooling/distributing/releasing, removing $S_{tge}$ | 2026-06-22 |
+| 1.2.0 | Block reward redefined as $`R_t = R^{\text{block}}_t + A_t c`$. Fee cap, fee split and excess capture removed; the reserve throttle removed and replaced by a solvency clamp. | 2026-08-23 |
> Disclaimer:
> This material, including any linked pages or documents, is provided for informational purposes only. It does not constitute investment advice, a solicitation, or an offer to buy or sell any securities, tokens, or other financial instruments, nor should it be construed as legal, financial, or tax advice.
@@ -33,529 +34,467 @@
# Introduction
-This document outlines the specifications for Logos Blockchain's block rewards mechanism, a critical component of the network's economic model. The mechanism is designed to create a sustainable economic framework that incentivizes network participation while maintaining long-term stability.
+This document specifies the block reward mechanism of Logos Blockchain: the amount of tokens paid at each block, the source of those tokens, and the state transitions the mechanism applies to the token stocks it controls.
-The objective is to develop a block rewards system that addresses key challenges specific to Logos Blockchain's architecture, including the unlinkability between block proposal and reward collection, and the inability to directly allocate transaction fees to specific block proposers. These constraints necessitate a carefully designed economic incentive structure.
+The objective is a block reward that pays for security while the network is establishing it, and that hands the job to transaction fees as the network grows into them. The mechanism must remain defined when the pre-allocated reserve is close to exhausted while the security target is still unmet.
-Building on previous work in blockchain economics, this specification proposes a dynamic token emission system that calibrates the release of the LGO genesis minted reserve according to network Key Performance Indicators (KPIs). The system uses two primary metrics: inferred total stake (as a security indicator) and average pooling rate (to maintain supply equilibrium).
+The design holds the token supply fixed. Block rewards are not minted. The fee component is recycled from the fees the block itself collected, the released component is drawn from a reserve allocated at genesis out of the hard cap, and the three stocks the mechanism controls sum to a constant at every block. Emission into circulation is bounded per block and per year, in every state and at any fee level.
-The document references internal mathematical models and simulations that demonstrate how the proposed mechanism would behave under various conditions. Key parameters include maximum annual emission rate ($1\%$), control responsiveness factors, and target metrics for network security.
+The released component is anchored to one measured indicator, the inferred total stake, compared against a target. A block height tracks time but says nothing about chain state, and a per-transaction count is manipulable by the proposer. The release depends on nothing else. Fee revenue passes through the mechanism to the recipients without altering it, and the reserve balance enters only at the solvency boundary, where it bounds what can be released.
-The conclusion of our analysis indicates that this KPI-based emission model should achieve several important outcomes:
+Fee computation and stake inference are out of scope. Refer to [Execution Market](execution-market.md) and [Storage Markets](storage-markets.md) for the fee amount, and to [Total Stake Inference](cryptarchia-total-stake-inference.md) for the stake estimate. Distribution to individual recipients is also out of scope. Refer to [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md) for how the leader share is held and claimed, and to [Blend Protocol](blend-protocol.md) and [Service Reward Distribution Protocol](bedrock-service-reward-distribution.md) for the Blend share. This document only defines the amount transferred at each epoch boundary and its split between the two recipient classes. The Execution priority fee is outside that amount. It is routed in full to the leader class through the leader reward accumulator of the [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md).
-- Initially higher emission rates from the reserve (capped at $`1\%`$ of the max supply annually) to bootstrap network participation.
-- Gradual stabilization of token supply as the system matures, with our baseline simulation showing just $`1.33\%`$ total inflation after $`10`$ years.
-- Self-regulating mechanism where the reserve release naturally adjusts to complement pooled transaction fees.
-- Built-in safeguards against manipulation through moving averages and bounded functions.
-
-This specification represents a comprehensive approach to creating a robust economic foundation for the Logos Blockchain network that balances security requirements with long-term economic sustainability.
+The properties this mechanism satisfies, its behaviour across the range of its state variables, the incentives it creates, its failure modes, and the trade-offs taken are derived in [\[Analysis\] Block Rewards](analysis_block_rewards_specs.md), revised to 1.1.0 alongside this document. Results proved there are referenced from this document by the labels P for derived properties, S for scenarios, I for incentive results, and F for failure modes. That document also records which results of revision 1.0.0 were replaced, reversed or withdrawn by this revision.
# Overview
-The Logos Blockchain block rewards mechanism is a KPI-based dynamic token emission system designed to create a sustainable economic framework that incentivizes network participation while maintaining long-term stability. This section provides a high-level understanding of how the system works and its key components.
+## Terminology
+
+The word "reward" denotes three distinct quantities in this document. Each is named explicitly wherever it appears to avoid misinterpretation.
+
+| Term | Symbol | Definition |
+| --- | --- | --- |
+| Block reward | $`R_t`$ | The total amount accrued at block $`t`$. The outcome of the mechanism, and the sum of the two quantities below. |
+| Block fees | $`R^{\text{block}}_t`$ | The gross Execution base fees and Permanent Storage fees collected in block $`t`$, passed through in full. Execution priority fees are excluded. |
+| Released rewards | $`\iota_t`$ | The part drawn from the reserve pool, which is allocated at genesis out of the hard cap. |
+
+$$
+R_t = R^{\text{block}}_t + \iota_t.
+$$
+
+The distinction is economic, and it is also a difference in provenance. Block fees move from circulation into the rewards pool directly, recycling tokens the block itself collected. Released rewards move from the reserve pool into the rewards pool, drawing down an allocation made at genesis and expanding the circulating supply. The two components arrive at the same destination along different edges, as Figure 1 shows.
+
+Neither component creates tokens, which is why [Derived Property P1](analysis_new_block_rewards_specs.md#p1-conservation) holds.
+
+Two neighbouring terms are not rewards:
+
+* The **reserve pool** $`B_t`$ is the account that funds released rewards. It is allocated at genesis, has no inflow and exactly one outflow, so its balance moves by $`\Delta B_t = -\iota_t`$ and is non-increasing for the life of the chain.
+* The **rewards pool** $`P_t`$ is the account in which block rewards accrue within an epoch before settlement. It receives both components of $`R_t`$ and pays out only at an epoch boundary.
## Key Principles
-The design of the rewards system reflects three architectural constraints unique to Logos Blockchain:
+Four architectural constraints of Logos Blockchain determine the shape of the mechanism.
-- Unlinkability: Block proposal and reward collection are intentionally decoupled for privacy, meaning rewards cannot be assigned to a single proposer.
-- Fee pooling: All transaction fees (execution base fees and permanent storage fees) are collected into a pending rewards pool, rather than directly given to block proposers.
-- Global metrics over local signals: Rewards are computed from network-wide KPIs at block production time, rather than from easily manipulated per-block data.
+- **Unlinkability.** Block proposal and reward collection are decoupled, so a block reward cannot be assigned to an identified proposer.
+- **Fee pooling.** Transaction fees are routed to a protocol account rather than paid directly to a proposer.
+- **Global metrics.** The block reward is a function of network-wide state observable at block production time, not of proposer-local or single-transaction data.
+- **Epoch settlement.** Block rewards are computed per block but paid per epoch. The amount owed accrues over the blocks of an epoch and is transferred at the epoch boundary to the distribution protocols, which pay individual recipients.
-These principles ensure that the system is censorship-resistant, manipulation-resistant, and aligned with long-term network incentives.
+The block reward is therefore an obligation accrued at block time and discharged at epoch time. The two schedules are distinct and the specification treats them separately.
## Requirements
-Building upon the requirements for Logos Blockchain's block rewards system, the implementation will establish that all transaction fees are pooled while block rewards are tied to measurable global metrics that reflect network health and security. This mechanism ensures that if network activity surges substantially, the accelerated pooling of tokens will be balanced by complementary distribution from the reserve over time.
+The mechanism is specified to satisfy the following requirements. Each is discharged by a numbered result in [\[Analysis\] Block Rewards](analysis_new_block_rewards_specs.md). The requirement is normative here; the proof that the mechanism meets it is in that document.
-For optimal functionality, block rewards should be anchored to specific observable metrics rather than arbitrary values. Block numbers simply track time passage without indicating chain state. Transaction counts per block are vulnerable to manipulation. On the other hand, tracking the number of Blend nodes or inferring total stake provide more robust information about the chain state, specially when they can be compared with targets that are considered “healthy”.
+| | Requirement | Discharged by |
+| --- | --- | --- |
+| R1 | The token supply is fixed. The mechanism never mints. The stocks it controls are conserved under every state transition. | [Derived Property P1](analysis_new_block_rewards_specs.md#p1-conservation) |
+| R2 | The released component responds to measured network state instead of elapsed time. A larger deviation of the key performance indicator from its target produces a larger draw on the pre-allocated reserve. | [Key Performance Indicator](#key-performance-indicator), [Security Controller](#security-controller) |
+| R3 | Released rewards are strictly positive whenever the security shortfall is positive **and the reserve is non-empty**. | [Derived Property P3](analysis_new_block_rewards_specs.md#p3-block-reward-bounds-and-monotonicity), scoped by [Derived Property P7](analysis_new_block_rewards_specs.md#p7-the-reserve-reaches-zero-in-finite-time) |
+| R4 | The block reward is a continuous function of the state. No threshold produces a jump in the amount paid. | [Derived Property P6](analysis_new_block_rewards_specs.md#p6-the-reserve-pool-covers-every-released-reward) |
+| R5 | Gross emission into circulation is bounded per block and per year, in every state, independently of fee revenue. | [Derived Property P3](analysis_new_block_rewards_specs.md#p3-block-reward-bounds-and-monotonicity) |
+| R6 | No stock accumulates without a release rule. Any token withheld from a block reward is held in an account the mechanism can later draw on. | [Derived Property P2](analysis_new_block_rewards_specs.md#p2-the-rewards-pool-accrues-within-an-epoch-and-discharges-at-the-boundary) |
+| R7 | No participant profits from inflating the fees in a block. | [Incentive Analysis I1](analysis_new_block_rewards_specs.md#i1-inflating-fees-is-not-profitable-but-is-no-longer-bounded-in-effect). Weakened relative to revision 1.0.0; see [Open Items](#open-items). |
+| R8 | The consensus rule is integer-valued and deterministic across nodes. | [Float Precision for Implementation](#float-precision-for-implementation) |
+| R9 | The obligation accrued over an epoch is discharged in full at the epoch boundary. The rewards pool retains no balance across epochs. | [Derived Property P2](analysis_new_block_rewards_specs.md#p2-the-rewards-pool-accrues-within-an-epoch-and-discharges-at-the-boundary) |
+
+R3 is the requirement this revision satisfies only over a bounded horizon. The reserve has no inflow, so a shortfall that persists long enough exhausts it and the released component goes to zero permanently. R3 is therefore a statement about the reserve's lifetime, not about all future states.
-Crucially, any metric-pegged reward system should aim toward a target value or equilibrium point, creating predictability and stability in the token economics.
+R9 separates accrual from payment. Without it the rewards pool balance would be a free variable and the conservation argument would not close at any single point in time.
## High-level System Design
-The system dynamically adjusts token emission based on two primary KPIs:
+The mechanism controls three token stocks:
-- Inferred Total Stake: Measures network security by tracking the total amount staked against a target threshold (e.g., $`30\%`$ of the maximum supply).
-- Average Pooling Rate: Tracks transaction fees (both Execution base fees and Permanent Storage) routed to the pending reward pool to maintain supply equilibrium.
+* the circulating supply $`S_t`$,
+* a reserve pool $`B_t`$ allocated at genesis, and
+* a rewards pool $`P_t`$ that accrues the obligation within an epoch.
-A control function combines these KPIs to determine the emission rate factor, bounded between a minimum and maximum annual reserve release. This ensures that:
+Every block, the block's Execution base fees and Permanent Storage fees move in full from circulation into the rewards pool, and the reserve pool releases $`\iota_t`$ into the rewards pool. At each epoch boundary the rewards pool is emptied into the distribution protocols. These are the only flows this mechanism applies, so $`S_t + P_t + B_t`$ is invariant under them. The Execution priority fee moves along a separate edge, from the payer to the leader reward accumulator.
-- When security participation is below target, a higher reserve release attracts more validators.
-- As usage increases and fees are pooled, the reserve release adjusts downward and distribution from the pool rises to stabilize circulating supply.
+
-
+> Figure 1. Token flows. Every edge is a transfer between existing stocks. Flows 1 and 2 occur at every block; flow 3 occurs only at an epoch boundary, when the rewards pool is emptied. The reserve pool has no inflow.
-The equation that defines the amount of block rewards is given by:
+The amount accrued at block $`t`$ is
$$
-A_t \cdot \dfrac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f} + (1-A_t) \cdot \bar{R}_t
+R_t = R^{\text{block}}_t + A_t \cdot c ,
$$
-where:
+the block's fees in full, plus a release from the reserve sized only by the security state:
+
+- $`c = I_{max} S_{cap} \Delta_t / f`$ is the per-block release cap. It is the maximum draw on the reserve in one block, and it annualizes to $`I_{max} S_{cap}`$.
+- $`A_t \in [0,1]`$ is the security controller. It responds to the shortfall of inferred total stake against target and to nothing else.
-- $`A_t`$ is the emission rate factor on a per year basis.
-- $`I_{max}`$ is the maximum emission rate per year.
-- $`S_{cap}`$ denotes the maximum allowable token supply (hard cap).
-- $`\Delta_t`$ denotes the fraction of year in one time step per e.g., epoch, block, or day.
-- $`f`$ be the average number of block proposal within $`\Delta_{t}`$ units.
-- $`R_\text{block}`$ denotes the total amount of Execution base fees and Permanent Storage fees that are routed to the pending reward pool when the block is proposed.
-- $`\bar{R}_t`$ denotes the average pooled reward: the moving average of $`R_\text{block}`$ over the look-back window $`T`$.
+The two components are independent. Fees do not displace the release, and the release does not depend on fees. The mechanism is a fee pass-through plus a stake-driven subsidy.
## Lifecycle Phases
-The system is designed to evolve through different phases:
+Let $`\theta_t`$ denote the security level. The regimes are keyed on $`\theta_t`$ and on the reserve balance. Fee revenue no longer selects a regime; it scales the reward within one. Each is evaluated in full in [Scenario Analysis](analysis_new_block_rewards_specs.md#scenario-analysis).
-- Bootstrap Phase: Initially higher emission rates (up to $`1\%`$ annually) to incentivize network participation when stake is below target. As it is explained below, this is viable even when Logos Blockchain experiences low activity because the level of activity only plays a role when the network participation gets close to the predefined target.
-- Stabilization Phase: As Proof-of-Stake (PoS) participation approaches target levels, emission becomes primarily driven by the fee pooling rate.
-- Equilibrium Phase: Circulating supply stabilizes as distribution from the pool matches pooled fees and the reserve release approaches zero.
-- High-Adoption Phase: If the fee pooling rate exceeds the maximum reserve release rate, circulating supply contracts as the pool accumulates faster than tokens are released. Total supply is unchanged.
+- **Bootstrap.** $`\theta_t \le 25\%`$, so $`A_t = 1`$. The release is at $`c`$ every block, the reserve drains at its maximum rate, and the staking yield against a small base is high. [Scenario S1](analysis_new_block_rewards_specs.md#s1-bootstrap)
+- **Stabilization.** $`\theta_t \in (25\%, 30\%)`$. $`A_t`$ falls linearly with the shortfall, the release shrinks, and a growing share of the block reward is fees. [Scenario S3](analysis_new_block_rewards_specs.md#s3-proportional-band)
+- **Self-sustaining.** $`\theta_t \ge 30\%`$, so $`A_t = 0`$. Nothing is released, the reward is fees alone, and the reserve is frozen at its current balance rather than drained. The mechanism spends the reserve only in the states that call for it. [Scenario S2](analysis_new_block_rewards_specs.md#s2-target-reached-no-usage), [Scenario S4](analysis_new_block_rewards_specs.md#s4-high-adoption)
+- **Terminal.** $`B_{t-1} = 0`$. The reserve is spent and the reward is fees alone from that block onward, whatever the security state. This state is absorbing: there is no inflow that can restore the reserve. [Scenario S5](analysis_new_block_rewards_specs.md#s5-depleted-reserve-security-below-target), [Failure Mode F1](analysis_new_block_rewards_specs.md#f1-terminal-reserve-exhaustion-and-the-yield-cliff)
-## Benefits
+The self-sustaining regime is reversible and the terminal regime is not. The difference between them is the subject of [Reserve Horizon and Terminal State](#reserve-horizon-and-terminal-state).
-This KPI-based approach delivers several advantages:
+## Properties
-- Self-regulating mechanism that automatically adjusts to network conditions.
-- Long-term sustainability with projected net circulating-supply growth of just $`1.33\%`$ after $`10`$ years (assuming constant pooling rate of $`0.5\%`$ per year).
-- Built-in safeguards against manipulation through moving averages and bounded functions.
-- Predictable economic model that balances security incentives with controlled supply.
+Each claim below is a result proved in the analysis document.
-The overall design creates a robust economic foundation for the Logos Blockchain blockchain that effectively balances the need for strong security incentives with long-term token supply stability.
+- **Conservation.** $`S_t + P_t + B_t`$ is invariant at every block. The mechanism never mints. [Derived Property P1](analysis_new_block_rewards_specs.md#p1-conservation)
+- **Epoch discharge.** The rewards pool accrues within an epoch and returns to zero at the boundary. [Derived Property P2](analysis_new_block_rewards_specs.md#p2-the-rewards-pool-accrues-within-an-epoch-and-discharges-at-the-boundary)
+- **Bounded emission.** Released rewards are at most $`c`$ per block, that is $`I_{max} S_{cap}`$ per year, in every state and at any fee level. The bound is unconditional on fees rather than mediated by the fee gap. [Derived Property P3](analysis_new_block_rewards_specs.md#p3-block-reward-bounds-and-monotonicity)
+- **Unbounded block reward.** $`R_t`$ has no upper bound, since it contains the block's fees uncapped. The bound of revision 1.0.0, $`R_t \le c`$, no longer holds and must not be assumed by downstream protocols. [Derived Property P3](analysis_new_block_rewards_specs.md#p3-block-reward-bounds-and-monotonicity), [Failure Mode F5](analysis_new_block_rewards_specs.md#f5-the-settled-reward-is-no-longer-a-bounded-signal)
+- **Separability.** The fee component and the released component are additively separable, with zero cross-partial. Fee revenue neither displaces nor triggers a release. [Derived Property P4](analysis_new_block_rewards_specs.md#p4-the-two-components-are-additively-separable)
+- **Monotone supply.** Circulating supply is non-decreasing epoch over epoch, and strictly increasing whenever $`A_t > 0`$ over the epoch. The contraction regime of revision 1.0.0 does not exist. [Derived Property P5](analysis_new_block_rewards_specs.md#p5-closed-form-for-the-stock-dynamics)
+- **Reserve solvency.** Released rewards never exceed the reserve pool balance, by the clamp in equation (2). [Derived Property P6](analysis_new_block_rewards_specs.md#p6-the-reserve-pool-covers-every-released-reward)
+- **Finite reserve horizon.** The reserve reaches zero in finite time under a persistent shortfall, and the terminal state is absorbing. [Derived Property P7](analysis_new_block_rewards_specs.md#p7-the-reserve-reaches-zero-in-finite-time), [Derived Property P8](analysis_new_block_rewards_specs.md#p8-reserve-horizon)
+- **Manipulation resistance.** Inflating the fees in a block is never profitable for a participant whose combined share of the epoch settlement is below one. The per-block absolute bound of revision 1.0.0 is gone; the recovered fraction is now constant in the fee paid. [Incentive Analysis I1](analysis_new_block_rewards_specs.md#i1-inflating-fees-is-not-profitable-but-is-no-longer-bounded-in-effect)
+- **Minimal consensus state.** The rule reads the reserve pool balance, the stake estimate, the block's fees, the rewards pool balance and the epoch position. No fee window or history is maintained.
# Construction
-The proposed mechanism implements a dynamic token emission system that precisely calibrates the LGO reserve release according to network performance metrics (KPIs). This adaptive model adjusts release rates based on how KPIs perform relative to their predetermined targets, while maintaining strict adherence to supply parameters and economic boundaries.
-
## Core Variables
-The following variables are input to the model:
-
-- $`S_{cap}`$ denotes the maximum allowable token supply (hard cap).
-- $`\Delta_t`$ denotes the fraction of year in one time step per e.g., epoch, block, or day:
- - if the time step is 1 day, then $`\Delta_t = 1/365`$.
- - if the time step is 1 block every $30$ seconds, then $`\Delta_t = 1/(365 \times 2880)`$.
- - if the time step is 1 epoch, which lasts 7.5 days, then $`\Delta_t = 1/(365/7.5) = 1/48.667`$.
-- $f$ be the average number of block proposal within $`\Delta_{t}`$ units:
- - if the time step is 1 day and blocks are proposed every 30 seconds, then $f=2880$ (the number of 30 seconds intervals in 1 day).
- - if the time step is 1 epoch, which lasts 7.5 days, and blocks are processed every 30 seconds, then $f = 7.5 \times 2880 = 21600$ (the number of 30 seconds intervals in 7.5 day).
-- $`I_{min}`$ is the minimum emission rate per year ($`I_{min} = 0\%`$ of $`S_{cap}`$).
-- $`I_{max}`$ is the maximum emission rate per year ($`I_{min} = 1\%`$ of $`S_{cap}`$).
-- $`Y`$ denotes the lifetime, in years, of the rewards reserve at the maximum release rate $`I_{max}`$ of $`S_{cap}`$ per year ($`Y = 10`$ years).
-- $`D_{i,target}`$ denotes the target value for the $i$-th KPI.
-- $`w_i`$ denotes the weight of the $i$-th KPI in the normalized deviation from target or in the normalized average; it satisfies $`\sum_i w_i = 1`$.
-- $`\alpha_d \gt 0`$ denotes the control responsiveness to KPI deviation metrics.
-- $`\alpha_a \gt 0`$ denotes the control responsiveness to KPI average metrics.
-- $T$ be the number of periods in the look-back window for the moving average.
-
-Let us define the following variables:
-
-- $`S_t`$ denotes the token circulating supply at time $t$.
-- $`P_t`$ denotes the pending rewards pool balance at time $t$. It collects the pooled fees and funds the distributed portion of the reward.
-- $`B_t`$ denotes the rewards reserve balance at time $t$. It holds the pre-allocated tokens drawn down by the reserve release, with initial size $`B_0 = I_{max} \cdot S_{cap} \cdot Y`$.
-- $`A_t \in [0,1]`$ denotes the emission rate factor on a per year basis.
- - This implies that $`A_t \cdot I_{max} \cdot \Delta_t`$ denotes the emission within the time-step.
-- $`D_{i,t}`$ denotes the $i$-th key performance indicator at time $t$ (e.g., TVL, staked amount, active users).
-- $`R_\text{block}`$ denotes the total amount of Execution Gas and Permanent Storage fees routed to the rewards pool in a block. Refer to [Execution Market](execution-market.md) and [Storage Markets](storage-markets.md) for how to compute $`R_{block}`$.
-- $`\bar{R}_t = \dfrac{1}{T} \sum_{\tau=t-T+1}^{t} D_{1,\tau}`$ denotes the average pooled reward: the moving average of $`R_\text{block}`$ over the look-back window $`T`$. It is the base distributed each block, topped up by the reserve release.
-
-## Parametrization
-
-| Symbol | Definition | Default Value | Explanation |
-| --- | --- | --- | --- |
-| $`S_{cap}`$ | Maximum token supply (hard cap) | 10 billion LGO | N.A. |
-| $T$ | The number of periods in the look-back window for the moving average. | $`120`$ | As the system is expected to produce 1 block every 30 seconds, this look-back window defines that the reward averages the fees pooled in the last hour. |
-| $`\alpha_a`$ | Denotes the control responsiveness to KPI average metrics. | $`1`$ | This parameter scales the reserve-release response to the pooling rate. It must be one-to-one. |
-| $`\alpha_d`$ | Denotes the control responsiveness to KPI deviation metrics. | $`1/4`$ | See [\[Analysis\] Block Reward Parameter Calibration](analysis-block-reward-parameter-calibration.md), for details. |
-| $`w_i`$ | Denotes the weight of the $i$-th KPI in the normalized deviation from target | $`1`$ | There's only one KPI of this type in our system. |
-| $`D_{0,target}`$ | Denotes the target value for the first KPI based on stake. | 3 billion LOGOS | $`30\%`$ of the maximum supply. |
-| $`D_{1,target}`$ | Denotes the target value for the second KPI based on fees. | $10$ billon LOGOS | In the context of this KPI, this value behaves as a normalizer |
-| $`I_{max}`$ | The maximum emission rate per year | $1\%$ | This value guarantees that, when the total inferred stake reaches $`D_{0,target}`$, then the APY for validation is ~3.33%. |
-| $`Y`$ | Lifetime of the rewards reserve at the maximum release rate ($`I_{max}`$ of $`S_{cap}`$ per year) | $`10`$ years | Sets the reserve size $`B_0 = I_{max} \cdot S_{cap} \cdot Y = 10^9`$ LGO ($10\%$ of $`S_{cap}`$). |
-| $`I_{min}`$ | The minimum emission rate per year | $`0\%`$ | This avoids inflationary token emissions. |
-| $f$ | The average number of block proposal within $`\Delta_{t}`$ units | $1$ | The time step $`\Delta_t`$ was chosen so that $`f`$ equals to $`1`$. |
-| $`\Delta_t`$ | Time step, the fraction of year in one time step (per e.g., epoch, block, or day) | $`1/(365 \times 2880)`$ | The time step is 1 block every $`30`$ seconds; there are 2880 blocks of 30 seconds in a day. |
-
-The calibration of these parameters can be found in [\[Analysis\] Block Reward Parameter Calibration](analysis-block-reward-parameter-calibration.md).
-
-## Block Rewards
-
-The amount of tokens rewarded in a block is anchored on the average pooled fees and topped up by the reserve release. The emission rate factor $`A_t`$ sets the size of the top-up: it controls how much of the reward is newly released and how much is the recycled average of pooled fees. The following behavior is expected:
+### Protocol constants
-- When the aggregate KPI is far from the target, $`A_t \rightarrow 1`$, the reserve release is maximized: it tops up the average pooled reward $`\bar{R}_t`$, raising the reward toward the per-block release cap $`\frac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f}`$.
-- When the aggregate KPI is close to the target, $`A_t \rightarrow 0`$, the top-up vanishes and the reward settles at the average pooled fees $`\bar{R}_t`$, funded by recycling the pooled fees to leaders and Blend nodes.
+- $`S_{cap}`$ is the maximum allowable token supply (hard cap).
+- $`\Delta_t`$ is the fraction of a year in one time step.
+- $`f`$ is the average number of block proposals within $`\Delta_t`$.
+- $`L`$ is the number of blocks in an epoch.
+- $`I_{max}`$ is the maximum annual release rate, expressed as a fraction of $`S_{cap}`$.
+- $`Y`$ is the lifetime, in years, of the reserve at release rate $`I_{max}`$.
+- $`D_{target}`$ is the target inferred total stake.
+- $`\Lambda`$ is the stake shortfall at which the security controller saturates, in tokens. Equivalently $`\delta^\ast = \Lambda / D_{target}`$, the same threshold as a normalized deviation.
+- $`B_0 = I_{max} \cdot S_{cap} \cdot Y`$ is the initial reserve, allocated at genesis from $`S_{cap}`$.
+- $`c`$ is the per-block release cap, in tokens.
-The reserve release within the time step $`\Delta_t`$ is given by
+The per-block release cap $`c`$ is derived as:
$$
-A_t \cdot I_{max} \cdot S_{cap} \cdot \Delta_t.
+c = \frac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f} .
$$
-The actual amount of tokens released from the reserve per block also depends on how many blocks are expected to be proposed between $`\Delta_{t-1}`$ and $`\Delta_{t}`$. This is expressed by the factor $f$, as defined [above](#core-variables).
+$`c`$ has a single role in this revision: it is the maximum draw on the reserve in one block. It is not applied to fees.
-The equation that implements the behavior above in terms of $`A_t`$ is given by:
+Its calibration is a yield statement, but the reference base is the saturation boundary and not the target. The release is at $`c`$ only while $`A_t = 1`$, that is while $`D_t \le D_{target} - \Lambda`$. At $`D_t = D_{target}`$ the controller is zero, nothing is released, and the block reward is pure fee recycling, so no release-funded yield can be quoted there at all. The largest staked base still receiving the full release is therefore $`D_{target} - \Lambda`$, and over the saturated region the release-funded annual yield is
$$
-\begin{equation}
-R_t = A_t \cdot \dfrac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f} + (1-A_t) \cdot \bar{R}_t
-\end{equation}
+r^{\iota}(D_t) = \frac{I_{max} S_{cap}}{D_t} \;\ge\; \frac{I_{max} S_{cap}}{D_{target} - \Lambda} ,
$$
-where:
+which at the adopted parameters is at least $`4.0\%`$, on a base of $`2.5 \cdot 10^9`$ LGO, and rises without bound as the staked base falls. Across the proportional band the release-funded yield is $`A_t I_{max} S_{cap} / D_t`$, which falls monotonically from $`4.0\%`$ at $`\theta = 25\%`$ to zero at $`\theta = 30\%`$. [Failure Mode F1](analysis_new_block_rewards_specs.md#f1-terminal-reserve-exhaustion-and-the-yield-cliff) tabulates $`r^{\iota}`$ across the range.
-- $`A_t`$ is the emission rate factor on a per year basis.
-- $`I_{max}`$ is the maximum emission rate per year.
-- $`S_{cap}`$ denotes the maximum allowable token supply (hard cap).
-- $`\Delta_t`$ denotes the fraction of year in one time step per e.g., epoch, block, or day.
-- $f$ be the average number of block proposal within $`\Delta_{t}`$ units.
-- $`R_\text{block} = D_{1,t}`$ denotes the per-block Execution base fees and Storage fees collected in the block and routed to the pending reward pool when the block is proposed.
-- $`\bar{R}_t = \dfrac{1}{T} \sum_{\tau=t-T+1}^{t} D_{1,\tau}`$ denotes the average pooled reward: the moving average of $`R_\text{block}`$ over the look-back window $`T`$.
+Epochs are indexed by $`e`$, and epoch $`e`$ spans the blocks $`t \in (T_{e-1}, T_e]`$ with $`T_e = e L`$.
-The recycled component distributes the average pooled reward $`\bar{R}_t`$, rather than the single-block fee $`R_\text{block}`$, which smooths it across the window $`T`$. Rearranging equation (1) isolates the role of the reserve release:
+Under a leader lottery the realized block count in an epoch is a random variable and $`L`$ is its expected value. The block reward accrues per block, so the amount settled at a boundary scales with the realized count. The annualized figures in this document assume the expected rate.
-$$
-\bar{R}_t + A_t \cdot \left( \dfrac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f} - \bar{R}_t \right).
-$$
+### State
-The base distributed every block is the average pooled fees $`\bar{R}_t`$. The second term is the reserve release: when the aggregate KPI is far from the target, $`A_t \rightarrow 1`$ and the reserve release tops up the reward from $`\bar{R}_t`$ toward the per-block release cap $`\frac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f}`$. In the bootstrap regime, where activity is low and $`\bar{R}_t < \frac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f}`$, the top-up is positive, so the reserve release raises the reward above the average pooled fees. If the average pooled fees already exceeds the release cap, the second term is non-positive, and therefore less tokens are released from the average pooled fees as rewards.
+- $`S_t`$ is the circulating supply.
+- $`B_t`$ is the reserve pool balance. It funds every released reward and receives nothing.
+- $`P_t`$ is the rewards pool balance. It accrues the block reward obligation within an epoch and is emptied at the boundary.
+- $`D_t`$ is the inferred total stake at time $`t`$, the key performance indicator.
+- $`R^{\text{block}}_t`$ is the gross amount of Execution base fees and Permanent Storage fees collected in block $`t`$. Execution priority fees are not included.
-```python
-def block_rewards(
- S_cap: float,
- emission_rate_factor: float,
- I_max: float,
- Delta_t: float,
- f: float,
- R_bar_t: float,
-) -> float:
- """
- Calculate the rewards distributed per block. It implements equation (1).
- """
- reserve_release = emission_rate_factor * I_max * S_cap * Delta_t / f
- pool_distribution = (1.0 - emission_rate_factor) * R_bar_t
- return reserve_release + pool_distribution
-```
+Consensus state read by this mechanism is $`(B_{t-1}, D_t, R^{\text{block}}_t)`$ to compute the block reward, and $`(P_{t-1}, t \bmod L)`$ to accrue and settle it. No window or fee history is required.
-## Pool Accounting and Supply Dynamics
+### Derived quantities
-The mechanism routes all transaction fees into a rewards pool. Let $`P_t`$ denote the pool balance at time $t$ and $`\bar{R}_t = \frac{1}{T}\sum_{\tau=t-T+1}^{t} D_{1,\tau}`$ the average pooled reward over the look-back window. Each block routes its fees into the pool and distributes the average pooled reward, recycled in proportion $`(1 - A_t)`$. The distribution is topped up by a release from a rewards reserve, not by minting: the reserve holds tokens pre-allocated from the fixed cap $`S_{cap}`$ at genesis. It is sized so that releasing at the maximum rate $`I_{max}`$ of $`S_{cap}`$ per year lasts $`Y`$ years, giving an initial balance $`B_0 = I_{max} \cdot S_{cap} \cdot Y`$.
+- $`\delta_t`$ is the normalized deviation of the key performance indicator from its target.
+- $`A_t \in [0,1]`$ is the security controller.
+- $`\iota_t = \min \lbrace A_t c, \; B_{t-1} \rbrace`$ is the released rewards, the part of the block reward drawn from the reserve.
+- $`R_t = R^{\text{block}}_t + \iota_t`$ is the block reward, accrued at block $`t`$ into $`P_t`$.
+- $`\Pi_e`$ is the epoch settlement amount, the total transferred to the distribution protocols at the boundary $`T_e`$.
-The inflows and the outflow at step $t$ are:
+## Parametrization
-- Fee inflow: $`R_\text{block} = D_{1,t}`$.
-- Reserve release (top-up): $`\iota_t = \min \lbrace A_t \cdot \dfrac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f}, \; B_{t-1} \rbrace`$, drawn from the reserve and added to the payout.
-- Distribution outflow, equal to the block reward: $`R_t = (1 - A_t) \cdot \bar{R}_t + \iota_t`$.
+| Symbol | Definition | Value | Basis |
+| --- | --- | --- | --- |
+| $`S_{cap}`$ | Maximum token supply | $`10^{10}`$ LGO | Hard cap. |
+| $`I_{max}`$ | Maximum annual release rate | $`1\%`$ | Sets the release-funded yield floor over the saturated region at $`I_{max} S_{cap} / (D_{target} - \Lambda) = 4.0\%`$, and the reserve at $`B_0 = I_{max} S_{cap} Y`$. Comparable to the annual supply growth of gold. |
+| $`Y`$ | Reserve lifetime at $`I_{max}`$ | $`10`$ years | Sets $`B_0 = 10^9`$ LGO, $`10\%`$ of $`S_{cap}`$. Exact, not nominal: the reserve has no inflow, so $`Y`$ is the calendar lifetime under a saturated controller regardless of fee revenue. |
+| $`\Delta_t`$ | Time step | $`1/(365 \cdot 2880)`$ | One block every 30 seconds. |
+| $`f`$ | Block proposals per time step | $`1`$ | $`\Delta_t`$ chosen so $`f = 1`$. |
+| $`c`$ | Per-block release cap | $`62500/657 \approx 95.129`$ LGO | Derived from the four rows above. |
+| $`D_{target}`$ | Target inferred total stake | $`3 \cdot 10^9`$ LGO | $`\theta_{target} = 30\%`$. Chains with utility exhibit a negative relation between usage and staking ratio, so a target above $`50\%`$ is not appropriate; the lower end of the observed $`30\%`$ to $`50\%`$ band stops the release sooner. |
+| $`\Lambda`$ | Stake shortfall at controller saturation | $`5 \cdot 10^8`$ LGO | Equivalently $`\delta^\ast = \Lambda / D_{target} = 1/6`$, so $`A_t = 1`$ below $`\theta = 25\%`$ and the proportional band runs from there to $`30\%`$. Jointly with $`I_{max}`$ it fixes the release-funded yield floor, since the base at saturation is $`D_{target} - \Lambda`$. See [Open Items](#open-items). |
+| $`L`$ | Blocks per epoch | $`21600`$ | $`7.5`$ days at one block every 30 seconds. Sets the reserve-funded settlement float at $`L c = 2.055 \cdot 10^6`$ LGO, $`0.02\%`$ of $`S_{cap}`$. The fee-funded part of the float is unbounded by the protocol. |
-The reserve funds the release and is monotonically non-increasing, bounded below by zero:
+## Key Performance Indicator
-$$
-B_t = B_{t-1} - \iota_t, \qquad B_t \geq 0.
-$$
+The mechanism uses the inferred total stake as a key performance indicator. It is measured at block production time, compared against a target, and the deviation drives the reserve release.
-Once the reserve is depleted, $`\iota_t = 0`$ and the reward reduces to the recycled component $`(1 - A_t) \cdot \bar{R}_t`$, funded entirely by pooled fees. The cap on $`\iota_t`$ makes the reserve last $`Y`$ years at the maximum release rate, and longer whenever $`A_t < 1`$.
+### Definition
-The pool collects every fee and pays out only the recycled component, so its balance evolves as
+$`D_t`$ denotes the inferred total stake, and $`D_{target}`$ the level considered secure. Refer to [Total Stake Inference](cryptarchia-total-stake-inference.md) for how $`D_t`$ is estimated from the observed rate of occupied slots.
+
+Given the privacy properties of Logos Blockchain, individual stake is not observable, and given a known maximum supply, the inferred total stake is the available indicator of the system's security. The security level is
$$
-P_t = P_{t-1} + R_\text{block} - (1 - A_t) \cdot \bar{R}_t.
+\theta_t = \frac{D_t}{S_{cap}}, \qquad \theta_{target} = \frac{D_{target}}{S_{cap}} .
$$
-The increment $`R_\text{block} - (1 - A_t)\bar{R}_t`$ can take either sign. Near target ($`A_t \rightarrow 0`$) the pool pays the average and banks the difference $`D_{1,t} - \bar{R}_t`$, acting as a buffer that smooths fee fluctuations; far from target ($`A_t \rightarrow 1`$) it retains the full fee while the reserve release carries the reward. The pool is redistributable, subject to $`P_t \geq 0`$.
+### Deviation from Target
-The mechanism conserves tokens across the three stocks it controls. Let the controlled total be $`S_t^{tot} = S_t + P_t + B_t`$, with $`S_t`$ the circulating supply. Per step:
+The mechanism responds to the deviation of the indicator from its target, normalized by the target:
$$
-\Delta S_t = R_t - R_\text{block} = (1 - A_t) \cdot \bar{R}_t + \iota_t - D_{1,t},
+\delta_t = \frac{D_{target} - D_t}{D_{target}} = 1 - \frac{\theta_t}{\theta_{target}} \;\in\; (-\infty, \, 1] .
$$
-$$
-\Delta P_t = R_\text{block} - (1 - A_t) \cdot \bar{R}_t, \qquad \Delta B_t = -\iota_t,
-$$
+- $`\delta_t > 0`$: stake below target. Released rewards are positive, in proportion to $`\delta_t`$.
+- $`\delta_t = 0`$: stake at target. Nothing is released.
+- $`\delta_t < 0`$: stake above target. Nothing is released, and the response is clamped rather than reversed, since the mechanism has no instrument for reducing stake.
-$$
-\Delta S_t^{tot} = \Delta S_t + \Delta P_t + \Delta B_t = 0.
-$$
+At genesis $`D_t`$ is small against the target, so $`\delta_t \rightarrow 1`$ and the response is maximal. As participation grows, $`\delta_t`$ falls toward zero and the block reward converges on the block's fees.
-The controlled total is constant: the mechanism never mints tokens. A reserve release moves tokens from $`B_t`$ into circulation, routing a fee moves tokens from circulation into $`P_t`$, and recycling moves them back. Circulating supply $`S_t`$ rises as the reserve drains, and contracts whenever the fee inflow exceeds the distributed reward, $`D_{1,t} > R_t`$, when tokens accumulate in the pool faster than they are paid out. This removes tokens from circulation, not from existence, and reverses if the pool is later released. Net circulating growth over the reserve's life is bounded by $`B_0 = I_{max} \cdot S_{cap} \cdot Y`$.
+The loop is closed: a larger deviation raises the block reward, a higher block reward raises the staking yield, and a higher yield attracts stake, which reduces the deviation. Fee revenue reinforces the same loop from the other side, since it adds to the yield without displacing the release.
-## Emission Rate Factor Function
+## Security Controller
-The emission rate factor $`A_t \in [0,1]`$ determines the portion of $`I_{max}`$ that should be emitted based on current values of $`\delta_t`$ and $`\gamma_t`$:
+The controller is the normalized deviation of the key performance indicator, saturated at a threshold $`\delta^\ast`$ and clamped below at zero:
$$
-A_t = \min \lbrace 1, \max \lbrace 0, \dfrac{ \alpha_d \cdot \delta_t + \alpha_a \cdot \gamma_t + I_{min}}{I_{max}} \rbrace \rbrace.
+A_t = \min \left\lbrace 1, \; \max \left\lbrace 0, \; \frac{\delta_t}{\delta^\ast} \right\rbrace \right\rbrace , \qquad \delta^\ast = \frac{\Lambda}{D_{target}} .
$$
-where
-
-- $`\alpha_d`$ controls the responsiveness to KPI deviation metrics.
-- $`\delta_t`$ is measuring the KPI deviation from targets.
-- $`\alpha_a`$ controls the responsiveness to KPI average metrics.
-- $`\gamma_t`$ is measuring the KPI average values of over the last $T$ steps.
-- $`I_{min}`$ is the minimum emission rate per year.
-- $`I_{max}`$ is the maximum emission rate per year.
-
-All terms are displayed in annualized form to ease comparison.
-
-```python
-def calculate_emission_rate_factor(
- alpha_dev:float,
- weighted_target_deviation: float,
- alpha_avg:float,
- weighted_avg: float,
- i_min: float = 0.0,
- i_max: float = 0.01
-) -> float:
- """It calculates the current emission rate factor"""
- emission_rate:float = alpha_dev * weighted_target_deviation + alpha_avg * weighted_avg + i_min
- emission_rate_factor:float = emission_rate / i_max
- emission_rate_factor = min(1.0, max(emission_rate_factor, 0.0))
- return emission_rate_factor
-```
-
-### KPI Deviation from Target
-
-The weighted deviation from target
+$`\delta^\ast`$ is the deviation at which the response saturates and $`\Lambda`$ is the same threshold expressed in tokens. The two are one parameter in two units. Substituting $`\delta_t`$ gives the form used by the consensus rule, in which no division by $`D_{target}`$ appears:
$$
-\delta_t = \sum_i w_i \times
-\dfrac{D_{i,target} - D_{i,t}}{D_{i,target}}.
+A_t = \frac{\min \lbrace \Lambda, \; \max \lbrace 0, \; D_{target} - D_t \rbrace \rbrace}{\Lambda} .
$$
-```python
-def weighted_deviation_from_target(
- kpi_weights: List[float],
- kpi_deviations: List[float]
-) -> float:
- """
- Calculate the normalized deviation (delta_t).
- Inputs:
- * kpi_weights: constant list of floats
- * kpi_deviations: for each KPI, it contains the results of "deviation_from_target"
- Returns:
- * a normalized annualized KPI in units of %.
- """
- assert len(kpi_weights) == len(kpi_deviations)
-
- weighted_target_deviation:float = 0.0
- for deviation, weight in zip(kpi_deviations, kpi_weights):
- weighted_target_deviation += weight * deviation value
-
- return weighted_target_deviation
-```
+Both forms are equivalent. The second is normative for implementation because $`\Lambda`$ is measured in tokens and can be compared directly against the stake shortfall.
-It implies that:
+The controller is piecewise linear in the indicator:
-- $`\delta_t \gt 0`$ → KPI below target → should increase the token emission by a factor of $`\alpha_d \cdot \delta_t`$.
-- $`\delta_t = 0`$ → KPI at target → should not change the token emission.
-- $`\delta_t \lt 0`$ → KPI above target → should reduce the token emission by a factor of $`\alpha_d \cdot \delta_t`$.
+- $`\delta_t \le 0`$, that is $`D_t \ge D_{target}`$, implies $`A_t = 0`$. Stake is at or above target and no release is warranted.
+- $`\delta_t \ge \delta^\ast`$, that is $`D_t \le D_{target} - \Lambda`$, implies $`A_t = 1`$. The deviation is at or beyond saturation and the release is maximal.
+- Between the two, $`A_t`$ interpolates linearly, so the response is proportional to the measured deviation over the interval $`(0, \delta^\ast)`$.
-> To measure the deviation, only the total estimated stake KPI is used in this part of the computation
+$`\delta^\ast`$ therefore fixes the width of the proportional band. At $`\delta^\ast = 1/6`$ the band runs from $`\theta = 25\%`$ to $`\theta = 30\%`$, and $`A_t`$ is saturated below it.
-### KPI Average
+## Block Rewards
-The weighted average metric is defined as
+The block reward is the block's fees plus a release from the reserve:
$$
-\gamma_t = \dfrac{1}{\Delta_t} \sum_i w_i \cdot \Bigl(\dfrac{1}{T} \sum_{\tau=t-T+1}^t \dfrac{ D_{i,\tau}}{D_{i,target}} \Bigr).
+\begin{equation}
+R_t = R^{\text{block}}_t + A_t \cdot c .
+\end{equation}
$$
-where:
+The two terms are independent. The first is a pass-through of value the block already collected; the second is a subsidy sized only by how far the inferred total stake sits below target. Neither scales the other.
-- The value $`D_{j,target}`$ can be any number with the same units of $`D_{j,i}`$.
-- The factor $`\dfrac{1}{\Delta_t}`$ turns $`\gamma_t`$ into an annualized quantity. This depends on the specific KPI.
+Equation (1) is the design statement. It is well defined only while the reserve can fund it, so the normative rule applies a solvency clamp:
-```python
-def weighted_average(
- kpi_weights: List[float],
- kpi_average: List[float]
-) -> float:
- """
- Calculate the weighted average metric (gamma_t)
- * kpi_weights: constant list of floats
- * kpi_average: for each KPI, it contains the results of "average_kpi"
- """
- assert len(kpi_weights) == len(kpi_deviations)
-
- weighted_avg:float = 0.0
- for avg, weight in zip(kpi_average, kpi_weights):
- weighted_avg += weight * avg
-
- return weighted_avg
-```
+$$
+\begin{equation}
+\iota_t = \min \lbrace A_t \cdot c, \; B_{t-1} \rbrace , \qquad R_t = R^{\text{block}}_t + \iota_t .
+\end{equation}
+$$
-The weighted average metric features:
+The clamp is not a design parameter. Without it the mechanism would debit more than the reserve holds and R1 would fail. It binds only in the final blocks of the reserve's life; at every earlier block $`A_t c \lll B_{t-1}`$ and equation (2) reduces to equation (1).
-- $`\gamma_t \gt 0`$ → should increase the token emission by a factor of $`\alpha_a \gamma_t`$.
-- $`\gamma_t = 0`$ → should not change the token emission.
-- $`\gamma_t \lt 0`$ → should reduce the token emission by a factor of $`\alpha_a \gamma_t`$.
+The clamp preserves R4. $`\min`$ of two continuous functions is continuous, so $`R_t`$ is continuous in $`D_t`$, in $`R^{\text{block}}_t`$ and in $`B_{t-1}`$, and no threshold produces a jump in the amount paid. What the clamp does not preserve is the asymptotic exhaustion of the reserve, that can reach zero exactly, in finite time, and the release stops there.
-> To measure the average, only the average pooling rate KPI is used in this part of the computation
+Bounds follow directly:
-## Key Performance Indicator(s)
+$$
+R^{\text{block}}_t \;\le\; R_t \;\le\; R^{\text{block}}_t + c .
+$$
-### KPI 1 - The Inferred Total Stake
+The reward is bounded below by the fees and above by the fees plus the per-block release cap. It is not bounded above in absolute terms. The released component alone satisfies $`0 \le \iota_t \le c`$ in every state and at any fee level, which is what discharges R5.
-Given the privacy features of Logos Blockchain and the fact that the token's maximum supply is known, the inferred total stake is the most appropriate indicator of the system's security.
+### Reserve Horizon and Terminal State
-Let:
+The reserve is spent at $`\iota_t`$ per block and never replenished, so its horizon is determined at genesis by the path of the controller:
-- $`D_{0,t}`$ denotes the evolution of the inferred total stake.
-- $`D_{0,target}`$ denotes the total stake that is considered secure. For the blockchain to be secure, we aim for $30\%$ of the maximum supply.
+$$
+B_t = B_0 - \sum_{s \le t} \iota_s , \qquad \sum_{s} \iota_s \;\le\; B_0 = I_{max} S_{cap} Y .
+$$
-The inferred total stake affects the emission rate through the "normalized deviation from target." The deviation implied by this KPI is characterized by the plot below.
+Under a saturated controller, $`A_t = 1`$ at every block, the horizon is exactly $`B_0 / c = 1.0512 \cdot 10^7`$ blocks, that is $`Y = 10`$ years. Under a mean controller value $`\bar{A}`$ over the interval, the horizon is $`Y / \bar{A}`$ years, tabulated in [Derived Property P8](analysis_new_block_rewards_specs.md#p8-reserve-horizon). The reserve is spent only in the states that call for it, so a chain that reaches its stake target early conserves the balance indefinitely; a chain that never reaches it spends the reserve in ten years.
-
+Once $`B_t = 0`$ the state is absorbing, per [Derived Property P7](analysis_new_block_rewards_specs.md#p7-the-reserve-reaches-zero-in-finite-time). Released rewards are zero from that block onward, the block reward is fees alone, and the mechanism has no instrument left if the stake subsequently falls below target. The release also stops abruptly rather than tapering: it falls from $`A_t c`$ to zero across two consecutive blocks, removing up to $`I_{max} S_{cap} / D_t`$ of annual staking yield at that instant. [Failure Mode F1](analysis_new_block_rewards_specs.md#f1-terminal-reserve-exhaustion-and-the-yield-cliff) quantifies the cliff and evaluates the available mitigations.
-> Figure 1
+## Accounting and Supply Dynamics
-This happens because, when the blockchain starts, $`D_{0,t} \vert_{t=0}`$ is very likely a small number compared to the target. Therefore, the equation [above](#kpi-deviation-from-target) tilts towards $1$ (or $100\%$) at that moment. As time passes and more stake participates in the PoS, the difference between the current total stake and the target diminishes. The equation [above](#kpi-deviation-from-target) oscillates around 0 (or $0\%$) when $`D_{0,t}`$ oscillates around $`D_{0,target}`$.
+### Stock accounting
-Let the Logos Blockchain’s security level be defined by:
+Two flows occur at every block. They are independent, and the order in which a node applies them does not matter.
$$
-\text{Security Level} = \dfrac{D_{0,target}}{S_{cap}}.
+\text{1. Block fees:} \quad R^{\text{block}}_t: \; S_t \rightarrow P_t , \qquad
+\text{2. Released rewards:} \quad \iota_t: \; B_t \rightarrow P_t .
$$
-### KPI 2 - The Average Pooling Rate
+$$
+S_t = S_{t-1} - R^{\text{block}}_t + \Pi_e \cdot \mathbb{1} \lbrace t = T_e \rbrace ,
+$$
-In the long run, Logos Blockchain should release only enough tokens to complement the pooled transaction fees, so that block rewards are funded primarily by distribution from the pool.
+$$
+B_t = B_{t-1} - \iota_t ,
+$$
-Let
+$$
+P_t = P_{t-1} + R^{\text{block}}_t + \iota_t - \Pi_e \cdot \mathbb{1} \lbrace t = T_e \rbrace = P_{t-1} + R_t - \Pi_e \cdot \mathbb{1} \lbrace t = T_e \rbrace .
+$$
-- $`D_{1,t}`$ denote the amount of Storage fees and Execution base fees pooled since $t-1$.
-- $`D_{1,target}=S_{cap}`$ denote the "normalizing factor" (it is the maximum supply, in this case).
+Each account has one role. The reserve pool funds released rewards and nothing else; it never touches the fees. The rewards pool receives both components of the block reward and pays out only at a boundary. Circulating supply loses the block's fees during the epoch and regains the settlement amount at the boundary.
-This choice of "target" implies that $`\gamma_t`$ evaluates the annualized average pooling rate with respect to the maximum supply. This makes the equation [above](#emission-rate-factor-function) consistent.
+The only debit from the reserve pool is $`\iota_t`$, and the clamp in equation (2) bounds it by $`B_{t-1}`$ unconditionally, so $`B_t \ge 0`$ holds at every block. No flow ordering constraint is required.
-# Float Precision for Implementation
+R6 is satisfied trivially. The reserve pool never accumulates, since it has no inflow, and the rewards pool is emptied at every boundary by R9. There is no stock in which value can build up without a release rule, because there is no stock that builds up.
-Because block rewards affect consensus state, the implementation must be fully deterministic across all nodes. For that reason, the normative implementation of the reward function should not rely on floating-point arithmetic, machine-dependent rounding behavior, or comparisons against machine epsilon. Earlier sections use real-valued formulas to explain the mechanism and its economic meaning, but the consensus rule itself should be defined only in terms of integer arithmetic. This is especially important because the current document already notes floating-point concerns in the KPI helper functions and then introduces a final integer rewrite for the reward computation. The issue is therefore not whether integers should be used, but how to present that integer formulation in a way that remains auditable and clearly derived from the protocol parameters.
+### Supply dynamics
-The goal of this section is not to change the reward mechanism. It is only to restate the already-specified mechanism in a canonical deterministic form with explicit named constants. In particular, the reward logic remains driven by the same two KPI components described previously: the inferred total stake relative to its target, and the moving average of pooled fees over the look-back window. Likewise, the reward still interpolates between the reserve release and distribution from the pooled fees through the emission factor $`A_t`$.
+Over epoch $`e`$ the circulating supply loses the epoch's fees and regains the settlement, which is the epoch's fees plus the epoch's releases. Netting the two,
$$
-A_t = \min \lbrace 1, \max \lbrace 0, \dfrac{ \alpha_d \cdot \delta_t + \alpha_a \cdot \gamma_t + I_{min}}{I_{max}} \rbrace \rbrace.
+S_{T_e} - S_{T_{e-1}} = \sum_{t = T_{e-1}+1}^{T_e} \iota_t \;\ge\; 0 .
$$
-Because we have
+Circulating supply is non-decreasing epoch over epoch and strictly increasing whenever any block in the epoch carries a positive release. Total net emission over the life of the chain is bounded by $`B_0 = 10^9`$ LGO, that is $`10\%`$ of $`S_{cap}`$, and is reached only if the shortfall persists for the full horizon.
-$$
-\alpha_d=\frac{1}{4},\quad
-\alpha_a=1,\quad
-I_{\max}=10^{-2},\qquad
-T=120,\quad
-f=1,\quad R_\text{block} = D_{1,t}\\
-D_{0,\mathrm{target}}=3\cdot 10^9,\qquad
-D_{1,\mathrm{target}}=S_{\mathrm{cap}}=10^{10},\qquad
-\Delta_t=\frac{1}{365\cdot 2880},
-$$
+### Epoch settlement
+
+At the last block of epoch $`e`$ the rewards pool is emptied. The settlement amount is the sum of the block rewards accrued over the epoch,
$$
-\delta_t = \sum_i w_i \times
-\dfrac{D_{i,target} - D_{i,t}}{D_{i,target}},
+\Pi_e = \sum_{t = T_{e-1}+1}^{T_e} R_t ,
$$
+and it is transferred out of $`P`$ and split between the two recipient classes, with the residual assigned so that the parts sum to the whole:
+
$$
-\gamma_t = \dfrac{1}{\Delta_t} \sum_i w_i \cdot \Bigl(\dfrac{1}{T} \sum_{\tau=t-T+1}^t \dfrac{ D_{i,\tau}}{D_{i,target}} \Bigr),
+\Pi^{blend}_e = \left\lfloor \frac{3 \, \Pi_e}{5} \right\rfloor, \qquad \Pi^{leader}_e = \Pi_e - \Pi^{blend}_e .
$$
-and $`w_i`$ denotes the weight of the $i$-th KPI in the normalized deviation from target or in the normalized average; it satisfies $`\sum_i w_i = 1`$.
+$`\Pi^{blend}_e`$ passes to the Blend distribution and $`\Pi^{leader}_e`$ to the leader reward pool. Both are outside this specification; refer to the protocols listed in the [Introduction](#introduction). The two components are settled on different downstream schedules, which does not affect the accounting here: from the perspective of this mechanism both leave $`P`$ at $`T_e`$.
-Therefore,
+Splitting at the epoch aggregate rather than per block reduces the truncation residual from one base unit per block to one per epoch, a factor of $`L`$.
-$$
-\begin{aligned}
-\frac{\alpha_d}{I_{\max}}\delta_t
-&=
-\frac{1/4}{10^{-2}}\cdot \frac{D_{0,\mathrm{target}}-D_{0,t}}{D_{0,\mathrm{target}}}
-\\
-&=
-25\cdot \frac{3\cdot 10^9-D_{0,t}}{3\cdot 10^9}
-\\
-&=
-\frac{3\cdot 10^9-D_{0,t}}{12\cdot 10^7}.
-\end{aligned}
-$$
+Immediately after settlement $`P_{T_e} = 0`$. This is the only instant at which the rewards pool balance is known without reference to the epoch's history, and it is the point at which the three-stock identity reduces to two, per [Derived Property P2](analysis_new_block_rewards_specs.md#p2-the-rewards-pool-accrues-within-an-epoch-and-discharges-at-the-boundary).
-and
+# Float Precision for Implementation
-$$
-\frac{\alpha_a}{I_{\max}}\gamma_t=\frac{1}{10^{-2}}\cdot \frac{1}{\Delta_t}\cdot \frac{1}{T}\sum_{\tau=t-T+1}^{t}\frac{D_{1,\tau}}{D_{1,\mathrm{target}}}=\\\frac{1}{10^{-2}}\cdot \frac{1}{\Delta_t}\cdot \frac{1}{T}\cdot\frac{1}{{D_{1,\mathrm{target}}}}\sum_{\tau=t-T+1}^{t}{D_{1,\tau}}=\\
-\\100\cdot \frac{1}{\frac{1}{365\cdot 2880}}\cdot \frac{1}{120}\cdot\frac{1}{10^{10}}\sum_{\tau=t-120+1}^{t}{D_{1,\tau}}=\\
-100\cdot \frac{365\cdot 2880}{120\cdot 10^{10}}\sum_{\tau=t-120+1}^{t} D_{1,\tau}=\\
-\frac{10512}{12\cdot 10^7}\sum_{\tau=t-120+1}^{t} D_{1,\tau}.
-$$
+Block rewards affect consensus state, so the normative rule is defined in integer arithmetic. All quantities are in base units, $`1`$ LGO $`= 10^{d}`$ base units with $`d = 18`$. No floating point, no machine-epsilon comparison, and no rounding-mode dependence appears in the rule. This discharges R8.
-So we rewrite $`A_t`$ by
+## Constants
$$
-A_t=\min\!\lbrace1,\max\!\lbrace0,\quad \frac{3\cdot 10^9-D_{0,t}+10512\sum_{\tau=t-120+1}^{t}D_{1,\tau}}{12\cdot 10^7}\rbrace\rbrace.
+c^{\ast} = \left\lfloor \frac{62500 \cdot 10^{d}}{657} \right\rfloor, \quad
+\Lambda^{\ast} = 5 \cdot 10^{8} \cdot 10^{d}, \quad
+M = 2^{32} .
$$
-And by denoting
+$`M`$ is the fixed-point scale of the controller. $`c^{\ast}`$ replaces the exact rational $`c`$; the truncation is below one base unit, that is $`10^{-18}`$ LGO. The throttle constant $`\Phi = \beta^\ast B_0`$ of revision 1.0.0 is removed.
+
+## Rule
$$
-\begin{aligned}
-A_t'
-&=
-\min\!\lbrace12\cdot 10^7,\max\!\lbrace0,\quad3\cdot 10^9-D_{0,t}+10512\sum_{\tau=t-120+1}^{t}D_{1,\tau}\rbrace\rbrace,
-\\
-A_t&=\frac{A_t'}{12\cdot 10^7}.
-\end{aligned}
+a_t = \left\lfloor \frac{\min \lbrace \Lambda^{\ast}, \; \max \lbrace 0, \; D_{target} - D_t \rbrace \rbrace \cdot M}{\Lambda^{\ast}} \right\rfloor ,
$$
-We can compute the block reward using only integers:
-
$$
-\text{Rewards}_t= A_t \cdot \dfrac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f} + (1-A_t) \cdot R_\text{block} =\\
-\frac{A_t'}{12\cdot 10^7} \cdot \dfrac{I_{max} \cdot S_{cap} \cdot \Delta_t}{f} + (1-\frac{A_t'}{12\cdot 10^7}) \cdot D_{1,t}
+\iota_t = \min \left\lbrace \left\lfloor \frac{a_t \cdot c^{\ast}}{M} \right\rfloor, \; B_{t-1} \right\rbrace , \qquad
+R_t = R^{\text{block}}_t + \iota_t .
$$
-and
+The fee term enters exactly, with no scaling and no floor, so all approximation error in $`R_t`$ is confined to the released component. The state update is then
$$
-\frac{I_{\max} \cdot S_{\mathrm{cap}}\cdot \Delta_t}{f}=\frac{10^{-2}\cdot 10^{10}}{365\cdot 2880}=\frac{10^8}{1051200}=\frac{62500}{657}.
+B_t = B_{t-1} - \iota_t, \qquad P_t = P_{t-1} + R_t, \qquad S_t = S_{t-1} - R^{\text{block}}_t ,
$$
-So:
+in any order, and at $`t = T_e`$ additionally
$$
-\text{Rewards}_t=
-\frac{A_t'}{12\cdot 10^7} \cdot \frac{62500}{657} + (1-\frac{A_t'}{12\cdot 10^7})\cdot D_{1,t} =\\
-\frac{62500\cdot A_t' + 657\cdot(12\cdot 10^7-A_t')\cdot D_{1,t}}{657\cdot 12\cdot 10^7}
-.
+\Pi_e = P_t, \qquad \Pi^{blend}_e = \left\lfloor \frac{3 \Pi_e}{5} \right\rfloor, \qquad \Pi^{leader}_e = \Pi_e - \Pi^{blend}_e, \qquad P_t \leftarrow 0 .
$$
-So we propose a reference implementation that uses integers:
+The clamp against $`B_{t-1}`$ is applied after the multiplication and floor, on a quantity already bounded by $`c^{\ast}`$, so it cannot overflow.
-```python
-import numpy as np
-from numpy import int64
+## Bit width
-A_SCALE = int64(120_000_000) # denominator of 1/(I_max * D1_target * Delta_t * T)
-INFLATION_NUMERATOR = int64(62_500) # numerator of I_max * S_CAP * DELTA_t / f
-INFLATION_DENOMINATOR = int64(657) # denominator of I_max * S_CAP * DELTA_t / f
-FEE_AVG_NUMERATOR = int64(10_512) # numerator of 1/(I_max * D1_target * Delta_t * T)
-STAKE_TARGET = int64(3_000_000_000)
+The largest intermediate is $`\max \lbrace \Lambda^{\ast} M, \; M c^{\ast} \rbrace = \Lambda^{\ast} M = 2.15 \cdot 10^{36}`$, which fits in `u128` with a factor of $`158`$ of headroom. `u64` is insufficient by seventeen orders of magnitude. Any change to $`\Lambda`$ or $`M`$ must preserve
+$$
+\max \lbrace \Lambda^{\ast} M, \; M c^{\ast} \rbrace < 2^{128} .
+$$
+
+The rewards pool accumulator is no longer bounded by a protocol constant, because the fee component of $`R_t`$ is uncapped. Its reserve-funded part is at most $`L c^{\ast} \approx 2.06 \cdot 10^{24}`$ base units, and the only bound on the total is the conservation bound $`P_t \le S_{cap}^{\ast} = 10^{28}`$ base units. `u128` accommodates the latter with eleven orders of magnitude to spare; `u64` does not accommodate either.
-def block_reward(total_stake: int64, pooled_fees_window: list[int64]) -> tuple[int64, int64]:
- sum_fees = np.sum(pooled_fees_window, dtype=int64)
- last_pooled_fee = pooled_fees_window[-1]
+## Accuracy
- a_numerator = np.minimum(
- np.maximum(STAKE_TARGET + FEE_AVG_NUMERATOR * sum_fees - total_stake, int64(0)),
- A_SCALE,
- )
+A full chain of $`20`$ epochs of $`L = 21600`$ blocks, $`432000`$ blocks in total, was simulated against exact rational arithmetic with $`D_t \in [0, 4 \cdot 10^9]`$ LGO and $`R^{\text{block}}_t \in [0, 3c]`$ drawn independently at each block. The run was repeated with the reserve initialized at $`2 \cdot 10^6`$ LGO so that the clamp binds. The differential test is `new-block-rewards/assets/reference_implementation.py`.
- reward_numerator = (
- INFLATION_NUMERATOR * a_numerator
- + INFLATION_DENOMINATOR * (A_SCALE - a_numerator) * last_pooled_fee
- )
- reward_denominator = INFLATION_DENOMINATOR * A_SCALE
+- worst absolute deviation from the exact block reward: $`2.22 \cdot 10^{-8}`$ LGO per block, that is $`0.023`$ LGO per year against a maximum annual release of $`10^8`$ LGO, a relative error of $`2.3 \cdot 10^{-10}`$ on the annual emission. Identical in both runs, since the fee term is exact and the clamp does not add error.
+- $`R^{\text{block}}_t \le R_t \le R^{\text{block}}_t + c^{\ast}`$: holds at every block, confirming [Derived Property P3](analysis_new_block_rewards_specs.md#p3-block-reward-bounds-and-monotonicity) and R5.
+- $`\iota_t \le B_{t-1}`$: holds at every block, in both runs, confirming [Derived Property P6](analysis_new_block_rewards_specs.md#p6-the-reserve-pool-covers-every-released-reward).
+- $`B_t = \max \lbrace 0, B_0 - \sum_{s \le t} \lfloor A_s c^{\ast} \rfloor \rbrace`$: exact at every block in both runs, including through exhaustion, confirming the closed form of [Derived Property P5](analysis_new_block_rewards_specs.md#p5-closed-form-for-the-stock-dynamics).
+- $`B_t \ge 0`$ with exact termination: in the near-empty run the reserve reached exactly zero at block $`30648`$ and stayed there, with the release identically zero thereafter and the block reward equal to the fees.
+- $`S_t + B_t + P_t`$ constant: checked at every block, including boundaries, confirming [Derived Property P1](analysis_new_block_rewards_specs.md#p1-conservation) at integer precision.
+- $`P_{T_e} = 0`$ at all $`20`$ boundaries, confirming [Derived Property P2](analysis_new_block_rewards_specs.md#p2-the-rewards-pool-accrues-within-an-epoch-and-discharges-at-the-boundary) and R9.
+- $`\Pi^{blend}_e + \Pi^{leader}_e = \Pi_e`$: exact. Computing the two components with independent floor divisions would lose up to one base unit per settlement and break [Derived Property P1](analysis_new_block_rewards_specs.md#p1-conservation); assigning the residual to the leader share removes the loss.
+- peak rewards pool balance: $`4.51 \cdot 10^6`$ LGO, against a reserve-funded component of at most $`L c = 2.05 \cdot 10^6`$ LGO. The excess is fee-driven and scales with fee volume, which is the observable consequence of the accumulator no longer having a protocol bound.
- blend_reward = reward_numerator * int64(6) // (reward_denominator * int64(10))
- leader_reward = reward_numerator * int64(4) // (reward_denominator * int64(10))
+## Reference
- return blend_reward, leader_reward
+```python
+DECIMALS = 18
+ONE = 10 ** DECIMALS
+
+CAP = 62_500 * ONE // 657 # c*
+LAMBDA = 500_000_000 * ONE # Lambda*
+D_TARGET = 3_000_000_000 * ONE
+M = 1 << 32
+L = 21_600 # blocks per epoch
+
+
+def released(total_stake: int, reserve: int) -> int:
+ """Released rewards for this block: A_t * c, clamped by the reserve balance."""
+ # security controller, scaled by M
+ shortfall = D_TARGET - total_stake
+ if shortfall < 0:
+ shortfall = 0
+ elif shortfall > LAMBDA:
+ shortfall = LAMBDA
+ a = shortfall * M // LAMBDA
+
+ iota = a * CAP // M
+ return iota if iota < reserve else reserve
+
+
+def block_reward(total_stake: int, gross_fees: int, reserve: int) -> int:
+ """The block reward accrued at this block: fees in full, plus the release."""
+ return gross_fees + released(total_stake, reserve)
+
+
+def apply_block(state, height, total_stake, gross_fees):
+ """State transition. The two block flows are independent, so a node may
+ apply them in any order."""
+ iota = released(total_stake, state["B"])
+ R = gross_fees + iota
+
+ state["S"] -= gross_fees # 1. R^block: S -> P
+ state["P"] += gross_fees
+ state["B"] -= iota # 2. iota : B -> P
+ state["P"] += iota
+
+ if height % L == 0: # 3. settlement at the boundary
+ Pi = state["P"]
+ blend = Pi * 3 // 5
+ leader = Pi - blend
+ state["P"] = 0
+ state["S"] += Pi
+ return R, (Pi, blend, leader)
+ return R, None
```
+
+`blend` passes to the Blend distribution and `leader` to the leader reward pool; both are outside this specification.
diff --git a/docs/blockchain/raw/execution-market.md b/docs/blockchain/raw/execution-market.md
index ecbdf6c85..374bb065b 100644
--- a/docs/blockchain/raw/execution-market.md
+++ b/docs/blockchain/raw/execution-market.md
@@ -26,6 +26,7 @@
| 1.1.0 | Round the base fee update upwards | 2026-07-28 |
| 1.1.1 | Precise that greedy inclusion selects a candidate only if it is valid in the state the already selected transactions leave | 2026-08-24 |
| 1.1.2 | Changing from burning/minting to pooling/distributing | 2026-08-26 |
+| 1.1.3 | Align every block-reward reference with [Block Rewards](block-rewards.md). No change to the price mechanism. | 2026-08-27 |
> Disclaimer:
> This material, including any linked pages or documents, is provided for informational purposes only. It does not constitute investment advice, a solicitation, or an offer to buy or sell any securities, tokens, or other financial instruments, nor should it be construed as legal, financial, or tax advice.
@@ -51,7 +52,7 @@ The design is founded on a target-based mechanism, philosophically aligned with
To further enhance security, this specification addresses a known vulnerability in the classic EIP-1559 design. As demonstrated by recent research ([Cachin et al., 2023](https://arxiv.org/pdf/2304.11478)), EIP-1559 is susceptible to base fee manipulation by rational, non-myopic block builders. Our design incorporates a direct mitigation for this threat, as proposed in [Cachin et al., 2023](https://arxiv.org/pdf/2304.11478): an Exponential Moving Average (EMA) based update rule for the base fee. Given the EMA nature of this update, these enhancements smooth fluctuations in execution gas consumption, making the protocol significantly more resilient to strategic manipulation without compromising its core benefits of responsiveness and predictability
-Furthermore, as opposed to the standard EIP-1559 mechanism, where the base fee is burned and tips are immediately given to miners, in our setting we route fees into a rewards pool, and later we distribute rewards from that pool given to the block builders at a later block through the [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md), for privacy preservation.
+Furthermore, as opposed to the standard EIP-1559 mechanism, where the base fee is burned and tips are immediately given to miners, in our setting neither component is burned and neither is paid to the proposer in its own block. Base fees accrue in the rewards pool over the blocks of an epoch and settle at the epoch boundary to block builders and Blend nodes, on the schedule specified in [Block Rewards](block-rewards.md). Priority fees accrue to the leader class alone. Both reach block builders through the [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md), which decouples the claim from the block that earned it, for privacy preservation.
# Overview
@@ -59,9 +60,10 @@ Our fee mechanism adapts Ethereum's EIP-1559 to the specific economic and securi
The mechanism operates on four core principles:
-- Dynamic Base Fee: A protocol-defined base_fee for Execution Gas must be paid for a transaction to be included in a block. This fee adjusts automatically based on a smoothed average of recent network demand relative to a predefined capacity target, ensuring sustainable network load. This base_fee is the minimal threshold to be paid for the transaction to be accepted by the block builder.
-- Priority Fee (Tip): To incentivize faster inclusion by block builders, users add a priority_fee on top of the base fee. This creates a simple and transparent auction for block space during periods of high demand. The proceeds of this goes to the block builder.
-- Fee Splitting and Pooling: The two fee components are treated differently. The entire base_fee is routed to the rewards pool, removing it from circulation. As usage grows, more base fees are routed to the pool and removed from circulation, which creates a direct link between network activity and the circulating supply of the native token. The priority_fee is not immediately distributed to the block builder (to preserve privacy), but instead it is directed into the block builders reward stream. 40% of the rewards will be allocated to block builders and the remaining 60% to Blend nodes. Rewards are privacy-preserving via [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md).
+- Dynamic Base Fee: A protocol-defined base_fee for Execution Gas must be paid for a transaction to be included in a block. This fee adjusts automatically based on a smoothed average of recent network demand relative to a predefined capacity target, ensuring sustainable network load. This base fee is the minimal threshold to be paid for the transaction to be accepted by the block builder.
+- Priority Fee (Tip): To incentivize faster inclusion by block builders, users add a priority fee on top of the base fee. This creates a simple and transparent auction for block space during periods of high demand. The proceeds go to the block builder class in full, with no Blend share, and are claimed anonymously rather than collected in the block itself.
+
+- Fee Routing and Pooling: The two fee components go to different destinations. The entire base fee is routed to the rewards pool, where it leaves circulation for the remainder of the epoch and returns in full at settlement; at each epoch boundary that pool is split 40% to block builders and 60% to Blend nodes, per [Block Rewards](block-rewards.md). The entire priority fee is routed instead to the leader reward accumulator and settles to block builders alone, with no Blend share. Neither component is paid to the proposer in its own block, which would tie the amount received to that block's contents; both are claimed anonymously via [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md).
The entire lifecycle can be visualized in the following flow:
@@ -70,18 +72,18 @@ The entire lifecycle can be visualized in the following flow:
## Incentive Analysis
- User Strategy: The mechanism promotes a straightforward bidding strategy. A rational user should set their execution_gas_price ($`c_t`$) to their true maximum willingness to pay. Setting it higher provides no advantage and risks overpayment, while setting it lower risks the transaction being delayed if the base_fee rises. The priority_fee acts as a simple tip to gauge the market rate for priority inclusion during congestion.
-- Block Builder Strategy: The dominant strategy for a rational, profit-maximizing block builder is to follow the prescribed block construction algorithm honestly. The block builder's revenue is derived from (a) priority fees and (b) block rewards in accordance with network Key Performance Indicators (KPIs) as described in [Block Rewards](block-rewards.md), which incentivize them to include the transactions that maximize their revenue. Because the base_fee is determined algorithmically based on historical data, a block builder cannot manipulate it for their own immediate gain.
+- Block Builder Strategy: The dominant strategy for a rational, profit-maximizing block builder is to follow the prescribed block construction algorithm honestly. The block builder's revenue is derived from (a) the priority fees of the epoch, which accrue to the leader class in full, and (b) their share of the epoch settlement of block rewards, as described in [Block Rewards](block-rewards.md). Neither is collected in the builder's own block: both are pooled over the epoch and claimed anonymously, so no amount received can be traced to the block that earned it. Base fees are carried through the settlement in full, so including the transactions that maximize the block's fee revenue raises both pools. Because the base fee is determined algorithmically based on historical data, a block builder cannot manipulate it for their own immediate gain.
## Economic Properties
- Sustainable Resource Management: The TFM automatically steers network usage toward the target ($`G_\text{target}`$). By increasing the cost of Execution Gas during high demand, the protocol prevents network overload. This protects the ability of nodes with modest hardware to participate, safeguarding decentralization.
-- Circulating-Supply Pressure: Routing the base_fee to the rewards pool (and later distributing a proportion of it back as rewards, cf [Block Rewards](block-rewards.md)) establishes a direct link between network activity and the circulating supply of the Logos Blockchain token. As usage grows, the rate at which base fees enter the pool increases, applying downward pressure on circulating supply. Because the pool is a redistributable reserve, this pressure acts on tokens in circulation, not on total supply.
+- Fee Recycling and Yield: Routing the base fee to the rewards pool recycles it rather than destroying it. The pooled base fees are returned in full at the epoch settlement, so usage applies no permanent downward pressure on the circulating supply and none on total supply (cf [Block Rewards](block-rewards.md)). Within an epoch the pooled amount is a float on circulation; at the boundary it is paid out. The link between network activity and the token therefore runs through yield rather than through supply: higher usage raises the amount settled per epoch, which raises the return to block builders and Blend nodes.
## Security Properties: Mitigation of Base Fee Manipulation
A critical feature of this design is its resilience to the base fee manipulation attack identified in classic EIP-1559. Our EMA-based update rule directly mitigates this vulnerability in two ways:
-1. Impact Dampening: The influence of any single block's Execution Gas consumption (e.g., an empty block) on the fee update is dampened by a factor of ($1q$), preventing sharp, manipulative drops in the base_fee.
+1. Impact Dampening: The influence of any single block's Execution Gas consumption (e.g., an empty block) on the fee update is dampened by a factor of $`(1-q)`$, preventing sharp, manipulative drops in the base_fee.
2. Exponential Decay: The effect of a manipulative block on subsequent base_fee calculations decays exponentially, making it economically infeasible for an attacker to sustain the attack.
# Construction
@@ -103,7 +105,8 @@ A critical feature of this design is its resilience to the base fee manipulation
| $\phi$ | Fee Adjustment Rate | 1/8 | A protocol constant controlling how quickly the base fee adjusts to demand. |
| $q$ | EMA Smoothing Factor | 9/10 | A protocol constant defining the weight of historical average in the EMA update rule. |
| $`F_t`$ | Total fee | - | $`F_t = g_t \,\cdot\bigl(b_{\mathrm{exec}}[s] + p_t\bigr)= g_t\cdot c_t`$ |
-| $`\hat{R}_{\mathrm{pooled}}[s]`$ | Amount of base fees pooled | - | This is used as an input to compute the block rewards |
+| $`\hat{R}_{\mathrm{pooled}}[s]`$ | Amount of base fees pooled | - | The Execution-market component of the block's gross fee inflow $`R^{\text{block}}_s`$, passed through in full to the block reward. |
+| $`\hat{R}_{\mathrm{priority}}[s]`$ | Amount of priority fees routed to leaders | - | Routed in full to the leader reward accumulator, outside $`R^{\text{block}}_s`$. |
### Parameter Justification
@@ -230,4 +233,17 @@ $$
= \sum_{t \in \mathcal{B}_s} \bigl(g_t \cdot b_{\mathrm{exec}}[s]\bigr).
$$
-This pooled quantity is then used as an input for the computation of the block rewards. It is the Execution-market component of the per-block pool inflow $`R_{block}`$, as described in [Block Rewards](block-rewards.md).
+This pooled quantity is the Execution-market component of the gross fee inflow $`R^{\text{block}}_s`$ defined in [Block Rewards](block-rewards.md); Permanent Storage fees are the other component. It enters the block reward additively and in full, with no cap, no split and no excess capture, and it does not enter the computation of the released component $`\iota_s`$.
+
+The priority fees of the block aggregate separately to
+
+$$
+\hat{R}_{\mathrm{priority}}(s)
+= \sum_{t \in \mathcal{B}_s} \bigl(g_t \cdot p_t\bigr).
+$$
+
+This quantity is routed in full to the leader reward accumulator of the [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md) rather than to the rewards pool. It takes no Blend share, is not part of $`R^{\text{block}}_s`$, and does not enter the epoch settlement $`\Pi_e`$ of [Block Rewards](block-rewards.md). The two aggregates account for the block's total fees,
+
+$$
+\sum_{t \in \mathcal{B}_s} F_t = \hat{R}_{\mathrm{pooled}}(s) + \hat{R}_{\mathrm{priority}}(s).
+$$
diff --git a/docs/blockchain/raw/overview-cryptoeconomics.md b/docs/blockchain/raw/overview-cryptoeconomics.md
index 480e6cc5e..460608bf5 100644
--- a/docs/blockchain/raw/overview-cryptoeconomics.md
+++ b/docs/blockchain/raw/overview-cryptoeconomics.md
@@ -7,7 +7,7 @@
| Status | raw |
| Category | Informational |
| Editor | Thomas Lavaur |
-| Contributors | Marcin Pawlowski , Filip Dimitrijevic |
+| Contributors | Marcin Pawlowski , Filip Dimitrijevic , Frederico Teixeira |
@@ -26,6 +26,7 @@
| 1.1.0 | Reflect the upward rounding of the fee market price updates | 2026-07-28 |
| 1.2.0 | Reflect the downward rounding of the leader share | 2026-08-05 |
| 1.2.1 | Changing from burning/minting to pooling/distributing/releasing | 2026-08-25 |
+| 1.2.2 | Align with the reviewed Block Rewards, Execution Market and Anonymous Leaders Reward specs | 2026-08-27 |
> **Disclaimer**:
> This material, including any linked pages or documents, is provided for informational purposes only. It does not constitute investment advice, a solicitation, or an offer to buy or sell any securities, tokens, or other financial instruments, nor should it be construed as legal, financial, or tax advice.
@@ -58,9 +59,9 @@ In this section we present an overview of the cryptoeconomical aspects of the Lo
- Transactions may incur up to two types of fees:
- Execution fee: covers the computational resources consumed by the transaction.
- Permanent Storage fee: covers the permanent Ledger storage resources consumed by the transaction.
-- Execution base fees and storage fees are routed into the rewards pool for each block, removing them from circulation.
+- Execution base fees and Permanent Storage fees are routed into the rewards pool for each block, where they stay until the epoch settlement returns them in full. Execution priority fees are routed instead to the leader reward pool, and take no Blend share.
- Rewards are distributed on an epoch basis:
- - Leaders (block proposers) include Mantle Transactions in every block. Each transaction pays Permanent Storage and Execution fees, which are routed into the rewards pool. For each block, a reward is calculated following the [Block Rewards](block-rewards.md). Additionally, a portion of the Execution fees is distributed back to leaders from the pool according to the [Execution Market](execution-market.md). These two sources determine the total rewards allocated to leaders, as explained in [Blend Service and Consensus Leaders](#blend-service-and-consensus-leaders), which correspond to tips from the Execution market and 40% of block rewards. For anonymity reasons, block proposers don't receive rewards directly. Instead, leader rewards accumulate in a single pool that increases on an epoch basis rather than per block (see [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md)). When a new epoch begins, the pool increases by the total leader rewards from all blocks in the previous epoch. Simultaneously, leaders from the previous epoch can start claiming their rewards, with each unclaimed reward (since genesis) representing one equal share of the pool.
+ - Leaders (block proposers) include Mantle Transactions in every block. Each transaction pays Permanent Storage fees and Execution fees. The Permanent Storage fees and the Execution base fees are routed into the rewards pool, in which a reward accrues for each block following the [Block Rewards](block-rewards.md). The Execution priority fees are routed separately, in full, to the leader reward pool, and take no Blend share (see [Execution Market](execution-market.md)). These two sources determine the total rewards allocated to leaders, as explained in [Blend Service and Consensus Leaders](#blend-service-and-consensus-leaders), which correspond to the tips of the Execution market, and 40% of the epoch settlement of block rewards. For anonymity reasons, block proposers don't receive rewards directly. Instead, leader rewards accumulate in a single pool that increases on an epoch basis rather than per block (see [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md)). When a new epoch begins, the pool increases by the total leader rewards from all blocks in the previous epoch. Simultaneously, leaders from the previous epoch can start claiming their rewards, with each unclaimed reward (since genesis) representing one equal share of the pool.
- Blend nodes provide Blend service to the network for at least one epoch. Using the same [Block Rewards](block-rewards.md), the protocol determines the total rewards allocated to the Blend network, as explained in [Blend Service and Consensus Leaders](#blend-service-and-consensus-leaders) which correspond to 60% of the block rewards.
When an epoch $`e`$ ends, Blend validators have one additional epoch $`e+1`$ to send an active message used by the [Reward Distribution Protocols](#reward-distribution-protocols) to determine reward distribution among validators. During the first block of epoch $`e+2$, Blend validators from epoch $`e`$ receive their portion of [Blend Service and Consensus Leaders](#blend-service-and-consensus-leaders) rewards, with proportions determined by the [Reward Distribution Protocols](#reward-distribution-protocols). These rewards are distributed at the start of the next epoch.
- The [Service Rewards Distribution Protocol](#service-rewards-distribution-protocol) handles payments of rewards for Blend Services to individual nodes.
@@ -134,12 +135,12 @@ The following sections explain how these principles apply to different roles in
### Blend Service and Consensus Leaders
-The Blend service and the leaders proposing the blocks share a same block reward that is calculated for each block based on a KPI function. This KPI function takes as input the inferred total stake and the amount of Execution and Permanent Storage fees of the block. How the KPI function calculates each block reward is explained in [Block Rewards](block-rewards.md).
+The Blend service and the leaders proposing the blocks share the same block reward that is calculated for each block. It is the sum the block's Execution base fees and Permanent Storage fees, passed through in full, and a release from the reserve sized by a KPI function. That KPI function takes a single input, the inferred total stake, and does not depend on fee revenue. How each block reward is calculated is explained in [Block Rewards](block-rewards.md).
- Blend rewards are distributed among all active Blend Nodes. Blend rewards are composed of a fraction of the block rewards. These rewards of epoch $`e`$ are defined when a new Blend epoch $`e+1`$ starts (a defined number of blocks) and are allocated to nodes based on their reported Active Messages and the [Reward Distribution Protocols](#reward-distribution-protocols) during epoch $`e+2`$ . The [Service Reward Distribution Protocol](bedrock-service-reward-distribution.md) manages the direct payment to nodes.
-- Leaders get a voucher for each included block in epoch $`e`$ . Vouchers represent an equal share of the leader reward pool. At the start of epoch $`e+1`$ , the leaders rewards of epoch $`e`$ are added to the pool (represented by a variable) and the voucher of epoch $`e`$ can start being used. The amount added to the pool is composed of a fraction of the block rewards and a portion of the Execution fees distributed back according to the [Execution Market](execution-market.md) from all blocks of epoch $`e`$ . Vouchers can be exchanged with a reward through a [Leader Claim Operation](bedrock-v1.1-mantle-specification.md) (on-chain transaction) that preserves privacy by decoupling the leader reward from the proposed block. The reward amount, represented by a share of the pool, is computed when the claim Operation is executed (c.f. [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md)).
+- Leaders get a voucher for each included block in epoch $`e`$ . Vouchers represent an equal share of the leader reward pool. At the start of epoch $`e+1`$ , the leaders rewards of epoch $`e`$ are added to the pool (represented by a variable) and the voucher of epoch $`e`$ can start being used. The amount added to the pool is composed of the leader share of the epoch settlement of block rewards, and of the Execution priority fees of all blocks of epoch $`e`$ , credited in full according to the [Execution Market](execution-market.md). Vouchers can be exchanged with a reward through a [Leader Claim Operation](bedrock-v1.1-mantle-specification.md) (on-chain transaction) that preserves privacy by decoupling the leader reward from the proposed block. The reward amount, represented by a share of the pool, is computed when the claim Operation is executed (c.f. [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md)).
-Each block reward of each block is split as follows between the Blend service and the leader:
+The block rewards accrued over an epoch are split as follows between the Blend service and the leader:
- 40% for the leader.
- 60% for the Blend service.
@@ -155,20 +156,22 @@ At the start of each Blend epoch, a Blend reward variable is computed. Its amoun
```python
def get_blend_reward(e: epoch): # rewards for the epoch e
- blend_rewards = 0
+ settlement = 0
for b in e.blocks: # for each block of the previous epoch
- blend_rewards += 0.6 * get_block_rewards(b) # get 60% of the rewards
- return blend_rewards
+ settlement += get_block_rewards(b) # accrue, do not split per block
+ return 3 * settlement // 5 # 60%, split once on the epoch total
```
-At the start of each epoch, the rewards are added to the leader rewards. Its amount is increased by 40% of the total block rewards of the previous epoch. The blocks from the previous epoch are denoted by B in the pseudocode below:
+At the start of each epoch, the rewards are added to the leader rewards. Its amount is increased by the leader share of the previous epoch's block rewards, that is the residual of the 60% Blend share on the epoch total, and by the Execution priority fees of that epoch in full. The blocks from the previous epoch are denoted by B in the pseudocode below:
```python
def update_leader_rewards(e: epoch, # rewards for the epoch e
leader_rewards: int): # added to the leader reward pool
+ settlement = 0
for b in e.blocks: # for each block of the previous epoch
- leader_rewards += 0.4 * get_block_rewards(b) # get 40% of the rewards
- leader_rewards += get_execution_market_tips(b) # get Execution market tips
+ settlement += get_block_rewards(b) # accrue, do not split per block
+ leader_rewards += get_execution_market_tips(b) # tips, in full, no Blend share
+ leader_rewards += 2 * settlement // 5 # the residual, 40%
return leader_rewards
```
@@ -180,8 +183,8 @@ To protect leaders' privacy, we must not link leaders to their blocks and reward
The [Anonymous Leaders Reward Protocol](bedrock-anonymous-leaders-reward.md) defines how leader rewards are maintained in the ledger and how leaders can claim them. Leader rewards follow a two-step procedure:
-1. When a new epoch $`e`$ starts, the unique reward pool variable for leaders is updated, increasing by the reward amount for the previous epoch $`e-1`$. This reward amount is calculated as the sum of leader block rewards from epoch $`e-1`$. Simultaneously, consensus nodes update the voucher set, adding vouchers of leaders from epoch $`e-1`$ to the global voucher set.
-1. From epoch $`e`$ onward, leaders can exchange their vouchers for shares of the rewards pool, as their vouchers are now in the set. Each unclaimed voucher represents an equal share of the leader rewards pool.
+1. When a new epoch $`e`$ starts, the unique reward pool variable for leaders is updated, increasing by the reward amount for the previous epoch $`e-1`$. This reward amount is the leader share of the block rewards settled for epoch $`e-1`$, together with the Execution priority fees of that epoch. Simultaneously, consensus nodes update the voucher set, adding vouchers of leaders from epoch $`e-1`$ to the global voucher set.
+2. From epoch $`e`$ onward, leaders can exchange their vouchers for shares of the rewards pool, as their vouchers are now in the set. Each unclaimed voucher represents an equal share of the leader rewards pool.
Claimable rewards remain stable during an epoch because the reward pool decreases proportionally to the number of unclaimed vouchers, and the pool is neither increased nor are new vouchers added to the set during an epoch. The share being a whole number of tokens, it is rounded down, so two leaders claiming during the same epoch may still differ by one token, the last claimants of the epoch being the ones receiving the extra token. The remainder of the division is left in the pool and redistributed at the next epoch.
@@ -203,8 +206,8 @@ The [Service Reward Distribution Protocol](bedrock-service-reward-distribution.m
In this section we provide references to the core specifications that define the mechanisms introduced throughout this document. Together, these specifications form the foundation of the Logos Blockchain cryptoeconomic model by detailing how fees are collected, how rewards are determined, and how incentives align across different roles in the network. Below is a short overview of each:
-- [Block Rewards](block-rewards.md). Outlines the KPI-based reward emission model that governs leader and Blend rewards. It details how emission from the reserve rewards pool adapts to network conditions using inferred stake and fee-inflow rates, ensuring sustainability, security, and downward pressure on circulating supply when demand is high.
-- [Execution Market](execution-market.md). Describes the fee mechanism for execution resources, including the use of a dynamic base fee and priority tips. It explains how execution demand is smoothed over time, how fees are routed into the rewards pool and later distributed as rewards, and how the system mitigates manipulation risks while maintaining predictable costs.
+- [Block Rewards](block-rewards.md). Outlines the reward model that governs leader and Blend rewards. It details how the block's fees are passed through in full, and how the release from the reserve adapts to network conditions using the inferred total stake alone, bounding emission per block and per year for as long as the reserve lasts.
+- [Execution Market](execution-market.md). Describes the fee mechanism for execution resources, including the use of a dynamic base fee and priority tips. It explains how execution demand is smoothed over time, how the base fee is routed into the rewards pool and the priority fee to the leader reward pool, and how the system mitigates manipulation risks while maintaining predictable costs.
- [Storage Markets](storage-markets.md). Defines the transaction fee mechanism for the Permanent Storage market. It introduces a timeframe-based model where prices are fixed during an epoch and adjusted smoothly between them, ensuring predictability for users while allowing the market to adapt to long-term trends.
These documents serve as complementary technical references, offering the deeper mathematical and procedural foundations that support the economic model described here.
@@ -213,7 +216,7 @@ These documents serve as complementary technical references, offering the deeper
As a general overview, and to prepare the reader before embarking in the study of these documents, we will highlight here the conceptual differences between the Execution Market and the Storage Market, since they operate under distinct economic logics even though both rely on fee mechanisms:
-- Execution Market Pricing is more reactive and adaptive, with the base fee updated every block using a smoothed demand signal. The system uses a dual-component fee structure: a protocol-defined base_fee and a priority_fee (tip) defined by the user setting the transaction's gas price. It is explicitly anchored to a target utilization (50% of gas limit, similar to EIP-1559) and a hard maximum gas per block, ensuring the network remains operable on minimal hardware. Both base and priority fees are initially routed into the rewards pool, but the priority fee is later distributed back as part of leader rewards, providing a clear, strategy-aligned mechanism for transaction inclusion and incentivization.
+- Execution Market Pricing is more reactive and adaptive, with the base fee updated every block using a smoothed demand signal. The system uses a dual-component fee structure: a protocol-defined base_fee and a priority_fee (tip) defined by the user setting the transaction's gas price. It is explicitly anchored to a target utilization (50% of gas limit, similar to EIP-1559) and a hard maximum gas per block, ensuring the network remains operable on minimal hardware. The base fee is routed into the rewards pool and settled to leaders and Blend nodes at the epoch boundary, while the priority fee is routed to the leader reward pool and settled to leaders alone, providing a clear, strategy-aligned mechanism for transaction inclusion and incentivization.
- Storage Markets Pricing is designed to be predictable and stable over a timeframe. Fees remain fixed within an epoch and are updated only at the transition to the next timeframe. This creates a single-component fee that is straightforward for users. While the mechanism has an anchoring point $`T_\text{base}`$ , it is not built around strict capacity limitsunlike execution. Instead, it prioritizes robustness and predictability, with parameters (such as the clipping factor) chosen to filter out volatility and keep pricing agnostic to short-term demand spikes.
Taken together, these distinctions show how the storage market emphasizes stability and medium-term predictability, while the execution market emphasizes responsiveness and short-term allocation efficiency, each addressing the unique constraints of their underlying resources.
\ No newline at end of file
diff --git a/docs/blockchain/raw/storage-markets.md b/docs/blockchain/raw/storage-markets.md
index 483a6368c..8a3074fb8 100644
--- a/docs/blockchain/raw/storage-markets.md
+++ b/docs/blockchain/raw/storage-markets.md
@@ -26,6 +26,7 @@
| 1.0.2 | Fix invalid python indentation due to github migration | 2026-07-27 |
| 1.1.0 | Round the price update upwards and align the reference code with the zero target guard | 2026-07-28 |
| 1.1.1 | Changing from burning/minting to pooling/distributing/releasing | 2026-08-25 |
+| 1.1.2 | Align every block-reward reference with [Block Rewards](block-rewards.md) 1.2.0. No change to the price mechanism. | 2026-08-27 |
> **Disclaimer:**
> This material, including any linked pages or documents, is provided for informational purposes only. It does not constitute investment advice, a solicitation, or an offer to buy or sell any securities, tokens, or other financial instruments, nor should it be construed as legal, financial, or tax advice.
@@ -55,7 +56,7 @@ Justification. As will be discussed later, the tradeoff between adaptability and
The proposed fee mechanism operates on a simple but powerful principle: the price for Logos Blockchain Storage is fixed and predictable within a given timeframe (epoch for Permanent Storage), but it adjusts smoothly between timeframes based on observed network usage.
-When a user submits data, a fee is calculated based on the Logos Blockchain Storage Gas consumption. This fee is determined by a price per Gas, $`P_{storage}`$, which is known in advance for the entire timeframe. The collected fee is routed in full into the network's shared rewards pool, the same pool that funds block rewards (see [Fee Routing](#fee-routing)).
+When a user submits data, a fee is calculated based on the Logos Blockchain Storage Gas consumption. This fee is determined by a price per Gas, $`P_{storage}`$, which is known in advance for the entire timeframe. The collected fee is routed in full into the network's shared rewards pool, the same pool in which block rewards accrue (see [Fee Routing](#fee-routing)).
At the end of each timeframe, the protocol tallies the total amount of Logos Blockchain Storage Gas that was stored. It compares this actual usage to an adaptive target a "healthy" usage level that is itself a dynamic blend of a long-term policy goal and recent historical usage. Based on whether the actual usage was above or below this target, the price $`P_{storage}`$ for the next timeframe is adjusted slightly up or down.
@@ -96,15 +97,15 @@ $$
### Fee Routing
-Each Logos Blockchain Storage fee $`F_{\text{storage}}`$ is routed in full into the network's shared rewards pool at the moment its transaction is included, rather than paid to any participant or removed from supply. This is the same pool fed by the [Execution Market](execution-market.md) and drawn down to pay leaders and Blend nodes.
+Each Logos Blockchain Storage fee $`F_{\text{storage}}`$ is routed in full into the network's shared rewards pool at the moment its transaction is included. This is the same pool fed by the base fees of the [Execution Market](execution-market.md). It is emptied at each epoch boundary, and the settled amount is split 40% to leaders and 60% to Blend nodes, per [Block Rewards](block-rewards.md).
-Aggregated over a block, the Storage fees of its transactions form the Storage-market component of the per-block pool inflow $`R_{block}`$ used to compute block rewards:
+Aggregated over a block, the Storage fees of its transactions form the Storage-market component of that block's gross fee inflow $`R^{\text{block}}`$, the quantity carried into the block reward by [Block Rewards](block-rewards.md):
$$
\hat{R}_{\text{storage}} = \sum_{t \in \mathcal{B}} S_{\text{gas}}(t) \cdot P_{\text{storage}}(s) = P_{\text{storage}}(s) \sum_{t \in \mathcal{B}} S_{\text{gas}}(t),
$$
-where $`\mathcal{B}`$ is the set of transactions in the block, $`S_{\text{gas}}(t)`$ is the Logos Blockchain Storage Gas consumed by transaction $t$, and $`P_{\text{storage}}(s)`$ is the fixed price of the enclosing timeframe $s$. The Execution market contributes the remaining component of $`R_{block}`$, the pooled base fees $`\hat{R}_{\text{pooled}}`$ (cf. [Execution Market](execution-market.md)), giving $`R_{block} = \hat{R}_{\text{storage}} + \hat{R}_{\text{pooled}}`$. This pooled inflow is distributed to leaders and Blend nodes through the reward mechanism of [Block Rewards](block-rewards.md). The Storage market governs only the price $`P_{\text{storage}}(s)`$; the routing and subsequent distribution of the resulting fee are defined by the block-reward mechanism.
+where $`\mathcal{B}`$ is the set of transactions in the block, $`S_{\text{gas}}(t)`$ is the Logos Blockchain Storage Gas consumed by transaction $t$, and $`P_{\text{storage}}(s)`$ is the fixed price of the enclosing timeframe $s$. The Execution market contributes the remaining component of $`R^{\text{block}}`$, the pooled base fees $`\hat{R}_{\text{pooled}}`$ (cf. [Execution Market](execution-market.md)), giving $`R^{\text{block}} = \hat{R}_{\text{storage}} + \hat{R}_{\text{pooled}}`$. This inflow is distributed to leaders and Blend nodes at the epoch boundary through the reward mechanism of [Block Rewards](block-rewards.md). The Storage market governs only the price $`P_{\text{storage}}(s)`$; the routing and subsequent distribution of the resulting fee are defined by the block-reward mechanism.
### Protocol Constants