Could we approximately simulate or track the slippage and fees that a script-based batch processing on Mento would have for a given trade size and time? We could then make it the same for a Granda Mento purchase.
That way, if I understand it correctly, we would not put regular Mento users at a disadvantage compared to Granda Mento users in terms of transaction costs.
For Granda Mento users that would mean: We optimize your UX, but don’t put you at an advantage in terms of fees.
As the costs Granda Mento are probably not that high, we could use those fees for something useful, for example to bolster the reserve or give it to Celo Foundation or a little bit of both.
A question that I have related to this: Would different fees in Granda Mento and Mento produce an arbitrage opportunity?
Zviad had a neat idea (please correct me if this is off):
I had understood things slightly differently.
The Granda Mento feature only works one way (CELO → cUSD)
There’s a minimum cUSD amount for Granda Mento exchanges
Any proposed exchanges need to be approved by a governable third party
The enforcement of the price is at the time that the exchange was proposed rather than the time it was executed.
like the originally specified trade price being within Y% of an oracle TWAP over period Z.
Why not just use the current oracle rate? Adding a TWAP to Mento would be the most difficult part of this proposal.
Good suggestion, I think the design we proposed in our call had this multisig play the role of approver rather than veto-er. As far as I understand it, it’s okay for Granda Mento exchanges to take a while (e.g. 2 weeks), and so governance as the veto-er isn’t an issue from that perspective.
Could we approximately simulate or track the slippage and fees that a script-based batch processing on Mento would have for a given trade size and time? We could then make it the same for a Granda Mento purchase.
This seems like a good suggestion.
we could use those fees for something useful, for example to bolster the reserve or give it to Celo Foundation or a little bit of both
I think by definition these fees go to the reserve, in the sense that any CELO exchanged for cUSD as part of Granda Mento should go to the reserve.
Would different fees in Granda Mento and Mento produce an arbitrage opportunity?
That’s an interesting question. I’m not sure I see any way to do this.
There’s a minimum cUSD amount for Granda Mento exchanges
I think that’s reasonable
Any proposed exchanges need to be approved by a governable third party
Is this what you were thinking?
Anyone can submit a proposed exchange (will more than likely be the Celo Foundation)
A multisig would need to approve a proposed exchange
The exchange is now pending and can be vetoed by governance (or possibly a second multisig per Nam’s recommendation if governance is not desirable)
The enforcement of the price is at the time that the exchange was proposed rather than the time it was executed
Why not just use the current oracle rate?
If the check would be requiring the submitted exchange price is within X% of the current oracle rate, then why not just use the oracle rate as the price directly without some sort of sanity check?
As for current oracle rate vs TWAP, to me it’s a question of how robust this should be to oracle manipulation without requiring vetoers to step in. If the community is confident they’ll be able to spot manipulation in time to veto the exchange, then the current oracle rate is probably ok. I agree implementing the TWAP will be a pain
The Granda Mento feature only works one way
it’s okay for Granda Mento exchanges to take a while (e.g. 2 weeks)
@albertw any thoughts on these? I was under the impression two-way trading and <= 1 week delay is desirable
Yes, i think this is probably more in-line with what I was thinking too. Not sure if it is necessary or not to limit exchanges to CELO->cUSD at a contract/implementation level. It seems fine to allow both from implementation perspective, even if only CELO->cUSD stuff is expected to get approved in the beginning.
Since there is a manual approval step anyways to lock the price in, it seems like there shouldn’t be any worry about oracle price manipulation?
The check to make sure “lock-in” price is within 5-10% of oracle price would be there just to make sure someone doesn’t fat finger an extra 0. So for something like that using current oracle price should be fine without needing to add TWAP support.
@trevor Desirable for this to be two way if it doesn’t increase the implementation difficulty by much. The reversibility at scale instills confidence to convert larger quantities.
Having a defined conversion rate locked in closer to proposal time is a bit more important than the difference between a 1 week vs 2 week approval. As long as there is some certainty in the timeline and the submitter knows ahead of time it is a reasonable near-market price, it shouldn’t be much of an issue for the user experience. I think if the conversion rate is determined up front, we wont be as worried about price manipulation, which will be very apparent to the party with the veto ability.
Sounds like we’re aligned then on what this should look like? I don’t feel strongly about one-way vs two way, it just hasn’t sounded to me like there’s really a need for this feature to support cUSD → CELO. It’s probably not too much harder to support both though it does increase complexity a bit.
Wanted to kickstart debate here about how much the fee for Granda Mento should be.
Feels like I can make an argument for 0.5% as it would be the same as Mento currently has. It could also be claimed that it should be even higher, as there is not slippage associated with the trade.
The fee discussion for Granda Mento doesn’t seem super useful since choice of price for CELO is going to be way more important. I don’t think separate fee is really needed since price is determined manually anyways.
What matters a lot more is how the price of CELO is chosen, and what level of transparency we have where the CELO is coming from that is being used to purchase cUSD (or cEUR) through Granda mento.
I think it would be transparent to separate price from fees, to not kind of price them in secretly.
Is the fee at the end a trade-off between incentivising stable-coin growth (=user acceptance) vs bolstering the reserve?
I can imagine a slightly higher fee between Mento and what you would get on OTC, in the area of 1%
(Does anyone know how a OTC fee structure looks like? I thought of 2-3%) Some reasons:
To further bolster the reserve to account for some weird stability risk scenarios: For example someone buys a large amount of cUSD, abandons the plans with it, chooses not to use Granda Mento to trade back because of execution time, and dumps them on the market creating cXXX price turmoil
Some OTC exchanges might use Granda Mento themselves, to cheaply buy cXXX and sell it with their fees. The reserve could take a higher cut of that
However my thoughts are under the condition that this wouldn’t decrease user acceptance
As part of the implementation of Granda Mento, we’ve been discussing appropriate multisig key holders from a geographically distributed community to be guardians of this process. A 4 of 7 multisig comprised of the following individuals has been nominated through discussion in Discord:
One of our founders previously helped Zedra ($100m Trust Company) set up a crypto OTC desk encase any support is needed in relation to designing off-chain legal components.
CIP 46 defines processes around use of Granda Mento
CGP 31 “activates” Granda Mento following Contract Release 5, and at the time of writing has been proposed with on-chain proposal ID 41. The CGP was recently updated to include information on how to verify the contents of the exchange proposal here, and the “Risks” section here was updated to describe details on the approver multisig and its ability to self-govern. The approver multisig signers in this CGP are the same as Albert proposed above, with the exception of @Alesh, who was replaced with @Deepak after opting out.
Yes, i think this is probably more in-line with what I was thinking too. Not sure if it is necessary or not to limit exchanges to CELO->cUSD at a contract/implementation level. It seems fine to allow both from implementation perspective, even if only CELO->cUSD stuff is expected to get approved in the beginning.