From 06307b200e824669d6922196915fcd3ee2c444ba Mon Sep 17 00:00:00 2001 From: GigaHierz Date: Mon, 31 Aug 2026 13:34:27 +0100 Subject: [PATCH 1/3] docs(release-process): fix wrong monorepo paths, invalid bash, and stale release-script flags MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Supersedes #2139, which was opened in February and has since diverged from main: merging it as-is would revert four fixes main has picked up (the `description` frontmatter, the pinned celo-monorepo setup link, the OpenZeppelin proxies link, and the anvil network option). This applies only the parts of #2139 that main still needs, on top of current main. Verified against celo-org/celo-monorepo: - `packages/what-is-celo/about-celo-l1/protocol/releaseData/` 404s — a bad find-and-replace from an old docs migration. The real path is `packages/protocol/releaseData/initializationData/`, which exists. - `.circleci/` 404s; the repo moved to GitHub Actions. `RELEASE_TAG` is defined at `.github/workflows/celo-monorepo.yml:32`. Bash that could not run: - `${N-1}` is parameter expansion with a default, not arithmetic — it evaluates to "N" whenever N is unset, so `PREVIOUS_RELEASE` came out as `core-contracts.vN`. Now `$((N-1))`. - `NETWORK=${"anvil"|"celo-sepolia"|"mainnet"}` is a syntax error. Now a real assignment with the options in a comment. - Six blocks used `$N`, `$PREVIOUS_RELEASE`, `$RELEASE_CANDIDATE` or `$PRIVATE_KEY` without defining them. Each block now stands alone (AGENTS.md section 5). The examples use N=18, the next release after the `core-contracts.v17` currently pinned in the workflow. Release script flags and outputs brought in line with the current implementation: `-r`/`-p` no longer name files that the scripts write themselves, `-k` is required by `release:make`, and the generated filenames (`report-*`, `*-libraries.json`, `proposal-*`) are stated where they are produced and used. Also drops the `export const N = "N"` Docusaurus leftover and three typos (Vaildator, valildator, EXCECUTED). Verified: `mintlify broken-links` reports no broken links. Co-Authored-By: martinvol Co-Authored-By: Claude Opus 5 (1M context) --- .../release-process/smart-contracts.mdx | 45 ++++++++++--------- 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/contribute-to-celo/release-process/smart-contracts.mdx b/contribute-to-celo/release-process/smart-contracts.mdx index f0a2fc3c5..4278c035a 100644 --- a/contribute-to-celo/release-process/smart-contracts.mdx +++ b/contribute-to-celo/release-process/smart-contracts.mdx @@ -4,8 +4,6 @@ sidebarTitle: "Smart Contracts" description: Details of the release process for updating smart contracts on the Celo platform. --- -export const N = "N"; - Details of the release process for updating smart contracts on the Celo platform. @@ -44,7 +42,7 @@ Mixin contracts and libraries are considered part of the contracts that consume ### Initialize Data -Whenever Celo Core Contracts need to be re-initialized, their initialization arguments should be checked into version control under `packages/what-is-celo/about-celo-l1/protocol/releaseData/initializationData/release${N}.json`. +Whenever Celo Core Contracts need to be re-initialized, their initialization arguments should be checked into version control under `packages/protocol/releaseData/initializationData/release${N}.json`. ### Release management in Git/Github @@ -55,13 +53,13 @@ Github branches/tags and Github releases are used to coordinate past and ongoing 1. A new release branch is created `release/core-contracts/${N}` with the contracts to be audited. 2. The latest commit on the release branch is tagged with `core-contracts.v${N}.pre-audit`. 3. On Github, a pre-release Github release should be created pointing at the latest tag on the release branch. -4. On master branch, `.circleci/config.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `celo-core-contracts-v${N}.pre-audit` so that all future changes to master are versioned against the new release. +4. On master branch, `.github/workflows/celo-monorepo.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `celo-core-contracts-v${N}.pre-audit` so that all future changes to master are versioned against the new release. 5. Ongoing audit responses/fixes should continue to go into `release/celo-core-contracts/${N}`. #### After a completed release process: 1. The release branch should be merged into `master` with a merge commit (instead of the usual squash merge strategy). -2. On master branch, `.circleci/config.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `core-contracts.v${N}` +2. On master branch, `.github/workflows/celo-monorepo.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `core-contracts.v${N}` ## Release Process @@ -90,13 +88,14 @@ yarn tags:view ```bash # Run from `packages/protocol` in the celo-monorepo -PREVIOUS_RELEASE="core-contracts.v${N-1}" -NETWORK=${"anvil"|"celo-sepolia"|"mainnet"} +N=18 # the release being prepared +PREVIOUS_RELEASE="core-contracts.v$((N-1))" +NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" # A -f boolean flag can be provided to use a forno full node to connect to the provided network yarn release:verify-deployed -n $NETWORK -b $PREVIOUS_RELEASE -f ``` -A `libraries.json` file is written to disk only necessary for `release:make` that describes linked library addresses. +A `$NETWORK-$PREVIOUS_RELEASE-libraries.json` file is written to disk describing linked library addresses. `release:make` requires it. ### Check Backward Compatibility @@ -121,12 +120,13 @@ article](https://docs.openzeppelin.com/upgrades-plugins/proxies#storage-collisio by OpenZeppelin for a good overview of this problem and why it's important to check for it. -The script generates a detailed report on version changes in JSON format. +The script generates a detailed report on version changes in JSON format, written to `report-$PREVIOUS_RELEASE-$RELEASE_CANDIDATE.json`. ```bash -PREVIOUS_RELEASE="core-contracts.v${N-1}" +N=18 +PREVIOUS_RELEASE="core-contracts.v$((N-1))" RELEASE_CANDIDATE="core-contracts.v${N}" -yarn release:check-versions -a $PREVIOUS_RELEASE -b $RELEASE_CANDIDATE -r "report.json" +yarn release:check-versions -a $PREVIOUS_RELEASE -b $RELEASE_CANDIDATE ``` This should be used in tandem with `release:verify-deployed -b $PREVIOUS_RELEASE -n $NETWORK` to ensure the compatibility checks compare the release candidate to what is actually active on the network. @@ -134,12 +134,15 @@ This should be used in tandem with `release:verify-deployed -b $PREVIOUS_RELEASE ### Deploy the release candidate Use the following script to build and deploy a candidate release. This takes as input the corresponding backward compatibility report and canonical library address mapping to deploy **changed** contracts to the specified network. (Use `-d` to dry-run the deploy). -STORAGE updates are adopted by deploying a new proxy/implementation pair. This script outputs a JSON contract upgrade governance proposal. +STORAGE updates are adopted by deploying a new proxy/implementation pair. This script writes a JSON contract upgrade governance proposal to `proposal-$NETWORK-$RELEASE_CANDIDATE.json`. ```bash -NETWORK=${"anvil"|"celo-sepolia"|"mainnet"} +N=18 +NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" +PREVIOUS_RELEASE="core-contracts.v$((N-1))" RELEASE_CANDIDATE="core-contracts.v${N}" -yarn release:make -b $RELEASE_CANDIDATE -n $NETWORK -r "report.json" -i "releaseData/initializationData/release${N}.json" -p "proposal.json" -l "libraries.json" +PRIVATE_KEY= # deployer key for $NETWORK +yarn release:make -b $RELEASE_CANDIDATE -n $NETWORK -r "report-$PREVIOUS_RELEASE-$RELEASE_CANDIDATE.json" -i "releaseData/initializationData/release${N}.json" -l "$NETWORK-$PREVIOUS_RELEASE-libraries.json" -k $PRIVATE_KEY ``` The proposal encodes STORAGE updates by repointing the Registry to the new proxy. Storage compatible upgrades are encoded by repointing the existing proxy's implementation. @@ -150,7 +153,7 @@ Submit the autogenerated upgrade proposal to the Governance contract for review ```bash # resultant proposal ID should be communicated publicly -celocli governance:propose --deposit 100e18 --from $YOUR_ADDRESS --jsonTransactions "proposal.json" --descriptionURL https://github.com/celo-org/governance/blob/main/CGPs/cgp-0055.md +celocli governance:propose --deposit 100e18 --from $YOUR_ADDRESS --jsonTransactions "proposal-$NETWORK-$RELEASE_CANDIDATE.json" --descriptionURL https://github.com/celo-org/governance/blob/main/CGPs/cgp-0055.md ``` ### Fetch Upgrade Proposal @@ -170,8 +173,9 @@ accepted contract upgrade (in the form of the proposal.json you fetched in the s Additionally, include `initialization_data.json` from the CGP if any of the contracts have to be initialized. ```bash +N=18 RELEASE_CANDIDATE="core-contracts.v${N}" -NETWORK=${"anvil"|"celo-sepolia"|"mainnet"} +NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" # A -f boolean flag can be provided to use a forno full node to connect to the provided network yarn release:verify-release -p "upgrade_proposal.json" -b $RELEASE_CANDIDATE -n $NETWORK -f -i initialization_data.json ``` @@ -181,8 +185,9 @@ yarn release:verify-release -p "upgrade_proposal.json" -b $RELEASE_CANDIDATE -n After a release executes via Governance, you can use `release:verify-deployed` again to check that the resulting network state does indeed reflect the tagged release candidate: ```bash +N=18 RELEASE="core-contracts.v${N}" -NETWORK=${"anvil"|"celo-sepolia"|"mainnet"} +NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" yarn release:verify-deployed -n $NETWORK -b $RELEASE -f ``` @@ -218,7 +223,7 @@ After a successful release execution on a testnet, the resulting network state s ``` - Complete a round of attestation - Redeem from Escrow -- Register a Vaildator +- Register a Validator ```bash celocli validator:register --blsKey --blsSignature --ecdsaKey --from ``` @@ -227,7 +232,7 @@ After a successful release execution on a testnet, the resulting network state s ```bash celocli election:run ``` -- Get a valildator slashed for downtime and ejected from the validator set +- Get a validator slashed for downtime and ejected from the validator set - Propose a governance proposal and get it executed ```bash celocli governance:propose --jsonTransactions --deposit --from --descriptionURL https://gist.github.com/yorhodes/46430eacb8ed2f73f7bf79bef9d58a33 @@ -423,7 +428,7 @@ Deploying a new contract release should occur with the following process. On-cha Passed or Rejected) and notify the community in the Discord #governance channel. -
  • Change corresponding CGP status to EXCECUTED.
    • +
  • Change corresponding CGP status to EXECUTED.
  • Merge the release branch into master with a merge commit From 6ae8ac3a29b907bb4744fd1bf9f7a658e3ba808a Mon Sep 17 00:00:00 2001 From: GigaHierz Date: Wed, 2 Sep 2026 22:46:26 +0100 Subject: [PATCH 2/3] docs(release-process): use the Foundry script names that still exist MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The four Truffle release scripts this page invoked were deleted from celo-monorepo, so the process could not be followed end to end: release:verify-deployed -> release:verify-deployed:foundry release:make -> release:make:foundry release:check-versions -> release:check-versions:foundry release:verify-release -> deleted; verify-deployed:foundry takes -p check-versions is the one that hides: the package.json key still exists, so grep finds it, but check-versions.sh calls build_tag and release-lib.sh now defines only build_tag_foundry, so it dies under set -euo pipefail before compiling anything. Also: - correct the pre-audit tag to the core-contracts.v${N} family - drop "(Use -d to dry-run)": the Foundry script has no -d; -u takes an RPC URL, so a local anvil fork is the way to rehearse - quote $PRIVATE_KEY and give it a visible placeholder — empty and unquoted, it word-split to a bare trailing -k and getopts bailed before the script's own "Need to set the private key" message could print - define N, NETWORK and RELEASE_CANDIDATE in the celocli propose block, which used two of them undefined and resolved to proposal--.json - name upgrade_proposal.json in the verify step instead of a proposal.json that appears nowhere else on the page - add forge, cast and jq to the prerequisites, and the packages/protocol working-directory comment to every block that needs it - link RELEASE_PROCESS_FOUNDRY.md, which maps each retired command Co-Authored-By: Claude Opus 5 (1M context) --- .../release-process/smart-contracts.mdx | 40 +++++++++++-------- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/contribute-to-celo/release-process/smart-contracts.mdx b/contribute-to-celo/release-process/smart-contracts.mdx index 4278c035a..6ce524c18 100644 --- a/contribute-to-celo/release-process/smart-contracts.mdx +++ b/contribute-to-celo/release-process/smart-contracts.mdx @@ -53,7 +53,7 @@ Github branches/tags and Github releases are used to coordinate past and ongoing 1. A new release branch is created `release/core-contracts/${N}` with the contracts to be audited. 2. The latest commit on the release branch is tagged with `core-contracts.v${N}.pre-audit`. 3. On Github, a pre-release Github release should be created pointing at the latest tag on the release branch. -4. On master branch, `.github/workflows/celo-monorepo.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `celo-core-contracts-v${N}.pre-audit` so that all future changes to master are versioned against the new release. +4. On master branch, `.github/workflows/celo-monorepo.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `core-contracts.v${N}.pre-audit` so that all future changes to master are versioned against the new release. 5. Ongoing audit responses/fixes should continue to go into `release/celo-core-contracts/${N}`. #### After a completed release process: @@ -63,10 +63,10 @@ Github branches/tags and Github releases are used to coordinate past and ongoing ## Release Process -There are several scripts provided (under `packages/protocol` in [celo-org/celo-monorepo](https://github.com/celo-org/celo-monorepo) and via [celocli](/cli/)) for use in the release process and with contract upgrade governance proposals to give participating stakeholders increased confidence. +There are several scripts provided (under `packages/protocol` in [celo-org/celo-monorepo](https://github.com/celo-org/celo-monorepo) and via [celocli](/cli/)). The release owners' own reference is [`RELEASE_PROCESS_FOUNDRY.md`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/RELEASE_PROCESS_FOUNDRY.md), which maps each retired Truffle command to its Foundry replacement. These are for use in the release process and with contract upgrade governance proposals to give participating stakeholders increased confidence. -For these to run, you may need to set up the celo-monorepo: follow the [Getting Started](https://github.com/celo-org/celo-monorepo/blob/045aa0061/README.md#-getting-started) steps and install the Node version pinned in [`.nvmrc`](https://github.com/celo-org/celo-monorepo/blob/045aa0061/.nvmrc) (managed with `nvm`). A successful `yarn install` and `yarn build` in the protocol package signal a completed setup. +For these to run, you may need to set up the celo-monorepo: follow the [Getting Started](https://github.com/celo-org/celo-monorepo/blob/045aa0061/README.md#-getting-started) steps and install the Node version pinned in [`.nvmrc`](https://github.com/celo-org/celo-monorepo/blob/045aa0061/.nvmrc) (managed with `nvm`). A successful `yarn install` and `yarn build` in the protocol package signal a completed setup. The release scripts also shell out to [Foundry](https://getfoundry.sh) (`forge`, `cast`) and `jq`, so install those too. Using these tools, a contract release candidate can be built, deployed, and proposed for upgrade automatically on a specified network. Subsequently, stakeholders can verify the release candidate against a governance upgrade proposal's contents on the network. @@ -79,12 +79,13 @@ Typical script options: ### View the tagged releases for each network ```bash +# Run from `packages/protocol` in the celo-monorepo yarn tags:view ``` ### Verify the previous Release on the Network -`release:verify-deployed` is a script that allows you to assess whether the bytecode on the given network matches the source code of a particular commit. It will run through the Celo Core Contracts and verify that the contracts' bytecodes as specified in the `Registry` match. Here, we will want to sanity-check that our network is running the previous release's audited commit. +`release:verify-deployed:foundry` is a script that allows you to assess whether the bytecode on the given network matches the source code of a particular commit. It will run through the Celo Core Contracts and verify that the contracts' bytecodes as specified in the `Registry` match. Here, we will want to sanity-check that our network is running the previous release's audited commit. ```bash # Run from `packages/protocol` in the celo-monorepo @@ -92,10 +93,10 @@ N=18 # the release being prepared PREVIOUS_RELEASE="core-contracts.v$((N-1))" NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" # A -f boolean flag can be provided to use a forno full node to connect to the provided network -yarn release:verify-deployed -n $NETWORK -b $PREVIOUS_RELEASE -f +yarn release:verify-deployed:foundry -n $NETWORK -b $PREVIOUS_RELEASE -f ``` -A `$NETWORK-$PREVIOUS_RELEASE-libraries.json` file is written to disk describing linked library addresses. `release:make` requires it. +A `$NETWORK-$PREVIOUS_RELEASE-libraries.json` file is written to disk describing linked library addresses. `release:make:foundry` requires it. ### Check Backward Compatibility @@ -123,26 +124,28 @@ check for it. The script generates a detailed report on version changes in JSON format, written to `report-$PREVIOUS_RELEASE-$RELEASE_CANDIDATE.json`. ```bash +# Run from `packages/protocol` in the celo-monorepo N=18 PREVIOUS_RELEASE="core-contracts.v$((N-1))" RELEASE_CANDIDATE="core-contracts.v${N}" -yarn release:check-versions -a $PREVIOUS_RELEASE -b $RELEASE_CANDIDATE +yarn release:check-versions:foundry -a $PREVIOUS_RELEASE -b $RELEASE_CANDIDATE ``` -This should be used in tandem with `release:verify-deployed -b $PREVIOUS_RELEASE -n $NETWORK` to ensure the compatibility checks compare the release candidate to what is actually active on the network. +This should be used in tandem with `release:verify-deployed:foundry -b $PREVIOUS_RELEASE -n $NETWORK` to ensure the compatibility checks compare the release candidate to what is actually active on the network. ### Deploy the release candidate -Use the following script to build and deploy a candidate release. This takes as input the corresponding backward compatibility report and canonical library address mapping to deploy **changed** contracts to the specified network. (Use `-d` to dry-run the deploy). +Use the following script to build and deploy a candidate release. This takes as input the corresponding backward compatibility report and canonical library address mapping to deploy **changed** contracts to the specified network. The Foundry script has no dry-run; pass `-u` with a local anvil fork's RPC URL to rehearse it. STORAGE updates are adopted by deploying a new proxy/implementation pair. This script writes a JSON contract upgrade governance proposal to `proposal-$NETWORK-$RELEASE_CANDIDATE.json`. ```bash +# Run from `packages/protocol` in the celo-monorepo N=18 NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" PREVIOUS_RELEASE="core-contracts.v$((N-1))" RELEASE_CANDIDATE="core-contracts.v${N}" -PRIVATE_KEY= # deployer key for $NETWORK -yarn release:make -b $RELEASE_CANDIDATE -n $NETWORK -r "report-$PREVIOUS_RELEASE-$RELEASE_CANDIDATE.json" -i "releaseData/initializationData/release${N}.json" -l "$NETWORK-$PREVIOUS_RELEASE-libraries.json" -k $PRIVATE_KEY +PRIVATE_KEY="0x..." # deployer key for $NETWORK +yarn release:make:foundry -b $RELEASE_CANDIDATE -n $NETWORK -r "report-$PREVIOUS_RELEASE-$RELEASE_CANDIDATE.json" -i "releaseData/initializationData/release${N}.json" -l "$NETWORK-$PREVIOUS_RELEASE-libraries.json" -k "$PRIVATE_KEY" ``` The proposal encodes STORAGE updates by repointing the Registry to the new proxy. Storage compatible upgrades are encoded by repointing the existing proxy's implementation. @@ -153,6 +156,9 @@ Submit the autogenerated upgrade proposal to the Governance contract for review ```bash # resultant proposal ID should be communicated publicly +N=18 +NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" +RELEASE_CANDIDATE="core-contracts.v${N}" celocli governance:propose --deposit 100e18 --from $YOUR_ADDRESS --jsonTransactions "proposal-$NETWORK-$RELEASE_CANDIDATE.json" --descriptionURL https://github.com/celo-org/governance/blob/main/CGPs/cgp-0055.md ``` @@ -167,28 +173,30 @@ celocli governance:show --proposalID --jsonTransactions "upgrade_pr ### Verify Proposed Release Candidate -This script serves the same purpose as `release:verify-deployed` but for a not-yet -accepted contract upgrade (in the form of the proposal.json you fetched in the step prior). It gives you the confidence that the branch specified in the `-b` flag in (same as `release:check-versions`) will be the resulting network state of the proposal if executed. It does so by going over all Celo Core Contracts and determining updates to the Registry pointers, proxy or implementation contracts and verifying their implied bytecode against the compiled source code. +This script serves the same purpose as `release:verify-deployed:foundry` but for a not-yet +accepted contract upgrade (in the form of the `upgrade_proposal.json` you fetched in the step prior). It gives you the confidence that the branch specified in the `-b` flag in (same as `release:check-versions:foundry`) will be the resulting network state of the proposal if executed. It does so by going over all Celo Core Contracts and determining updates to the Registry pointers, proxy or implementation contracts and verifying their implied bytecode against the compiled source code. Additionally, include `initialization_data.json` from the CGP if any of the contracts have to be initialized. ```bash +# Run from `packages/protocol` in the celo-monorepo N=18 RELEASE_CANDIDATE="core-contracts.v${N}" NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" # A -f boolean flag can be provided to use a forno full node to connect to the provided network -yarn release:verify-release -p "upgrade_proposal.json" -b $RELEASE_CANDIDATE -n $NETWORK -f -i initialization_data.json +yarn release:verify-deployed:foundry -p "upgrade_proposal.json" -b $RELEASE_CANDIDATE -n $NETWORK -f -i initialization_data.json ``` ### Verify Executed Release -After a release executes via Governance, you can use `release:verify-deployed` again to check that the resulting network state does indeed reflect the tagged release candidate: +After a release executes via Governance, you can use `release:verify-deployed:foundry` again to check that the resulting network state does indeed reflect the tagged release candidate: ```bash +# Run from `packages/protocol` in the celo-monorepo N=18 RELEASE="core-contracts.v${N}" NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" -yarn release:verify-deployed -n $NETWORK -b $RELEASE -f +yarn release:verify-deployed:foundry -n $NETWORK -b $RELEASE -f ``` ## Testing From 2bb252cf1d05ae4ff90f6a61e099053aa9e4f492 Mon Sep 17 00:00:00 2001 From: GigaHierz Date: Thu, 3 Sep 2026 11:46:27 +0200 Subject: [PATCH 3/3] docs(release-process): warn about the deployer key in argv, define YOUR_ADDRESS, drop a stray run-from comment Three follow-ups from review: - Add a Warning after the release:make:foundry block. The script's -k flag puts the deployer key on the command line, which is readable by other processes (/proc on Linux) and lands in shell history. This page is where a release engineer meets that interface and it tells them to run it against mainnet, so the page carries the warning. - Define YOUR_ADDRESS in the celocli governance:propose block so it stands alone like the others. - Drop the 'Run from packages/protocol' comment on the tags:view block. That one is git for-each-ref and works from anywhere in the repo; it was the only block where the comment did no work. Co-Authored-By: Claude Fable 5.1 --- contribute-to-celo/release-process/smart-contracts.mdx | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/contribute-to-celo/release-process/smart-contracts.mdx b/contribute-to-celo/release-process/smart-contracts.mdx index 6ce524c18..3eab46b98 100644 --- a/contribute-to-celo/release-process/smart-contracts.mdx +++ b/contribute-to-celo/release-process/smart-contracts.mdx @@ -79,7 +79,6 @@ Typical script options: ### View the tagged releases for each network ```bash -# Run from `packages/protocol` in the celo-monorepo yarn tags:view ``` @@ -148,6 +147,10 @@ PRIVATE_KEY="0x..." # deployer key for $NETWORK yarn release:make:foundry -b $RELEASE_CANDIDATE -n $NETWORK -r "report-$PREVIOUS_RELEASE-$RELEASE_CANDIDATE.json" -i "releaseData/initializationData/release${N}.json" -l "$NETWORK-$PREVIOUS_RELEASE-libraries.json" -k "$PRIVATE_KEY" ``` + +`-k "$PRIVATE_KEY"` puts the deployer key on the command line, where it is readable by other processes on the machine (for example via `/proc` on Linux) and is written to your shell history. Run it from a dedicated deploy machine, and clear the key from the environment and history afterwards. + + The proposal encodes STORAGE updates by repointing the Registry to the new proxy. Storage compatible upgrades are encoded by repointing the existing proxy's implementation. ### Submit Upgrade Proposal @@ -159,6 +162,7 @@ Submit the autogenerated upgrade proposal to the Governance contract for review N=18 NETWORK="celo-sepolia" # "anvil", "celo-sepolia" or "mainnet" RELEASE_CANDIDATE="core-contracts.v${N}" +YOUR_ADDRESS="0x..." # proposer account; must hold the deposit celocli governance:propose --deposit 100e18 --from $YOUR_ADDRESS --jsonTransactions "proposal-$NETWORK-$RELEASE_CANDIDATE.json" --descriptionURL https://github.com/celo-org/governance/blob/main/CGPs/cgp-0055.md ```