🧊 [RFC] Explore a KeeperDAO Coordination facility for mStable AMM

This RFC was written in collaboration with exeggcute from KeeperDAO and @dimsome from mStable


This RFC proposes a collaboration between mStable and KeeperDAO to explore a direct integration of KeeperDAO’s Coordination protocol with an mStable AMM. The integration would create a way for arbitrage transactions to be relayed through the KeeperDAO Coordination protocol, with the vast majority (approximately 80%) of the profit generated from this arbitrage being distributed to the mStable protocol and its users or LPs.


Through the addition of a reduced- or dynamic-fee swap function only accessible to KeeperDAO Keepers, Keepers who wish to use mStable’s AMM for rebalancing and arbitrage of mAsset baskets could do so without competition from Keepers operating in the wild, who will reach arbitrage price later due to the need to pay the flat fee of the public swap function.

This small priority from the reduced fee can allow KeeperDAO Keepers to execute swaps through the far more efficient Coordination protocol, with greatly reduced settlement overhead versus the public mempool where profit is bid away to the benefit of miners.

In practice this would mean that pools with this special fee lane could be more balanced than they are today, because the more efficient rebalancing arbitrage can happen more frequently and for smaller imbalances than at present. This could make the pools more capital efficient overall.

The reduced- or dynamic-fee swap function would be restricted to KeeperDAO Keepers, because these Keepers are secured by the Coordination protocol, which protects both the interests of the Keepers and of mStable LPs. The Coordination protocol uses a just-in-time auction to discover the maximum value of any transaction executed through it, and transfers 80% of that value to the originator, in this case the mStable protocol.

So instead of fees, which these LPs are giving up to create this special swap function, the Coordination protocol will ensure that mStable receives the lion’s share of the arbitrage profits created against the mStable AMM. This would allow for arbitrage to flow back to the protocol, rather than being donated to whoever can execute the transaction or pay the most to be included in a block.

The Coordination protocol integration would require a small modification of the mStable AMM smart contract: a new function with an altered swap fee and a whitelist lookup. The rest of the function would be identical to the existing swap function. There would be a public swap and this special swap, with the only difference being that the special swap is gated by the whitelist and has a different fee, since it is only for the purpose of arbitrage/rebalancing by dedicated Keepers, and the profits generated from this are shared with the LPs of mStable.


This is a novel mechanism that creates multiple benefits for mStable, its users, and its LPs. Not only does it allow the protocol and LPs to internalize more value from arbitrage, value that would otherwise be lost, but it also allows us to improve the basket composition and weights - allowing users to mint and redeem with lower slippage. This in turn makes the basket more capital-efficient while creating an additional source of revenue.

There is no proof-of-concept demonstrating whether the returns for LPs would be similar to or even exceed returns from a flat fee. But that would be the best scenario because our markets would get more efficient, and we would be making an additional return at the same time.

This RFC asks for general comments on whether this concept is a viable venue to explore further.


  • Allows the mStable protocol to internalize more value from arbitrage. Currently, the excess profit from arbitrage goes to the arbitrageurs and miners/block producers.
  • Caters better to our core users, arbitrageurs are not considered core users.
  • Potential to create a further partnership with KeeperDAO, namely a treasury allocation towards mStable Save.
  • Creates no hard service dependency between mStable and KeeperDAO; the facility gracefully falls back to the default behaviour and the AMM would still function as intended by default.
  • Better balanced basket closer to the ideal weight and therefore less slippage for users when depositing single assets.


  • Rather a new concept
  • Would require a smart contract upgrade

Next Steps

This could be a really unique value-add for both protocols. And this RFC asks for input from everyone whether this is something that we should, together with KeeperDAO, investigate further. After positive comments, this concept would be further explored and viability accessed. We would then have a better picture of the actual benefit and look further into the details of implementation.


mStable :handshake: KD? Yes. I couldn’t be more in favor of exploring this integration further.

If this works as it says on the tin, then we’d still have keepers balancing our bAsset weights, but we would be reclaiming most of the profits on those transactions opposed to the arbitrageurs keeping them. On top of that, if this doesn’t work as planned, then the existing mechanism will still be there to fall back to – seems like a no-brainer honestly.

KeeperDAO is building ever more relevant and important plumbing services in MEV, and partnering with this big-brained team will almost certainly only bear prosperous outcomes.


I am somewhat biased since I had already a discussion with @hazard about this, but I think this is a really interesting concept for mStable to explore.

I would really see this as the first step in our collaboration. I wonder what other synergies there are when you consider playing the coordination game with all the future products that are yet to be envisioned. Thinking about a new product that has already an MEV and coordination built in, is the real potential here I see.


Thanks a lot for the write-up @hazard

Even if I was part of these discussions between Keeper & mStable, it doesn’t alter how relevant I consider this potential AMM upgrade.

  • from a pure swap optimization perspective, this new contract update is more efficient and helps the mUSD basket maintain its peg
  • It’s a way for mStable as a protocol to capture sustainable value which for now is going to arbitragers (mainly bots)

On top of this attractive opportunity, we’re in discussion with @hazard and the Keeper DAO treasury team about Stablecoin Treasury diversification/utilization ideas into mStable Save.

I would personally really love to see such a two-sided win-win partnership between our two protocols


Looks great to me. :+1:


Mutual benefit integration. Looking forward to the Coordination!


Thanks for posting this, great to see the Coordination game of KeeperDAO coming together now!

Personally, I think this is a great idea, and I think it’s beneficial to both parties, especially since our AMM is mainly used by arbitrageurs anyways, this seems to capture the elephant in the room.

Looking forward to seeing this unfold, and how KeeperDAO can collaborate with mStable in this way.


Any movement on this? Doesn’t seem to have any dissent to speak of.

1 Like

Yup, I agree, feedback is overall positive! The main concern is focus and priority, there have been tasks that are more congruent with our strategy to move mStable forward.

If by any chance you or someone can pick this up and work on this, I would gladly push the proposal forward.

This is in a nutshell what changes are required:

  • Requires upgrading contracts
  • adjust swap, redeem, mint, or add one function to figure out the path callable only for Keeper to set swapFee = 0 and pass it to the Logic (Library Contract).
  • Add function to set a keeper
  • Add modifier/or check in the function to check for keeper
  • MassetLogic library to allow accept the swapFee from the calling function

Relevant contracts:

mStable-contracts/Masset.sol at master · mstable/mStable-contracts · GitHub mStable-contracts/MassetLogic.sol at master · mstable/mStable-contracts · GitHub

Opened an Issue here: KeeperDAO Coordination facility for mStable AMM (0 Fees Swap for KeeperDAO keepers) · Issue #356 · mstable/mStable-contracts · GitHub

1 Like

I’m at the point that I could maybe write the logic (after studying the current contracts), but I know nothing about writing unit tests and haven’t had to fork mainnet for any of my other work yet. : /

If the job sits there for long enough, I’ll probably get to that point though. I was looking to Foundry for doing tests; is the project picky about what’s used for performing tests?

1 Like

Yeah, we would like to remain using the current packages, without adding any more dependencies.