Description
We can have Airseeker send transactions in a way that reverts if the update is not warranted (according to the update parameters.) This way, incorrect RPC provider responses wouldn't cause redundant updates. This doesn't mean much, as the concern there is draining the sponsor wallets, and reverting transactions still spend gas.
Generally speaking, a change that would result in all data feed updates on a chain going out from the same msg.sender (i.e., a global gas sponsorship scheme) should be avoided because sequencers are vulnerable to spam, and they utilize methods including throttling individual accounts to combat that.
One scheme I can think of this:
- Sponsor wallets of each active data feed sign an EIP-7702 authorization pointing to a contract of ours (say ContractX)
- Any third party can use this authorization to call the respective sponsor wallet as if it's a ContractX
- ContractX does the following:
- Updates the data feed
- Reverts if the data feed update was not warranted (if so third party loses gas funds because they sent a reverting transaction)
- Sends the transaction cost back to the caller + a potential reward
This all could already have been done by deploying sponsor contract for each data feed (or rather an implementation and clones). EIP-7702 only enables that we can do all that while keeping the funds in the EOA sponsor wallets, and we wouldn't need to deploy a contract per data feed, only a single implementation that will be authorized. On the downside, authorizations are single use (they have nonces). That sucks because
- We would need to serve a new public, live endpoint to serve authorizations
- Airseeker would need to keep track of the nonce, which means this doesn't provide protection from RPC issues (arguably you can ask the user to provide the nonce but that opens up the endpoint to spam)
I tried to come up with ways EIP-7702 can help our case (specifically data feeds/OEV) but couldn't. Feel free to add your own thoughts.