-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Use floats for fee multipliers, add base multiplier #14818
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #14818 +/- ##
===========================================
- Coverage 46.48% 41.92% -4.56%
===========================================
Files 1046 874 -172
Lines 90907 80759 -10148
===========================================
- Hits 42254 33862 -8392
+ Misses 45547 43966 -1581
+ Partials 3106 2931 -175
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just flagging what I think is non-idiomatic Go; not a hard blocker for me if you need to merge soon. (But worth chatting about here or elsewhere!)
62976e2
to
48371fb
Compare
@scharissis made some changes, could you please re-check? |
Description
The fee estimator for devnet-sdk had a bit of a usability issue with it - the base & tip multipliers were defined as
big.Int
s which meant the fees could only be increased by integer multiples. This is not great as there are plenty of numbers between1
and2
(some would even say an infinite amount of numbers but those people are not working withfloat64
limitations).This PR fixes the issue and adds base multiplier besides the tip multiplier. Some libraries set this to
1.2
by default (ethers, viem) but to avoid any surprises, a value of1.0
will be used for both of these by default.On top of the changes in the logic, the functional options pattern has been used (thanks @scharissis for this)