We've recently been working on an autotask that is triggered when a certain event is emitted, and then sends a detailed summary of the transaction where it happened. We are using a sentinel that triggers the autotask when the event is detected.
As part of that summary, we would love to understand the gas cost of executing the transaction. In Polygon, it's rather easy. The transaction has the following properties gasUsed, effectiveGasPrice, so it's easy to take it from there. Now, in Optimism, it's not that easy. I checked, and the following properties are available:
We are basically listening to a specific event with a sentinel, and we then execute an autotask that will send a notification to us (in Telegram) with information about the transaction.
The transaction itself is a multi-swap, so the caller is basically providing multiple tokens in exchange for multiple others in return. As part of the notification we want to understand the tokens that were involved, but we also want to understand if it was profitable.
We basically calculate profit by doing: profit = value(tokens reward) - value(tokens provided) - transaction gas cost
We could already calculate the value of the tokens involved, and we could easily calculate the transaction cost in Polygon, but it's a little trickier in Optimism. In Optimism, the gas cost is: gas cost = gasPrice * gas + l1gasUsed * l1GasPrice * l1FeeScalar
The transaction body that is available to the autotask already provides: gas, l1gasUsed, l1GasPrice and l1FeeScalar. But we didn't have gasPrice
It would be great if it was also available on the body itself. Right now, we are making an extra call eth_getTransactionByHash to fetch said data.
I'm not sure if that answers your question, but I'm happy to provide more details if necessary
I was asking because we're currently managing this field as an only-internal field and I wanted to see if there's something our users can use it for, and this definitely helps, so we appreciate it a lot.
Regarding exposing this through our endpoints, I don't think it'll be accurate enough since we're using it only to allocate the relayer balance to the extra potential cost, so we don't send txs the relayer won't be able to pay for. In this context, there might be a few blocks in difference from what's actually priced to what we estimated it would be priced, also, we are not saving it by parts (l1GasUsed, l1GasPrice, l1FeeScalar), just the total (extraCost)
Still, we may reconsider exposing it sometime, but definitely, this feedback helps. We will get back to you in case we expose it.