ECIP 1115: Olympia L-Curve Smoothing for Long-Term Network Security

Author	Cody Burns, Chris Mercer
Discussions-To	https://github.com/orgs/ethereumclassic/discussions/530
Status	Draft
Type	Meta
Created	2025-11-15
Requires	1111, 1112, 1113, 1114

Simple Summary

This ECIP introduces an optional governance-layer mechanism that smooths a configurable portion of Treasury-held BASEFEE revenue across a future window using a deterministic L-curve. The mechanism reshapes the timing of BASEFEE-derived incentives to provide a more predictable miner revenue profile as fixed issuance declines. All parameters are fully configurable through the Olympia Improvement Proposal (OIP) process.

Abstract

This ECIP specifies a governance-layer framework for applying an L-curve smoothing function to Treasury-held BASEFEE revenue. After each block’s basefee amount is deposited into the Olympia Treasury under ECIP-1111 and ECIP-1112, a configurable portion may be smoothed across a governance-defined future window. The mechanism produces a predictable revenue schedule without altering consensus-layer EIP-1559 behavior.

Smoothed payouts are authorized solely through the Governor → Timelock → Executor pipeline defined in ECIP-1113 and expressed as standard Treasury withdrawals under ECIP-1114. All operational parameters—window length, weighting function, allocation fraction, and miner distribution policy—are set or modified exclusively through the Olympia Improvement Proposal (OIP) process.

Motivation

As Ethereum Classic’s fixed-emission schedule (ECIP-1017) continues to reduce block subsidies over time, priority fees (tips—defined in Type-2 transactions as maxPriorityFeePerGas and implicit in gasPrice for Type-0 and Type-1) remain the primary consensus-level fee mechanism for miners. These variable priority fees directly reward block producers and continue to anchor Proof-of-Work incentives regardless of how the BASEFEE is handled.

Under ECIP-1111 and ECIP-1112, 100% of the BASEFEE is redirected to the Olympia Treasury. Any decision to allocate a portion of that Treasury-held BASEFEE back to miners is optional, fully governed through OIPs, and intended to complement—not replace—the priority fee market.

If the Olympia DAO elects to direct a percentage of Treasury-held BASEFEE toward long-term network security, those BASEFEE-derived allocations will inherently fluctuate with network activity. A smoothing mechanism can reshape the timing of these optional allocations, reducing short-term volatility and providing a more predictable payout profile without altering consensus-layer incentives.

Critically, the smoothing framework allows Ethereum Classic to experiment with security-budget policies incrementally and empirically. Rather than setting hard monetary rules (as was done with ECIP-1017) without fee-market data, smoothing keeps BASEFEE-based miner incentives flexible, adjustable, and governance-driven. This design preserves consensus simplicity, avoids premature monetary commitments, and lets the network adapt as Type-2 fee markets mature post-Olympia.

Placing smoothing at the governance layer ensures the mechanism is fully optional, tunable over time, and upgradable without hard forks, while the underlying priority-fee mining incentives remain unchanged at the consensus layer.

Specification

1. Scope

This ECIP defines a governance-layer mechanism that applies a deterministic L-curve to a configurable portion of Treasury-held BASEFEE revenue after it has been deposited under the consensus rules of ECIP-1111 and ECIP-1112. It introduces no changes to consensus behavior, EIP-1559 basefee computation, block validity, or state-transition rules.

Smoothing logic operates strictly at the application and governance layer. Any payout generated by smoothing MUST be authorized through the Governor → Timelock → Executor pipeline defined in ECIP-1113 and expressed as a standard Treasury withdrawal under ECIP-1114. This ECIP does not modify Treasury access control, hash-bound proposal semantics, or the execution pathway.

ECIP-1115 specifies only the smoothing framework. All operational parameters—including the smoothing window, weighting function, allocation fraction, payout cadence, and miner distribution method—MUST be introduced, modified, or removed exclusively through the Olympia Improvement Proposal (OIP) process.

The mechanism is optional. The Olympia DAO MAY activate, adjust, suspend, or disable smoothing without requiring a hard fork.

2. Smoothing Model

The smoothing mechanism applies a deterministic weighting function (“L-curve”) to a configurable portion of Treasury-held BASEFEE revenue over a governance-defined future window. The model determines only the timing of BASEFEE-derived payouts; total allocated amounts remain unchanged.

Let B_k denote the BASEFEE revenue credited to the Treasury for block k under ECIP-1111 and ECIP-1112. Governance MAY specify a fraction f of each B_k to be included in smoothing, where 0 ≤ f ≤ 1. The smoothed portion is:

R_k = f · B_k

A governance-defined smoothing window of length N assigns a payout schedule across indices j = 1…N using a deterministic, on-chain computable weighting function L(j). The following invariants apply:

Normalization:
Σ₍ⱼ₌₁→ᴺ₎ L(j) = 1
Determinism:
L(j) MUST be fully deterministic, on-chain computable, and depend solely on governance-approved parameters.
Non-negativity:
L(j) ≥ 0 for all j.
Configurability:
N, f, and the functional form of L(j) MUST be adjustable solely through the OIP process.

The smoothed allocation attributed to offset index j for block k is:

A(k + j) = R_k · L(j)

This framework does not mandate a specific curve family. L(j) MAY be linear, piecewise linear, exponential, polynomial, or parameterized, provided it satisfies the above invariants and is fully on-chain computable.

The smoothing model defines only the timing and magnitude of intended allocations. Execution of payouts is governed separately and MUST follow ECIP-1113 and ECIP-1114 using standard Treasury withdrawal semantics.

3. Allocation Rule

For each block k, the smoothing mechanism produces a sequence of intended allocations A(k + j) for j = 1…N, as defined in Section 2. These allocations represent scheduled future payouts that MAY be initiated through standard Treasury withdrawal semantics after approval via the governance pipeline defined in ECIP-1113 and ECIP-1114.

Smoothing defines only the schedule of intended payouts; it does not create rights, claims, or automatic execution. All payouts MUST be explicitly authorized by governance through the OIP process or through a governance-approved smoothing module that prepares Treasury withdrawal calls conforming to ECIP-1114.

Multiple smoothing schedules MAY overlap. For a given target index t, the cumulative intended allocation is the sum of all applicable contributions:

A_total(t) = Σ over all k such that (k + j = t) of A(k + j)

All such sums MUST be:

Deterministic: computable solely from governance-defined parameters and the historical sequence of Treasury-held BASEFEE credits.
Non-negative: no negative adjustments or offsetting entries are permitted.
Monotonic in scope: smoothing MUST NOT withdraw or reserve Treasury funds automatically; only governance-approved actions MAY cause value to exit the Treasury.

This ECIP does not define buffering, queuing, or state-tracking requirements. Any smoothing module that aggregates intended allocations MUST treat the smoothing rule as a deterministic transformation over historical B_k values and MUST NOT modify Treasury behavior or access control. Execution of actual payouts remains exclusively governed by the Governor → Timelock → Executor pipeline defined in ECIP-1113 and ECIP-1114.

4. Miner Distribution Mechanism

Smoothed allocations define only the timing and magnitude of intended payouts. To convert these intended allocations into actual Treasury withdrawals, governance MAY designate a Miner Reward Module responsible for mapping approved smoothing outputs to specific recipient addresses.

The Miner Reward Module operates strictly at the application layer and MUST:

receive intended allocation amounts from a governance-approved smoothing module,
compute miner or mining-pool payout shares according to parameters defined through the OIP process,
prepare Treasury withdrawal calls that conform to ECIP-1114, and
rely exclusively on the Governor → Timelock → Executor pipeline defined in ECIP-1113 for authorization and execution.

The Miner Reward Module MUST NOT:

modify consensus-layer behavior,
determine miner eligibility using off-chain or discretionary authority,
read or modify Treasury state outside authorized execution,
enforce automatic payouts or reserve Treasury funds,
bypass the governance execution pipeline, or
introduce privileged roles, admin keys, or discretionary veto authority.

Governance MAY choose any miner identification or weighting method, including but not limited to:

mining pool payout addresses specified through governance,
miner self-declared payout addresses registered through open, permissionless processes,
hashpower-attestation mechanisms defined via OIP, or
any on-chain computable distribution rule that satisfies ECIP-1113 invariants.

All such methods MUST be deterministic, transparent, and fully configurable through OIP. No miner or pool obtains an automatic right to funds from smoothing; payouts require explicit governance approval and execution through ECIP-1113 and ECIP-1114.

This ECIP does not mandate a specific Miner Reward Module design. Multiple versions MAY exist over time, and governance MAY update or replace them via the OIP process without requiring a network fork.

5. Governance Integration

All parameters and operational components of the smoothing mechanism MUST be governed exclusively through the Olympia Improvement Proposal (OIP) process defined in ECIP-1113. This includes, but is not limited to:

the smoothing window N,
the allocation fraction f,
the weighting function L(j) and its governing parameters,
activation or deactivation of smoothing,
upgrade or replacement of the Smoothing Module, and
upgrade or replacement of the Miner Reward Module.

Any module that participates in smoothing MUST operate entirely at the application layer and MUST rely on the Governor → Timelock → Executor execution pipeline for authorization of Treasury withdrawals. Smoothing modules and Miner Reward Modules MUST NOT contain any mechanism for automatic withdrawal, reservation, or direct access to Treasury funds.

Governance MAY adopt, revise, or disable smoothing through standard OIP proposals. Any update to smoothing parameters MUST be:

deterministic and on-chain verifiable,
published as part of the OIP payload, and
effective only after successful execution through the Timelock and Executor.

Governance MAY replace or upgrade smoothing-related modules provided that all implementations:

preserve the invariants defined in this ECIP,
do not modify Treasury code or its access control,
do not alter consensus-layer behavior defined in ECIP-1111,
do not alter the hash-bound execution semantics defined in ECIP-1114, and
remain fully transparent, permissionless, and auditable on-chain.

This ECIP does not mandate a specific governance cadence or parameter schedule. All decisions regarding smoothing configuration, module selection, update frequency, and activation state are left to OIP-controlled governance and do not require a network fork.

6. Treasury Behavior

This ECIP does not modify the Olympia Treasury defined in ECIP-1112. The Treasury continues to receive 100% of the basefee amount for each block under the consensus-layer rules of ECIP-1111, and smoothing operates only after these deposits have been made.

The Treasury does not compute smoothing schedules, maintain smoothing state, or reserve funds for smoothing. All Treasury withdrawals—whether related to smoothing or any other purpose—MUST be authorized exclusively through the Governor → Timelock → Executor pipeline defined in ECIP-1113 and encoded as standard Treasury calls under ECIP-1114.

Smoothing modules and Miner Reward Modules MUST NOT introduce any changes to the Treasury’s access control, immutability, or withdrawal semantics. All interactions with the Treasury are limited to governance-approved execution payloads that use the existing withdrawal interface defined in ECIP-1112.

This ECIP defines no new Treasury functions and introduces no additional responsibilities for Treasury code or consensus-layer behavior.

7. Optionality

The smoothing mechanism defined in this ECIP is fully optional. Governance MAY activate, adjust, suspend, or disable smoothing through the Olympia Improvement Proposal (OIP) process without requiring a network fork or any modification to consensus-layer behavior.

Enabling or disabling smoothing does not affect Treasury deposits under ECIP-1111 and ECIP-1112, nor does it change the execution pipeline defined in ECIP-1113 and ECIP-1114. If smoothing is inactive, Treasury-held BASEFEE revenue remains available for standard governance-directed use through existing ECFP processes.

Rationale

ECIP-1115 introduces an optional mechanism for reshaping the timing of BASEFEE-derived Treasury payouts without altering Ethereum Classic’s consensus rules or the EIP-1559 transaction fee mechanism. The smoothing model is motivated by economic analyses that study the effects of distributing fee revenue across multiple future blocks—most notably the ℓ-smoothed “pay the base fee forward” mechanism described by Roughgarden (§8.3). In that model, the base-fee revenue from block k is distributed evenly across the next ℓ blocks, reducing revenue variance while preserving incentive alignment.

ECIP-1115 adapts this economic insight to the Olympia framework by applying smoothing only after the basefee amount has been deposited into the immutable Treasury under ECIP-1111 and ECIP-1112. This preserves the transaction-fee semantics of EIP-1559 while allowing the network to experiment with alternative temporal distributions of Treasury-held BASEFEE revenue. By generalizing Roughgarden’s uniform ℓ-window rule into an arbitrary, governance-defined weighting function L(j), ECIP-1115 enables the community to evaluate linear, exponential, piecewise, or other curve families as empirical data becomes available.

Placing smoothing at the governance layer rather than at consensus offers several benefits:

Consensus-layer simplicity:
The underlying transaction-fee mechanism remains unchanged across all clients, avoiding additional consensus complexity or opportunities for divergence.
Treasury immutability:
The Treasury remains a minimal, immutable vault that does not maintain smoothing state or engage in revenue scheduling logic.
Governance flexibility:
All smoothing parameters—window length, weighting function, allocation fraction, payout cadence, and miner distribution methods—can be adjusted or replaced through the OIP process without requiring new hard forks.
Determinism and auditability:
Smoothing schedules are derived entirely from deterministic, on-chain computable functions using historical BASEFEE credits. This ensures predictable behavior and allows independent verification of intended allocations.
No automatic entitlements:
Smoothing defines a schedule of intended allocations only. All actual payouts require a successful governance action and are executed through the Governor → Timelock → Executor pipeline defined in ECIP-1113 and the funding-proposal structure of ECIP-1114.

The R_k → A(k+j) construction is deliberately chosen because it captures the essence of ℓ-smoothed economic design while remaining fully compatible with Olympia’s Treasury-based governance model. ECIP-1115 offers a governance-controlled tool for reducing short-term volatility in miner incentive flows as fixed issuance declines, while keeping all changes strictly outside the Ethereum Classic consensus layer and preserving the architectural principles of Olympia.

Backwards Compatibility

ECIP-1115 introduces no changes to Ethereum Classic’s consensus rules, transaction processing, basefee computation, block validity, or state-transition semantics. All consensus-layer behavior defined in ECIP-1111 and ECIP-1112 remains unchanged, including the requirement that 100% of the basefee amount is credited to the Treasury during block finalization.

Because smoothing operates exclusively at the governance and application layer, all existing and future clients remain fully consensus-compatible without any changes.

Smoothing does not modify the Treasury contract defined in ECIP-1112 or the governance execution pipeline defined in ECIP-1113. All withdrawals related to smoothing continue to use the hash-bound, permissionless execution model defined in ECIP-1114. No migrations, state recalculations, or protocol upgrades are required for activation or deactivation of smoothing modules.

As a result, ECIP-1115 is fully backward compatible with all existing Ethereum Classic clients and has no impact on peer-to-peer networking, block production, or chain selection.

Security Considerations

ECIP-1115 introduces no new consensus-layer behavior and therefore does not alter consensus-level security assumptions. All security considerations are confined to the governance and application layers where smoothing is defined and executed.

Governance and Execution Integrity

All payouts associated with smoothing MUST be authorized through the Governor → Timelock → Executor pipeline defined in ECIP-1113. Smoothing modules and Miner Reward Modules MUST NOT contain automatic withdrawal logic, reserve Treasury funds, or bypass governance controls. Any deviation from deterministic, governance-approved execution could undermine the immutability guarantees of ECIP-1112.

Treasury Isolation

The Olympia Treasury remains an immutable vault that does not compute, store, or track smoothing allocations. Smoothing MUST NOT introduce new Treasury state, mutate existing state, or alter the Treasury’s withdrawal semantics. All payout requests MUST conform to the existing hash-bound execution model defined in ECIP-1114.

Deterministic Computation

Smoothing schedules MUST be derived from deterministic, on-chain computable functions defined through governance. Modules MUST NOT rely on off-chain data sources, external oracles, or discretionary operator input. Non-deterministic or off-chain dependencies could produce inconsistent allocations and undermine the auditability of smoothing behavior.

Recipient Identification and Fairness

Any method used to identify miners or mining pools—such as self-declared payout addresses, governance-defined recipients, or hashpower-based attestations—MUST be transparent, deterministic, and fully configurable through OIP. No module MAY introduce privileged recipients, opaque weighting systems, or off-chain veto authority.

Overlapping Schedules and Aggregation

Multiple smoothing windows may overlap. Implementations MUST ensure that cumulative allocations are computed deterministically and do not exceed governance-approved limits. Aggregation logic MUST NOT imply future claims on Treasury funds; only governance-approved executions may transfer value.

Optionality and Activation Risks

Because smoothing is optional, governance MAY activate or deactivate it at any time. Parameter changes or module replacements SHOULD be evaluated carefully to avoid unexpected shifts in payout schedules. Rapid or uncoordinated parameter changes may affect miner expectations but pose no consensus-level risk.

No Miner Entitlements

Smoothing defines intended allocations only. No miner obtains an enforceable right to Treasury funds based on smoothing schedules alone. All payouts require explicit approval through ECIP-1113 and MUST be encoded as standard Treasury calls under ECIP-1114.

Implementation Notes

This ECIP defines the framework and invariants for smoothing Treasury-held BASEFEE revenue. It does not mandate a particular contract structure or implementation strategy. The following notes provide guidance for implementers while preserving the modularity and immutability guarantees of ECIP-1112–1114.

Smoothing Module Structure

A Smoothing Module MAY be implemented as a standalone smart contract or as a set of coordinating contracts responsible for:

receiving governance-approved parameters (N, f, L(j), and related configuration),
computing intended allocations according to the smoothing model,
producing deterministic outputs that can be referenced in governance-approved Treasury withdrawal calls.

The Smoothing Module MUST NOT hold funds, modify Treasury balances, or introduce automatic withdrawal logic.

Governance Integration

All parameter updates—such as changes to window length, weighting function, allocation fraction, or payout cadence—MUST be applied through the Olympia Improvement Proposal (OIP) process. Implementers SHOULD design modules with clear on-chain parameter interfaces so governance can update configuration safely and transparently.

Deterministic Allocation Outputs

Smoothing outputs SHOULD be expressed as deterministic, on-chain computable values. Implementations MAY store intermediate results or compute allocations on demand, provided that:

output values are reproducible from historical Treasury-held BASEFEE amounts B_k and governance-approved parameters; and
no off-chain data sources, randomness, or discretionary operator input is required.

Miner Reward Module

A Miner Reward Module MAY be implemented to map intended smoothing allocations to recipient addresses. Such modules SHOULD:

support on-chain computation of payout shares,
accept configuration via OIP,
expose deterministic logic only,
prepare Treasury withdrawal calls conforming to ECIP-1114.

The module MUST NOT reserve Treasury funds, maintain privileged withdrawal authority, or depend on opaque off-chain attestation sources.

Interaction With the Treasury

The ECIP-1112 Treasury remains unchanged. Implementations MUST treat the Treasury as an immutable vault that only executes authorized withdrawal calls arriving via the Executor.

Any implementation MUST ensure:

no direct calls to the Treasury outside the governance pipeline,
no alteration of Treasury state or semantics, and
no expectation that the Treasury stores smoothing state.

Off-Chain Tools

Indexers, dashboards, or analytics tools MAY compute and display projected smoothing schedules. Such tooling is non-normative and MUST NOT be required for correct on-chain operation.

Parameter Defaults

This ECIP defines no default parameters. Implementers SHOULD assume all parameter values are unset until supplied via OIP, and SHOULD ensure contract initialization requires explicit, governance-approved activation.

ECIP-1115 builds on and extends the Olympia framework introduced in the preceding ECIPs. Each ECIP contributes a distinct layer of the architecture:

ECIP-1111 — Olympia EVM and Protocol Upgrades
Activates EIP-1559 and redirects the basefee amount to the Olympia Treasury instead of burning it. This is the source of all BASEFEE revenue available for smoothing.
ECIP-1112 — Olympia Treasury Contract
Defines the immutable Treasury that receives all consensus-layer basefee deposits. Smoothing operates strictly on Treasury-held funds and does not modify Treasury code or access control.
ECIP-1113 — Olympia DAO Governance Framework
Establishes the Governor → Timelock → Executor pipeline, which is the exclusive path through which any Treasury withdrawal—including smoothing-related payouts—must be authorized and executed.
ECIP-1114 — Ethereum Classic Funding Proposal Process (ECFP)
Specifies the hash-bound execution format used for Treasury withdrawals. Smoothing-related payouts must be encoded as standard ECIP-1114-compliant execution payloads.

ECIP-1115 introduces an optional governance-layer mechanism for applying L-curve smoothing to the BASEFEE revenue accumulated under this framework. It does not modify the behavior of ECIP-1111 through ECIP-1114 and can be activated, adjusted, or disabled independently through the OIP process.

Academic Foundation

Roughgarden, Tim.
Transaction Fee Mechanism Design for the Ethereum Blockchain (2021).
Section §8.3 introduces the ℓ-smoothed “pay the base fee forward” mechanism, in which the base-fee revenue from block k is distributed evenly across the next ℓ blocks.
ECIP-1115 generalizes this concept into a governance-controlled L-curve framework that operates entirely on Treasury-held BASEFEE after consensus-layer deposit.

Governance-Layer Precedents (EVM Ecosystem)

The design of ECIP-1115 follows established best practices from major EVM governance systems that implement delayed, scheduled, or parameterized execution at the application layer rather than at consensus. These systems demonstrate that predictable, scheduled payouts and parameterization are best handled through modular governance frameworks.

Compound Governor Bravo
Defines proposal lifecycle, delayed execution, and parameter governance via Timelock scheduling. Widely regarded as the canonical EVM governance pattern and used as a reference point for Olympia’s Governor → Timelock → Executor design.
MakerDAO (MCD + MIPs Framework)
Uses on-chain executive delays and scheduled parameter updates for monetary policy and system-wide risk parameters. Maker’s governance-layer execution mirrors the separation adopted in ECIP-1115: delayed, rule-based execution outside consensus.
Aave Governance v2/v3
Employs time-locked execution and modular governance contracts for controlled rollout of risk-parameter updates and treasury payouts. Demonstrates the viability of governance-controlled payout scheduling without consensus involvement.
ENS DAO
Uses standard Governor/Timelock patterns and off-chain metadata binding for transparent, scheduled, rule-based execution flows similar to ECIP-1114 and ECIP-1115.
Aragon OSx
Implements modular governance plugins that perform scheduled actions through permissioned executors, reinforcing the pattern of isolating scheduling and payout logic in governance rather than protocol code.

These systems collectively validate ECIP-1115’s governance-layer approach: smoothing and parameter scheduling belong at the Olympia DAO layer, not in Ethereum Classic consensus.

Treasury-Driven Funding Systems (L1/L2 Ecosystem)

Several treasuries across Layer 1 and Layer 2 ecosystems implement structured or scheduled payouts at the governance layer:

Arbitrum DAO Treasury — governance-controlled multi-stage disbursements
Optimism Governance (RetroPGF) — milestone- and impact-based payouts with staged release
Celo Community Fund — governance-controlled fee distribution with configurable cadence
Mantle Treasury — sequencer revenue managed via modular governance processes

These real-world systems show that delayed, structured, or rule-based payouts are a well-established governance-layer pattern, not a consensus-layer mechanism.

Alignment With Olympia

The governance-layer smoothing mechanism in ECIP-1115 aligns with these precedents by:

using delayed execution exclusively through a Governor → Timelock → Executor pipeline,
treating smoothing outputs as intended allocations, never automatic entitlements,
maintaining strong separation between Treasury immutability (ECIP-1112) and governance control (ECIP-1113),
enabling flexible, evolving policy without hard forks or consensus changes.

These patterns reinforce the architectural choice to implement smoothing on top of the Olympia governance system rather than embedding it into consensus-layer fee mechanics.

ECIP 1115: Olympia L-Curve Smoothing for Long-Term Network Security Source