Add FIP: Premium Percentile Ratio

FIPS/fip-0115.md

@@ -0,0 +1,198 @@
+---
+fip: "0115"
+title: Premium Percentile Base Fee Target
+author: William Morriss (@wjmelements), Lin Zexiao (@LinZexiao)
+discussions-to: http://github.com/filecoin-project/FIPs/discussions/1236
+status: Draft
+type: Technical Core
+category: Core
+created: 2026-02-13
+spec-sections: 2.8.19 Gas Fees
+---
+
+# FIP-0115: Premium Percentile Base Fee Target
+
+## Simple Summary
+
+Replacing the utilization-based base fee adjustment with a premium-based target will stabilize gas markets and improve tipset efficiency.
+
+## Abstract
+
+Instead of targeting 50% gas limit utilization, which is unreliable for multiple block proposers, congestion is detected by considering the ratio between the effective priority fee, called the premium, and the base fee.
+When this ratio exceeds 1/8, the base fee increases; when it falls below this threshold (or if the blocks are sufficiently empty), the base fee decreases.
+This approach aligns base fee adjustments with congestion signals, which should improve the predictability of gas markets, thereby reducing proposer duplications.
+
+## Change Motivation
+
+EIP-1559 makes predictable gas markets by providing short-term supply elasticity.
+The utilization target of EIP-1559 was designed for a system measuring gasUsed in a single-proposer system.
+In contrast, Filecoin has multiple proposers, and so its utilization depends on the tipset efficiency, determined by the decidedly unreliable independence of proposed blocks.
+
+The utilization target is a bad fit for the current multiple-proposer system, because duplicated transactions consume `BlockGasLimit` but reduce utilization.
+This is demonstrated by the base fee not spiking during periods of congestion.
+In fact, no utilization-targeting scheme can distinguish between high-duplication situations caused by stratified priority fees and those caused by inactivity.
+Consequently, base fee adjustment is not aligned with congestion.
+When the base fee does not increase under congestion, it results in unpredictable gas markets, which further stratify priority fees, further increasing duplication.
+
+This proposed change develops a new target for determining whether to increase base fee that is more suitable to multiple proposers.
+This will increase the ratio of the base fee to the priority fee, which will reduce duplication and thereby improve utilization.
+
+## Specification
+Premium refers to the effective miner tip per gas after subtracting base fee.
+
+$$ Premium_{i} = Max(0, Min(MaxPriorityFeePerGas_{i}, MaxFeePerGas_{i} - BaseFee_{curr})) $$
+
+After deduping the transactions in the tipset, sort the gas by premium.
+If the total gas limit is greater than `BlockGasLimit`, truncate the excess gas.
+If the total gas limit is less than `BlockGasLimit`, pad the premium distribution with zeros.
+The result is a sorted distribution of the premiums paid in the tipset for the top `BlockGasLimit` of gas.
+
+Percentile premium targets have two parameters.
+
+1. `P` = $20$, a percentile of the effective premium distribution to consider
+2. `R` = $\frac{1}{8}$, the ratio between the effective premium at `P` and the applicable base fee.
+
+The behavior of `ComputeNextBaseFee` will change to consider the premium $Premium_{P}$ at percentile `P` of this distribution and then calculate the next base fee using the following formulae.
+
+$$ MaxAdj = \lfloor BaseFee_{curr} * R \rfloor $$
+$$ BaseFee_{next} = Max(\lceil \frac{1}{R} \rceil, BaseFee_{curr} + Min(MaxAdj, Premium_{P} - MaxAdj)) $$
+
+## Design Rationale
+
+Prices provide information signals to market participants to inform their decisions.
+
+High premiums signal congestion, because pending transactions are competing for blockspace.
+Under congestion, the base fee should increase to price-out less-urgent transactions, to signal current demand to subsequent transactors, and to reduce net inflation.
+
+Low priority fees signal available blockspace.
+If blockspace is available, the base fee should decrease in order to signal current supply to subsequent transactors, welcome less-urgent transactions, and make use of network capacity.
+
+### Bounding
+
+The minimum possible value of $Premium_{P}$ is 0, so $BaseFee_{next}$ is bounded.
+
+$$ BaseFee_{next} \in [BaseFee_{curr} - MaxAdj, BaseFee_{curr} + MaxAdj] $$.
+
+These boundaries match the behavior of EIP-1559.
+
+The `BaseFee_{next}` minimum, $\frac{1}{R}$, ensures a positive $MaxAdj$.
+
+### Base Fee Manipulation
+
+`P` is low in order to make $Premium_{P}$ less manipulable.
+
+An individual proposer can increase the base fee by proposing non-public (and therefore unduplicated) transactions that pay themselves a high priority fee.
+The possible base fee increase per epoch is capped by $MaxAdj$.
+The cost of this manipulation is the lost priority fees plus the base fees of their non-public transactions.
+
+In the short term, such manipulation could reduce effective priority fees, increase base fee burn, and delay confirmations.
+Such griefing might increase priority fees in the medium term, but because `R` and `P` are low, this manipulation is unprofitable.
+However, this change does make upward base fee manipulation more practical than before.
+
+`R` is low to reduce the average ratio of priority fees to base fees and improve tipset efficiency.
+A low `R` reduces the profitability of upward base fee manipulation.
+
+On the other hand, downward base fee manipulation is more difficult after this change, as proposing an empty block has a negligible impact on the base fee due to truncation.
+
+### Premium Subversion
+
+Users can subvert priority fees by paying priority fees out-of-band.
+Such users might pay zero priority fees and still have their transactions included due to an off-chain subscription service or a direct payment within the transaction.
+
+Filecoin currently mitigates this with Ticket Quality uncertainty, which reduces the benefits of such coordination.
+
+Since such transactions are not in the public mempool, they are unlikely to threaten tipset efficiency.
+If priority fee subversion becomes common enough to threaten the burn, it could be mitigated in several ways.
+
+1. Require that transactions be proposed by multiple proposers.
+2. Ignore tx.maxPriorityFeePerGas and only consider MaxFeePerGas in the premium calculation.
+3. Modify tipset transaction ordering rules to execute transactions in priority order.
+
+## Backwards Compatibility
+
+Systems recommending gas prices to transactors SHOULD be updated.
+
+* `Filecoin.GasEstimateGasPremium` MAY suggest $BaseFee_{curr} * R$. The Ethereum-compatible `eth_maxPriorityFeePerGas` wraps this and would reflect the same change.
+* `eth_gasPrice` (which returns `BaseFee + GasEstimateGasPremium`) MAY suggest $BaseFee_{curr} * (1 + R)$. There is no single Filecoin-native equivalent; the base fee is available from tipset block headers and the premium from `GasEstimateGasPremium`.
+* `Filecoin.GasEstimateMessageGas`, which fills all gas fields on a message, SHOULD also be updated to reflect the new premium guidance.
+
+## Test Cases
+
+### $Premium$
+
+| $BaseFee_{curr}$ | MaxFeePerGas | MaxPriorityFeePerGas | Premium |
+| ---------------: | -----------: | -------------------: | ------: |
+|                8 |            8 |                    8 |       0 |
+|                8 |           16 |                    7 |       7 |
+|                8 |           19 |                   10 |      10 |
+|           123456 |       123455 |               123455 |       0 |
+|           123456 |      1234567 |              1111112 | 1111111 |
+
+### Tipset Gas Percentiles
+
+For `BlockGasLimit = 10_000_000_000`, suppose there were only two transactions in the merged tipset.
+
+| $Premium_{0}$ | $GasLimit_{0}$ | $Premium_{1}$ | $GasLimit_{1}$ | $Premium_{P}$ |
+| ------------: | -------------: | ------------: | -------------: | ------------: |
+|           123 |    59999999999 |           100 |    20000000000 |             0 |
+|           123 |    59999999999 |             0 |    20000000001 |             0 |
+|           123 |    59999999999 |           100 |    20000000001 |           100 |
+|           123 |    79999999999 |           100 |    20000000001 |           100 |
+|           123 |    80000000000 |           100 |    20000000000 |           123 |
+|           123 |    80000000000 |           100 |    90000000000 |           123 |
+
+### $BaseFee_{next}$
+
+| $BaseFee_{curr}$ | $MaxAdj$ | $Premium_{P}$ | $BaseFee_{next}$ |
+| ---------------: | -------: | ------------: | ---------------: |
+|                8 |       1  |             0 |                8 |
+|                8 |       1  |             1 |                8 |
+|                8 |       1  |             2 |                9 |
+|                8 |       1  |             3 |                9 |
+|               15 |       1  |             0 |               14 |
+|               15 |       1  |             1 |               15 |
+|               15 |       1  |             2 |               16 |
+|               15 |       1  |             3 |               16 |
+|              807 |     100  |             0 |              707 |
+|              807 |     100  |            20 |              727 |
+|              807 |     100  |            40 |              747 |
+|              807 |     100  |            60 |              767 |
+|              807 |     100  |            80 |              787 |
+|              807 |     100  |           100 |              807 |
+|              807 |     100  |           120 |              827 |
+|              807 |     100  |           140 |              847 |
+|              807 |     100  |           160 |              867 |
+|              807 |     100  |           180 |              887 |
+|              807 |     100  |           200 |              907 |
+|              807 |     100  |           201 |              907 |
+|              808 |     101  |             0 |              707 |
+|              808 |     101  |             1 |              708 |
+|              808 |     101  |           201 |              908 |
+|              808 |     101  |           202 |              909 |
+|              808 |     101  |           203 |              909 |
+
+## Security Considerations
+
+Concerns about gas premium subversion can be mitigated before they impact the base fee by early detection.
+Alternatively, this change could be released alongside a separate change mitigating such subversion.
+
+## Incentive Considerations
+
+While a low `R` will reduce proposer income from premiums by increasing the proportion of transaction fees that are burned, higher base fees should reduce net inflation.
+The expected reduction in premiums may be mitigated if tipset efficiency improves, due to higher utilization.
+
+## Product Considerations
+
+Base fee elasticity will improve gas utilization, increasing network throughput.
+
+## Implementation
+
+- [ ] Curio (TODO)
+- [ ] Forest (TODO)
+- [ ] Lotus (TODO)
+- [ ] Lotus Miner (TODO)
+- [ ] Venus (TODO)
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

README.md

@@ -148,4 +148,5 @@ This improvement protocol helps achieve that objective for all members of the Fi
 | [0109](http://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0109.md) | Enable smart contract notifications for Direct Data Onboarding (DDO) | FIP | Rod Vagg (@rvagg) | Final |
 | [0110](http://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0110.md) | Allow Shorter Deal Durations | FIP | Will Scott (@willscott) | Draft |
 | [0111](http://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0111.md) | Add Support for EIP-7702 (Set Code for EOAs) in the FEVM | FIP | Michael Seiler (@snissn), Aarav Mehta (@aaravm) | Draft |
+| [0115](http://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0115.md) | Premium Percentile Target | FIP | William Morriss (@wjmelements), Lin Zexiao (@LinZexiao) | Draft |