You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the tx queue stores 2 ledgers worth of Soroban transactions, and rejects any new cheaper transactions submitted to core. As noted by @dmkozh, this is quite limiting when the network limits are very low (for example, phase 1 limits only allow 1 large Soroban tx per ledger).
We may want to increase the multiplier to allow more transactions to enter the transactions queue, in hopes of them all eventually making them into the ledger. This doesn't fundamentally solve the problem, as transactions are still at risk of being dropped due to low ledger limits (we only keep transactions around for 4 ledgers), but this change may slightly increase chances of transactions getting in, and potentially improve developer experience.
One thing to keep in mind is that rejecting a transaction right away provides better user experience, as the user immediately knows the fee that's needed to get into the ledger. Increasing the multiplier may cause core to drop transactions on the floor, without any useful feedback to the user, creating confusion. Marking this issue as "discussion" as I'm curious to hear what others think.
The text was updated successfully, but these errors were encountered:
Currently, the tx queue stores 2 ledgers worth of Soroban transactions, and rejects any new cheaper transactions submitted to core. As noted by @dmkozh, this is quite limiting when the network limits are very low (for example, phase 1 limits only allow 1 large Soroban tx per ledger).
We may want to increase the multiplier to allow more transactions to enter the transactions queue, in hopes of them all eventually making them into the ledger. This doesn't fundamentally solve the problem, as transactions are still at risk of being dropped due to low ledger limits (we only keep transactions around for 4 ledgers), but this change may slightly increase chances of transactions getting in, and potentially improve developer experience.
One thing to keep in mind is that rejecting a transaction right away provides better user experience, as the user immediately knows the fee that's needed to get into the ledger. Increasing the multiplier may cause core to drop transactions on the floor, without any useful feedback to the user, creating confusion. Marking this issue as "discussion" as I'm curious to hear what others think.
The text was updated successfully, but these errors were encountered: