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 applies a deterministic L-curve to a governance-selected portion of Treasury-held BASEFEE revenue across a future window, only if smoothing is explicitly activated through an OIP. The mechanism reshapes the timing of BASEFEE-derived incentives to provide a more predictable miner revenue profile if governance elects to use smoothing for miner payouts; this ECIP does not mandate such use, and smoothing remains entirely optional. 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 operates strictly after consensus-layer deposit into the Treasury and produces a predictable revenue schedule without altering consensus-layer EIP-1559 behavior or block-processing rules.

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 to miners is optional, fully governed through OIPs, and intended only to complement—not replace—the consensus-level priority-fee incentive mechanism.

If the Olympia DAO elects to direct a percentage of Treasury-held BASEFEE toward long-term network security, governance MAY choose to route those allocations through governance-approved payouts, without creating any entitlement, expectation, or obligation toward miners or any other recipient class. These allocations will inherently fluctuate with network activity. A smoothing mechanism can reshape the timing of such allocations, reducing short-term volatility and providing a more predictable payout profile only if governance elects to activate it, all without altering consensus-layer incentives such as miner tips. This ECIP does not modify, reinterpret, or supplement the monetary policy defined under ECIP-1017; ECIP-1115 smoothing applies only to Treasury-held BASEFEE after deposit into the immutable Treasury defined in ECIP-1112, and affects solely the timing of governance-approved payouts, with no effect on issuance, BASEFEE computation, priority-fee mechanics, or any consensus-layer economic behavior.

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, miner priority fees (tips), block rewards, difficulty adjustment, 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. L(j) MUST NOT rely on off-chain data sources, randomness, or any non-deterministic process.
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 values that MAY be used as inputs to 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, reservations, implied obligations, 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—explicitly not a liability, reserve, obligation, earmark, or claim upon Treasury funds—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.

Smoothing MUST NOT imply buffering, queuing, or earmarking funds inside any contract. Only explicit governance-approved Treasury withdrawals create real movements of value.

4. Miner Distribution Mechanism

Smoothed allocations define only the hypothetical timing and magnitude of governance-controlled payouts and create no rights, claims, or reservations against Treasury-held funds. To convert any of these allocations into actual Treasury withdrawals, governance MAY designate a Miner Reward Module responsible for mapping approved smoothing outputs to specific recipient addresses. Such a module is optional, governance-defined, and MAY be used for any class of recipients—not only miners—and does not, by itself, create any entitlement, expectation, or preferential claim to Treasury-held BASEFEE for miners or any other group.

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.

Recipient identification MUST NOT rely on hashpower or mining-rate data sourced from off-chain systems, unverifiable APIs, or any non-deterministic computation.

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.

No recipient class—including miners, pools, infrastructure providers, or other groups—receives any priority, privilege, or implied preference under this ECIP. All payouts must be explicitly authorized via governance.

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.

No smoothing-related module MAY modify, intercept, or bypass the standard Governor → Timelock → Executor execution path under any circumstances.

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.

Smoothing MUST NOT add state variables, flags, or configuration references to the Treasury, nor may it require Treasury modification, redeployment, or upgrade.

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, and disabling smoothing SHALL NOT affect any historical allocations or create retroactive obligations. The default state of the system is that smoothing is inactive unless explicitly activated by an OIP.

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. The ℓ-smoothed model is referenced only as economic context and does not prescribe any specific window length, weighting function, or numerical configuration. All parameters remain entirely governance-defined.

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. Activation or deactivation of smoothing cannot cause a consensus fork under any circumstances, as smoothing operates exclusively at the governance layer.

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.

Smoothing MUST NOT introduce privileged recipients, preferred entities, or governance-exempt payout flows. All recipients must be subject to identical governance-verification rules.

Smoothing MUST NOT generate any claimable rights, future expectations, implicit liabilities, or accounting obligations against the Treasury.

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.

Failure or misconfiguration of a Smoothing Module or Miner Reward Module MUST NOT impair or delay standard Treasury operations or governance-authorized withdrawals.

No default smoothing parameters or module configurations are defined by this ECIP; governance MUST explicitly activate smoothing before it has any effect.

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 the modular Olympia framework defined across ECIPs 1111–1114. Each component provides 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. Smoothing operates on Treasury-held BASEFEE as defined in ECIP-1112, independent of transaction type or origin.
ECIP-1112 — Olympia Treasury Contract
Defines the immutable Treasury that receives all consensus-layer basefee deposits. Smoothing operates strictly on Treasury-held BASEFEE after deposit and does not alter Treasury code or access control.
ECIP-1113 — Olympia DAO Governance Framework
Establishes the Governor → Timelock → Executor pipeline, which is the exclusive path for authorizing all Treasury withdrawals, including any optional smoothing-related payouts.
ECIP-1114 — Ethereum Classic Funding Proposal Process (ECFP)
Specifies the hash-bound execution format required for all Treasury releases. Any smoothing-derived payout MUST be encoded as a standard ECIP-1114 execution payload.

ECIP-1115 adds an optional governance-layer mechanism for applying L-curve smoothing to Treasury-held BASEFEE. It does not modify 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, distributing per-block revenue across a future window to reduce variance while preserving incentive alignment.
ECIP-1115 adapts this concept into a governance-controlled L-curve applied solely to Treasury-held BASEFEE after consensus-layer deposit.

Governance-Layer Timing & Scheduling Precedents

ECIP-1115 aligns with established EVM governance patterns in which timed execution, scheduled payouts, or parameterized release windows are implemented at the governance layer through timelocks or controlled modules:

Compound Governor Bravo — canonical timed-execution model using a Governor → Timelock → Executor pipeline.
MakerDAO (MCD + MIPs) — scheduled executive actions and parameter updates via time-delayed governance spells.
Aave Governance v2/v3 — modular, timelocked execution for treasury actions and parameter changes.
ENS DAO — utilizes standard governance-and-timelock flows for delayed execution of approved actions.

These systems demonstrate that temporal control of payouts and actions is a governance-layer function, not a consensus modification—mirroring ECIP-1115’s placement of smoothing above protocol semantics.

DAO Treasury Timing & Recurring Distribution Patterns

A range of DAO treasuries implement recurring, epoch-based, or streaming payouts through governance-approved mechanisms. These patterns provide practical precedents for ECIP-1115’s role as a time-smoothing, governance-controlled payout scheduler:

Arbitrum DAO — multi-stage incentive programs and periodic distributions approved through governance.
Optimism RetroPGF — recurring, epoch-based funding rounds disbursing treasury allocations in structured intervals.
Celo Community Fund — configurable, season-based governance allocations over a defined timeframe.
Mantle Treasury programs — modular, recurring distributions from treasury controlled by DAO vote.

These systems show that temporal structuring of treasury payouts is common and governance-driven.

On-Chain Streaming & Programmatic Disbursement Tools

Modern DAOs increasingly use streaming or vesting mechanisms to smooth treasury outflows over time in a governance-controlled manner:

Superfluid — real-time streaming of grants, incentives, or salaries under DAO governance, used to distribute treasury funds over predictable intervals.
Hedgey — on-chain vesting and multi-period distribution tooling widely adopted for structured incentive programs and scheduled treasury disbursements.

These tools demonstrate that smoothing or time-distribution of payouts is now a common governance-layer pattern used to manage treasury volatility and cadence—precisely the role ECIP-1115 fills for Treasury-held BASEFEE.

Alignment With Olympia and EVM Best Practices

ECIP-1115 follows these governance-layer precedents by:

applying a parameterizable timing function (L-curve) exclusively through the Governor → Timelock → Executor pipeline,
treating smoothing outputs as governance-controlled scheduling inputs—not automatic or entitlement-based payouts,
operating solely on Treasury-held funds without altering consensus or modifying ECIP-1112 behavior, and
enabling flexible, adjustable payout policy without any changes to protocol economics.

These properties ensure that smoothing operates entirely at the governance layer, preserves the immutability of the ECIP-1112 Treasury, and introduces no consensus-layer changes.

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