BLOCK-REWARDS

Timeline

• 2026-08-26 — b655e4b — [RFC] Block Rewards: Replace Burning/Minting with Pooling/Distributing/Releasing (#375)
• 2026-07-03 — 709cf7f — Bedrock-RFC: Remove Concept of a Session (#365)
• 2026-05-29 — 67e498e — chore: fix math issues (#350)
• 2026-05-28 — d45eed2 — Chore: mirror blochain specs into github/mdbook (#347)

Revisions History

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.

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 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 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 from the reserve (capped at of the max supply 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 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.

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 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.

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 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.

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 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.

A control function combines these KPIs to determine the emission rate factor, bounded between a minimum and maximum annual reserve release. This ensures that:

• 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.

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 maximum allowable token supply (hard cap).
• 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 routed to the pending reward pool when the block is proposed.
• denotes the average pooled reward: the moving average of over the look-back window .

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 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.

Benefits

This KPI-based approach delivers several advantages:

• Self-regulating mechanism that automatically adjusts to network conditions.
• Long-term sustainability with projected net circulating-supply growth of just after years (assuming constant pooling 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 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:

• denotes the maximum allowable token supply (hard cap).
• 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 ( of ).
• is the maximum emission rate per year ( of ).
• denotes the lifetime, in years, of the rewards reserve at the maximum release rate of per year ( years).
• 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 pending rewards pool balance at time . It collects the pooled fees and funds the distributed portion of the reward.
• denotes the rewards reserve balance at time . It holds the pre-allocated tokens drawn down by the reserve release, with initial size .
• 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 routed to the rewards pool in a block. Refer to Execution Market and Storage Markets for how to compute .
• denotes the average pooled reward: the moving average of over the look-back window . It is the base distributed each block, topped up by the reserve release.

Parametrization

The calibration of these parameters can be found in [Analysis] Block Reward Parameter Calibration.

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 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:

• When the aggregate KPI is far from the target, , the reserve release is maximized: it tops up the average pooled reward , raising the reward toward the per-block release cap .
• When the aggregate KPI is close to the target, , the top-up vanishes and the reward settles at the average pooled fees , funded by recycling the pooled fees to leaders and Blend nodes.

The reserve release within the time step is given by

The actual amount of tokens released from the reserve per block 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 maximum allowable token supply (hard cap).
• 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 per-block Execution base fees and Storage fees collected in the block and routed to the pending reward pool when the block is proposed.
• denotes the average pooled reward: the moving average of over the look-back window .

The recycled component distributes the average pooled reward , rather than the single-block fee , which smooths it across the window . Rearranging equation (1) isolates the role of the reserve release:

The base distributed every block is the average pooled fees . The second term is the reserve release: when the aggregate KPI is far from the target, and the reserve release tops up the reward from toward the per-block release cap . In the bootstrap regime, where activity is low and , 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.

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

Pool Accounting and Supply Dynamics

The mechanism routes all transaction fees into a rewards pool. Let denote the pool balance at time and 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 . 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 at genesis. It is sized so that releasing at the maximum rate of per year lasts years, giving an initial balance .

The inflows and the outflow at step are:

• Fee inflow: .
• Reserve release (top-up): , drawn from the reserve and added to the payout.
• Distribution outflow, equal to the block reward: .

The reserve funds the release and is monotonically non-increasing, bounded below by zero:

Once the reserve is depleted, and the reward reduces to the recycled component , funded entirely by pooled fees. The cap on makes the reserve last years at the maximum release rate, and longer whenever .

The pool collects every fee and pays out only the recycled component, so its balance evolves as

The increment can take either sign. Near target () the pool pays the average and banks the difference , acting as a buffer that smooths fee fluctuations; far from target () it retains the full fee while the reserve release carries the reward. The pool is redistributable, subject to .

The mechanism conserves tokens across the three stocks it controls. Let the controlled total be , with the circulating supply. Per step:

The controlled total is constant: the mechanism never mints tokens. A reserve release moves tokens from into circulation, routing a fee moves tokens from circulation into , and recycling moves them back. Circulating supply rises as the reserve drains, and contracts whenever the fee inflow exceeds the distributed reward, , 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 .

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 pooling 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's maximum 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 maximum 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 Pooling Rate

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.

Let

• denote the amount of Storage fees and Execution base fees pooled since .
• denote the "normalizing factor" (it is the maximum supply, in this case).

This choice of "target" implies that evaluates the annualized average pooling rate with respect to the maximum 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 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 .

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:

import numpy as np
from numpy import int64

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)


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]

    a_numerator = np.minimum(
        np.maximum(STAKE_TARGET + FEE_AVG_NUMERATOR * sum_fees - total_stake, int64(0)),
        A_SCALE,
    )

    reward_numerator = (
        INFLATION_NUMERATOR * a_numerator
        + INFLATION_DENOMINATOR * (A_SCALE - a_numerator) * last_pooled_fee
    )
    reward_denominator = INFLATION_DENOMINATOR * A_SCALE

    blend_reward = reward_numerator * int64(6) // (reward_denominator * int64(10))
    leader_reward = reward_numerator * int64(4) // (reward_denominator * int64(10))

    return blend_reward, leader_reward