Conversation
wjmelements
requested review from
TippyFlitsUK,
anorth,
dannyob,
jennijuju,
jsoares,
lanzafame,
momack2 and
rvagg
as code owners
Co-authored-by: Rod Vagg <rod@vagg.org>
|
@wjmelements please take number 0115 for this. Update frontmatter, filename, and README with this. |
A |
Co-authored-by: LinZexiao <55120714+LinZexiao@users.noreply.github.com>
| 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. |
There was a problem hiding this comment.
What is the behaviour of changing this parameter, and why was 1/8th chosen?
Also, what is the expected steady state? It is premium = BaseFee / 8 or the reverse?
There was a problem hiding this comment.
why was 1/8th chosen
It should be low for the reasons discussed in the rationale. Particularly, if it is too high, it can be profitable for proposers to increase it.
I originally suggested 1/9 but I thought 1/8 is rounder.
Also, what is the expected steady state? It is premium = BaseFee / 8
Yes, though steadiness is only applicable at the specified percentile.
There was a problem hiding this comment.
BaseFeeMaxChangeDenom 1/8 doesn't change that parameter.
There was a problem hiding this comment.
It could be possible to have R unrelated to BaseFeeMaxChangeDenom but it would complicate the math a little.
|
Could you please include how the switch logic should happen in implementation? What would happen if a node is running on a software with the existing mechanism post upgrade epoch? |
|
Would be good to get a technical review from @magik6k |
6 participants
This adds a FIP for the Premium Percentile Ratio proposal I described here.
CC @LinZexiao, who is welcome to co-author
Changes