This question builds on Case 3 proposed under the question of ‘Who pays for gas and how much?’ for Oyster. In this case, Users specify, in the Request, the maximum gas price that they will reimburse Gateways for sending the transaction containing the Response. It is further assumed that Gateways are unable to hedge gas prices due to the max gas price stated being insufficient to cover the cost of hedging, non-existence of such hedging markets or poor liquidity if they do.
The happy path is quite clear: as soon as it’s time for the Gateway to submit the Response, if the gas prices on the Common Chain are lower than the max specified by the User, the Gateway can use any gas price between the market gas price and the max to sign the transaction. If the transaction successfully gets included in a block before the deadline, the excess gas tokens escrowed can be refunded to the User and/or shared with the Gateway.
However, the situation gets murky when market gas prices are close to or higher than the max specified by the User. If the transaction fails to get included in a block due to any reason before the deadline, the Gateway is subject to slashing if slashing conditions only check for the receipt of Responses before deadlines.
To prevent slashing, there are three ways a Gateway can prove that it wasn’t his fault and that there was nothing it could do.
Solution 1: A list of RPCs could be whitelisted by the protocol. The Gateway enclave could then prove to have made the necessary RPC calls to propagate the Response transaction at a certain timestamp. The downsides of this approach are:
(i) the maintenance of such a whitelist
(ii) mandatory use of centralized RPC providers
(iii) reliance on the RPC provider not being malicious
(iv) designing some sort of a obscurity scheme such that the Gateway can’t selectively drop Response packets at the router level
Solution 2: A way for Gateways to prove that market gas prices were above a certain threshold in the blocks leading to the deadline. This is both hard to implement and also not full proof as transactions might not get included even at lower gas prices for reasons beyond the Gateway’s control (RPC bugs, sequencer/validator-side delays in processing mempool queue, network issues etc).
Solution 3: Protocols like Primev could potentially be used to receive signed receipts from validators indicating that they indeed received transactions for the Gateway. It is not known yet as to whether Primev or other protocols enabling preconfirmations will support such a primitive where they only acknowledge receipt of a transaction but do not necessarily guarantee inclusion.