MEV capturing AMM (McAMM)

Applications
20

Wow, thank you all for all the support and love this idea has gotten. It’s really great to see that first prototypes are developed on hackathons, etc. If someone continues to be interested in helping to build it, feel free to DM me.

One reason why McAMMs got so much traction is the work of Tim Roughgarden’s team: The description of Loss Versus Rebalancing (LVR). We as a community recognize more and more that LVR is an important metric for LPs and McAMMs are one potential mean to minimize LVR for LPs.

I agree with the many voices stating that we first need to find a solution for redistributing the auction proceeds to the LPs, before we can start any serious implementations.
Here, I want to share one further idea - that for sure comes with big trade-off and seems quite complex :slight_smile: .
It uses the concept of re-auctioning the right to trade first, which was first thought of by @hasu.research.

Idea for returning captured MEV to LPs:

High level idea:
The right of first execution is again auctioned off globally for all AMMs, but the auction winner - called the lead-auctioneer - has to re-auction the individual slots per AMM.
The lead auctioneer has to determine the auction winners per AMM and bundle their trades into one lead auctioneer’s transaction. This transaction contains the information of the highest bid per AMM-auction, and each AMM will receive their highest bid value as a fee for their LPs. The lead-auctioneer is required to prove that they behaved correctly with a zk-proof, afterwards.

1.0 - Centralized version:

  • Onchain, we continue to have one auction for the right of first execution for all AMMs belonging to a router.
  • However, the first transaction can not freely be chosen, but has to be crafted by the following process:

    • The lead auctioneer has to re-auction for each AMM the right to trade against this AMM first.

    • Each bidder will have to send their bids encoded as an AMM-interaction with the following information: <AMM contract, LVR compensation bid, gas-cost-refunds, trade payload, signature>

      • where LVR compensation bid is the bidding amount nominated in the AMM-pair’s ‘sell token’ - which depends on the direction the AMM is traded against - to win the right of first execution for the specified AMM contract.
      • gas-cost-refunds are an ETH amount specified by the arbitrageurs to pay for the gas cost
      • trade payload is a trade that will be executed against the AMM on behalf of the arbitrageur to capture the arbitrage opportunity. The payload will be executed from a “lead auctioneer router contract”
      • the signature is a signature from the arbitrageur for their trade.
      • (participating arbitrageurs would have to set an approval for their trade for the lead auctioneer router contract beforehand, that allows the lead auctioneer to execute their trade given their signature)

    • The lead search will compile a list of “winning AMM-interactions”:

      • the list will only have 1 entry per AMM
      • each entry must have a valid and executable payload on the latest block
      • all entries are winning: I.e., they are maximizing the LVR compensation bid on a per-pool basis.

    • The lead auctioneer’s transaction will execute the list of AMM-interactions on the lead auctioneer router contract.

    • The LVR compensation will be withdrawn from the arbitrageurs accounts and paid to LP providers in the pool as a normal fee.
      Only a small portion of the LVR-compensation will be sent to the lead auctioneer for their work. This is called the LVR compensation fee.

    • The revenue for the lead auctioneer is the sum of LVR compensations fees.
      Hence, we can expect that the first slot will be auctioned off for the expected LVR compensation fees minus the operational costs.

Challenges in this spec:
This specification requires trust in the lead auctioneer. There is no mechanism enforcing the lead auctioneer to include the highest LVR compensation bids into their transaction and not censor any transactions. This can be solved with the following spec:

1.1 Decentralized version:
We have the same setup, as described in the centralized version and additionally, we require:

  • The lead auctioneer needs to provide a bond before participating in the global auction.
  • There will be several Distributed-key-generation-validators (DKG-validators) selected by the DAO. They will generate for each auction a public key used to encrypt bids, and after the auction end -shortly before block-building -, they will reveal a private key to decrypt bids.
  • The lead auctioneer will collect the encrypted bids from the arbitrageurs.
  • The lead auctioneer will build a “commit hash”: The Merkle root of his collected bids
  • The DKG-validator will agree on one “commit hash” from the lead auctioneer, sign it off and reveal their key. This allows the lead auctioneer to decrypt the bids. Since the DKG-validators double-check the commit-hash, they act as on non-censorship oracle.
  • The lead auctioneer will decrypt the AMM-interactions, build the tx with the highest bids and send it out immediately.
  • Some blocks later, the lead auctioneer is required to provide a zk-proof that proves that their tx was built indeed correctly and the highest bids of all bids considered in the Merkle tree of the “commit hash” were included.
  • If the lead auctioneer does not provide the proof of their correct behavior, they will lose their bond.

Discussion:
Unfortunately, the 2.0 version is very complex and requires a DAO to deploy certain actors. This is suboptimal, especially since the DKG-validators can grief the auction winners by not providing their decryption keys in time. Hence, the majority of DKG-validators must be assumed to be good actors.
I think the community should definitively search for simpler and more beautiful solutions :slight_smile: .

5 Likes