Reserve Gift Policy

Governance
1

As the Reserve address is public, anyone can send digital assets to it. Some of these assets may be gifts from well intentioned projects, while others may just look for publicity or will lack a real usage. It is yet to be addressed how the Reserve should handle those assets, and the technical limitations the problem currently has.

Proposed process to handle gifts

Every quarter a governance proposal is to be submitted to categorize all assets in the Reserve that do not have a formal allocation. Two categories of tokens exist: Assets to hold and assets to liquidate, no matter in what chain they are sent.

  • Assets to hold: high quality assets of mission aligned projects. Examples of such could be:

    1. Ubeswap tokens ($UBE)
    2. Moola tokens ($MOO)
    3. Poof tokens ($POOF)

  • Assets to liquidate: assets the community doesn’t have any intention to hold in the long term. Examples of such could be:

    1. CELODOGE ($cDOGE)
    2. CELOSHIBA ($cSHIBA)

If an asset is labeled as liquidate, this proposal itself makes the appropriate smart contracts calls to liquidate them on Ubeswap (or some liquidity aggregator available at that time) for CELO, and sends it back to the Reserve. This call has a potential risk of getting front-run, but assuming there’s no economic interest for these assets, it shouldn’t matter.

If these assets are not tradable or their value is negligible, they shall be sent to a burn address or charity.

If an asset is labeled as hold, they don’t formally have a target allocation in the Reserve composition, but should be counted in the total Reserve holdings and displayed in Reserve communications. These assets shall be kept indefinitely until:

  1. The community proposes selling all or a portion of an asset. This could be the case if market conditions seem favorable, the projects have a bad growth prospect or stop being mission-aligned. This is ad-hoc and doesn’t need regular check-ins.
  2. The Reserve’s collateralization ratio has fallen below the Tobin Tax reserve ratio threshold (200%). This can be done right after the tobin tax is activated (this threshold currently only counts the Celo part), which is a safety mechanism the protocol already has in place.
  3. They move to a formal allocation. Pending market conditions, volatility, correlation with other assets held in the Reserve and the will of the Celo community through a governance proposal, an asset could eventually be added to the reserve, having a target allocation to maintain.

In the future, the Reserve could interact with projects that sent assets to it and were labeled as hold, like for example, staking the assets of a hypothetical project to receive a portion of its proceeds or providing liquidity for pairs of assets gifted and staking the LP assets. As risk exists with assets held in any decentralized protocol, assets with a formal allocation of the reserve should never be put at risk.

At some point in the future if there is a lot of overhead with dealing with these assets, the decision of which tokens are kept and which tokens are liquidated can be delegated to a token curated registry.

In case of gifts received in assets that already have an allocation in the Reserve (like CELO, BTC, ETH, or DAI), they are simply considered part of the Reserve, ignoring the fact that they were gifted. Messages received in the incoming transfers are never considered endorsed by the Reserve, nor the Celo community.

Technical challenges:

  1. Assets on the Reserve address: any asset currently sent to this address would be unmovable because this smart contract can’t trigger a transfer, thus for them to be usable in the short term, they should be sent to the Governance Proxy contract, were governance can trigger a smart contract call to move/sell the assets.
    A contract upgrade could be proposed to make the Reserve able to move and/or sell tokens in its address. This would create a separation between funds that are meant to help the stability mechanism versus funds that are meant to be distributed as part of the community fund.
  2. Nothing prevents anyone from sending a non-transferable token to the Reserve (or other core contracts). In that case, the only way to remove that asset from the Reserve address would be an expensive hard fork.

Economical open questions:

  1. As assets gifted to the Reserve may also sit on the Celo Platform, all assets gifted to the Reserve potentially have a high correlation with the price of Celo, thus their usefulness as hedge, or even last resort in the case of undercollateralization of stable assets, remains to be proven.

Discussion:

  1. How should the Reserve handle assets submitted to it on-chain?
  2. What are the potential legal risks associated with receiving assets and holding them in core contracts?
  3. Would a contract upgrade to support gifts in the Reserve address make sense?
  4. Should the Reserve interact with projects built on Celo?
  5. How are other projects dealing with gifts? Vitalik Buterin notably exchanged and donated $60M worth of assets gifted to him.
1 Like
2

Thanks for this post, I see three steps for a simple approach.

1. Baseline
Let’s me for now call these “Type 1” or “Approved Reserve Assets”.
As a baseline, Celo protocol should only be handling assets that are specifically approved by governance to be part of the Reserve (Celo, BTC, ETH, DAI).

2. Gifts to Approved Reserve Asset Addresses that are not Reserve Assets themselves
Let’s call these “Type 2” assets.
Examples here would be UBE sent to the reserve’s Celo address, or BCH sent to the reserve’s BTC address.

  • I think all of these should be liquidated (within some reasonable time frame) and swapped for the Approved Reserve Asset (Rebalancing would then occur among Approved Reserve Assets as per governance protocol).
  • I don’t think we should have random amounts of Celo alts (or Ethereum alts for that matter) as part of the reserve. This makes the reserve strategy messy and will be hard to systematize. If there is a specific desire for the protocol to support “friendly tokens” I think this should be handled in a separate CGP (I don’t think this is a good idea).

3. Gifts to non-Approved Reserve Asset Addresses
Let’s call these “Type 3” assets.
An example here would be a gift of ADA (Cardano) [unless it is wrapped ADA for the Celo blockchain] to the Celo Reserve.
I think these gifts should be ignored. In any case, I don’t see how these gifts would arise because Celo reserve would not own/control any non-Approved Reserve Asset Addresses (e.g. a Cardano address) - unless I’m missing something.

3

On 2. I don’t think this would be useful, in that case no project would ever send tokens to the Reserve if they are going to be liquidated right away, specially in the early days.

On 3. I agree this is a good approach, if the reserve smart address on ETH or other EVM receives address, they should be ignored completely. (in the case they sent it to an smart contract address, there’s actually no way of transferring it anyway since the contracts wont be deployed on that chain on that address)

4

Thanks @martinvol , re point 2, I feel that encouraging tokens to be sent to the reserve tends to increase the need for governance and subjectivity. I would think that governance has a lot to manage already that needs streamlining before something like this would be introduced. At the same time, I understand if there are other views on this point and welcome them.

5

Hi @martinvol , to add to my point above:

  • As I have posted above, I prefer that governance not encourage protocols to donate/assign tokens to the reserve (unless they are willing to donate type 1 assets). More above.

  • If governance did decide to allow type 2 assets in the reserve, I would still recommend against them being counted as part of the official reserve. Quite simply, the safety that is provided by two units of high quality collateral is not the same as one unit of high quality and one of low quality. We will then move into a scenario where reserve assets will need to be risk weighted in order to calculate “effective collateralisation”. It will be like Basel II and Basel III all over again. I would highly recommend focusing on high quality collateral for now in this early stage of the protocol.

Side note: I think the same logic applies for why MCO2 should not be added as a reserve asset.

1 Like
6

  1. In general, crypto-assets sent to the reserve voluntarily can be viewed as a type of “Trojan gift,” or “gift-with-strings-attached,” in that projects who want to be added to the reserve aim to circumnavigate the typical governance process by depositing their tokens to the reserve. This sort of behavior can be easily disarmed by liquidating all non-reserve listed crypto-assets. Imagine this line of argument: “Look, our tokens are already in the reserve, and we’re super-missioned aligned with Celo, we should definitely be a reserve asset! We gave Celo such a nice gift, now it should go both ways!”

  2. A more efficient way of large-scale liquidation than dumping through some AMM (e.g. Ubeswap) would be something like a batch or reverse Dutch auction. Implementations exist for both already today.

1 Like
7

We’re planning on giving a portion of MOO tokens to the Celo reserve. Our thinking is that by giving value to the reserve, we help provide a more diversified asset base to backstop the value of cTokens. Moola markets are dependent on the value of cUSD, cEUR, and future cTokens maintaining their peg, so Moola has a vested interest in making sure they are sufficiently collateralized.

8

@Patrick , could you share your view on the benefits to Moola from gifting tokens to the Celo reserve? Thanks

1 Like
9

I can’t think of any benefits to Moola unless the “tokens gifted” for the purpose of collateralization are “HQLA crypto-assets”. Otherwise it’s just additional risk.

If Moola is willing to provide a certain level of liquidity depth to their token (essentially by LPing their own pools) then this risk is mitigated. One thing I’ve mentioned before is the need to define what an appropriate and low-risk pool depth would look like and to uphold a common quantitative standard.

MakerDAO has a great risk assessment dashboard for these types of metrics (on-chain liquidity | relevant forum post).

As a side note:

It might actually be worth requiring LP tokens as collateral for riskier mid-cap projects. Something I’ve been thinking about.

10

What are you calling type 1 or 2 assets?

In case you’re referring to (1) assets to hold and (2) assets to liquidate, the tricky thing here is that I don’t think the Reserve should consider tokens before it gets them, so it’s not possible to know how they’d be considered before they send it.

11

Hi @martinvol , see here for my definitions of types 1, 2 and 3 assets. Cheers.

12

Hey @Pinotio.com, the benefits to Moola from gifting tokens to the Celo reserve that I see are;

  1. We contribute additional value held in the Celo reserve which means that Moola markets are that much more likely to remain solvent since our markets rely on cTokens maintaining their price peg.

  2. Moola community treasury benefits from price stability of cTokens because the treasury collects revenue in cUSD and cEUR.

  3. We set a precedent that other projects may choose to follow by gifting some portion of their governance tokens to the reserve, which again would bolster the value and increase diversity in the reserve.

  4. By gifting MOO tokens to the reserve we are also delegating that amount of voting authority (once we transfer Moola governance to MOO owners) to CELO owners. This is beneficial because it increases the likelihood that over time Moola will be governed in a way that serves the best interest of the Celo network, protocol, and community.

1 Like
13

Thanks @Patrick . Noted on 1-3. Re point 4, I think this brings up an important question for Celo governance - were such tokens to be accepted in the reserve - as to whether and how they would be voted.

As I understand, BTC, ETH and DAI tokens held in reserve are not voted, nor are there plans to do so.

In principle voting those tokens could make sense, but in practise I would prefer to see a focus on first developing the quality of Celo governance. As with most - if not all - blockchains, there are big challenges around voter participation and also challenges around the large mismatch between those with activity/engagement (e.g. building on the protocol or contributing on the forum) and those with voting power.

14

Hi All, synthesizing this thread and throwing in my summary thoughts.

  1. To echo @martinvol and @Patrick 's points, there are several good reasons for the protocol to accept gifts to the reserve; principal of which is that gifts to the reserve bolster stability. Therefore, it makes sense to have a policy that encourages gifts to the reserve, because they increase the stability characteristics of the protocol.

  2. To echo @Pinotio.com and @papa_raw 's points, if those gifts become part of the official reserve (in other words, if the protocol includes these gifts in computing collateralization ratio or determining target allocations), such a policy runs the risk of being counter-productive to stability, by introducing cases where the protocol could effectively be substituting lower-volatility assets with potentially higher-volatility assets (or by introducing cases where the community needs to make ad-hoc governance decisions around an asset at the time of a gift). Therefore, it makes sense to have a policy that does not use these gifts when computing target allocations and collateralization ratios, or when determining future reserve assets.

These points are both valid, and it feels to me straightforward to synthesize them, as follows. We could introduce a construct called a supplemental reserve, where gifts are sent. The supplemental reserve is never liquidated, unless the base reserve collateralization ratio goes below the Tobin Tax threshold, at which point the reserve assets in the supplemental reserve can be liquidated pro rata and proceeds sent to the base reserve until the collateralization ratio is back to par. Everything else in the protocol remains the same – target allocations and collateralization ratios are computed on the base reserve, ignoring the supplemental reserve.

This has clear stability benefits to the protocol, without introducing the concerns about risk or governance simplicity brought up earlier in the thread.

There are broader questions about how best to do governance around selection (and eventually voting) of reserve assets more generally. I think is worth having a discussion on this in a separate thread, but with this synthesis above, this can be treated as a parallel conversation, since this supplemental reserve construct can be introduced regardless of the means of governance for asset selection (and voting) in the base reserve.

3 Likes
15

A nice suggestion @sep . I support it.

3 Likes