Discussion on Granda Mento: Enabling Larger Stablecoin Mints

Governance
1

I wanted to kick off discussion on a potential future CGP before it gets to draft phase, and bring it up on Governance Call 7. @trevor and I have been doing some design and user research respectively on enabling larger bulk mints, potentially gated by the Governance process. Some thoughts or feedback on the following early draft, especially on the Governance involvement or limitations would be appreciated.

Overview

Mento is able to facilitate smaller trades and minting of cUSD and cEUR with minimal slippage for smaller trade sizes. However, significant slippage of over 2% starts to occur on both Mento and on centralized exchanges at trades sizes of ~$50k+. Users are forced to exchange CELO for stablecoins slowly over a longer period of time or arrange for one or many OTC trades to satisfy large demand while minimizing price slippage. Slippage on Mento is uncapped, while OTC trades typically take a hit of 2-3% in the block sizes we’re aware of. Increasing Mento bucket sizes permanently to address this need puts a more significant portion of the Reserve at risk.

Currently, cUSD can only be minted over time through Mento and via Validator rewards. Building a governance-gated process to exchange large (~$1 million+) amounts of CELO for stablecoins will enable large entities to make significant block purchases of cUSD and cEUR at scale such that the network can expand faster. This is a temporary security-optimizing solution that is being considered in the short-term for every large instance mint until Mento is reworked to support more efficient large-scale minting on a sustained basis.

Primary Users and their Perceptions

Institutional and corporate entities that desire to exchange sums of $1 million USD equivalent or more in fiat or CELO to stablecoins such as cUSD, cEUR, and future Reserve-backed currencies. Compared to other stablecoins, there is far deeper liquidity or at par redemption capabilities directly from fiat at this scale. A rate limited or high slippage trade at this scale makes it a no-go for larger players considering this option.

  • It is feasible to covert this over time, but most of these entities prefer doing it in one block trade like an OTC trade. Having to do this repeatedly is a deterrent for these users. It is not a mental model they are familiar with to spread this out into several purchases of $50k or less.
  • When the user is not already tied into the Celo ecosystem, they simply choose a stablecoin on another chain that has deeper liquidity and is easier to obtain (e.g. USDT, USDC, etc). Some users do not join Celo at all because they cannot purchase at this scale on their terms (such as on the Circle.com USDC Institutional Trading Program).
  • Newer stablecoins such as cEUR and future stablecoins have much fewer options for liquidity at this scale. OTC is not feasible.
  • Mento is perceived as an exchange and source of liquidity by these users rather than its primary function as a stability mechanism.

Proposed Changes

(Below still needs to be fully designed, but should be seen as a high level approach)

A batch exchange contract to temporarily hold CELO to be sold is to be created to escrow the funds prior to approval by governance. The escrow contract should determine a swap price before the execution phase in a secure manner that is not prone to manipulation. How we determine the swap price based on some possible combination of randomness and TWAP near submission time still needs a bit of research and design input. Requestors of large swaps should submit their CELO to be exchanged and their limits on maximum percentage slippage in either direction as inputs to this process.

Transactions in the proposal:

  1. Addition of a contract-based minter to cUSD contract
  • Destination: cUSD contract
  • Data: An additional authorized minter address
  • Value: Address of a cUSD batch exchange contract
  1. Addition of a contract-based minter to cEUR contract
  • Destination: cEUR contract
  • Data: An additional authorized minter address
  • Value: Address of a cEUR batch exchange contract

In addition, the reverse transaction to redeem stablecoins for CELO at scale will also be considered in the design to build trust in a two-way convertible system.

Risks

  • Oracle price determination: A way to deter actors from attacking price oracles at a specific block for such large swap quantities is needed to dissuade financial attacks. Adversaries may still find ways to game the exchange price to slightly more favorable terms.
  • A future version of Mento that solves large exchanges more elegantly may never be built and we may be stuck with a very manual process for longer than expected.
  • This requires quite a bit of input from Governance voters and may lead to voting fatigue if used excessively.
2

I am a bit confused what is the goal here. I see two scenarios:

#1. There is a user who has 1 million+ $-s and wants to convert it to cUSD with minimal slippage.
#2. There is a user who already has ton of CELO and wants to get access to cUSD.

I don’t think it makes sense to solve or enable any batch trade things for #2 case. Especially at the core protocol. If such large trades are needed, it would be much better if someone else were to build a decentralized auction type of thing so large buys or sells of CELO for cUSD can happen as a single batch. But overall, that shouldn’t be a concern for the core protocol itself.

As for case #1, question would be, what as an acceptable slippage and timeline for the trade?

  • I am fairly confident it is possible to trade 1 million USDT <-> cUSD at 1% premium + (whatever trading fees they would get charged on Bittrex), over just a few days at most. This is especially true for acquiring cUSD. Essentially, if you make a limit order to buy cUSD at the price of 1.01 USDT, even with an order of size 1 million, it will get filled in few days at most.
  • If we want this type of trade to happen at even lower premium, there are other things that would be more useful to do:
    • Get USD / cUSD listed on CoinbasePro
    • Decrease Mento spread from 0.005 to 0.003
1 Like
3

Strongly agreed with @thezviad that increasing exchange liquidity for cUSD/cEUR/cXOF is a healthier approach than setting up a complicated governance option. Would love to see the stable coins on large US exchanges like Coinbase Pro.

1 Like
4

It’s a bit of a chicken and egg problem with getting listed on centralized exchanges and liquidity. Generally, the larger the exchange, the higher their requirements are for a minimum market cap or trade volume before they are interested in listing a coin. Liquidity gets exchange listings, which in turn generates more liquidity. This is a potential tool that could be used to leverage our more robust fiat-to-crypto conversion ability for CELO to extend it to the stablecoins.

@thezviad it is primarily for user #1 as you mentioned who is able to plan out a month in advance this type of conversion. Some potential practical applications for these users are CBDC pilots, larger scale stablecoin grants, and scaling up stablecoin-based businesses. At this point, there is only moderate liquidity on cUSD on Bittrex, which I see as a single point of failure. cEUR is even smaller in market cap at this time and would be challenging to get significant orders filled via OTC or traditional exchanges.

5

by having more Ubeswaps? Or offering celo incentives for Ubeswap pools?

6

It’s great that there’s high demand for Celo stablecoins! But I’m not sure this is the right approach to scale up minting.

I agree with @thezviad’s comments. Having exceptional conversions that use a locked, slippage-free price feels like we’re creating a two-tiered trading system where larger traders get special treatment.

I’m also concerned with having more than 1 stablecoin minter. It’s tough to understand and predict how these multiple minters will affect each other.

Are there other solutions that could work here? In the governance call we talked about an off-chain solution of a broker gradually acquiring assets to facilitate large purchases. Also curious to hear what changes we could make to Mento to improve its scale.

1 Like
7

I view reliance on Bittrex for cUSD purchases right now as a centralized single source of failure. OTC’s aren’t particularly much better. I definitely don’t see governance involvement as a long term thing, but a stepping stone until we have something better… maybe a picture is worth a thousand words here for the constraints we’re trying to address from a market perspective.

cUSD market cap growth has mostly been pretty flat/slow after initialization, except for these periods I’ve highlighted in red.

cUSD market cap growth
cUSD market cap growth1618Ă—1207 61.1 KB

There’s likely some upper cap for tolerable market slippage that’s preventing us from growing much faster. This conversion of large amounts of CELO to cUSD over time is already happening to a degree in these red blocks above, during which time the peg has mostly kept within $1.01. The question is, would this proposed Granda Mento solution or some variant thereof help us scale from 46 million to 460 million much faster than what the current market participants are resorting to given Mento’s limitations today?

8

Linking original discussion here: Discord (copy-pasting doesn’t work well from Discord nufortunately)

9

As a wrap up point from me. I am still not convinced this is a good idea, and I would personally be opposed to it.

But if we do end up with additional mechanism anyways, my vote would go for more auction style setup instead. Something like this:

  • Governance approves that Reserve will buy X amount of CELO at the maximum price of Y cUSD.
  • Now everyone can participate in this auction, so if there are people who are willing to sell their CELO for smaller price than Y cUSD, they can sell their CELO instead. So reserve gets the best available price for buying X amount of CELO.

This means that there are no brokered deals with individual entities that want to sell CELO. But it can be used to release large amounts of cUSD (or cEUR) in circulation in a single trade.

10

I’m very much in agreement that in an ideal world, big purchases of stable tokens should not have to do with the protocol, and should be done off-chain and OTC.

One thing I think we’ve learned is that Mento was mostly as designed a mechanism to maintain stability in times of potential de-pegs where stable tokens must be burned or minted, but it isn’t a very good mechanism for minting large amounts of stable tokens. I’d love to see a bigger effort in the future address this in a “Mento 2.0,” but I think this is a ways out. In my eyes Granda Mento would be a short-term solution that shouldn’t involve too complicated of an implementation.

When someone gradually acquires stable tokens via Mento to facilitate a large purchase, assuming the amount of CELO sold over time is the same for the duration of the trading, in a way it’s similar to them selling their CELO at a TWAP from (start, end) in exchange for cUSD. This could look something like:

for each bucket update:

  • sell X CELO for stable token via Mento

But this also puts an additional burden on the trader:

  1. The operational inconvenience of having to do this is considerable (need to operate the service, keys are handing large amounts of money that aren’t as cold as they probably should be)
  2. They obviously can’t anticipate what the price will be in the future, and because many trades occur over a period of time, it’s not like they can codify a max/min TWAP they’re willing to pay.

If a 3rd party “broker” were to do this on behalf of a potential buyer, I think the risk still applies.

The main concern I hear is: how can we ensure a “fair” price?

If we were to use a TWAP taken from (proposal time, execution time) for example (this could even scale with the amount of CELO being sold or something), the price would be similar to what would be experienced by gradually trading w/ Mento (though the time from proposal → execution could be longer/shorter than what would be experienced via gradually trading with Mento). A trader could submit the max TWAP value and min TWAP value they’re willing to spend as a part of the governance proposal. If voters are uncomfortable with the min TWAP value being too low (potentially giving the trader a very good deal if the price tanks), voters can vote against it.

Additionally, slippage could still be incorporated-- you can imagine a Granda Mento trade occurring against a CP-MM whose bucket sizes are much larger than Mento’s and are at a ratio that matches the TWAP price. This would just mean that a $1M trade would incur less slippage than a $10M one.

But I think the crux of this is that it’s gated by governance. If voters don’t like the deal, the deal is off. Voters can decide whether they agree with the price bounds, and they can also factor in the context of the trade-- eg will this trade benefit the greater Celo ecosystem?

But all this is so up in the air right now. The biggest question for me is: assuming a robust way to determine price, would the community be in support of a mechanism for large (1M+) mints that may ultimately benefit the ecosystem as a whole? My answer is yes, but I think it just depends so strongly on how the price is determined.

11

Agree that scenario 1 is the important problem to solve here

12

IMO there’s no need for large mints to go through governance.

The reason Mento has slippage right now is to provide negative feedback to protect the reserve when the oracle rate is “wrong”.

Without this negative feedback, if an attacker was able to manipulate the oracle price to zero, either by compromising the oracle keys or by coordinating a “flash crash” across the major exchanges, they would be able to pull a large amount of CELO out of the reserve with only a small amount of cXXX.

With the negative feedback, which essentially places a time-based rate limit on net Mento volumes, the attacker’s profits are rate limited as well.

It’s for this reason that minting large amounts of cUSD are difficult. If I have the opportunity to mint > $1M cUSD in exchange for CELO, there’s an incentive for me to temporarily “pump” the price of CELO right before this, so that I can get my cUSD for much less CELO, effectively “cheating” the reserve.

Having a second track for large mints that goes through governance is just one way to mitigate this incentive.

One alternative would be to make the timing of the mint uncertain. You could imagine a feature in which you can lock up CELO in order for the right to purchase cUSD at a 1% slippage from the oracle rate at a random time based off of the latest block hash (i.e. at each block you have a 1/N chance of being able to execute the purchase). This would prevent you from knowing when your order will actually execute, and if you spread that out over a long enough period of time, you make this manipulation attack infeasible (as you would need to keep the “pump” going for such a long time that it would not be profitable).

13

I’m not sure I totally agree that Mento shouldn’t have a second track for larger trades; seems analogous to OTC in the “real world”

14

But maybe backing up a bit. Before we start debating solutions it feels like we should first agree on the problem, as it seems there’s some debate as to whether it is actually difficult to acquire > $1M worth of cUSD.

@albertw can you share some more information on the issues that users are having?

15

fwiw, we had a pretty good small-scale test of some of this today. There was close to ~100k cUSD that was bought on OkCoin for ~1-2% cost in fees. Peg shot up to 1.02+ but came back down to 1.01 fairly quickly. (I would guess that with time, this would happen even faster as arbitrage systems get better with more volume).

However, peg won’t go down below 1.01 from arbitrage (at least not in short term, and not consistently), because peg deviation is too small for arbitrage to be profitable.

I am still very confident it is possible to buy 1 million cUSD in <1 day, only thing I would alter is that it would probably cost 1.5% in fees (i.e. limit order at 1.015 instead of 1.01).

Imo, I still think that the real issue here is that cUSD supply expansion or contraction is too costly. And big part of that cost is 0.5% fee (in each direction) that Mento has. Consistently converting from USD → CELO → cUSD, or other way around: cUSD → CELO → USD costs close to 1% in fees. That means contracting or expanding cUSD supply using the protocol costs close to 1% in fees. So that means there has to be a very strong incentive for someone to do so.

I think there are many valid reasons right now to decrease Exchange spread from 0.005 to something much smaller. (i.e. 0.0025, or maybe even less like 0.001). In short term, this could potentially lead to some costs for the reserve. However, it will make it much cheaper to expand the supply using protocol itself, and will provide much tighter bounds for the peg.

Once there is a lot more organic cUSD <-> USD volume, Exchange spread can be increased back again (probably not to 0.005 which is crazy high by any measure, but to 0.003 to match more standard Uniswap fees).

16

I think there are many valid reasons right now to decrease Exchange spread from 0.005 to something much smaller.

I think this could make sense but I would be reluctant to do this without broader changes to Mento due to the reserve costs you mentioned. The current structure means that if the price of CELO changes by more than the spread within the 5 minute update frequency the reserve has some costs due to arbitrage trading that does not support price stability.

The constant-product-market-maker mechanism is there to provide negative feedback in periods of asymmetry (i.e. more buyers than sellers or more sellers than buyers) to protect against oracle attacks. For example, if someone were able to manipulate the oracle price to zero, you wouldn’t want them to be able to pull all of the CELO out of the reserve immediately. Unfortunately, as implemented, this means that the exchange price is only intermittently defined by the oracles, which creates costs to the reserve during periods of high price volatility. These costs scale with the amount of liquidity provided by Mento. For this reason that I don’t believe that the current expansion/contraction mechanism is suitable for large volumes.

However, I can think of some alternative approaches to negative feedback that do not have this property.

For example, you could imagine instead pegging the mid-price offered by Mento to the oracle rate, and adjusting the spread based on an exponential moving average of trading volumes. This spread could even be asymmetric (i.e. different functions for how much the bid and ask prices deviate from the oracle price). I think this could allow the spread to normally be much tighter than it is now as you would not have the same “costs” associated with high volatility; this would remove the existing arbitrage opportunities that exist even when the oracle price is correct that do not support stability of cXXX.

Ultimately, there exists a fundamental tension between negative feedback as protection against oracle attacks and the ability to expand or contract the cXXX supply by large volumes very quickly. The only solution that I can see is the one @thezviad suggested, which is to allow other users to provide this protection via an auction. I think this is a promising direction but I’m not clear yet on how to make it work.

For those that followed this project from the very early days, the original stability mechanism was actually auction based. The protocol defined the expansion/contraction amount, and let users define the price. The current stability protocol of course does the opposite; the protocol defines the price, and users define how much to expand or contract supply by. I suspect there’s a way that you could get the best of both worlds, where users define both, but I’m not sure how to do it.

17

There are few points that I would disagree with here. First, from first principles perspective, having a stable peg can’t possible happen for free. Someone has to pay for it, and in a sense, reserve paying for it is the most natural thing to happen. Now it is a question of cost, how much is reserve paying for the stability?

I think worrying too much about Mento fee-s is missing forest for the trees. Lets say even if Mento was doing 1 Billion USD volume per year (it is doing significantly less more like <200 MLN per year), and if we switched fees from 0.005 → 0.001, that would cause loss of 1 BLN * 0.004 in fees, which is 4 MLN USD per year. This on the surface level might seem like a lot of money, but when you zoom out, it is essentially negligible compared to the changes in price of CELO when you are thinking about the health of the reserve and looking at a year time scale. So if it actually helps with the peg and adoption of cUSD, paying this out even for a few years while ecosystem is growing, should be a no brainer.

However, this is still too simplistic way of thinking. As DeFi ecosystem gets built out on Celo, and becomes larger, Mento is in a primary spot to become a source of income for the reserve. And costs of stability can actually shift from reserve to DeFi protocols instead. And having lower fees in Mento is essential for this.

Here is how this would work:

  • Mento is in best position to be the on-chain protocol that maintains price parity with CEXes for CELO and cXXX assets. That means when prices change in off-chain markets, Mento is the first thing that gets arbitraged away. (I see this being mentioned as a negative, but I strongly disagree. This is a good thing!)
  • Because Mento is the first thing that gets price parity with CEXes, that means rest of the DeFi systems on Celo (i.e. like Ubeswap) will actually arbitrage against Mento to react to price changes.
  • It is important to keep in mind that off-chain arbitrage is few orders of magnitude harder compared to on-chain arbitrage. That means once you have an established DEX that maintains price parity with the off-chain stuff, it immediately becomes a dominant intermediary for all other on-chain protocols. Assuming you have reasonable fees.

So picture looks like this:

image
image668Ă—856 24.7 KB

This makes Mento an intermediary to arb between Off-Chain and On-Chain stuff. Being middlemen between Off-chain and On-chain stuff is an incredibly profitable venture. As DeFi ecosystem grows on Celo, this can not only cover any costs reserve has to endure for stability, but can actually become significant source of profits for the reserve.

We are already seeing some of this in-action, and we should have lot more data to support all of this in upcoming months (assuming DeFI ecosystem grows on Celo).

Way more than Mento fees, what I would worry about is that unlike cUSD, cEUR mento is not getting arb-ed against CEX-es, so it isn’t maintaining price parity in-between bucket updates. It would be huge missed opportunity if instead of being an intermediary, Mento actually gives up that position to some other on-chain protocol. So now you will have delayed arb cycle like: CEX <-> Ubeswap <-> Mento. Imo, that would be pretty big loss of opportunity and it would also negatively affect peg boundaries.

18

First, from first principles perspective, having a stable peg can’t possible happen for free. Someone has to pay for it, and in a sense, reserve paying for it is the most natural thing to happen

Totally agree, I wasn’t arguing against this. I’m perfectly supportive of stability costs being covered by the reserve; that is the way the protocol was designed to work.

There are broadly two types of arbitrage that can happen right now between Mento and centralized exchanges:

  1. The cUSD/CELO price offered by Mento differs from the USD/CELO price offered on centralized exchanges. This creates an incentive to arbitrage Mento to match the USD/CELO price (plus or minus a small delta due to cUSD/USD price deviations).
  2. The cUSD/USD price has sufficiently deviated from its peg on centralized exchanges. This creates an incentive to buy/sell cUSD on Mento and take the opposite position on the centralized exchanges.

The protocol was designed specifically to provide (2), such that arbitrage opportunities are present whenever cUSD deviates from its peg, in a way that pushes the cUSD price back to 1.

I would argue that (1) is an unintended and undesirable side-effect of the current implementation, as a result of the way that protection against oracle attacks was implemented. At the current scale it’s not really an issue, but my point is that this approach to negative feedback scales in costs with the liquidity provided by Mento, and there’s no need for it to be that way. This is a relevant point as we’re talking about the problem of increasing Mento liquidity to allow for larger expansions/contractions at a smaller cost to the expander/contracter.

So if it actually helps with the peg and adoption of cUSD, paying this out even for a few years while ecosystem is growing, should be a no brainer.

Totally agree with this as well. However I feel like you’re presenting a false choice; reducing the spread is just one of many things that could be done to improve the stability of cXXX and increase the liquidity Mento can offer. So it’s not so much a choice of “do we reduce the spread or not?” so much as “Mento has been live for about a year, and the design is a couple years old. What have we learned since then that we can do to make a better stability protocol?” I feel very strongly that the answer is more than “reduce the spread”.

Now of course, some of these changes can be implemented more quickly than others, and I’m very open to the idea that the first thing to do could be to decrease the spread*. But I’m not sure I’m open to the idea that this is the only thing that should be done - I suspect there are much larger changes that can and should be made to the protocol beyond tweaking some parameters.

And costs of stability can actually shift from reserve to DeFi protocols instead.

  • Mento is in best position to be the on-chain protocol that maintains price parity with CEXes for CELO and cXXX assets. That means when prices change in off-chain markets, Mento is the first thing that gets arbitraged away. (I see this being mentioned as a negative, but I strongly disagree. This is a good thing!)

So I totally agree that Mento should aim to maintain price parity with CEXes as closely as possible; the stability of cXXX depends on it. My point is that the current way that price parity is achieved is sub-optimal, in a way that prevents Mento from safely scaling to support the expansion/contraction scenarios that @albertw is looking to address.

Way more than Mento fees, what I would worry about is that unlike cUSD, cEUR mento is not getting arb-ed against CEX-es, so it isn’t maintaining price parity in-between bucket updates

The good news is that the solution I sketched out actually solves this problem! IMO if we’re concerned with stability, this is the wrong worry to have. Instead of “are traders scooping up arb opportunities when cXXX is pegged?”, we should be focused on “are traders scooping up arb opportunities when cXXX loses its peg?”. It’s only a quirk of the negative feedback mechanism designed to protect against oracle attacks that the former is even a thing. However I do agree that if the answer is “no” to the first question it’s likely to be “no” to the second question as well, and this is something worth investigating.

*At the moment I’m not totally convinced that a smaller spread solves the problem that @albertw posed here. I will certainly concede that tightening the spread tightens the expected price range of cXXX, but I don’t know that the UX of deviating up to 0.5% from the peg is an important problem to solve right now

19

I feel like maybe I skipped over some of the thinking that lead to this train of thought.

In response to some of the pushback from @thezviad and @jmrossy on the idea of a separate “granda mento” feature, I started asking myself what it would take to support larger expansions and contractions in the current feature.

The naive approach is just to increase the bucket sizes, which allows for more volumes to be exchanged at a lower slippage. The most extreme version of this solution would be to do away with “buckets” entirely, and allow Mento to always trade unlimited volumes (or, at least, bounded only by the reserve’s assets) at whatever the oracle price is.

The problem with this approach is:

  1. Price discovery becomes increasingly expensive. The less sensitive Mento is to trading activity, the greater the arbitrage opportunity exists between Mento and CEXes. At the extreme, Mento would be willing to buy up the orderbook on CEXes until the price reaches whatever the price on Mento is. I think it’s clear that this doesn’t work well in the current protocol where these prices can be up to 5 minutes out of date.
  2. The incentives to attack oracles go way up. Whether by attempting to compromise oracle keys, or by manipulating CEX orderbooks, if you can trick Mento, even for a short period of time, that the CELO price is very low, you can buy up the reserve. At present relatively small bucket sizes rate limit this such that the attack would need to be sustained for a while to be impactful.

So, I started to think about the following questions:

  1. How can we design a protocol such that the costs of price discovery do not grow as quickly when increasing the speed at which Mento can expand/contract supply?
  2. How can we design a protocol that does not trade off this speed against safety against oracle attacks?

One idea, which is something that we’ve played around with before, was to disable Mento when cXXX was holding the peg. In theory this is a good idea; Mento is designed only to protect the cXXX peg, and whenever cXXX is pegged, there’s no need for it to exist. However there are some practical reasons this isn’t feasible. It creates a chicken-and-egg problem for new tokens, as you won’t be able to know whether or not cXXX is pegged until it is launched, and you won’t be able to launch cXXX until you know if it’s pegged. Furthermore, it requires cXXX/XXX price discovery, which is not currently a requirement, and you could imagine that being difficult for lower liquidity currencies (e.g. cBRL).

Then I started to think about the 5 minute bucket update frequency. In almost all cases the protocol is already getting a steady stream of high quality price information via the oracles, but it essentially only looks at it every five minutes. If you increased this frequency, you could increase the bucket sizes and allow for less slippage during large contractions and expansions, which would address the problem that kicked off this thread!

The natural result of this line of thinking is a Mento without buckets that just allows users to exchange at the current oracle price (minus a small spread). This seems like a great solution so long as the oracle price is accurate. We’ve come full circle, as this was actually the first iteration of CP-DOTO; the Uniswap mechanism was added later on to defend against inaccurate oracles.

So then the natural next question is, are there forms of negative feedback that protect against infrequent oracle inaccuracies but otherwise take full advantage of frequent oracle updates, allowing the “effective orderbook depth” offered by Mento to be increased?

And that’s where I came up with the very rough idea of having the Mento mid-price be fully specified by the current oracle price, and for the bid/ask to deviate from this price as a function of the exponential moving average of Mento volumes*.

However, this line of thinking will only take you so far. At some point, you reach the limits of the unavoidable tension between using large exchange asymmetries as a signal that the oracle price is off, and wanting to allow for large exchange asymmetries to respond to large changes in supply/demand of cXXX.

And so that’s when I started to think about auctions. You actually don’t need the protocol to defend against manipulated oracle prices, users will tell you! If, for example, exchanges we not atomic, but instead had a 10 block window where the price could be raised by another user, the protocol would have strong protection from oracle manipulation attacks. There are a lot of problems to be worked out here**, which is why I think the proposal above is more promising for now, but I think it’s an interesting direction.

* There are probably other useful inputs to these functions besides Mento volumes.
** First and foremost, if the oracle price was 0, and free CELO was being given away, why would Alice “outbid” Bob rather than place her own bid for free CELO? You need a way to “force” this competition, but it’s hard to do that unless you limit the supply of the volume being competed over. How do you do that? It almost takes you full circle back to the original approach of having the protocol define the expansion/contraction amounts, but we concluded years ago that was a bad idea, and I don’t think we’ve learned anything since then that would support revisiting.

20

Thanks @asa for walking us through your reasoning, that was helpful! And it jogs my memory of how Mento came to be designed as it is. Can we correctly summarize your recommendation as: we should explore Mento config changes (i.e. spread) and more complex alternatives (i.e. auctions) but you’re in favor of Granda Mento as it’s been proposed here as a quicker stopgap solution?

@trevor to your point about the governance gating being the crucial factor here, though I agree that would probably protect the mechanism from abuse, I’m still not convinced this is a net good thing for the network long-term. A system where CELO holders have to review and approve individual exchanges seems more susceptible to politics, controversy, and price manipulation. Maybe those concerns have already been considered. Some related clarifying questions for you @albertw:

  1. Is there a static price threshold for when Granda would be invoked? $1 million?
  2. Is it for anyone looking for buy or just certain classes of traders?
  3. How often roughly do we imagine these big trades happening?

It may be the case that other, more elegant solutions are too complex for alleviating immediate need and Granda Mento is the least worst option. Though it sounds like @thezviad is not convinced the status quo couldn’t be made to work. If a stopgap solutions is definitely needed, I’m not adamantly opposed to Granda Mento but not convinced we can’t do better. I have no alternative solutions atm though, sorry :upside_down_face: