Introducing the Stablematic On-Chain Market Maker

What the hell is this?

Good question. In this post I present the specification for an on-chain market maker with useful properties to MKR holders. It is similar to uniswap in some ways, and distinct in others. This is only a specification and description of how such a contract could work. I have done no development work (nor do I really plan to, I don’t have the expertise.)

Why should I care?

Another great question. The mechanism I’m proposing has the following properties.

+ A uniswap-like contract that only deals in stablecoins, open for any liquidity provider to earn fees without the risk of large ‘impermanent’ losses due to severe price movements.
+ Provides an approximate on-chain answer to the question ‘what do market makers inventories look like?’
+ Allows MKR holders to react to changing Dai supply/demand balance before it affects the peg.
+ Provides an new source of income for MakerDAO.
+ Incentivizes MKR holders to keep the price within a ‘Target Range’ as opposed to accepting larger oscillations above and below $1.
- Unlike uniswap, it cannot guarantee to always have liquidity.

Important Definitions

Target Range - The maximum range at which Dai should trade versus other stablecoins.

Variable Price Liquidity Percentage - The share of liquidity that is available for trades within the target range.

Liquidity Reward - Equivalent to uniswap’s fee, this goes to providers of liquidity.

Stability Reward - When trading inside the bounds of the target range this is used to burn MKR. At the bounds of the target range, this reward goes to providers of liquidity.

What are the differences from Uniswap?

This system is similar in many ways to uniswap. For those that don’t know how uniswap works, I suggest reading up on that before diving into this. Unless specified, assume parity with uniswap.

First the easy-to-understand ones

  • Dai is the base currency.
  • It will only trade Dai versus other stablecoins.

And now the more complicated…

The algorithm within the target range

The algorithm in this contract would work differently from uniswaps ‘constant product’ system. Let’s assume that the Target Range is 1%, this means that we allow Dai to trade against USDC at between 0.99 and 1.01.

The price varies from 1:1 when the inventories are exactly equal, to 1:0.99 or 1:1.01 when the Variable Price Liquidity Percentage (VPLP) has been depleted. Within the target range, the price is set proportionally based on the amount of VPLP that has been used. Allow me to illustrate with some examples:

Say the VPLP is set at 20%, and we start with 1000 Dai and 1000 USDC within the liquidity pool (and that we’re ignoring the affect of trading fees.)

At 800 Dai, and 1200 USDC, the price of Dai is 1.010 USDC.
At 900 Dai, and 1100 USDC, the price of Dai is 1.005 USDC.
At 1000 Dai, and 1000 USDC, the price of Dai is 1.000 USDC.
At 1100 Dai and 900 USDC, the price of Dai is 0.995 USDC.
At 1200 Dai and 800 USDC, the price of Dai is 0.990 USDC.

Outside the target range

So what happens to the liquidity after we reach the edge of the target range? Answer: We stop changing the price.

In this contract the price is always within the bounds of the Target Range. After the Variable Liquidity Percentage is depleted, the price stops changing, remaining at 0.99 or 1.01 in our example above.

At this point, trades are still permitted at this price until the inventory for one token is completely depleted.

The effect of enforcing the Target Range is to provide a ‘buffer’ of Dai available at a certain price. Provided the contract holds significant liquidity, this buffer will hold the Dai price within the Target Range across the whole market by providing an arbitrage opportunity for traders. But only until the liquidity is entirely depleted.

MKR Token Holders have until the liquidity is depleted to adjust the Stability Fee or the DSR to fix the macro-scale supply/demand imbalance. Not only that, but the size of the contract inventory, and the speed at which the inventory is being depleted provides valuable information as to the magnitude of the required changes in the DCS parameters.

While the VLPL is depleted, the Stability Reward is re-directed to the liquidity providers. This helps to incentivize MKR Holders to maintain the macro-scale supply/demand balance within the Target Range and rewards liquidity providers to make up for the fact that they could be making more money by trading outside the Target Range in another market.

A few notes

  • The more liquidity this contract contains, the more effective it is at stabilising the Dai price within the Target Range.
  • We would need to make sure that the fee is competitive with uniswap from the perspective of liquidity providers. That said, this contract has an advantage over uniswap in that more liquidity is available for trade at a specific price point because we are not using the constant-product model.
  • The higher the VLPL, the less each trade changes the price of Dai within the target range, however this comes at the cost of having a smaller ‘buffer’ once the VLPL is depleted.
  • Setting of the Target Range and VLPL parameters can be done as part of MKR governance. An MVP version of this contract could allow a mutlisig to set these values. The Stability Reward should not be modifiable by MKR governance, it should be a fixed percentage of the Liquidity Reward and should change proportionally to the Liquidity reward.

Feedback is very welcome, it’s quite possible I’ve missed some terrible incentive misalignment. Going forward I think a system like this would be beneficial to stabilize the Dai price, but I lack the expertise to create it myself. If anyone with that expertise thinks likewise I’d love to discuss it further.

I also have no idea in which forum category this fits. I’ve put it in Governance just because.


After the Variable Liquidity Percentage is depleted, the price stops changing, remaining at 0.99 or 1.01 in our example above.

I think you should continue to think about this mechanism. If the real market price moves outside of the range you are suggesting, then your system will both have liquidity dry up (because it will be profitable to arb away all inventory) and will stop providing an accurate price of Dai.

Instead of trying to corral market participants into providing liquidity in a range, I think it would be more fruitful to think about how you can provide tools to speculators to bet that the future price of Dai will revert to the peg, thus increasing liquidity. For example, if there was some sort of Dai Future, that let speculators bet on the future value of Dai with leverage, you could encourage market participants to provide additional Dai liquidity. Additionally, such a future would provide additional information about market expectations enabling Maker voters to make better decisions.


Thanks for taking the time to respond, but I think there may have been misunderstanding about the goals here (possibly I wasn’t clear).

This is essentially the entire point of the contract. While the liquidity will absolutely dry up as it is arbed away, the speed and extent of this drain is a signal that can help MKR holders determine the magnitude of SF and DSR changes.

Again with the price of Dai, the idea of the contract it to defend the price within a range. It provides a price, that price is part of the market, the more liquidity in the contract, the more ‘accurate’ that price will be as it has more weight in the market. It’s meant to be a buffer to the price, and it’s effectiveness is dependent on the size of that buffer.

I am absolutely cognizant that with sub $1,000,000 liquidity this contract will not be especially effective for the signalling aspect, as the liquidity will be drained too rapidly.

Luckily for us, this tool currently exists (at least to some extent)! Dydx offers margin long and short on their DAI/USDC market. It’s not an explicit futures instrument, but it does allow speculators to bet on the return to the peg with leverage.

1 Like

I once inquired if a version of Uniswap could do this job. The answer I got was that the gas cost was too high. Since gas cost is paid in ETH you also need some of that in order to have the bot running. Maybe there are steps that can be taken to reduce gas costs.

Thanks for writing this great post!

It absolutely makes sense in my mind to utilize infrastructure similar to this if possible asap. However I am wondering if it makes sense strategically for MakerDAO to take on this task or if it would be possible to “outsource” this task to other organisations? I have been thinking the same about oracles. Some of this infrastructure might be too important to “outsource”. However if secure and DECENTRALIZED market making and oracles will exist (outside MakerDAO) in the future would this not be an ideal scenario so that MakerDAO can focus all its resources on governance of the peg(s)? However much I would like an increased number of revenue streams for MTHs don’t we risk putting too many complicated tasks under the responsibility of MakerDAO?


I’m not sure that gas cost is that much of an issue, at least I don’t see why it would be more of an issue than for uniswap generally.

There are steps that can be taken to reduce gas cost though, from general best practices to stuff like Gas Token

So this is a good point, it’s not really necessary that this system be under control of MKR Holders. The advantage is that we can change the ‘Target Range’ and the ‘Variable Price Liquidity Percentage’ as spreads become lower and volume increases. If not MKR Holders doing this, who would we be comfortable delegating this to? Alternatively it can remain fixed at 1% or 0.5%.

Likewise, it’s not 100% necessary to award MKR Holders a reward for keeping Dai within the target range, we’re incentivized to do this anyway. Sending that share of the reward to liquidity providers would further incentivize liquidity.

On a more general note, I think that ultimately MKR Holders are going to have more and more responsibilities thrust upon them in the coming years. I think this is fine, we will figure out how to delegate responsibility safely. I expect this will take the form of ratifying teams to take responsibility in different areas. We’re already seeing this with risk and oracles. Potentially you could have a market maker team that administers this contract, although there is not a huge amount of work that would need to go into it, so it’s probably overkill.

I don’t like the abrupt “end” of liquidity at 0.99/1.01.

But I think, I came up with some Vyper-math-compatible solution. In brief, I seem to have derived an invariant (double-checking though) where most liquidity is concentrated close to 1, but it gradually falls off to the infinity. It has analytical solution for y(x) or x(y).

So the question is: would it be useful to have a system which guarantees liquidity up to the infinity, however most of it is around 1.0? Should I continue thinking in this direction?


You can also use things like gas relayers, there are already deployed on Mainnet

And there is actually working Mainnet deployment
Also it is decentralized (anyone can register as relayer and SC can choose if he trusts relayer or not)

More on the topic:

I’m not a creator of solution, just user of it :slight_smile:

I must say that was also my worry first second after reading.

You put significant high risk and oportunity cost on Liquidity providers by doing so you need to provide significant fee for which there is no room for (since by nature two stable coins will be traded with small margins)

Great post, sorry for the slow reply (I was away).

I think, if In understood correctly your intentions, that the whole idea builds on the following key point:

Incentivizes MKR holders to keep the price within a ‘Target Range’ as opposed to accepting larger oscillations above and below $1.

This is the key aspect, I believe, to discuss.

Question: Do we want to add game-theoretic incentives directly at the level of Maker (e.g., using the SF as you propose), to enforce good behaviour?

As somebody already pointed out, long/short (mature and with liquidity) platform on the DAI/USDC pair should already provide stability, given that MKR holders are trusted by the market to maintain the peg.

I personally have the feeling that the incentives, for MKR holders, are already there: keep the peg at 1:1 or die and lose a lot of value.

I personally feel (but I am not sure) that, if we can keep the peg 1:1, we don’t need new functionalities at the level of Maker contracts (e.g., using SF, etc). The efficient market will automatically help us to keep the peg close to 1:1 with small oscillations (short/long platforms, insurances, etc)

Is it true that Stability Reward is Part of Liquidity Reward ?

So when trades are being made in range part of a fee goes to burn MKR and when is outside of range all goes to Liquidity Providers?

I think what should be incentivised during trading out of range is providing missing stable coin.

Also I have a question:

Is liquidity being added/removed in same way as in Uniswap (proportional to current proportions of collateral in pair) If so Additional liquidity do not make much sense in situation of imbalance and if no there should be some reward for providing liquidity during imbalance

because side that is providing missing (more valuable at the time) collateral to common pool should be rewarded for doing so otherwise it takes a loss.

I would suggest that once (after some trade ) pool goes out of a range
block number when it happens is noted and once that happens addLiquidity accepts only adding liquidity on one side and there is additional reward for liquidity provider proportional to multiplication of

  1. amount of missing collateral (outside a range)
  2. amount of time since range was broken
  3. amount of collateral provided by liquidity provider

That introduce kind of auction mechanism,
if amount is immediately provided there is almost no reward (since time is very small).

If situation is critical (lot of missing collateral to restore balance) reward is bigger.

and also reward is proportional to amount of provided collateral

OK the part that the liquidity dries up needs a cushion as it can happen unbelievably fast and we know that governance is slow.

I have a suggestion to add cushion. Currently, as you said, Uniswap liquidity providers lose when prices move in one direction as we all know. I suggest, making the trading fee variable. For example instead of 0.3 percent flat, we can make it 0.3% + (cushion)*weighted_sum(the amount each liquidity provider would lose as a result of the trade) which is then distributed based on pool share. This will help liquidity providers (here, MKR holders) buy some time by increasing the “cushion” parameter before they can make a decision. The “cushion” parameter makes the price changing trade/arbitrage on the platform less profitable and will work as a brake.

I agree and have a solution for this! Please see my reply here.

Welcome to the forum @michwill! Thanks for responding.

I think the abrupt end is a unavoidable trade-off to get the signalling properties, that said, this is pretty interesting, I don’t suppose you can elaborate on how this works? It would be a pretty big improvement on uniswap (I think?) and also this specification from the perspective of liquidity providers.

In a general sense, I would say yes this is useful, keep working on it!

Yes and no. Opportunity cost, yes, this would be a passive investment and wouldn’t compete with more actively managed options. Not sure that I agree that it is higher risk, I’d argue it’s lower risk than uniswap for example. To be clear, I don’t expect this to outperform Market Makers running their own arbitrage bots. That said, I do think it would be better than:

  • Depositing Dai or USDC on uniswap (no risk of price movements in Eth, also fee is 0.06% because it hops through Eth.)
  • Depositing Dai and USDC on a uniswap fork with Dai as the base currency and with no other changes. (There is more liquidity available around $1 here because we are not using constant product.)

While it’s true stablecoins are traded with small margins 0.03% of a dollar is only $0.0003. Current spread on dy/dx at time of writing is $0.0053. In my experience this is not an unusual spread.

It’s difficult to judge the amount of volume that this contract would pick up, but yes, incentive for liquidity providers might be a problem.

It doesn’t, at least not currently. Part of the problem is that shorts are more painful than longs when trading margin due to the differing rates on Dai and USDC.

In my view, this contract would help make the market more efficient, it’s very much a short-term buffer that could help to improve stability. It does nothing for long term trends. The SF changes handle long term trends quite well, but they do seem to fall short on short-term movement. This could help solve that problem (possibly.)

How exactly would you do this? (And yes you are correct in your understanding of the Stability/Liquidity reward.)

I did think a bit about this, but it becomes quite complicated. The way to reward people from doing this would be to provide more ‘pool share’ tokens for adding liquidity in the missing stablecoin. Unfortunately, this then dilutes everyone else’s share.

I’m also not sure that this is actually beneficial. People would just buy Dai from other markets and sell it to the contract. That doesn’t help stability. The ultimate goal is not to keep the contract ‘full’ the ultimate goal is to improve Dai stability. The contract helps this by providing an on-chain signal of the pressure on the peg and providing a buffer to maintain the price within a range in the short term.

If Dai is trading outside the ‘Target Range’ and the liquidity is depleted, there is nothing more the contract can do. At that point it’s up to the stability fee to effect change.

Welcome to the forum @mohsenghajar!

100% Agree, in order for this to work for any length of time (1 week, 2 weeks, depending on the cadence) it will need a lot of liquidity. I would suggest that 10+% of the total Dai supply would be optimal. If the incentives are enough I don’t feel that this is entirely impossible to achieve. Much more Dai has already been lent on Compound.

You could do this and I think you’re right, it would work as a brake. Interesting idea!

‘Braking’ the liquidity drain may or may not be a good thing though. The advantage is that it draws out the liquidity and allows people to trade with the contract for longer, the downside is that it makes the buffer less effective at holding the Dai Price within the range.

The objective of this contract is to hold the dai price within the target range for as long as possible. If you move the target range then you just acting in the same as any other market maker. The key advantage to this specification is that it potentially lets us make appropriate and measured SF changes before the peg breaks beyond a Target Range. No system we currently have gives us that quality.

True. But how would you stop other exchanges to enable dai/usd trade when you are off-peg and halting trade? IMO it’s only good to know more ahead and buy time until the governance can decide on what to do without handing over the dai/usd exchange to some other entity.

I prefer to put my code where my mouth is (really, not that hard to do). I was having a long flight, and during that I derived an invariant replacing Uniswap’s xy = const.

The hint is this. You have Uniswap-style rebalancing if you have xy = const (where x is number of tokens X, and y is number of tokens Y). If you have x + y = const, you have a constant price (1) and that’s it. It is possible to have some invariant f(x,y) in between those two.

Will probably put something here once ready

Has anybody looked at, github repo?

1 Like

Hi there. Have you made any progress on the concentrating variant? Sounded like a really interesting idea.