[Secondary Proposal] AirSigner(MEV-Airnode) Development

AirSigner Proposal

Team: AirSigner

Period: 3 months from date grant is distributed

Amount: 24,000 USDC

Destination: 0xA3a413d7536F28c811518649B1c93d5d25fCB790 (hardware wallet managed by doge_bull)

Summary:

This proposal requests funding for the development of an auction mechanism on top of Airnode designed to monetize for MEV. This will be implemented as an open source API that data providers may run alongside Airnode. This API will host sealed bid auctions at frequent intervals to assign the right for third parties to perform Beacon updates with signed data. The proposal is written by doge_bull who will be managing the project.

Abstract:

Oracles can extract MEV by bundling data feed updates with other state changes like liquidations into the same transaction. This service will use Airnodes signed data gateway to offer rights to update Beacons to the open market of searchers. Ensuring separation of the oracle and searcher roles helps avoid vertical integration, while regular public auctions increase competition and transparency, both helping to mitigate the centralising forces of MEV. High competition between searchers maintains the security of the dapp, while helping most of the value flow back to them as can be seen with MEV-Geth auctions trending towards 95% of available value paid to auctioneers (miners).

Motivation:

This service should increase the adoption of Beacons by lowering the costs for dapps, and increasing the revenue for data providers. Oracles serving Maker, Compound, and Aave on Ethereum mainnet alone forfeited a lower bounds estimate of $15,800,000 in MEV from May 21st to June 21st (calculations at the end), which helps show the size of the industry. It will also make Beacons more responsive to volatility by removing the necessity for deviation thresholds to be crossed to perform an update. Lastly it will act as a public good by moving gas price bidding wars off chain, reducing negative externalities of MEV.

Specification:

  • AirSigner will be an API implemented in Python that runs alongside an Airnode instance. Searchers can submit sealed bids to this API along with the associated request parameters for the respective Beacon, and at regular intervals it will assign a winner of the auction to the highest bidder. It will then make an HTTP request to the Airnodes signed data gateway with the parameters provided from the winning bid, and re-sign the values returned in the signature along with the bid amount and the wallet address of the bidder.
  • Only the winning bidder will be allowed to view the API response for that auction round. So that AirSigner access will not act as a substitute to API access for the underlying data provider, and searchers will have to separately purchase that to participate effectively.
  • This response can then be used by searchers to update the beacon using functions updateBeaconWithSignedBid/updateBeaconSetWithSignedBid that will verify that the msg.sender of the tx is the winning bidder, and the value paid to the data provider is higher than the bid amount signed for (as well as the original functionality of the updateBeaconWithSignedData and updateBeaconSetWithSignedData functions).
  • To prevent denial of service attacks AirSigner will not allow searchers to win two auctions in a row, and will revoke api-keys of searchers who propose winning bids and consistently fail to execute the corresponding Beacon update.

Drawbacks:

  • Searchers who access AirSigner could use it to have first rights to MEV on every protocol that uses that beacon. We could get around this if we had to by having a provider deploy a second beacon instance using a second wallet specifically for the protocol that wants to take part.
  • Added complexity and extra software for data providers to run. These risks can be mitigated with a slow rollout across providers and beacons.

Deliverables:

  • AirSigner.

  • PR on DapiServer.sol to add updateBeaconWithSignedBid and updateBeaconSetWithSignedBid functions.

  • Articles and documentation on the service.

  • Data collection/monitoring software for the service.

Timeline:

  • 3 months

Requested Funds:

  • Lead Developer: elementalBrian, salary: 8k per month

Calculations:

  • These are a bit rough but should serve as a decent lower bounds.

  • Source: Dune on 06/21/22.

  • I took total debt covered in the last month and multiplied that by 5% (lower bounds liquidation incentive) to get the total profits extracted. This number assumes searchers do not need to bribe block producers as they cannot be frontrun due to the data being signed for only them to update the Beacon with.

Explanation of Proposal Parameters:

  • Target contract address is the USDC token contract address, which is 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
  • Target contract signature: transfer (address, uint256). This is the function to call on the target contract, which triggers a transfer of USDC tokens.
  • The parameters stated include the address these USDC are to be sent to, which should match the proposal address, followed by the number of USDC. USDC has 6 decimal places, and solidity is unable to deal with decimal places - hence we add 6 zeros after the proposed USDC number. The number of decimal places can be verified on the USDC contract page of Etherscan - $1.00 | USD Coin (USDC) Token Tracker | Etherscan
3 Likes
University Vote
  • For
  • Against
  • Abstain

0 voters

That sounds really cool! Do you have any other resources I could look into to learn about MEV in the context of oracles? Your summary was good, but I still think part of it went over my head.

Sure this article expands on the proposal more.

Thanks, I’ll take a look!