Skip to content
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 endpoint to enable estimation of inclusion fee #105

Closed
namankumar opened this issue Mar 18, 2024 · 6 comments
Closed

Add endpoint to enable estimation of inclusion fee #105

namankumar opened this issue Mar 18, 2024 · 6 comments

Comments

@namankumar
Copy link

What problem does your feature solve?

As a transaction-submitting developer, I need a way to estimate inclusion fee so that I can be sure my transaction will make it into the next ledger.

What would you like to see?

An endpoint that returns an inclusion fee, where the value of the fee is such that it maximizes the probability of the transaction making it into the current ledger while minimizing wasted XLM.

What alternatives are there?

N/A

@namankumar
Copy link
Author

Notes:

  • this endpoint could potentially be a field returned by simulateTransaction.transactionData as well... I'm open to both possibilities cc: @janewang
  • docs should be updated to suggest best practices for using the endpoint
  • the logic to compute the value of inclusion fee is TBD
    • Ethereuem geth looks 20 blocks behind and only considers the cheapest 3 transactions for each block, choosing the 60th percentile. 20 blocks is likely too long for Soroban

@janewang
Copy link
Collaborator

We already proposed doing this from the RPC spec and I'd like to include what we actually want to build in the ticket description. Mind let me create the ticket?

@namankumar
Copy link
Author

Feel free

@namankumar
Copy link
Author

Another idea that came up while discussing with Jane. We can simplify the MVP even more: use the same logic as fee_stats but filter out soroban tx for the new endpoint

@janewang
Copy link
Collaborator

Closed in favor of #114

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants