Taking profits back from MEV bots

Angle Core module allows users to mint and burn agEUR at a 1:1 rate against collateral. As this rate is taken from Chainlink EURUSD feed, Chainlink oracle updates create an arbitrage opportunity between the agEUR price available with the Core module and the on-chain prices on the different agEUR pools.

Empirically, short after blocks where the oracle moved significantly enough, arbitrageurs profited from this opportunity to extract value from the protocol.

When Chainlink EURUSD price feed effectively brings the “correct” off-chain EURUSD price on-chain, other DeFi pools with Euro stablecoins are still priced according to the “old” EUR value: Angle may be right, but it is wrong with respect to the others.

This gap is what creates the arbitrage opportunity that MEV bots gladly come to fill it at the expense of other Angle stakeholders.

Let’s look at a simple example of how this work in practice.

A simple arbitrage example

At t0, 1 agEUR = 1 USDC, both on Chainlink and on a Uniswap V3 agEUR-USDC pool.

At t1, Chainlink updates its oracle price and 1 agEUR = 1.01 USDC . At this point, there is a moment when the Uniswap V3 pool is still priced at 1 agEUR = 1 USDC and the following arbitrage opportunity is available: 1 agEUR → 1.01 USDC (Core module), 1.01 USDC → 1.01 agEUR (Uniswap pool) resulting in a 1% profit.

While the size of the opportunity is very dependent on market volatility and oracle updates, it is straightforward to profit from.

Note that arbitrages can be potentially far more complex than simply USDC → agEUR → USDC. Other stablecoins with pools in common with agEUR can for instance be involved in the routes, like: USDC → EURs → agEUR → USDC. This arbitrage is what in fact stabilizes the price of Euro stablecoins which have pools in common with agEUR (even centralized ones).

Taking back the value from MEV bots

With Angle, we put in place a novel solution to protect the protocol from losing too much value from this situation. The mechanism involves partnering with arbitrageurs, to end up creating a beneficial tradeoff for most users and the protocol.

It consists in restricting access to the Core module (mint and burn) to only certain whitelisted addresses during two blocks (24s) after an oracle update. This essentially “offers” these whitelisted addresses the arbitrage opportunity, in return for a share of their profits to be redirected to the protocol.

In practice, this happens through the oracle contracts of the Core module which are paused for two blocks after an update of the EURUSD feed, unless the tx.origin is a whitelisted address. A KeeperRegistry contract is responsible for containing the whitelist.

Mechanism’s tradeoffs

This mechanism implies that oracle updates are delayed by 2 blocks for mint and burn transactions.

In the “good” case where whitelisted keepers share their profit with the protocol, the protocol ends up with some additional revenue, while it was making none before.

In the “worst” case where whitelisted addresses try to cheat the protocol, the protocol still ends up in the same situation as before where it is getting arb-ed without taking any profit from it.

In the end, with this new system, the protocol is almost always better off than in the previous situation. It’s worth noting that it comes at the expense of small and temporary disruption of user interactions and of breaking up the principle of neutrality.

Current implementation

Following a governance vote, this implementation was launched with a whitelisted a keeper from Propeller-Heads. Their whitelisted EOA is 0x467B1Ba078681463359A36347f717DaBa3afebf3, and the interactions are detailed in this governance discussion. Propeller has agreed to a profit split of 60% (Angle) - 40% (Propeller).

Any other keeper that would want to share their profit with us to profit from this opportunity is welcome to contact us!