Provide transaction queue at the raw transaction level to help developers make decision regarding inclusion fees

[janewang]

We'd like to ask Core to provide real-time data on the confirmation latency of mempool transactions at a ledger block level, specifically the average time it takes for a transaction to be included in a block. This information could be exposed downstream to the RPC.

Our interest lies in accessing mempool transactions within the captive core, necessitating the exposure of this data at the raw transaction level rather than in aggregated form. By acquiring this data, we can establish a correlation between inclusion fees and transaction processing time.

This correlation will assist developers in making informed decisions regarding inclusion fees based on the speed at which transactions are included in the ledger.

[anupsdf]

Hi @janewang, Can you elaborate a bit more on the problem we want to solve? I am not sure how useful it would be to Provide mempool transactions at the raw transaction level so want to understand the problem a bit more.

What might help here is the minimum inclusion fee for all Soroban transactions that is currently published when a block is confirmed. We could have these two scenarios,

• When NOT in surge pricing, we will see 100 stroops as minimum inclusion fee. Raw txn level inclusion fee won't help here.
• When in surge pricing, we will see the minimum inclusion fee of all Soroban transactions in the set. Raw transaction level inclusion fee won't help since each individual transaction's inclusion fee could be very different (equal or higher) than the entire set's min inclusion fee. This min inclusion fee would vary every block during surge pricing depending on the set chosen.

[janewang]

We're seeking to generate predictive statistics regarding possible time required for inclusion of transactions on to the ledger on within a specified timeframe. To achieve this, we aim to compile a list of transactions currently in the mempool and arrange them in descending order by inclusion fee. By doing so, we can calculate probablistically the anticipated time for a transaction to be included in the ledger. For instance, with two Soroban transactions on a ledger, we can determine the most probable time for a transaction to be incorporated into the ledger.

Separately the mempool can help developers understand what is happening with in-flight transactions. There are products like mempool explorer which allows devs to see the state of a mempool and its pending transactions and provide useful features like estimating fee rates and ETA on unconfirmed transactions. It further provides insights to when to speed up / bump an unconfirmed transaction which are useful not just developers but also defi users.

@sydneynotthecity and I are looking for raw transaction level data to be able to gain some insights into the mempool.

[MonsieurNicolas]

The mempool in Stellar does not work like other chains: the view you get from a local node won't really help you estimate "time to inclusion". The system is designed to perform fast feedback loops. When the network is congested, the best path forward is to use historical inclusion fees from the past few ledgers to estimate the next ledger inclusion fee. If a transaction is given a high fee it should be included in the next couple ledgers with high probability.