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
This is a prerequisite to working on DA block submission. We want to define the interface that the SDK teams can depend on for determining transaction fee.
Background
It costs a variable amount to post the blocks to the DA layer, we are trying to minimize that cost with DA block compression, but there are a lot of things that we can't control. Even if DA block cost was constant, the submitter may be the only submitter for that block or there may be many submitters who could share the cost. But, the cost isn't constant because ETH gas prices change.
Interface
We just want to take these things into account to give tx submitters as much visibility into and control of what there fee is going to be. And also flexibility for the implementer to find them an answer.
The text was updated successfully, but these errors were encountered:
I'm thinking the best approach is to hide the rules for determining the next block's maximum gas price, and just expose that number to any tx builders via a client endpoint.
xgreenx
added
the
epic
An epic is a high-level master issue for large pieces of work.
label
Feb 4, 2024
This is a prerequisite to working on DA block submission. We want to define the interface that the SDK teams can depend on for determining transaction fee.
Background
It costs a variable amount to post the blocks to the DA layer, we are trying to minimize that cost with DA block compression, but there are a lot of things that we can't control. Even if DA block cost was constant, the submitter may be the only submitter for that block or there may be many submitters who could share the cost. But, the cost isn't constant because ETH gas prices change.
Interface
We just want to take these things into account to give tx submitters as much visibility into and control of what there fee is going to be. And also flexibility for the implementer to find them an answer.
The text was updated successfully, but these errors were encountered: