-
Notifications
You must be signed in to change notification settings - Fork 497
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
Add fee suggestions to /fee_stats
endpoint
#926
Comments
Just to get on the same page:
And of course, all the information we use to calculate these numbers is readily available so consumers can choose any other combination. @MonsieurNicolas can you take a look at the numbers above and? |
Potential revised: {
"last_ledger": "22658657",
"last_ledger_base_fee": "100",
"ledger_capacity_usage": "0.38",
"min_accepted_fee": "100",
"mode_accepted_fee": "100",
"p10_accepted_fee": "100",
"p20_accepted_fee": "100",
"p30_accepted_fee": "100",
"p40_accepted_fee": "100",
"p50_accepted_fee": "100",
"p60_accepted_fee": "100",
"p70_accepted_fee": "100",
"p80_accepted_fee": "100",
"p90_accepted_fee": "275",
"p95_accepted_fee": "475",
"p99_accepted_fee": "8000",
"fee_recommendations" : {
"low" : 100,
"medium" : 200,
"high" : 475
}
} I think the above creates sufficient sufficient separation between general stats and opinionated recommendations. But also open to a completely different endpoint. @tomquisel ? |
I think we shouldn't do it. Normal users will (should) never interact with this endpoint directly and developers should take other things into consideration when setting fee (ex. Exposing opinionated values here will discourage developers from thinking more about how they should set the fees in their apps. They may also think that it's kind of a golden standard for fee selection but it's not. |
Adding to @bartekn : I would stay clear of raw recommendations, provide data that allows people to take real decisions and make tradeoffs for their use case. Maybe we should be more explicit (by use of grouping), on the timelines for all these things: {
"last_ledger": "22658657",
"last_ledger_base_fee": "100",
"stats": {
"ledger_count": 5,
"ledger_capacity_usage": "0.38",
"min_accepted_fee": "100",
"p10_accepted_fee": "100",
"p20_accepted_fee": "100",
"p30_accepted_fee": "100",
"p40_accepted_fee": "100",
"p50_accepted_fee": "100",
"p60_accepted_fee": "100",
"p70_accepted_fee": "100",
"p80_accepted_fee": "100",
"p90_accepted_fee": "275",
"p95_accepted_fee": "475",
"p99_accepted_fee": "8000"
}
}
percentiles: [
[ 10, 100],
[ 20, 100],
[ 30, 100],
[ 40, 100],
[ 50, 100],
[ 60, 100],
[ 70, 100],
[ 80, 100],
[ 90, 275]
] if we were flipping things around, the data would look something like this (truncated at 50th percentile): percentiles: [
[ 50, 275],
[ 60, 100],
[ 70, 100],
[ 80, 100],
[ 90, 100],
[ 95, 100]
] alternatively use a dictionary, but iterating over a dictionary when looking for ranges is not very natural. |
I agree that experienced stellar developers should be mindful about fees and devise their own strategies. I also think that not all (probably most) developers fit in that bucket and by not suggesting strategies we're sending them to the extremes (min fee, 99th percentile, absurdly high numbers, etc.). As a reference, ethgasstation is a common tool in the ethereum ecosystem for fee strategies. @MonsieurNicolas regarding format and |
@bartekn yeah we need to make sure it's clear in the api that these recommendations reflect the present and people should be mindful about transactions that will be submitted in the future. |
OK, so I am starting to warm up to the idea of having values that are directly usable by clients (ie, clients just need simple tweaks to use them, like pad those values even more). I think we need to dig deeper on this though: Using priorities "low", "medium", "high" can be a mechanism for that. What they actually mean is what we should define better: using percentiles from past transactions as a way to define them is actually not useful as what people care about is chances of success for future ledgers without overbidding. Maybe we should just map them to the criticality of the transactions and clearly explain the limitations so that we can change the algorithm used to compute those things without breaking the contract. I think that the way to frame it is probably by attempting to expose the trade off being made: bid more to have a higher chance of getting included in the next 3 ledgers or not. That said - there is something I am struggling with here:
|
See the discussion in stellar/js-stellar-sdk#233.
Add the following fee preset suggestions to the response from
/fee_stats
as Tomer suggested:This provides recommendations that are easy to use, and are implemented centrally rather than requiring reimplementation in each SDK.
When this is finished, be sure support for fetching these gets added to JS, Java, and Go SDKs.
The text was updated successfully, but these errors were encountered: