Hi all,
I’ve added a new draft PR to make the base fee uncapped
Thoughts?
Cheers,
Darren
4 Likes
So I was talking to Tony about this.
The most simple way to achieve this is to perhaps just change the divisor from 255 to be 1. This maintains backwards compatibility and also reduces the code changes. The base fee coefficient would remain bounded between 0 and 255 however this range would be sufficiently large enough.
The reason for increasing the range for the base fee coefficient is to provide network participants with the ability to give higher priority to their transactions. With the current implement network participants are bound to twice the gas price, 0.42 VTHO.
With the alteration suggested here, replace the divisor with 1 instead of the current value of 255, a network participant has an upper bound of 53.76 VTHO.
Calculations above are using a gas price of 21000 for a VET transfer as an example.
The current formula is:
Transaction Fee = Base Gas Fee + ( Base Gas Fee * ( Base Fee Coefficient / 255 ) )
The proposed formula is:
Transaction Fee = Base Gas Fee + ( Base Gas Fee * ( Base Fee Coefficient / 1 ) )
2 Likes
I like the idea and think moving to an ‘uncapped’ fee schedule mostly holds benefits.
Following up on the comment by @brettski, the proposed formula doesn’t make the base fee uncapped but only allows it to be 128 times higher as the current transaction fee formula, as far as I understand.
Would there also be the option of practically removing the upper bound of fees while staying close to the current framework by changing the denominator of the current proposed formula?
Transaction Fee = Base Gas Fee + ( Base Gas Fee * ( Base Fee Coefficient / .1^18 ) )
Theoretically there remains an upper bound, but this way, practically it will be unattainable.
1 Like
Correct uncapped is incorrect with the proposed implementation a cap remains it is just increased from the existing 2x cap to a 128x cap.
Worth exploring your proposal of modifying the denominator below 1.