Whitelist MEV bots after oracle updates

Hey everyong ! Here is an idea I’ve been thinking about during the last weeks.


One of the core innovation of the core module is that we allow minting and burning at oracle rate + fees. This creates risks and opportunities:

  • we cannot let the protocol trade at an incorrect price so we have to keep significant fees
  • we create arbitrage opportunities at each oracle update as we change our internal price for our stablecoins.


To better extract the value generated by the system to the benefit of the DAO, we could decide to automatically pause the protocol after an oracle update for 1 or 2 blocks, and let only a list of whitelisted address minting and burning.

Then, these adresses would have to give back say 75% of the revenues generated by the arbitrages with the DAO, otherwise we would remove them from the whitelist spots.

I suggest that we try this with the EUR/USD oracle, which is usually updated a few times a day.


Implementing this would require only a small twist in the oracle contract so shouldn’t be difficult. Basically “if an oracle update just happened, check that the tx.origin is in this list”


The main risk is that the protocol would frequently be paused for 1 or 2 blocks, but on the other side this setup would increase security: in case an oracle messes up, all the extractable value would be required by known agents. It could be seen a first step towards a reduction of the fees.


A rough backward estimation of the revenue this would generate is ~50k$ / year (considering only EUR / USD), but shows that the revenue would be very volatile depending on market conditions. This could significantly change.

Looking forward to hearing your tough on this !

1 Like

I think it’s important to keep the permissionless nature of minting and burning, so my concern is with having a whitelist. Also, a major feature of agEUR, imo, is the guarantee that you can always get out of agEUR with a max slippage of ~0.5%. I got burned by using ibAssets from K3pr, not realizing there was no redemption mechanism, so now I am stuck with it because there is not enough AMM liquidity to get out without a ton of slippage.

Maybe it’s possible to slightly modify this proposal to only allow whitelisted addresses to use flashloans in the minting/burning process, and keep the ability of normal minting/burning for everyone else (I’m not sure if that is technically possible). Any other ideas on how to do this while maintaining the minting/burning function for normal users?

To clarify, the proposal would only consist in having the whitelist in 1 or 2 block after each oracle update, just enough for the arbitrageurs to act, so it shouldn’t change anything for normal users as 99.9% of the time the whitelist won’t be there.

Thanks for clarifying this. In that case, I think this is a good idea!

Hey everyone! Looking forward to supporting this proposal.

About us

We (propellerheads.xyz) develop and maintain StabilityKeepers. And we have most of the infrastructure in place to support this proposal.


  • The whitelisted account that captures the value can be controlled by Angle
    • And could e.g. be secured by multi-sig
  • Trades will execute through a router contract
  • Oracle updates are monitored by a StabilityKeeper
    • After every Oracle update the StabilityKeeper calculates the optimal swap route to adjust agEUR on all pools to the Oracle price.
    • The StabilityKeeper uses Flashloans and so only needs ETH for transaction fees.
  • This does not create any dependency between Angle and the StabilityKeeper. If it fails, is offline, or does not act, normal redemption & minting resumes after 1 block.


  • Recapture value that is currently lost from Angle and LPs to miners / bots.
  • Ensure a tight peg to the Oracle price on all agEUR pools under any market condition.
1 Like

Hey :slight_smile:

This proposal doesn’t really go in the direction of an “unstoppable and permissionless” protocol but it does address an important issue and comes up with a decently elegant solution so I’m in favor of it :slight_smile:

One thing that immediately comes up to my head is: how do we ensure the whitelisted bots actually behave in a correct manner? As you mentioned “in case an oracle messes up, all the EV will go to known agents”. But say an a 1M EV opportunity comes up: how will we enforce the money transfer from the MEV bots?

Do you envision some kind of a KYC and a DAO vote to accept newcomers? Or would it be a legal document from AngleLabs to the other bot companies? Curious to hear how exactly we can enforce that :slight_smile:

It’s a very good question. What I had in mind was just a private KYC without legal documentation, just to make sure we know which address belong to whom so we are sure every player is doxxed, but it may actually not be enough

Well imagine you KYC me. There’s a 1M-3M arbitrage opportunity. I make it, but don’t give anything back to Angle. What are you going to do? Sue me? But there’s no contract, so how can you win? And what if the KYC person is, say, in another country, with less regulation?

I don’t think we really have a workaround around this, as Angle is a DAO so it does not have a legal entity. If it’s only an arbitrage, then there is nothing much we can do aside blacklisting the address. In case it’s an “exploit” due to some kind of oracle failure, then agEUR holders could fill a class action or follow the procedure to recover funds from a hack, which is still far better than an exploit from a tornadoed address

Basically the system I propose is not bulletproof, but still better than the current one

We can propose a trustless solution for this:

  • Profits always go to an EOA controlled by the AngleDAO.
  • The executor EAO is whitelisted as tx.origin, but can only execute transactions, not receive profits.

We already implemented and tested it this week. So would be ready to use this, if this is preferred.

Hey @Prope1er , thanks for participating in the solution!

One small comment to clarify, this setup isn’t trustless per se: the SwapContract called by the ExecuterEOA could be modified, and a different split of profit be sent to the protocol ProfitEOA.