Discussion on Granda Mento: Enabling Larger Stablecoin Mints

Governance
22

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?

I’m not sure I understand the problem well enough to recommend a solution. Is the problem that Mento cannot adjust cXXX supply quickly enough? Or is the problem that Alice cannot easily buy $10MM cUSD? And does solving the former problem help solve the latter?*

For the former problem, I see roughly four options (in order of difficulty/time to implement)

  1. Parameter adjustment of Mento 1.0 (e.g. bucket sizes, update frequency, spread, etc.)
  2. Adding a Granda Mento feature specifically for large increases in cXXX supply**
  3. A Mento 2.0 similar in theory to Mento 1.0 but with improvements that allow for “deeper orderbooks” (e.g. using the latest oracle rate and defining a spread around that based on volumes)
  4. A Mento 2.0 that does not have a negative feedback mechanism to rate limit cXXX supply changes (e.g. something with auctions :man_shrugging:)

IMO all approaches should be on the table, and it’s likely that we wind up adopting more than one of these approaches over time. I’m looking forward to getting more clarity on the problem from @albertw.


* Even if the answer is “no”, I feel strongly that the former is a problem worth solving. If you assume Mento needs to be able to absorb X% daily fluctuations in cXXX demand, as cXXX adoption grows you need Mento’s ability to expand or contract supply to grow linearly with it in order to be able to safely maintain the peg. So whether or not it solves the “granda mento” problem, I do believe it’s time to start working on a Mento 2.0 proposal.
** Fwiw I think there are probably lots of ways to do this without needing Governance to be involved, if that’s the main objection to the solution @trevor proposed.

23

I think with that we get back to my original question. What is the problem we are trying to solve? If slippage/fees aren’t an issue, I am not convinced that you can’t buy 1 MIL cUSD in < 1 day.

Here is my current data/predictions of what is possible:

  • buy 1 MIL cUSD at a price of 1.02, very high confidence this happens in <1 day.
  • buy 1 MIL cUSD at a price of 1.015, high confidence this happens in 1-2 days.
  • buy 1 MIL cUSD at a price of 1.01, unlikely to go smoothly, but might still get filled in 1 week.

The important fact here is that, as far as my data goes, current limitations on throughput aren’t because of Mento, but because cUSD is only listed on two fairly low quality exchanges. Bittrex and OkCoin are essentially toy exchanges compared to CoinbasePro and Binance.

If it was possible to trade cUSD on Binance (or especially CoinbasePro), it would most likely be possible to do 10x the volume at the same price ranges. (EDIT: 10x is probably an exaggeration since it will start hitting mento limitations, but it will be a lot smoother compared to current OkCoin/Bittrex experiences. Probably still within ~1 MIL per day range but it will easier to do this continuously over many days).

24

One issue with delayed trades is that it will make arbitrage less-safe, hence less efficient/more expensive. Which will make it more difficult/expensive to maintain the peg.

Lets say I want to convert 100 USD → ~99 cUSD. I can look at current prices on CEX and on-chain, and if i see that USD → CELO → cUSD path has right prices, I can buy CELO on CEX, and sell it on-chain for cUSD. With current setup, risk is fairly minimal because there is a very low chance that price will change between making a trade on CEX vs making the trade on-chain.

With a delayed auction, there is now a larger risk that I wont get the price that I need for the on-chain trade. Larger the delay, higher the risk, so that will cut into the leeway that each trade needs to keep, making every thing more expensive.

Also this type of auction has to start a separate auction block for every trade, so it will become very complex. IF you just have set 10 block windows where auctions happen, users will just wait for block 9 before they make their trade. So in the end all trading will end up happening in a single block anyways.

25

Yeah I’m not convinced there’s a way to make auctions work. The points you make were some of the reasons we abandoned the original stability protocol design. I’d like to keep playing around with ideas around how to protect against oracle attacks without relying on negative feedback, but it’s a hard problem.

I think with that we get back to my original question. What is the problem we are trying to solve?

Yeah agreed we don’t have a clear enough answer to this question yet. I know @albertw is putting together some materials on this and I expect he’ll have something ready to share relatively soon.

If slippage/fees aren’t an issue, I am not convinced that you can’t buy 1 MIL cUSD in < 1 day.

I suspect slippage/fees are a problem, but I’m not clear on the requirements. Something for @albertw to help us understand.

Here is my current data/predictions of what is possible:

Interesting! Indeed that doesn’t seem too bad, but again I’m not clear on how much cUSD folks are trying to purchase and what premium over the peg they’re willing to tolerate.

@thezviad IIUC, in your model of thinking about this problem, folks place a limit order on a CEX to buy cUSD with USD, and eat through the order book up to their limit price. The order book gets replenished by arbitrageurs when the ask rises above the threshold at which arbitrage is profitable (which is a function of the spread and Mento/CEX order book depth), at a rate limited by the Mento bucket sizes and CELO/USD CEX order book depth. Is this right?

1 Like
26

Those two scenarios are actually very closely tied together. I think if I give an overview of how a medium-large scale market-making+arb can work in practice, it can add additional insights here.

Performing full USD → CELO → cUSD → USD arb is extremely inefficient. That is not going to be scalable or practical, or safe, or efficient. Imo, that is not the way to have a medium-large scale setup.

Instead of taking the full arb cycle, here is how large market-making/arbing can work for USD/cUSD in practice:

Market-maker + Arb entity (lets call them MM) has large supply of [USD] and large supply of [cUSD].

MM does regular market making providing both buy and sell side orders for cUSD. As MM’s supplies change, prices that they provide also changes. (i.e. as MM is running out of cUSD, they will start selling cUSD at a higher premium and vice versa)

This is just regular market making for now. In addition to this, MM can employ a strategy to rebalance things in the background. So if MM is running low on cUSD, they can perform USD → CELO → cUSD trade to replenish cUSD supplies (at prices that makes the whole setup profitable). If they are running low on USD, they can perform cUSD → CELO → USD trades.

Because MM doesn’t have to depend on full arbitrage loop being profitable in a single instant, this setup can be much more scalable and more efficient. This allows MM to provide tighter spreads on USD/cUSD.

Because MM is performing rebalancing of supplies “in the background”, that means they will be trading USD → CELO → cUSD (or other way around) even when there might not be a de-peg at all. This still serves the purpose to provide stability and maintain the peg more efficiently.

1 Like
27

Yes indeed. As I mentioned in my reply above, arb-ers don’t have to do full arb loops every time. Buying cUSD using “USD → CELO → cUSD” path can be separate from selling cUSD → USD on CEX. That separation makes things more efficient. So question comes down to:
How much volume can you convert through USD → CELO → cUSD route while taking certain amount of losses (i.e. converting at a loss of 1.5% is fairly easy, converting at 1% loss gets trickier, converting at 0.5% loss is very hard).

The good part of not by-passing regular markets for larger trades is that it incentivizes regular Market-Maker/ARBers to increase their supplies. This creates natural additional use case and demand for cUSD. And has other cascading benefits too, since higher capitalized market makers and arbitrageurs create more efficient market in steady state.

1 Like
28

I edited the opening post to add some details about the intended user in a more generalized sense with some of their perceptions based on some of the folks I’ve talked to. It’s more important to align on the purpose and intended use of such a tool at this point more than the exact solution. There could be a variety of implementations, but I do believe we need to enable larger minting capabilities; otherwise, the capabilities of Reserve-backed stablecoins at scale cannot compare to more liquid stablecoins like USDT and USDC once bridges from other chains such as Optics are enabled. When corporate and institutional players compare the ability of cUSD and cEUR to be purchased and sold at scale to those aforementioned coins, they are discouraged from even participating in the Celo ecosystem and impeded from scaling faster.

To bring it to some concrete user examples of why a larger mint/exchange capability will be needed soon, these are few specific case studies that have been discussed with people who’ve looked at exchanging at that level:

  1. There’s some upcoming grants and larger scale UBI programs in the $1-10 Million cUSD range that may require conversion at scale. This is potentially an order of magnitude larger than what’s been done in the past by impactMarket.

  2. Community currencies (cXOF for example) may require fairly large initialization of liquidity (Ubeswap pools) and collateral on the scale of $1 million+ to get started. Scaling out cEUR-based currencies that are hard to obtain on OTC desks is challenging with current Mento limitations.

  3. Moss team is a good example of where higher than expected slippage at larger cUSD conversion quantities stopped them from providing more liquidity to their Ubeswap pool. The Ubeswap pool cMCO2-cUSD pool (Ubeswap Info) has 7% of the liquidity of the comparable Uniswap MCO2-USDC pool because it was too frustrating of a user experience to try to buy cUSD repeatedly or through OTC to establish a larger base liquidity.

These operations or intended purchases also do not happen in a silo, and “compete” with other purchases done through Mento for lower slippage. Hopefully, these specific cases paint a clearer picture of the users this is designed for and how the current Mento system limitations are a barrier for them.

1 Like
29

Thanks @albertw!

I’m sold on this being a problem that is worth solving with a separate feature. While we have promising approaches to increase Mento liquidity*, it doesn’t sound like that would, in and of itself, allow users to purchase large volumes of cXXX.

IIUC, the argument that increasing Mento efficiency improves the bulk purchase experience requires market makers to play a more active role than they’re playing right now, and I’m not yet convinced that increasing Mento efficiency for e.g. cEUR will meaningfully increase the order book depth for whatever exchanges it’s listed on. This approach also requires that exchanges list a cXXX/FIAT pair in the first place, which can be a bit of a chicken and egg problem, as exchanges don’t want to list until there’s meaningful volumes, and under this approach meaningful volumes require exchanges to list. This problem exists not just for new cXXX currencies, but even for cUSD.

Even if I’m wrong about all of that (@thezviad please don’t be shy about correcting me!), the drawback of having a separate feature for supply expansions > [$1M] seems low to me. It seems relatively straightforward to build a safe auction-based system per @thezviad’s suggestion.


* To reiterate I think this is worth doing whether or not it solves the "Granda Mento" problem, and to me it's just a question of prioritization.
30

thanks @albertw for providing more info. I think it would be useful to make UX requirements a bit more specific so we are all on the same page for expectations.

First, I think it is important to split two use-cases:

  1. User comes in with outside capital in USD (we can discuss EUR separately, but to keep things focused, lets stay with USD for now) and wants to convert to stable coins
  2. User already has significant amount of CELO acquired (through early investment, or through long accumulation period) and wants to convert that CELO → cUSD in large amounts.

Let’s first align on this: Are talking about case #1 or case #2? Discussing both together will only cause confusion, because in my mind they are very different things. If we want to discuss BOTH, i think we should have two separate threads. Discussing them together doesn’t make sense to me.

Assuming we are talking about case #1, it would be useful to nail down expectations of what we want user to be able to do.

Best competing alternative to USD->cUSD is following:

  • User wires USD to CoinbasePro.
  • User converts USD:USDC 1:1 using CoinbasePro website. Instant conversion, with no trading fees, and no slippage.

I would say there is close to no-chance to achieve that type of UX with a decentralized protocol. If we want to achieve that level of UX, then some central entity must subsidize cUSD acquisitions. This central entity can be funded from reserve/protocol too, but essential part is that it will have to be subsidized, and it will have to be done through some centralized org. (I am not against it btw, I think this can be a way to grow the initial cUSD supply, but we should be transparent that we are subsidizing initial cUSD acquirers from the protocol)

Now if we want to keep things decentralized, we need to have more realistic expectations for the UX. So let’s align on what that expectation should be.

Example flow:

  • User comes in, wires 1 million USD to OKCoin
  • User converts 1 million USD → X amount of cUSD within Y amount of days by making a simple buy limit order on OkCoin.

Now what would be acceptable X and Y in this case?

2 Likes
31

To clarify the focus here, this solution concentrates on the CELO → cUSD/cEUR part of the conversion, but it is a critical part of the full fiat to cStable flow (fiat → CELO → cStable) that is a bottleneck at this point. Fiat to CELO trading is covered sufficiently by exchanges and OTC desks and is outside the realm of our influence. We certainly don’t want to own any fiat on/off ramps, and this is up to the free market to implement.

There is already sufficient liquidity and avenues to acquire CELO at scale and all the entities needing larger quantities of CELO are able to fulfill their needs buying from the Foundation, current large holders/investors, or OTC. Case in point: Deutsche Telekom is able to make an institutional sized investment of CELO recently (from fiat).

Although in theory they could place a large limit order to buy cUSD/cEUR, nobody has done this in practice. There is a great uncertainty in fill time and I’m not sure how these users feel about a partial fill by their expected time of need. Users at this scale of conversion are very averse to uncertainty in time and pricing.

32

I think this makes sense as to why we are sort of talking about two different things. Allowing users who slowly accumulate CELO to mint cUSD is a valid use case, but seems very different from getting cUSD from USD directly.

Allowing users to sell large amounts of CELO (that they have acquired slowly) for cUSD, no matter how the price is determined, is going to be very unfair to the rest of the CELO holders, and is going to introduce a lot of risk to the protocol. I think to solve this use case, we can instead take notes from Maker and DAI. But unlike Maker, because of rest of the Celo protocol design (specifically because there is reserve), it can be much safer and easier to implement.

Here is a high level idea:

  • Users who hold CELO can put their CELO down as collateral and mint cUSD (or other cXXX tokens) directly from the reserve. We can start with over-collateralization of minimum 2x, but this can probably be brought down to 1.5x later on too.
  • If price of CELO goes up, both user and reserve are happy.
  • If price of CELO goes down, reserve and user share the burden. But reserve is still guaranteed to never lose more than 50% of the original value. This is strictly a lot safer than having allowed user to sell their CELO for cUSD.
  • Because these loans are against the reserve, there doesn’t really need to be any penalties, interest rates or fees. (Maybe some interest rates later on for minted cXXX tokens, but it can start with 0% fees too).
  • Liquidations would be done against the reserve, so only Reserve will be able to reclaim CELO from the user if price of CELO goes down. This can remove a lot of other complications and potential attack vectors.
  • Because of no large liquidation penalties, this should be easy from users side to manage. Unlike regular lending protocols, they wont have to worry about huge liquidations if they are slightly under-collateralized. If the price of CELO drops, they will lose some amount of CELO, but it can be done in a way that they only lose minimal amount that brings their account back to healthy state.
  • There would be total maximum cap on amount of cUSD that can be minted using this. We can start with a lower number (i.e. 10s of millions), and potentially grow it to 100s of millions, but it can have a cap that would provide further protection against worst case scenarios.

(of course this is just high level idea, there will have to be more details that will need to be figured out for a real version of this system).

I would personally be much more supportive of this type of direction, than any kind of auction or mento based strategy that simply allows users to instantly convert their slowly accumulated CELO for cUSD. Allowing users to just dump CELO for cUSD in an instant, puts all the risk on the reserve if price of CELO drops significantly. This seems way too risky and also unfair to rest of the CELO holders.

33

I think this makes sense as to why we are sort of talking about two different things. Allowing users who slowly accumulate CELO to mint cUSD is a valid use case, but seems very different from getting cUSD from USD directly.

I think Albert’s point was that it’s relatively easy to exchange fiat for large quantities of CELO. And so if you solve the problem of exchanging large quantities of CELO for cXXX, you solve the problem of exchanging fiat for large quantities of cXXX.

Allowing users to sell large amounts of CELO (that they have acquired slowly) for cUSD, no matter how the price is determined, is going to be very unfair to the rest of the CELO holders, and is going to introduce a lot of risk to the protocol
Allowing users to just dump CELO for cUSD in an instant, puts all the risk on the reserve if price of CELO drops significantly. This seems way too risky and also unfair to rest of the CELO holders.

These are strongly worded statements, can you elaborate?

I think to solve this use case, we can instead take notes from Maker and DAI.

While this would be an interesting feature, I don’t think that allowing users to borrow cXXX against their CELO holdings meets the user needs that Albert has shared. It is both capital inefficient and requires that the user take a long CELO position, and in many cases speculating on cryptocurrencies will not be part of these users’ businesses.

34

It might be that I am misunderstanding the proposal/direction here. Wouldn’t the user already be exposed to CELO price volatility if they have to first acquire bunch of CELO and then somehow batch exchange this CELO → cUSD?

If the user spends a week acquiring CELO, and there is another week long process (i.e. involving governance) to convert this CELO → cUSD, wouldn’t they be exposed to potential 2 week long period where price of CELO can change dramatically and affect the overall trade?

Considering price of CELO can easily change +/- 10-20% within a week isn’t this whole process already exposed to lots of price volatility risk? This is where I am getting confused. I don’t really understand how it would work to have a separate phase for buying CELO and separate phase to convert CELO → cUSD and not be exposed to CELO price volatility? (assuming these phases take at least few days)

35

Wouldn’t the user already be exposed to CELO price volatility if they have to first acquire bunch of CELO and then somehow batch exchange this CELO → cUSD?

I’m not sure that there’s a way to go from fiat → CELO → cXXX with no CELO price volatility risk, but borrowing cXXX against CELO seems to me to be an approach that is intentionally designed to take on more CELO price volatility risk.

It’s a difference of being exposed to that volatility for a few days (i.e. the time it takes to move out of CELO into cUSD) vs being exposed to volatility for as long as you want to use cUSD (hopefully much longer than a few days!).

Separately, one of the advantages I think the Celo protocol has over Maker is that supply of the medium-of-exchange token can scale with demand for the token rather than demand for leveraged long positions on the underlying collateral (e.g. ETH)

If the user spends a week acquiring CELO, and there is another week long process (i.e. involving governance) to convert this CELO → cUSD, wouldn’t they be exposed to potential 2 week long period where price of CELO can change dramatically and affect the overall trade?

I’ve never purchased CELO (or anything else, for that matter) OTC so I will defer to @albertw to shed more light on what that looks like. However, I would seem to me that the user only has exposure to CELO after the purchase is made, which means that their exposure is limited to the time it takes to convert that CELO into cUSD.

For that, I’m not convinced that this can’t be done more quickly.

The main concern that I’ve had when thinking about this feature (and more broadly, about Mento) is how to design it in a way that is robust in the face of oracle attacks.

In a fantasy world where we could guarantee that the oracle feed always reflects the “true price” of CELO (whatever that means), I’m not sure a Granda Mento feature would be necessary, as Mento’s “order books” could safely be way deeper. Obviously that’s not how oracles work; participants can be malicious, keys can be compromised, and the information the oracles report can be manipulated (e.g. by pumping or dumping on centralized exchanges).

To protect against this, Mento incorporates a negative feedback mechanism in the form of a constant-product-market-maker*, which essentially limits trading volumes. This allows the protocol to be parameterized based off of CEX order book depth such that the cost per unit time of manipulating the oracle price feed is less than the profit per unit time that can be extracted out of Mento.

This is of course at odds with the goal of being able to exchange lots of CELO for cXXX relatively quickly.

However, you correctly identified in your first post an alternative way of protecting against oracle attacks, which is to let other users provide price information. As you point out the UX is slightly worse (e.g. exchanges do not settle instantly), but that might be acceptable to folks who want to make fewer but larger exchanges.

One, not-very-thought-through solution that is illustrative of the direction I’m thinking is to allow for anyone to buy [between 1M and 10M cUSD per day] at the current oracle price (plus some protocol defined spread), with a [4 day] period for someone else to offer more CELO and take their place. This should ensure that users cannot exploit an attack on the oracles (as they should be outbid), and ensure the market has sufficient time to adjust accordingly before the purchase is completed.

However it seems like your concerns are different, and I’d like to understand them better. You talk about fairness to CELO holders and risk to the reserve, can you elaborate on those points?


* I just want to reiterate that I think it's time to look at alternative negative feedback mechanisms that are more efficient, but IMO that's a mostly orthogonal conversation.
36

Maybe what would help is if we could have a full end-2-end example of how this setup would work, because I feel like I am missing something and I am having hard time getting on the same page.

I keep getting confused on what type of user we are looking at. If the user/entity who wants to acquire lots of cUSD isn’t a CELO investor, and they don’t hold any CELO to begin with, we go back to just regular use-case.

So we are still just looking at a user who brings in large amounts of USD and wants to just convert this to cUSD. They don’t have any exposure to CELO, and they aren’t interested in having any exposure to CELO.

We have established that they don’t want to just make a limit order on a regular exchange because of uncertainty on how long it would take to fill such an order. So it isn’t about the fees/slippage but about uncertainty if the order will ever get filled or not. That makes sense.

Now instead, proposal seems to be something like this:

  • User reaches out to an OTC desk to buy CELO. So they buy 1 million $ worth of CELO at whatever OTC price they get, plus fees.
  • After acquiring their CELO, they immediately put this CELO in escrow and submit a governance proposal to convert this CELO to cUSD. Appropriate price I am guessing here would be whatever OTC desk would pay for that amount of CELO. (Using market prices from CoinbasePro for CELO/USD at even just 1 million $ depth would have huge slippage so i am guessing that isn’t going to be appropriate?).
  • Assuming governance proposal passes, they end up with the cUSD afterwards.

So the idea here is that OTC desks buy/sell CELO even in 1 million $ range at pretty small spread, so this is going to cost lower than potential slippage they would get by buying cUSD directly on an Exchange.

Plus uncertainty here is only wrt to Governance, which in vacuum seems like a lot of uncertainty, but in practice they would get pre-approval from Celo Foundation beforehand and have higher likely hood of passing their proposal assuming Foundation votes yes on it?

37

Everything you said is consistent with my understanding, though again I believe there are ways to build such a feature safely without going through governance if we feel that the cons (less decentralized and therefore less accessible, inconvenient for voters) outweigh the pros (fast and easy to implement).

Note that any feature we build here may be temporary. I think we all agree that deep cXXX/XXX order books on centralized exchanges is the best solution, and providing an alternative solution in the meantime may allow cXXX adoption to grow to the point where this feature is no longer needed.

38

Thanks. Would be good to confirm from @albertw too.

If the scenario I described is indeed what is being targeted, I am guessing in practice, expectation is that the OTC desk is most likely just the Celo Foundation itself right? (at the very least Celo Foundation would be facilitating the trade so they would be involved in the trade, if not just directly selling the CELO that they hold themselves).

39

Yes, @thezviad your end to end example is correct.

  • The fiat to CELO part of the conversion is (relatively) easy today. These large buyers quite often buy directly from the Celo Foundation at these levels of acquisition, but OTC is also a viable option. No changes here, and we expect this to remain pretty much the same.
  • The second part of the conversion from CELO to cXXX stablecoin is tedious or perceived as too difficult by these users, and is the focus of our stopgap solution. Because this CELO->cXXX part of the conversion to stablecoins is challenging today, users are discouraged from even doing the first step above. One could argue that having this solution available is beneficial to CELO holders because it would unlock a path to conversion at scale of fiat->CELO->cXXX, which has a major capital inflow to CELO as the first component. A capital outflow from CELO->cXXX is still somewhat positive, as cXXX stablecoins remain backed by the CELO reserve (which has quite a lot of CELO in it)
  • The “governance proposal passes” part is perhaps a bit cumbersome in my mind, and it’s not an idea I’m attached to. We’ve originally pitched this as a governance gated mechanism in the interests of security as Asa mentioend, but this isn’t the best UX. Ideally, this would simply be a contract users can deposit CELO into that has some security mechanisms built into it such that attack vectors are minimized. I would be quite happy if this was implemented safely in a manner where we wouldn’t need to burden governance or trigger a complex auction even time a major swap happened.
1 Like
40

Hey everyone, today @albertw, @asa , @Tobi, @thezviad and I had a call to discuss ideas around Granda Mento.

A recap of the discussion:

Though an auction-based system is attractive because they are open to everyone, with auctions come a lot of complexities and assumptions. Ultimately, we felt like an auction is not the way to go.

We began with clarifying what Granda Mento would aim to solve. One of the major concerns in this thread is that this could provide an unfair rate for special players to buy/sell CELO from the reserve. Two categories of users were discussed:

  1. Those who own significant amounts of USD and wish to mint cUSD
  2. Those who own significant amounts of CELO and wish to mint cUSD

Granda Mento is designed to focus on (1). The complete trade would look like: USD → CELO → cUSD. It became clear that a large purchaser would likely come to the Celo Foundation, who could broker the deal by making that CELO → cUSD trade with the protocol, and a purchaser making a USD deal with the Foundation.

Zviad had a neat idea (please correct me if this is off):

A contract is created and owned by the Celo Foundation that must be pre-approved by Governance to have the ability to trade X CELO or cUSD with the Reserve. Trades can now occur via this contract to trade with the Reserve. A trade is not atomic – it must be “kicked-off” and has a delay before being executed. The price of the trade is provided at the trade kick-off time. During the time between trade kick-off and trade execution, the community can decide to veto the trade. If the trade has not been vetoed and the appropriate delay has elapsed, the trade can be executed as long as it passes some safety checks, like the originally specified trade price being within Y% of an oracle TWAP over period Z.

Some thoughts on this:

  • While this is centralized, the process would be transparent.
  • The optimistic approval of trades results in lower effort from voters-- ie Governance only has to approve the contract once, and then subsequent trades can be approved without voting.
  • Governance is slow and painful - it may make sense to have the veto process not necessarily be through the existing Governance setup.
  • A desire of this is to provide just enough friction to the trade where it won’t undermine the real market. Eg fees, having to deal with the Foundation, and time delays.

As for the time horizon of this, it’s unclear whether or not “Mento 2.0” would include a mechanism to make this process obsolete. If/when cUSD hits a higher level of total supply, the need for USD → cUSD trades going through Granda Mento may disappear. However, for a less popular future cXXX that may not have as high demand as cUSD, the process could be helpful even in the long term.

I still have some questions:

  • What would fees on the trade look like?
  • What would the veto voting look like? The required governance period feels very long to rely upon for a veto
  • Did I miss anything from our call related to Granda Mento worth mentioning?
1 Like
41

One thing to consider is to make the “cost” of the veto in dependence of the size of the trade. Maybe just something like
veto if amount of locked gold vetoing > trade value.

Also I wonder how folks feel about a multisig of relevant parties to have veto power be more useful than “general governance”. I’m making the assumption that most trades will be uncontroversial, and just making it easy to veto would not practically break this process. As pointed out, Governance isn’t really meant to be agile, and I’m not sure how to make it so easily.

1 Like