BLOCK-REWARDS
| Field | Value |
|---|---|
| Name | Block Rewards |
| Slug | 199 |
| Status | raw |
| Category | Standards Track |
| Editor | Frederico Teixeira [email protected] |
| Contributors | Filip Dimitrijevic [email protected] |
Timeline
- 2026-05-29 —
67e498e— chore: fix math issues (#350) - 2026-05-28 —
d45eed2— Chore: mirror blochain specs into github/mdbook (#347)
Revisions History
| Version | Changes | Date |
|---|---|---|
| 1.0.0 | Initial revision. | 2026-04-24 |
Disclamer: 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.
All information regarding project details, token design, distribution mechanisms, technical parameters, and any forward-looking statements is preliminary and subject to change without notice. No representations or warranties are made as to the completeness or accuracy of the information herein.
Nothing in this material should be relied upon for investment or business decisions. Recipients of this information assume all risks associated with its use and are responsible for seeking independent professional advice regarding any actions based on it.
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.
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.
Building on previous work in blockchain economics, this specification proposes a dynamic token emission system that calibrates LGO issuance according to network Key Performance Indicators (KPIs). The system uses two primary metrics: inferred total stake (as a security indicator) and average burning rate (to maintain supply equilibrium).
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 (), control responsiveness factors, and target metrics for network security.
The conclusion of our analysis indicates that this KPI-based emission model should achieve several important outcomes:
- Initially higher emission rates (capped at annually) to bootstrap network participation.
- Gradual stabilization of token supply as the system matures, with our baseline simulation showing just total inflation after years.
- Self-regulating mechanism where token issuance naturally adjusts to compensate for burned 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.
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.
Key Principles
The design of the rewards system reflects three architectural constraints unique to Logos Blockchain:
- Unlinkability: Block proposal and reward collection are intentionally decoupled for privacy, meaning rewards cannot be assigned to a single proposer.
- Fee burning: All transaction fees (execution base fees and permanent storage fees) are burned, 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.
These principles ensure that the system is censorship-resistant, manipulation-resistant, and aligned with long-term network incentives.
Requirements
Building upon the requirements for Logos Blockchain's block rewards system, the implementation will establish that all transaction fees are burned 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 burning of tokens will be balanced by compensatory emissions over time.
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”.
Crucially, any metric-pegged reward system should aim toward a target value or equilibrium point, creating predictability and stability in the token economics.
High-level System Design
The system dynamically adjusts token emission based on two primary KPIs:
- Inferred Total Stake: Measures network security by tracking the total amount staked against a target threshold (e.g., of TGE supply).
- Average Burning Rate: Tracks transaction fees (both Execution base fees and Permanent Storage) burned to maintain supply equilibrium.
A control function combines these KPIs to determine the emission rate factor, bounded between a minimum and maximum annual issuance. This ensures that:
- When security participation is below target, higher issuance attracts more validators.
- As usage increases and fees are burned, emissions adjust downward to stabilize supply.
The equation that defines the amount of block rewards is given by:
where:
- is the emission rate factor on a per year basis.
- is the maximum emission rate per year.
- denotes the token supply at Token Generation Event (TGE).
- denotes the fraction of year in one time step per e.g., epoch, block, or day.
- be the average number of block proposal within units.
- denotes the total amount of Execution base fees and Permanent Storage fees that are burned when the block is proposed.
Lifecycle Phases
The system is designed to evolve through different phases:
- Bootstrap Phase: Initially higher emission rates (up to 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 burning rate.
- Equilibrium Phase: Supply stabilizes with issuance matching burned fees.
- High-Adoption Phase: If burning exceeds maximum emission, supply becomes deflationary.
Benefits
This KPI-based approach delivers several advantages:
- Self-regulating mechanism that automatically adjusts to network conditions.
- Long-term sustainability with projected total inflation of just after years (assuming constant burning rate of per year).
- Built-in safeguards against manipulation through moving averages and bounded functions.
- Predictable economic model that balances security incentives with controlled supply.
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.
Construction
The proposed mechanism implements a dynamic token emission system that precisely calibrates LGO issuance according to network performance metrics (KPIs). This adaptive model adjusts emission 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:
- denotes the token supply at Token Generation Event (TGE).
- denotes the maximum allowable token supply (hard cap), if any.
- denotes the fraction of year in one time step per e.g., epoch, block, or day:
- if the time step is 1 day, then .
- if the time step is 1 block every seconds, then .
- if the time step is 1 epoch, which lasts 7.5 days, then .
- be the average number of block proposal within units:
- if the time step is 1 day and blocks are proposed every 30 seconds, then (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 (the number of 30 seconds intervals in 7.5 day).
- is the minimum emission rate per year (default: ).
- is the maximum emission rate per year (default: ).
- denotes the target value for the -th KPI.
- denotes the weight of the -th KPI in the normalized deviation from target or in the normalized average; it satisfies .
- denotes the control responsiveness to KPI deviation metrics.
- denotes the control responsiveness to KPI average metrics.
- be the number of periods in the look-back window for the moving average.
Let us define the following variables:
- denotes the token circulating supply at time .
- denotes the emission rate factor on a per year basis.
- This implies that denotes the emission within the time-step.
- denotes the -th key performance indicator at time (e.g., TVL, staked amount, active users).
- denotes the total amount of Execution Gas and Permanent Storage fees burnt in a block. Refer to 🔀[1.0.0] Execution Market and 🔀[1.0.0] Storage Markets for how to compute .
Parametrization
| Symbol | Definition | Default Value | Explanation |
|---|---|---|---|
| | Token supply at TGE | 10 billion LGO | N.A. |
| | The number of periods in the look-back window for the moving average. | | As the system is expected to mint 1 block every 30 seconds, this look-back window defines that the minting averages the fees burned in the last hour. |
| | Denotes the control responsiveness to KPI average metrics. | | This parameter drives the token emission from the burn rate. It must be one-to-one. |
| | Denotes the control responsiveness to KPI deviation metrics. | | See [1.0.0][Analysis] Block Reward Parameter Calibration, for details. |
| | Denotes the weight of the -th KPI in the normalized deviation from target | | There's only one KPI of this type in our system. |
| | Denotes the target value for the first KPI based on stake. | 3 billion LOGOS | of the token supply. |
| | Denotes the target value for the second KPI based on fees. | billon LOGOS | In the context of this KPI, this value behaves as a normalizer |
| | The maximum emission rate per year | | This value guarantees that, when the total inferred stake reaches , then the APY for validation is ~3.33%. |
| | The minimum emission rate per year | | This avoids inflationary token emissions. |
| | The average number of block proposal within units | | The time step was chosen so that equals to . |
| | Time step, the fraction of year in one time step (per e.g., epoch, block, or day) | | The time step is 1 block every seconds; there are 2880 blocks of 30 seconds in a day. |
The calibration of these parameters can be found in 🔀[1.0.0][Analysis] Block Reward Parameter Calibration.
Block Rewards
The amount of tokens to be rewarded in a block depends on the emission rate factor . This controls how much is minted from inflation and how much is diverted from transaction fees. The following behavior is expected:
- When the aggregate KPI is far from the target, , then the emission of new tokens (inflation) is maximized, and most of the transaction fees aren't minted back. The amount of tokens burned does not impact the block rewards in this situation. This means that the system can burn more tokens than it mints.
- When the aggregate KPI is close to the target, , then the emission from inflation is minimized, and most of is minted back for leaders and Blend nodes.
That is, what drives the source of minting is the KPI: if far from the target, the system mints new tokens; if close to the target, the system mints exactly what was burned (up to of TGE).
The emission from inflation within the time step is given by
The actual amount of tokens minted per block (because of inflation) also depends on how many blocks are expected to be proposed between and . This is expressed by the factor , as defined above.
The equation that implements the behavior above in terms of is given by:
where:
- is the emission rate factor on a per year basis.
- is the maximum emission rate per year.
- denotes the token supply at Token Generation Event (TGE).
- denotes the fraction of year in one time step per e.g., epoch, block, or day.
- be the average number of block proposal within units.
- denotes the total amount of Execution base fees and Storage fees that are burned when the block is proposed.
def block_rewards(
S_tge:float,
emission_rate_factor:float,
I_max:float,
Delta_t:float,
f:float,
D_1_t: float
) -> float:
"""
Calculate the rewards per block.
It implements equation (1).
"""
emission_from_inflation = emission_rate_factor * I_max * S_tge * Delta_t / f
emission_from_rewards = (1. - emission_rate_fator) * R_block_cur
return emission_from_inflation + emission_from_rewards
Emission Rate Factor Function
The emission rate factor determines the portion of that should be emitted based on current values of and :
where
- controls the responsiveness to KPI deviation metrics.
- is measuring the KPI deviation from targets.
- controls the responsiveness to KPI average metrics.
- is measuring the KPI average values of over the last steps.
- is the minimum emission rate per year.
- is the maximum emission rate per year.
All terms are displayed in annualized form to ease comparison.
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
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
It implies that:
- → KPI below target → should increase the token emission by a factor of .
- → KPI at target → should not change the token emission.
- → KPI above target → should reduce the token emission by a factor of .
To measure the deviation, only the total estimated stake KPI is used in this part of the computation
KPI Average
The weighted average metric is defined as
where:
- The value can be any number with the same units of .
- The factor turns into an annualized quantity. This depends on the specific KPI.
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
The weighted average metric features:
- → should increase the token emission by a factor of .
- → should not change the token emission.
- → should reduce the token emission by a factor of .
To measure the average, only the average burning rate KPI is used in this part of the computation
Key Performance Indicator(s)
KPI 1 - The Inferred Total Stake
Given the privacy features of Logos Blockchain and the fact that the token TGE supply is known, the inferred total stake is the most appropriate indicator of the system's security.
Let:
- denotes the evolution of the inferred total stake.
- denotes the total stake that is considered secure. For the blockchain to be secure, we aim for of the TGE supply.
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.

Figure 1
This happens because, when the blockchain starts, is very likely a small number compared to the target. Therefore, the equation above tilts towards (or ) 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 oscillates around 0 (or ) when oscillates around .
Let the Logos Blockchain’s security level be defined by:
KPI 2 - The Average Burning Rate
In the long run, Logos Blockchain should mint only enough tokens to compensate for the burned transaction fees.
Let
- denote the amount of Storage fees and Execution base fees burned since .
- denote the "normalizing factor" (it is the TGE supply, in this case).
This choice of "target" implies that evaluates the annualized average burning rate with respect to the TGE supply. This makes the equation above consistent.
Float Precision for Implementation
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.
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 burned fees over the look-back window. Likewise, the reward still interpolates between inflationary issuance and burned-fee compensation through the emission factor .
Because we have
and denotes the weight of the -th KPI in the normalized deviation from target or in the normalized average; it satisfies .
Therefore,
and
So we rewrite by
And by denoting
We can compute the block reward using only integers:
and
So:
So we propose a reference implementation that uses integers:
#![allow(unused)] fn main() { const A_SCALE: u128 = 120_000_000; // denominator of 1/(I_max * D1_target * Delta_t * T) const INFLATION_NUM: u128 = 62_500; // numerator of I_max * S_TGE * DELTA_t / f const INFLATION_DEN: u128 = 657; // denominator of I_max * S_TGE * DELTA_t / f const FEE_AVG_NUM: u128 = 10_512; // numerator of 1/(I_max * D1_target * Delta_t * T) const STAKE_TARGET: u128 = 3e9; fn block_reward(total_stake: u64, burned_fees_window: [u64; 120]) -> (u64, u64) { let sum_fees: u128 = burned_fees_window.iter().map(|x| *x as u128).sum(); let last_burned_fee: u128 = *burned_fees_window.last().unwrap() as u128; let a_num = STAKE_TARGET .saturating_add(FEE_AVG_NUM.saturating_mul(sum_fees)) .saturating_sub(total_stake as u128) .min(A_SCALE); let reward_num = INFLATION_NUM * a_num + INFLATION_DEN * (A_SCALE - a_num) * last_burned_fee; let reward_den = INFLATION_DEN * A_SCALE; // 60% Blend, 40% leader, with truncation applied only once per share let blend_reward = (reward_num * 6 / (reward_den * 10)) as u64; let leader_reward = (reward_num * 4 / (reward_den * 10)) as u64; (blend_reward, leader_reward) } }