Replacing Chainlink Fast Gas Price Oracle with Base Fee after EIP1559

Currently on Ethereum Mainnet Gelato charges a small % premium on top of the ethereum gas fees for every transaction on the network. For example, if a transaction costs $10, Gelato will charge ~$11 (~10% premium), where the profit goes to the bot operator.

In order to calculate the fee that bots can charge for transaction, Gelato’s ExecFacet.sol implements a function which a) measures the gas consumed by a certain execution and b) multiplies that by the current fast gas price (chainlink).

Now, for most use cases this works pretty well on mainnet. However on Polygon for example, there is no fast gas price oracle to my understanding and thus we have to use a fixed (e.g. 1 MATIC per tx) or dynamic (e.g. 0.2% of value which flows through tx) fee model to incentivize bot operators to execute the tasks.

Moreover, having an external oracle be used in the calculation of the “fair fees” adds an additional dependency to Gelato which we cannot control as well as adds some additional gas costs for state reads.

After EIP1559 gets merged, smart contracts will be able to access the BaseFee in solidity which we could potentially be used instead of the Chainlink Fast Gas Price Oracle. We should investigate whether we can use this BaseFee and if it actually represents (most of the time) the actual execution cost that the bot used to get a transaction mined in time.

Let’s build a first PoC that implement that and test it out to see whether fee payments can be made cheaper, more accurate and require less dependencies. It might turn out to be a worse implementation than the current one using Chainlink, in which case I am happy to just remain with our current “proven” system, but lets experiment :slight_smile:

5 Likes

Definitely worth experimenting with! I see where you are going with it being less intensive than an oracle but will need to confirm if it’s a better implementation after EIP 1559 is live.

This is a cool idea. Some naive questions:

EIP1559 is backwards compatible with old transaction types I believe (right?). Does this pose any issues for using the BaseFee as the ‘fair fee’ measure (will it work just as well on new and legacy transaction types after London?)

Also, what about the miner tip? We don’t really know how much that will come into play yet but could this make usage of the BaseFee unsafe or more complex in certain conditions?

Questions aside, I’m all for getting rid of the oracle reliance.

This seems like a natural transition assuming the speed and accuracy of calculating the fees is par for the course than using Chainlink Oracles, or faster. It will be interesting to see how the introduction of EIP1159 has an effect on overall network activity , and identify how quickly more systems move to fetch gas prices from the BaseFee if viable.

Though it’s a sensible proposal and definitely worth experimenting, thinking from the operators’ perspective, regardless of which method turns out to be cheaper, wouldn’t the operators always want the network to adopt the more expensive one so that they can get a bigger premium?

1 Like

Though it’s a sensible proposal and definitely worth experimenting, thinking from the operators’ perspective, regardless of which method turns out to be cheaper, wouldn’t the operators always want the network to adopt the more expensive one so that they can get a bigger premium?

Yes the rational operator is always incentivized to relay transactions with more expensive gas costs to receive a larger premium. In fact, this is the reason why enforcing some rule about gas prices in the GelatoDiamond smart contract (which is the top level call for all gelato tasks executed by operators) is necessary. For instance, right now we check the operator’s refund against the actual gas consumption and the chainlink oracle fast gas price, to verify that the operator is not maliciously ‘overcharging’ customers for executions. If we didn’t check gas price of execution against the gas price oracle, rational operators would use exorbitant gas prices when executing tasks to inflate their premium.

Now, if we do experiment with BaseFee as the new metric for proper execution gas pricing, and we see it gives customers a better experience (better rates while maintaining reliably fast executions) we could implement this as the standard check in the GelatoDiamond and this basically forces the operators to comply (txs that don’t comply will simply revert causing losses to the operator).

In general it is true that there could be some friction between the desires of customers (cheaper executions) and operators (more expensive executions, i.e. more profit). However operators know that if the fees that gelato network is routinely charging for automated executions is too high, the network will have a hard time finding customers, so there is some alignment as well. For now bot operators are known, whitelisted parties that have the long term health of Gelato network in mind, so I don’t expect difficulty in getting consensus around better prices for customers even if it lowers their profit margins per transaction slightly. But yes, this is important to keep in mind for the future, when onboarding bot operators is permissionless and decisions about changes to the protocol are governed 100% by on-chain voting mechanisms. In that case it will be important that voting power is well distributed among the different participants (operators, projects that use gelato infrastructure, end users, etc) so that no one POV dominates too easily.

1 Like

Thanks @kassandra.eth !! Very insightful, and spreading alphas left and right :grin:

Regarding DAO and voting, having either the customers or operators dominate the votes is generally a negative thing in my opinion, while having a tug of war between these two is not ideal either. Finding a common ground would be the key. Once Gelato scaled up to handle more (types of) on-chain activities, the quantity increase shall offset the cheaper fees for the operators.

On the other hand, though the incentive on the customers side is pretty clear: lower fees, on the operators side it may appear that they need to make a choice themselves: lower fees + more transactions vs. the opposite. So is it an idea to actually make it optional for both sides of the bargain and let the market dictate how it may develop? Then for the customers, they may need to make a choice between high fee + more operators (hence faster) vs. the opposite, while for the operators the choices become high fee + less customer vs. the opposite.

This creates another layer of economic dynamics, and may be worth experimenting once there the network is big enough.

1 Like

Would actually really like to hear some feedback on this one, especially from the team, about having two different executor markets with different but both fixed fee structures.

1 Like

Interesting thought. I think the exact business model that will arise as the dominant one is yet to be established. You are right that customers do favour “cheap” transactions and that an open market for executors in which they can individually set the fees that they are willing to charge is a good option to achieve that, however there are also a lot of other factors involved.

For example, there can only be so many transactions mined inside one block. If Executors have e.g. 20 transactions they need to execute right now, they will have to prioritise which ones to execute first. For something like this, users would actually have to “signal” in one way or another that their transactions should be prioritised. This is also an interesting property that the GEL token can handle, e.g. the more stake you as a customer have, the more Executors will incentivise your transactions over others.

Fixed fees only work on layer2s right now, on mainnet we do have to charge variable fees as the cost basis is significantly higher (underlying gas costs).

2 Likes

the more stake you as a customer have, the more Executors will incentivise your transactions over others

I’m loving this design :sunglasses: which further strengthens the utility side of the token, and a really nice layer of game theory :wink:

The gas cost seems to have emerged to be the bottleneck to the fee structure design on mainnet. I seriously don’t see it get any better. It basically kills the flexibility in implementing any premium for an execution in exchange of a faster service, since the base cost is already freaking large.

Already envisage a future where the network will be overwhelmingly more utilized on various L2s and L1s with EVM.

1 Like