From d39b85bf51016ee3492a1d3e38d1fe8712884a9b Mon Sep 17 00:00:00 2001 From: Paul Lange Date: Mon, 24 Aug 2026 11:31:36 +0200 Subject: [PATCH 1/5] docs: delete _deprecated/ (105 unreferenced pages) --- _deprecated/cel2/faq.mdx | 107 ---- _deprecated/cel2/index.mdx | 65 --- .../cel2/notices/celo-sepolia-launch.mdx | 90 ---- .../cel2/notices/eigenda-v2-upgrade.mdx | 74 --- _deprecated/cel2/notices/isthmus-upgrade.mdx | 66 --- _deprecated/cel2/notices/l2-migration.mdx | 13 - _deprecated/cel2/operators/architecture.mdx | 19 - _deprecated/cel2/operators/migrate-node.mdx | 274 ---------- _deprecated/cel2/operators/overview.mdx | 12 - _deprecated/cel2/operators/run-node.mdx | 421 --------------- _deprecated/integration/checklist.mdx | 86 --- _deprecated/integration/cloud-hsm.mdx | 123 ----- _deprecated/integration/custody.mdx | 96 ---- _deprecated/integration/general.mdx | 96 ---- _deprecated/integration/index.mdx | 26 - _deprecated/integration/listings.mdx | 166 ------ .../about-celo-l1/node/run-alfajores.mdx | 113 ---- .../about-celo-l1/node/run-baklava.mdx | 113 ---- .../about-celo-l1/node/run-mainnet.mdx | 123 ----- .../protocol/consensus/index.mdx | 25 - .../protocol/consensus/locating-nodes.mdx | 36 -- .../consensus/validator-set-differences.mdx | 16 - .../protocol/contracts/add-contract.mdx | 28 - .../identity/encrypted-cloud-backup.mdx | 113 ---- .../about-celo-l1/protocol/identity/index.mdx | 54 -- .../protocol/identity/metadata.mdx | 70 --- .../odis-domain-sequential-delay-domain.mdx | 14 - .../protocol/identity/odis-domain.mdx | 50 -- .../identity/odis-use-case-key-hardening.mdx | 42 -- .../odis-use-case-phone-number-privacy.mdx | 40 -- .../about-celo-l1/protocol/identity/odis.mdx | 116 ---- .../protocol/identity/privacy-research.mdx | 16 - .../identity/smart-contract-accounts.mdx | 83 --- .../protocol/pos/becoming-a-validator.mdx | 15 - .../pos/epoch-rewards-locked-gold.mdx | 43 -- .../protocol/pos/epoch-rewards-validator.mdx | 67 --- .../protocol/pos/epoch-rewards.mdx | 50 -- .../about-celo-l1/protocol/pos/index.mdx | 65 --- .../protocol/pos/locked-gold.mdx | 75 --- .../about-celo-l1/protocol/pos/penalties.mdx | 48 -- .../protocol/pos/validator-elections.mdx | 59 -- .../protocol/pos/validator-groups.mdx | 67 --- .../about-celo-l1/protocol/randomness.mdx | 55 -- .../stability/adding-stable-assets.mdx | 89 ---- .../about-celo-l1/protocol/stability/doto.mdx | 60 --- .../protocol/stability/granda-mento.mdx | 56 -- .../protocol/stability/index.mdx | 36 -- .../protocol/stability/oracles.mdx | 31 -- .../protocol/stability/stability-fees.mdx | 63 --- .../transaction/erc20-transaction-fees.mdx | 83 --- .../protocol/transaction/escrow.mdx | 32 -- .../protocol/transaction/gas-pricing.mdx | 42 -- .../protocol/transaction/index.mdx | 23 - .../protocol/transaction/native-currency.mdx | 26 - .../transaction/transaction-types.mdx | 469 ---------------- .../transaction/tx-comment-encryption.mdx | 45 -- .../celo-foundation-voting-policy.mdx | 162 ------ .../about-celo-l1/validator/celo-website.mdx | 4 - .../validator/devops-best-practices.mdx | 35 -- .../about-celo-l1/validator/discord.mdx | 4 - .../about-celo-l1/validator/index.mdx | 43 -- .../validator/key-management/detailed.mdx | 162 ------ .../validator/key-management/key-rotation.mdx | 70 --- .../validator/key-management/summary.mdx | 37 -- .../about-celo-l1/validator/monitoring.mdx | 156 ------ .../about-celo-l1/validator/node-upgrade.mdx | 169 ------ .../about-celo-l1/validator/proxy.mdx | 34 -- .../about-celo-l1/validator/run/mainnet.mdx | 25 - .../about-celo-l1/validator/security.mdx | 32 -- .../validator/troubleshooting-faq.mdx | 59 -- .../validator/validator-explorer.mdx | 109 ---- .../about-celo-l1/validator/voting.mdx | 96 ---- _deprecated/what-is-celo/celo-website.mdx | 4 - .../what-is-celo/joining-celo/builders.mdx | 28 - .../joining-celo/code-of-conduct.mdx | 4 - .../contributors/cip-contributors.mdx | 27 - .../contributors/code-contributors.mdx | 77 --- .../documentation-contributors.mdx | 86 --- .../joining-celo/contributors/overview.mdx | 49 -- .../release-process/attestation-service.mdx | 152 ------ .../base-cli-contractkit-dappkit-utils.mdx | 95 ---- .../release-process/blockchain-client.mdx | 101 ---- .../contributors/release-process/index.mdx | 18 - .../release-process/smart-contracts.mdx | 503 ------------------ .../what-is-celo/joining-celo/daos.mdx | 90 ---- .../what-is-celo/joining-celo/index.mdx | 64 --- .../using-celo/bridged_tokens/tokens.mdx | 24 - _deprecated/what-is-celo/using-celo/index.mdx | 64 --- .../what-is-celo/using-celo/manage/asset.mdx | 62 --- .../using-celo/manage/exchange.mdx | 32 -- .../using-celo/manage/release-gold.mdx | 117 ---- .../using-celo/manage/self-custody.mdx | 435 --------------- .../using-celo/protocol/celo-token.mdx | 48 -- .../using-celo/protocol/consensus.mdx | 46 -- .../using-celo/protocol/escrow.mdx | 32 -- .../governance/governable-parameters.mdx | 30 -- .../governance/governance-toolkit.mdx | 38 -- .../protocol/governance/overview.mdx | 95 ---- .../governance/smart-contracts-upgrades.mdx | 26 - .../voting-in-governance-using-mondo.mdx | 38 -- .../governance/voting-in-governance.mdx | 182 ------- .../using-celo/protocol/index.mdx | 34 -- .../protocol/transaction/overview.mdx | 53 -- .../transaction/transaction-types.mdx | 489 ----------------- .../transaction/tx-comment-encryption.mdx | 38 -- 105 files changed, 8763 deletions(-) delete mode 100644 _deprecated/cel2/faq.mdx delete mode 100644 _deprecated/cel2/index.mdx delete mode 100644 _deprecated/cel2/notices/celo-sepolia-launch.mdx delete mode 100644 _deprecated/cel2/notices/eigenda-v2-upgrade.mdx delete mode 100644 _deprecated/cel2/notices/isthmus-upgrade.mdx delete mode 100644 _deprecated/cel2/notices/l2-migration.mdx delete mode 100644 _deprecated/cel2/operators/architecture.mdx delete mode 100644 _deprecated/cel2/operators/migrate-node.mdx delete mode 100644 _deprecated/cel2/operators/overview.mdx delete mode 100644 _deprecated/cel2/operators/run-node.mdx delete mode 100644 _deprecated/integration/checklist.mdx delete mode 100644 _deprecated/integration/cloud-hsm.mdx delete mode 100644 _deprecated/integration/custody.mdx delete mode 100644 _deprecated/integration/general.mdx delete mode 100644 _deprecated/integration/index.mdx delete mode 100644 _deprecated/integration/listings.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/node/run-alfajores.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/node/run-baklava.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/node/run-mainnet.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/consensus/index.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/consensus/locating-nodes.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/consensus/validator-set-differences.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/contracts/add-contract.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/encrypted-cloud-backup.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/index.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/metadata.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-domain-sequential-delay-domain.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-domain.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-use-case-key-hardening.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-use-case-phone-number-privacy.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/odis.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/privacy-research.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/identity/smart-contract-accounts.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/becoming-a-validator.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-locked-gold.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-validator.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/index.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/locked-gold.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/penalties.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/validator-elections.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/pos/validator-groups.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/randomness.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/stability/adding-stable-assets.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/stability/doto.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/stability/granda-mento.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/stability/index.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/stability/oracles.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/stability/stability-fees.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/transaction/erc20-transaction-fees.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/transaction/escrow.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/transaction/gas-pricing.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/transaction/index.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/transaction/native-currency.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/transaction/transaction-types.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/protocol/transaction/tx-comment-encryption.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/celo-foundation-voting-policy.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/celo-website.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/devops-best-practices.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/discord.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/index.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/key-management/detailed.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/key-management/key-rotation.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/key-management/summary.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/monitoring.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/node-upgrade.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/proxy.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/run/mainnet.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/security.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/troubleshooting-faq.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/validator-explorer.mdx delete mode 100644 _deprecated/what-is-celo/about-celo-l1/validator/voting.mdx delete mode 100644 _deprecated/what-is-celo/celo-website.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/builders.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/code-of-conduct.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/cip-contributors.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/code-contributors.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/documentation-contributors.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/overview.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/release-process/attestation-service.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/release-process/base-cli-contractkit-dappkit-utils.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/release-process/blockchain-client.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/release-process/index.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/contributors/release-process/smart-contracts.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/daos.mdx delete mode 100644 _deprecated/what-is-celo/joining-celo/index.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/bridged_tokens/tokens.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/index.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/manage/asset.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/manage/exchange.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/manage/release-gold.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/manage/self-custody.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/celo-token.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/consensus.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/escrow.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/governance/governable-parameters.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/governance/governance-toolkit.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/governance/overview.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/governance/smart-contracts-upgrades.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/governance/voting-in-governance-using-mondo.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/governance/voting-in-governance.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/index.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/transaction/overview.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/transaction/transaction-types.mdx delete mode 100644 _deprecated/what-is-celo/using-celo/protocol/transaction/tx-comment-encryption.mdx diff --git a/_deprecated/cel2/faq.mdx b/_deprecated/cel2/faq.mdx deleted file mode 100644 index f0834e2a39..0000000000 --- a/_deprecated/cel2/faq.mdx +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Cel2 FAQ -og:description: Frequently Asked Questions about Cel2 ---- - -## Isthmus - -### My Alfajores node stalled at the Isthmus hardfork block (49908280) - -If you reached the hardfork block before upgrading to v2.1.0 your node can get stuck. - -This can be resolved by upgrading both op-geth and op-node to v2.1.0, stopping -op-node, rewinding the op-geth head to before the hardfork and starting -op-node again. - -To rewind the head you can use: - -``` -cast rpc -r debug_setHead 49908270 -``` - -## Mainnet - -### My node is having trouble keeping up to date with the chain head / having trouble connecting to and finding peers - -A couple of issues could be causing this. - -* If you are running multiple instances of op-node, make sure to check that they each have a unique and persisted private key at `--p2p.priv.path` -* Ensure that your node is accessible to other nodes, check the __Configure P2P for external network access__ section under [Running a full node](/cel2/operators/run-node#running-a-full-node) - -### How do I run a node or upgrade an existing node? - -See the guides for [running a node](/cel2/operators/run-node) or the guide on [how to migrate an L1 node](/cel2/operators/migrate-node). - -### Do I need to run my own EigenDA proxy? - -Yes. This is part of [running a node](/cel2/operators/run-node). -If you're using the [Docker Compose Setup](https://github.com/celo-org/celo-l2-node-docker-compose), it's included. - -### What happened to funds on Celo L1 after the migration to L2? - -All balances have been carried over to the L2, unchanged. - -### How do ERC-20 tokens and the native CELO token work after the migration to L2? - -There is no change and it continues to work in the same way as before. - -### Is Celo able to support Solidity versions above 0.8.19? - -Yes, same as with Ethereum. - -### What data model changes happened in the RPC specs (esp. which gas tokens) between Celo L1 and L2? - -Have a look at the [changes from L1 to L2 in the specs](https://specs.celo.org/l2_migration.html#changes-for-json-rpc-users). - -### What happens to Validators? - -Validators are becoming [Community RPC providers](/cel2/operators/community-rpc-node). - -### Where can I see those [Community RPC providers](/cel2/operators/community-rpc-node)? - -There are multiple options. - -* Install [Celo CLI](/cli/index) at version 6.1.0 or later. Then run: `celocli network:community-rpc-nodes`. -* [Vido Node Explorer](https://dev.vido.atalma.io/celo/rpc) -* [Celo Community RPC Gateway](https://celo-community.org/) - -### What happened to governance, since the migration from Celo L1 to L2? - -[Governance](/what-is-celo/using-celo/protocol/governance/overview) remains a pillar of the Celo blockchain. The Validator Hotfix process has been adapted, see [Updated Governance Hotfix](https://specs.celo.org/l2_migration.html#updated-governance-hotfix) for the changes. - -### What happened to these features? - -* CELO token duality? Supported, see [Token Duality](https://specs.celo.org/token_duality.html). -* Fee currencies? Supported, see [Fee Abstraction](https://specs.celo.org/fee_abstraction.html). -* Epoch rewards? Epochs now work differently, but rewards stay, see [Epochs and Rewards](https://specs.celo.org/smart_contract_updates_from_l1.html#epochs-and-rewards). - -### How is the Celo L2 different to Optimism? - -See [What's Changed Optimism -> Celo L2](/legacy/transition/optimism/op-l2). -Also see [Celo L2 Specification](https://specs.celo.org/root.html) for greater detail. - -### What are the costs for L1 data and how are they paid? - -See [What's changed section covering L1 fees](/legacy/transition/optimism/op-l2#l1-fees). - -### What's the block time? - -The block period is 1 second. - -### What's the throughput? - -The gas limit per block is 30 million, so the maximum throughput is 30M gas/s. - -### Is there anything that used to work on Celo L1 that doesn’t anymore on L2? - -See [What's Changed Celo L1 -> L2](/legacy/transition/whats-changed/l1-l2) and [L1 -> L2 Migration Changes](https://specs.celo.org/l2_migration.html) in the spec for greater detail. - -## Testnets - -### What’s the difference between Dango and Alfajores? - -Dango was a short-lived testnet forked from Alfajores at block [24940100](https://celo-alfajores.blockscout.com/block/0xc0e521a7b7326064ec12f51449de16d3218de161335daaa4ae8bbed1790b4a6c) to test the migration to L2. It was shut down in October 2024. - -Alfajores is a long running Celo network testnet that was [launched in July 2019](https://blog.celo.org/introducing-alfajores-1b162ebcb44d) and upgraded to L2 in September 2024. - -See the [Alfajores network info here](/build-on-celo/network-overview). diff --git a/_deprecated/cel2/index.mdx b/_deprecated/cel2/index.mdx deleted file mode 100644 index fd82a04be2..0000000000 --- a/_deprecated/cel2/index.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "Overview" ---- - -## Celo L2 Mainnet - -Celo has transitioned from a standalone EVM-compatible Layer 1 blockchain to an Ethereum Layer 2. -This shift, [proposed by cLabs in July 2023](https://forum.celo.org/t/clabs-proposal-for-celo-to-transition-to-an-ethereum-l2/6109), aims to maintain the seamless user experience that Celo is known for—characterized by speed, low costs, and ease of use—while leveraging Ethereum’s security and ecosystem. - -## What does this mean for our ecosystem? - -Celo's evolution from an L1 EVM-compatible chain to an L2 solution marks a significant milestone in our ongoing relationship with the Ethereum ecosystem. As an L1 chain, Celo has always maintained close ties with Ethereum, sharing its commitment to decentralization, security, and innovation. By transitioning to an L2, Celo strengthens this bond, allowing our developers and protocols to immerse themselves even deeper into the vibrant, collaborative Ethereum community. This integration enhances opportunities for open-source contributions, joint initiatives, and the development of public goods, ensuring that Celo's impact resonates widely across the blockchain space. - -### Technical Changes - -The table below summarizes the technical changes involved in transitioning from Celo's Layer 1 to Layer 2: - -| **Aspect** | **Layer 1** | **Layer 2** | -|----------------------|---------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------| -| **Architecture** | Single service, providing execution, consensus, and data availability. | Multiple services built on the op-stack with separate execution, data availability, and settlement layers. | -| **Bridging** | Third-party bridges connecting to various chains. | Additional native bridge with Ethereum alongside existing third-party bridges. | -| **CELO Token** | Lived on the Celo L1. | Lives on Ethereum; CELO on L2 represents CELO bridged from Ethereum. | -| **Blocks** | 5s long, 50M gas. | 1s long, 30M gas. | -| **Extra Fields** | — | Withdrawals & withdrawalsRoot, blobGasUsed & excessBlobGas, parentBeaconBlockRoot. | -| **Removed Fields** | — | Randomness, epochSnarkData. | -| **Validator Duties**| Operated the consensus protocol. | Validators will temporarily operate community RPC nodes. | -| **Validator Rewards**| Distributed at epoch blocks. | Distributed periodically via smart contract execution. | -| **Sequencing** | Determined by the output of consensus, run by validators. | Initially handled by a centralized sequencer with plans for decentralized sequencing later. | -| **Precompiles** | — | All Celo precompiles removed except for the transfer precompile which supports token duality. | -| **EIP1559** | Governable implementation on-chain. | Upgraded implementation with modified parameters across networks. | -| **Hardforks** | — | Cel2 hardfork for transition to L2 alongside other op-stack hardforks. | -| **Transactions** | — | Deprecated transactions include Type 0 with feeCurrency field and Type 124. | -| **Finality** | One block finality, instantaneous once block is produced. | Finality depends on trust in sequencer, batcher, proposer, and eigenDA, or ultimately on Ethereum. | - -For more detailed technical changes, see [Celo's L2 Migration Documentation](https://specs.celo.org/l2_migration.html). - -## Important Dates - -### Early July, 2024: Dango L2 Testnet Launch - -The Dango Testnet announced on the 7th of July 2024, Celo’s first L2 public test network, went live. Dango allowed developers and infrastructure providers to familiarize themselves with the L2 environment. It was shut down on the 9th of October 2024. - -### 26th September, 2024: Alfajores L2 Testnet Launch - -The Celo L2 testnet, Alfajores, went live! This provides a testing environment for node operators and developers to ensure compatibility before the Mainnet launch. - -### October 2024: Code Freeze and Audits - -The core dev team froze all feature development by mid-October and underwent a thorough external audit. The result is available at https://celo.org/audits. - -### 20th February, 2025: Baklava L2 Testnet Launch - -Using the final audited release, the Celo validator community performed a dry run of the L2 upgrade on the Baklava network. - -### 26th March, 2025: Celo L2 Mainnet Launch - -Following a successful Baklava upgrade, the Celo L2 Mainnet officially went live. - -## Useful Links - -* [Layer 2 Specification](https://specs.celo.org/root.html) -* [Node Operator Guide](/cel2/operators/overview) -* [What's Changed?](/cel2/whats-changed/overview) -* [Cel2 Code](https://github.com/celo-org/optimism) -* [FAQ](/cel2/faq) diff --git a/_deprecated/cel2/notices/celo-sepolia-launch.mdx b/_deprecated/cel2/notices/celo-sepolia-launch.mdx deleted file mode 100644 index 51508fd597..0000000000 --- a/_deprecated/cel2/notices/celo-sepolia-launch.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: "Celo Sepolia Testnet Launch" ---- - -Celo Sepolia is a new developer testnet that will replace Alfajores when Holesky sunsets in September 2025. The Baklava testnet will also sunset with Holesky, with no replacement planned. - - -**Key Information** - -This page will be kept updated with key information about the transition. - -- **Chain ID**: 11142220 -- **Status**: testnet live -- **Built on**: Ethereum Sepolia L1 -- **Phases**: - - Jul 23, 2025: Celo Sepolia launch ✅ - - Jul 24, 2025—Jul 31, 2025: Internal testing ✅ - - Aug 1, 2025—Aug 12, 2025: Early access phase ✅ - - Aug 13, 2025: Public announcement ✅ - - **Aug 14, 2025—Sep 14, 2025: Transition period :round_pushpin:** - - Sep 30, 2025: Planned Alfajores and Baklava sunset, aligned with Holesky deprecation - -**Node Providers**: Please support both Alfajores and Celo Sepolia during the transition period. - -**Developers**: Verify that your dependencies support Celo Sepolia, then go ahead and deploy all contracts. - - -## What is Celo Sepolia? - -Celo Sepolia is the new developer testnet for Celo running as an Ethereum Layer 2 on Sepolia. It starts with a clean slate (no inherited state from Alfajores) and is designed for long-term use following Ethereum Sepolia's testnet lifecycle. - -## Call to Action - -### For Node Providers - -Please support both Alfajores and Celo Sepolia in parallel during the early access and transition phases to ensure a smooth migration for developers. See the [node setup guide](/cel2/operators/run-node) for technical details and our recommended [Docker Compose Setup](https://github.com/celo-org/celo-l2-node-docker-compose). - -Release versions: - -- `op-geth` at [v2.1.2](https://github.com/celo-org/op-geth/releases/tag/celo-v2.1.2) -- `op-node` at [v2.1.0](https://github.com/celo-org/optimism/releases/tag/celo-v2.1.0) -- `eigenda-proxy` at [v1.8.2](https://github.com/layr-labs/eigenda/pkgs/container/eigenda-proxy/437919973?tag=v1.8.2) - -### For Developers - -- Update applications to support chain ID 11142220. -- Redeploy contracts on Celo Sepolia. -- Get testnet CELO tokens from the faucets. - -Since Celo Sepolia starts with a clean slate, there is no historical data or contracts carried over from Alfajores, providing a pristine testing environment. - -## Key Characteristics and Resources - -- Chain ID: 11142220 -- L1 Foundation: Ethereum Sepolia -- EigenDA: v2 (Blazar) -- Contracts: [see the L1 and L2 contracts in the specification](https://specs.celo.org/core_contracts.html?#celo-sepolia-testnet) -- RPC endpoint: [Celo Sepolia Forno](https://forno.celo-sepolia.celo-testnet.org) -- Block explorer: [Blockscout](https://celo-sepolia.blockscout.com) -- Faucets: - - [Google Cloud Web3 Faucet](https://cloud.google.com/application/web3/faucet/celo/sepolia) - - [Celo Sepolia Token Faucet](https://faucet.celo.org/celo-sepolia) -- Bridge: [Superbridge for Celo Sepolia](https://testnets.superbridge.app/?fromChainId=11155111&toChainId=11142220) - -## Key Differences from Alfajores - -| Aspect | Alfajores | Celo Sepolia | -|--------|-----------|--------------| -| L1 Foundation | Ethereum Holesky | Ethereum Sepolia | -| Chain ID | 44787 | 11142220 | -| State | Historical from L1 migration | Fresh start | -| Longevity | Sunset planned Sept 2025 | Long-term testnet | - -## Early Adopters - -Thank you to the first wave of our ecosystem partners supporting Celo Sepolia already: - -- **Google Cloud** – [Google Cloud Web3 Faucet](https://cloud.google.com/application/web3/faucet/celo/sepolia) -- **Blockscout** – [Block Explorer](https://celo-sepolia.blockscout.com/) -- **EigenDA v2** – Data Availability -- **Superbridge** – Bridging Infrastructure -- **Ankr** – Node & RPC Provider -- **AllThatNode by DSRV** – Node & RPC Provider -- **Redstone** – Oracle Services -- **Talent Protocol** – Web3 Professional Network -- **Prosperity Pass** – Celo PG Onchain Access Pass - -## Getting Help - -Please reach out to our team on [Discord](https://chat.celo.org) in the [#celo-L2-support](https://discord.com/channels/600834479145353243/1286649605798367252) channel if you have any questions. diff --git a/_deprecated/cel2/notices/eigenda-v2-upgrade.mdx b/_deprecated/cel2/notices/eigenda-v2-upgrade.mdx deleted file mode 100644 index 46657f5c66..0000000000 --- a/_deprecated/cel2/notices/eigenda-v2-upgrade.mdx +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "Ice Cream Hardfork 🍦" -sidebarTitle: "EigenDA v2 Upgrade" ---- - -This page outlines changes related to the EigenDA v2 upgrade for node operators. - - -This page will be kept updated with key information about the upgrade. As this upgrade is activated on the sequencer, no detailed activation times can be given. - -- Baklava testnet activation was executed on Wed, Jul 30, 2025. -- Alfajores testnet activation was executed on Wed, Aug 20, 2025. -- **Mainnet** activation is planned for Wed, Sep 10, 2025. - - -## What is the Ice Cream Hardfork? - -As part of [Celo’s continued growth as an Ethereum L2](https://forum.celo.org/t/celo-as-an-ethereum-l2-a-frontier-chain-for-global-impact/11376), Celo is integrating [EigenDA v2](https://docs.eigencloud.xyz/products/eigenda/releases/blazar), also known as [Blazar](https://docs.eigencloud.xyz/products/eigenda/releases/blazar), to further innovate and strengthen the network’s data availability layer. - -Blazar represents a major architectural upgrade to the EigenDA protocol, introducing improved system throughput and stability, alongside new capabilities like permissionless DA payments and enhanced resource throttling. - -Most notably for Celo: - -- End-to-end confirmation latency is significantly reduced, moving from minutes to near real-time. Blazar’s design enables rollups to reference blocks in their own logic without waiting for L1 confirmations. -- System throughput and network stability are greatly improved through more efficient chunk distribution, optimized request routing, and horizontal scalability of DA nodes. -Support for decentralized dispersal is unlocked by eliminating DDoS attack surfaces inherent in the original push-based mode. - -## For Node Operators - -Node operators need to upgrade the [EigenDA proxy](https://github.com/Layr-Labs/eigenda/tree/master/api/proxy) to version [v1.8.2](https://github.com/Layr-Labs/eigenda/pkgs/container/eigenda-proxy/437919973?tag=v1.8.2) before the activation date. The version is backwards compatible with EigenDA v1 and can be updated beforehand. - -The new proxy version will require to *add* the following new flags for each network (remember to fill the `eigenda.v2.eth-rpc` and `eigenda.v2.signer-payment-key-hex` from your own set up) - -### Mainnet -``` - --storage.backends-to-enable="V1,V2" \ - --eigenda.v2.disperser-rpc=disperser.eigenda.xyz:443 \ - --eigenda.v2.eth-rpc= \ - --eigenda.v2.signer-payment-key-hex= \ - --eigenda.v2.max-blob-length="16MiB" \ - --eigenda.v2.cert-verifier-addr="0xE1Ae45810A738F13e70Ac8966354d7D0feCF7BD6" \ - --eigenda.v2.service-manager-addr="0x870679e138bcdf293b7ff14dd44b70fc97e12fc0" \ - --eigenda.v2.bls-operator-state-retriever-addr="0xEC35aa6521d23479318104E10B4aA216DBBE63Ce" \ -``` - -### Alfajores and Baklava -``` - --storage.backends-to-enable="V1,V2" \ - --eigenda.v2.disperser-rpc=disperser-holesky.eigenda.xyz:443 \ - --eigenda.v2.eth-rpc= \ - --eigenda.v2.signer-payment-key-hex= \ - --eigenda.v2.max-blob-length="16MiB" \ - --eigenda.v2.cert-verifier-addr="0xFe52fE1940858DCb6e12153E2104aD0fDFbE1162" \ - --eigenda.v2.service-manager-addr="0xD4A7E1Bd8015057293f0D0A557088c286942e84b" \ - --eigenda.v2.bls-operator-state-retriever-addr="0xB4baAfee917fb4449f5ec64804217bccE9f46C67" \ -``` - -### Celo Sepolia -``` - --storage.backends-to-enable="V1,V2" \ - --eigenda.v2.disperser-rpc=disperser-testnet-sepolia.eigenda.xyz:443 \ - --eigenda.v2.eth-rpc= \ - --eigenda.v2.signer-payment-key-hex= \ - --eigenda.v2.max-blob-length="16MiB" \ - --eigenda.v2.cert-verifier-addr="0x73818fed0743085c4557a736a7630447fb57c662" \ - --eigenda.v2.service-manager-addr="0x3a5acf46ba6890B8536420F4900AC9BC45Df4764" \ - --eigenda.v2.bls-operator-state-retriever-addr="0x22478d082E9edaDc2baE8443E4aC9473F6E047Ff" \ -``` - - -**Docker Compose** - -The required configuration for each service can be found in our [Docker Compose Setup](https://github.com/celo-org/celo-l2-node-docker-compose), where every network has a corresponding `.env` file. - diff --git a/_deprecated/cel2/notices/isthmus-upgrade.mdx b/_deprecated/cel2/notices/isthmus-upgrade.mdx deleted file mode 100644 index 0288d28541..0000000000 --- a/_deprecated/cel2/notices/isthmus-upgrade.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: "L2 Isthmus Hardfork" -sidebarTitle: "Isthmus Upgrade" ---- - -This page outlines breaking changes related to the Isthmus network upgrade for node operators. - - -This page will be kept updated with key information about the hardfork. - -- Baklava testnet activation was executed at timestamp `1749654000` ([block 37881140](https://celo-baklava.blockscout.com/block/0xec4a86ed28d74090b71cb59c34e4b31b8a49ef00b09880d67034dc56237e4b1d)) on Wed, Jun 11, 2025, 15:00:00 UTC. -- Alfajores testnet activation was executed at timestamp `1750863600` ([block 49908280](https://celo-alfajores.blockscout.com/block/0x643b5ce0b59b83ffd8a9b9cfc13a91eeb1228094e0dbb3e1927ec2afc28dfbcb)) on Wed, Jun 25, 2025, 15:00:00 UTC. -- **Mainnet** activation was executed at timestamp **`1752073200`** ([block 40172442](https://celo.blockscout.com/block/0xdef57aaf634a3de07e7763db9b21d5e192e784316b8c233a2a4cd1eea6bf4f41)) on Wed, Jul 9, 2025, 15:00:00 UTC. - - - -If you're encountering a stuck node after Alfajores hardfork block (49908280), see the [FAQ](../faq.md#my-alfajores-node-stalled-at-the-isthmus-hardfork-block-49908280). - - -## What's included in Isthmus - -Isthmus contains these main changes: - -- **Implement Prague features on the OP Stack**: This includes the EIPs that are relevant to the L2 that are being added to Ethereum with its Pectra activation. Learn more about this [here](https://gov.optimism.io/t/proposal-preview-implement-prague-features-on-the-op-stack/9703). - - Notable EIP's included: - - [EIP-7702](https://github.com/ethereum/EIPs/blob/f27ddf2b0af7e862a967ee38ceeaa7d980786ca1/EIPS/eip-7702.md): Set code transaction - - [EIP-2537](https://github.com/ethereum/EIPs/blob/f27ddf2b0af7e862a967ee38ceeaa7d980786ca1/EIPS/eip-2537.md): BLS12-381 precompiles - - [EIP-2935](https://github.com/ethereum/EIPs/blob/f27ddf2b0af7e862a967ee38ceeaa7d980786ca1/EIPS/eip-2935.md): Block hashes contract predeploy - - [EIP-7623](https://github.com/ethereum/EIPs/blob/f27ddf2b0af7e862a967ee38ceeaa7d980786ca1/EIPS/eip-7623.md): Increase calldata cost - -- **L2 Withdrawals Root in Block Header**: This lowers the lift for chain operators by allowing them to run a full node to operate op-dispute-mon, making it easier to guarantee the security of the fault proofs for the chains in the Superchain as the number of chains scales. Learn more about this [here](https://gov.optimism.io/t/proposal-preview-l2-withdrawals-root-in-block-header/9730). - -For more information on the Isthmus implementation details, please review [OP's Isthmus specification](https://specs.optimism.io/protocol/isthmus/overview.html). - -Isthmus additionally enables the [Holocene hardfork](https://docs.optimism.io/notices/holocene-changes) with the following changes: - -- **Holocene block derivation**: A set of changes that render the derivation pipeline stricter and simpler, improving worst-case scenarios for the Fault Proof System and Interoperability. -- **EIP-1559 configurability**: The elasticity and denominator EIP-1559 parameters become configurable via the SystemConfig L1 contract, allowing the gas target and gas limit to be configured independently. - -For more information on the Holocene details, please review [OP's Holocene specification](https://specs.optimism.io/protocol/holocene/overview.html). - -## For node operators - -Node operators will need to upgrade to the respective Isthmus releases before the activation dates. - -### Update to the latest release - -The release contains the activation timestamps for Celo Mainnet, Baklava and Alfajores. - -- `op-geth` at [v2.1.0](https://github.com/celo-org/op-geth/releases/tag/celo-v2.1.0) -- `op-node` at [v2.1.0](https://github.com/celo-org/optimism/releases/tag/celo-v2.1.0) - -#### Updating the EigenDA proxy - -The Isthmus hardfork also prepares the Celo networks for the EigenDA v2 update. - -This means that operators need to make sure to upgrade the [EigenDA proxy](https://github.com/Layr-Labs/eigenda/tree/master/api/proxy) to version [v1.8.2](https://github.com/Layr-Labs/eigenda/pkgs/container/eigenda-proxy/437919973?tag=v1.8.2). - -### Verify Your Configuration - -Make the following checks to verify that your node is properly configured. - -- op-node and op-geth will log their configurations at startup -- Check that the Isthmus time is set to `activation-timestamp` in the `op-node` startup logs -- Check that the Isthmus time is set to `activation-timestamp` in the `op-geth` startup logs diff --git a/_deprecated/cel2/notices/l2-migration.mdx b/_deprecated/cel2/notices/l2-migration.mdx deleted file mode 100644 index ad7102106b..0000000000 --- a/_deprecated/cel2/notices/l2-migration.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: "Celo L2 Migration" ---- - - -* Mainnet has been migrated on block **31056500**, March 26, 2025, 3:00 AM UTC. -* The Baklava testnet has been migrated on block **28308600**, February 20, 2025. -* The Alfajores testnet has been migrated on block **26384000**, September 26, 2024. - - -The instructions for migrating a Celo node from Layer 1 to Layer 2 are outlined [in this guide](/cel2/operators/migrate-node). This process is necessary to transition your Celo L1 node to the new Celo L2 architecture based on the OP-Stack. - -If you wish to run a Celo L2 node from scratch, you can follow the instructions in the [Running a Celo Node](/cel2/operators/run-node) guide. diff --git a/_deprecated/cel2/operators/architecture.mdx b/_deprecated/cel2/operators/architecture.mdx deleted file mode 100644 index 2ec14696e4..0000000000 --- a/_deprecated/cel2/operators/architecture.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Node architecture" -sidebarTitle: "Architecture" ---- - -This page reviews node architecture for all nodes running on the Celo network. All L2 Celo nodes are composed of two core software services, the Rollup Node and the Execution Client. Celo also optionally supports a third component, Legacy L1 Celo, that can serve stateful queries for blocks and transactions created before the L2 Upgrade. - -## Rollup node - -The Rollup Node is responsible for deriving L2 block payloads from L1 data and passing those payloads to the Execution Client. The Rollup Node can also optionally participate in a peer-to-peer network to receive blocks directly from the Sequencer before those blocks are submitted to L1. The Rollup Node is largely analogous to a [consensus client](https://ethereum.org/en/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) in Ethereum. - -## Execution client - -The Execution Client is responsible for executing the block payloads it receives from the Rollup Node over JSON-RPC via the standard [Ethereum Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md#engine-api----common-definitions). The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network. The Execution Client is largely analogous to an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) in Ethereum. - -## Next steps - -- To get your node up and running, start with the [operator guide](/cel2/operators/run-node). -- If you've already got a Celo node up and running, check out [how to migrate it to a L2 node](/cel2/operators/migrate-node). diff --git a/_deprecated/cel2/operators/migrate-node.mdx b/_deprecated/cel2/operators/migrate-node.mdx deleted file mode 100644 index 5dd2c818d8..0000000000 --- a/_deprecated/cel2/operators/migrate-node.mdx +++ /dev/null @@ -1,274 +0,0 @@ ---- -title: Migrating a Celo L1 Node -sidebarTitle: "Migrating an L1 Node" ---- - - -Unless you need to migrate your own Celo L1 data, we recommend using a snapshot instead. -You can find the latest snapshot in the [Network Config & Assets](/cel2/operators/run-node#network-config--assets) section. - - -This guide helps Celo L1 node operators migrate their nodes to Celo L2. It describes how to use the [migration tool](https://github.com/celo-org/optimism/tree/celo-rebase-12/op-chain-ops/cmd/celo-migrate) to transform pre-migration database snapshots into a format that Celo L2 nodes can use for a `full` sync. - -**Alternative options:** - -- **Fresh L2 node**: Skip to the [node operator guide](/cel2/operators/run-node) for `snap` sync from scratch -- **Pre-migrated data**: Download migrated datadirs from [Network Config & Assets](/cel2/operators/run-node#network-config--assets) - - -**Terminology** - -The terms L1 and pre-hardfork are used interchangeably to reference Celo before the L2 transition. L1 does not refer to Ethereum in this document. - - -## Migration Overview - -Migrating a pre-hardfork datadir involves these high-level steps: - -1. Upgrade your L1 node to the [latest client release](/cel2/operators/run-node#mainnet-2) so it will stop producing blocks at the hardfork. -2. 1-2 days before the hardfork, stop your node and run a pre-migration to migrate the majority of data. This is not required, but is highly recommended for minimizing downtime. See [Preparing for the L2 migration](/cel2/notices/l2-migration). -3. Restart your node and wait for the hardfork. -4. Shut down your node once the hardfork block number is reached. -5. Run the migration tool to migrate your L1 datadir and produce the hardfork block. -6. Launch your L2 node with the migrated datadir. - -### Important Notes - -- The migration tool can be run multiple times as the L1 chain data grows and will continue migrating from where it last left off. -- While the pre-migration can be run multiple times and will get faster each time, you should avoid running the full migration more than once as it will be slower the second time. -- All migrations writing to a given destination datadir must use the same node's source datadir. That is, you should not run the pre-migration with a db snapshot from node A and then run the full migration with a db snapshot from node B. -- Your node must be stopped before the migration tool is run, even once it has reached the hardfork. -- You should not attempt to migrate archive node data, only full node data. - -## Preparation Steps - -### 1. Upgrade L1 Nodes - -All node operators must upgrade their L1 (`celo-blockchain`) nodes to the required version before the hardfork. This release defines migration block numbers so nodes will stop producing blocks at the right time. - -### 2. Run a Pre-Migration (Recommended) - - -**Archive Node Limitation** - -Both pre-migration and full migration require **full node data only**. If you only have archive nodes, sync a full node before the hardfork. You cannot migrate archive data, even for L2 archive nodes. See [Running an archive node](/cel2/operators/run-node#running-an-archive-node) for details. - - -You can use either Docker or build from source. -The pre-migration may take several hours to complete. - -#### Using Docker (Recommended) - -1. Stop your L1 node -2. Clone the migration repository: - - ```bash - git clone https://github.com/celo-org/celo-l2-node-docker-compose.git - cd celo-l2-node-docker-compose - ``` - -3. Run the pre-migration where `` is `alfajores`, `baklava`, or `mainnet`: - - ```bash - ./migrate pre [] - ``` - - If a destination datadir is specified, ensure that `DATADIR_PATH` inside `.env` is updated to match when you start your node. - -4. Restart your L1 node and wait for the hardfork - -#### Using Source Code - -1. Stop your L1 node -2. Build the migration tool: - - ```bash - git clone https://github.com/celo-org/optimism.git - cd optimism/op-chain-ops - make celo-migrate - ``` - -3. Run the pre-migration: - - ```bash - go run ./cmd/celo-migrate pre \ - --old-db /celo/chaindata \ - --new-db /geth/chaindata - ``` - -4. Restart your L1 node and wait for the hardfork - -### Key Information - -#### Alfajores testnet - -- Block number: `26384000` -- Date: September 26, 2024 -- Minimum `celo-blockchain` version: [v1.8.7](https://github.com/celo-org/celo-blockchain/releases/tag/v1.8.7) -- `op-geth`: [celo-v2.0.0-rc4](https://github.com/celo-org/op-geth/releases/tag/celo-v2.0.0-rc4) -- `op-node`: [celo-v2.0.0-rc4](https://github.com/celo-org/optimism/releases/tag/celo-v2.0.0-rc4) - -#### Baklava testnet - -- Block number: `28308600` -- Date: February 20, 2025 -- Minimum `celo-blockchain` version: [v1.8.8](https://github.com/celo-org/celo-blockchain/releases/tag/v1.8.8) -- `op-geth`: [celo-v2.0.0-rc4](https://github.com/celo-org/op-geth/releases/tag/celo-v2.0.0-rc4) -- `op-node`: [celo-v2.0.0-rc4](https://github.com/celo-org/optimism/releases/tag/celo-v2.0.0-rc4) - -#### Mainnet - -- Block number: `31056500` -- Date: March 26, 2025 (3:00 AM UTC) -- Minimum `celo-blockchain` version: [v1.8.9](https://github.com/celo-org/celo-blockchain/releases/tag/v1.8.9) -- `op-geth`: [celo-v2.0.0](https://github.com/celo-org/op-geth/releases/tag/celo-v2.0.0) -- `op-node`: [celo-v2.0.0](https://github.com/celo-org/optimism/releases/tag/celo-v2.0.0) - -## Full Migration Process - -When the hardfork block number is reached, complete the migration using either Docker (recommended) or source code. - -### Hardware Requirements - -- Make sure you have enough storage to accommodate 2x the pre-hardfork chaindata. Chaindata size can vary, so please double check your node. -- We recommend using local storage for the source and destination datadirs. -- 16GB+ RAM recommended - -### Run Migration with Docker - -Once the hardfork block is reached, run the full migration using the same repository: - -1. Stop your L1 node when the hardfork block number is reached - -2. If you haven't already, clone the migration repository: - - ```bash - git clone https://github.com/celo-org/celo-l2-node-docker-compose.git - cd celo-l2-node-docker-compose - ``` - -3. Run the full migration where `` is `alfajores`, `baklava`, or `mainnet`: - - ```bash - ./migrate full [] - ``` - - If a destination datadir is specified, ensure that `DATADIR_PATH` inside `.env` is updated to match when you start your node. - -### Run Migration from Source - -If you prefer not to use Docker, run the migration directly from source: - -1. Stop your L1 node when the hardfork block number is reached - -2. If you haven't already, build the migration tool: - - ```bash - git clone https://github.com/celo-org/optimism.git - cd optimism/op-chain-ops - make celo-migrate - ``` - -3. Run the full migration: - - - - ```bash - go run ./cmd/celo-migrate full \ - --deploy-config \ - --l1-deployments \ - --l1-rpc \ - --l2-allocs \ - --outfile.rollup-config \ - --outfile.genesis \ - --migration-block-number \ - --old-db /celo/chaindata \ - --new-db /geth/chaindata \ - --l1-beacon-rpc= - ``` - - Note the L1-beacon-RPC-URL must support querying historical `finality_checkpoints`. We are using https://ethereum-beacon-api.publicnode.com in [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose). - - You can check support for historical `finality_checkpoints` by retrieving some suitably old finality_checkpoints, for example slot 5000000. - - ```bash - curl https://ethereum-beacon-api.publicnode.com/eth/v1/beacon/states/5000000/finality_checkpoints | jq - ``` - - - - ```bash - go run ./cmd/celo-migrate full \ - --deploy-config \ - --l1-deployments \ - --l1-rpc \ - --l2-allocs \ - --outfile.rollup-config \ - --outfile.genesis \ - --migration-block-number \ - --old-db /celo/chaindata \ - --new-db /geth/chaindata - ``` - - - - You can find the required input artifacts in the [Network config & Assets](/cel2/operators/run-node#network-config--assets) section. - - We recommend using the [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) codebase as an additional reference for running the migration from source. - -The full migration process will take at least 5 minutes to complete for mainnet, assuming most data has been pre-migrated. If no pre-migration was performed, it could take several hours. - -Congrats! Your datadir is now ready to use with a Celo L2 node. See [Running a Celo Node](/cel2/operators/run-node) for instructions on how to start your Celo L2 node. - -## Troubleshooting - -If you encounter difficulties during the migration that are not covered below, please reach out to our team. You can also check the `celo-l2-node-docker-compose` [README](https://github.com/celo-org/celo-l2-node-docker-compose/blob/main/README.md) and the `celo-migrate` [README](https://github.com/celo-org/optimism/blob/celo-rebase-12/op-chain-ops/cmd/celo-migrate/README.md) for more information on how the migration tooling works. - -### Database Error (EOF) - -If you encounter this error during migration: - -```shell -CRIT [03-19|10:38:17.229] error in celo-migrate err="failed to run full migration: failed to get head header: failed to open database at \"/datadir/celo/chaindata\" err: failed to open leveldb: EOF" -``` - -**Solution:** Start up the celo-blockchain client with the same datadir, wait for it to fully load, then shut it down. This repairs inconsistent shutdown states. - -Alternatively, open a console and exit: - -```bash -geth console --datadir -# Wait for console to load, then exit -``` - -It seems that this issue is caused by the celo-blockchain client sometimes shutting down in an inconsistent state, which is repaired upon the next startup. - -### Missing Data / DB Continuity Check Failures - -Both the `pre` and `full` migration commands will first run a script to check whether the source db provided has any gaps in data. This check may fail with an error indicating that data is missing from your source db. - -To resolve this: - -- Try re-running the migration with a different source datadir if available. - - We will post a full pre-hardfork database snapshot in the [Network config & Assets](/cel2/operators/run-node#network-config--assets) section shortly after the hardfork, but we recommend having your own backup datadir available as well. -- Ensure the datadir is fully synced to just before the hardfork block. - -To check if a db has gaps, you can simply re-run the migration command which will automatically perform the check each time. - -If needed, you can also run the `check-db` script on its own as follows. - -1. Check out and build the latest version of the script in [celo optimism monorepo](https://github.com/celo-org/optimism). - - ```bash - git clone https://github.com/celo-org/optimism - cd optimism/op-chain-ops - make celo-migrate - ``` - -2. Run the script - - ```bash - go run ./cmd/celo-migrate check-db --db-path [--fail-fast] - ``` - - This command takes in an optional `--fail-fast` flag that will make it exit at the first gap detected like it does when run via [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose). If the `--fail-fast` flag is not provided then the script will collect all the gaps it finds and print them out at the end. diff --git a/_deprecated/cel2/operators/overview.mdx b/_deprecated/cel2/operators/overview.mdx deleted file mode 100644 index 42a8a3280a..0000000000 --- a/_deprecated/cel2/operators/overview.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "Node operators & Validators" -sidebarTitle: "Node operators" ---- - -While most applications should remain unaffected, node operators, validators, and RPC providers must ensure their systems are prepared for the transition to maintain seamless operations. - -See the following document for more details: - -* [Celo L2 migration](/cel2/notices/l2-migration) - -See the guides for [running a node](/cel2/operators/run-node) or the guide on [how to migrate a L1 node](/cel2/operators/migrate-node). diff --git a/_deprecated/cel2/operators/run-node.mdx b/_deprecated/cel2/operators/run-node.mdx deleted file mode 100644 index 1dadb4418e..0000000000 --- a/_deprecated/cel2/operators/run-node.mdx +++ /dev/null @@ -1,421 +0,0 @@ ---- -title: "Running a Celo Node" ---- - -This guide is designed to help node operators run a Celo L2 node. - - -**L1 to L2 data migration** - -If you wish to migrate data from a Celo L1 node and have not yet done so, please see the [migration guide](/cel2/operators/migrate-node) before continuing. Alternatively, you can `snap` sync from scratch without migrating existing L1 data. - - -## Recommended Hardware - -### Mainnet - -- 16GB+ RAM -- 1TB+ SSD (NVME Recommended) -- Minimum 4 CPU, recommended 8 CPU -- 100mb/s+ Download - -### Testnets (Alfajores, Baklava, and Celo Sepolia) - -- 16GB+ RAM -- 500GB SSD (NVME Recommended) -- Minimum 4 CPU, recommended 8 CPU -- 100mb/s+ Download - - -**Storage Requirements** - -Storage size requirements will increase over time, especially for archive nodes. - -If running an archive node, please make sure you also have enough storage for the legacy Celo L1 archive datadir. See [Running an archive node](#running-an-archive-node). - - -## Run Node with Docker - -To simplify running nodes, Celo has created the [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repository with all the necessary configuration files and docker compose templates to make running a Celo L2 node easy. - -See the [README](https://github.com/celo-org/celo-l2-node-docker-compose/blob/main/README.md) for instructions on installing docker and docker compose if needed. - - -**Docker Desktop on MacOS** - -You will most likely need to increase the virtual disk limit in order to accommodate the chaindata directory. This can be done by opening Docker Desktop, going to Settings -> Resources -> Advanced and increasing the disk image size. - - -### Running a Full Node - -Follow these steps to run a full node. If you would like to run an archive node, see [below](#running-an-archive-node). - -1. Pull the latest version of [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) and `cd` into the root of the project. - - ```bash - git clone https://github.com/celo-org/celo-l2-node-docker-compose.git - cd celo-l2-node-docker-compose - ``` - -2. Configure your `.env` file. - - __Copy default configurations__ - - The [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repo contains a `.env` file for each Celo network (`alfajores`, `baklava`, `celo-sepolia`, and `mainnet`). Start by copying the default configuration for the appropriate network. - - ```bash - export NETWORK= - cp $NETWORK.env .env - ``` - - __Configure sync mode__ - - By default, [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) will start your node with `snap` sync. This allows your node to start without a migrated L1 datadir, as pre-hardfork block data will be automatically downloaded from peers during syncing. This is the easiest way to start an L2 node. - - Alternatively, you can start your node with `full` sync if you have a migrated L1 datadir. For instructions on obtaining a migrated L1 datadir, please see [Migrating an L1 Node](/cel2/operators/migrate-node). - - To use `full` sync, configure `.env` as follows: - - ```text - OP_GETH__SYNCMODE=full - DATADIR_PATH= - ``` - - __Configure node type__ - - Your node will run as a `full` node by default, but can also be configured as an `archive` node if you wish to preserve access to all historical state. Note that `full` has a different meaning here than in the context of syncing. See [Running an archive node](#running-an-archive-node) for more information. - - __Configure P2P for external network access__ - - -**Network Configuration** - - If the following options are not configured correctly, your node will not be discoverable or reachable to other nodes on the network. This is likely to impair your node's ability to stay reliably connected to and synced with the network. - - - - `OP_NODE__P2P_ADVERTISE_IP` - Specifies the public IP to be shared via discovery so that other nodes can connect to your node. If unset op-node other nodes on the network will not be able to discover and connect to your node. - - `PORT__OP_NODE_P2P` - Specifies the port to be shared via discovery so that other nodes can connect to your node. Defaults to 9222. - - `OP_GETH__NAT` - Controls how op-geth determines its public IP that is shared via the discovery mechanism. If the public IP is not correctly configured then other nodes on the network will not be able to discover and connect to your node. The default value of `any` will try to automatically determine the public IP, but the most reliable approach is to explicitly set the public IP using `extip:`. Other acceptable values are `(any|none|upnp|pmp|pmp:|extip:|stun:)`. - - `PORT__OP_GETH_P2P` - Specifies the port to be shared via discovery so that other nodes can connect to your node. Defaults to 30303. - -3. Start the node. - - ```bash - docker-compose up -d --build - ``` - -4. Check the progress of the node as it syncs. - - ```bash - docker-compose logs -n 50 -f op-geth - ``` - - This will display and follow the last 50 lines of logs. In a syncing node, you would expect to see `Syncing beacon headers downloaded=...` where the downloaded number is increasing and later lines such as `"Syncing: chain download in progress","synced":"21.07%"` where the percentage is increasing. Once the percentage reaches 100%, the node should be synced. - -5. Check that node is fully synced. - - Once the node is fully synced, you can validate that it's following the network by fetching the current block number via the RPC API and seeing that it's increasing as expected. - - ```bash - cast block-number --rpc-url http://localhost:9993 - ``` - - Note that until fully synced, the RPC API will return 0 for the head block number. - -### Running an Archive Node - -#### Overview - -To run an L2 archive node, you need to start the L2 execution client in archive mode. This allows the node to accept RPC requests that require archive data for blocks created after the L2 transition. For historical data from before the L2 transition, you can configure your node to forward those requests to a legacy Celo L1 archive node that contains the historical blockchain state. - -#### Instructions - - -**Prerequisites** - -These instructions assume you already have - -1. A migrated full node datadir that has been synced to the migration block. See [Migrating an L1 Node](/cel2/operators/migrate-node) if you do not have this. -2. A non-migrated Celo L1 archive node datadir. Do not attempt to migrate an archive datadir. - -Please ensure neither datadir is being used by a running node before proceeding. - - -1. Pull the latest version of [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) and `cd` into the root of the project. - - ```bash - git clone https://github.com/celo-org/celo-l2-node-docker-compose.git - cd celo-l2-node-docker-compose - ``` - -2. Configure your `.env` file. - - __Copy default configurations__ - - The [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) repo contains a `.env` file for each Celo network (`alfajores`, `baklava`, `celo-sepolia`, and `mainnet`). Start by copying the default configuration for the appropriate network. - - ```bash - export NETWORK= - cp $NETWORK.env .env - ``` - - __Configure sync mode__ - - By default, [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) will start your node with `snap` sync. While `archive` nodes can technically run with `snap` sync, they will only store archive data from the point that `snap` sync completes. This will leave a gap in the archive data after the hardfork, so we recommend running archive nodes with `full` sync and a migrated pre-hardfork datadir. - - To use `full` sync, configure `.env` as follows: - - ```text - OP_GETH__SYNCMODE=full - DATADIR_PATH= - ``` - - __Configure node type__ - - To enable `archive` mode, configure `.env` as follows: - - ```text - NODE_TYPE=archive - ``` - - __Configure Historical RPC Service__ - - To handle RPC requests for pre-hardfork state and execution, an L2 archive node proxies to a legacy archive node or "Historical RPC Service". - There are two ways to configure a Historical RPC Service for your archive node: - - 1. Supply a pre-hardfork archive datadir and let [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) start a legacy archive node. To do this configure `.env` as follows: - - ```text - HISTORICAL_RPC_DATADIR_PATH= - ``` - - When you start your L2 node, a legacy archive node will also start using the pre-hardfork archive datadir. Your L2 node will be configured to use the legacy archive node as its Historical RPC Service. - - 2. Start the legacy archive node yourself and configure `.env` as follows: - - ```text - OP_GETH__HISTORICAL_RPC= - ``` - - This will cause any value you set for `HISTORICAL_RPC_DATADIR_PATH` to be ignored. The tool will not start a legacy archive node when it starts your L2 archive node. - - If you choose to run your own legacy archive node, you should do so with different flags than before the hardfork, as the node will no longer be syncing blocks or communicating with other nodes. To see how we recommend re-starting a legacy archive node as a Historical RPC Service, see [this script](https://github.com/celo-org/celo-l2-node-docker-compose/blob/30ee2c4ec2dacaff10aaba52e59969053c652f05/scripts/start-historical-rpc-node.sh#L19). - - __Configure P2P for external network access__ - - -**Network Configuration** - - If the following options are not configured correctly, your node will not be discoverable or reachable to other nodes on the network. This is likely to impair your node's ability to stay reliably connected to and synced with the network. - - - - `OP_NODE__P2P_ADVERTISE_IP` - Specifies the public IP to be shared via discovery so that other nodes can connect to your node. If unset op-node other nodes on the network will not be able to discover and connect to your node. - - `PORT__OP_NODE_P2P` - Specifies the port to be shared via discovery so that other nodes can connect to your node. Defaults to 9222. - - `OP_GETH__NAT` - Controls how op-geth determines its public IP that is shared via the discovery mechanism. If the public IP is not correctly configured then other nodes on the network will not be able to discover and connect to your node. The default value of `any` will try to automatically determine the public IP, but the most reliable approach is to explicitly set the public IP using `extip:`. Other acceptable values are `(any|none|upnp|pmp|pmp:|extip:|stun:)`. - - `PORT__OP_GETH_P2P` - Specifies the port to be shared via discovery so that other nodes can connect to your node. Defaults to 30303. - -3. Start the node(s). - - ```bash - docker-compose up -d --build - ``` - -4. Check the progress of your L2 archive node as it syncs. - - ```bash - docker-compose logs -n 50 -f op-geth - ``` - - This will display and follow the last 50 lines of logs. In a syncing node, you would expect to see `Syncing beacon headers downloaded=...` where the downloaded number is increasing and later lines such as `"Syncing: chain download in progress","synced":"21.07%"` where the percentage is increasing. Once the percentage reaches 100%, the node should be synced. - -5. Check that node is fully synced. - - Once the node is fully synced, you can validate that it's following the network by fetching the current block number via the RPC API and seeing that it's increasing as expected. - - ```bash - cast block-number --rpc-url http://localhost:9993 - ``` - - Note that until fully synced, the RPC API will return 0 for the head block number. - -6. Try querying historical state to test archive functionality. - - ```bash - cast balance --block
--rpc-url http://localhost:9993 - ``` - -## Building a Node from Source - -Docker images are the easiest way to run a Celo node, but you can always build your own node from source code. You might wish to do this if you want to run on a specific architecture or inspect the source code. - -The [celo-l2-node-docker-compose](https://github.com/celo-org/celo-l2-node-docker-compose) codebase is still the best reference for how to run your nodes from source, and below you can find all the [Network config & Assets](#network-config--assets) needed to participate in the hardfork. - -## Network Config & Assets - -### Mainnet - -- [Full migrated chaindata](https://storage.googleapis.com/cel2-rollup-files/celo/celo-mainnet-migrated-chaindata.tar.zst) -- [Rollup deploy config](https://storage.googleapis.com/cel2-rollup-files/celo/config.json) -- [L1 contract addresses](https://storage.googleapis.com/cel2-rollup-files/celo/deployment-l1.json) -- [L2 allocs](https://storage.googleapis.com/cel2-rollup-files/celo/l2-allocs.json) -- [rollup.json](https://storage.googleapis.com/cel2-rollup-files/celo/rollup.json) -- [Genesis](https://storage.googleapis.com/cel2-rollup-files/celo/genesis.json) used for snap syncing -- P2P peers - - op-geth bootnode/peers, to be used with op-geth `--bootnodes` flag: - - ```text - enode://28f4fcb7f38c1b012087f7aef25dcb0a1257ccf1cdc4caa88584dc25416129069b514908c8cead5d0105cb0041dd65cd4ee185ae0d379a586fb07b1447e9de38@34.169.39.223:30303 - enode://a9077c3e030206954c5c7f22cc16a32cb5013112aa8985e3575fadda7884a508384e1e63c077b7d9fcb4a15c716465d8585567f047c564ada2e823145591e444@34.169.212.31:30303 - enode://029b007a7a56acbaa8ea50ec62cda279484bf3843fae1646f690566f784aca50e7d732a9a0530f0541e5ed82ba9bf2a4e21b9021559c5b8b527b91c9c7a38579@34.82.139.199:30303 - enode://f3c96b73a5772c5efb48d5a33bf193e58080d826ba7f03e9d5bdef20c0634a4f83475add92ab6313b7a24aa4f729689efb36f5093e5d527bb25e823f8a377224@34.82.84.247:30303 - enode://daa5ad65d16bcb0967cf478d9f20544bf1b6de617634e452dff7b947279f41f408b548261d62483f2034d237f61cbcf92a83fc992dbae884156f28ce68533205@34.168.45.168:30303 - enode://c79d596d77268387e599695d23e941c14c220745052ea6642a71ef7df31a13874cb7f2ce2ecf5a8a458cfc9b5d9219ce3e8bc6e5c279656177579605a5533c4f@35.247.32.229:30303 - enode://4151336075dd08eb6c75bfd63855e8a4bd6fd0f91ae4a81b14930f2671e16aee55495c139380c16e1094a49691875e69e40a3a5e2b4960c7859e7eb5745f9387@35.205.149.224:30303 - enode://ab999db751265c714b171344de1972ed74348162de465a0444f56e50b8cfd048725b213ba1fe48c15e3dfb0638e685ea9a21b8447a54eb2962c6768f43018e5c@34.79.3.199:30303 - enode://9d86d92fb38a429330546fe1aefce264e1f55c5d40249b63153e7df744005fa3c1e2da295e307041fd30ab1c618715f362c932c28715bc20bed7ae4fc76dea81@34.77.144.164:30303 - enode://c82c31f21dd5bbb8dc35686ff67a4353382b4017c9ec7660a383ccb5b8e3b04c6d7aefe71203e550382f6f892795728570f8190afd885efcb7b78fa398608699@34.76.202.74:30303 - enode://3bad5f57ad8de6541f02e36d806b87e7e9ca6d533c956e89a56b3054ae85d608784f2cd948dc685f7d6bbd5a2f6dd1a23cc03e529ea370dd72d880864a2af6a3@104.199.93.87:30303 - enode://1decf3b8b9a0d0b8332d15218f3bf0ceb9606b0efe18f352c51effc14bbf1f4f3f46711e1d460230cb361302ceaad2be48b5b187ad946e50d729b34e463268d2@35.240.26.148:30303 - ``` - - - op-node bootnodes, to be used with op-node `--p2p.bootnodes` flag: - - ```text - enr:-J64QJipvmFhMq6DVh6RR4HvIiiBtyy1NUg_QlnAAbf18SMqCxCPZtLgUiWED5p0HRVPv69Wth4YPsvdKXSUyh57mWuGAZXRp6HjgmlkgnY0gmlwhCJTtG-Hb3BzdGFja4TsyQIAiXNlY3AyNTZrMaECKPT8t_OMGwEgh_eu8l3LChJXzPHNxMqohYTcJUFhKQaDdGNwgiQGg3VkcIIkBg - enr:-J64QCxBGS49IQbkbwsUuVWt9CkMctMCRe0b-4dqRsLr4QJ1S52urWPUk2uhBU5uerRGpxWTZZW5FtJC-9gSBHN3cSiGAZXRp4rbgmlkgnY0gmlwhCKph0CHb3BzdGFja4TsyQIAiXNlY3AyNTZrMaECqQd8PgMCBpVMXH8izBajLLUBMRKqiYXjV1-t2niEpQiDdGNwgiQGg3VkcIIkBg - enr:-J64QLG71bmmljNbLFx3qim6zXohKA3jbK_4C4d1cwixI-7VMoBIlnM6kWZVvvdWcbjTQ6QXB1LAO39eZWC4Heztj1-GAZXRpzUGgmlkgnY0gmlwhCKpySSHb3BzdGFja4TsyQIAiXNlY3AyNTZrMaEDApsAenpWrLqo6lDsYs2ieUhL84Q_rhZG9pBWb3hKylCDdGNwgiQGg3VkcIIkBg - enr:-J64QKFU-u1x1gt3WmNP88EDUMQ316ymbzdGy83QjkBDqVSsJBn6-nipuqYQDeHYoLBLVJUMdyAiwxVbbDm14qQSf5qGAZXRppmIgmlkgnY0gmlwhCJTfzOHb3BzdGFja4TsyQIAiXNlY3AyNTZrMaEC88lrc6V3LF77SNWjO_GT5YCA2Ca6fwPp1b3vIMBjSk-DdGNwgiQGg3VkcIIkBg - enr:-J64QIXTVl0Opbdn20TSrkzpIZ4xQ54bERRlTmSeZ05dFLdlSbuRY7yn5tJeTPzsSldTw5V5E0qjEQcsfr20vMjTUDyGAZXRpiWygmlkgnY0gmlwhCPjrx6Hb3BzdGFja4TsyQIAiXNlY3AyNTZrMaED2qWtZdFrywlnz0eNnyBUS_G23mF2NORS3_e5RyefQfSDdGNwgiQGg3VkcIIkBg - enr:-J64QFAsbeR4xRSyVyQOk7bILUCoMjI2EnbZvo4UAK3842HMYw41-UZXdnQJH8lwvzWn7qsY3Vu73NuxzxWKn4XB5wiGAZXRpYPAgmlkgnY0gmlwhCJSxmKHb3BzdGFja4TsyQIAiXNlY3AyNTZrMaEDx51ZbXcmg4flmWldI-lBwUwiB0UFLqZkKnHvffMaE4eDdGNwgiQGg3VkcIIkBg - enr:-J64QFQSrL3mfG-i64T-5DgVE5V9dGKC5A0JrEvD6CRpZvuLK3feg4bPaqFWfqXyNN_6IgY2z1Jkr4Mf2Zx-GdWlWquGAZXQkMdSgmlkgnY0gmlwhCImtd-Hb3BzdGFja4TsyQIAiXNlY3AyNTZrMaEDQVEzYHXdCOtsdb_WOFXopL1v0Pka5KgbFJMPJnHhau6DdGNwgiQGg3VkcIIkBg - enr:-J64QAp3g1m-5uX-_mBXWyo6ZQqAlnRcAt11Xwy0-ZzqaSrDSlg4adyOz6v9flzLgxYkVvXI50nJGs8GjLgT5bwDLtyGAZXQrD69gmlkgnY0gmlwhCJMJgaHb3BzdGFja4TsyQIAiXNlY3AyNTZrMaECq5mdt1EmXHFLFxNE3hly7XQ0gWLeRloERPVuULjP0EiDdGNwgiQGg3VkcIIkBg - enr:-J64QFCZs1ePThNEsRxIIzbfDxYfap1nEyuPPpSUeeWOoPFWOp0zSEPwLEtXhG1eH-ipsB5CgtaVzcXOyT9hKeAeVVaGAZXQkaZ3gmlkgnY0gmlwhCO7ajaHb3BzdGFja4TsyQIAiXNlY3AyNTZrMaEDnYbZL7OKQpMwVG_hrvziZOH1XF1AJJtjFT5990QAX6ODdGNwgiQGg3VkcIIkBg - enr:-J64QJ9LY8m9AjNgujuVT0juX8T6PHKojZEIqd-7_vhBasfiT2xUUJoUfWga_xVJGFECFcN6hPKB4TjihmYFxHXelwOGAZXQkclrgmlkgnY0gmlwhCJMELeHb3BzdGFja4TsyQIAiXNlY3AyNTZrMaEDyCwx8h3Vu7jcNWhv9npDUzgrQBfJ7HZgo4PMtbjjsEyDdGNwgiQGg3VkcIIkBg - enr:-J64QGJFPZzLj2GLFgB4JhTde7rXChMNFERNbzrwYYTG7CY2SCSggFrU3VXczzWBvOoJWdbOMOzPuCI2klknGjruUxeGAZXQkf1LgmlkgnY0gmlwhGjHJzuHb3BzdGFja4TsyQIAiXNlY3AyNTZrMaEDO61fV62N5lQfAuNtgGuH5-nKbVM8lW6JpWswVK6F1giDdGNwgiQGg3VkcIIkBg - enr:-J64QEXleDl25w0qEG__wmDgwnzB0F5zapu00D_jM4qkCbA3WIcLC8rXPm8dcrKdZNBuNXJOtNE6c2_ZDkuQMvIuhjCGAZXQwDjFgmlkgnY0gmlwhCKMdU-Hb3BzdGFja4TsyQIAiXNlY3AyNTZrMaECHezzuLmg0LgzLRUhjzvwzrlgaw7-GPNSxR7_wUu_H0-DdGNwgiQGg3VkcIIkBg - ``` - -- Container images: - - [Celo L1 client](https://us-docker.pkg.dev/celo-org/us.gcr.io/geth-all:1.8.9) - - [op-geth](https://us-west1-docker.pkg.dev/devopsre/celo-blockchain-public/op-geth:celo-v2.1.0) - - [op-node](https://us-west1-docker.pkg.dev/devopsre/celo-blockchain-public/op-node:celo-v2.1.0) - - [eigenda-proxy](https://ghcr.io/layr-labs/eigenda-proxy:v1.8.2) - -### Alfajores - -- [Full migrated chaindata](https://storage.googleapis.com/cel2-rollup-files/alfajores/alfajores-migrated-datadir.tar.zst) -- [Rollup deploy config](https://storage.googleapis.com/cel2-rollup-files/alfajores/config.json) -- [L1 contract addresses](https://storage.googleapis.com/cel2-rollup-files/alfajores/deployment-l1.json) -- [L2 allocs](https://storage.googleapis.com/cel2-rollup-files/alfajores/l2-allocs.json) -- [rollup.json](https://storage.googleapis.com/cel2-rollup-files/alfajores/rollup.json) -- [Genesis](https://storage.googleapis.com/cel2-rollup-files/alfajores/genesis.json) used for snap syncing -- P2P peers: - - op-geth bootnode/peers, to be used with op-geth `--bootnodes` flag: - - ```text - enode://ac0f42fa46f8cc10bd02a103894d71d495537465133e7c442bc02dc76721a5f41761cc2d8c69e7ba1b33e14e28f516436864d3e0836e2dcdaf032387f72447dd@34.83.164.192:30303 - enode://596002969b8b269a4fa34b4709b9600b64201e7d02e2f5f1350affd021b0cbda6ce2b913ebe24f0fb1edcf66b6c730a8a3b02cd940f4de995f73d3b290a0fc92@34.82.177.77:30303 - enode://3619455064ef1ce667171bba1df80cfd4c097f018cf0205aaad496f0d509611b7c40396893d9e490ee390cd098888279e177a4d9bb09c58387bb0a6031d237f1@34.19.90.27:30303 - enode://e3c54db6004a92d4ee87504f073f3234a25759b485274cc224037e3e5ee792f3b482c3f4fffcb764af6e1859a1aea9710b71e1991e32c1dee7f40352124bb182@35.233.249.87:30303 - enode://674410b34fd54c8406a4f945292b96111688d4bab49aecdc34b4f1b346891f4673dcb03ed44c38ab467ef7bec0b20f6031ad88aa1d35ce1333b343d00fa19fb1@34.168.43.76:30303 - ``` - - - op-node static peers, to be used with op-node `--p2p.bootnodes` flag: - - ```text - enr:-J64QOpbyT0wCfa37PO5qirwmbRsdHy_nMy8-Yam8-SaeK4oL6S-5Z0YKE6TphhZWjfux-EfjxedIbqdiXDEd2bRrNiGAZX2gzlHgmlkgnY0gmlwhCPFGTSHb3BzdGFja4Tz3QIAiXNlY3AyNTZrMaEDrA9C-kb4zBC9AqEDiU1x1JVTdGUTPnxEK8Atx2chpfSDdGNwgiQGg3VkcIIkBg - enr:-J64QI8egoBPlV8cBO9xhBK1wg2ZJj3UH_nw9DjA_mfyYNY2ewDNJ88uCKXV5Kmlj15p3OpdbdUiyXBI9OuxU0LEBtmGAZX2gyNbgmlkgnY0gmlwhCJpFgSHb3BzdGFja4Tz3QIAiXNlY3AyNTZrMaECWWAClpuLJppPo0tHCblgC2QgHn0C4vXxNQr_0CGwy9qDdGNwgiQGg3VkcIIkBg - enr:-J64QCnvpKsWBbrZEzJXQYraWh6XpAI4ygdtrjRPxBKsrdPwHOaN2OcN1w7eBdA2vyXEicxseNVpIFQfvB3nKKzSBo2GAZX2gtNGgmlkgnY0gmlwhCJT0aiHb3BzdGFja4Tz3QIAiXNlY3AyNTZrMaEDNhlFUGTvHOZnFxu6HfgM_UwJfwGM8CBaqtSW8NUJYRuDdGNwgiQGg3VkcIIkBg - enr:-J64QLMeHf5MBmx06LfYEVAB2-5BfvChT-uf3_cKiUFwoA8BI6yjQVSGQMe8F-Oqd662lPaa62Aikq-ra9a_J82852iGAZX2grXVgmlkgnY0gmlwhCJT1pWHb3BzdGFja4Tz3QIAiXNlY3AyNTZrMaEC48VNtgBKktTuh1BPBz8yNKJXWbSFJ0zCJAN-Pl7nkvODdGNwgiQGg3VkcIIkBg - enr:-J64QH2pBtdN_th8TLGEEMjmz5lMsU7nxcY2hpRGUtbPb7McP4VD089C72g0Ms8eztJzf5u3S-3ooH9S3Q0Qj1BYnbKGAZX2gn8tgmlkgnY0gmlwhCKpBTSHb3BzdGFja4Tz3QIAiXNlY3AyNTZrMaEDZ0QQs0_VTIQGpPlFKSuWERaI1Lq0muzcNLTxs0aJH0aDdGNwgiQGg3VkcIIkBg - ``` - -- Container images: - - [Celo L1 client](https://us-docker.pkg.dev/celo-org/us.gcr.io/geth-all:1.8.7) - - [op-geth](https://us-west1-docker.pkg.dev/devopsre/celo-blockchain-public/op-geth:celo-v2.1.0-rc2) - - [op-node](https://us-west1-docker.pkg.dev/devopsre/celo-blockchain-public/op-node:celo-v2.1.0-rc) - - [eigenda-proxy](https://ghcr.io/layr-labs/eigenda-proxy:v1.8.2) - -### Baklava - -- [Final Celo L1 chaindata](https://storage.googleapis.com/cel2-rollup-files/baklava/baklava-l1-final.tar.zst) -- [Full migrated chaindata](https://storage.googleapis.com/cel2-rollup-files/baklava/baklava-migrated-datadir.tar.zst) -- [Rollup deploy config](https://storage.googleapis.com/cel2-rollup-files/baklava/config.json) -- [L1 contract addresses](https://storage.googleapis.com/cel2-rollup-files/baklava/deployment-l1.json) -- [L2 allocs](https://storage.googleapis.com/cel2-rollup-files/baklava/l2-allocs.json) -- [rollup.json](https://storage.googleapis.com/cel2-rollup-files/baklava/rollup.json) -- [Genesis](https://storage.googleapis.com/cel2-rollup-files/baklava/genesis.json) used for snap syncing -- P2P peers: - - op-geth bootnode/peers, to be used with op-geth `--bootnodes` flag: - - ```text - enode://6017c373a4151250e166ee7205b78cf845caff6a2003b3be38af8a09a569e413e31b21667d38a065f747a3662aec4920f122ad1bf1d46605cacf2d3d19f0ff5b@34.19.52.198:30303 - enode://e0ab5ed2071b0ea0d57a52e3cd3da7c97db1a0754e00e91a32a1ca9dab6bf040fa1dd8775e8d6812a557d75760b1b90d18a8d69cbf8cfc2b7acdacf0b47fce96@34.168.70.112:30303 - enode://b6d21edf251da32ffc1527092045ad3beba435f8ba27373dba8ce35f3ee54a411dc8327b57ebce9dc5c53e29825ea9e62356289a849fc4a048cce64da771aed8@34.82.194.102:30303 - enode://339acdcbc3961b11f5458bab3c931e1bbb41548d9cea7692311db1543deac1f4a9efc1e6cff93f745865988d16bdc6bbb38cd59a8dde71bafd236eec0d5e0fea@34.82.75.77:30303 - enode://616429f584575f8da463c18e5e2d38ec028b95446bffd607ebf8ac3d2dd3bbe9b859c91efbbbea6cf51ad78fb0d5db178f66ca57e647bd46bfe6692cc06127e9@34.53.24.17:30303 - ``` - - - op-node static peers, to be used with op-node `--p2p.bootnodes` flag: - - ```text - enr:-J64QKvLBbIvoGzKERuQQuFGDttUj_Yww7s0JBR6BGvI6utnGIHyUuHX87XEbHBDUk71XhkKb3N_kpFlrbOljK8yqO2GAZXyJxGRgmlkgnY0gmlwhCJpeVSHb3BzdGFja4Tw5gMAiXNlY3AyNTZrMaEDYBfDc6QVElDhZu5yBbeM-EXK_2ogA7O-OK-KCaVp5BODdGNwgiQGg3VkcIIkBg - enr:-J64QJIRPy9nuK8uc1s3UnyimNCBp2neviwNseTF70lHBkRYMv6GaioffcV_0s5TRL6JoDdLehW4gtUuy5Y45gETTP-GAZXTuoo-gmlkgnY0gmlwhCPHp8iHb3BzdGFja4Tw5gMAiXNlY3AyNTZrMaEC4Kte0gcbDqDVelLjzT2nyX2xoHVOAOkaMqHKnatr8ECDdGNwgiQGg3VkcIIkBg - enr:-J64QGsGoqQCyPbkzIUG-fxqC6uo1WE7akbchrMTNXVn1KPqUEwq03AlRYzmyyM22WAP69-vZfdMIx1J-A2OL-1t2R-GAZXTurk8gmlkgnY0gmlwhCKRbx6Hb3BzdGFja4Tw5gMAiXNlY3AyNTZrMaECttIe3yUdoy_8FScJIEWtO-ukNfi6Jzc9uozjXz7lSkGDdGNwgiQGg3VkcIIkBg - enr:-J64QHJ0ygyqmw5Tvli7SzMujhP8GxhQ672vF_C-7hcRQudZe5J2SxAton0wMt3C47jyHq2fvaTEh029mzwYQ3jHhCGGAZXTuuivgmlkgnY0gmlwhCPp9oGHb3BzdGFja4Tw5gMAiXNlY3AyNTZrMaECM5rNy8OWGxH1RYurPJMeG7tBVI2c6naSMR2xVD3qwfSDdGNwgiQGg3VkcIIkBg - enr:-J64QPX27ur5gkXOhje9MU7p6AD_C26n-vcBiKq8adst3WkpAyVgo-sWCIAikqDyX-i94hoOYxOOAV1Mx5pIQ5xgHUmGAZXTuxj7gmlkgnY0gmlwhCJ_LRWHb3BzdGFja4Tw5gMAiXNlY3AyNTZrMaEDYWQp9YRXX42kY8GOXi047AKLlURr_9YH6_isPS3Tu-mDdGNwgiQGg3VkcIIkBg - ``` - -- Container images: - - [Celo L1 client](https://us-docker.pkg.dev/celo-org/us.gcr.io/geth-all:1.8.8) - - [op-geth](https://us-west1-docker.pkg.dev/devopsre/celo-blockchain-public/op-geth:celo-v2.1.0-rc2) - - [op-node](https://us-west1-docker.pkg.dev/devopsre/celo-blockchain-public/op-node:celo-v2.1.0-rc) - - [eigenda-proxy](https://ghcr.io/layr-labs/eigenda-proxy:v1.8.2) - -### Celo Sepolia - -- [L1 contract addresses](https://storage.googleapis.com/cel2-rollup-files/celo-sepolia/deployment-l1.json) -- [rollup.json](https://storage.googleapis.com/cel2-rollup-files/celo-sepolia/rollup.json) -- [Genesis](https://storage.googleapis.com/cel2-rollup-files/celo-sepolia/genesis.json) used for snap syncing -- P2P peers: - - op-geth bootnode/peers, to be used with op-geth `--bootnodes` flag: - - ```text - enode://7fd35dfea27042fe008c74ea97c7a41254b293152730419a6e9bcd84bb03c7ced418c1043e2ef6ad63d2facca6fbdacfbf7c4bfcf33ee7e9a0e6b7eb0617595d@34.169.104.197:30303 - enode://151bcf170585971fc78129d9c16af355a1a53e1c825ce1ac20700ea754aa33eda60ca83de6f954bfed8d36c53f33295d93dbc3da9d549d6547d09467806b4b3d@104.199.124.11:30303 - enode://aa5fb766438ac5a0354eb2eec1c0c002b56bb2ce7ed44f0e76e019cbb931222faa9ecfb0fa0055c0c62a2fcf04492d4129349a1045dfef140585250281885e4b@34.83.115.97:30303 - enode://27c81ca466c99016d1595429afc68d66afb3ed9d5a2dd7f6a7797db23a4c826546a177b69b4932f3a75ce374b09d8ccc5b52dad615b3c47dbb8f6217d79ded22@35.247.1.226:30303 - ``` - - - op-node static peers, to be used with op-node `--p2p.bootnodes` flag: - - ```text - enr:-J-4QF7_9Y18cQSQ2wXHD_e65Qy82L1DpfVK4TlOuTDC9oAxeFxmvAn877A2ZXXfc08eLFgZP1mrRjkF4Kts1eGPGbKGAZg2ao5CgmlkgnY0gmlwhCKRF6aHb3BzdGFja4XMiKgFAIlzZWNwMjU2azGhA3_TXf6icEL-AIx06pfHpBJUspMVJzBBmm6bzYS7A8fOg3RjcIIkBoN1ZHCCJAY - enr:-J-4QEbMTKrBfyAeq9hWlEchulzvt1gWA-wAGa_kUdWw1K-faR-AjFNzhcVGG7yDnRb1RptLDGWVpl-WXWhrgJ4TKEaGAZg2XFFugmlkgnY0gmlwhCKotN-Hb3BzdGFja4XMiKgFAIlzZWNwMjU2azGhAxUbzxcFhZcfx4Ep2cFq81WhpT4cglzhrCBwDqdUqjPtg3RjcIIkBoN1ZHCCJAY - enr:-J-4QEawPak_hVU3h1wPZEGu7zLOv1C3k4WI8nHLUc83RqsRMauPtOPt8hYDFyxeJeaUyp0OUM0oyq-_9CEdshE1oWaGAZg2XLgDgmlkgnY0gmlwhCJSX5OHb3BzdGFja4XMiKgFAIlzZWNwMjU2azGhA6pft2ZDisWgNU6y7sHAwAK1a7LOftRPDnbgGcu5MSIvg3RjcIIkBoN1ZHCCJAY - enr:-J-4QCDpfivb0y0Sne1sZOqm1_WOKWWyJ6fo9j93jrxGVm0CcG6tScy3oQAaUuUbh-SmS_cQTO9ciw0_R3q1rpcjGLmGAZg2cWjGgmlkgnY0gmlwhCPFR5uHb3BzdGFja4XMiKgFAIlzZWNwMjU2azGhAifIHKRmyZAW0VlUKa_GjWavs-2dWi3X9qd5fbI6TIJlg3RjcIIkBoN1ZHCCJAY - ``` - -- Container images: - - [op-geth](https://us-west1-docker.pkg.dev/devopsre/celo-blockchain-public/op-geth:celo-v2.1.2) - - [op-node](https://us-west1-docker.pkg.dev/devopsre/celo-blockchain-public/op-node:celo-v2.1.0) - - [eigenda-proxy](https://ghcr.io/layr-labs/eigenda-proxy:v1.8.2) - -## Troubleshooting - -### Transactions Are Not Being Executed When Submitted to a Node - -If your node is synced but transactions submitted to it are not executed, make sure the `--rollup.sequencerhttp` flag is correctly set. - -- Mainnet: `--rollup.sequencerhttp=https://cel2-sequencer.celo.org/` -- Alfajores: `--rollup.sequencerhttp=https://sequencer.alfajores.celo-testnet.org` -- Baklava: `--rollup.sequencerhttp=https://sequencer.baklava.celo-testnet.org` -- Celo Sepolia: `--rollup.sequencerhttp=https://sequencer.celo-sepolia.celo-testnet.org` - -### Self-Hosted Public RPC Does Not Retrieve Transactions by Hash - -If you are hosting a public RPC node, please make sure the flag `--history.transactions` is set to 0 in op-geth (i.e. `--history.transactions=0`), so all transactions are indexed. Otherwise, transactions will not be retrievable by hash. - -## Getting Help - -Please reach out to our team on [Discord](https://chat.celo.org) in the [#celo-L2-support](https://discord.com/channels/600834479145353243/1286649605798367252) channel if you have any questions. diff --git a/_deprecated/integration/checklist.mdx b/_deprecated/integration/checklist.mdx deleted file mode 100644 index 5acef4a84a..0000000000 --- a/_deprecated/integration/checklist.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: "Checklist" -sidebarTitle: "Checklist" -og:description: Checklist for applications building and integrating on Celo. ---- - -Checklist for applications building and integrating on Celo. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## General - -### Addresses - -Addresses are identical to Ethereum addresses. When displaying and asking for user-inputted addresses, consider using and validating address checksums following the [EIP55 standard](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-55.md) to detect typos. - -For core smart contracts, developers are highly encouraged to use the Registry to reference the contracts in case they will have to be repointed (via Governance) - -### QR Codes - -Celo has [WIP QR code standard CIP16](https://github.com/celo-org/celo-proposals/pull/40) that aims to standardize how applications can ask wallets for transactions to avoid the user having to manually copy/paste addresses and other transaction metadata. - -## Custodian/Exchange - -Please read more under [Custody](/integration/custody), but here is a shortened version: - -### Detect Transfers - -Stable-value currencies, currently cUSD and cEUR, are contracts, `StableToken` and `StableTokenEUR` respectively, that can be accessed via the ERC20 interface. The native asset CELO can be accessed via the `GoldToken` ERC20 interface, or natively, similar to ETH on Ethereum. - -Addresses for those contracts can be found by querying the [registry](/developer/contractkit/contracts-wrappers-registry) or in the [Listing Guide](/integration/listings). - -### Proof of Stake - -Users may want to participate in Celo's Proof of Stake system to help secure the network and earn rewards. - -### Authorized Signers - -Celo's core smart contracts use Celo's `Accounts` abstraction to allow balance-moving keys to be held in cold storage, while other keys can be authorized to vote and be held in warm storage or online. - -### Release Gold - -There is an audited `ReleaseGold` smart contract which allows for the release of CELO over a set schedule through which CELO might be distributed to a user. - -## Wallets - -These suggestions apply to any application that custodies a key and allows users to interact and transfer value on the Celo platform. - -### Key Derivation - -Celo wallets should follow the [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) for deriving private keys from [BIP39 mnemonics](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). Celo's key derivation path is at `m/44'/52752'/0'/0`. The first key typically is the `account key` that wallets should register themselves with and accept balance transfers on. The second key can be derived to be an account's `dataEncryptionKey` to allow other users on Celo to encrypt information to. - -### Identity Protocol - -Celo has a [lightweight identity protocol](/legacy/protocol/identity) that allows users to address each other via their phone number instead of addresses that Celo wallets should implement. Since user privacy is important, Celo wallets should leverage the built-in [Phone Number Privacy protocol](/legacy/protocol/identity/odis-use-case-phone-number-privacy) to protect against large-scale harvesting of user phone numbers. - -### Wallet Address - -When transferring assets to an account, wallets should check the receiving account's `walletAddress` at which they want to receive funds at. Use cases might be smart contract accounts that want different recovery characteristics, but receive funds at a different address. Also, `walletAddresses` of `0x0` should indicate that the account requires a different mechanism to acquire the `walletAddress`. - -### Transaction metadata - -cUSD (aka StableToken) adds an additional method to the ERC20 interface called `transferWithComment` which allows senders to specify an additional comment that Celo wallets should support. Additionally, comments should be encrypted to the `dataEncryptionKey` when applicable. - -## Validator Group Explorers - -[Validator Group Explorers](/what-is-celo/about-celo-l1/validator/validator-explorer) are critical to Celo's Proof of Stake system. Explorers will consider using the following standards to provide a minimum experience across all explorers. - -### Names - -All Celo accounts on `Accounts.sol` can claim any name they want. While explorers should display it, they should also be cognizant of the fraud potential. - -### Identities - -Celo accounts can make claims to existing identities, some of which are verifiable (Domain Names or Keybase profiles). Explorers should consider displaying those identities to reduce the potential for impersonation. - -### Performance indicators - -Validator Groups and their validators can perform their duties differently and explorers should reflect that to allow voters to ensure an optimal validator set. While uptime in the form of block signatures by the validators ultimately affect rewards, explorers should also consider displaying [other metrics](/what-is-celo/about-celo-l1/validator/voting#choosing-a-validator-group) that impact the success of the Celo ecosystem, such as validators' performance in the identity protocol. \ No newline at end of file diff --git a/_deprecated/integration/cloud-hsm.mdx b/_deprecated/integration/cloud-hsm.mdx deleted file mode 100644 index 08df0cd362..0000000000 --- a/_deprecated/integration/cloud-hsm.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: "Using a Cloud HSM" -sidebarTitle: "Cloud HSM" -og:description: How to create a cloud HSM in Azure and connect it to celocli. ---- - -How to create a cloud HSM in Azure and connect it to `celocli`. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Introduction to HSM - -A cloud Hardware Security Module (HSM) provides a good balance between security and accessibility. A cloud HSM can manage a Celo private key and can be used seamlessly with `celocli` and `contractkit`. Similar to a ledger device, a key in an HSM avoids the key from ever being sent over the network or stored on disk since the key can never leave the hardware boundary and all signing is performed within the HSM. To authenticate to the HSM, it's recommended to create a service principal account that has been granted access to sign with the managed keys. A cloud HSM can be a great option for managing vote signer keys, since you may want these keys to be portable but also maintain good security practices. - -## Create an Azure subscription - -If you don't have an Azure subscription already, you can [create a free trial here](https://azure.microsoft.com/free/) that starts with $200 credit. You can [view the pricing for Eliptic Curve Cryptography (ECC) HSM keys here](https://azure.microsoft.com/pricing/details/key-vault/). - -## Deploy your Azure Key Vault - -The Key Vault can store keys, secrets, and certificates. Permission can be specified to perform certain actions across the entire Key Vault (ex. key signing). - -- Search the marketplace for "Key Vault" -- Click Create and fill out the deployment information -- Ensure you select the Premium pricing tier for HSM support -- Enable soft-delete and purge protection to ensure your keys aren't accidentally deleted - -## Create your key - -Next, we'll create the ECDSA key. - -- Navigate to your newly created Key Vault and click on the `Keys` section. -- Click on "Generate/Import" -- Select "EC-HSM" -- Select "SECP256K1" - -You'll see your newly generated key listed in the `Keys` section. - -```bash -# On your local machine -export AZURE_VAULT_NAME= -export AZURE_KEY_NAME= -``` - -## Create a Service Principal - -A Service Principal (SP) is preferred over your personal account so that permission can be heavily restricted. In general, Service Principal accounts should be used for any automation or services that need to access Azure resources. - -Use the [Cloud Shell](https://shell.azure.com/bash) to create the client credentials. - -Create a service principal and configure its access to Azure resources: - -```bash -# In the Cloud Shell -az ad sp create-for-rbac -n --skip-assignment -``` - -The account will be created and will output the account's credentials. - -```bash -{ - "appId": "generated-app-ID", - "displayName": "dummy-app-name", - "name": "http://dummy-app-name", - "password": "random-password", - "tenant": "tenant-ID" -} -``` - -Set these as environment variables so that they can be used by `celocli` or `contractkit`. - -```bash -# On your local machine -export AZURE_CLIENT_ID= -export AZURE_CLIENT_SECRET= -export AZURE_TENANT_ID= -``` - -## Grant your Service Principal access to the key - -In the Cloud Shell or Access Policies pane of the Key Vault, set the [GET, LIST, SIGN] permission for the new account. - -```bash -# In the Cloud Shell -az keyvault set-policy --name --spn $AZURE_CLIENT_ID --key-permissions get list sign -``` - -## Connecting CeloCLI to KeyVault - -Now that your environment variables are set, we just need to let `celocli` know that we want to use this Key Vault signer. We do this by passing in the flag `--useAKV` and `--azureVaultName`. Similar to `--useLedger`, all CLI commands will use the HSM signer when `--useAKV` is specified. - -```bash -# On your local machine -celocli account:list --useAKV --azureVaultName $AZURE_VAULT_NAME -``` - -Your Key Vault address will show up under "Local Addresses". If you'd like to use this key as your vote signer key, you can follow [this guide](/what-is-celo/using-celo/protocol/governance/voting-in-governance) and replace `--useLedger` with `--useAKV --azureVaultName $AZURE_VAULT_NAME`. - -## Connecting ContractKit to KeyVault - -To leverage your HSM keys in `contractkit`, first create an `AzureHSMWallet` object and use it to create a `ContractKit` object with `newKitFromWeb3`. Note that `AzureHSMWallet` expects AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, and AZURE_TENANT_ID environment variables to be specified. - -```js -import { ContractKit, newKitFromWeb3 } from "@celo/contractkit"; -import { AzureHSMWallet } from "@celo/wallet-hsm-azure"; - -const azureVaultName = "AZURE-VAULT-NAME"; -const akvWallet = await new AzureHSMWallet(azureVaultName); -await akvWallet.init(); -console.log(`Found addresses: ${await akvWallet.getAccounts()}`); -const contractKit = newKitFromWeb3(this.web3, akvWallet); -``` - -## Summary - -You can now leverage a cloud HSM key to perform signing as a user or application. This improves both security and availability of your Celo keys. We also recommend enabling two-factor authentication across your Azure subscription and to leverage [Managed Service Identities](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) where possible. \ No newline at end of file diff --git a/_deprecated/integration/custody.mdx b/_deprecated/integration/custody.mdx deleted file mode 100644 index 01d2bcee68..0000000000 --- a/_deprecated/integration/custody.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: "Custody" -sidebarTitle: "Custody" -og:description: Details for custodians, exchanges, and other services that intend to custody Celo assets such as Celo Dollar and CELO on behalf of a user. ---- - -Details for custodians, exchanges, and other services that intend to custody Celo assets such as Celo Dollar and CELO on behalf of a user. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Custody Overview - -Generally speaking, custodying CELO, the native token on the Celo network, requires understanding the various states that CELO can exist in at any time. This is to provide useful services beyond custody such as allowing users to lock up their CELO and vote with it. Many of these "states" are implemented as smart contracts, and involve sending CELO from a user owned account to a contract address. Thus, in order to be able to show a user's true balance, services need to be able to observe every balance changing operation and reconcile CELO balances from all the various contracts and states CELO can be in. - -## Balance Model - -As a fork of Ethereum, Celo retains the account model to keep track of users' balances. Celo Dollar and CELO implement the [ERC20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) interface. As mentioned previously, it is common for smart contracts to hold balances on behalf of other addresses. One example is the [`LockedGold`](/what-is-celo/about-celo-l1/protocol/pos/locked-gold) smart contract that holds the "locked portion of a user's `CELO` balance". Another one is the [`ReleaseGold`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol) smart contract that holds `CELO` that is being released to a beneficiary address over time according to some schedule. - - -Celo assets assets exist on an independent blockchain, and although they implement the ERC20 interface, they cannot be accessed through wallets that connect to the Ethereum network. Wallets and other integrations must connect to the Celo network to transfer tokens on Celo. - - -Applications that display balances may need to be written to be aware of this possibility. - -## Transfers - -CELO and Celo Dollars implement the ERC20 interface, as will any future core stable Celo currencies. CELO, as the native currency of the network, can also be transferred by specifying the value field of a transaction, in the same way that ETH can be transferred in Ethereum. Therefore, for CELO, application developers should be aware that transactions can be specified in both ways. - -## CELO State Machine - -CELO as described previously can also exist in various states that represent a specific user behavior. For example, if a user wants to lock CELO to either participate in consensus directly or vote, that CELO will be sent to the `LockedGold` smart contract. To understand the high level flow, please read [this description of the various states CELO can exist in](/what-is-celo/about-celo-l1/protocol/pos/locked-gold#locking-and-voting-flow). - -## Smart Contracts - -The following smart contracts are helpful to understand in order to map the conceptual states to actual accounts and function calls. - -### Accounts - -[Accounts.sol](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/Accounts.sol) allows the mapping of an address to an account in storage, after which all further functionality (locking, voting, etc.) can be accessed. - -The [`createAccount`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/Accounts.sol#L103) function indexes the address as an account in storage, and is required to differentiate an arbitrary key-pair from a user-owned account in the Celo network. - -The `Accounts` contract also allows for the authorization of various signer keys, such as a [vote signer key](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/Accounts.sol#L175). This allows for the user who owns the primary account key to authorize a separate key that can only vote on behalf of the account. This allows for the ability to custody keys in a manner corresponding to their exposure or "warmth". Eg. the primary account private key can be kept in cold storage after authorizing the signer keys, which can be in warmer environments, and potentially more exposed to the network. See the [key management guide](/what-is-celo/about-celo-l1/validator/key-management/detailed) for more details. - -### LockedGold - -[LockedGold.sol](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/LockedGold.sol), which references Celo Gold, the deprecated name for the native token, is used as part of Celo's [proof-of-stake](/what-is-celo/about-celo-l1/protocol/pos/) mechanism. Users can lock CELO by sending it to the `LockedGold` contract after creating an account via the `Accounts` contract as described above. This allows users to vote in validator elections, receive epoch rewards, and participate in on-chain governance. - -There are two ways in which users can vote: - -- Directly, by sending voting transactions with the same key used to lock up CELO -- Via an authorized vote signer, which can submit voting transactions on behalf of the account with locked CELO - -`LockedGold` has a mapping of addresses to `balances` which is a [type](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/LockedGold.sol#L26) that contains both the `nonvoting` amount of CELO as well as `pendingWithdrawals`, which contain values corresponding to timestamps at which they can be withdrawn. The reason for the latter is because all locked CELO has an unlocking period that is [set at time of contract initialization](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/LockedGold.sol#L78), which is 3 days in the Celo network's deployed `LockedGold` contract. Hence, if users unlock CELO in tranches, multiple pending withdrawals could exist at once. Once the timestamp has eclipsed, CELO can be [withdrawn back to the user's address](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/LockedGold.sol#L193). - -### Election - -Once CELO has been locked via `LockedGold`, it can then be used to vote for validator groups. [Election.sol](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/Election.sol) is the contract that manages this functionality. - -The `votes` in this contract are tracked by a [Votes type](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/Election.sol#L87) which has `pending`, `active`, and `total` votes. Pending votes are those that have been cast for a validator group, and active votes are those that have been activated after an epoch, meaning that these votes generate voter rewards. - -Votes are cast for a validator group using the [`vote` function](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/Election.sol#L229). This increments the `pending` and `total` votes in the `Election` contract, and decrements the equivalent amount of CELO from the `nonvoting` balance in the `LockedGold` contract, for the associated account. - -The [`activate` function](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/Election.sol#L263) can then be called to shift `pending` votes into `active` votes in a following epoch. Votes in either state can then be revoked, which decrements votes from the `Election` contract and returns them to the `LockedGold` balance for the associated account. Users can revoke votes at any time and this takes effect instantly. - -### ReleaseGold - -A common problem in other proof-of-stake protocols is the tension between wanting early token holders' balances to release over time to ensure long-term alignment, while also wanting them to be able to participate in consensus to increase the security of the network. To bridge both goals, many early token balances in the Celo network are released via the [`ReleaseGold`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol) contract. Beneficiaries of these contracts can then participate in the proof-of-stake system by staking and voting with CELO that has not yet been "released" for transfers. Please find more high level information about the `ReleaseGold` contract [here](/what-is-celo/using-celo/manage/release-gold). - -From a technical perspective, `ReleaseGold` can be thought of as a "puppet" account controlled by the "puppeteer", or the beneficiary private key corresponding to the `beneficiary` address in the contract. This beneficiary key can then authorize validator signer and vote signer keys that can then call respective functions associated with validating or voting. Most of the required function calls described above can be made by the signer keys directly to the `LockedGold` or `Election` contracts associated with the `ReleaseGold` account. However, some functions in the `ReleaseGold` contract are proxied to the underlying `LockedGold` or `Election` contracts, and have a separate function signature that can be called by the `beneficiary` address. Notably: - -- [`createAccount`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol#L669) -- [`authorizeVoteSigner`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol#L525) and similar functions for other signer keys -- [`lockGold`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol#L469) and [`unlockGold`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol#L477) - -Notice that all these functions have corresponding functions that are called on the underlying contract. The `ReleaseGold` contract can then just be thought of as brokering the transaction to the correct place, when necessary. - -## Other Balance Changing Operations - -In addition to transfers (both native and ERC-20) and locking / voting flows affecting user balances, there are also several additional Celo network features that may cause user balances to change: - -- Gas fee payments: the fee paid by transaction senders to use the network -- Epoch rewards distribution: reward payments to voters, validators, and validator groups - -Some of these may occur as events rather than transactions on the network, and therefore when updating balances, special attention should be paid to them. - -## Useful Tools - -Since monitoring balance changing operations is important to be able to display user balances properly, it can be helpful to use a tracing or reconciling system. [Celo Rosetta](https://github.com/celo-org/rosetta) is an RPC server that exposes an API to query the Celo blockchain, obtain balance changing operations, and construct airgapped transactions. With a special focus on getting balance change operations, Celo Rosetta provides an easy way to obtain changes that are not easily queryable using the celo-blockchain RPC. \ No newline at end of file diff --git a/_deprecated/integration/general.mdx b/_deprecated/integration/general.mdx deleted file mode 100644 index aeaae52117..0000000000 --- a/_deprecated/integration/general.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: "General" -sidebarTitle: "General" -og:description: General information about integrations regardless of your service or use case. ---- - -General information about integrations regardless of your service or use case. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Accessing the chain - -There are a myriad of ways through which you can access chain data: - -### Running your own node - -To be completely independent and have a reliable view into the latest chain data, you will likely want to run your own node(s). - -You can just clone [`celo-blockchain`](https://github.com/celo-org/celo-blockchain) and then run `make geth` to receive the binary. - -By default, `geth` will use `/root/.celo` as the data dir, if you would like to change that specify the `--datadir` argument. - -This is all you should need to connect to a network: - -For Mainnet: - -```bash -geth -``` - -For Alfajores: - -```bash -geth --alfajores -``` - -For Baklava: - -```bash -geth --baklava -``` - -For more command line options, please see [https://geth.ethereum.org/docs/fundamentals/command-line-options](https://geth.ethereum.org/docs/fundamentals/command-line-options) - -### Forno - -Forno is a hosted node service for interacting with the Celo network. This allow the user to get connected to the Celo Blockchain without having to run its own node. - -Can be used as an `Http Provider` with `ContractKit` - -As Forno is a public node you will have to sign transactions locally because with your own private key, because Forno doesn't store them. But don't worry, the `ContractKit` will handle this for you. - -Forno networks: - -``` -Sepolia = 'https://forno.celo-sepolia.celo-testnet.org/' - -Alfajores (deprecated) = 'https://alfajores-forno.celo-testnet.org' - -Baklava (deprecated) = 'https://baklava-forno.celo-testnet.org' - -Mainnet = 'https://forno.celo.org' -``` - -### Blockscout - -We also expose data on the cLabs run blockscout instance. Blockscout itself exposes an API. - -``` -Alfajores = 'https://celo-alfajores.blockscout.com/' - -Baklava = 'https://celo-baklava.blockscout.com/' - -Mainnet = 'https://celo.blockscout.com/' -``` - -## Signing Transactions - -Compared to Ethereum transactions, Celo transactions have an additional optional field: - -- `feeCurrency` - Specifies the address of the currency in which fees should be paid. If `null`, the native token `CELO` is assumed. - - {/* TODO: Fix this link when this part of the docs is done -[Read more about Celo Transactions](/celo-codebase/what-is-celo/about-celo-l1/protocol/transactions) */} - -To sign transactions, you have the following options: - -- Use the JSON-RPC [`sendTransaction`](https://github.com/ethereum/execution-apis/blob/c710097abda52b5a190d831eb8b1eddd3d28c603/tests/eth_sendRawTransaction/send-legacy-transaction.io) method to your node which would have the account in question unlocked. (Either manually or via a library such as `web3`) -- Use [ContractKit's](/developer/contractkit/) local signing feature. \ No newline at end of file diff --git a/_deprecated/integration/index.mdx b/_deprecated/integration/index.mdx deleted file mode 100644 index 0965bebc05..0000000000 --- a/_deprecated/integration/index.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Integrate with Celo -og:description: Collection of resources to help integrate Celo with your service. -sidebarTitle: "Overview" ---- - -## Celo Integrations - -Collection of resources to help integrate Celo with your service. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -Celo provides you with the tools to easily integrate DeFi into your existing mobile application or blockchain service. Integrating with Celo allows you to accept payments, send payouts, and manage all of your DeFi needs using our global financial infrastructure. - -- [General information](/integration/general) -- [Integration Checklist](/integration/checklist) -- [Custody](/integration/custody) -- [Listings](/integration/listings) -- [Using a Cloud HSM](/integration/cloud-hsm) diff --git a/_deprecated/integration/listings.mdx b/_deprecated/integration/listings.mdx deleted file mode 100644 index 3ebe39e2e1..0000000000 --- a/_deprecated/integration/listings.mdx +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: "Listings" -sidebarTitle: "Listing" -og:description: Support for digital asset exchanges or ranking sites that would like to run a Celo node and audit your setup. ---- - -Support for digital asset exchanges or ranking sites that would like to run a Celo node and audit your setup. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Support - -If you have any questions or need assistance with these instructions, please contact cLabs or ask in the #exchanges channel on [Celo’s Discord server](https://chat.celo.org/). Remember that Discord is a public channel: never disclose recovery phrases (also known as backup keys, or mnemonics), private keys, unsanitized log output, or personal information. - -This guide will also help you find all the necessary information about brand assets, how to integrate with Celo and what useful listing information are made available to you as well as any information about looking for support. - -## Celo Brand Assets for Listing - -If you are listing Celo on your exchange, you will probably need access to the Celo Platform brand assets. They can be found [here](https://celo.org/brand-kit). - -Please ensure your use of the Celo Platform assets provided follows the brand policy found [here](https://celo.org/brand-kit-policy). - -## How To's - -### Integrating Celo With Your Infrastructure - -There are several ways to integrate the Celo Platform with your infrastructure. - -A general overview of integrations that would be relevant to you listing Celo Platform are shown [here](/integration/general). - -For more specific use-cases for exchanges, please checkout the [Custody and Exchange Integration Guide](/integration/custody) as well. - -## Important Information - -### Celo Native Asset and Stable Value Currencies - -There are key assets on the Celo network, the Celo native asset (CELO) and Celo-powered Stable Value Currencies, such as Celo Dollar (cUSD) and Celo Euro (cEUR). CELO was formerly called Celo Gold (cGLD) when the contract was deployed, so you will often see references to Celo Gold and CGLD in the codebase. To learn more about the two, please read [this](/tooling/overview/migrate/from-ethereum#the-celo-native-asset-and-the-celo-dollar) section of the docs. - -You can also view the forum post about the name change [here](https://forum.celo.org/t/proposal-to-rename-celo-gold-to-celo-native-asset/528). - -## Resources - -### Address for CELO and Stable Value Currencies - -- CELO (\$CELO) - [`0x471ece3750da237f93b8e339c536989b8978a438`](https://celo.blockscout.com/address/0x471ece3750da237f93b8e339c536989b8978a438/transactions) -- Celo Dollar (\$cUSD) - [`0x765de816845861e75a25fca122bb6898b8b1282a`](https://celo.blockscout.com/address/0x765de816845861e75a25fca122bb6898b8b1282a/transactions) -- Celo Euro (\$cEUR) - [`0xd8763cba276a3738e6de85b4b3bf5fded6d6ca73`](https://celo.blockscout.com/address/0xd8763cba276a3738e6de85b4b3bf5fded6d6ca73/transactions) -- Celo Brazilian Real (\$cREAL) - [`0xe8537a3d056DA446677B9E9d6c5dB704EaAb4787`](https://celo.blockscout.com/address/0xe8537a3d056DA446677B9E9d6c5dB704EaAb4787/transactions) - -### Useful API endpoints - -The following are useful API endpoints available to you that would help you in your listings of the CELO and cUSD digital assets. - -#### CELO and Stable Value Currencies - -##### Total CELO supply - -For querying the API on total coins in circulation in CELO, which are the total amount of coins in existence right now, the following endpoint will provide you with that: - -```sh -$ curl https://thecelo.com/api/v0.1.js?method=ex_totalcoins -{"code":"200","msg":"success","data":{"CELO":608485841.9959723,"cUSD":10250632.56099673}} -``` - -##### Stable Value Currencies - -###### cUSD Circulating Supply - -Circulating Supply refers to the # of coins that are circulating in the market and in the general public's hands. - -```sh -$ curl https://thecelo.com/api/v0.1.js?method=ex_cusd_circulating -11353464.550486518 -``` - -###### cEUR Circulating Supply - -This endpoint is not yet available. - -#### CP-DOTO (Stability Algorithm) - -CP-DOTO information can be found [here](/what-is-celo/about-celo-l1/protocol/stability/doto). - -For API endpoints useful for listing that follow [CMC requirements](https://docs.google.com/document/d/1S4urpzUnO2t7DmS_1dc4EL4tgnnbTObPYXvDeBnukCg/edit#) - -##### Mento Addresses - -- cUSD/CELO contract - [`0x67316300f17f063085Ca8bCa4bd3f7a5a3C66275`](https://celo.blockscout.com/address/0x67316300f17f063085Ca8bCa4bd3f7a5a3C66275/transactions) -- cEUR/CELO contract - [`0xE383394B913d7302c49F794C7d3243c429d53D1d`](https://celo.blockscout.com/address/0xE383394B913d7302c49F794C7d3243c429d53D1d/transactions) -- cREAL/CELO contract - [`0x8f2cf9855C919AFAC8Bd2E7acEc0205ed568a4EA`](https://celo.blockscout.com/address/0x8f2cf9855C919AFAC8Bd2E7acEc0205ed568a4EA/transactions) - -##### Summary - -Summary overview of market data for all tickers and all markets. These endpoints don't yet support cEUR. - -```sh -$ curl https://thecelo.com/api/v0.1.js?method=ex_summary - -{"trading_pairs":"CELO_CUSD","last_price":2.6143,"lowest_ask":2.5933609958506225,"highest_bid":2.5676,"base_volume":37524.32000000003,"quote_volume":14714.520000000002,"price_change_percent_24h":3.7027120070382127,"highest_price_24h":2.649,"lowest_price_24h":2.4787}} -``` - -##### Assets - -In depth details of the assets available on the exchange. - -```sh -$ curl https://thecelo.com/api/v0.1.js?method=ex_assets - -{"code":"200","msg":"success","data":{"CELO":{"name":"CELO","unified_cryptoasset_id":"5567","can_withdraw":"true","can_deposit":"true","min_withdraw":"0.000000000000000001","max_withdraw":"0.000000000000000001","maker_fee":"0.00","taker_fee":"0.005"},"CUSD":{"name":"Celo Dollars","unified_cryptoasset_id":"825","can_withdraw":"true","can_deposit":"true","min_withdraw":"0.000000000000000001","max_withdraw":"0.000000000000000001","maker_fee":"0.00","taker_fee":"0.005"}}} -``` - -##### Ticker - -24-hour rolling window price change statistics. - -```sh -$ curl https://thecelo.com/api/v0.1.js?method=ex_ticker - -{"code":"200","msg":"success","data":{"CELO_CUSD":{"base_id":"5567","quote_id":"825","last_price":2.6124,"quote_volume":14789.520000000002,"base_volume":37720.30000000003,"isFrozen":"0"}}} -``` - -##### Orderbook - -Market depth of a trading pair. One array containing a list of ask prices and another array containing bid prices. - -```sh -$ curl https://thecelo.com/api/v0.1.js?method=ex_orderbook - -{"code":"200","msg":"success","data":{"timestamp":1601061465962,"bids":[["2.5964","100"]],"asks":[["2.622606871230003","100"]]}} -``` - -##### CELO cUSD - -Recently completed (past 24h) trades. - -```sh -$ curl https://thecelo.com/api/v0.1.js?method=ex_celocusd - -{"code":"200","msg":"success","data":{"CELO_CUSD":[{"trade_id":2697341,"timestamp":1601061491,"price":0.38238291620515147,"quote_volume":25,"base_volume":65.37948987916423,"type":"Sell"},{"trade_id":2697336,"timestamp":1601061466,"price":0.382293821845672,"quote_volume":25,"base_volume":65.39472670341044,"type":"Sell"}]}} -``` - -### Whitepapers - -To learn about the Celo Protocol, please refer to the [whitepaper](https://celo.org/papers). - -If you need more information to explore other aspects of the Celo Protocol, there’s a [useful links](/what-is-celo/using-celo/) page. - -To learn more about the Stability Mechanism, you can find it over [here](/what-is-celo/about-celo-l1/protocol/stability/doto). -The [Stability Analysis Whitepaper](https://celo.org/papers/Celo_Stability_Analysis.pdf) and [blog post](https://medium.com/celohq/a-look-at-the-celo-stability-analysis-white-paper-part-1-23edd5ef8b5) will provide a lot more information on the stability algorithm. - -If you want to find more information about the Celo Reserve, a diversified portfolio of cryptocurrencies supporting the ability of the Celo protocol to expand and contract the supply of Celo stable assets, please visit [https://reserve.mento.org/](https://reserve.mento.org/). - -### Github - -The Celo Protocol GitHub is located [here.](https://github.com/celo-org/) - -### Audits - -All the security audits on the smart contracts, security and economics of the Celo Platform can be found [here](https://celo.org/audits). \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/node/run-alfajores.mdx b/_deprecated/what-is-celo/about-celo-l1/node/run-alfajores.mdx deleted file mode 100644 index 69b757de54..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/node/run-alfajores.mdx +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: "Run an Alfajores Full Node" -sidebarTitle: "Alfajores Full Node" -og:description: How to run a full node on the Alfajores Network using a prebuilt Docker image. ---- - -How to run a full node on the Alfajores Network using a prebuilt Docker image. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## What is a Full Node? - -Full nodes play a special purpose in the Celo ecosystem, acting as a bridge between the mobile wallets \(running as light clients\) and the validator nodes. - -## Prerequisites - -- **You have Docker installed.** If you don’t have it already, follow the instructions here: [Get Started with Docker](https://www.docker.com/get-started). It will involve creating or signing in with a Docker account, downloading a desktop app, and then launching the app to be able to use the Docker CLI. If you are running on a Linux server, follow the instructions for your distro [here](https://docs.docker.com/install/#server). You may be required to run Docker with `sudo` depending on your installation environment. - - -The code you'll see on this page is bash commands and their output. - -When you see text in angle brackets <>, replace them and the text inside with your own value of what it refers to. Don't include the <> in the command. - - -## Celo Networks - -First, we are going to setup the environment variables required for `Alfajores` network. Run: - -```bash -export CELO_IMAGE=us.gcr.io/celo-org/geth:alfajores -``` - -## Pull the Celo Docker image - -We're going to use a Docker image containing the Celo node software in this tutorial. - -If you are re-running these instructions, the Celo Docker image may have been updated, and it's important to get the latest version. - -```bash -docker pull $CELO_IMAGE -``` - -## Set up a data directory - -First, create the directory that will store your node's configuration and its copy of the blockchain. This directory can be named anything you'd like, but here's a default you can use. The commands below create a directory and then navigate into it. The rest of the steps assume you are running the commands from inside this directory. - -```bash -mkdir celo-data-dir -cd celo-data-dir -``` - -## Create an account and get its address - -In this step, you'll create an account on the network. If you've already done this and have an account address, you can skip this and move on to configuring your node. - -Run the command to create a new account: - -```bash -docker run -v $PWD:/root/.celo --rm -it $CELO_IMAGE account new -``` - -It will prompt you for a passphrase, ask you to confirm it, and then output your account address: `Public address of the key: ` - -Save this address to an environment variable, so that you can reference it below (don't include the braces): - -```bash -export CELO_ACCOUNT_ADDRESS= -``` - - -This environment variable will only persist while you have this terminal window open. If you want this environment variable to be available in the future, you can add it to your `~/.bash_profile` - - -## Start the node - -This command specifies the settings needed to run the node, and gets it started. - -```bash -docker run --name celo-fullnode -d --restart unless-stopped --stop-timeout 300 -p 127.0.0.1:8545:8545 -p 127.0.0.1:8546:8546 -p 30303:30303 -p 30303:30303/udp -v $PWD:/root/.celo $CELO_IMAGE --verbosity 3 --syncmode full --http --http.addr 0.0.0.0 --http.api eth,net,web3,debug,admin,personal --light.serve 90 --light.maxpeers 1000 --maxpeers 1100 --etherbase $CELO_ACCOUNT_ADDRESS --alfajores --datadir /root/.celo -``` - -You'll start seeing some output. After a few minutes, you should see lines that look like this. This means your node has started syncing with the network and is receiving blocks. - -```text -INFO [07-16|14:04:24.924] Imported new chain segment blocks=139 txs=319 mgas=61.987 elapsed=8.085s mgasps=7.666 number=406 hash=9acf16…4fddc8 age=6h58m44s cache=1.51mB -INFO [07-16|14:04:32.928] Imported new chain segment blocks=303 txs=179 mgas=21.837 elapsed=8.004s mgasps=2.728 number=709 hash=8de06a…77bb92 age=6h33m37s cache=1.77mB -INFO [07-16|14:04:40.918] Imported new chain segment blocks=411 txs=0 mgas=0.000 elapsed=8.023s mgasps=0.000 number=1120 hash=3db22a…9fa95a age=5h59m30s cache=1.92mB -INFO [07-16|14:04:48.941] Imported new chain segment blocks=335 txs=0 mgas=0.000 elapsed=8.023s mgasps=0.000 number=1455 hash=7eb3f8…32ebf0 age=5h31m43s cache=2.09mB -INFO [07-16|14:04:56.944] Imported new chain segment blocks=472 txs=0 mgas=0.000 elapsed=8.003s mgasps=0.000 number=1927 hash=4f1010…1414c1 age=4h52m31s cache=2.34mB -``` - -You will have fully synced with the network once you have pulled the latest block number, which you can lookup by visiting the [Alfajores Block Explorer](https://celo-alfajores.blockscout.com/). - - -**Security**: The command line above includes the parameter `--http.addr 0.0.0.0` which makes the Celo Blockchain software listen for incoming RPC requests on all network adaptors. Exercise extreme caution in doing this when running outside Docker, as it means that any unlocked accounts and their funds may be accessed from other machines on the Internet. In the context of running a Docker container on your local machine, this together with the `docker -p` flags allows you to make RPC calls from outside the container, i.e from your local host, but not from outside your machine. Read more about [Docker Networking](https://docs.docker.com/network/network-tutorial-standalone/#use-user-defined-bridge-networks) here. - - -## Command Line Interface - -Once the full node is running, it can serve the [Command Line Interface](/cli/) tool `celocli`. For example: - -```bash -$ npm install -g @celo/celocli -... -$ celocli node:synced -true -$ celocli account:new -... -``` \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/node/run-baklava.mdx b/_deprecated/what-is-celo/about-celo-l1/node/run-baklava.mdx deleted file mode 100644 index 3cda20f5b8..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/node/run-baklava.mdx +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Run a Baklava Full Node -og:description: How to get a full node running on the Baklava Network using a prebuilt Docker image. -sidebarTitle: "Baklava Full Node" ---- - -How to get a full node running on the Baklava Network using a prebuilt Docker image. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## What is a Baklava Full Node? - -Full nodes play a special purpose in the Celo ecosystem, acting as a bridge between the mobile wallets \(running as light clients\) and the validator nodes. - -## Prerequisites - -- **You have Docker installed.** If you don’t have it already, follow the instructions here: [Get Started with Docker](https://www.docker.com/get-started). It will involve creating or signing in with a Docker account, downloading a desktop app, and then launching the app to be able to use the Docker CLI. If you are running on a Linux server, follow the instructions for your distro [here](https://docs.docker.com/install/#server). You may be required to run Docker with `sudo` depending on your installation environment. - - -Code you'll see on this page is bash commands and their output. - -When you see text in angle brackets <>, replace them and the text inside with your own value of what it refers to. Don't include the <> in the command. - - -## Celo Networks - -First, we are going to setup the environment variables required for `Baklava` network. Run: - -```bash -export CELO_IMAGE=us.gcr.io/celo-org/geth:baklava -``` - -## Pull the Celo Docker image - -We're going to use a Docker image containing the Celo node software in this tutorial. - -If you are re-running these instructions, the Celo Docker image may have been updated, and it's important to get the latest version. - -```bash -docker pull $CELO_IMAGE -``` - -## Set up a data directory - -First, create the directory that will store your node's configuration and its copy of the blockchain. This directory can be named anything you'd like, but here's a default you can use. The commands below create a directory and then navigate into it. The rest of the steps assume you are running the commands from inside this directory. - -```bash -mkdir celo-data-dir -cd celo-data-dir -``` - -## Create an account and get its address - -In this step, you'll create an account on the network. If you've already done this and have an account address, you can skip this and move on to configuring your node. - -Run the command to create a new account: - -```bash -docker run -v $PWD:/root/.celo --rm -it $CELO_IMAGE account new -``` - -It will prompt you for a passphrase, ask you to confirm it, and then output your account address: `Public address of the key: ` - -Save this address to an environment variable, so that you can reference it below (don't include the braces): - -```bash -export CELO_ACCOUNT_ADDRESS= -``` - - -This environment variable will only persist while you have this terminal window open. If you want this environment variable to be available in the future, you can add it to your `~/.bash_profile` - - -## Start the node - -This command specifies the settings needed to run the node and gets it started. - -```bash -docker run --name celo-fullnode -d --restart unless-stopped --stop-timeout 300 -p 127.0.0.1:8545:8545 -p 127.0.0.1:8546:8546 -p 30303:30303 -p 30303:30303/udp -v $PWD:/root/.celo $CELO_IMAGE --verbosity 3 --syncmode full --http --http.addr 0.0.0.0 --http.api eth,net,web3,debug,admin,personal --light.serve 90 --light.maxpeers 1000 --maxpeers 1100 --etherbase $CELO_ACCOUNT_ADDRESS --baklava --datadir /root/.celo -``` - -You'll start seeing some output. After a few minutes, you should see lines that look like this. This means your node has started syncing with the network and is receiving blocks. - -```text -INFO [07-16|14:04:24.924] Imported new chain segment blocks=139 txs=319 mgas=61.987 elapsed=8.085s mgasps=7.666 number=406 hash=9acf16…4fddc8 age=6h58m44s cache=1.51mB -INFO [07-16|14:04:32.928] Imported new chain segment blocks=303 txs=179 mgas=21.837 elapsed=8.004s mgasps=2.728 number=709 hash=8de06a…77bb92 age=6h33m37s cache=1.77mB -INFO [07-16|14:04:40.918] Imported new chain segment blocks=411 txs=0 mgas=0.000 elapsed=8.023s mgasps=0.000 number=1120 hash=3db22a…9fa95a age=5h59m30s cache=1.92mB -INFO [07-16|14:04:48.941] Imported new chain segment blocks=335 txs=0 mgas=0.000 elapsed=8.023s mgasps=0.000 number=1455 hash=7eb3f8…32ebf0 age=5h31m43s cache=2.09mB -INFO [07-16|14:04:56.944] Imported new chain segment blocks=472 txs=0 mgas=0.000 elapsed=8.003s mgasps=0.000 number=1927 hash=4f1010…1414c1 age=4h52m31s cache=2.34mB -``` - -You will have fully synced with the network once you have pulled the latest block number, which you can look up by visiting the [Baklava Block Explorer](https://celo-baklava.blockscout.com/). - - -**Security**: The command line above includes the parameter `--http.addr 0.0.0.0` which makes the Celo Blockchain software listen for incoming RPC requests on all network adaptors. Exercise extreme caution in doing this when running outside Docker, as it means that any unlocked accounts and their funds may be accessed from other machines on the Internet. In the context of running a Docker container on your local machine, this together with the `docker -p` flags allows you to make RPC calls from outside the container, i.e., from your local host, but not from outside your machine. Read more about [Docker Networking](https://docs.docker.com/network/network-tutorial-standalone/#use-user-defined-bridge-networks) here. - - -## Command Line Interface - -Once the full node is running, it can serve the [Command Line Interface](/cli/) tool `celocli`. For example: - -```bash -$ npm install -g @celo/celocli -... -$ celocli node:synced -true -$ celocli account:new -... -``` \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/node/run-mainnet.mdx b/_deprecated/what-is-celo/about-celo-l1/node/run-mainnet.mdx deleted file mode 100644 index 33ec52646d..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/node/run-mainnet.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: "Run a Full Node" -sidebarTitle: "Mainnet Full Node" -og:description: How to run a full node on the Celo Mainnet Network using a prebuilt Docker image. ---- - -How to run on the Mainnet Network using a prebuilt Docker image. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -Full nodes play a special purpose in the Celo ecosystem, acting as a bridge between the mobile wallets \(running as light clients\) and the validator nodes. - -## Prerequisites - -- **You have Docker installed.** If you don’t have it already, follow the instructions here: [Get Started with Docker](https://www.docker.com/get-started). It will involve creating or signing in with a Docker account, downloading a desktop app, and then launching the app to be able to use the Docker CLI. If you are running on a Linux server, follow the instructions for your distro [here](https://docs.docker.com/install/#server). You may be required to run Docker with `sudo` depending on your installation environment. - - -Code you'll see on this page is bash commands and their output. - -When you see text in angle brackets <>, replace them and the text inside with your own value of what it refers to. Don't include the <> in the command. - - -## Celo Networks - -First we are going to setup the environment variables required for the `mainnet` network. Run: - -```bash -export CELO_IMAGE=us.gcr.io/celo-org/geth:mainnet -``` - -## Pull the Celo Docker image - -We're going to use a Docker image containing the Celo node software in this tutorial. - -If you are re-running these instructions, the Celo Docker image may have been updated, and it's important to get the latest version. - -```bash -docker pull $CELO_IMAGE -``` - -## Set up a data directory - -First, create the directory that will store your node's configuration and its copy of the blockchain. This directory can be named anything you'd like, but here's a default you can use. The commands below create a directory and then navigate into it. The rest of the steps assume you are running the commands from inside this directory. - -```bash -mkdir celo-data-dir -cd celo-data-dir -``` - -## Create an account and get its address - -In this step, you'll create an account on the network. If you've already done this and have an account address, you can skip this and move on to configuring your node. - -Run the command to create a new account: - -```bash -docker run -v $PWD:/root/.celo --rm -it $CELO_IMAGE account new -``` - -It will prompt you for a passphrase, ask you to confirm it, and then will output your account address: `Public address of the key: ` - -Save this address to an environment variables, so that you can reference it below (don't include the braces): - -```bash -export CELO_ACCOUNT_ADDRESS= -``` - - -This environment variable will only persist while you have this terminal window open. If you want this environment variable to be available in the future, you can add it to your `~/.bash_profile` - - -## Start the node - -This command specifies the settings needed to run the node, and gets it started. - -```bash -docker run --name celo-fullnode -d --restart unless-stopped --stop-timeout 300 -p 127.0.0.1:8545:8545 -p 127.0.0.1:8546:8546 -p 30303:30303 -p 30303:30303/udp -v $PWD:/root/.celo $CELO_IMAGE --verbosity 3 --syncmode full --http --http.addr 0.0.0.0 --http.api eth,net,web3,debug,admin,personal --light.serve 90 --light.maxpeers 1000 --maxpeers 1100 --etherbase $CELO_ACCOUNT_ADDRESS --datadir /root/.celo -``` - -You'll start seeing some output. After a few minutes, you should see lines that look like this. This means your node has started syncing with the network and is receiving blocks. - -```text -INFO [07-16|14:04:24.924] Imported new chain segment blocks=139 txs=319 mgas=61.987 elapsed=8.085s mgasps=7.666 number=406 hash=9acf16…4fddc8 age=6h58m44s cache=1.51mB -INFO [07-16|14:04:32.928] Imported new chain segment blocks=303 txs=179 mgas=21.837 elapsed=8.004s mgasps=2.728 number=709 hash=8de06a…77bb92 age=6h33m37s cache=1.77mB -INFO [07-16|14:04:40.918] Imported new chain segment blocks=411 txs=0 mgas=0.000 elapsed=8.023s mgasps=0.000 number=1120 hash=3db22a…9fa95a age=5h59m30s cache=1.92mB -INFO [07-16|14:04:48.941] Imported new chain segment blocks=335 txs=0 mgas=0.000 elapsed=8.023s mgasps=0.000 number=1455 hash=7eb3f8…32ebf0 age=5h31m43s cache=2.09mB -INFO [07-16|14:04:56.944] Imported new chain segment blocks=472 txs=0 mgas=0.000 elapsed=8.003s mgasps=0.000 number=1927 hash=4f1010…1414c1 age=4h52m31s cache=2.34mB -``` - -You will have fully synced with the network once you have pulled the latest block number, which you can lookup by visiting the [Block Explorer](https://celo.blockscout.com/). - - -**Security**: The command line above includes the parameter `--http.addr 0.0.0.0` which makes the Celo Blockchain software listen for incoming RPC requests on all network adaptors. Exercise extreme caution in doing this when running outside Docker, as it means that any unlocked accounts and their funds may be accessed from other machines on the Internet. In the context of running a Docker container on your local machine, this together with the `docker -p` flags allows you to make RPC calls from outside the container, i.e from your local host, but not from outside your machine. Read more about [Docker Networking](https://docs.docker.com/network/network-tutorial-standalone/#use-user-defined-bridge-networks) here. - - -## Running an Archive Node - -If you would like to run an archive node for `celo-blockchain`, you can run the following command: - -```bash -docker run --name celo-fullnode -d --restart unless-stopped --stop-timeout 300 -p 127.0.0.1:8545:8545 -p 127.0.0.1:8546:8546 -p 30303:30303 -p 30303:30303/udp -v $PWD:/root/.celo $CELO_IMAGE --verbosity 3 --syncmode full --gcmode archive --txlookuplimit=0 --cache.preimages --http --http.addr 0.0.0.0 --http.api eth,net,web3,debug,admin,personal --light.serve 90 --light.maxpeers 1000 --maxpeers 1100 --etherbase $CELO_ACCOUNT_ADDRESS --datadir /root/.celo -``` - -We add the following flags: `--gcmode archive --txlookuplimit=0 --cache.preimages` - -In `celo-blockchain`, this is called gcmode which refers to the concept of garbage collection. Setting it to archive basically turns it off. - -## Command Line Interface - -Once the full node is running, it can serve the [Command Line Interface](/cli/) tool `celocli`. For example: - -```bash -$ npm install -g @celo/celocli -... -$ celocli node:synced -true -$ celocli account:new -... -``` \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/index.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/index.mdx deleted file mode 100644 index 3ff4e8305a..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/index.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Consensus" -sidebarTitle: "Overview" -og:description: Overview of Celo's consensus protocol and network validators. ---- - -Overview of Celo's consensus protocol and network validators. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Protocol - -Celo’s consensus protocol is based on an implementation called Istanbul, or IBFT. IBFT was developed by AMIS and [proposed](https://github.com/ethereum/EIPs/issues/650) as an extension to [go-ethereum](https://github.com/ethereum/go-ethereum) but never merged. Variants of IBFT exist in both the [Quorum](https://github.com/jpmorganchase/quorum) and [Pantheon](https://github.com/PegaSysEng/pantheon) clients. We’ve modified Istanbul to bring it up to date with the latest [go-ethereum](https://github.com/ethereum/go-ethereum) releases and we’re fixing [correctness and liveness issues](https://arxiv.org/abs/1901.07160) and improving its scalability and security. - -## Finality - -Blocks in IBFT protocol are final, which means that there are no forks and any valid block must be somewhere in the main chain. The only way to revert a block would be to utilise social coordination to get all participants to manually revert the block. - -## Validators - -Celo’s consensus protocol is performed by nodes that are selected as validators. There is a maximum cap on the number of active validators that can be changed by governance proposal, which is currently set at 110 validators. The active validator set is determined via the proof-of-stake process and is updated at the end of each epoch, a fixed period of approximately one day. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/locating-nodes.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/locating-nodes.mdx deleted file mode 100644 index bc7c4b0e69..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/locating-nodes.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Locating Nodes -og:description: How Celo nodes join the network, establish a connection, and communiate their IP address. ---- - -How Celo nodes join the network, establish a connection, and communiate their IP address. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## V4 Discovery Protocol - -All Celo nodes \(including our validators\) are using a variant of Ethereum's V4 discovery protocol to find other nodes within the network. Details of Ethereum's protocol can be found [here](https://github.com/ethereum/devp2p/blob/master/discv4.md). - -## Joining the Network - -When a node attempts to join the network, it will execute Celo's discovery protocol. - -It will first send a request to the bootnodes to retrieve a list of other nodes of the network. The bootnodes will then reply with that list, and then the joining node will then send additional requests to nodes in that list to find additional nodes in the network. The main difference in Celo's discovery protocol compared to Ethereum's is that it will require that the joining node's networkID be the same as the bootnodes' \(and the same as all other network's nodes\). - -Also, all of the messages in Celo's discovery protocol must be hashed with a special salt to be accepted by other nodes. The reason why these changes were made is so that each node within a network will only store information of other nodes that have the same networkID (to distinguish nodes from other networks) and the same special salt \(to distinguish nodes from other blockchains, such as Ethereum\). - -## Establishing a Connection - -Once a joining node finds other nodes, it will establish direct TCP connections to a subset of them. This will allow that node to sync it's blockchain and transactions. Validators will additionally attempt to establish TCP connections to the rest of the validators, so that it can send consensus messages directly to them, instead of via gossip. The reason that the validators do this is to minimize the latency of messages that are sent and received among the validators, and to ultimately help minimize block time. - -## Communicating IP Address - -The way that validators communicate their IP address to other validators is by periodically gossiping a subprotocol message that we call an _IstanbulAnnounce_ message. - -That message will contain `n` copies (where `n` is the total number of validators for the current epoch) of the sending validator's IP address where each copy is encrypted with the other validators' public key. Once a validator receives a gossiped _IstanbulAnnounce_ message, it will decrypt the encrypted IP address that was encrypted with its public key, and then establish a TCP connection to it. All consensus related messages will then sent via those direct TCP connections. - -When an epoch ends, a validator will establish new connections with any newly elected validator and disconnect from any removed validators. If the validator itself is removed from the new epoch's validator set, then it will disconnect with all the validators. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/validator-set-differences.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/validator-set-differences.mdx deleted file mode 100644 index de4a4cbd7b..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/consensus/validator-set-differences.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Validator Set Differences -og:description: How validator sets are elected and managed with the Celo protocol. ---- - -How validator sets are elected and managed with the Celo protocol. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Computing Set Differences - -The validator set for a given epoch is elected at the end of the last block of the previous epoch. The new validator set is written to the **extradata** field of the header for this block. As an optimization, the validator set is encoded as the difference between the new and previous validator sets. Nodes that join the network are able to compute the validator set for the current epoch by starting with the initial validator set \(encoded in the genesis block\) and iteratively applying these diffs. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/contracts/add-contract.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/contracts/add-contract.mdx deleted file mode 100644 index 2029ac236b..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/contracts/add-contract.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Add a contract in celo-monorepo -og:description: How to set up Unit/Migration tests on Celo -sidebarTitle: "Add a Contract" ---- - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - -## Adding a contract in celo-monorepo - -Set up a unit/migration test suit for the contract you just created in celo-monorepo and a short guide to running it successfully on celo test net. We’ll be using `Accounts.sol` as an example. - -## After initial contract creation - -After the contract is created and it’s ready to be tested, run `yarn build` to trigger typechain which is essentially a TS wrapper for the contract. Keep in mind that everytime you change your contract you have to run `yarn build` once again. - -## Unit tests - -The test directory is organized the same way as the contracts directory so feel free to navigate to the parent folder of your currently created contract and create a corresponding(.ts) file for it. For example: `celo-monorepo/packages/protocol/contracts/common/Accounts.sol → celo-monorepo/packages/protocol/test/common/accounts.ts`. - - -Some build issues can be resolved by simply deleting the `build` and the `typechain` folder. Don’t forget to run `yarn build` once again. - diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/encrypted-cloud-backup.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/encrypted-cloud-backup.mdx deleted file mode 100644 index eb3ef18d8a..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/encrypted-cloud-backup.mdx +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: PEAR 🍐 ---- - -Pin/Password Encrypted Account Recovery. - ---- - -Secure and reliable account key backups are critical to the experience of non-custodial wallets, and Celo more generally. -Day-to-day, users store their account keys on their mobile device, but if they lose their phone, they need a way to recover access to their account. -Described in this document is a protocol for encrypted backups of a user's account keys in their cloud storage account. - -## Summary - -Using built-in support for iOS and Android, mobile apps can save data backups to Apple iCloud and Google Drive respectively. -When a user installs the wallet onto a new device, possibly after losing their old device, or reinstalls the app on the same device, it can check the user's Drive or iCloud account for account backup data. -If available, this data can be downloaded and used to initialize the application with the recovered account information. - -Access to the user's cloud storage requires logging in to their Google or Apple account. -This provides a measure of security as only the owner of the cloud storage account can see the data, but is not enough to confidently store the wallet's account key. -In order to provide additional security, the account key backup should be encrypted with a secret, namely a PIN or password, that the user has memorized or stored securely. -This way, the users account key backup is only accessible to someone who can access their cloud storage account _and_ knows their secret. - -Because user-chosen secrets, especially PINs, are susceptible to guessing, this secret must be [hardened]() before it can be used as an encryption key. -Using [ODIS](/legacy/protocol/identity/odis) for [key hardening](/legacy/protocol/identity/odis-use-case-key-hardening), this scheme derives an encryption key for the account key backup that is resistant to guessing attacks. - -With these core components, we can construct an account recovery system that allows users who remember their password or PIN, and maintain access to a cloud storage account, to quickly and reliably recover their account while providing solid security guarantees. - -Valora is currently working to implement encrypted account recovery, using the user's access PIN for encryption. - -### Similar protocols - -- [iCloud Keychain](https://support.apple.com/guide/security/secure-icloud-keychain-recovery-secdeb202947/web) uses 6-digit PIN, hardened by an HSM app, and encrypt iCloud Keychain backups. -- [Signal SVR](https://support.apple.com/guide/security/secure-icloud-keychain-recovery-secdeb202947/web) uses a 4-digit PIN or alphanumeric password, hardened by an Intel SGX app, to encrypt contacts and metadata. -- [Coinbase Wallet](https://blog.coinbase.com/backup-your-private-keys-on-google-drive-and-icloud-with-coinbase-wallet-3c3f3fdc86dc) uses a password encrypted cloud backup to store user account keys. It is unclear if any hardening is used. -- [WhatsApp E2E Encrypted Backups](https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee-backups/) uses [OPAQUE](https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/) to harden a password encrypted backup -- [MixIn Network TIP](https://github.com/MixinNetwork/tip) uses 6-digit PINs, hardened by a set of signers, to derive account keys - -## User experience - -Here we describe the user experience of the protocol as designed. -Wallets may alter this flow to suite the needs of their users. - -### Onboarding - -During onboarding on a supported device, after the PIN or password is set and the account key is created, the user should be informed about the account backup and given a chance opt-out of backup system for their account. -If they opt out, the rest of the setup should be skipped as they will not be using this account recovery system. - -On Android, when the user opts-in, they should be prompted to select a Google account that they would like to use to store the backup. -On iOS, the user need not be prompted as there is a single Apple account on the device and the permissions architecture allows access to application-specific iCloud data without prompting the user. - -In the background, the chosen PIN or password and a locally generated salt value should be used to query ODIS. -The resulting hardened key should be used to encrypt the BIP-39 account key mnemonic. -The encrypted mnemonic and metadata, including the salt, should be stored in the user's cloud storage. - -### Recovery - -During recovery, the application should determine if a backup is available in their cloud account. -On iOS, this can be done automatically. -On Android, the user may choose to restore from a cloud backup, at which point they should be prompted to choose their Google account. - -If a backup is available the user may select to restore from a cloud backup, at which point they should be asked for their PIN or password. -Given the PIN or password, the application should combine it with the salt value and query ODIS to retrieve the hardened key for decrypting the account key backup. -If successful, the user will be sent to the home screen. -If unsuccessful, the user will be given the option to try again or enter their mnemonic phrase instead. - -Users should, by requirement of security, be given a limited number of attempts to enter their PIN or password. -Attempts should be rate limited with a certain number of attempts available immediately (e.g. 3-5 attempts within the first 24 hours), and a limited number of additional attempts available after one or more waiting periods (e.g. up to 10-15 attempts over 3 days). -Once all attempts are exhausted, the backup will become unrecoverable and the user will only be able to recover their account if they have their mnemonic phrase written down. - -## Implementation - -Client support for the encrypted backup protocol described here is implemented in the [`@social-connect/encrypted-backup` package](https://github.com/celo-org/social-connect/tree/main/packages/encrypted-backup). - -Creating a backup file consists of a number of steps to derive the encryption key, and assemble the backup file. - -1. Generate a random nonce and hash it with the password or PIN input to get the initial key. -2. Generate a random fuse key and hash it with the initial key to get an updated key. - Encrypt this fuse key to the public key of the circuit breaker service and discard the plaintext fuse key. -3. Send the key as a blinded message to the ODIS to be hashed under a [password hardening domain](/legacy/protocol/identity/odis-use-case-key-hardening). - Use an authentication key derived from the backup nonce such that only a user with access to the backup can make queries to ODIS. - Hash the response from ODIS together with the key to generate the hardened key. -4. Encrypt the account mnemonic phrase with the hardened encryption key, and assemble it together with the nonce, ODIS domain information, encrypted fuse key, and environment metadata for ODIS and the circuit breaker. - -If the implementing service does not wish to include a circuit breaker, which is described in more detail below, step two can be skipped. - -The backup file created in this protocol can then be stored by the wallet that implements this protocol in some authenticated storage, such as iCloud or Google Drive. - -In order to open the backup and recover the users account mnemonic the encrypted backup file is first retrieved from authenticated storage, then the decryption key is derived in the following steps similar to the steps above. - -1. Hash the password or PIN input with the nonce in the backup to get the initial key. -2. Query the circuit breaker to unwrap the encrypted fuse key and hash it with the initial key to get an updated key. -3. Send the key as a blinded message to the ODIS to be hashed under the included [password hardening domain](/legacy/protocol/identity/odis-use-case-key-hardening). - Use an authentication key derived from the backup nonce. - Hash the response from ODIS together with the key to generate the hardened key. -4. Decrypt the backup data with the hardened decryption key and return it as the account mnemonic. - -### Circuit breaker - -In order to handle the event of an ODIS service compromise, this is protocol includes a recommended circuit breaker service. -A circuit breaker service is essentially an online decryption service with a well-known public key that can be taken offline if needed to prevent access to the decryption key. -By using a fuse key which is decrypted to the circuit breaker service, and therefore can only be accessed if the service is online, as a step to derive the encryption key for the backup, the circuit breaker service operator is able to disable decryption of backup files in case of an emergency to protect user funds. -In particular, if the ODIS key hardening service is discovered to be compromised, the circuit breaker operator will take their service offline, preventing backups using the circuit breaker from being opened. -This ensures that an attacker who has compromised ODIS cannot leverage their attack to forcibly open backups created with this function. - -### PIN Blocklist - -When using a 4 or 6 digit PIN code to encrypt a backup, there are a number of PINs that are far more common than common than others. -Sequences (123456), patterns (124578) and important dates (110989) are chosen most frequently. -Within 30 guesses, an attacker has a 5-9% chance of guessing a users first-choice PIN code, as suggested by [research into PIN security](https://this-pin-can-be-easily-guessed.github.io/). -In order to address this, it is highly recommended to block the most easily guessed PINs. -One way to do this is to block PINs that are most popular. -A suggested implementation, which is [implemented by the Valora wallet](https://github.com/valora-inc/wallet/blob/3940661c40d08e4c5db952bd0abeaabb0030fc7a/packages/mobile/src/pincode/authentication.ts#L56-L108), is to create a blocklist from the top 25k most frequently seen PINs in the HIBP Passwords dataset. diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/index.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/index.mdx deleted file mode 100644 index 9a3b82e6db..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/index.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Identity Overview" -sidebarTitle: "Overview" -og:description: How Celo maps wallet addresses to phone numbers to make financial tools more accessible to mobile phone users. ---- - -How Celo maps wallet addresses to phone numbers to make financial tools more accessible to mobile phone users. - ---- - - -Celo's Identity protocol has moved to [docs.self.xyz](https://docs.self.xyz/). - - -## Introduction to Identity on Celo - -Celo’s unique purpose is to make financial tools accessible to anyone with a mobile phone. One barrier for the usage of many other platforms is their required usage of 30+ hexadecimal-character-long strings as addresses. It’s like bank account numbers, but worse. Hard to remember, easy to mess up. They are so hard to use that the predominant way of exchanging addresses is usually via copy-paste over an existing messaging channel or via QR-codes in person. Both approaches are practically interactive protocols and thus do not cover many use cases in which people would like to transact. Celo offers an optional lightweight identity layer that starts with a decentralized mapping of phone numbers to wallet addresses, allowing users to transact with one another via the most common identity scheme everyone is familiar with: their address book. - - -![](https://storage.googleapis.com/celo-website/docs/attestations-flow.jpg) - - -### Adding their phone number to the mapping - -To allow Bob to find an address mapped to her phone number, Alice can use the decentralized attestations protocol to link an account address to her phone number. Alice starts by making a request to the `Attestations` contract; transferring a fee along with her request. After a brief waiting time of `4` blocks (20 seconds), the `Attestations` contract will use the `Random` contract to produce a random selection of validators, from the current elected set in the `Validators` contract, to issue the attestation challenges. - -As part of the expectation of validators, they run the attestation service whose endpoint they register in their [Metadata](/legacy/protocol/identity/metadata). After attestation issuers have been selected for their requests, Alice determine the validators' attestation service URLs from her [Metadata](/legacy/protocol/identity/metadata) and requests an attestation message to her phone number by sending a direct HTTPS request. In turn, the attestation service produces a signed secret message attesting to the ownership of the given phone number by the requesting account. The validator sends the message to Alice's phone number via SMS. Read more under [attestation service](#attestation-service). - -When Alice receives the text message, she can take that signed message to the `Attestations` contract, which can verify that the attestation came from the validator indeed. Upon a successful attestation, the validator can redeem for the attestation request fee to pay them for the cost of sending the SMS. In the end, we have recorded an attestation by the validator to a mapping of Alice’s phone number to her account address. - -### Using the mapping for payment - -Once Alice has completed attestations for their phone number/address, Bob, who has her phone number in his contact book, can see that Alice has an attested account address with her phone number. He can use that address to send funds to Alice, without her having to specifically communicate her address to Bob. - -The `Attestations` contract records all attestations of a phone number to any number of addresses. That for example could happen when a user loses their private key and wants to map a new wallet address. However, it could also happen through the collusion of a validator with Alice. Therefore, it is important that clients of the identity protocol highlight possible conflicting attestations. - -Some risk exists for attestations to be added without the permission of the "legitimate" owner of the phone number. One such risk is that the phone service provider or [SIM swap](https://wikipedia.org/wiki/SIM_swap_scam) attacker could take control of the phone number and complete a number of attestations. Another risk is that a sufficient number of Attestation Service providers may collude to complete fake attestations. Notably, completing malicious attestations does not lead to a loss of funds, as the private key is still the necessary and sufficient condition for transactions of an account. However, without proper care, future senders may be tricked into sending funds to the newly associated address. In general the number and age of attestations for an address should be taken into account to identify the valid owner of a phone number. - -There are additional measures we can take to further secure the integrity of the mapping’s usage. In the future we plan to provide reference implementations in the wallet for some of these. For example, we plan to detect remapping of wallet addresses. Many users are already accustomed to sending small amounts first and verifying the receipt of those funds before attempting to transfer larger amounts. - -### Preventing harvesting of phone numbers - -To protect user privacy by preventing mass harvesting of phone numbers, the Celo platform includes a service that obfuscates the information saved on the blockchain. The service is enabled by default for all Celo Wallet users. Details of its functionality and architecture are explained in [Phone Number Privacy](/legacy/protocol/identity/odis-use-case-phone-number-privacy) - -### Attestation service - -The attestation service is a simple Node.js service that validators run to send signed messages for attestations. It can be configured with SMS providers, as different providers have different characteristics like reliability, trustworthiness and performance in different regions. The attestation service currently supports [Twilio](https://www.twilio.com) and [Nexmo](https://nexmo.com). Celo should widen the number of supported providers over time. - - - {/* We have been experimenting with a SMS provider that we would like community feedback on. Instead of sending the SMS via conventional providers like Twilio, users of a `Rewards Mobile App` could register themselves with a `Verification Pool` and be made responsible for sending those text messages. It would allow users with cheap or leftover SMS capacity from their cell phone plan to effectively acquire a share of the attestation request fees. It would represent a unique on-ramp for users who do not have access to classic on-ramps like exchanges. Validators could configure their attestation service to use such a SMS provider which could in theory provide better inclusion and performance. */} - -### Future improvements to privacy - -Celo is committed to meet the privacy needs of its users. More details about areas for future research can be found in [Privacy Research](/legacy/protocol/identity/privacy-research) \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/metadata.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/metadata.mdx deleted file mode 100644 index 452a55b4da..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/metadata.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "Metadata and Claims" -sidebarTitle: "Celo Metadata and Claims" -og:description: How the Celo protocol's metadata and claims feature makes it possible to connect on-chain with off-chain identities. ---- - -How the Celo protocol's **metadata and claims** feature makes it possible to connect on-chain with off-chain identities. - ---- - -## Use Cases - -- Tools want to present public metadata supplied by a validator or validator group as part of a list of candidate groups, or a list of current elected validators. -- Governance Explorer UIs may want to present public metadata about the creators of governance proposals -- The Celo Foundation receives notice of a security vulnerability and wants to contact elected validators to facilitate them to make a decision on applying a patch. -- A DApp makes a request to the Celo Wallet for account information or to sign a transaction. The Celo Wallet should provide information about the DApp to allow the user to make a decision whether to sign the transaction or not. - -Furthermore, these tools may want to include user chosen information such as names or profile pictures that would be expensive to store on-chain. For this purpose, the Celo protocol supports **metadata** that allows accounts to make both verifiable as well as non-verifiable claims. The design is described in [CIP3](https://github.com/celo-org/CIPs/pull/4). - -On the `Accounts` smart contract, any account can register a URL under which their metadata file is available. The metadata file contains an unordered list of claims, signed by the account. - -## Types of Claim - -ContractKit currently supports the following types of claim: - -- **Name Claim** - An account can claim a human-readable name. This claim is not verifiable. - -- **Attestation Service URL Claim** - For the [lightweight identity layer](/legacy/protocol/identity), validators can make a claim under which their Attestation Service is reachable to provide attestations. This claim is not verifiable. - -- **Keybase User Claim** - Accounts can make claims on [Keybase](https://keybase.io) usernames. This claim is verifiable by signing a message with the account and hosting it on the publicly accessible path of the Keybase file system. - -- **Domain Claim** - Accounts can make claims on domain names. This claim is verifiable by signing a message with the account and embedding it in a [TXT record](https://wikipedia.org/wiki/TXT_record). - -In the future ContractKit may support other types of claim, including: - -- **X User Claim** - Accounts can make claims on [X](https://x.com/) usernames. This claim is verifiable by signing a message with the account and posting it as a tweet. Any client can verify the claim with a reference to the tweet in the claim. - -## Handling Metadata - -You can interact with metadata files easily through the [CLI](/cli/account), or in your own scripts, tools or DApps via [ContractKit](/developer/contractkit/). Most commands require a node being available under `http://localhost:8545` to make view calls, and to modify metadata files, you'll need the relevant account to be unlocked to sign the files. - -You can create an empty metadata file with: - -```bash -celocli account:create-metadata ./metadata.json --from $ACCOUNT_ADDRESS -``` - -You can add claims with various commands: - -```bash -celocli account:claim-attestation-service-url ./metadata.json --from $ACCOUNT_ADDRESS --url $ATTESTATION_SERVICE_URL -``` - -You can display the claims in your file and their status with: - -```bash -celocli account:show-metadata ./metadata.json -``` - -Once you are satisfied with your claims, you can upload your file to your own web site or a site that will host the file (for example, [https://gist.github.com](https://gist.github.com) and then register it with the `Accounts` smart contract by running: - -```bash -celocli account:register-metadata --url $METADATA_URL --from $ACCOUNT_ADDRESS -``` - -Then, anyone can lookup your claims and verify them by running: - -```bash -celocli account:get-metadata $ACCOUNT_ADDRESS -``` \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-domain-sequential-delay-domain.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-domain-sequential-delay-domain.mdx deleted file mode 100644 index 5ec386d8f3..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-domain-sequential-delay-domain.mdx +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Sequential Delay Domain ---- - - - -The Sequential Delay Domains is an [ODIS Domain](/legacy/protocol/identity/odis-domain) supporting signature-authenticated rate limits defined as a series of time-delayed stages. -The motivating use case is allowing wallets to define how often users can attempt to recover their account via the scheme outlined in [Pin/Password Encrypted Account Recovery](/legacy/protocol/identity/encrypted-cloud-backup), but can be used in any other application that need an authenticated rate limit represented as a series of time delayed stages. - -## Specification - -A full specification of the Sequential Delay Domain is available in an extension to CIP-40. - -- [Sequential Delay Domain Specification](https://github.com/celo-org/celo-proposals/blob/master/CIPs/CIP-0040/sequentialDelayDomain.md) diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-domain.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-domain.mdx deleted file mode 100644 index 0b164e4b79..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-domain.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: ODIS Domains -sidebarTitle: Overview ---- - - - - -Domain API features described here are not deployed to Mainnet ODIS as of April 1, 2022. - - -In order to support use cases such as password hardening, and future applications, ODIS implements Domains. -A Domain instance is structured message sent to ODIS along with the secret blinded message. -Unlike the blinded message, the Domain instance is visible to the ODIS service and allows the client to specify context information about their request. -This context information is used to decide what rate limit and/or authentication should be applied to the request, and is combined into the result to ensure output is unique to the context. -The Domain instance and blinded message are both passed to the ODIS partially oblivious pseudorandom function (POPRF), which is a new construction extending upon the [OPRF function](/legacy/protocol/identity/odis) used in the [phone number privacy service](/legacy/protocol/identity/odis-use-case-phone-number-privacy). - -As an example, a Domain for hashing an account password might specify an application username of "vitalik.eth" (context) and a cap of 10 password attempts (rate-limiting parameter). -These would be combined with the user's password (blinded input) in the POPRF, which acts as a one-way function, to form the final output. -As a result the rate limiting parameters, in this case allowing a total of 10 queries, can be set to arbitrary values but are effectively binding once chosen. -This allows the parameters to be tuned to the needs of the individual user or application and prevents potential overlap of different use cases. - -Queries with distinct domain specifiers will receive uncorrelated output. -For example, output from ODIS with the phone number domain and message `18002738255` will be distinct from and unrelated to the output when requesting with a password domain and message `18002738255`. - -In order to make this scheme flexible, allowing for user-defined tuning of rate-limits and the introduction of new rate limiting and authorization rules in the future, domains are defined as serializeable structs. -New domain types, with associated rate-limiting rules, may be added in the future to meet the needs of new applications. - -## Specification - -A full specification of Domains and the related ODIS APIs is available in CIP-40. - -- [CIP-40](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0040.md) - -## Implemented Domains - -- [Sequential Delay Domain](/legacy/protocol/identity/odis-domain-sequential-delay-domain) - -## Creating a Domain Type - -The Domains interface is designed to be flexible to facilitate new applications for the ODIS POPRF function. -If you have an application that would benefit from a new Domain type and rate limiting ruleset, the first step is to open an extension to the CIP-40 standard. - -New Domain types are standardized through a lighter version of the [general CIP process](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0000.md). -Open a PR against the celo-org/celo-proposals repository to add a specification for your new domain to the [CIP-40 extensions folder](https://github.com/celo-org/celo-proposals/tree/master/CIPs/CIP-0040). -As an example for what you should include, take a look at the [specification](https://github.com/celo-org/celo-proposals/blob/master/CIPs/CIP-0040/sequentialDelayDomain.md) for the `SequentialDelayDomain`. -When it is ready for review, contact a [CIP editor](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0000.md#cip-editors) to help get reviews from the ODIS core development team. - -Implementing a new Domain type, which includes new rate limiting to be enforced by the ODIS operators, requires an upgrade to the ODIS server implementation. -Once the new domain type is standardized, this implementation can be written and deployed to the staging and production ODIS service operators. diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-use-case-key-hardening.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-use-case-key-hardening.mdx deleted file mode 100644 index 4729aa761a..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-use-case-key-hardening.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Key Hardening ---- - -Passwords are useful primitive in a number of applications, allowing a user to authenticate themselves by knowing the secret information. -Unfortunately, effective offline password cracking techniques limit the use of passwords to derive encryption or authentication keys. -An attacker with access to a signature or encrypted file that used a password, or the hash of a password, as the key can make repeated guesses until they find the password. -Given advanced tools such as [`hashcat`](https://hashcat.net/hashcat/) and extensive experience, hackers are very good at guessing passwords. - -Rate-limited or expensive hashing can be used to make it much more difficult to crack a password. -Computationally expensive password hashing functions, such as PBKDF and scrypt, are commonly used for this purpose, but provide [limited protection](https://arxiv.org/abs/2006.05023) and are expensive to run on end-user devices. -ODIS implements hashing (i.e. PRF evaluation) with a rate limit controlled by the committee of ODIS operators, and can be used to harden a password into a stronger cryptographic key. -As long as this committee remains collectively honest and secure, an attacker cannot make more guesses at a users password than ODIS allows, making it extremely unlikely a good password will be broken. - -Using ODIS for key hardening allows passwords to be used in a number of applications, including to create [encrypted account backups](/legacy/protocol/identity/encrypted-cloud-backup) and as a factor in [smart contract account recovery](/legacy/protocol/identity/smart-contract-accounts). - -## Rate limiting - -Choosing an appropriately restrictive rate limit is crucial. -Using a rate limit that is too restrictive may cause users to become frustrated as their access is denied if they take too many tries to recall their password, and a rate limit that is too loose can allow an attacker a much better chance at guessing the users password. -The appropriate rate limit is related to how much entropy the user secret has. - -- A strong user password can tolerate a loose rate limit, allowing millions of attempts without significant chance of attacker success. -- An average user password can tolerate a moderate rate limit, allowing hundreds of attempts. -- A 4 or 6 digit PIN can tolerate tens of attempts before the attacker has a significant chance of success. - -Because the right rate limit is context specific, [Domains](/legacy/protocol/identity/odis-domain) can be configured to the needs of the user. -The [Sequential Delay Domain](/legacy/protocol/identity/odis-domain-sequential-delay-domain) is designed for the use case of PIN and password hashing, and can be used to allow for a fixed number of attempts over a configurable time period (e.g. 15 attempts over 3 days). -The Sequential Delay Domain additionally supports signature-based authentication to prevent quota from being consumed by any except the intended user. - -## Salting - -Even with the use of ODIS to prevent brute-force guessing of a password, it remains important to include a user-specific value in the hashing request as a salt to prevent [rainbow table attacks](https://wikipedia.org/wiki/Rainbow_table). -A salt can be included in the Domain parameter of the request to ODIS to ensure a rate limit is enforced specific to the user's context. -Using a random salt value is recommended, however a client identifier such as a username or [phone number hash](/legacy/protocol/identity/odis-use-case-phone-number-privacy) can also be used. - -## Password filtering - -In addition to using ODIS to harden passwords chosen by users, it is recommended that the application help the user choose a good password during onboarding. -Password filtering, blocking the user from setting a password which may be weak, can greatly improve the quality of a user's password and prevent it being broken by guessing the most common passwords (e.g. "password"). -[NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63-3.html) recommends that passwords should be checked against a list of known compromised passwords, such as [HIBP Passwords](https://haveibeenpwned.com/Passwords). -Additional research has found other [practical techniques for increasing the strength of passwords chosen by users](https://www.andrew.cmu.edu/user/nicolasc/publications/Tan-CCS20.pdf). diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-use-case-phone-number-privacy.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-use-case-phone-number-privacy.mdx deleted file mode 100644 index 72df01af69..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis-use-case-phone-number-privacy.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Phone Number Privacy ---- - - - -Celo's [identity protocol](/legacy/protocol/identity) allows users to associate their phone number with one or more addresses on the Celo blockchain. -This allows users to find each other on the Celo network using phone number instead of cumbersome hexadecimal addresses. -The Oblivious Decentralized Identifier Service (ODIS) was created to help preserve the privacy of phone numbers and addresses. - -- [ODIS](/legacy/protocol/identity/odis) - -## Understanding the problem - -When a user sends a payment to someone in their phone's address book, the mobile client must look up the identifier for that phone number on-chain to find the corresponding Celo blockchain address. -This address is needed in order to create a payment transaction, and the user may only know the phone number of the person they want to pay. -If cleartext phone numbers were used as identifiers directly on the Celo network, then anyone would be able to associate all phone numbers with blockchain accounts and balances (e.g. After searching for addresses with a high balance, they could look up the associated phone number to [phish](https://wikipedia.org/wiki/Phishing) the account owner). -If instead, the identifier was the hash of the recipient's phone number, attackers would still be able to associate phone numbers with accounts and balances via a [rainbow table attack](https://wikipedia.org/wiki/Rainbow_table). - -## The solution - -The basis of the solution is to derive a user's identifier from both their phone number and a secret pepper that is provided by the Oblivious Decentralized Identifier Service (ODIS). -In order to associate a phone number with a Celo blockchain address, the mobile wallet first queries ODIS for the pepper. -It then uses the pepper to compute the unique identifier that's used on-chain. - -Peppers produced by ODIS are cryptographically strong, and so cannot be guessed in a brute force or rainbow table attack. -ODIS imposes a rate limit controlling how many peppers any individual can request, and so prevents an attacker from scanning a large number of phone numbers in an attempt to compromise user privacy. - -### Pepper request rate limiting - -ODIS imposes a rate limit on requests for peppers in order to limit the feasibility of rainbow table attacks. -When ODIS receives a request for a pepper, it authenticates the request and ensures the requester has not exceeded their quota. -Since blockchain accounts and phone numbers are not naturally Sybil-resistant (i.e. individuals can have many accounts or phone numbers), ODIS bases request quota on the following factors: - -- Requester transaction history -- Requester phone number attestation count and success rate -- Requester account balance - -The requirements for these factors are configured to make it prohibitively expensive to scrape large quantities of phone numbers while still allowing typical user flows to remain unaffected. -In particular, it should be possible for a user to look up their contacts in order to send them payments. diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis.mdx deleted file mode 100644 index 9732e5f625..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/odis.mdx +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: Oblivious Decentralized Identifier Service (ODIS) -sidebarTitle: Overview ---- - -The Oblivious Decentralized Identifier Service (ODIS) allows for privacy preserving [phone number mappings](/legacy/protocol/identity/odis-use-case-phone-number-privacy), [password hardening](/legacy/protocol/identity/odis-use-case-key-hardening), and other use cases by implementing a rate limited oblivious pseudorandom function (OPRF). -Essentially, it is a service that allows users to compute a limited number of hashes (i.e. PRF evaluations), without letting the service see the data being hashed. -Many useful applications are built on top of this primitive, such as privacy protected phone number mappings, password hardening, and [captchas for bot detection](https://privacypass.github.io/). - -## Distributed key generation - -For the sake of user privacy and security, no single party should have the ability to unilaterally compute the OPRF function. -To ensure this, ODIS was designed to be decentralized across a set of reputable participants. -Before ODIS was deployed, a set of operators participated in a Distributed Key Generation (DKG) ceremony to generate shared secret, with its pieces split between the operators. -Details of the DKG setup can be found [in the Celo Threshold BLS repository](https://github.com/celo-org/celo-threshold-bls-rs). - -Each ODIS node holds a share of the key which can be used to calculate a piece of the OPRF evaluation that will be sent to the user. -When enough of these pieces are combined, their combination can be used to derive the unique OPRF evaluation (i.e. hash). -The number of key holders ($$m$$) and threshold of signatures required ($$k$$) to construct a full evaluation are both configurable at the time of the DKG ceremony. - -### Production setup - -As of October 2021, ODIS operates with 7 signers and a threshold of 5 (i.e. $$m=7, k=5$$). -As a result, 5 of the 7 parties must cooperate in order to produce an output from the (P)OPRF function, and as long as at least 3 are honest and secure, no unauthorized requests will be served. - -{/* TODO(victor): Once the new set is in production, information about the 7 operators should be included here */} - -### Security properties - -The goal the distributed key generation is to make it harder for a hacker, or a corrupt ODIS operator, to compromise the security of ODIS. -In particular, if an attacker has control over any less then the threshold $$k$$ of keys, they cannot make an unauthorized computation (e.g. querying the pepper for a phone number without quota) of the OPRF function. -Additionally, as long as $$k$$ operators remain honest and have access to their keys, honest users will continue to be able to use the service even if $$m-k$$ corrupt operators are refusing their requests. - -For example, consider the phone number privacy protocol when there are 7 ODIS operators and the required threshold is 5. An attacker may compute the pepper for all phone numbers if 5 operators are compromised or corrupt. If 3 are corrupt or taken offline (e.g. by DDoS attack) then an attacker may prevent the rest of the operators from generating the pepper for users. - -In the case that a single key is compromised, user data will remain private and the service operational; however, it's important that we can detect and perform a key rotation before the number of keys compromised exceeds $$k$$ or $$m - k + 1$$ (whichever is lower). - -## Rotating keys - -If a key held by one of the operators is leaked, or if the operator becomes corrupt, a key rotation can allow the group to generate a new set of keys. Once the new keys are in place, operators can destroy their old keys, preventing any use from the compromised key. -Key rotation can also allow new ODIS operators to be added, by creating new keys for all the existing operators as well as the newly added operator. - -To rotate keys, a new DKG ceremony must be performed with at least $$k$$ of the $$m$$ original keys. -These newly generated keys will not be compatible with the old keys; however if $$k$$ of the old keys are used, an attacker may still reach the necessary threshold. -Therefore, it's extremely important that all of the old keys are destroyed after a successful key rotation. -This DKG ceremony also provides the opportunity to change the values for $$k$$ and $$m$$, adding or removing operators, or changing the threshold required to compute the OPRF. -Note that this process for key rotation does not change the public key the client uses to [verify](#verification) the results. - -## Blinding - -When a client queries ODIS to get an OPRF evaluation, the client first blinds the phone number locally using a secret one-time key. -This blinding process preserves the privacy of underlying message (e.g. a mobile number or password) such that ODIS nodes won't learn any of the user's sensitive information. -In addition to protecting the user's privacy, it reduces the risk of targeted censorship. -ODIS operators compute the OPRF against this hidden input value, and return a result which is also hidden from the operators. -After the application receives the response, it unblinds it to receive the final evaluation result. -Note that this blinding process provides privacy to the user _even_ if all of the ODIS operators were corrupted. -This blinding process is what makes the oblivious pseudo random function (OPRF) "oblivious". - -## Verification - -Query results from ODIS can be verified against the services public key, which is shared with users along with the client library. -By verifying the results, the client can be sure that the service computed the OPRF correctly and that no one could have intercepted and changed the result. - -## Combiner - -To facilitate the communication needed for the $$k$$ of $$m$$ OPRF evaluation, ODIS includes a combiner service which performs this orchestration for the convenience of wallets and other clients building on Celo. -Like the ODIS operators, the combiner only receives the blinded message and therefore it cannot learn anything about the user's sensitive information. -The combiner also verifies the response from each operator to ensure a corrupt operator cannot affect the resulting pepper. -Clients can additionally verify the response they get from the combiner to ensure the combiner could not have tampered with it. - -Anyone can run a combiner, for their own use or for the public. -Currently, cLabs operates one such combiner that may be used by any project building on Celo. - -## Rate limiting - -As part of its core function, ODIS enforces rate limits on user queries. -Rate limits depend on the application context in which ODIS is being used (e.g. the rate limit is much higher for deriving peppers for phone numbers than for hardening a 6-digit PIN) - -### Phone number privacy - -The original API, targeted for phone number privacy, enforces a rate limit based on the actions, balance, and verification status or the user on the Celo blockchain. -In order to measure the quota for a given requester, ODIS must check their on-chain account information. -To prove ownership over their account, the POST request contains an Authorization header with the signed message body. -When ODIS nodes receive the request, it authenticates the user by recovering the message signer from the header and comparing it to the value in the message body. - -### Domains - -In the newer domain separated API, the rate limit can depend on a variety of factors configured to each domain type. -More information about the domains API and the implemented domain types can be found in the respective pages. - -- [Domains](/legacy/protocol/identity/odis-domain) -- [Sequential Delay Domain](/legacy/protocol/identity/odis-domain-sequential-delay-domain) - -A full specification of the Domains API can be found in CIP-40. - -- [CIP-40](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0040.md) - -## Request flow diagram - - -![request flow diagram](https://storage.googleapis.com/celo-website/docs/ODIS-flow-diagram.svg) - - -## Architecture - - -![architecture diagram](https://storage.googleapis.com/celo-website/docs/ODIS-architecture-diagram.svg) - - -The hosted architecture is divided into two components, the combiner and the signers. -Currently the combiner is a cloud function and the signers are independent NodeJS servers run by the operators. -Both services leverage the [Celo Threshold BLS library](https://github.com/celo-org/celo-threshold-bls-rs) which has been compiled to [a Web Assembly module](https://github.com/celo-org/blind-threshold-bls-wasm). - -The combiner and signers maintain some minimal state in a SQL database, mainly related to quota tracking. - -For storage of the BLS signing key, the signers currently support three cloud-based keystores: Azure Key Vault, AWS Secret Manager, and Google Secret Manager. diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/privacy-research.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/privacy-research.mdx deleted file mode 100644 index f17976abbb..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/privacy-research.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Future Privacy Research" -sidebarTitle: "Privacy Research" ---- - -Celo is committed to meet the privacy needs of its users. This section describes future plans for delivering on this commitment, while also sharing the current limitations of the Celo networks. - -### Privacy mode - -One downside to this identity protocol is that knowledge of a phone number can let anyone quickly determine the balance of the associated wallet, which of course may be unacceptable for many use cases. For these circumstances, the contract allows users to use the `Attestations` contract in privacy mode. In this mode, the user does not map their phone number to their wallet address, but to an account that is not meant to be the recipient of transfers. Through a registered encryption key on the user’s account on the contract, schemes can be derived to allow users to selectively reveal their true wallet addresses to authorized participants. - -{/* ### Transaction and Balance Privacy - -As with most public blockchains \(e.g. Bitcoin, Ethereum\), transactions and smart contracts calls on Celo are public for everyone to see. This means that if a user wants to map the hash of their phone number to their wallet address, people with knowledge of that user's phone number will be able to see their transactions and balances. - -To address this issue, the cLabs team, [Matterlabs](https://matterlabs.dev) and other esteemed zk-SNARK cryptographers and Celo community members are working to create a framework that makes it easy to create gas-efficient tokens that offer Zcash-like privacy, using a shared anonymity pool. Such an implementation could allow wallets to use the default identity mode easily without the risk that someone with your phone number could see your balance and transaction history. */} diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/smart-contract-accounts.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/identity/smart-contract-accounts.mdx deleted file mode 100644 index 001ab9715a..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/identity/smart-contract-accounts.mdx +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Smart Contract Accounts ---- - -Smart contract accounts are used to enable features beyond what can be accomplished with an externally owned account (EOA) alone. -In this document, we'll describe some of the features and considerations associated with smart contract accounts in general, and the architecture used by the Valora wallet in particular as an example of how smart contract accounts can be used. - -EOAs are what most people think of when they imagine a blockchain wallet. -EOAs are comprised of an ECDSA public/private key pair from which the on-chain address is derived. -The account address is derived from the public key, and transactions are authorized by the private key. -In most wallets, the EOA is generated and stored on the user's mobile device and backed up via a BIP-39 mnemonic phrase. - -A smart contract account on the other hand is a smart contract that can be used to interact with other smart contracts on behalf of the owner. -Celo provides an open-source implementation of a smart contract account; the [meta-transaction wallet](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/MetaTransactionWallet.sol) (MTW). -In general, ownership can be determined in arbitrary ways, but most commonly an EOA is designated as the owner and can authorize transactions my signing a meta-transaction containing the details of the authorized transaction. -This is how the meta-transaction wallet works. -In this case you can think of the smart contract account as the primary account, and the EOA as the controller of this account. - -## Benefits of a smart contract account - -### Separation of signer and payer - -When new users create a wallet, they start with an empty balance. -This makes it difficult for the new users to verify their phone number as they need to pay for both the Celo transactions and the Attestation Service fees ([see here for more details](/legacy/protocol/identity/)). -To make this experience more intuitive and frictionless for new users, cLabs operates an [onboarding service called Komenci](https://github.com/celo-org/komenci/) that pays for the transactions on behalf of the user. -It does this by first deploying a meta-transaction wallet contract and setting the wallet EOA address as the signer. -At this point, the EOA can sign transactions and submit them to Komenci. -Komenci will wrap the signed transaction into a meta-transaction, which it pays for and submits to the network. - -In general, smart contract accounts allow the someone other than the account owner to pay for the transaction fees required to submit a transaction to the blockchain, enabling a number of useful operations not otherwise possible. - -### Account recovery - -Smart contract accounts can also be useful if a user ever loses their phone and recovery phrase. -Unlike EOAs, smart contract accounts can support account recovery methods that do not rely solely on recovering the underlying keys. -The meta-transaction wallet implements [a function](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/MetaTransactionWallet.sol#L101-L108) to assign another Celo address as the Guardian of the account. -This Guardian can be a simple backup key or a smart contract implementing social recovery, [KELP](https://eprint.iacr.org/2021/289), or another account recovery protocol. -With the authorization of the Guardian, the meta-transaction wallet will update the owner of the account to replace the lost key. -Any funds or privileges held by the meta-transaction wallet are then recovered to the user who can control the account using their new key. - -### Transaction batching - -With smart contract accounts, including the meta-transaction wallet, transactions can be batched together to execute atomically. -This makes for a better user experience, as transactions can be guaranteed to execute all together or entirely revert. -It can also prevent some cases where front-running would be possible by splitting the user's transactions. - -## Valora accounts - -Behind every Valora wallet are two types of accounts: an externally owned account (EOA) and a meta-transaction wallet. -Valora generates the EOA during onboarding, and has a meta-transaction wallet deployed for it by Komenci with the generated EOA as the signer. -Using this configuration, Valora users gain the benefits listed above, including having Valora pay for the transaction fees associated with onboarding. - -## Sending to a Valora wallet - -When performing a payment to a Valora wallet, it's important that the address that is receiving funds is the EOA, and not the MTW since funds in the MTW are not displayed or directly accessible to Valora users. -To look up a wallet using a phone number: - -1. Use ODIS to query the phone number pepper -2. Use the phone number pepper to get the on-chain identifier -3. Use the on-chain identifier to get the account address -4. Use the account address to get the wallet address (EOA) - -The first two steps are covered extensively in [this guide](/developer/contractkit/odis). - -To get the account address (step 3) you can use the [Attestation contract method `lookupAccountsForIdentifier`](https://github.com/celo-org/celo-monorepo/blob/e6fdaf798a662ffe2c12f9a74b28e0fa1c1f8101/packages/sdk/contractkit/src/wrappers/Attestations.ts#L472). - -To get the wallet address from the account (step 4) you can use the [Account contract method `getWalletAddress`](https://github.com/celo-org/celo-monorepo/blob/e6fdaf798a662ffe2c12f9a74b28e0fa1c1f8101/packages/sdk/contractkit/src/wrappers/Accounts.ts#L318). - -It may also be necessary to lookup the data encryption key (ex. [for comment encryption](/what-is-celo/about-celo-l1/protocol/transaction/tx-comment-encryption)). This key can similarly be queried with the account by using the [Account contract method `getDataEncryptionKey`](https://github.com/celo-org/celo-monorepo/blob/e6fdaf798a662ffe2c12f9a74b28e0fa1c1f8101/packages/sdk/contractkit/src/wrappers/Accounts.ts#L310). - -You can view a working example of this all tied together in [the `celocli` command `identity:get-attestations`](https://github.com/celo-org/celo-monorepo/blob/master/packages/cli/src/commands/identity/get-attestations.ts). - -## Enabling Valora to interact with your dApp - -### Signatures - -Since all Valora users will have the use a meta-transaction wallet, it's important to keep in mind that transactions may originate from an EOA as well as a smart contract. -If your contract relies upon EIP-712 signed typed data, be sure to also support typed data originating from contracts. -This data can't be signed by the `msg.sender` since it's originating from a contract, but is implicitly authorized by originating from the contract. - -## Implementation - -The implementation of the meta-transaction wallet can be [found here](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/MetaTransactionWallet.sol). diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/becoming-a-validator.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/becoming-a-validator.mdx deleted file mode 100644 index f496af3b85..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/becoming-a-validator.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Becoming a Validator" ---- - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -To participate in the network, an operator must put up a slashable commitment of locked CELO, register as a validator, and join a validator group. A minimum stake of one CELO and a notice period of 60 days is required to be a validator in the Alfajores Testnet. - -Any account that meets the minimum stake and notice period requirements can register as a validator. By doing so, the locked funds on that account become ‘at risk’: a fraction of the stake can be slashed automatically for an evolving set of misbehaviors. In addition, the community can use governance proposals to slash funds, which avoids having to anticipate and encode in the protocol every possible misbehavior. As long as the CELO staked for a validator account is not slashed, it’s eligible to earn rewards like any other Locked Gold account. - -A validator joins a validator group by affiliating itself with it. However, to avoid untrusted or malicious validators joining a group, the validator group must accept the affiliation. Once done, the validator is added to the list of validators in the group. A validator can remove itself from a validator group at any time. Changes only take effect at the next subsequent election, so if the validator is currently participating in consensus, it’s expected to do so until the end of the epoch in which it deregisters itself. diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-locked-gold.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-locked-gold.mdx deleted file mode 100644 index 46c9a6cfd0..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-locked-gold.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Locked CELO Rewards" -sidebarTitle: "Locked CELO Rewards" -og:description: How to earn locked CELO rewards and adjust the rate for voting participation, target schedule, and deductions. ---- - -How to earn locked CELO rewards and adjust the rate for voting participation, target schedule, and deductions. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Introduction to Locked CELO Rewards - -Holders of Locked CELO that voted in the previous epoch for a group that elected one or more validators and have activated their votes are eligible for rewards. Rewards are added directly to the Locked CELO voting for that group, and re-applied as votes for that same group, so future rewards are compounded without the account holder needing to take any action. The voting process is described further [here](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-locked-gold). - - -Rewards to Locked CELO are totally independent from validator and validator group rewards, and are not subject to the **group share**. - - - -![Flow diagram showing locked CELO rewards process](https://storage.googleapis.com/celo-website/docs/locked-gold-rewards.jpg) - - -## Adjusting the Reward Rate for Voting Participation - -The protocol has a target for the proportion of circulating CELO that is locked and used for voting. An on-target reward rate is determined and then adjusted at every epoch to increase or reduce the attractiveness of locking up additional supply. This aims to balance having sufficient liquidity for CELO, while making it more challenging to buy enough CELO to meaningfully influence the outcome of a validator election. - -The reward rate is adjusted as follows: - - -![Mathematical equation showing reward rate adjustment formula](https://storage.googleapis.com/celo-website/docs/voting_reward_rate_adjustment_equation.png) - - -where $$rr$$ is the reward rate or voting yield, $$vf$$ is the voting fraction calculated as locked CELO for voting divided by circulating CELO supply, and $$af$$ is the adjustment factor. If the voting participation is below the target at the end of an epoch, the on-target reward rate is increased; if the voting participation is above the target at the end of an epoch, the reward is decreased. - -## Adjusting the Reward Rate for Target Schedule and Deductions - -Adjusting the on-target reward rate to account for under- or over-spending against the target schedule gives a baseline reward, essentially the percentage increase for a unit of Locked CELO voting for a group eligible for rewards. - -The reward for activated Locked CELO voting for a given group is determined as follows. First, if the group elected no validators in the current epoch, rewards are zero. Otherwise, the baseline reward rate factors in two deductions. It is multiplied by the slashing penalty for the group, and by the average epoch uptime score for validators in the group elected in the current epoch. Finally, the group's activated pool of Locked CELO is increased by this rate. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-validator.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-validator.mdx deleted file mode 100644 index 5d63fd2845..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-validator.mdx +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "Validator Rewards" -sidebarTitle: "Validator Rewards" -og:description: Overview of epoch rewards for Validators and Validator Groups. ---- - -Overview of epoch rewards for Validators and Validator Groups. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -The protocol aims to incentivize validator uptime performance and penalize past poor behavior in future rewards, while ensuring that payments are economically reasonable in size independent of fluctuations of the price of CELO. - -**Five factors affect validator and group rewards:** - -- The on-target reward amount for this epoch -- The protocol's [overall spending vs target of epoch rewards](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards) -- The validator’s ‘uptime score’ -- The current value of the slashing penalty for the group of which it was a member at the last election -- The group share for the group of which it was a member at the last election - -Epoch rewards to validators and validator groups are denominated in Celo Dollars, since it is anticipated that most of their expenses will be incurred in fiat currencies, allowing organizations to understand their likely return regardless of volatility in the price of CELO. To enable this, the protocol mints new Celo Dollars that correspond to the epoch reward equivalent of CELO which are maintained on chain to preserve the collateralization ratio. Of course, the effect on the target schedule depends on the prevailing exchange rate. - - -![](https://storage.googleapis.com/celo-website/docs/validator-rewards.jpg) - - -## On-target Rewards - -The on-target validator reward is a constant value (as block rewards typically would be) and is intended to cover costs plus an attractive margin for amortized capital and operating expenses associated with a recommended set up that includes redundant hosts with hardware wallets in a secure co-lo facility, proxy nodes at cloud or edge hosting providers, as well as security audits. As with most parameters of the Celo protocol, it can be changed by governance proposal. - -In the usual case where no validator in the group has been slashed recently, and the validator has signed almost every block in the epoch, then the validator receives the full amount of the on-target reward, less the fraction sent to the validator group based on the group share. Unlike in some other proof-of-stake schemes, epoch rewards to validators do not depend on the number of votes the validator’s group has received. - -## Calculating Uptime Score - -The Celo protocol tracks an ‘uptime score’ for each validator. When a validator proposes a block, it also includes in the block body every signature that it has received from validators committing the previous block. - - -![](https://storage.googleapis.com/celo-website/docs/uptime-score.jpg) - - -For a validator to be ‘up’ at a given block, it must have its signature included in at least one in the previous twelve blocks. This cannot be done during the first 11 blocks of the epoch. At each epoch, this counter is reset to 0. Because the proposer order is shuffled at each election, it is very hard for a malicious actor withholding an honest validator’s signatures to affect this measure. - -Then, a validator’s uptime for the epoch is the proportion of blocks in the epoch for which it is ‘up’: `u = (counter + downtime_grace_period) / (epoch_size - 11)`. Its epoch uptime score `S_ve = u ^ k`, where `downtime_grace_period` and `k` are a governable constants. This means that even repeated downtimes of less than around a minute are ignored and longer downtimes also won't count against the validator as long as their total duration stays below `downtime_grace_period`. After that the score will reduce rapidly due to the exponent `k`. - -The validator’s overall uptime score is an exponential moving average of the uptime score from this and previous epochs. `S_{v} = min(S_ve, S_ve * x + S_{v-1} * (1 -x))` where `0 < x < 1` and is governable. Since `S_v` starts out at zero, validators have a disincentive to change identities and an incentive to prioritize activities that improve long-term availability. - -## Calculating Slashing Penalty - -The protocol also tracks for each group a ‘slashing penalty’, initially equal to one but successively reduced on each occasion a validator in that group is slashed. The penalty returns to one 30 days after it was last reduced. - -This factor is applied to all rewards to validators in that group, to the group itself, and to voters for the group. - -The slashing penalty gives groups a further incentive to vet validators they accept as members, not only to avoid reducing their own future rewards from existing validators but to attract and retain the best validators. - -Validators have an incentive to be elected through groups with a high value, so a recent slashing makes a group less attractive. Validators also have an incentive to select groups where they believe careful vetting processes are in place, because poor vetting of other validators in the group reduces their own expectation of future rewards. - -When a validator is slashed, reduced rewards may lead other validators in the same group to consider equivalently ‘safe’ slots in other groups, if they are available. A validator disassociating from the group would cause the group’s rewards to further decline. While that may cause churn in the set of groups through which validators are elected, it is unlikely that a validator would move to a group where they could not be elected (since in this case they would receive no rewards, as opposed to fewer rewards), hence making the votes by which they were previously elected unproductive. - -## Group Share - -Validator groups are compensated by taking a share of the rewards allocated to validators. Validator groups set a **group share** rate when they register, and can change that at any time. The protocol automatically deducts this share, sending that portion of the epoch rewards to the validator group of which they were a member at the time of the last election. - -Since the sum of a validator’s reward and its validator group’s reward are the same regardless of the ‘group share’ that the group chooses, no side-channel collusion is possible to avoid deductions for downtime or previous slashing. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards.mdx deleted file mode 100644 index d2dc0a6672..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Epoch Rewards" -sidebarTitle: "Overview" -og:description: Introduction to Celo epoch rewards and the target reward release schedule. ---- - -Introduction to Celo epoch rewards and the target reward release schedule. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## What are Epoch Rewards? - -**Epoch Rewards** are similar to the familiar notion of block rewards in other blockchains, minting and distributing new units of CELO as blocks are produced, to create several kinds of incentives. - -**Epoch rewards are paid in the final block of the epoch and are used to:** - -- Distributed [rewards for validators and validator groups](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-validator) -- Distribute [rewards to holders of Locked CELO](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-locked-gold) voting for groups that elected validators -- Make payments into a [Community Fund](/home/protocol/epoch-rewards/community-fund) for protocol infrastructure grants -- Make payments into a [Carbon Offsetting Fund](/home/protocol/epoch-rewards/carbon-offsetting-fund) for carbon offsetting projects - -A total of 400 million CELO will be released for epoch rewards over time. CELO is a utility and governance asset on Celo, and also the reserve collateral for Celo Dollar (and possibly in the future other whitelisted tokens). It has a fixed total supply and in the long term will exhibit deflationary characteristics similarly to Ethereum. - -### Reward Disbursement - -The total amount of disbursements is determined at the end of every epoch via a two step process. - -**Step 1** - -In step one, economically desired **on-target rewards** are derived. These are explained in the following pages. Several factors can increase or decrease the value of the payments that would ideally be made in a given epoch (including the CELO to Dollar exchange rate, the collateralization of the reserve, and whether payments to validators or groups are held back due to poor uptime or prior slashing). - -**Step 2** - -In step two, these on-target rewards are adjusted to generate a drift towards a predefined target epoch rewards schedule. This process aims to solve the trade-off between paying reasonable rewards in terms of purchasing power and avoiding excessive over- or underspending with respect to a predefined epoch rewards schedule. More detail about the two steps is provided below. - -## Adjusting Rewards for Target Schedule - -There is a target schedule for the release of CELO epoch rewards. The proposed target curve \(subject to change\) of remaining epoch rewards declines linearly over 15 years to 50% of the initial 400 million CELO, then decays exponentially with half life of $$h = ln(2)\times15 =10.3$$ afterwards. The choice of $$h$$ guarantees a smooth transition from the linear to the exponential regime. - - -![Chart showing CELO epoch rewards release schedule over time: starting at 400 million CELO, declining linearly over 15 years to 200 million CELO (50% of initial), then transitioning to exponential decay with half-life of 10.3 years](https://storage.googleapis.com/celo-website/docs/epoch-rewards-schedule.png) - - -The total **actual rewards** paid out at the end of a given epoch result from multiplying the total on-target rewards with a `Rewards Multiplier`. This adjustment factor is a function of the percentage deviation of the remaining epoch rewards from the target epoch rewards remaining. It evaluates to `1` if the remaining epoch rewards are at the target and to smaller \(or larger\) than `1` if the remaining rewards are below \(or above, respectively\) the target. This creates a drag towards the target schedule. - -The sensitivity of the adjustment factor to the percentage deviation from the target are governable parameters: one for an underspend, one for an overspend. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/index.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/index.mdx deleted file mode 100644 index d3b44bd3d3..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/index.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "Proof of Stake" -sidebarTitle: "Overview" -og:description: Overview of Celo's proof-of-stake algorithm, mechanisms, and implementation. ---- - -import {YouTube} from '/snippets/YouTube.jsx'; - -Overview of Celo's proof-of-stake algorithm, mechanisms, and implementation. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Mastering the Art of Validating - - - -## Validator Types - -Celo uses a Byzantine Fault Tolerant [consensus protocol](/what-is-celo/about-celo-l1/protocol/consensus) to agree on new blocks to append to the blockchain. The instances of the Celo software that participate in this consensus protocol are known as **validators**. More accurately, they are **active validators** or **elected validators**, to distinguish them from **registered validators** which are configured to participate but are not actively selected. - -## Proof-of-Stake - -Celo's proof-of-stake mechanism is the set of processes that determine which nodes become active validators and how incentives are arranged to secure the network. - -## Active Validators - -The first set of active validators are determined in the genesis block. Thereafter at the end of every epoch, a fixed number of blocks fixed at network creation time, an election is run that may lead to validators being added or removed. - - -![](https://storage.googleapis.com/celo-website/docs/concepts.jpg) - - -## Validator Elections - -In Celo's [Validator Elections](/what-is-celo/about-celo-l1/protocol/pos/validator-elections), holders of the native asset, CELO, may participate and earn rewards for doing so. Accounts do not make votes for validators directly, but instead vote for [validator groups](/what-is-celo/about-celo-l1/protocol/pos/validator-groups). - -Before they can vote, holders of CELO move balances into the [Locked Gold](/what-is-celo/about-celo-l1/protocol/pos/locked-gold) smart contract. Locked Gold can be used concurrently for: placing votes in Validator Elections, maintaining a stake to satisfy the requirements of registering as a validator or validator group, and also voting in on-chain [Governance](/what-is-celo/using-celo/protocol/governance/overview/) proposals. This means that validators and groups can vote and earn rewards with their stake. - - -**note** - -Unlike in other proof-of-stake systems, holding Locked Gold or voting for a group does not put that amount 'at risk' from slashing due to the behavior of validators or validator groups. Only the stake put up by a validator or group may be slashed. - - -## Implementation - -Most of Celo's proof-of-stake mechanism is implemented as smart contracts, and as such can be changed through Celo's on-chain [Governance](/what-is-celo/using-celo/protocol/governance/overview/) process. - -- [`Accounts.sol`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/Accounts.sol) manages key delegation and metadata for all accounts including Validators, Groups and Locked Gold holders. - -- [`LockedGold.sol`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/LockedGold.sol) manages the lifecycle of Locked Gold. - -- `Validators.sol` handles registration, deregistration, staking, key management and epoch rewards for validators and validator groups, as well as routines to manage the members of groups. - -- [`Election.sol`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/Election.sol) manages Locked Gold voting and epoch rewards and runs Validator Elections. - -In Celo blockchain: - -- [`consensus/istanbul/backend/backend.go`](https://github.com/celo-org/celo-blockchain/blob/master/consensus/istanbul/backend/backend.go) performs validator elections in the last block of the epoch and calculates the new [validator set diff](/what-is-celo/about-celo-l1/protocol/consensus/validator-set-differences). - -- [`consensus/istanbul/backend/pos.go`](https://github.com/celo-org/celo-blockchain/blob/master/consensus/istanbul/backend/pos.go) is called in the last block of the epoch to process validator uptime scores and make epoch rewards. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/locked-gold.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/locked-gold.mdx deleted file mode 100644 index 5145806dde..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/locked-gold.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Locked CELO and Voting -og:description: Introduction to locked CELO and how to use validator elections to participate in voting. -sidebarTitle: "Locked CELO" ---- - -Introduction to Celo locked gold (CELO) and how to use validator elections to participate in voting. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - - -**Terminology** - -This page references "Locked Gold". The native asset of Celo was called Celo Gold (cGLD), but is now called CELO. Many references have been updated, but code and smart contract references may still mention Gold as it is more difficult to reliably and securely update the protocol code. - - ---- - -## Validator Election Participation - -To participate in validator elections, users must first make a transfer of CELO to the `LockedGold` smart contract. - -## Concurrent Use of Locked CELO - -Locking up CELO guarantees that the same asset is not used more than once in the same vote. However every unit of Locked CELO can be deployed in several ways at once. Using an amount for voting for a validator does not preclude that same amount also being used to vote for a governance proposal, or as a stake at the same time. Users do not need to choose whether to have to move funds from validator elections in order to vote on a governance proposal. - -## Unlocking Period - -Celo implements an **unlocking period**, a delay of 3 days after making a request to unlock Locked CELO before it can be recovered from the escrow. - -This value balances two concerns. First, it is long enough that an election will have taken place since the request to unlock, so that those units of CELO will no longer have any impact on which validators are managing the network. This deters an attacker from manipulations in the form of borrowing funds to purchase CELO, then using it to elect malicious validators, since they will not be able to return the borrowed funds until after the attack, when presumably it would have been detected and the borrowed funds’ value have fallen. - -Second, the unlocking period is short enough that it does not represent a significant liquidity risk for most users. This limits the attractiveness to users of exchanges creating secondary markets in Locked CELO and thereby pooling voting power. - -## Locking and Voting Flow - - -![](https://storage.googleapis.com/celo-website/docs/locked-gold-flow.jpg) - - -The flow is as follows: - -- An account calls `lock`, transferring an amount of CELO from their balance to the `LockedGold` smart contract. This increments the account's 'non-voting' balance by the same amount. - -- Then the account calls `vote`, passing in an amount and the address of the group to vote for. This decrements the account's 'non-voting' balance and increments the 'pending' balance associated with that group by the same amount. This counts immediately towards electing validators. Note that the vote may be rejected if it would mean that the account would be voting for more than 3 distinct groups, or that the [voting cap](/what-is-celo/about-celo-l1/protocol/pos/validator-elections#group-voting-caps) for the group would be exceeded. - -- At the end of the current epoch, the protocol will first deliver [epoch rewards](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards) to validators, groups and voters based on the current epoch (pending votes do not count for these purposes), and then run an [election](/what-is-celo/about-celo-l1/protocol/pos/validator-elections) to select the active validator set for the following epoch. - -- The pending vote continues to contribute towards electing validators until it is changed, but the account must call `activate` (in a subsequent epoch to the one in which the vote was made) to convert the pending vote to one that earns rewards. - -- At the end of that epoch, if the group for which the vote was made had elected one or more validators in the prior election, then the activated vote is eligible for [Locked CELO rewards](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-locked-gold). These are applied to the pool of activated votes for the group. This means that activated voting Locked CELO automatically compounds, with the rewards increasing the account's votes for the same group, thereby increasing future rewards, benefitting participants who have elected to continuously participate in governance. - -- The account may subsequently choose to `unvote` a specific amount of voting Locked CELO from a group, up to the total balance that the account has accrued there. Due to rewards, this Locked CELO amount may be higher than the original value passed to `vote`. - -- This Locked CELO immediately becomes non-voting, receives no further Epoch Rewards, and can be re-used to vote for a different group. - -- The account may choose to `unlock` an amount of Locked CELO at any time, provided that it is inactive: this means it is non-voting in Validator Elections, the `deregistrationPeriod` has elapsed if the amount has been used as a validator or validator group stake, and not active in any [Governance proposals](/what-is-celo/using-celo/protocol/governance/overview/). Once an unlocking period of 3 days has passed, the account can call `withdraw` to have the `LockedGold` contract transfer them that amount. - -Votes persist between epochs, and the same vote is applied to each election unless and until it is changed. Vote withdrawal, vote changes, and additional CELO being used to vote have no effect on the validator set until the election finalizes at the end of the epoch. - -## Vote Delegation - -[Contract Release 10](https://github.com/celo-org/celo-monorepo/issues/10375) introduced vote delegation, which allows the governance participant to delegate their voting power. - - -Validators and Validator groups cannot delegate. - - -The governance participants who cannot actively participate to vote on governance proposals in the Celo ecosystem can now delegate their votes to utilize the dormant votes. - -Currently, participants can only delegate to 10 other delegatees. - -Participants can follow the steps [here](/what-is-celo/using-celo/protocol/governance/voting-in-governance#vote-delegation) to perform delegation using CeloCLI. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/penalties.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/penalties.mdx deleted file mode 100644 index 175f0d7468..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/penalties.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Validator Penalties" -sidebarTitle: "Penalties" -og:description: Introduction to validator penalties, enforcement mechanisms, and conditions. ---- - -Introduction to validator penalties, enforcement mechanisms, and conditions. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## What is Slashing? - -Slashing accomplishes punishment of misbehaving validators by seizing a portion of their stake. Without these punishments, for example, the Celo Protocol would be subject to the nothing at stake problem. Validator misbehavior is classified as a set of slashing conditions below. - -## Enforcement Mechanisms - -The protocol has three means of recourse for validator misbehavior. Each slashing condition applies a combination of these, as described below. - -- **Slashing of validator and group stake -** Some slashing conditions take a fixed amount of the Locked Gold stake put up by a validator. In these cases, the group through which that validator was elected for the epoch in which the slashing condition was proven is also slashed the same fixed amount. A validator or group's stake may be forfeit while it is registered or, after being deregistered, during the notice period (60 days for validators, 180 days for groups) and before the amount is withdrawn from the `LockedGold` contract. - -- **Suppression of future rewards -** Every validator group has a **slashing penalty**, initially `1.0`. All rewards to the group and to voters for the group are weighted by this factor. If a validator is slashed, the group through which that validator was elected for the epoch in which it misbehaved has the value of its slashing penalty halved. So long as no further slashing occurs, the slashing penalty is reset to `1.0` after `slashing_penalty_reset_epochs` epochs. - -- **Ejection -** When a validator is slashed, it is immediately removed from the group of which it is currently a member (even if this group is not the group that elected the validator at the point the misbehavior was recorded). Since no changes in the active validator set are made during an epoch, this means an elected validator continues participate in consensus until the end of the epoch. The group can choose to re-add the validator at any point, provided the usual conditions are met (including that the validator has sufficient Locked Gold as stake). - -## Slashing Conditions - -There are three categories of slashing conditions: - -- Provable \(initiated off-chain, verifiable on-chain\) -- Governed \(verified only by off-chain knowledge\) - -### Provable - -Provable slashing conditions cannot be initiated automatically on chain but information provided from an external source can be definitively verified on-chain. - -In exchange for sending a transaction which initiates a successful provable slashing condition on-chain, the reporter receives a "reward", a portion of the slashed amount (which will always be greater than the gas costs of the proof). The reward is added to the reporter's balance of non-voting LockedGold. The remainder of the slashed amount is sent to the [Community Fund](/home/protocol/epoch-rewards/community-fund). - -- **Persistent downtime -** A validator which can be shown to be absent from 8640 consecutive BLS signatures will be slashed 100 CELO, have future rewards suppressed, and (most importantly in this case) will be ejected from its current group. - -- **Double Signing -** A validator which can be shown to have produced BLS signatures for 2 distinct blocks at the same height and in the same consensus round but with different hashes will be slashed 9000 CELO, have future rewards suppressed, and will be ejected from its current group. Note that unlike some proof-of-stake networks, Celo does not penalize validators for double signing regular consensus messages. In particular, one side-effect of how Celo provides liveness can result in cases where honest validators may legitimately double sign blocks across different rounds at the same height (Cosmos terms this [amnesia](https://github.com/tendermint/spec/blob/fa3430ad163a2a0ed77aa3f624a70cd9b8b84b78/spec/consensus/signing.md#other-rules) and also specifically excludes it from slashing). - -### **Governed** - -For misbehavior which is harder to formally classify and requires some off-chain knowledge, slashing can be performed via [governance proposals](/what-is-celo/using-celo/protocol/governance/overview/). These conditions are important for preventing nuanced validator attacks. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/validator-elections.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/validator-elections.mdx deleted file mode 100644 index 98a8ac3dfd..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/validator-elections.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Validator Elections" -sidebarTitle: "Validator Elections" -og:description: Introduction to Celo validator elections and management of groups and votes throughout the process. ---- - -Introduction to Celo validator elections and management of groups and votes throughout the process. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Updating the Active Validator Set - -The active validator set is updated by running an election in the final block of each epoch, after processing transactions and [Epoch Rewards](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards). - -### Group Voting Caps - -One way to consider the security of a proof-of-stake system is the marginal cost of getting a malicious validator elected. In a steady state, assuming the Celo community set the incentives appropriately, a full complement of validators is likely to be elected, which means the attack cost is the cost of acquiring sufficient CELO to receive more votes than the currently elected validator with fewest votes, and thereby supplant it. - -### Goal of Validator Elections - -The objective of Celo’s validator elections differs from real-world elections: they aim to translate voter preferences into representation while promoting decentralization and creating a moat around existing, well-performing elected validators. Two design choices influence this: a limit on the maximum number of member validator that a group can list, and a **voting cap** on the number of votes that any one group can receive. - -### Handling Excess Votes - -Since voting for a group can cause only the group’s member validators to get elected, and no more, votes in excess of the number needed to achieve that are unproductive in the sense that they do not raise the number of votes needed to get the least-voted-for validator elected. This would translate into a lower cost for a malicious actor to acquire enough CELO to supplant that validator. This is particularly true because the protocol limits the maximum number of members in a group, to promote decentralization. - -### Per-Group Vote Cap - -The Celo protocol addresses this by enforcing a per-group vote cap. This cap is set to be the number of votes that would be needed to elect all of its validators, plus one more validator. The cap is enforced at the point of voting: a user can only cast a vote for a group if it currently has fewer votes than this cap. An account holder may not set or increase the amount of gold they have voting for a particular validator group `j`, if it already has at least `[(group_members_j + 1) / min(total_group_members, max_validators)]` of the total Locked Gold. - -### Adding New Validators - -If a group adds a new validator, or the total amount of voting Locked Gold increases, the group’s cap rises and new votes are permitted. If a group removes a validator or a validator chooses to leave, or the total amount of voting Locked Gold falls, then the group’s cap falls: if it has more votes than this new cap, then new votes are no longer permitted, but all existing votes continue to be counted. - -The Celo protocol allows an account to divide its vote between up to ten groups, since there may be cases where the vote cap prevents an account allocating its entire vote to its first choice group. - -## Running the Election - - -![](https://storage.googleapis.com/celo-website/docs/election.jpg) - - -The `Election` contract is called from the IBFT block finalization code to select the validators for the following epoch. The contract maintains a sorted list of the Locked Gold voting (either pending or activated) for each Validator Group. The [D’Hondt method](https://wikipedia.org/wiki/D'Hondt_method), a closed party list form of proportional representation, is applied to iteratively select validators from the Validator Groups with the greatest associated vote balances. - -### Filtering Groups - -The list of groups is first filtered to remove those that have not achieved a certain fraction of the votes of the total voting Locked Gold. - -### Assigning Seats - -Then, in the first iteration, the algorithm assigns the first seat to the group that has at least one member and with the most votes. Thereafter, it assigns the seat to the group that would ‘pay’, if its next validator were elected, the highest vote averaged over its candidates that have been selected so far plus the one under consideration. - -### Number of Active Validators - -There is a minimum target and a maximum cap on the number of active validators that may be selected. If the minimum target is not reached, the election aborts and no change is made to the validator set this epoch. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/validator-groups.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/pos/validator-groups.mdx deleted file mode 100644 index c5b49a87a2..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/pos/validator-groups.mdx +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "Validator Groups" -sidebarTitle: "Validator Groups" -og:description: Celo's proof-of-stake mechanism introduces the concept of Validator Groups as intermediaries between voters and validators. ---- - -Celo's proof-of-stake mechanism introduces the concept of **Validator Groups** as intermediaries between voters and validators. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## What is a Validator Group? - -A validator group has **members**, an ordered list of candidate validators. There is a fixed limit to the number of members that a group may have. - -## Why use a Validator Group? - -Validator groups can help mitigate the information disparity between voters and validators. It is anticipated that groups might emerge that do not necessarily operate validators themselves but attract votes for their reputation for ensuring their associated validators have known real-world identities, have high uptime, are well maintained and regularly audited. Since every validator needs to be accepted by a single group to stand for election, that group will be more able to build up long-term judgements on their validators’ operational practices and security setups than each of the numerous CELO holders that might vote for it would. - -## Fielding Multiple Validators - -Equally, a number of organizations may want to attempt to field multiple validators under their own control, or be able to interchange the specific machines or keys under which they validate in the case of hardware or connectivity failure. By switching out validators in the list, groups can accomplish this without users having to change their votes. - -## Validator Group Limits - -Validator groups can have no more than a small, fixed maximum number of validators -- currently 5 in Mainnet. This means an organization wanting to get more validators elected than this maximum has the added challenge of managing multiple group identities and reputations simultaneously. This further promotes decentralization and strengthens operational security, making it more likely that the validator set will be composed of nodes operated in different fashions by independent individuals and organizations. - -## Registration - -Any account that has at least the minimum stake requirement in Locked Gold, whether voting or non-voting, can register an empty validator group. If a validating key is specified it may be used for this registration. - -## Deregistration - -The account that creates a validator group is able to deregister that group if it has no members. - -While an account has a registered validator group, or for up to a `deregistrationPeriod` after it is deregistered, attempts to `unlock` the account's amount of Locked Gold will fail if they would cause the remaining amount to fall below the minimum stake requirement. - -## Group Share - -Validator groups are compensated by taking a share (the 'Group Share') of the [validator rewards](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-validator) from any of its member validators that are elected during an epoch. This value is set at registration time and can be changed later. - -## Changing Group Members - -The account owner controls the list of validators in their group and can at any time add, remove, or re-order validators. - -For a validator to be added to a group, several conditions must hold: the number of members in the group must be less than the maximum; the Locked Gold balance of the group's account must be sufficient (the stake is per-member validator); and the validator must first have set its affiliation to the group. - -This means that while a group can unilaterally remove a validator, and a validator can unilaterally leave by changing its affiliation, both parties have to agree before a validator can become a member of a group. - -## Votes and Voting Cap - -Validator Groups can receive votes from Locked Gold up to a [voting cap](/what-is-celo/about-celo-l1/protocol/pos/validator-elections#group-voting-caps). This value is set to be the number of votes that would be needed to elect all of its validators, plus one more validator. The cap is enforced at the point of voting: a user can only cast a vote for a group if it currently has fewer votes than this cap. - -## Slashing Penalty - -A [slashing penalty](/what-is-celo/about-celo-l1/protocol/pos/penalties), initially `1.0`, is also tracked for each validator group. This value may be reduced as a penalty for misbehavior of the validator in the group. It affects the future rewards of the group, its validators, and Locked Gold holders receiving rewards for voting for the group. - -## Metadata - -Both validators and validator groups can use [Accounts Metadata](/legacy/protocol/identity/metadata) to provide unverified metadata (such as name and organizational affiliation) as well as claims that can be verified off-chain for control of third-party accounts. All validators are encouraged to make a verifiable claim for [domain names](/what-is-celo/about-celo-l1/validator/validator-explorer). - -## Dissolving of a Validator Group - -There is a 180 day unlocking period for Celo locked when creating a validator group. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/randomness.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/randomness.mdx deleted file mode 100644 index 491465aaee..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/randomness.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Randomness" -sidebarTitle: "Celo Randomness" -og:description: How unpredictable pseudo-randomness is achieved on the Celo blockchain. ---- - -How unpredictable pseudo-randomness is achieved on the Celo blockchain and offered as a service for dapp developers. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Producing Pseudo-randomness - -Producing unpredictable pseudo-randomness without a trusted third party is not trivial. Several solutions for this problem exist or are being currently researched. They include Verifiable Random Functions \(for example, based on BLS threshold signatures\), Verifiable Delay Functions, and commit-reveal schemes. - -Currently, Celo implements a simple [RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness#the-randao) commit-reveal scheme which is secure enough for many uses, offering validators only 1 bit of influence: a validator can affect randomness only by choosing _not to propose_ a block, which results in the next validator revealing their pre-commited randomness. A more sophisticated solution might be implemented as the network evolves, especially if randomness becomes necessary for other purposes that require stronger assumptions about the randomness’s security \(for example if it was decided that a randomized leader election algorithm should replace the current round robin\). - -In a proposed block, the proposer attaches two values related to the randomness scheme - randomness corresponding to their previous commitment, and a new commitment to freshly generated random bytes that will be revealed in the future. The revealed randomness is added to an entropy pool accessible on-chain from the Random smart contract. - -## Randomness Equation - -More formally, the $$n * {th} $$ block proposed by a given validator contains values $$(r_n, s_n)$$ such that $$\text{keccack256}(r_n) = s*{n-1}$$. The one exception to this is the validator’s first block, the case where $$n = 1$$, since they have not previously committed to randomness yet. Here, the protocol instead requires that $$r_1 = 1$$. - -## Using Onchain Randomness - -This randomness can be used by any smart contracts deployed to a Celo network using the Random core contract, e.g.: - -```solidity -import "celo-monorepo/packages/protocol/identity/interfaces/IRandom.sol"; -import "celo-monorepo/packages/protocol/common/interfaces/IRegistry.sol"; - -contract Example { - function test() external view returns (bytes32 randomness) { - randomness = IRandom( - IRegistry(0x000000000000000000000000000000000000ce10) - .getAddressFor(keccak256(abi.encodePacked("Random"))) - ).random(); - } -} -``` - -Alternatively, through inheritance of [UsingRegistry](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/UsingRegistry.sol). - -```solidity -import "celo-monorepo/packages/protocol/common/UsingRegistryV2.sol"; - -contract Example is UsingRegistryV2 { - function test() external view returns (bytes32 randomness) { - randomness = getRandom().random(); - } -} -``` \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/adding-stable-assets.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/stability/adding-stable-assets.mdx deleted file mode 100644 index f6b9dc2340..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/adding-stable-assets.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: "Add Stable Assets" -sidebarTitle: "Add Stable Assets to Celo" -og:description: Overview of the requirements and steps to add a new stable asset to the Celo platform. ---- - -Overview of the requirements and steps to add a new stable asset to the Celo platform. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - - -**Note** - -This example assumes we want to add to the platform a new stable asset `cX` tracking the value of X (where X can be a fiat currency like ARS or MXN), using the [Mento exchange](/what-is-celo/about-celo-l1/protocol/stability/doto). - - -## Requirements - -**Liquidity** - -The asset X has to be liquidly traded against CELO, in a CELO/X ticker. In absence of that, X has to be liquidly traded, including weekends, against well known assets that trade 24/7, like BTC or ETH, such that the price of X with respect to Celo can be inferred. In this second case, an implicit pair can be calculated for the oracle reports. - -**Determine pre-mint addresses and amounts** - -It is possible to pre-mint a fixed amount at the time of launching a new stable asset, good candidates to receive the pre-mint are the community fund and other entities commited to distribute this initial allocation to grant recipients and liquidity providers. - - -A good criteria to a successfully decide a pre-mint amount is to check by how much it would affect the reserve collateralization ratio, this is, the ratio of all stable assets, divided by all the reserve holdings. Reserve information, as well as the collateralization ration can be found on the [Reserve website](https://reserve.mento.org/). - - -## Procedure - -### Including contracts on the registry - -Currently, the addition of new assets is tied to the [Contract Release Cycle](/what-is-celo/joining-celo/contributors/release-process/smart-contracts), as the contracts `ExchangeX` and `StableTokenX` need to be checked in [^1]. These new contracts inherit from Exchange and StableToken, that are the ones originally used for `cUSD`. As StableToken `cX` will be initialized by the contract release, key parameters like `spread` and `reserveFraction` should be included, although they can be later modified by setters in the following governance proposals. The only value that can't be changed is the pre-mint amount. - -### Freezing - -These contracts should be set as frozen to prevent `cX` from being transferable before Mento supports it in a governance proposal. At this point, as there are no oracles, the contract `ExchangeX` can't update buckets and it is thus impossible to mint and burn `cX`. There is [an issue open](https://github.com/celo-org/celo-monorepo/issues/7331) to include this step as part of the Contract Release. - -For the [deployment of cEUR](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0033.md), this was included as part of the [Oracle activation](#oracle-activation) proposal. - -### Constitutional parameters - - {/* TODO: SDK urls will need to be changed when the SDK type docs are separated from the rest of docs */} - -As new contracts are added to the registry, new **constitution parameters** need to be set. There's an [issue open](https://forum.celo.org/t/governance-proposals-for-march-2021/816) to include this in the tooling to support it as part of the Contract Release. - -### Oracle activation - -A following governance proposal needs to be submitted to enable [oracles](/what-is-celo/about-celo-l1/protocol/stability/oracles) to report. This oracle proposal needs to enable addresses to report to the `StableTokenX` address and, optionally, fund them to pay for gas fees. An example of this proposal is the [cEUR oracle activation proposal](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0033.md)[^2]. - -### Full activation - -The last governance proposal is expected to unfreeze the contract and attach the last strings in the process to get a fully transferable asset stabilized by the Reserve. This propose involves: - -1. Unfreezing both `StableTokenX` & `ExchangeX`. -2. Making `ExchangeX` able to pull CELO out of the Reserve for the buckets `Reserve.addExchangeSpender` -3. Declaring the token to the Reserve as an asset to be stabilized calling `Reserve.addToken` -4. Enable `StableTokenX` as a fee currency, so that it can be used to pay for gas `FeeCurrencyWhitelist.addToken`. -5. In case necessary, parameters such as `reserveFraction` and `spread` can also be updated in this governance proposal. -6. Granda Mento activation - -After passing this last proposal, `cX` should be fully activated. - -## Tooling - -Adding a new stable asset involves updating many parts of the tooling, such as: - -- Update the Ledger app integration such that it displays the names of the newly added token. -- Update oracles and generating their keys and addresses. -- Adding support on `contractkit`. -- Adding support on [kliento](https://github.com/celo-org/kliento). -- Adding support on [eksportisto](https://github.com/celo-org/eksportisto). -- Update on the cli, an example list of things to add are included on [this issue](https://github.com/celo-org/celo-monorepo/issues/6793). -- Supporting on Dapp kit. - -[^1] There are opened issues trying to de-couple the addition of new assets to the reserve to the release cycle. - - -[^2] Please note this example proposal also includes freezing, this is because, at the time of writing (22-march-2021), the tooling for proposing a contract release doesn't support freezing those contracts on the same proposal. Proposals shall not be modified manually given that the tool is meant to run verifications. - \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/doto.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/stability/doto.mdx deleted file mode 100644 index c8f52a525b..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/doto.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Stability Algorithm (Mento)" -sidebarTitle: "Celo Stability Algorithm (Mento)" -og:description: How the supply of the Celo Dollar is achieved in the Celo protocol using the constant-product decentralized one-to-one mechanism (CP-DOTO). ---- - -How the supply of the Celo Dollar is achieved in the Celo protocol using the constant-product decentralized one-to-one mechanism. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## What is Mento? - -On a high level, Mento (previously known as CP-DOTO) allows user demand to determine the supply of celo stable assets by enabling users to create, for example, a new Celo Dollar by sending 1 US Dollar worth of CELO to the reserve, or to burn a Celo Dollar by redeeming it for 1 US Dollar worth of CELO. The mechanism requires an accurate [Oracle](./oracles) value of the CELO to US Dollar market rate to work. - -## Incentives - -This creates incentives such that when demand for the Celo Dollar rises and the market price is above the peg, users can profit using their own efforts by buying 1 US Dollar worth of CELO on the market, exchanging it with the protocol for one Celo Dollar, and selling that Celo Dollar for the market price. - -Similarly, when demand for the Celo Dollar falls and the market price is below the peg, users can profit using their own efforts by purchasing Celo Dollar at the market price, exchanging it with the protocol for 1 US Dollar worth of CELO, and selling the CELO to the market. - -## Mitigating Risk - -In cases in which the CELO to US Dollar oracle value is not an accurate reflection of the market price, exploiting such discrepancies can lead to a depletion of the reserve. Mento, inspired by the [Uniswap](https://uniswap.io/) system, mitigates this risk of depletion as follows: The Celo protocol maintains two virtual buckets of CELO and Celo Dollar. The amounts in these virtual buckets are recalibrated every time the reported oracle value is updated, provided the difference between the current time and the oracle timestamp is less than $$oracle\_staleness\_threshold$$. - -## Model Equations - -The equation for the constant-product-market-maker model fixes the product of the wallet quantities. - -$$ -G_t \times D_t = k -$$ - -where $$G_t$$ and $$D_t$$denote the quantities in the CELO and Celo Dollar buckets respectively and $$k$$ is some constant. Given the above rule, it can be shown that the price of CELO, to be paid in Celo Dollar units, is - -$ -P_t = \frac{D_t}{G_t} -$ - -for traded amounts that are small relative to the bucket quantities. - -## Oracle Rates - -Whenever the CELO to US Dollar oracle rate is updated, the protocol adjusts the bucket quantities such that they equalize the on-chain CELO to Celo Dollar exchange rate $$P_t$$ to the current oracle rate. During such a reset, the CELO bucket must remain smaller than the total reserve gold balance. To achieve this, the CELO bucket size is defined as the total reserve balance times $$gold\_bucket\_size$$, with $$0 < gold\_bucket\_size < 1$$ and the Celo Dollar bucket size is then chosen such that $$P_t$$ mirrors the oracle price. To discourage excessive on-chain trading, a transaction fee is imposed by adding small spread around the above exchange rate. - -If the oracle precisely mirrors the market rate, the on-chain CELO to Celo Dollar rate will equal the CELO to US Dollar market rate and no profit opportunity will exist as long as Celo Dollar precisely tracks the US Dollar. If the oracle price is imprecise, the two rates will differ, and a profit opportunity will be present even if Celo Dollar accurately tracks the US Dollar. However, as traders exploit this opportunity, the on-chain price $$P_t$$ will dynamically adjust in response to changes in the tank quantities until the opportunity ceases to exist. This limits the depletion potential in Mento in the case of imprecise or manipulated oracle rates. - - -For a more detailed explanation, read the article [Zooming in on the Celo Expansion & Contraction Mechanism](https://medium.com/celoorg/zooming-in-on-the-celo-expansion-contraction-mechanism-446ca7abe4f "Zooming in on the Celo Expansion & Contraction Mechanism"). - - -## Multi-mento Deployment - -Many instances of mento can be deployed in parallel for different stable assets. Currently, `cEUR` and `cUSD` live side-by-side, with independent buckets and oracle reports (although both of them are using the same `SortedOracles` instance). They all fill the CELO bucket with funds from the Reserve, but not necessarily at the same time. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/granda-mento.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/stability/granda-mento.mdx deleted file mode 100644 index 5e6f624678..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/granda-mento.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Granda Mento -og:description: Introduction to Granda Mento (CIP 38), its design, and how to manage exchange proposals. ---- - -Introduction to Granda Mento (CIP 38), its design, and how to manage exchange proposals. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## What is Granda Mento? - -Granda Mento, described in [CIP 38](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0038.md), is a mechanism for exchanging large amounts of CELO for Celo stable tokens that aren't suitable for [Mento](./doto) or over-the-counter (OTC). - -Mento has proven effective at maintaining the stability of Celo's stable tokens, but the intentionally limited liquidity of its constant-product market maker results in meaningful slippage when exchanging tens of thousands of tokens at a time. Slippage is the price movement experienced by a trade. Generally speaking, larger volume trades will incur more slippage and execute at a less favorable price for the trader. - -Similar to Mento, exchanges through Granda Mento are effectively made against the reserve. Purchased stable tokens are created into existence ("minted"), and sold stable tokens are destroyed ("burned"). Purchased CELO is taken from the reserve, and sold CELO is given to the reserve. For example, a sale of 50,000 CELO in exchange for 100,000 cUSD would involve the 50,000 CELO being transferred to the reserve and the 100,000 cUSD being created and given to the exchanger. - -At the time of writing, exchanging about 50,000 cUSD via Mento results in a slippage of about 2%. Without Granda Mento, all launched Celo stable tokens can only be minted and burned using Mento, with the exception of cUSD that is minted as validator rewards each epoch. Granda Mento was created to enable institutional-grade liquidity to mint or burn millions of stable tokens at a time. - -The Mainnet Granda Mento contract address is `0x03f6842B82DD2C9276931A17dd23D73C16454a49` ([link](https://celo.blockscout.com/address/0x03f6842B82DD2C9276931A17dd23D73C16454a49)), was introduced in [Contract Release 5](https://github.com/celo-org/governance/blob/main/CGPs/cgp-0037.md), and activated in [CGP 31](https://github.com/celo-org/governance/blob/main/CGPs/cgp-0031.md). - -## How it works - -A Granda Mento exchange requires rough consensus from the Celo community and, unlike the instant and atomic Mento exchanges, involves the exchanger locking their funds to be sold for multiple days before they are exchanged. - -### Design - -At a high level, the life of an exchange is: - -1. Exchanger creates an "exchange proposal" on-chain that locks their funds to be sold and calculates the amount of the asset being purchased according the current oracle price and a configurable spread. -2. If rough consensus from the community is achieved, a multi-sig (the "approver") that has been set by Governance approves the exchange proposal on-chain. -3. To reduce trust in the approver multi-sig, a veto period takes place where any community member can create a governance proposal to "veto" an approved exchange proposal. -4. After the veto period has elapsed, the exchange is executable by any account. The exchange occurs with the price locked in at stage (1). - -### Processes - -Processes surrounding Granda Mento exchanges, like how to achieve rough consensus from the community, are outlined in [CIP 46](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0046.md). At the minimum, it takes about 7 days to achieve rough consensus. - -The approver multi-sig that is ultimately responsible for approving an exchange proposal that has achieved rough consensus from the community is `0xf10011424A0F35B8411e9abcF120eCF067E4CF27` ([link](https://celo.blockscout.com/address/0xf10011424A0F35B8411e9abcF120eCF067E4CF27/transactions)) and has the following signers: - -| **Name** | **Affiliation** | **Discord Handle** | **Address** | -| --------------- | ----------------------------- | ------------------------- | -------------------------------------------- | -| Andrew Shen | Bi23 Labs | `Shen \| Bi23 Labs #6675` | `0xBecc041a5090cD08AbD3940ab338d4CC94d2Ed3c` | -| Pinotio | Pinotio | `Pinotio.com #5357` | `0x802FE32083fD341D8e9A35E3a351291d948a83E6` | -| Serge Kiema | DuniaPay | `serge_duniapay #5152` | `0xdcac99458a3c5957d8ae7b92e4bafc88a32b80e4` | -| Will Kraft | Celo Governance Working Group | `Will Kraft #2508` | `0x169E992b3c4BE08c42582DAb1DCFb2549d9C23E1` | -| Zviad Metreveli | WOTrust | `zm #1073` | `0xE267D978037B89db06C6a5FcF82fAd8297E290ff` | -| human | OpenCelo | `human #6811` | `0x91f2437f5C8e7A3879e14a75a7C5b4CccC76023a` | -| Deepak Nuli | Kresko | `Deepak \| Kresko#3647` | `0x099f3F5527671594351E30B48ca822cc90778a11` | \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/index.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/stability/index.mdx deleted file mode 100644 index a306beb336..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/index.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Stability Mechanism" -sidebarTitle: "Overview" -og:description: Overview of the Celo protocol's Stability Mechanisms. ---- - -import {YouTube} from '/snippets/YouTube.jsx'; -import {ColoredText} from "/snippets/ColoredText.jsx"; - - -Find updated information on Celo's Stability Protocol at [mento.org](https://mento.org). - - - -Overview of the Celo protocol's Stability Mechanisms. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Stability of Mento Stablecoin Protocol - - - -The Celo protocol's stability mechanism comprises the following: - -- [Stability Algorithm (Mento)](/what-is-celo/about-celo-l1/protocol/stability/doto) -- [Granda Mento](/what-is-celo/about-celo-l1/protocol/stability/granda-mento) -- [Oracles](/what-is-celo/about-celo-l1/protocol/stability/oracles) -- [Stability Fees](/what-is-celo/about-celo-l1/protocol/stability/stability-fees) -- [Adding Stable Tokens](/what-is-celo/about-celo-l1/protocol/stability/adding-stable-assets) \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/oracles.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/stability/oracles.mdx deleted file mode 100644 index 11bf7b2278..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/oracles.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Oracles -og:description: How the SortedOracles smart contract uses governance to collect reports and maintain the oraclized rate or the Celo dollar. ---- - -How the **SortedOracles** smart contract uses governance to collect reports and maintain the oraclized rate or the Celo dollar. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## SortedOracles Smart Contract - -As mentioned in the previous section, the stability mechanism needs to know the market price of CELO with respect to the US dollar. This value is made available on-chain in the [SortedOracles smart contract](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/stability/SortedOracles.sol). - -## Collecting Reports - -Through governance, a whitelist of reporters is selected. These addresses are allowed to make reports to the SortedOracles smart contract. The smart contract keeps a list of most recent reports from each reporter. To make it difficult for a dishonest reporter to manipulate the oraclized rate, the official value of the oracle is taken to be the _median_ of this list. - -## Maintaining Oracle Values - -To ensure the oracle's value doesn't go stale due to inactive reporters, any reports that are too old can be removed from the list. "Too old" here is defined based on a protocol parameter that can be modified via governance. - -## Celo-Oracle Repository - -You can find more information about the technical specification of the Celo Oracles feeding data to the reserve in the [GitHub repository here](https://github.com/celo-org/celo-oracle). \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/stability-fees.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/stability/stability-fees.mdx deleted file mode 100644 index e1e177c90b..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/stability/stability-fees.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Stability Fees" -sidebarTitle: "Celo Stability Fees" -og:description: Overview of stability fee parameters, timing, frequency, amounts, management, and updates. ---- - -Overview of stability fee parameters, timing, frequency, amounts, management, and updates. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -### Parameters Governing the Stability Fee - -`inflationPeriod` how long to wait between rounds of applying inflation - -`inflationRate` the multiplier by which the inflation factor is adjusted per `inflationPeriod` - -### Timing, Frequency, and Amount of Fee - -The `inflationRate` is the multiplier by which the `inflationFactor` is increased per `inflationPeriod`. It is initially set to `1` which leaves it to governance to enable the stability fee later on. - -Both, the `inflationRate` as well as the `inflationPeriod`, are specified for a given stable token and subject to changes based on governance decisions. - -### Stability Fee Levied on Balance - -Each account’s stable token balance is stored as ‘units’, and `inflationFactor` describes the units/value ratio. The Celo Dollar value of an account can therefore be computed as follows. - -`Account cUSD Value = Account cUSD Units / inflationFactor` - -When a transaction occurs, a modifier checks if the stability fee needs updating and, if so, the `inflationFactor` is updated. - -### Updates to the Inflation Factor - -To apply periodic inflation, the inflation factor must be updated at regular intervals. Every time an event triggering an `inflationFactor` update\(eg a transfer\) occurs, the `updateInflationFactor` modifier is called \(pseudocode below\), which does the following: - -1. Decide if on or more `inflationPeriod` have passed since the last time `inflationFactor` was updated -2. If so, find out how many have passed -3. Compute the new `inflationFactor` and update the last updated time: - -`inflationFactor` = `inflationFactor` \* `inflationRate` ^ `# inflationPeriods since last update` - -### Changes to Inflation Factor - -Desired inflation rates may vary over time. When a new rate needs to be set, a governance proposal is required to update the inflation rate. If successful, the above function is called, which ensures `inflationFactor` is up to date, then updates the `inflationRate` and `inflationPeriod` parameters. - -### Inflation Factor Update Schedule - -The `updateInflationFactor` modifier is called by the following functions: - -- `setInflationParameters` -- `approve` -- `mint` -- `transferWithComment` -- `burn` -- `transferFrom` -- `transfer` -- `debitFrom` \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/erc20-transaction-fees.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/erc20-transaction-fees.mdx deleted file mode 100644 index f5c21753c9..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/erc20-transaction-fees.mdx +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: "Introduction" -sidebarTitle: "Paying for Gas with Tokens" -og:description: How to pay gas fees using allowlisted ERC20 tokens on Celo. ---- - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - -In most L1 and L2 networks, transaction fees can only be paid with one asset, typically, the native asset for the ecosystem which is often volatile in nature. In order to simplify the process of sending funds on Celo, these fees can be paid with allowlisted ERC20 tokens such as USDT, USDC, cUSD, and others, in addition to CELO. This means that a user sending a stablecoin to friends or family will be able to pay the transaction fee out of their stablecoin balance, and will not need to hold a separate CELO balance in order to transact. Critically, Celo supports this functionality natively without Account Abstraction, Pay Masters, or Relay Services. Instead, wallets simply need to add an extra `feeCurrency` field on transaction objects to take advantage of this feature. - -## Fee Currency Field - -The protocol maintains a governable allowlist of smart contract addresses which can be used to pay for transaction fees. These smart contracts implement an extension of the ERC20 interface, with additional functions that allow the protocol to debit and credit transaction fees. When creating a transaction, users can specify the address of the currency they would like to use to pay for gas via the `feeCurrency` field. Leaving this field empty will result in the native currency, CELO, being used. Note that transactions that specify non-CELO gas currencies will cost approximately 50k additional gas. - -## Allowlisted Gas Fee Addresses - -To obtain a list of the gas fee addresses that have been allowlisted using [Celo's Governance Process](/what-is-celo/using-celo/protocol/governance/overview), you can run the `getCurrencies` method on the `FeeCurrencyDirectory` contract. All other notable Mainnet core smart contracts are listed [here](/contracts/core-contracts#celo-mainnet). - -### Tokens with Adapters - -After Contract Release 11, addresses in the allowlist are no longer guaranteed to be full ERC20 tokens and can now also be [adapters](https://github.com/celo-org/celo-monorepo/blob/release/core-contracts/11/packages/protocol/contracts-0.8/stability/FeeCurrencyAdapter.sol). Adapters are allowlisted in-lieu of tokens in the scenario that a ERC20 token has decimals other than 18 (e.g. USDT and USDC). - -The Celo Blockchain natively works with 18 decimals when calculating gas pricing, so adapters are needed to normalize the decimals for tokens that use a different one. Some stablecoins use 6 decimals as a standard. - -Transactions with those ERC20 tokens are performed as usual (using the token address), but when paying gas currency with those ERC20 tokens, the adapter address should be used. This adapter address is also the one that should be used when querying [Gas Price Minimum](/what-is-celo/about-celo-l1/protocol/transaction/gas-pricing). - -Adapters can also be used to query `balanceOf(address)` of an account, but it will return the balance as if the token had 18 decimals and not the native ones. This is useful to calculate if an account has enough balance to cover gas after multiplying `gasPrice * estimatedGas` without having to convert back to the token's native decimals. - -#### Adapters by network - -##### Mainnet - -| Name | Token | Adapter | -| ------ | --------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | -| `USDC` | [`0xcebA9300f2b948710d2653dD7B07f33A8B32118C`](https://celoscan.io/address/0xcebA9300f2b948710d2653dD7B07f33A8B32118C#code) | [`0x2F25deB3848C207fc8E0c34035B3Ba7fC157602B`](https://celoscan.io/address/0x2F25deB3848C207fc8E0c34035B3Ba7fC157602B#code) | -| `USDT` | [`0x48065fbbe25f71c9282ddf5e1cd6d6a887483d5e`](https://celoscan.io/address/0x48065fbbe25f71c9282ddf5e1cd6d6a887483d5e#code) | [`0x0e2a3e05bc9a16f5292a6170456a710cb89c6f72`](https://celoscan.io/address/0x0e2a3e05bc9a16f5292a6170456a710cb89c6f72#code) | - -##### Alfajores (testnet) - -| Name | Token | Adapter | -| ------ | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | -| `USDC` | [`0x2F25deB3848C207fc8E0c34035B3Ba7fC157602B`](https://alfajores.celoscan.io/address/0x2f25deb3848c207fc8e0c34035b3ba7fc157602b#code) | [`0x4822e58de6f5e485eF90df51C41CE01721331dC0`](https://alfajores.celoscan.io/address/0x4822e58de6f5e485eF90df51C41CE01721331dC0#code) | - -##### Baklava (testnet) - -N/A - -### Enabling Transactions with ERC20 Token as fee currency in a wallet - -We recommend using the [viem](https://viem.sh/) library as it has support for the `feeCurrency` field in the transaction required for sending transactions where the gas fees will be paid in ERC20 tokens. Ethers.js and web.js currently don't support `feeCurrency`. - -#### Estimating gas price - -To estimate gas price use the token address (in case of cUSD, cEUR and cREAL) or the adapter address (in case of USDC and USDT) as the value for `feeCurrency` field in the transaction. - - -The Gas Price Minimum value returned from the RPC has to be interpreted in 18 decimals. - - -#### Preparing a transaction - -When preparing a transaction that uses ERC20 token for gas fees, use the token address (in case of cUSD, cEUR and cREAL) or the adapter address (in case of USDC and USDT) as the value for `feeCurrency` field in the transaction. - -The recommended transaction `type` is `123`, which is a CIP-64 compliant transaction read more about it [here](/what-is-celo/about-celo-l1/protocol/transaction/transaction-types). - -Here is how a transaction would look like when using USDC as a medium to pay for gas fees. - -```js -let tx = { - // ... other transaction fields - feeCurrency: "0x2f25deb3848c207fc8e0c34035b3ba7fc157602b", // USDC Adapter address - type: "0x7b", -}; -``` - - -To get details about the underlying token of the adapter you can call `adaptedToken` function on the adapter address, which will return the underlying token address. - \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/escrow.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/escrow.mdx deleted file mode 100644 index 43f6251457..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/escrow.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Escrow" -sidebarTitle: "Celo's Escrow Contract" -og:description: Introduction to the Celo Escrow contract and how to use it to withdraw, revoke, and reclaim funds. ---- - -Introduction to the Celo Escrow contract and how to use it to withdraw, revoke, and reclaim funds. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## What is the Escrow Contract? - -The `Escrow` contract utilizes Celo’s Lightweight identity feature to allow users to _send payments to other users who don’t yet have a public/private key pair or an address_. These payments are stored in this contract itself and can be either withdrawn by the intended recipient or reclaimed by the sender. This functionality supports _both_ versions of Celo’s lightweight identity: identifier-based \(such as a phone number to address mapping\) and privacy-based. This gives applications that intend to use this contract some flexibility in deciding which version of identity they prefer to use. - -## How it works - -If Alice wants to send a payment to Bob, who doesn’t yet have an associated address, she will send that payment to this `Escrow` contract and will also create a temporary public/private key pair. The associated temporary address will be referred to as the `paymentId`. Alice will then externally share the newly created temporary private key, also known as an _invitation_, to Bob, who will later use it to claim the payment. This paymentId will now be stored in this contract and will be mapped to relevant details related to this specific payment such as: the value of the payment, an optional identifier of the intended recipient, an optional amount of `attestations` the recipient must have before being able to withdraw the payment, an amount of time after which the sender can revoke the payment \(via the `expirySeconds` field - more on that in the “withdrawing” section below\), which asset is being transferred in this payment, etc. - -## Withdrawing - -The recipient of an escrowed payment can choose to withdraw their payment assuming they have successfully created their own public/private key pair and now have an address. To prove their identity, the recipient must be able to prove ownership of the paymentId’s private key, which should have been given to them by the original sender. If the sender set a minimum number of attestations required to withdraw the payment, that will also be checked in order to successfully withdraw. Following the same example as above, if Bob wants to withdraw the payment Alice sent him, he must sign a message with the private key given to him by Alice. The message will be the address of Bob’s newly created account. Bob will then be able to withdraw his payment by providing the paymentId and the v, r, and s outputs of the generated ECDSA signature. An escrowed payment may have `expirySeconds` set, which references the amount of time that must pass before the sender can revoke the payment. Note that after `expirySeconds` have passed, the payment recipient may _still withdraw the payment as long as it has not already been revoked_. - -## Revoking & Reclaiming - -Alice sends Bob an escrowed payment. Let’s say Bob never withdraws it, or worse, the temporary private key he needs to withdraw the payment gets lost or sent to the wrong person. For this purpose, Celo’s protocol also allows for senders to reclaim any unclaimed escrowed payment that they sent. After an escrowed payment's `expirySeconds` \(set by the sender on creation of the payment\) has passed, the sender of the payment can revoke the payment and reclaim their funds with just the paymentId. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/gas-pricing.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/gas-pricing.mdx deleted file mode 100644 index 48812b10e5..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/gas-pricing.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Gas Pricing" -sidebarTitle: "Celo Gas Pricing" -og:description: Introduction to gas prices, calculations, transactions, and fees on the Celo network. ---- - -Introduction to gas prices, calculations, transactions, and fees on the Celo network. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Gas Price Minimum - -Celo uses a gas market based on [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). The protocol establishes a **gas price minimum** that applies to all transactions regardless of which validator processes them. - -The gas price minimum will respond to demand, increasing during periods of sustained demand, but allowing temporary spikes in gas demand without price shocks. The Celo protocol aims to have blocks filled at the `target_density`, a certain proportion of the total block gas limit. When blocks are being filled more than the target, the gas price minimum will be raised until demand subsides. If blocks are being filled at less than the target rate, the gas price minimum will decrease until demand rises. - -## Calculating Gas Price - -In the Celo protocol, the gas price minimum for the next block is calculated based on the current block: - -``` -gas_price_minimum' = gas_price_minimum * (1 + ((total_gas_used / block_gas_limit) − target_density) * adjustment_speed) + 1 -``` - -Every transaction is required to pay for gas at or above the gas price minimum in order to be processed. Full nodes will reject transactions whose gas price is below the current gas price minimum, and will discard outstanding transactions if the gas price minimum subsequently falls below the gas price that the transactions specify. - -## Selecting a Transaction Gas Price - -This approach provides a simple mechanism for clients to determine what gas price they should pay. A `GasPriceMinimum` smart contract provides access to the current gas price minimum. For example, with the parameters specified for the Celo testnets, a gas price of 3x the current gas price minimum will be valid in all scenarios for the following 30 seconds. - -When the client wants to ensure that their transaction is processed quickly, they may wish to further increase the gas price to encourage validators proposing new blocks to include it in preference to other transactions. - -## Transaction Fee Recipients - -The required portion of gas fee, known as the **base**, is set as `base = gas_price_minimum * gas_used` and is sent to the Gas Fee Handler smart contract, which is controlled by governance and handles how the fees are used (e.g., for carbon removal and burning). The rest of the gas fee, known as the **tip**, is rewarded to the validator that proposes the block. Block producers only receive the tip and not the base of the gas fee, which means that they do not have an incentive to artificially inflate the gas price minimum by flooding the network with transactions. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/index.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/index.mdx deleted file mode 100644 index c6b1cf8bff..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/index.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Transactions" -sidebarTitle: "Overview" -og:description: Introduction to Celo transactions and gas prices. ---- - -Introduction to Celo transactions and gas prices. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Celo vs Ethereum Transactions - -Transactions in the Celo protocol include payments, contract calls, and other operation which modifies state. They are similar to Ethereum transaction with the following key differences. - -- Gas prices must meet or exceed the [gas price minimum](/what-is-celo/about-celo-l1/protocol/transaction/gas-pricing). -- Gas fees may be paid in currencies other than the native CELO. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/native-currency.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/native-currency.mdx deleted file mode 100644 index c1c15aa603..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/native-currency.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Native Currency" -sidebarTitle: "Celo Native Currency" -og:description: Introduction to CELO and its compliance to the ERC20 standard. ---- - -Introduction to CELO and its compliance to the ERC20 standard. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## What is CELO? - -The native currency in the Celo protocol, CELO, conforms to the ERC20 interface. This is made possible by way of a permissioned “Transfer” precompile, which only the CELO ERC20 smart contract can call. The address of the contract exposing this interface can be looked up via the Registry smart contract, and has the “GoldToken” identifier. - - -**note** - -As the native currency of the protocol, CELO, much like Ether, can still be sent directly via transactions by specifying a non-zero “value”, bypassing the ERC20 interface. - \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/transaction-types.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/transaction-types.mdx deleted file mode 100644 index 1d1ed75857..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/transaction-types.mdx +++ /dev/null @@ -1,469 +0,0 @@ ---- -title: Transaction types on Celo -og:description: This page contains an explainer on transaction types supported on Celo and a demo to make specific transactions. ---- - -This page contains an explainer on transaction types supported on Celo and a demo to make specific transactions. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - -> **IMPORTANT** -> This repo is for educational purposes only. The information provided here may be inaccurate. -> Please don’t rely on it exclusively to implement low-level client libraries. - -## Summary - -Celo has support for all Ethereum transaction types (i.e. "100% Ethereum compatibility") -and a single Celo transaction type. - -### Actively supported on Celo - -| Chain | Transaction type | # | Specification | Recommended | Support | Comment | -| ----------------------------------------------------------------------- | -------------------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | --------- | -------------------------------------------------------- | -| | Dynamic fee transaction v2 | `123` | [CIP-64](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0064.md) | ✅ | Active 🟢 | Supports paying gas in custom fee currencies | -| | Dynamic fee transaction | `2` | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) ([CIP-42](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0042.md)) | ✅ | Active 🟢 | Typical Ethereum transaction | -| | Access list transaction | `1` | [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) ([CIP-35](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0035.md)) | ❌ | Active 🟢 | Does not support dynamically changing _base fee_ per gas | -| | Legacy transaction | `0` | [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) ([CIP-35](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0035.md)) | ❌ | Active 🟢 | Does not support dynamically changing _base fee_ per gas | - -### Scheduled for deprecation on Celo - -| Chain | Transaction type | # | Specification | Recommended | Support | Comment | -| ------------------------------------------------------------------- | ----------------------- | ----- | -------------------------------------------------------------------------------------------------------------- | ----------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| | Dynamic fee transaction | `124` | [CIP-42](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0042.md) | ❌ | Security 🟠 | Deprecation warning published in [Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md#deprecation-warning) | -| | Legacy transaction | `0` | Celo Mainnet launch ([Blockchain client v1.0.0](https://github.com/celo-org/celo-blockchain/tree/celo-v1.0.0)) | ❌ | Security 🟠 | Deprecation warning published in [Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md#deprecation-warning) | - -The stages of support are: - -- **Active support** 🟢: the transaction type is supported and recommended for use. -- **Security support** 🟠: the transaction type is supported but not recommended for use - because it might be deprecated in the future. -- **Deprecated** 🔴: the transaction type is not supported and not recommended for use. - -### Client library support - -Legend: - -- = - support for the recommended Ethereum transaction type (`2`) -- = support - for the recommended Celo transaction type (`123`) -- ✅ = available -- ❌ = not available - -| Client library | Language | | since | | since | Comment | -| --------------------- | :------: | :---------------------------------------------------------------------: | :---: | :------------------------------------------------------------------ | --------------------------------------------------------------------------- | ------------------------------------------------ | -| `viem` | TS/JS | ✅ | | ✅ | >[1.19.5][1] | --- | -| `ethers` | TS/JS | ✅ | | ❌ | | Support via fork in
`celo-ethers-wrapper` | -| `celo-ethers-wrapper` | TS/JS | ✅ | | ✅ | >[2.0.0](https://github.com/jmrossy/celo-ethers-wrapper/releases/tag/2.0.0) | --- | -| `web3js` | TS/JS | ✅ | | ❌ | | Support via fork in
`contractkit` | -| `contractkit` | TS/JS | ✅ | | ✅ | >[5.0.0](https://github.com/celo-org/celo-monorepo/releases/tag/v5.0) | --- | -| `Web3j` | Java | ✅ | | ❌ | | --- | -| `rust-ethers` | Rust | ✅ | | ❌ | | --- | -| `brownie` | Python | ✅ | | ❌ | | --- | - -[1]: https://github.com/wevm/viem/blob/main/src/CHANGELOG.md#1195 - -## Background - -### Legacy transactions - -Ethereum originally had one format for transactions (now called "legacy transactions"). -A legacy transaction contains the following transaction parameters: -`nonce`, `gasPrice`, `gasLimit`, `recipient`, `amount`, `data`, and `chaindId`. - -To produce a valid "legacy transaction": - -1. the **transaction parameters** are [RLP-encoded](https://eth.wiki/fundamentals/rlp): - - ``` - RLP([nonce, gasprice, gaslimit, recipient, amount, data, chaindId, 0, 0]) - ``` - -1. the RLP-encoded transaction is hashed (using Keccak256). - -1. the hash is signed with a private key using the ECDSA algorithm, which generates the `v`, `r`, - and `s` **signature parameters**. - -1. the transaction _and_ signature parameters above are RLP-encoded to produce a valid **signed - transaction**: - - ``` - RLP([nonce, gasprice, gaslimit, recipient, amount, data, v, r, s]) - ``` - -A valid signed transaction can then be submitted on-chain, and its raw parameters can be -parsed by RLP-decoding the transaction. - -### Typed transactions - -Over time, the Ethereum community has sought to add new types of transactions -such as dynamic fee transactions -([EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559)) -or optional access list transactions -([EIP-2930: Optional access lists](https://eips.ethereum.org/EIPS/eip-2930)) -to supported new desired behaviors on the network. - -To allow new transactions to be supported without breaking support with the -legacy transaction format, the concept of **typed transactions** was proposed in -[EIP-2718: Typed Transaction Envelope](https://eips.ethereum.org/EIPS/eip-2718), which introduces -a new high-level transaction format that is used to implement all future transaction types. - -### Distinguishing between legacy and typed transactions - -Whereas a valid "legacy transaction" is simply an RLP-encoded list of -**transaction parameters**, a valid "typed transactions" is an arbitrary byte array -prepended with a **transaction type**, where: - -- a **transaction type**, is a number between 0 (`0x00`) and 127 (`0x7f`) representing - the type of the transaction, and - -- a **transaction payload**, is arbitrary byte data that encodes raw transaction parameters - in compliance with the specified transaction type. - -To distinguish between legacy transactions and typed transactions at the client level, -the EIP designers observed that the **first byte** of a legacy transaction would never be in the range -`[0, 0x7f]` (or `[0, 127]`), and instead always be in the range `[0xc0, 0xfe]` (or `[192, 254]`). - -With that observation, transactions can be decoded with the following heuristic: - -- read the first byte of a transaction -- if it's bigger than `0x7f` (`127`), then it's a **legacy transaction**. To decode it, you - must read _all_ bytes (including the first byte just read) and interpret them as a - legacy transaction. -- else, if it's smaller or equal to `0x7f` (`127`), then it's a **typed transaction**. To decode - it you must read the _remaining_ bytes (excluding the first byte just read) and interpret them - according to the specified transaction type. - -Every transaction type is defined in an EIP, which specifies how to _encode_ as well as _decode_ -transaction payloads. This means that a typed transaction can only be interpreted with knowledge of -its transaction type and a relevant decoder. - -## List of transaction types on Celo - -### Legacy transaction (`0`) - -> **NOTE** -> This transaction type is 100% compatible with Ethereum and has no Celo-specific parameters. - -Although legacy transactions are never formally prepended with the `0x00` transaction type, -they are commonly referred to as "type 0" transactions. - -- This transaction is defined as follows: - - ``` - RLP([nonce, gasprice, gaslimit, recipient, amount, data, v, r, s]) - ``` - -- It was introduced on Ethereum during Mainnet launch on [Jul 30, 2015](https://en.wikipedia.org/wiki/Ethereum) - as specified in the [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf). - -- It was introduced on Celo during the - [Celo Donut hard fork](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0027.md) - on [May 19, 2021](https://blog.celo.org/donut-hardfork-is-live-on-celo-585e2e294dcb) - as specified in [CIP-35: Support for Ethereum-compatible transactions](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0035.md). - -### Access list transaction (`1`) - -> **NOTE** -> This transaction type is 100% compatible with Ethereum and has no Celo-specific parameters. - -- This transaction is defined as follows: - - ``` - 0x01 || RLP([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS]) - ``` - -- It was introduced on Ethereum during the Ethereum Berlin hard fork on - [Apr, 15 2021](https://ethereum.org/en/history/#berlin) as specified in - [EIP-2930: Optional access lists](https://eips.ethereum.org/EIPS/eip-2930). - -- It was introduced on Celo during the - [Celo Donut hard fork](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0027.md) - on [May 19, 2021](https://blog.celo.org/donut-hardfork-is-live-on-celo-585e2e294dcb) - as specified in [CIP-35: Support for Ethereum-compatible transactions](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0035.md). - -### Dynamic fee transaction (`2`) - -> **NOTE** -> This transaction type is 100% compatible with Ethereum and has no Celo-specific parameters. - -- This transaction is defined as follows: - - ``` - 0x02 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS]) - ``` - -- It was introduced on Ethereum during the Ethereum London hard fork on - [Aug, 5 2021](https://ethereum.org/en/history/#london) as specified in - [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559). - -- It was introduced on Celo during the - [Celo Espresso hard fork](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0041.md) - on [Mar 8, 2022](https://blog.celo.org/brewing-the-espresso-hardfork-92a696af1a17) as specified - in [CIP-42: Modification to EIP-1559](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0042.md) - -### Legacy transaction (`0`) - -> **NOTE** -> This transaction is not compatible with Ethereum and has three Celo-specific -> parameters: `feecurrency`, `gatewayfeerecipient`, and `gatewayfee`. - -> **Warning** -> This transaction type is scheduled for deprecation. A deprecation warning was published in the -> [Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md#deprecation-warning) -> on [Sep 26, 2023](https://forum.celo.org/t/mainnet-alfajores-gingerbread-hard-fork-release-sep-26-17-00-utc/6499). - -- This transaction is defined as follows: - - ``` - RLP([nonce, gasprice, gaslimit, feecurrency, gatewayfeerecipient, gatewayfee, recipient, amount, data, v, r, s]) - ``` - -- It was introduced on Celo during Mainnet launch on - [Apr 22, 2020](https://dune.com/queries/3106924/5185945) as specified in - [Blockchain client v1.0.0](https://github.com/celo-org/celo-blockchain/tree/celo-v1.0.0). - -### Dynamic fee transaction (`124`) - -> **NOTE** -> This transaction is not compatible with Ethereum and has three Celo-specific -> parameters: `feecurrency`, `gatewayfeerecipient`, and `gatewayfee`. - -> **Warning** -> This transaction type is scheduled for deprecation. A deprecation warning was published in the -> [Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md#deprecation-warning) -> on [Sep 26, 2023](https://forum.celo.org/t/mainnet-alfajores-gingerbread-hard-fork-release-sep-26-17-00-utc/6499). - -- This transaction is defined as follows: - - ``` - 0x7c || RLP([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, feecurrency, gatewayfeerecipient, gatewayfee, destination, amount, data, access_list, v, r, s]) - ``` - -- It was introduced on Celo during the - [Celo Espresso hard fork](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0041.md) - on [Mar 8, 2022](https://blog.celo.org/brewing-the-espresso-hardfork-92a696af1a17) as specified - in [CIP-42: Modification to EIP-1559](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0042.md). - -### Dynamic fee transaction v2 (`123`) - -> **NOTE** -> This transaction is not compatible with Ethereum and has one Celo-specific -> parameter: `feecurrency`. - -- This transaction is defined as follows: - - ``` - 0x7b || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, feeCurrency, v, r, s]) - ``` - -- It was introduced on Celo during the - [Celo Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md) - on [Sep 26, 2023](https://forum.celo.org/t/mainnet-alfajores-gingerbread-hard-fork-release-sep-26-17-00-utc/6499) - as specified in - [CIP-64: New Transaction Type: Celo Dynamic Fee v2](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0064.md) - -## How to Send Transactions - -### Import Dependencies - - - - - -```ts -import { - createPublicClient, - createWalletClient, - hexToBigInt, - http, - parseEther, - parseGwei, -} from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { celoAlfajores } from "viem/chains"; -import "dotenv/config"; // use to read private key from environment variable -``` - - - - - -### Create Public and Wallet Client - - - - - -```ts -const PRIVATE_KEY = process.env.PRIVATE_KEY; - -/** - * Boilerplate to create a viem client - */ -const account = privateKeyToAccount(`0x${PRIVATE_KEY}`); -const publicClient = createPublicClient({ - chain: celoAlfajores, - transport: http(), -}); -const walletClient = createWalletClient({ - chain: celoAlfajores, // Celo testnet - transport: http(), -}); -``` - - - - - -### Function to print Transaction receipt - - - - - - ```ts - function printFormattedTransactionReceipt(transactionReceipt: any) { - - const { - blockHash, - blockNumber, - contractAddress, - cumulativeGasUsed, - effectiveGasPrice, - from, - gasUsed, - logs, - logsBloom, - status, - to, - transactionHash, - transactionIndex, - type, - feeCurrency, - gatewayFee, - gatewayFeeRecipient - } = transactionReceipt; - - const filteredTransactionReceipt = { - type, - status, - transactionHash, - from, - to - }; - - console.log(`Transaction details:`, filteredTransactionReceipt, `\n`); - } - ``` - - - - - -### Code to send Transaction Type (0) - - - - - - ```ts - /** - - Transation type: 0 (0x00) - - Name: "Legacy" - - Description: Ethereum legacy transaction - */ - async function demoLegacyTransactionType() { - console.log(`Initiating legacy transaction...`); - const transactionHash = await walletClient.sendTransaction({ - account, // Sender - to: "0x70997970c51812dc3a010c7d01b50e0d17dc79c8", // Recipient (illustrative address) - value: parseEther("0.01"), // 0.01 CELO - gasPrice: parseGwei("20"), // Special field for legacy transaction type - }); - - const transactionReceipt = await publicClient.waitForTransactionReceipt({ - hash: await transactionHash, - }); - - printFormattedTransactionReceipt(transactionReceipt); - } - ``` - - - - - -### Code to send Transaction Type (2) - - - - - - ```ts - /** - * Transaction type: 2 (0x02) - * Name: "Dynamic fee" - * Description: Ethereum EIP-1559 transaction - */ - async function demoDynamicFeeTransactionType() { - console.log(`Initiating dynamic fee (EIP-1559) transaction...`); - const transactionHash = await walletClient.sendTransaction({ - account, // Sender - to: "0x70997970c51812dc3a010c7d01b50e0d17dc79c8", // Recipient (illustrative address) - value: parseEther("0.01"), // 0.01 CELO - maxFeePerGas: parseGwei("10"), // Special field for dynamic fee transaction type (EIP-1559) - maxPriorityFeePerGas: parseGwei("10"), // Special field for dynamic fee transaction type (EIP-1559) - }); - - const transactionReceipt = await publicClient.waitForTransactionReceipt({ - hash: await transactionHash, - }); - - printFormattedTransactionReceipt(transactionReceipt); - } - ``` - - - - - -### Code to send Transaction Type (123) - - - - - - ```ts - /** - * Transaction type: 123 (0x7b) - * Name: "Dynamic fee" - * Description: Celo dynamic fee transaction (with custom fee currency) - */ - async function demoFeeCurrencyTransactionType() { - console.log(`Initiating custom fee currency transaction...`); - const transactionHash = await walletClient.sendTransaction({ - account, // Sender - to: "0x70997970c51812dc3a010c7d01b50e0d17dc79c8", // Recipient (illustrative address) - value: parseEther("0.01"), // 0.01 CELO - feeCurrency: "0x874069Fa1Eb16D44d622F2e0Ca25eeA172369bC1", // cUSD fee currency - maxFeePerGas: parseGwei("10"), // Special field for dynamic fee transaction type (EIP-1559) - maxPriorityFeePerGas: parseGwei("10"), // Special field for dynamic fee transaction type (EIP-1559) - }); - - const transactionReceipt = await publicClient.waitForTransactionReceipt({ - hash: await transactionHash, - }); - - printFormattedTransactionReceipt(transactionReceipt); - } - ``` - - - - diff --git a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/tx-comment-encryption.mdx b/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/tx-comment-encryption.mdx deleted file mode 100644 index 37e1ff200d..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/protocol/transaction/tx-comment-encryption.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Encrypted Payment Comments" -sidebarTitle: "Celo Encrypted Payment Comments" -og:description: Overview of encrypted payment comments and its technical details related to symmetric and asymmetric encryption. ---- - -Overview of encrypted payment comments and its technical details related to symmetric and asymmetric encryption. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -### Introduction to Comment Encryption - -As part of Celo’s identity protocol, a public encryption key is stored along with a user’s address in the `Accounts` contract. - -Both the address key pair and the encryption key pair are derived from the backup phrase. When sending a transaction the encryption key of the recipient is retrieved when getting his or her address. The comment is then encrypted using a 128 bit hybrid encryption scheme \(ECDH on secp256k1 with AES-128-CTR\). This system ensures that comments can only be read by the sending and receiving parties and that messages will be recovered when restoring a wallet from its backup phrase. - -### Comment Encryption Technical Details - -A 128 bit randomly generated session key, sk, is generated and used to symmetrically encrypt the comment. sk is asymmetrically encrypted to the sender and to the recipient. - -‌`Encrypted = ECIES(sk, to=pubSelf) | ECIES(sk, to=pubOther) | AES(ke=sk, km=sk, comment)` - -#### ‌Symmetric Encryption \(AES-128-CTR\) - -- Takes encryption key, ke, and MAC key, km, and the data to encrypt, plaintext -- Cipher: AES-128-CTR using a randomly generated iv -- Authenticate iv \| ciphertext using HMAC with SHA-256 and km -- Return iv \| ciphertext \| mac - -#### Asymmetric Encryption \(ECIES\) - -1. Takes data to encrypt, plaintext, and the public key of the recipient, pubKeyTo -2. Generate an ephemeral keypair, ephemPubKey and ephemPrivKey -3. Derive 32 bytes of key material, k, from ECDH between ephemPrivKey and pubKeyTousing ConcatKDF \(specified as NIST 800-56C Rev 1 One Step KDF\) with SHA-256 for H\(x\) -4. The encryption key, ke, is the first 128 bits of k -5. The MAC key, km, is SHA-256 of the second 128 bits of k -6. Encrypt the plaintext symmetrically with AES-128-CTR using ke, km, and a random iv -7. Return ephemPubKey \| AES-128-CTR-HMAC\(ke, km, plaintext\) where the public key needs to be uncompressed \(current limitation with decrypt\). \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/celo-foundation-voting-policy.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/celo-foundation-voting-policy.mdx deleted file mode 100644 index 7b159b24b2..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/celo-foundation-voting-policy.mdx +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: Celo Foundation Voting Policy -og:description: How the Celo Foundation anticipates allocating its votes to validator groups, with special attention to the first allocated groups at the Celo Mainnet release and the months thereafter. -sidebarTitle: "Voting Policy" ---- - -How the Celo Foundation anticipates allocating its votes to validator groups, with special attention to the first allocated groups at the Celo Mainnet release and the months thereafter. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - - -The policy described here can change at any time as determined by the Foundation Board. - - -## Policy Objectives - -The Foundation voting policy aims to: - -- Be fair by avoiding preferential treatment to certain groups; -- Vote in-line with the Foundation’s purpose, which is to encourage financial inclusion and prosperity for all; -- Encourage professional, secure, and reliable validators; -- Be equal opportunity by enabling new groups to have validators elected; and -- Promote network stability by encouraging a gradual turnover in elected validators instead of abrupt election changes - -## Process - -Every 4 months, the Foundation, through its Board, will distribute a portion of its total available votes to a cohort of validator groups. These validators must meet certain basic standards (details below) and alignment with the Foundation’s purpose. The total number of validator groups in a cohort can vary. - -Validator groups who will be selected for a cohort (and will thus receive a portion of the Foundation’s votes) will be informed by the following (non-exhaustive) considerations: - -1. The number of elected validators in earlier cohorts; -2. Network stability; -3. CELO governance participation (e.g., how many CELO holders are actively participating in voting); and -4. The quality of validator group applicants - -Each validator group selected in the cohort will receive a portion of the Foundation votes for a period of 12 months. During this period, so long as a validator in the group is not slashed or otherwise engages in misbehavior, the validator group will continue to receive these votes. If the validator group is slashed or engages in misbehavior, however, the votes for that validator group will be withdrawn for the remainder of the period. If the validator group is slashed, it may reapply to the Foundation after a 6 month period. In addition, the Foundation may also withdraw its votes if the validator group or the validators in the group fail to meet other standards, including running an attestation service. - - -![](https://storage.googleapis.com/celo-website/docs/celo-foundation-cohorts.jpg) - - -## Eligibility Criteria - -### Network Criteria - -To support effective and responsible validators, the Foundation considers the following, main criteria for network performance, which must be met by all applicants who receive Foundation votes. - -- **Zero Slashing Incidents.** The validator members of any applying group must not have been slashed within the last 6 months of application. (Note, there are a variety of reasons for slashing, including downtime, security issues, etc. At the outset, and because groups can re-apply at 6 months and 1 day of the slashing, all slashing will be considered equal at this stage) - -- **Attestation Performance.** Ability and commitment to running attestation services with high completion rates. - -- **Uptime Performance.** High performance uptime score over the past 30 days on Mainnet (or Baklava if not elected on Mainnet) - -**Note**: If you are NOT ELECTED on Mainnet, you must be validating on Baklava testnet for at least 30 days. If you are ELECTED you must run validators and attestation service for at least one month (30 days) on Mainnet. If you are ELECTED on Mainnet but for less than 30 days, you must be validating on Baklava for 30 days at least. - -### Supporting Criteria - -On top of the main criteria outlined in the previous example, the Foundation considers the following, supporting criteria, which must be met by all applicants who receive Foundation votes: - -- **Audit Checklist and Self Reporting.** As part of the application process, the Foundation will publish a list of recommended validator settings. The members of every group applying will self attest to complying with the recommended checklist. - -- **Education.** An effective validator must be secure. Applicants’ members will take an education course. The course must be completed annually. - -- **Basic Diligence.** Because the Foundation holds a substantial number of votes, and its voting may determine whether a validator is elected, the Foundation will conduct a basic diligence process for voted groups. The diligence would include name, location, entity information. This diligence would occur on an annual basis for any group receiving votes. - -### Additional Criteria - -In addition to meeting the main and supporting criteria, outlined above, the Foundation anticipates prioritizing validator groups who are mission aligned and/or will provide greater network resilience. These criteria may include: - -- The geographical location of the validator group - -- Non-profit organizations - -- Organizations who commit to donating a percentage of rewards to non-profit organizations - -- The likelihood of the validator group having substantial network support from other voters - -This criteria assumes the validators perform well in the main and supporting criteria. It is used as an additional way to evaluate validator applicants assuming there’s a limited number of seats in a cohort and that the validators being evaluated all performed well in network performance as outlined in the main criteria. - -## Application - -The following new deadlines will be established for the next 3 cohorts as fixed dates. -Each cohort will last 12 months, there’s a 4 months gap between each cohort. - -- Cohort 11: November 1 new date for voting in - -- Cohort 12: March 1 new date for voting in - -- Cohort 13: July 1 new date for voting in - -For each cohort, the deadline to apply/be evaluated (if you are reapplying) is exactly 1 month prior to the date of being voted in. So for Cohort 8, it’ll be October 1 for the deadline, etc. - -## New Applicants - -### Application Prerequisites - -Before applying all validator group members should have: - -- **Important**: Run at least one Validator and Validator Group on Baklava -- **Important**: Run an Attestation Service on Baklava -- **Important**: Register a validator group on Mainnet and get 150k CELO voted for your validator group -- Completed the [Mastering the Art of Validating](https://youtu.be/3UIudzzCb8o) and [Validator Group Marketing](https://www.youtube.com/watch?v=0_veGIugCGQ) courses -- Completed the [Security Self Assessment Audit](https://docs.google.com/presentation/d/e/2PACX-1vRdKNpXI2mvqwQF6L5LRrxPW2qRK-5MDce5EhqXqLC1MSYmupZMFnhp6YEP0gLYuRKW-FF0fcAqhEAp/pub?start=true&loop=false&delayms=10000&slide=id.g76d52a0216_0_333), which includes completing this [checklist](https://docs.google.com/spreadsheets/d/1FqmUfleCoyNIUep7PoVu3ujHd-OkHZJ8o6p7Affr93w/edit?usp=sharing) - -### Application Details - -Before applying be ready to share the following: - -- A personal statement telling the Foundation why your group should get votes (max 1,500 characters) -- Validator Group details: email, name, website, address on Mainnet and Baklava, and geographic location -- Information about your team: full names, link to professional profiles such as LinkedIn or GitHub, and an explanation of the team’s relevant experience - -- Whether your Group: - - Is validating or has validated in the past 1 month on the Baklava Testnet (Need to provide validator group address and validator address on Baklava) - - Has been slashed in the past 6 months and if so why (for reapplicants) - - Members have all completed the online training (see prerequisites) - - Members have all completed the self-audit (see prerequisites) -- Optional: - - The list of contributions made to the Celo ecosystem - - Date, audit firm name, and report of your last security audit if your Group has been audited by an external firm in the past 12 months - -## Reapplicants - -If you’re part of an existing cohort with expiring votes and interested in reapplying, the re-application process is much more simpler as an existing cohort. - -You will receive an email from Celo Foundation asking you if you are interested in reapplying for the new Cohort. - -At the application deadline date for new applicants, your validator group will be evaluated on Performance Score and Attestation Score. If you score above the Foundation’s threshold, you will be considered for the new cohort along with the new applicants reapplying, limited by seat availability in that cohort. If you don’t make the new cohort, you are invited to reapply for the next cohort application. - -### Cohort Information - -Past Foundation votes recipients: - -- **Cohort 1:** The Great Celo Stake Off [leaderboard](https://docs.google.com/spreadsheets/d/1Me56YkCHYmsN23gSMgDb1hZ_ezN0sTjNW4kyGbAO9vc/edit#gid=1970613133) participants at ranking 26-50 -- votes expired on Aug 1, 2020 -- **Cohort 2:** The Great Celo Stake Off [leaderboard](https://docs.google.com/spreadsheets/d/1Me56YkCHYmsN23gSMgDb1hZ_ezN0sTjNW4kyGbAO9vc/edit#gid=1970613133) participants at ranking 1-25 -- votes expired on Nov 1, 2020 -- **Cohort 3:** [6 validator groups](https://docs.google.com/spreadsheets/d/1OkWnr6EOeFn4pIv0zxmXFNtHLmKWf_qCJOJ4iacov-A/edit?usp=sharing) -- votes expired on Feb 1, 2021 -- **Cohort 4:** [22 validator groups](https://docs.google.com/spreadsheets/d/1bp2nJUxqhWner-uOffBohKQc3N93e--eMpP7XOBrbGI/edit?usp=sharing) -- votes expired on May 1, 2021 -- **Cohort 5:** [24 validator groups](https://docs.google.com/spreadsheets/d/1n2lwFsAsFaohng4Bo_FEWcoXzZl5CrLFxA6EK0nuFSA/edit#gid=0) -- votes expired on November 1, 2021 -- **Cohort 6:** [7 validator groups](https://docs.google.com/spreadsheets/d/1HT_fN-mSAL2etF0Po_h122jeU1zpEtdpb_khogOfBCg/edit?usp=sharing) -- votes will expire on March 1, 2022 -- **Cohort 7:** [23 validator groups](https://docs.google.com/spreadsheets/d/1eYBzQMObTAy-WKs5CHHFnGGl_k1rQo0MBHinV3OgSik/edit#gid=1466530578) -- votes will expire on July 1, 2022 -- **Cohort 8:** [24 validator groups](https://docs.google.com/spreadsheets/d/11fTPMa_2FXAye_mgidE_3Ub-xY_aJLo0WXee_Qn5mC8/edit#gid=0) -- votes will expire on November 1, 2022 -- **Cohort 9:** [7 validator groups](https://docs.google.com/spreadsheets/d/1NcIMKvZnxyqzgbnaICisMR1y0eyxpr0HvCHFCHH-EDA/edit?pli=1#gid=0) -- votes will expire on March 1, 2023 - -Currently receiving Foundation votes: - -- **Cohort 10:** [24 validator groups](https://docs.google.com/spreadsheets/d/1q0FhZJ2wYxg0JaZ-hbdIodRGwZPPNgf3aqD3ubArtj0/edit#gid=0) -- votes will expire on July 1, 2023 -- **Cohort 11:** [24 validator groups](https://docs.google.com/spreadsheets/d/1CPbZmaS_e-dvPu1fujMYhaiUY_1sNqi3nYaYTIIBK6E/edit#gid=0) -- votes will expire on November 1, 2023 -- **Cohort 12:** 5 validator groups -- votes will expire on March 1, 2024 - -Coming soon: -- **Cohort 13:** 24 validator groups -- votes will expire on July 1, 2024 - - - -If you would like to keep up-to-date with all the news happening in the Celo community, including validation, node operation and governance, please sign up to our [Celo Signal mailing list here](https://share.hsforms.com/1Qrhush1vSA2WIamd_yL4ow53n4j). - -You can add the [Celo Signal public calendar](https://calendar.google.com/calendar/u/0/embed?src=c_9su6ich1uhmetr4ob3sij6kaqs@group.calendar.google.com) as well which has relevant dates. - diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/celo-website.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/celo-website.mdx deleted file mode 100644 index d395554220..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/celo-website.mdx +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Celo Website -url: https://celo.org ---- \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/devops-best-practices.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/devops-best-practices.mdx deleted file mode 100644 index 379e28961c..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/devops-best-practices.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "DevOps Best Practices" -sidebarTitle: "DevOps Best Practices" -og:description: Best practices for running cloud infrastructure for Celo nodes and services. ---- - -Best practices for running cloud infrastructure for Celo nodes and services. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Cloud Infrastructure Best Practices - -### Node Redundancy - -If you are running your celo-blockchain nodes for mainnet in the cloud as a validator, then we recommend having more than one node running. - -You can use the redundant validator node as a backup node. It's important that it should only be used as a backup node so you must not enable block-signing with it (to avoid double signing). - -In case your primary validator node fails for some reason, then having the redundant node is extremely valuable as you can add the validator keys to it and point it to your proxy to continue signing blocks. - -### Snapshotting - -Another useful thing you can do is enabling snapshotting on your redundant node. - -There's no best answer on cadence for snapshotting your redundant node, but one snapshot a week is a good estimate, depending on budget and how the cloud provider charges for snapshotting. - -That way, in the event of a node or instance failure on your validator box, which can potentially lead to database failure and requiring you to resync your validator node, then you can use your snapshot as a starting point for syncing and don't have to wait too long to sync. - -### Kubernetes - -We are working on getting a Kubernetes recommended specification and will update this section once we have a recommended spec. If you are using Kubernetes with your validator node, feel free to submit a PR to update this section with your setup. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/discord.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/discord.mdx deleted file mode 100644 index e195e72454..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/discord.mdx +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Celo Discord -url: https://discord.com/invite/celo ---- \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/index.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/index.mdx deleted file mode 100644 index 0d20bff471..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/index.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: Celo Validators -og:description: Collection of resources to support Validators on the Celo network. -sidebarTitle: "Overview" ---- - - -Secure the Celo network by participating in the consensus of the Celo protocol. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -Celo Validators participate in the consensus of the Celo protocol. They help secure the Celo network by verifying transactions and proposing blocks to add to the Celo blockchain. - - -Not ready to become a Celo Validator? [Learn more about Celo](/). - - -## Important Information - -- [Key Management](/what-is-celo/about-celo-l1/validator/key-management/summary) - -## Nodes and Services - -- [Securing Celo Nodes and Services](/what-is-celo/about-celo-l1/validator/security) -- [Upgrading a Node](/what-is-celo/about-celo-l1/validator/node-upgrade) -- [Monitoring](/what-is-celo/about-celo-l1/validator/monitoring) -- [Running Proxies](/what-is-celo/about-celo-l1/validator/proxy) - -## Validator Tools - -- [Validator Explorer](/what-is-celo/about-celo-l1/validator/validator-explorer) - -## Voting Policy - -- [Celo Foundation Voting Policy](/what-is-celo/about-celo-l1/validator/celo-foundation-voting-policy) - - -For questions, comments, and discussions please use the [Celo Forum](https://forum.celo.org/) or [Discord](https://chat.celo.org/). - diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/key-management/detailed.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/key-management/detailed.mdx deleted file mode 100644 index 11a5686c2a..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/key-management/detailed.mdx +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: "Detailed Role Descriptions" -sidebarTitle: "Key Management" -og:description: Detailed description of the various account roles found in the Celo protocol with examples of how to designate an account as playing a particular role. ---- - -Detailed descriptions of the various account roles as found in the Celo protocol with examples of how to designate an account as playing a particular role. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Celo Accounts - -Any private key generated for use in the Celo protocol has a corresponding address. The account address is the last 20 bytes of the hash of the corresponding public key, just as in Ethereum. Celo account keys can be used to sign and send transactions on the Celo network. - -Celo Accounts can be designated as Locked Gold Accounts or authorized as signer keys on behalf of a Locked Gold Account by sending special transactions using [celocli](/cli/). Note that Celo accounts that have not been designated as Locked Gold Accounts or authorized signers may not be able to send certain transactions related to proof-of-stake. - -## Locked CELO Accounts - -[Locked CELO](/what-is-celo/about-celo-l1/protocol/pos/locked-gold) Account keys have the highest level of privilege in the Celo protocol. These keys can be used to lock and unlock CELO in order to be used in proof-of-stake. Furthermore, Locked CELO Account keys can be used to authorize other keys to sign transactions and messages on behalf of the Locked CELO Account. - -In _most_ cases, the Locked CELO Account key has all the privileges as any authorized signers. For example, if a voter signer is authorized, a user can place votes on behalf of the Locked CELO Account with both the authorized vote signer _and_ the Locked CELO Account. - -Because of the significant privileges afforded to the Locked CELO Account, it is best to store this key securely and access it as infrequently as is possible. Authorizing other signers is one way to minimize how frequently you need to access your Locked CELO Account key. The Locked CELO Account key will only be used to send transactions and **can be stored on a Ledger hardware wallet.** - -### Creating a Locked CELO Account - -A Celo account may be designated as a Locked CELO Account by running the following command: - -```shell -# Designate the Celo account as a Locked CELO Account -celocli account:register --from $ADDRESS_TO_DESIGNATE --useLedger - -# Confirm the address was designated as a Locked CELO Account -celocli account:show $ADDRESS_TO_DESIGNATE -``` - -Note that [ReleaseGold](/what-is-celo/using-celo/manage/release-gold) beneficiary keys are considered vanilla Celo accounts with respect to proof-of-stake, and that the `ReleaseGold` contract address is what ultimately gets designated as a Locked CELO Account. - -## Authorized Vote Signers - -Any Locked CELO Account may optionally authorize a Celo account as a vote signer. Authorized vote signers can vote for validator groups and for on-chain governance proposals on behalf of the Locked CELO Account. - -Note that the vote signer must first generate a "proof-of-possession" indicating that signer's willingness to be authorized on behalf of the Locked CELO Account. - -Authorized vote signers can only be used to send voting transactions and **can be stored on a Ledger hardware wallet**. - -### Authorizing a Vote Signer - -A Celo account may be authorized as a vote signer on behalf of a Locked CELO Account by running the following commands: - -```shell -# Create a proof-of-possession. Note that the signer private key must be available. -celocli account:proof-of-possession --account $LOCKED_GOLD_ACCOUNT --signer $SIGNER_TO_AUTHORIZE --useLedger - -# Authorize the vote signer. Note that the Locked Gold Account private key must be available. -celocli account:authorize --from $LOCKED_GOLD_ACCOUNT --role vote --signer $SIGNER_TO_AUTHORIZE --signature $SIGNER_PROOF_OF_POSSESSION --useLedger - -# Confirm that the vote signer was authorized -celocli account:show $LOCKED_GOLD_ACCOUNT - -# You can also look up account info via the authorized signer -celocli account:show $SIGNER_TO_AUTHORIZE -``` - -## Authorized Validator Signers - -Any Locked CELO Account may optionally authorize a Celo account as a validator signer. Authorized validator signers can be used to register and manage a validator or validator group on behalf of the Locked CELO Account. If the authorized validator signer is used to register and run a validator, the signer key is also used to sign consensus messages. - -### Authorized Validator Signers for Validator Groups - -An authorized validator signer key that will be used to register a validator group can be used to send group management transactions (e.g. register, add member A, queue commission update to 0.25, etc.) Because this key does not participate directly in consensus it **can be stored on a Ledger hardware wallet.** - -### Authorized Validator Signers for Validators - -An authorized validator signer key that will be used to register a validator can be used to send validator management transactions (e.g. register, affiliate with group A, etc.) This key will also be used to sign consensus messages and thus **cannot be stored on a Ledger hardware wallet** as signing consensus messages is not currently supported by the Celo Ledger App. - -Note that the validator signer must first generate a "proof-of-possession" indicating the signer's willingness to be authorized on behalf of the Locked CELO Account. - -### Authorizing a Validator Signer - -A Celo account may be authorized as a validator signer on behalf of a Locked CELO Account by running the following commands: - -```shell -# Create a proof-of-possession. Note that the signer private key must be available. -# Note that the signing key can be kept on a Ledger if it will be used to run a Validator Group. -celocli account:proof-of-possession --account $LOCKED_GOLD_ACCOUNT --signer $SIGNER_TO_AUTHORIZE - -# Authorize the validator signer. Note that the Locked CELO Account private key must be available. -# Note that if a Validator has previously been registered on behalf of the Locked CELO Account it -# may be desirable to include the BLS key here as well. Please see the documentation on -# validator key rotation for more information. -celocli account:authorize --from $LOCKED_GOLD_ACCOUNT --role validator --signer $SIGNER_TO_AUTHORIZE --signature $SIGNER_PROOF_OF_POSSESSION --useLedger - -# Confirm that the vote signer was authorized -celocli account:show $LOCKED_GOLD_ACCOUNT - -# You can also look up account info via the authorized signer -celocli account:show $SIGNER_TO_AUTHORIZE -``` - -## Authorized Validator BLS Signers - -The Celo protocol uses BLS signatures in consensus to ultimately determine whether or not a particular block is valid. Many BLS signatures over the same content can be combined into a single "aggregated signature", allowing several kilobytes of signatures to be compressed into fewer than 100 bytes, ensuring that the block headers remain compact and light client friendly. - -When registering a Validator on behalf of a Locked CELO Account, users must provide a BLS public key, as well as a proof-of-possession to protect against [rogue key attacks](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html). - -By default users can derive the BLS key directly from their authorized validator signer key. From a key management and security perspective, this means that the authorized BLS signer key is **exactly the same** as the authorized validator signer key. - -Most users will only need to think about BLS signer keys when registering a validator, or when authorizing a new validator signer _after_ registering a validator. It follows that when a validator authorizes a new validator signer, the BLS public key and proof-of-possession for the new authorized validator signer should be provided as well. - -Advanced users may optionally derive their BLS key separately, but that is out of the scope of this documentation. - -### Deriving a BLS public key - -To derive a BLS public key and proof-of-possession from the authorized validator signer key, and use that information to register a validator, run the following commands: - -```shell -# Derive the BLS public key and create a proof-of-possession. Note that the signer private key must be available. -# Also note that BLS proof-of-possessions are not currently supported by celocli -docker run -v $PWD:/root/.celo --rm -it $CELO_IMAGE account proof-of-possession $AUTHORIZED_VALIDATOR_SIGNER $LOCKED_GOLD_ACCOUNT --bls - -# Register the Validator with the authorized validator signer on behalf of the Locked CELO Account -celocli validator:register --from $AUTHORIZED_VALIDATOR_SIGNER --blsKey $BLS_SIGNER_PUBLIC_KEY --blsSignature $BLS_SIGNER_PROOF_OF_POSSESSION - -# Confirm that the validator was registered -celocli validator:show $LOCKED_GOLD_ACCOUNT - -# You can also look up the validator via the authorized signer -celocli validator:show $AUTHORIZED_VALIDATOR_SIGNER -``` - -## Authorized Attestation Signers - -Any Locked CELO Account may optionally authorize a Celo account as an attestation signer. Authorized attestation signers can sign attestation messages on behalf of the Locked Gold Account in Celo's [lightweight identity protocol](/legacy/protocol/identity/). - -Note that the Celo Ledger App does yet not support signing attestation messages and as such attestation signer keys **cannot be stored on a Ledger hardware wallet**. - -Note that the attestation signer must first be used to generate a "proof-of-possession" indicating the signer's willingness to be authorized on behalf of the Locked Gold Account. - -### Authorizing an Attestation Signer - -A Celo account may be authorized as a vote signer on behalf of a Locked CELO Account by running the following commands: - -```shell -# Create a proof-of-possession. Note that the signer private key must be available. -celocli account:proof-of-possession --account $LOCKED_GOLD_ACCOUNT --signer $SIGNER_TO_AUTHORIZE -# If celocli is unavailable on the attestations node, the proof-of-possession can be generated with celo-blockchain -docker run -v $PWD:/root/.celo --rm -it $CELO_IMAGE account proof-of-possession $SIGNER_TO_AUTHORIZE $LOCKED_GOLD_ACCOUNT - -# Authorize the attestation signer. Note that the Locked CELO Account private key must be available. -celocli account:authorize --from $LOCKED_GOLD_ACCOUNT --role attestations --signer $SIGNER_TO_AUTHORIZE --signature $SIGNER_PROOF_OF_POSSESSION --useLedger - -# Confirm that the vote signer was authorized -celocli account:show $LOCKED_GOLD_ACCOUNT - -# You can also look up account info via the authorized signer -celocli account:show $SIGNER_TO_AUTHORIZE -``` \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/key-management/key-rotation.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/key-management/key-rotation.mdx deleted file mode 100644 index db6b619e25..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/key-management/key-rotation.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "Validator Signer Key Rotation" -sidebarTitle: "Key Rotation" -og:description: How to manage signer key rotations as a Celo Validator. ---- - -How to manage signer key rotations as a Celo Validator. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Why Rotate Keys? - -As detailed in [the Celo account roles description page](/what-is-celo/about-celo-l1/validator/key-management/detailed), Celo Locked CELO accounts can authorize separate signer keys for various roles such as voting or validating. This way, if an authorized signer key is lost or compromised, the Locked CELO account can authorize a new signer to replace the old one, without risking the key that custodies funds. This prevents losing an authorized signer key from becoming a catastrophic event. In fact, it is recommended as an operational best practice to regularly rotate keys to limit the impact of keys being silently compromised. - -### Validator Signer Rotation - -Because the Validator signer key is constantly in use to sign consensus messages, special care must be taken when authorizing a new Validator signer key. The following steps detail the recommended procedure for rotating the validator signer key of an active and elected validator: - -1. Create a new Validator instance as detailed in the [Deploy a Validator](/what-is-celo/about-celo-l1/validator/run/mainnet) section of the getting started documentation. When using a proxy, additionally create a new proxy and peer it with the new validator instance, as described in the same document. Wait for the new instances to sync before proceeding. Please note that when running the proxy, the `--proxy.proxiedvalidatoraddress` flag should reflect the new validator signer address. Otherwise, the proxy will not be able to peer with the validator. - - -Before proceeding to step 2 ensure there is sufficient time until the end of the epoch to complete key rotation. - - -2. Authorize the new Validator signer key with the Locked CELO Account to overwrite the old Validator signer key. - -```bash -# With $SIGNER_TO_AUTHORIZE as the new validator signer: - -# On the new validator node which contains the new $SIGNER_TO_AUTHORIZE key -docker run -v $PWD:/root/.celo --rm -it $CELO_IMAGE account proof-of-possession $SIGNER_TO_AUTHORIZE $VALIDATOR_ACCOUNT_ADDRESS -docker run -v $PWD:/root/.celo --rm -it $CELO_IMAGE account proof-of-possession $SIGNER_TO_AUTHORIZE $VALIDATOR_ACCOUNT_ADDRESS --bls -``` - -1. If `VALIDATOR_ACCOUNT_ADDRESS` corresponds to a key you possess: - -```bash -# From a node with access to the key for VALIDATOR_ACCOUNT_ADDRESS -celocli account:authorize --from $VALIDATOR_ACCOUNT_ADDRESS --role validator --signer $SIGNER_TO_AUTHORIZE --signature 0x$SIGNER_PROOF_OF_POSSESSION --blsKey $BLS_PUBLIC_KEY --blsPop $BLS_PROOF_OF_POSSESSION -``` - -2. If `VALIDATOR_ACCOUNT_ADDRESS` is a `ReleaseGold` contract: - -```bash -# From a node with access to the beneficiary key of VALIDATOR_ACCOUNT_ADDRESS -celocli releasecelo:authorize --contract $VALIDATOR_ACCOUNT_ADDRESS --role validator --signer $SIGNER_TO_AUTHORIZE --signature 0x$SIGNER_PROOF_OF_POSSESSION --blsKey $BLS_PUBLIC_KEY --blsPop $BLS_PROOF_OF_POSSESSION -``` - - -Please note that the BLS key will change along with the validator signer ECDSA key on the node. If the new BLS key is not authorized, then the validator will be unable to process aggregated signatures during consensus, **resulting in downtime**. For more details, please read [the BLS key section of the Celo account role descriptions](/what-is-celo/about-celo-l1/validator/key-management/detailed#authorized-validator-bls-signers). - - -1. **Leave all validator and proxy nodes running** until the next epoch change. At the start the next epoch, the new Validator signer should take over participation in consensus. - -2. Verify that key rotation was successful. Here are some ways to check: - {/* TODO: The following URL assumes that the user is running against the Baklava network. This will need to be updated */} - -- Open `baklava-blockscout.celo-testnet.org/address//validations` to confirm that blocks are being proposed. -- Open `baklava-celostats.celo-testnet.org` to confirm that your node is signing blocks. -- Run `celocli validator:signed-blocks --signer $SIGNER_TO_AUTHORIZE` with the new validator signer address to further confirm that your node is signing blocks. - - -The newly authorized keys will only take effect in the next epoch, so the instance operating with the old key must remain running until the end of the current epoch to avoid downtime. - - -5. Shut down the validator instance with the now obsolete signer key. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/key-management/summary.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/key-management/summary.mdx deleted file mode 100644 index b0e6ac0bf5..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/key-management/summary.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Overview -og:description: Introduction to the philosophy and account roles related to key management on Celo. -sidebarTitle: "Summary" ---- - -Introduction to the philosophy and account roles related to key management on Celo. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Philosophy - -The Celo protocol was designed with the understanding that there is often an inherent tradeoff between the convenience of accessing a private key and the security with which that private key can be custodied. In general Celo is unopinionated about how keys are custodied, but also allows users to authorize private keys with specific, limited privileges. This allows users to custody each private key according to its sensitivity (i.e. what is the impact of this key being lost or stolen?) and usage patterns (i.e. how often and under which circumstances will this key need to be accessed). - -## Summary - -The table below outlines a summary of the various account roles in the Celo protocol. Note that these roles are often _mutually exclusive_. An account that has been designated as one role can often not be used for a different purpose. Also note that under the hood, all of these accounts) are based on secp256k1 ECDSA private keys with the exception of the BLS signer. The different account roles are simply a concept encoded into the Celo proof-of-stake smart contracts, specifically [Accounts.sol](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/common/Accounts.sol). - -For more details on a specific key type, please see the more detailed sections below. - -| Role | Description | Ledger compatible | -| ----------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------- | -| Celo Account | An account used to send transactions in the Celo protocol | Yes | -| Locked CELO Account | Used to lock and unlock CELO and authorize signers | Yes | -| Authorized vote signer | Can vote on behalf of a Locked CELO Account | Yes | -| Authorized validator (group) signer | Can register and manage a validator group on behalf of a Locked CELO Account | Yes | -| Authorized validator signer | Can register, manage a validator, and sign consensus messages on behalf of a Locked CELO Account | No | -| Authorized validator BLS signer | Used to sign blocks as a validator | No | -| Authorized attestation signer | Can sign attestation messages on behalf of a Locked CELO account | No | - - -A Locked CELO Account may have at most one authorized signer of each type at any time. Once a signer is authorized, the only way to deauthorize that signer is to authorize a new signer that has never previously been used as an authorized signer or Locked CELO Account. It follows then that a newly deauthorized signer cannot be reauthorized. - \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/monitoring.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/monitoring.mdx deleted file mode 100644 index c25498fca6..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/monitoring.mdx +++ /dev/null @@ -1,156 +0,0 @@ ---- -title: "Monitoring" -sidebarTitle: "Monitoring" -og:description: Commands, metrics, APIs, and services for monitoring Validators and Proxies. ---- - -Commands, metrics, APIs, and services for monitoring Validators and Proxies. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Monitoring Validators and Proxies - -### Logging - -Several command line options control logging: - -- `--verbosity`: Sets logging verbosity. `3` outputs logs up to `INFO` level and is recommended. `4` outputs up to `DEBUG` level; `5` is `TRACE`. - -- `--vmodule`: Overrides this verblosity in specific modules. For example, to configure `TRACE` level logging of consensus activity, use `consensus/istanbul/*=5`. - -- `--consoleoutput`: Sends output to the given path, or to `stdout`. - -- (Deprecatedin v1.5) `--consoleformat`: Formats logs for easy viewing in a terminal (`term`), or as structured JSON (`json`). -- (Introduced in v1.5) `--log.json`: Formats logs as structured JSON (`true`), or for easy viewing in a terminal (`false`, default option). - -Useful messages to record or set up log-based metrics on: - -- `msg="Validator Election Results"`: When the last block of any epoch (`number`) has been agreed, `elected` shows whether the validator was selected in the validator election. - -- `msg="Elected but didn't sign block"`: This validator was elected but did not have its signature included in the block given by `number` (in fact, in the child's parent seal). This block could count towards downtime if 12 successive blocks are missed. - -### Metrics - -Celo Blockchain inherits [go-ethereum's metrics](https://github.com/ethereum/go-ethereum/wiki/Metrics-and-Monitoring) system, but additional Celo-specific metrics have been added. - -Metrics reporting is enabled with the `--metrics` flag. - -Pull-based metrics are available using the `--pprof` flag. This enables the `pprof` debugging HTTP server, by default on `http://localhost:6060`. The `--pprof.addr` and `--pprof.port` options can be used to configure the interface and port respectively. If the node is running inside a Docker container, you will need to set `--pprof.addr 0.0.0.0`, then on your Docker command line add `-p 127.0.0.1:6060:6060`. - - -Be sure never to expose the `pprof` service to the public internet. - - -[Prometheus](https://prometheus.io) format metrics are available at `http://localhost:6060/debug/metrics/prometheus`. - -[ExpVar](https://golang.org/pkg/expvar/) format metrics are available at `http://localhost:6060/debug/metrics`. - -Support for pushing metrics to [InfluxDB](https://www.influxdata.com/products/influxdb-overview/) is available via `--metrics.influxdb` and related flags. This works without the `pprof` server. - -Note that metric name separators differ between these endpoints. - -All metrics are soft-state and are cleared when the process is restarted. - -### Memory metrics - -Memory metrics derived from [mstats](https://godoc.org/github.com/go-graphite/carbonzipper/mstats): - -- `system_memory_held`: Gauge of virtual address space allocated by the Celo Blockchain process, measured in bytes. -- `system_memory_used`: Gauge of Memory in use by the Celo Blockchain process, measured as bytes of allocated heap objects. -- `system_memory_allocs`: Counter for memory allocations made, measured in bytes. Consider monitoring the rate. -- `system_memory_pauses`: Counter for stop-the-world Garbage Collection pauses, measured in nanoseconds. Consider monitoring the rate. - -### CPU metrics - -- `system_cpu_sysload`: Gauge of load average for the system. -- `system_cpu_syswait`: Gauge of IO wait time for the system. -- `system_cpu_procload`: Gauge of load average for the Celo Blockchain process. - -### Network metrics - -- `p2p_peers`: The number of connected peers. This should remain at exactly `1` for a proxied validator (just its proxy). It should remain at a relatively steady level for proxy nodes. - -- `p2p_ingress`: Counter for total inbound traffic, measured in bytes. Consider monitoring the rate. - -- `p2p_egress`: Counter for total outbound traffic, measured in bytes. Consider monitoring the rate. - -- `p2p_dials`: Counter for outbound connection attempts. Consider monitoring the rate. - -- `p2p_serves`: Counter for accepted inbound connection attempts. Consider monitoring the rate. - -### Blockchain metrics - -- `chain_inserts_count`: The count of insertions of new blocks into this node's chain. The rate of this metric should be close to constant at `0.2` /second. - -### Validator health metrics - -A number of metrics are tracked for the parent of the last sealed block received (i.e. this is always two fewer than the current consensus sequence): - -- `consensus_istanbul_blocks_elected`: Counts the number of blocks for which this validator has been elected - -- `consensus_istanbul_blocks_signedbyus`: Counts the blocks for which this validator was elected and its signature was included in the seal. This means the validator completed consensus correctly, sent a `COMMIT`, its commit was received in time to make the seal of the parent received by the next proposer, or was received directly by the next proposer itself, and so the block will not count as downtime. Consider monitoring the rate. - -- `consensus_istanbul_blocks_missedbyus`: Counts the blocks for which this validator was elected but not included in the child's parent seal (this block could count towards downtime if 12 successive blocks are missed). Consider monitoring the rate. - -- `consensus_istanbul_blocks_missedbyusinarow`: (_since 1.0.2_) Counts the blocks for which this validator was elected but not included in the child's parent seal in a row. Consider monitoring the gauge. - -- `consensus_istanbul_blocks_proposedbyus`: (_since 1.0.2_) Counts the blocks for which this validator was elected and for which a block it proposed was succesfully included in the chain. Consider monitoring the rate. - -- `consensus_istanbul_blocks_downtimeevent`: (_since 1.0.2_) Counts the blocks for which this validator was elected and for blocks where it is considered down (occurs when `missedbyusinarow` is >= 12). Consider monitoring the rate. - -### Consensus metrics - -- `consensus_istanbul_core_desiredround`: Current desired round for this validator, i.e the round we are waiting to see a quorum of validators send `RoundChange` messages for. Usually this value should be `0`. Desired rounds increment with each timeout, which backoff exponentially. A value of `5` indicates consensus has stalled for more than 30 seconds. Values above that means the validator is unable to participate in quorum (either because it is disconnected, out of sync, etc, or because of network partition or failure of other validators). - -- `consensus_istanbul_core_round`: : Current consensus round for this validator, i.e the round for which this validator has received a quorum of `RoundChange` messages. Usually this value should be `0`. If this value is less than `consensus_istanbul_core_desiredround` the validator is not connected to a quorum of other validators that are also unable to participate (for instance, they did see a proposed block, but this validator did not). If it is equal, it means the validator remains connected to a quorum of other validators but cannot agree on a block. - -- `consensus_istanbul_core_sequence`: Current consensus sequence number, i.e the block number currently being proposed. - -### Network consensus health metrics - -- `consensus_istanbul_blocks_totalsigs`: The number of validators whose signatures were included in the child's parent seal. This can be used to determine how many validators are up and contributing to consensus. If this number falls towards two thirds of validator set size, network block production is at risk. - -- `consensus_istanbul_blocks_missedrounds`: Sum of the `round` included in the `parentAggregatedSeal` for the blocks seen. That is, the cumulative number of consensus round changes these blocks needed to make to get to this agreed block. This metric is only incremented when a block is succesfully produced after consensus rounds fails, indicating down validators or network issues. - -- `consensus_istanbul_blocks_missedroundsasproposer`: (_since 1.0.2_) A meter noting when this validator was elected and could have proposed a block with their signature but did not. In some cases this could be required by the Istanbul BFT protocol. - -- `consensus_istanbul_blocks_validators`: (_since 1.0.2_) Total number of validators eligible to sign blocks. - -- `consensus_istanbul_core_consensus_count`: Count and timer for succesful completions of consensus (Use `quantile` tag to find percentiles: `0.5`, `0.75`, `0.95`, `0.99`, `0.999`) - -### Management APIs - -Celo blockchain inherits and extends go-ethereum's Javascript console, exposing [management APIs](https://geth.ethereum.org/docs/rpc/server) and web3 DApp APIs. - -Connect a client using a variant of the `attach` command line option: - -```bash -geth attach --datadir DATADIR -geth attach ipc:PATH/TO/geth.ipc -geth attach http://localhost:8545 -geth attach ws://localhost:8546 -``` - -{/* -Celo adds specific functions around consensus: - -```bash - -``` */} - -## Community Monitoring Tools - -### [Atalma Signature & Attestation Viewer (Celo Vido)](https://vido.atalma.io/celo/block-map) - -- Visualizer of current and historic data on validator signatures collected in each block on Mainnet and Baklava. -- Visualizer of current and historic attestation requests and completions, and attestation endpoint versions and status on Mainnet and Baklava. - -### [Virtual Hive Celo Network Validator Exporter](https://github.com/virtualhive/celo-network-validator-exporter) - -Prometheus exporter that scrapes downtime and meta information for a specified validator signer address from the Celo blockchain. All data is collected from a blockchain node via RPC. - -{/* ## Monitoring Network Health, Elections, and Accounts */} \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/node-upgrade.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/node-upgrade.mdx deleted file mode 100644 index d858740cc1..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/node-upgrade.mdx +++ /dev/null @@ -1,169 +0,0 @@ ---- -title: "Upgrade a Node" -sidebarTitle: "Node Upgrades" -og:description: How to upgrade to the newest available version of a Celo node. ---- - -How to upgrade to the newest available version of a Celo node. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Recent Releases - -- [You can view the latest releases here.](https://github.com/celo-org/celo-blockchain/releases) - -## When an upgrade is required - -Upgrades to the Celo node software will often be optional improvements, such as improvements to performance, new useful features, and non-critical bug fixes. Occasionally, they may be required when the upgrade is necessary to continue operating on the network, such as hard forks, or critical bug fixes. - -## Upgrading a non-validating node - -Use these instructions to update non-validating nodes, such as your account node or your attestation node on the Baklava testnet. Also use these instructions to upgrade your proxy node, but remember not to stop the proxy of a running validator. - -### Pull the latest Docker image - -```bash -export CELO_IMAGE=us.gcr.io/celo-org/geth:mainnet -docker pull $CELO_IMAGE -``` - -### Stop and remove the existing node - -Stop and remove the existing node. Make sure to stop the node gracefully (i.e. giving it time to shut down and complete any writes to disk) or your chain data may become corrupted. - -Note: The `docker run` commands in the documentation have been updated to now include `--stop-timeout 300`, which should make the `-t 300` in `docker stop` below redundant. However, it is still recommended to include it just in case. - -```bash -docker stop -t 300 celo-fullnode -docker rm celo-fullnode -``` - - -## Upgrading a Validating Node - -Upgrading a validating node is much the same, but requires extra care to be taken to prevent validator downtime. - -One option to complete a validating node upgrade is to perform a key rotation onto a new node. Pull the latest Docker image, as mentioned above, then execute a Validator signing key rotation, using the latest image as the new Validator signing node. A recommended procedure for key rotation is documented in the [Key Management](/what-is-celo/about-celo-l1/validator/key-management/key-rotation) guide. - -A second option is to perform a hot-swap to switch over to a new validator node. The new validator node **must** be configured with the same set of proxies as the existing validator node. - -### Hotswapping Validator Nodes - - -Hotswap is being introduced in version 1.2.0. When upgrading nodes that are not yet on 1.2.0 refer to the guide to perform a key rotation. - - -Validators can be configured as primaries or replicas. By default validators start as primaries and will persist all changes around starting or stopping. Through the istanbul management RPC API the validator can be configured to start or stop at a specified block. The validator will participate in consensus for block numbers in the range `[start, stop)`. - - -Note that the replica node **must** use the same set of proxies as the primary node. If it does not it will not be able to switchover without downtime due to needing to the complete the announce protocol from scratch. Replicas behind the same set of proxies as the primary node will be able to switchover without downtime. - - -#### RPC Methods - -- `istanbul.start()` and `istanbul.startAtBlock()` start validating immediately or at a block -- `istanbul.stop()` and `istanbul.stopAtBlock()` stop validating immediately or at a block -- `istanbul.replicaState` will give you the state of the node and the start/stop blocks -- `istanbul.validating` will give you true/false if the node is validating - - -`startAtBlock` and `stopAtBlock` must be given a block in the future. - - -#### Geth Flags - -- `--istanbul.replica` flag which starts a validator in replica mode. - -On startup, nodes will look to see if there is a `replicastate` folder inside it's data directory. If that folder exists the node will configure itself as a validator or replica depending on the previous stored state. The stored state will take precedence over the command line flags. If the folder does not exists the node will stored it's state as configured by the command line. When RPC calls are made to start or stop validating, those changes will be persisted to the `replicastate` folder. - - -If reconfiguring a node to be a replica or reusing a data directory, make sure that the node was previously configured as replica or that the `replicastate` folder is removed. If there is an existing `replicastate` folder from a node that was not configured as a replica the node will attempt to start validating. - - -#### Steps to upgrade - -1. Pull the latest docker image. -2. Start a new validator node on a second host in replica mode (`--istanbul.replica` flag). It should be otherwise configured exactly the same as the existing validator. - - It needs to connect to the existing proxies and the validator signing key to connect to other validators in listen mode. - - If reconfiguring a node to be a replica or reusing a data directory, make sure that the node was previously configured as replica or that the `replicastate` folder is removed. -3. Once the replica is synced and has validator enode urls for all validators, it is ready to swapped in. - - Check validator enode urls with `istanbul.valEnodeTableInfo` in the geth console. The field `enode` should be filled in for each validator peer. -4. In the geth console on the primary run `istanbul.stopAtBlock(xxxx)` - - Make sure to select a block number comfortably in the future. - - You can check what the stop block is with `istanbul.replicaState` in the geth console. - - You can run `istanbul.start()` to clear the stop block -5. In the geth console of the replica run `istanbul.startAtBlock(xxxx)` - - You can check what the start block is with `istanbul.replicaState` in the geth console. - - You can run `istanbul.stop()` to clear the start block -6. Confirm that the transition occurred with `istanbul.replicaState` - - The last block that the old primary will sign is block number `xxxx - 1` - - The first block that the new primary will sign is block number `xxxx` -7. Tear down the old primary once the transition has occurred. - -Example geth console on the old primary. - -```bash -> istanbul.replicaState -{ - isPrimary: true, - startValidatingBlock: null, - state: "Primary", - stopValidatingBlock: null -} -> istanbul.stopAtBlock(21000) -null -> istanbul.replicaState -{ - isPrimary: true, - startValidatingBlock: null, - state: "Primary in given range", - stopValidatingBlock: 21000 -} -> istanbul.replicaState -{ - isPrimary: false, - startValidatingBlock: null, - state: "Replica", - stopValidatingBlock: null -} -``` - -Example geth console on the replica being promoted to primary. Not shown is confirming the node is synced and connected to validator peers. - -```bash -> istanbul.replicaState -{ - isPrimary: false, - startValidatingBlock: null, - state: "Replica", - stopValidatingBlock: null -} -> istanbul.startAtBlock(21000) -null -> istanbul.replicaState -{ - isPrimary: false, - startValidatingBlock: 21000, - state: "Replica waiting to start", - stopValidatingBlock: null -} -> istanbul.replicaState -{ - isPrimary: true, - startValidatingBlock: null, - state: "Primary", - stopValidatingBlock: null -} -``` - -### Upgrading Proxy Nodes - - -Release 1.2.0 is backwards incompatible in the Validator and Proxy connection. Validators and proxies must be upgraded to 1.2.0 at the same time. - - -With multi-proxy, you can upgrade proxies one by one or can add newly synced proxies with the latest Docker image and can remove the old proxies. If upgrading the proxies in place, a rolling upgrade is recommended as the validator will re-assign direct connections as proxies are added and removed. These re-assignments will allow the validator to continue to participate in consensus. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/proxy.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/proxy.mdx deleted file mode 100644 index d45f264a78..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/proxy.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Running Proxies" -sidebarTitle: "Running Proxies" -og:description: How to ensure Validator uptime by running proxy nodes. ---- - -How to ensure Validator uptime by running proxy nodes. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Why run a Proxy? - -Validator uptime is essential for the health of the Celo blockchain. To help with validator uptime, operators can use the proxy node, which will provide added security for the validator. It allows the validator to run within a private network, and to communicate to the rest of the Celo network via the proxy. - -Also, starting from the Celo client 1.2 release, we will support assigning multiple proxies per validator. This provides better uptime for the validator for the case of a proxy going down. Also, it will help with making each proxy enode URL less public by only sharing it with a subset of the other validators. - - -The communication protocol between the validator and it's proxies implemented in release 1.2 is NOT backwards compatible to the pre-1.2 protocol. So if the proxy or validator is being upgraded to 1.2, then both needs to be upgraded to that version. Note that validators and proxies using release 1.2 are still compatible with remote nodes. - - -There are two ways to specify the proxy information to a validator. It can be done on validator startup via the command line argument, or by the rpc api when the validator is running. - - -## RPC API - -- `istanbul.addProxy(, )` can be used on the validator to add a proxy to the validator's proxy set -- `istanbul.removeProxy()` can be used on the validator to remove a proxy from the validator's proxy set -- `istanbul.proxies` can be used on the validator to list the validator's proxy set - -- `istanbul.proxiedValidators` can be used on the proxies to list the proxied validators \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/run/mainnet.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/run/mainnet.mdx deleted file mode 100644 index 40080f19e1..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/run/mainnet.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Running a Validator" -sidebarTitle: "Mainnet Validator" -og:description: How to get a Validator node running on the Celo Mainnet. ---- - -How to get a Validator node running on the Celo Mainnet. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## What is a Validator? - -Validators help secure the Celo network by participating in Celo’s proof-of-stake protocol. Validators are organized into Validator Groups, analogous to parties in representative democracies. A Validator Group is essentially an ordered list of Validators. - -Just as anyone in a democracy can create their own political party, or seek to get selected to represent a party in an election, any Celo user can create a Validator group and add themselves to it, or set up a potential Validator and work to get an existing Validator group to include them. - -While other Validator Groups will exist on the Celo Network, the fastest way to get up and running with a Validator will be to register a Validator Group, register a Validator, and affliate that Validator with your Validator Group. The addresses used to register Validator Groups and Validators must be unique, which will require that you create two accounts in the step-by-step guide below. - -Because of the importance of Validator security and availability, Validators are expected to run a "proxy" node in front of each Validator node. In this setup, the Proxy node connects with the rest of the network, and the Validator node communicates only with the Proxy, ideally via a private network. - -[Read more about Celo's mission and why you may want to become a Validator.](https://medium.com/celoorg/calling-all-chefs-become-a-celo-validator-c75d1c2909aa) - This article still uses the term Celo Gold which is the deprecated name for the Celo native asset, which now is referred to simply as "Celo" or preferably "CELO". \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/security.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/security.mdx deleted file mode 100644 index 82ebc7c812..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/security.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Run Secure Nodes and Services" -sidebarTitle: "Nodes and Services" -og:description: Recommendations for running secure Celo nodes and services. ---- - -Recommendations for running secure Celo nodes and services. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - - -Running Celo nodes and services securely, especially as part of running a validator, is of utmost importance. Failure to do so can lead to severe consequences including, but not limited to loss of funds, slashing due to double signing, etc. - - -### RPC Endpoints - -Celo nodes can be interacted with through an RPC interface for common interactions such as querying the blockchain, inspecting network connectivity and much more. The RPC interface is exposed via HTTP, WebSockets or a local IPC socket. There are two considerations: - -1. There is no authentication in the RPC interface. Anyone with access to the interface will be able to execute any actions that are enabled with the command-line options. This includes sensitive RPC modules like `personal` which interacts with the private keys stored on the node (`admin` is another one). It is not recommended to enable RPC modules unless you explicitly need them. Other RPC modules might be less sensitive but could create unnecessary load on your machine (like the `debug` module) to execute a DoS attack. - -2. If you do need access to the RPC modules (for example to use `celocli` or the attestation service), use a firewall and similar mechanisms to restrict access to the RPC interface. You almost never want the interface to be accessible from outside the machine itself. - -### Public Endpoints - -Beyond the RPC interface, Celo nodes and services have other interfaces that actually need to be exposed to the public internet. While varying degrees of protection exist within the software, such as validating attestation requests against the blockchain or monitoring connections in the discovery protocol, additional measures are recommended to reduce the impact of malicious traffic. Examples include, but are not limited to: - -- **DDoS protection:** Protected public endpoints from a DDoS attack is highly recommended to allow valid requests to be served -- **Whitelist endpoints:** The attestation service exposes a limited number of paths to function correctly. You could use a reverse proxy to reject paths that don't match them. \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/troubleshooting-faq.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/troubleshooting-faq.mdx deleted file mode 100644 index 514f6e3c73..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/troubleshooting-faq.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Validator FAQ" -sidebarTitle: "Validator FAQ" -og:description: Answers to frequently asked questions while troubleshooting issues as a Validator. ---- - -Answers to frequently asked questions while troubleshooting issues as a Validator. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## How do I reset my local Celo state? - -You may desire to reset your local chain state when updating parameters or wishing to perform a clean reset. Note that this will cause the node to resync from the genesis block which will take a couple hours. - -```bash -# Remove the celo state directory -sudo rm -rf celo -``` - -## How do I backup a local Celo private key? - -It's important that local accounts are properly backed up for disaster recovery. The local keystore files are encrypted with the specified account password and stored in the keystore directory. To copy this file to your local machine you may use ssh: - -```bash -ssh USERNAME@IPADDRESS "sudo cat /root/.celo/keystore/" > ./nodeIdentity -``` - -You can then back this file up to a cloud storage for redundancy. - - -It's important that you use a strong password to encrypt this file since it will be held in potentially insecure environments. - - -## How do I install and use celocli on my node? - -To install celocli on a Linux machine, run the following: - -```bash -sudo apt-get update -sudo apt-get install libusb-1.0-0 -y -sudo npm install -g @celo/celocli --unsafe-perm -``` - -To install celocli on a Mac/Windows machine, run the following: - -```bash -npm install @celo/celocli -``` - -You can then run celocli and point it to your local geth.ipc file: - -```bash -# Check if node is synced using celocli -sudo celocli node:synced --node geth.ipc -``` \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/validator-explorer.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/validator-explorer.mdx deleted file mode 100644 index a605d90288..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/validator-explorer.mdx +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Validator Explorer -og:description: How to use the Validator Explorer to view Validator performance. ---- - -How to use the Validator Explorer to view Validator performance. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## Introduction to the Explorer - **Deprecated** - -You can interact with the Validator Explorer that allows you to have a complete view of how the different validators are performing. This is one resource voters may use to find validator groups to vote for. - -All of the existing validators and groups in the Celo network are included in this view. The default view shows all registered validator groups - if you click on any of the group names it will expand to show the validators affiliated with that group. You can also sort results by each column's value by clicking on the header field. - -If you are looking to see how your validator is performing, you should first find the group your validator is affiliated with. Then you can click on the group name to see your validator and the rest of the validators affiliated with this group. - -If you are running a validator group, one way to demonstrate your credibility to voters is claiming your validator badges by following the instructions [here](https://github.com/celo-org/website/blob/master/validator-badges/README.md). - -A critical element of this explorer is the Validator Group name, which can help voters recognize organizations or active community members. This name is fetched from the `account` information registered on-chain for your validator and validator group. In order to combat name impersonation, a group can register a domain claim within their metadata. This verification is done by adding a [TXT record](https://wikipedia.org/wiki/TXT_record) to their domain which includes a signature of their domain claim signed by their associated account. This claim is then verified by the validator explorer. Individual users may also verify a claim using `celocli account:get-metdata`. - -For example, if a group was run by the owners of `example.com`, they may want to register their Validator Group with the name `Example`. The name does not need to be the same as the name of your domain, but for simplicity we do so here. To give credence to this name, they may want to add a DNS claim. They can do this by adding a DNS claim to their metadata, claiming the URL `example.com`, while simultaneously adding a `TXT Record` to `example.com` that includes this claim signed by their group address. Let’s go through this example in detail, using a `ReleaseGold` contract as our validator group. - -Assuming you have already deployed your Validator Group via a `ReleaseGold` contract, you will need these environment variables set to claim your domain. - -### Environment variables - -| Variable | Explanation | -| ----------------------------------- | ------------------------------------------------------------------------------- | -| CELO_VALIDATOR_GROUP_RG_ADDRESS | The `ReleaseGold` contract address for the Validator Group | -| CELO_VALIDATOR_RG_ADDRESS | The `ReleaseGold` contract address for the Validator | -| CELO_VALIDATOR_SIGNER_ADDRESS | The address of the validator signer authorized by the validator account | -| CELO_VALIDATOR_GROUP_SIGNER_ADDRESS | The address of the validator (group) signer authorized by the validator account | - -First let's create the metadata file: - -```bash -# On your local machine -celocli account:create-metadata ./group_metadata.json --from $CELO_VALIDATOR_GROUP_RG_ADDRESS -``` - -Now we can set the group's name: - -```bash -# On your local machine -celocli releasecelo:set-account --contract $CELO_VALIDATOR_GROUP_RG_ADDRESS --property name --value Example.com -``` - -Now we can generate a claim for the domain associated with this name `example.com`: - -```bash -# On your local machine -celocli account:claim-domain ./group_metadata.json --domain example.com --from $CELO_VALIDATOR_GROUP_SIGNER_ADDRESS -``` - -This will output your claim signed under the provided signer address. This output should then be recorded via a `TXT Record` on your desired domain, so in this case we should add a `TXT Record` to `example.com` with this signed output. - -You can now view and simultaneously verify the claims on your metadata: - -```bash -# On your local machine -celocli account:show-metadata ./group_metadata.json -``` - -Take a look at the output and verify these claims look right to you. This tool also automatically verifies the signatures on claims you've added. - -Once that record is added, we can then register this metadata under on our `Validator Group` account for external validation. - -Before we do this, you may also want to associate some validators with this domain. The benefit of doing this is to extend your DNS claim to your validators as well, meaning your validators can also verifiably be associated with your domain. You could also do this by adding individual DNS claims for each validator, but this would require separate `TXT Record`s for each, which is inconvenient. Instead, you can simply associate the group and validators together under a single claim. - -In order to do so, you will need to claim each validator address on your group's metadata. You will also need to claim your group account on each of your validator's metadata to complete the association. We will run through an example of a single validator now: - -First lets claim the `validator` address from the `group` account: - -```bash -# On your local machine -celocli account:claim-account ./group_metadata.json --address $CELO_VALIDATOR_RG_ADDRESS --from $CELO_VALIDATOR_GROUP_SIGNER_ADDRESS -``` - -Now let's submit the corresponding claim from the `validator` account on the `group` account (note: if you followed the directions to set up the attestation service, you may have already registered metadata for your validator. If that is the case, skip the steps to create the `validator`'s metadata and just add the account claim.) - -```bash -# On your local machine -celocli account:create-metadata ./validator_metadata.json --from $CELO_VALIDATOR_RG_ADDRESS -celocli account:claim-account ./validator_metadata.json --address $CELO_VALIDATOR_GROUP_RG_ADDRESS --from $CELO_VALIDATOR_SIGNER_ADDRESS -``` - -And then host both metadata files somewhere reachable via HTTP. You can use a service like gist.github.com. Create two gists, each with the contents of the respective files and then click on the Raw button to receive the permalinks to the machine-readable file. If you had already registered a metadata URL for your `validator` you just need to update that registerd gist, so you can skip the `validator` metadata registration below. - -Now we can register these URLs on each account: - -```bash -# On your local machine -celocli releasecelo:set-account --contract $CELO_VALIDATOR_GROUP_RG_ADDRESS --property metaURL --value -celocli releasecelo:set-account --contract $CELO_VALIDATOR_RG_ADDRESS --property metaURL --value -``` - -If everything goes well users should be able to see your claims by running: - -```bash -# On your local machine -celocli account:get-metadata $CELO_VALIDATOR_GROUP_RG_ADDRESS -``` - -If everything went well, you should now have your group and validator associated with each other and with your associated domain! \ No newline at end of file diff --git a/_deprecated/what-is-celo/about-celo-l1/validator/voting.mdx b/_deprecated/what-is-celo/about-celo-l1/validator/voting.mdx deleted file mode 100644 index 06fe94d4ab..0000000000 --- a/_deprecated/what-is-celo/about-celo-l1/validator/voting.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Voting for Validator Groups -og:description: Overview of Validator elections for Validator groups including technical details, policies, and explorers. ---- - -Resources for Validator Groups elections including technical details, policies, and Validator explorers. - - -This page describes the historical Celo Layer 1 blockchain. It is useful for understanding Celo’s history, but does not reflect the current state of the network. As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo has transitioned to an Ethereum Layer 2. - - ---- - -## What are Validators? - -Validators play a critical role in the Celo protocol, determining which transactions get applied and producing new blocks. Selecting organizations that operate well-run infrastructure to perform this role effectively is essential for Celo's long-term success. - -The Celo community makes these decisions by locking CELO and voting for [Validator Groups](/what-is-celo/about-celo-l1/protocol/pos/validator-groups), intermediaries that sit between voters and Validators. Every Validator Group has an ordered list of up to 5 candidate Validators. Some organizations may operate a group with their own Validators in it; some may operate a group to which they have added Validators run by others. - - -If you would like to keep up-to-date with all the news happening in the Celo community, including validation, node operation and governance, please sign up to our [Celo Signal mailing list here](https://share.hsforms.com/1Qrhush1vSA2WIamd_yL4ow53n4j). - -You can add the [Celo Signal public calendar](https://calendar.google.com/calendar/u/0/embed?src=c_9su6ich1uhmetr4ob3sij6kaqs@group.calendar.google.com) as well which has relevant dates. - - -## Validator Elections - -[Validator elections](/what-is-celo/about-celo-l1/protocol/pos/validator-elections) are held every epoch (approximately once per day). The protocol elects a maximum of 110 Validators. At each epoch, every elected Validator must be re-elected to continue. Validators are selected [in proportion](/what-is-celo/about-celo-l1/protocol/pos/validator-elections#running-the-election) to votes received for each Validator Group. - -If you hold CELO, or are a beneficiary of a [`ReleaseGold` contract](/what-is-celo/using-celo/manage/release-gold) that allows voting, you can vote for Validator Groups. A single account can split their LockedGold balance to have outstanding votes for up to 10 groups. - -CELO that you lock and use to vote for a group that elects one or more Validators receives [epoch rewards](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards) every epoch (approximately every day) once the community passes a governance proposal enabling rewards. The initial level of rewards is anticipated to be around 6% per annum equivalent (but is subject to change). - -Unlike a number of Proof of Stake protocols, **CELO used for voting is never at risk**. The actions of the Validator Groups or Validators you vote for can cause you to receive lower or higher rewards, but the CELO you locked will always be available to be unlocked in the future. [Slashing](/what-is-celo/about-celo-l1/protocol/pos/penalties) in the Celo protocol applies only to Validators and Validator Groups. - -## Choosing a Validator Group - -As a CELO holder, you have the opportunity to impact the Celo network by voting for Validator Groups. As Validators play an integral role in securing Celo, it is crucial that voters choose groups that contribute to both the technical health of the network, as well as the community. Some factors to consider when deciding which Validator Group to vote for include: - -### Technical - -- **Proven identity:** Validators and groups can supply [verifiable DNS claims](/what-is-celo/about-celo-l1/validator/validator-explorer). You can use these to securely identify that the same entity has access both to the account of a Validator or group and the supplied DNS records. - -- **Can receive votes**: Validator Groups can receive votes up to a certain [voting cap](/what-is-celo/about-celo-l1/protocol/pos/validator-elections#group-voting-caps). You cannot vote for groups with a balance that would put it beyond its cap. - -- **Will get elected**: CELO holders only receive voter rewards during an epoch if their CELO is used to vote for a Validator Group that elects at least one Validator during that epoch. Put another way, your vote does not contribute to securing the network or earning you rewards if your group does not receive enough other votes to elect at least one Validator. - -- **Secure**: The operational security of Validators is essential for everyone's use of the Celo network. You can see scores under the "Master Validator Challenge" column in the Stake Off leaderboard. Scores of 80% or greater were awarded the "Master Validator" badge, indicating a serious proven commitment to operational security. - -- **Reliable**: Celo's consensus protocol relies on two-thirds of elected Validators being available in order to produce blocks and process transactions. Voter rewards are directly tied to the [uptime score](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-validator#calculating-uptime-score) of all elected Validators in the group for which the vote was made. Any period of consecutive downtime greater than a minute reduces a Validator's uptime score. - -- **No recent slashing:** When Validators and groups register, their Locked Gold becomes "staked", in that it is subject to penalties for conduct that could seriously adversely affect the health of the network. Voters' Locked Gold is never slashed, but voter rewards are affected by a group's [slashing penalty](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-validator#calculating-slashing-penalty), which is halved when a group or one of its Validators is slashed. Look for groups with a last slashing time long in the past, ideally `0` (never), and a slashing penalty value of `1.0`. - -- **Runs an Attestation Service**: The [Attestation Service](/legacy/protocol/identity/) is an important service that Validators can run that allows users to verify that they have access to a phone number and map it to an address. Supporting Validators that run this service makes it easier for new users to begin using Celo. - -- **Runs a Validator on Baklava**: A group that runs a Validator on the [Baklava](/build-on-celo/network-overview) helps maintain the testnet and verify that upgrades to the Celo Blockchain software can be deployed smoothly. - -### Community - -- **Promotes the Celo mission**: Celo's mission is to [build a monetary system that creates the conditions of prosperity for all](https://medium.com/celoorg/an-introductory-guide-to-celo-b185c62d3067). Consider Validator Groups that further this mission through their own activities or initiatives around financial inclusion, education and sustainability. - -- **Broadens Diversity**: The Celo community aims to be inclusive to the largest number of contributors, with the most varied and diverse backgrounds possible. Support that diversity by considering what new perspectives and strengths the teams you support offer. As well as the backgrounds and experiences of the team, consider that the network security and availability is improved by Validators operating at different network locations, on different platforms, and with different toolchains. - -- **Contributes to Celo:** Support Validator Groups that strengthen the Celo developer community, for example through building or operating services for the Celo ecosystem, participating actively in on-chain governance, and answering questions and supporting others, on [Discord](https://chat.celo.org) or the [Forum](https://forum.celo.org). - -## The Celo Foundation Voting Policy - -As described above, there are many criteria to consider when deciding which group to vote for. While it is highly recommended that all CELO holders do their independent research when deciding which group to vote for, another option is to vote for Validator Groups that have received votes from the Celo Foundation. - -The Celo Foundation has a [Validator Group voting policy](/what-is-celo/about-celo-l1/validator/celo-foundation-voting-policy) that it follows when voting with the CELO that it holds. This policy has been developed by the Foundation board and technical advisors with the express goal of promoting the long-term security and decentralization of the network. Validator Groups have an opportunity to apply for Foundation votes every 3 months, and a new cohort is selected based on past performance and contributions. - -You can find the [full set of Validator Groups currently receiving votes, and their addresses linked here](https://docs.google.com/spreadsheets/d/1ltVNkQfXW3lIZxXU52R3IXeD6w21oacWFVb3a-FYRBY/edit?usp=sharing). - -## Validator Explorers - -The Celo ecosystem includes a number of great services for browsing registered Validator Groups and Validators. - - -**Warning**: Exercise caution in relying on Validator-supplied names to determine their real-world identity. Malicious participants may attempt to impersonate other Validators in order to attract votes. - -Validators and groups can also supply [verifiable DNS claims](/what-is-celo/about-celo-l1/validator/validator-explorer), and the Celo Validator Explorer displays these. You can use these to securely identify that the same entity has access both to the account of a Validator or group and the supplied DNS records. - - -### [Celo Mondo Validator Explorer](https://mondo.celo.org/) ([cLabs](https://clabs.co)) - -The Celo Mondo "Staking" tab displays information for Mainnet Validators. - -### [Celovote Scores](https://celovote.com/scores) (WOTrust | celovote.com) - -Celovote shows a ranking of Validator groups based on their estimated annual rate of return (ARR). -The estimate is calculated based on past performance. - -### [Vido](https://vido.atalma.io/celo/block-map) ([Atalma](https://www.atalma.io/)) - -Vido is a block visualization and monitoring suite for Mainnet and the Baklava testnet. -It shows missed blocks and downtime for the Validator group set and subscribable metrics to get alerted if your Validator is no longer signing. \ No newline at end of file diff --git a/_deprecated/what-is-celo/celo-website.mdx b/_deprecated/what-is-celo/celo-website.mdx deleted file mode 100644 index d395554220..0000000000 --- a/_deprecated/what-is-celo/celo-website.mdx +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Celo Website -url: https://celo.org ---- \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/builders.mdx b/_deprecated/what-is-celo/joining-celo/builders.mdx deleted file mode 100644 index 085538966c..0000000000 --- a/_deprecated/what-is-celo/joining-celo/builders.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Celo Builders -sidebarTitle: "Builders" ---- - -Whether you're just starting or are an experienced developer, Celo offers a variety of ways for you to engage and grow your projects. - ---- - -## Builders in the Celo Ecosystem - -The Celo Builder Community is a global network of developers, entrepreneurs, and enthusiasts dedicated to building a regenerative digital economy that promotes prosperity for all. By joining, you'll have the opportunity to create onchain apps and tools that drive financial inclusion and support sustainable development on a global scale. - -## How to Get Involved - -There are several ways to get started as a builder on Celo: - -* **Join the Builder Community**: Connect with like-minded individuals on platforms like [Discord](https://discord.com/invite/celo) and the [Celo Forum](https://forum.celo.org/). You'll find channels dedicated to everything from smart contract development to mobile-first dApp creation. - -* **Participate in Hackathons**: Hackathons are an excellent way to challenge your skills, collaborate with other developers, and potentially win rewards for innovative solutions. Find ecosystem events on our community [event platform](https://celo.stand.lemonade.social/events). - -* **Contribute to Open Source Projects**: You can [contribute](/what-is-celo/joining-celo/contributors/overview) directly to Celo’s open-source codebase or build complementary projects. - -* **Apply for Grants**: Celo has grants programs, like [Prezenti](https://www.prezenti.xyz/) and [Celo Public Goods](https://www.celopg.eco/) which supports projects that align with its mission to provide financial services to the next billion people. - -* **Apply for an Accelerator**: Check out [Celo Camp](https://www.celocamp.com/), the accelerator focused on the Celo ecosystem. If you are not yet at that stage, they also offer [Startup Pathway](https://startup-pathway.mykajabi.com/) a program, that leads you through your first steps to becoming a founder. - -* **Access Exclusive Resources**: [Register as a Celo Builder](https://docs.google.com/forms/d/e/1FAIpQLSemO5Kbf8fzq70AtiZEPRkk040MmpmmyhRqeurAwuVWUg63tQ/viewform) to gain access to resources and support available to active builders on Celo. diff --git a/_deprecated/what-is-celo/joining-celo/code-of-conduct.mdx b/_deprecated/what-is-celo/joining-celo/code-of-conduct.mdx deleted file mode 100644 index 23e25316da..0000000000 --- a/_deprecated/what-is-celo/joining-celo/code-of-conduct.mdx +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Code of Conduct -url: https://celo.org/code-of-conduct ---- \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/cip-contributors.mdx b/_deprecated/what-is-celo/joining-celo/contributors/cip-contributors.mdx deleted file mode 100644 index 90fc466da1..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/cip-contributors.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Community Improvement Proposals -og:description: Join a community of developers, designers, dreamers, and doers building prosperity for everyone. -sidebarTitle: "CIP Contributors" ---- - -Celo's Improvement Proposals \(CIPs\) describe standards for the Celo platform, including the core protocol specifications, SDK, and contract standards. A CIP is a design document that should provide background information, a rationale for the proposal, detailed solution including technical specifications, and, if any, a list of potential risks. The proposer is responsible for soliciting community feedback and for driving consensus. - -Participation in the Celo project is subject to the [Code of Conduct](https://celo.org/code-of-conduct). - -## Submitting CIPs - -Draft all proposals following the template below and submit to the [CIPs repository](https://github.com/celo-org/celo-proposals) via a PR \(pull request\). - -CIP template: - -- **Summary:** Describe your proposal in 280 characters or less. -- **Abstract**: Provide a short description of the technical issue being addressed. -- **Motivation:** Clearly explain why the proposed change should be made. It should layout the current Celo protocol shortcomings it addresses and why doing so is important. -- **Specification:** Define and explain in detail the technical requirements for new features and/or changes proposed. -- **Rationale**: Explain the reasoning behind your approach. It should cover alternative approaches considered, related work, and trade-offs made. -- **Implementation:** For all proposals going through the governance process, this section should reference the code implementing the proposed change. It’s recommended to get community feedback before writing any code. -- **Risks:** Highlight any risks and concerns that may affect consensus, proof-of-stake, governance, protocol economics, the stability protocol, security, and privacy. - - -For questions, comments, and discussions please use the [Celo Forum](https://forum.celo.org/) or [Discord](https://chat.celo.org/). - \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/code-contributors.mdx b/_deprecated/what-is-celo/joining-celo/contributors/code-contributors.mdx deleted file mode 100644 index 2a27b055c9..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/code-contributors.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "Code Contributors" -sidebarTitle: "Code Contributors" -og:description: How to contribute to the Celo ecosystem as a member of the community. ---- -import {ColoredText} from "/snippets/ColoredText.jsx"; - -How to contribute to open source projects and further the growth of the Celo ecosystem. - ---- - -## How to Contribute - -Contributing to the Celo ecosystem through open-source projects is a valuable way to support public goods and connect with the community. Whether you're new to open-source or an experienced contributor, the guidelines below will help you get started. - - -For quick questions, check the docs or create a ticket in the [Celo Discord](https://discord.com/invite/celo). Please avoid filing an issue on GitHub just to ask a question; using the resources above will provide faster responses. - - -### Prerequisites - -To contribute to Celo, the following accounts are necessary: - -- [GitHub:](https://github.com/celo-org) Required for raising issues, contributing code, or editing documentation. -- [Discord:](https://discord.com/invite/celo) Required for engaging with the Celo community. - -### Getting Started - -Browse the [code](https://github.com/celo-org), raise an issue, or contribute a pull request. - -Look for issues that are tagged as "[good first issue](https://github.com/search?q=org%3Acelo-org+is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22&type=issues)", "[help wanted](https://github.com/search?q=org%3Acelo-org+is%3Aissue+is%3Aopen+label%3A%22help+wanted%22&type=issues)", or "[1 hour tasks](https://github.com/search?q=org%3Acelo-org+is%3Aissue+is%3Aopen+label%3A%221+hour+tasks%22&type=issues)". These labels will help you find appropriate starting points. If you want to dive deeper, explore other labels and TODOs in the code. - -### Working On An Issue - -1. Reach out to the repository maintainer to assign you to the issue. -2. Add a comment outlining your plan and timeline. -3. If someone is already assigned, check with the repo maintainer if they are still working on it. -4. Ensure no duplicate issues exist for the work you're planning. - -### Submitting Issues - -If you're interested in creating a new issue, first explore existing projects and ensure that the issue doesn't already exist. When submitting a new issue, follow these guidelines: - -1. Ensure the issue is placed in the correct repository. -2. Provide a clear and specific title. -3. Include a comprehensive description outlining the current and expected behavior. -4. Add relevant labels to categorize the issue. - -Tasks range from minor to major improvements. Based on your interests, skillset, and level of comfort with the code-base feel free to contribute where you see appropriate. Our only ask is that you follow the guidelines below to ensure a smooth and effective collaboration. - -## Contribution Workflow - -Celo uses a standard "contributor workflow" where changes are made through pull requests (PRs). This workflow enables peer review, easy testing, and social collaboration. - -Following these guidelines will help ensure that your pull request (PR) gets approved. Each protocol may have its own specific guidelines, so review them before contributing. Celo-specific contribution guidelines can be found [here](./overview.md). - -1. Fork the repository. Make sure you also [add an upstream](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork) to be able to update your fork. -2. Clone your fork to your computer. -3. Create a topic branch and name it appropriately. Starting the branch name with the issue number is a good practice and a reminder to fix only one issue in a Pull-Request (PR). -4. **Make your changes** adhering to the coding conventions described below. In general, a commit serves a single purpose and diffs should be easily comprehensible. For this reason do not mix any formatting fixes or code moves with actual code changes. -5. Commit your changes. See [How to Write a Git Commit Message](https://cbea.ms/git-commit/) article by Chris Beams. -6. Test your changes locally before pushing to ensure that what you are proposing is not breaking another part of the software. Check the repository for the needed tests. Your PR should contain unit and end-to-end tests and a description of how these were run. -7. Include changes to relevant documentation.. You should update the documentation based on your changes. -8. Push your changes to your remote fork (usually labeled as origin). -9. Create a pull-request (PR) on the repository. If it's not ready to review, make it a `Draft` PR. If the PR addresses an existing issue, include the issue number in the PR title in square brackets (for example, [#2374]). -10. Provide a **comprehensive description** of the problem addressed and changes made. Explain dependencies and backwards incompatible changes. -11. Add labels to identify the type of your PR. For example, if your PR fixes a bug, add the "bug" label. -12. If the PR address an existing issue, comment in the issue with the PR number. -13. Ensure your changes are reviewed. Request the appropriate reviewers. When in doubt, consult the CODEOWNERS file for suggestions.Let the project you are contributing to know in the issue comments on GitHub or using the Discord sever chat channels that your PR is ready for review. If you are a maintainer, you can choose reviewers, otherwise this will be done by one of the maintainers. -14. **Make any required changes** on your contribution from the reviewers' feedback. Make the changes, commit to your branch, and push to your remote fork. -15. When your PR is approved, validated, all tests pass and your branch has no conflicts, it can be merged. Again, this action needs to be done by a maintainer - usually the same person who approves will also merge it. - -You contributed to Celo! Congratulations and thanks! - - -If you've commented on an existing issue and have been waiting for a reply, or want to message us for any other reason, please use the [Celo Forum](https://forum.celo.org/) or [Discord](https://chat.celo.org/). - \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/documentation-contributors.mdx b/_deprecated/what-is-celo/joining-celo/contributors/documentation-contributors.mdx deleted file mode 100644 index 6784e7e203..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/documentation-contributors.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Documentation Contributors -og:description: How to contribute to the Celo documentation and help improve the ecosystem. ---- - -Help improve the Celo ecosystem by contributing to documentation and educational resources. - ---- - -import {YouTube} from '/snippets/YouTube.jsx'; - -## Why Documentation Matters - -Documentation contributors play a vital role in the Celo ecosystem by creating clear, accessible resources that help users, developers, and community members understand and use Celo technology. High-quality documentation is essential for adoption, education, and the overall growth of the ecosystem. - -Good documentation: - -- **Lowers barriers to entry** for newcomers -- **Improves developer experience** and productivity -- **Empowers users** to solve problems independently -- **Supports the community** by reducing the support burden -- **Helps explain** Celo's vision and technical implementation - -## How You Can Contribute - -There are many ways to improve Celo documentation, regardless of your technical expertise: - -### 1. Technical Documentation - -- Protocol specifications and architecture guides -- Integration guides and code samples - -### 2. User Guides and Tutorials - -- Step-by-step tutorials for beginners -- How-to guides for specific tasks -- Troubleshooting guides and FAQs -- Explainer articles for key concepts - -### 3. Documentation Maintenance - -- Update outdated information -- Fix broken links and references -- Improve organization and navigation -- Enhance readability and clarity - -## Getting Started - -### Edit an existing page - -To edit an existing page in the documentation: - -1. Navigate to the page you want to edit at [docs.celo.org](/) -2. Click **Edit this page** at the bottom of the page -3. Make your changes directly on GitHub -4. Write a clear commit message describing your changes -5. Select "Create a new branch and start a pull request" -6. Describe your changes in the Pull Request (PR) -7. Tag appropriate reviewers -8. Wait for approval and for the site build checks to pass before merging - -### Add/remove pages - -To add a new page to the documentation: - -1. Fork the [Celo Docs repository](https://github.com/celo-org/docs) -2. Add or delete pages in the appropriate location -3. Create a PR with your changes for the live version of the site -4. Update the "sidebars.js" file in the main folder: - - This file controls the navigation menu on the left side of the docs site - - Add or remove the appropriate files from the list - -### Content Guidelines - -When creating or editing documentation: - -- **Be accurate**: Verify all information, examples, and code snippets -- **Be clear**: Use simple language and avoid unnecessary jargon -- **Be comprehensive**: Cover topics thoroughly but concisely -- **Be structured**: Use proper headings, lists, and formatting -- **Be inclusive**: Write for a global audience with diverse backgrounds -- **Be helpful**: Anticipate questions and provide helpful resources - - -For questions, comments, and discussions please use the [Celo Forum](https://forum.celo.org/) or [Discord](https://chat.celo.org/). - \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/overview.mdx b/_deprecated/what-is-celo/joining-celo/contributors/overview.mdx deleted file mode 100644 index b2f66929d0..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/overview.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Celo Contributor Overview" -sidebarTitle: "Overview" -og:description: Join a community of developers, designers, dreamers, and doers building prosperity for everyone. ---- - -Celo is open source and welcomes participation from everyone. We strive to fulfill our [Community Tenets](https://celo.org/community) by being inclusive and empowering. All contributors must abide by Celo's [Code of Conduct](https://celo.org/code-of-conduct). - -## Ways to Contribute - -Our community welcomes contributors with diverse skills: - -- [**Code Contributors**](/what-is-celo/joining-celo/contributors/code-contributors) - Developers who improve Celo's protocol and infrastructure -- [**CIP Contributors**](/what-is-celo/joining-celo/contributors/cip-contributors) - Authors of Celo Improvement Proposals -- [**Documentation Contributors**](/what-is-celo/joining-celo/contributors/documentation-contributors) - Writers who create and maintain technical documentation - -## General Contribution Guidelines - -Whether you're contributing code, documentation, or other content, these principles apply: - -- **Fork the repository** - Always work in your own fork before submitting changes -- **Use PRs for changes** - Pull requests are preferred, especially for small changes like typos -- **Work in branches** - Use feature branches, not master/main, for ongoing work -- **Submit regularly** - For non-trivial work, submit PRs regularly to get feedback -- **Quality matters** - Double-check your work before submission -- **Be objective** - Remain fact-based and neutral in tone - -## PR Best Practices - -For effective contributions: - -- Create meaningful PRs with clear descriptions -- For works in progress, use "WIP" in the title -- Request appropriate reviewers (check CODEOWNERS when unsure) -- Explain dependencies and breaking changes -- Include relevant tests and documentation updates - -## Tutorial Contributions - -Share your Celo experience through blog posts: - -- Create files in the [blog directory](https://github.com/celo-org/docs/tree/main/blog) using format `YYYY-MM-DD-post-name.md` -- Include proper front matter (title, description, author info) -- Use `` to define post summaries -- For images, create a folder with the same naming convention containing your post (as index.md) and assets - - -For questions or discussions, use the [Celo Forum](https://forum.celo.org/) or [Discord](https://chat.celo.org/). - \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/release-process/attestation-service.mdx b/_deprecated/what-is-celo/joining-celo/contributors/release-process/attestation-service.mdx deleted file mode 100644 index 1cb8e61e77..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/release-process/attestation-service.mdx +++ /dev/null @@ -1,152 +0,0 @@ ---- -title: "Attestation Service Release Process" -sidebarTitle: "Attestation Service" -og:description: Details of the release process for updating the attestation service on the Celo platform. ---- - -Details of the release process for updating the attestation service on the Celo platform. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - - -This release process is currently in use. - - -## Versioning - -Releases of Attestation Service are made as needed. Releases are numbered according to semantic versioning, as described at [semver.org](https://semver.org). - -Development builds should be identified with `-dev`, and only one commit should exist with a released version `x.y.z` for any `(x, y, z)`. - -## Documentation - -Documentation is maintained in the [celo-org/docs](https://github.com/celo-org/docs) repo and is hosted on [docs.celo.org](/). - -## Identifying releases - -### Git branches - -Development is done on the `master` branch, which corresponds to the next major or minor version. Changes to be included in a patch release of an existing minor version are cherry-picked to that existing release branch. - -### Git tags - -Each release should be [created on Github](https://github.com/celo-org/celo-monorepo/releases) and tagged with the version number, e.g. `attestation-service-vX.Y.Z`. Each release should include a summary of the release contents, including links to pull requests and issues with detailed description of any notable changes. - -Tags should be signed and can be verified with the following command. - -```bash -git verify-tag attestation-service-vX.Y.Z -``` - -On Github, each release tag should have attached signatures that can be used to verify the Docker images. - -### Docker tags - -Each Docker image is tagged with `attestation-service-`. Just as a Git tag immutably points to a commit hash, the Docker tag should immutably point to an image hash. - -In addition, each Docker image corresponding to a released version should be tagged with `attestation-service-vX.Y.Z`. - -The latest image qualified for deployment to various networks are also tagged as follows: - -- Alfajores: `attestation-service-alfajores` -- Baklava: `attestation-service-baklava` -- Mainnet: `attestation-service-mainnet` - -### Signatures - -Artifacts produced by this build process (e.g. tags, Docker images) will be signed by a [core developer key](https://github.com/celo-org/celo-monorepo/blob/master/developer_key_publishing.md). - -Public keys for core developers are hosted on celo.org and can be imported to `gpg` with the following command: - -```bash -gpg --auto-key-locate wkd --locate-keys $EMAIL -``` - -Currently hosted core developer keys used for Attestation Service releases include: - -- tim@clabs.co - -## Build process - -### Docker images - -Docker images are built automatically with [Google Cloud Build](https://cloud.google.com/build) upon pushes to `master` and all release branches. Automated builds will be tagged in [Google Artifact Registry](https://cloud.google.com/artifact-registry) with the corresponding commit hash. - -A signature should be produced over the image automatically built at the corresponding commit hash and included with the Github release. - -Release image signatures can be verified with the following command: - -```bash -docker save $(docker image inspect us.gcr.io/celo-testnet/celo-monorepo:attestation-service-vX.Y.Z -f '{{ .Id }}') | gpg --verify attestation-service-vX.Y.Z.docker.asc - -``` - -## Testing - -As well as monorepo CI tests, all releases are expected to go through manual testing as needed to verify security properties, accuracy of documentation, and compatibility with deployed and anticipated versions of `celocli` and wallets including Valora. Releases currently involve coordinating with Valora to run the verification e2e tests in CI. - -## Promotion process - -### Source control - -Patch releases should be constructed by cherry-picking all included commits from `master` to the `release/attestation-service/x.y` branch, if necessary created from the `attestation-service-vX.Y.Z` tag of the most recent major or minor release. The first commit of this process should change the version number encoded in the source from `x.y.z` to `x.y.z+1-dev` and the final commit should change the version number to `x.y.z+1`. - -Major and minor releases should be constructed by pushing a commit to the `master` branch to change the encoded version number from `x.y.z-dev` to `x.y.z`. A `attestation-service-vX.Y.Z` tag should be created at this commit which uniquely references one commit; release notes should be published alongside this. The next commit should change the version number from `x.y.z` to `x.y+1.0-dev`, or `x+1.0.0-dev` if the next planned release is a major release. - -### Distribution - -Distribution of an image follows this schedule: - - - - - - - - - - - - - - - - - - -
DateAction
T-1w -
    -
  1. Deploy release candidate build to Alfajores testnet
    2. -
  2. Test manually and via e2e verification tests
    3. -
-
T -
    -
  1. Confirm Valora production and testing builds against Alfajores experience no issues and that e2e verification tests complete successfully
    2. -
  2. Publish the release notes and tag the relevant commit on GitHub
    3. -
  3. Tag released Docker image with attestation-service-alfajores, attestation-service-baklava, attestation-service-mainnet, and attestation-service-vX.Y.Z tags (removing tags from other releases)
    4. -
  4. Inform the community of the new release via Discord and the Celo Forum
    5. -
-
T+1w onwards -
    -
  1. Confirm Mainnet services have upgraded without issues
    2. -
  2. Continue monitoring dashboards for user issues
    3. -
-
- -### Emergency Patches - -Bugs which affect the security, stability, or core functionality of the Celo identity protocol or prevent new users onboarding to wallets including Valora may need to be released outside the standard release cycle. In this case, an emergency patch release should be created on top of all supported minor releases which contains the minimal change and corresponding test for the fix. - -If the issue is not exploitable, release notes should describe the issue in detail and the image should be distributed publicly. - -If the issue is exploitable and mitigations are not readily available, a patch should be prepared privately and signed binaries should be distributed from private commits. Establishing trust is key to pushing out the fix. An audit from a reputable third party may be contracted to verify the release to help earn that trust. - -## Vulnerability Disclosure - -Vulnerabilities in Attestation Service releases should be disclosed according to the [security policy](https://github.com/celo-org/celo-blockchain/blob/master/SECURITY.md). \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/release-process/base-cli-contractkit-dappkit-utils.mdx b/_deprecated/what-is-celo/joining-celo/contributors/release-process/base-cli-contractkit-dappkit-utils.mdx deleted file mode 100644 index 8936f8508b..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/release-process/base-cli-contractkit-dappkit-utils.mdx +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: "Release Process for CeloCLI and ContractKit" -sidebarTitle: "CeloCLI and ContractKit" -og:description: Details of the release process for updating CeloCLI and ContractKit on the Celo platform. ---- - -Details of the release process for updating CeloCLI and ContractKit on the Celo platform. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Versioning - -Use the standard MAJOR.MINOR.PATCH semantic versioning scheme described at [semver.org](http://semver.org). - -New releases can be expected as follows: - -- Major releases: approximately yearly -- Minor releases: approximately 8 times a year -- Patch releases: as needed - -Development builds will be identified as such: `x.y.z-dev`, and will be published as `x.y.z` when stable. - -## Identifying releases - -### NPM - -You can find the npm packages in the following places: - -- [@celo/celocli](https://www.npmjs.com/package/@celo/celocli) -- [@celo/contractkit](https://www.npmjs.com/package/@celo/contractkit) - -### Github tags - -To identify the commits included in a specific release and see which new features were added or bugs fixed, please refer to the [release notes](https://github.com/celo-org/celo-monorepo/releases) in the monorepo. Also to keep track of continual updates to the stable and dev versions of the packages, each package has a `CHANGELOG.md` file: [Celocli](https://github.com/celo-org/developer-tooling/blob/master/packages/cli/CHANGELOG.md) and [Contractkit](https://github.com/celo-org/developer-tooling/blob/master/packages/sdk/contractkit/CHANGELOG.md). -All releases should be tagged with the version number, e.g. `contractkit-vX.Y.Z`. Each release should include a summary of the release contents, including links to pull requests and issues with detailed description of any notable changes. - -### Communication - -The community will be notified of package updates through the following channels: - -For all releases: - -- Each package’s `CHANGELOG.md` file, as mentioned above -- Github releases page, as mentioned above -- [Discord](https://chat.celo.org): #developer-chat, #mainnet, and #sdk - -For major releases: - -- Twitter: [@CeloDevs](https://x.com/CeloDevs) -- Mailing list: cLabs’ Tech Sync -- [Celo Forum](https://forum.celo.org/) - - -## Testing - -All builds of these packages are automatically tested for performance and backwards compatibility in CI. Any regressions in these tests should be considered a blocker for a release. -Minor and major releases are expected to go through additional rounds of manual testing as needed to verify behavior under stress conditions. - - -Work in progress - - -## Promotion process - -- For a patch release: The first step of this process should be a commit that changes the version number encoded in the source from `x.y.z-dev` to `x.y.z+1-dev` and the final step should change the published version number from `x.y.z-1` to `x.y.z`. -- For minor releases, the same process should be followed, except the `y` value would increment, and the `z` value would become 0. -- For major releases, the same process should be followed, except the `x` value would increment, and `y` and `z` values would become 0. - -Only one commit should ever have a non-dev tag at any given version number. When that commit is created, a tag should be added along with release notes. Once the tag is published it should not be reused for any further release or changes. - -### Emergency patches - -Bugs which affect the security, stability, or core functionality of the network may need to be released outside the standard release cycle. In this case, an emergency patch release should be created on top of all supported minor releases which contains the minimal change and corresponding test for the fix. An emergency patch retro will also be published, and will include information such as why the patch was necessary and what code changes it includes. - -## Vulnerability Disclosure - -Vulnerabilities in any of these releases should be disclosed according to the [security policy](https://github.com/celo-org/celo-blockchain/blob/master/SECURITY.md). - -## Dependencies - -- @celo/mobile - Dappkit relies on this -- Celocli -- All the packages under the ["SDK" folder](https://github.com/celo-org/developer-tooling/tree/master/packages/sdk) -- These all rely on each other quite a bit, so triple-check that these packages weren’t affected by a change in another. - -## Dependents - -- Celocli -- All the packages under the ["SDK" folder](https://github.com/celo-org/developer-tooling/tree/master/packages/sdk) \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/release-process/blockchain-client.mdx b/_deprecated/what-is-celo/joining-celo/contributors/release-process/blockchain-client.mdx deleted file mode 100644 index 8323c8a520..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/release-process/blockchain-client.mdx +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: "Blockchain Client Release Process" -sidebarTitle: "Blockchain Client" -og:description: Details of the release process for updating the blockchain client on the Celo platform. ---- - -Details of the release process for updating the blockchain client on the Celo platform. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Versioning - -Releases of celo-blockchain are numbered according to semantic versioning, as described at [semver.org](https://semver.org). - -All builds are identified as `unstable` (a development build) or `stable` (a commit released as a particular version number). There should only ever exist one commit with a version `x.y.z-stable` for any `(x, y, z)`. - -### Signatures - -Artifacts produced by this build process (e.g. Docker images) will be signed by [cosign](https://github.com/sigstore/cosign). - -## Documentation - -The documentation for client features, such as APIs and commands, is maintained in the `docs` directory within the `celo-blockchain` repository. Documentation on protocol features, such as the proof-of-stake protocol, is hosted on [docs.celo.org](). - -## Identifying releases: - -### Git branches - -Each minor version of celo-blockchain has its own “release branch”, e.g. `release/1.0`. - -Development is done on the `master` branch, which corresponds to the next major or minor version. Changes to be included in a patch release of an existing minor version are cherry-picked to that existing release branch. - -### Git tags - -All releases should be tagged with the version number, e.g. `vX.Y.Z`. Each release should include a -summary of the release contents, including links to pull requests and issues with detailed -description of any notable changes. - -Tags should be signed and can be verified with the following command. - -```bash -git verify-tag vX.Y.Z -``` - -On Github, each release tag should link to the respective Docker image, along with signatures that -can be used to verify those images. - -### Docker tags - -Each released Docker image should be tagged with its version number such that for release `x.y.z`, the image should have tags `x`, `x.y`, and `x.y.z`, with the first two tags potentially being moved from a previous image. Just as a Git tag `x.y.z` immutably points to a commit hash, the Docker tag, `x.y.z` should immutably point to an image hash. - -## Build process - -### Docker images - -Docker images are built automatically with [Google Cloud Build](https://cloud.google.com/build) upon pushes to `master` and all release branches. Automated builds will be tagged in [Google Artifact Registry](https://cloud.google.com/artifact-registry) with the corresponding commit hash. - -A signature should be produced over the image automatically built at the corresponding commit hash and included with the GitHub release. - -Release image signatures can be verified with the following command: - -```bash -docker save $(docker image inspect us.gcr.io/celo-org/geth:X.Y.Z -f '{{ .Id }}') | gpg --verify celo-blockchain-vX.Y.Z.docker.asc - -``` - -## Testing - -All builds of `celo-blockchain` are automatically tested for performance and backwards compatibility in CI. Any regressions in these tests should be considered a blocker for a release. - -Minor and major releases are expected to go through additional rounds of manual testing as needed to verify behavior under stress conditions, such as a network with faulty nodes, and poor network connectivity. - -## Promotion process - -### Source control - -Patch releases should be constructed by cherry-picking all included commits from `master` to the `release/x.y` branch. The first commit of this process should change the version number encoded in the source from `x.y.z-stable` to `x.y.z+1-unstable` and the final commit should change the version number to `x.y.z+1-stable`. - -Major and minor releases should be constructed by pushing a commit to the `master` branch to change the encoded version number from `x.y.z-unstable` to `x.y.z-stable`. A `release/x.y` branch should be created from this commit. The next commit must change the version number from `x.y.z-stable` to `x.y+1.0-unstable`, or `x+1.0.0-unstable` if the next planned release is a major release. - -Only one commit should ever have a “stable” tag at any given version number. When that commit is created, a tag should be added along with release notes. Once the tag is published it should not be reused for any further release or changes. - -### Emergency Patches - -Bugs which affect the security, stability, or core functionality of the network may need to be released outside the standard release cycle. In this case, an emergency patch release should be created on top of all supported minor releases which contains the minimal change and corresponding test for the fix. - -If the issue is not exploitable, release notes should describe the issue in detail and the image should be distributed publicly. - -If the issue is exploitable and mitigations are not readily available, a patch should be prepared privately, and signed binaries should be distributed from private commits. Establishing trust is key to pushing out the fix. An audit from a reputable third party may be contracted to verify the release to help earn that trust. Once a majority of validators are updated, patch details can be made public. - -> Pushing an upgrade with this process will be disruptive to any nodes that do not upgrade quickly. It should _only_ be used when the circumstances require it. - -## Vulnerability Disclosure - -Vulnerabilities in `celo-blockchain` releases should be disclosed according to the [security policy](https://github.com/celo-org/celo-blockchain/blob/master/SECURITY.md)e \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/release-process/index.mdx b/_deprecated/what-is-celo/joining-celo/contributors/release-process/index.mdx deleted file mode 100644 index 53aa78f324..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/release-process/index.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Release Process" -sidebarTitle: "Overview" -og:description: Overview of the release process for updates to the Celo platform. ---- - - - -Overview of the release process for updates to the Celo platform. - - -It is critical that updates to the Celo platform can be released on a regular basis, and in a way that ensures the security and reliability of the Celo network. In order to facilitate this, the following release processes are published here. - - -- [Smart Contracts](/what-is-celo/joining-celo/contributors/release-process/smart-contracts) -- [Blockchain Client](/what-is-celo/joining-celo/contributors/release-process/blockchain-client) -- [CeloCLI and ContractKit](/what-is-celo/joining-celo/contributors/release-process/base-cli-contractkit-dappkit-utils) -- [Attestation Service](/what-is-celo/joining-celo/contributors/release-process/attestation-service) \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/contributors/release-process/smart-contracts.mdx b/_deprecated/what-is-celo/joining-celo/contributors/release-process/smart-contracts.mdx deleted file mode 100644 index 2531255982..0000000000 --- a/_deprecated/what-is-celo/joining-celo/contributors/release-process/smart-contracts.mdx +++ /dev/null @@ -1,503 +0,0 @@ ---- -title: "Smart Contracts Release Process" -sidebarTitle: "Smart Contracts" -og: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. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - - -This release process is a work in progress. Many infrastructure components required to execute it are not in place, and the process itself is subject to change. - - -## Versioning - -Each deployed Celo core smart contract is versioned independently, according to semantic versioning, as described at [semver.org](https://semver.org), with the following modifications: - -- STORAGE version when you make incompatible storage layout changes -- MAJOR version when you make incompatible ABI changes -- MINOR version when you add functionality in a backwards compatible manner, and -- PATCH version when you make backwards compatible bug fixes. - -Changes to core smart contracts are made via on-chain Governance, approximately four times a year. When a release is made, **all** smart contracts from the release branch that differ from the deployed smart contracts are released, and included in the **same** governance proposal. Each release is identified by a unique monotonically increasing version number `N`, with `1` being the first release. - -### Core Contracts - -Every deployed Celo core contract has its current version number as a constant which is publicly accessible via the `getVersionNumber()` function, which returns the storage, major, minor, and patch versions. The version number is encoded in the Solidity source and updated as part of code changes. - -Celo Core Contracts deployed to a live network without the `getVersionNumber()` function, such as the original set of core contracts, are to be considered version `1.1.0.0`. - -### Mixins and libraries - -Mixin contracts and libraries are considered part of the contracts that consume them. When a mixin or library has changed, all contracts that consume them should be considered to have changed as well, and thus the contracts should have their version numbers incremented and should be re-deployed as part of the next smart contract release. - -### 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`. - -### Release management in Git/Github - -Github branches/tags and Github releases are used to coordinate past and ongoing releases. Ongoing smart contract development is done on the `master` branch (even after release branches are cut). Every smart contract release has a designated release branch, e.g. `release/core-contracts/${N}` in the celo-monorepo. - -#### When a new release branch is cut: - -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. -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}` - -## 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. - - -For these to run, you may need to follow the [setup instructions](https://github.com/celo-org/celo-monorepo/blob/master/SETUP.md). These steps include installing Node and setting `nvm` to use the correct version of Node. Successful `yarn install` and `yarn build` in the protocol package signal a completed setup. - - -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. - -Typical script options: - -- By default, the scripts expect a celo-blockchain RPC at port 8545 locally. With `-f` you can specify the scripts to use a hosted forno node -- By default, scripts will output verbose logs under `/tmp/celo-${script-name}.log`. You can change the location of the log output with `-l file.log` - -### View the tagged releases for each network - -```bash -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. - -```bash -# Run from `packages/protocol` in the celo-monorepo -PREVIOUS_RELEASE="core-contracts.v${N-1}" -NETWORK=${"baklava"|"alfajores"|"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. - -### Check Backward Compatibility - -This script performs some automatic checks to ensure that the smart contract versions in the source code have been set correctly with respect to the latest release. It is run as part of CI and helps ensure that backwards incompatibilities are not accidentally introduced by requiring that devs manually update version numbers whenever smart contract changes are made. - -Specifically, it compiles the latest and candidate releases and compares smart contracts: - -1. Storage layout, to detect storage version changes -2. ABI, to detect major and minor version changes -3. Bytecode, to detect patch version changes - -Finally, it checks release candidate smart contract version numbers and requires that they have been updated appropriately since the latest release by following semantic versioning as defined in the [Versioning section](#versioning) above. - -The following exceptions apply: - -- If the STORAGE version has changed, it does not perform backward compatibility checks -- If the MAJOR version has changed, it checks storage layout compatibility but not ABI compatibility - -Critically, this ensures that proxied contracts do not experience storage -collisions between implementation versions. See [this -article](https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies#storage-collisions-between-implementation-versions) -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. - -```bash -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" -``` - -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. - -### 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. - -```bash -NETWORK=${"baklava"|"alfajores"|"mainnet"} -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" -``` - -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 - -Submit the autogenerated upgrade proposal to the Governance contract for review by voters, outputting a unique identifier. - -```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 -``` - -### Fetch Upgrade Proposal - -Fetch the upgrade proposal and output the JSON encoded proposal contents. - -```bash -# Make sure you run at least celocli 0.0.60 -celocli governance:show --proposalID --jsonTransactions "upgrade_proposal.json" -``` - -### 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. - -Additionally, include `initialization_data.json` from the CGP if any of the contracts have to be initialized. - -```bash -RELEASE_CANDIDATE="core-contracts.v${N}" -NETWORK=${"baklava"|"alfajores"|"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 -``` - -### 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: - -```bash -RELEASE="core-contracts.v${N}" -NETWORK=${"baklava"|"alfajores"|"mainnet"} -yarn release:verify-deployed -n $NETWORK -b $RELEASE -f -``` - -## Testing - -All releases should be evaluated according to the following tests. - -### Unit tests - -All changes since the last release should be covered by unit tests. Unit test coverage should be enforced by automated checks run on every commit. - -### Manual Checklist - -After a successful release execution on a testnet, the resulting network state should be spot-checked to ensure that no regressions have been caused by the release. Flows to test include: - -- Do a cUSD and CELO transfer - ```bash - celocli transfer:dollars --from --value --to - celocli transfer:celo --from --value --to - ``` -- Register a Celo account - ```bash - celocli account:register --from --name - ``` -- Report an Oracle rate - ```bash - celocli oracle:report --from --value - ``` -- Do a CP-DOTO exchange - ```bash - celocli exchange:celo --value --from - celocli exchange:dollars --value --from - ``` -- Complete a round of attestation -- Redeem from Escrow -- Register a Vaildator - ```bash - celocli validator:register --blsKey --blsSignature --ecdsaKey --from - ``` -- Vote for a Validator -- Run a mock election - ```bash - celocli election:run - ``` -- Get a valildator 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 - ``` - -### Automated environment tests - -Stakeholders can use the `env-tests` package in `celo-monorepo` to run an automated test suite against the network - -### Verify smart contracts - -Verification of smart contracts should be done both on https://celoscan.io/ and https://celo.blockscout.com/. - -1. [Update your Smart Contract on celoscan](/developer/verify/celoscan) -2. [Update your Smart Contract on Blockscout](/developer/verify/blockscout) - -### Performance - -A ceiling on the gas consumption for all common operations should be defined and enforced by automated checks run on every commit. - -For troubleshooting please see Readme.md of protocol package. - -### Backwards compatibility - -Automated checks should ensure that any new commit to `master` does not introduce a breaking change to storage layout, ABI, or other common backward compatibility issues unless the STORAGE or MAJOR version numbers are incremented. - -Backwards compatibility tests will also be run before every release to confirm that no breaking changes exist between the pending release and deployed smart contracts. - -### Audits - -All changes since the last release should be audited by a reputable third party auditor. - -### Emergency patches - -If patches need to be applied before the next scheduled smart contract release, they should be cherry-picked to a new release branch, branched from the latest deployed release branch. - -## Promotion process - -Deploying a new contract release should occur with the following process. On-chain governance proposals should be submitted on Tuesdays for consistency and predictability. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DateAction
T -
    -
  1. - Create a Github issue tracking all these checklist items as an audit - log -
    2. -
  2. - Implement the{" "} - git management steps{" "} - for when a new release branch is cut. -
    3. -
  3. - Submit the release branch to a reputable third party auditor for review. -
    4. -
  4. Begin drafting release notes.
    5. -
-
T+1w -
    -
  1. Receive report from auditors.
    2. -
  2. Add audit summary to the final draft of the release notes.
    3. -
  3. - If all issues in the audit report have straightforward fixes: -
      -
    1. - {" "} - Submit a governance proposal draft using this [format: ](https://github.com/celo-org/celo-proposals/blob/master/CGPs/template.md) -
      2. -
    2. - {" "} - Add any initialization data to the CGP that should be included as - part of the proposal -
      3. -
    3. - {" "} - Announce forthcoming smart contract release on: - https://forum.celo.org/c/governance -
      4. -
    -
    4. -
  4. Commit audit fixes to the release branch
    5. -
  5. Submit audit fixes to auditors for review.
    6. -
  6. - Tag the first release candidate commit according to the{" "} - - git release management instructions - - . -
    7. -
  7. - Let the community know about the upcoming release proposal by posting - details to the Governance category on https://forum.celo.org and cross - post in the{" "} - Discord #governance channel. - See the 'Communication guidelines' section below for information on what - your post should contain. -
    8. -
-
T+2w -
    -
  1. - On Tuesday: Run the{" "} - smart contract release script{" "} - in order to to deploy the contracts to Baklava as well as submit a - governance proposal. -
      -
    • - Transition proposal through Baklava governance process. -
      • -
    • - Update your forum post with the Baklava PROPOSAL_ID, - updated timings (if any changes), and notify the community in the - Discord #governance channel. -
      • -
    -
    2. -
-
T+3w -
    -
  1. Confirm all contracts working as intended on Baklava.
    2. -
  2. - Run the{" "} - - smart contract release script - {" "} - in order to to deploy the contracts to Alfajores as well as submit a - governance proposal. -
    3. -
  3. - Update your forum post with the Alfajores PROPOSAL_ID, - updated timings (if any changes), and notify the community in the - Discord #governance channel. -
    4. -
-
T+4w -
    -
  1. Confirm all contracts working as intended on Alfajores.
    2. -
  2. - Confirm audit is complete and make the release notes and forum post - contain a link to it. -
    3. -
  3. - On Tuesday: Run the{" "} - - smart contract release script - {" "} - in order to to deploy the contracts to Mainnet as well as submit a - governance proposal. -
    4. -
  4. - Update the corresponding governance proposal with the updated on-chain{" "} - PROPOSAL_ID and mark CGP status as "PROPOSED". -
    5. -
  5. - Update your forum post with the Mainnet PROPOSAL_ID, - updated timings (if any changes), and notify the community in the - Discord #governance channel. -
    6. -
  6. - At this point all stakeholders are encouraged to{" "} - verify the proposed contracts - deployed match the contracts from the release branch. -
    7. -
  7. - Monitor the progress of the proposal through the{" "} - governance process. -
      -
    • - Currently the governance process should take approximately 1 week: - 24 hours for the dequeue process, 24 hours for the approval - process, and 5 days for the referendum process. After which, the - proposal is either declined or is ready to be executed within 3 - days. -
      • -
    • - For updated timeframes, use the celocli:{" "} - celocli network:parameters -
      • -
    -
    8. -
-
T+5w -
    -
  1. - If the proposal passed: -
      -
    1. Confirm all contracts working as intended on Mainnet.
      2. -
    2. - Update your forum post with the Mainnet governance outcome ( - Passed or Rejected) and notify the - community in the Discord #governance channel. -
      3. -
    3. Change corresponding CGP status to EXCECUTED.
      4. -
    4. - Merge the release branch into master with a merge - commit -
      5. -
    -
  2. - If the proposal failed: -
      -
    1. Change corresponding CGP status to EXPIRED.
      2. -
    -
    3. - -
-
- -If the contents of the release (i.e. source Git commit) change at any point after the release has been tagged in Git, the process should increment the release identifier, and process should start again from the beginning. If the changes are small or do not introduce new code (e.g. reverting a contract to a previous version) the audit step may be accelerated. - -### Communication guidelines - -Communicating the upcoming governance proposal to the community is critical and may help getting it approved. - -Each smart contract release governance proposal should be accompanied by a [Governance category](https://forum.celo.org/c/governance/) forum post that contains the following information: - -- Name of proposer (individual contributor or organization). -- Background information. -- Link to the release on Github. -- Link to the audit report(s). -- Anticipated timings for the Baklava and Alfajores testnets and Mainnet. - -It's recommended to post as early as possible and at minimum one week before the anticipated Baklava testnet governance proposal date. - -Make sure to keep the post up to date. All updates (excluding fixing typos) should be communicated to the community in the [Discord](http://chat.celo.org/) `#governance` channel. - -### Emergency patches - - -Work in progress - - -## Vulnerability Disclosure - -Vulnerabilities in smart contract releases should be disclosed according to the [security policy](https://github.com/celo-org/celo-blockchain/blob/master/SECURITY.md). - -## Dependencies - -None - -## Dependents - - -Work in progress - \ No newline at end of file diff --git a/_deprecated/what-is-celo/joining-celo/daos.mdx b/_deprecated/what-is-celo/joining-celo/daos.mdx deleted file mode 100644 index 1d402a8737..0000000000 --- a/_deprecated/what-is-celo/joining-celo/daos.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Celo Regional DAOs -sidebarTitle: "Regional DAOs" ---- - -import {ColoredText} from "/snippets/ColoredText.jsx"; - - -As of March 2025, the **Regional DAOs** have established a **Regional Council** to coordinate shared funding and enhance collaboration with the Celo Foundation. - -You can read more in the latest proposal: [Celo Regional Council H1 2025](https://forum.celo.org/t/celo-regional-council-h1-2025/10063). - -The **landscape of Regional DAOs is constantly evolving**, so stay updated by following discussions in the **[Celo Forum](https://forum.celo.org/)**. - - -Regional DAOs are community-driven organizations that operate autonomously, focusing on local development and empowering communities to use and build on Celo. Explore the many ways to get involved. - ---- - -## How Regional DAOs Are Furthering Celo's Mission - -Regional DAOs have been an essential part of Celo's growth. They onboard builders, developers and users into the ecosystem by hosting IRL events, providing mentorship and governance. - -Each regional DAO has a different focus which might change over time, but the general idea is to further Celo's mission for Prosperity for All on the ground. - -### Celo Africa DAO - -Celo Africa DAO, [launched in April 2023](https://forum.celo.org/t/celo-africa-dao-report-may-june-july/6385) , has been building a huge network of builders and founders on the ground in Africa and was able to maintain and grow it through showing up consistently. If you live in one of the listed countries below, make sure to connect and to try joining one of the IRL events. Read up on the reports and proposals in the [Celo Forum](https://forum.celo.org/u/celoafricadao/summary). - -Reach out to the main DAO or the chapters on [Twitter](https://x.com/CeloAfricaDao) or [Telegram](https://t.me/CeloAfrica). - -#### Local Chapters - -- [Celo Ghana](https://x.com/Celo_Ghana) -- [Celo Kenya](https://x.com/CeloKenya) -- [Celo Nigeria](https://x.com/CeloNigeria) -- [Celo South Africa](https://x.com/CeloSouthAfrica) -- [Celo Uganda](https://x.com/CeloUganda) - -### Celo Europe DAO - -Celo Europe DAO launched in [June 2023](https://forum.celo.org/t/celo-europe-dao-s0-report/7050) , has been hosting events and fostering the community around ReFi and RWA protocols as well as Celo Gather and supporting other Ecosystem DAOs with similar events. Read up on the reports and proposals in the [Celo Forum](https://forum.celo.org/search?q=celo%20europe%20dao). - -- [Twitter](https://x.com/CeloEurope) - -### Koh Celo (Celo Thailand DAO) DAO - -Koh Celo has been launched in the [beginning of 2024](https://forum.celo.org/t/kohcelo-celo-thailand-dao-project-for-road-to-devcon-h1-2024-regional-dao-final/7402) , starting off by proposing a program for the Road to DevCon 2024. Read up on the reports and proposals in the [Celo Forum](https://forum.celo.org/search?q=KohCelo). - -- [Twitter](https://x.com/KohCelo) - -### CeLatam - -CeLatam has been launched in the [April 2023](https://forum.celo.org/t/celatam-season-0-report/7870) , starting off by proposing a program for the Road to DevCon 2024. Read up on the reports and proposals in the [Celo Forum](https://forum.celo.org/u/celatam/summary). - -Reach out to them on [Twitter](https://x.com/CeLatamOrg). - -### Celo Columbia - -Reach out to them on [Twitter](https://x.com/Celo_Col). - -### Celo Mexico - -Reach out to them on [Twitter](https://x.com/celomexico). - -### Celo PH DAO - -Reach out to them on [Twitter](https://x.com/celophdao). - -### Celo Korea - -Reach out to them on [Twitter](https://x.com/CeloKorea). - -### Celo Türkiye - -Reach out to them on [Twitter](https://x.com/TrCelo). - -### Celo Arabia - -Reach out to them on [Twitter](https://x.com/CeloArabia). - -### Celo India - -Reach out to them on [Twitter](https://x.com/Celo_India). - -## Get Involved with Regional DAOs - -By participating in a Regional DAO, you can contribute to the growth of the Celo ecosystem in your local area. Each DAO offers opportunities for developers, entrepreneurs, and community members to collaborate, share ideas, and drive impactful projects. Explore your region’s DAO to see how you can get involved and help further Celo’s mission of financial inclusion and sustainability. - -For more information on how to join or collaborate with a Regional DAO, visit the [Celo Forum](https://forum.celo.org/) or [Discord](https://discord.com/invite/celo) to connect with the community. diff --git a/_deprecated/what-is-celo/joining-celo/index.mdx b/_deprecated/what-is-celo/joining-celo/index.mdx deleted file mode 100644 index 443e0dbef6..0000000000 --- a/_deprecated/what-is-celo/joining-celo/index.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Joining Celo -sidebarTitle: "Overview" ---- - -Explore the many ways to engage with the Celo ecosystem and contribute to its growth. - ---- - -Welcome to the Celo Ecosystem! Whether you're a user, developer, founder, or contributor, there are numerous ways to engage and make a meaningful impact. This guide will help you explore the various opportunities available within the Celo community, from using innovative applications to contributing to open-source projects, and participating in governance. Dive in to discover how you can be a part of Celo's mission to create a more inclusive financial system. - -### As a User - -- [**Explore Projects on Celo:**](/showcase) Start using and engaging with Celo apps. -- [**Follow updates from the Celo Foundation on Medium**](https://medium.com/@celoorg) - -### As a Builder - -- [**Register as an active Celo builder:**](https://docs.google.com/forms/d/e/1FAIpQLSemO5Kbf8fzq70AtiZEPRkk040MmpmmyhRqeurAwuVWUg63tQ/viewform) Access exclusive resources and support. -- [**Join our builder community:**](/what-is-celo/joining-celo/builders) Connect with other builders in the ecosystem. -- [**Contribute to open source projects:**](/what-is-celo/joining-celo/contributors/code-contributors) Help grow Celo by contributing to key projects. -- [**Get involved in a local chapter:**](/what-is-celo/joining-celo/daos) Attend in-person workshops for mentoring and support. -- [**Participate in Celo Public Goods:**](https://www.celopg.eco/) Explore ongoing funding rounds. -- [**Get your page added**](https://github.com/celo-org/docs/blob/main/src/data/users.tsx) to our [**dApp showcase page**](/showcase). -- [**Introduce your project**](https://forum.celo.org/) in the [**Celo Forum**](https://forum.celo.org/) in the founders' category. -- [**Apply to Celo Camp:**](https://www.celocamp.com/) Join the accelerator focused on scaling apps on Opera MiniPay. -- [**Engage with Celo DAOs:**](/what-is-celo/joining-celo/daos) Gain user feedback, access networking opportunities, and validate your project. -- [**Apply for Prezenti Grants:**](https://www.prezenti.xyz/) Explore grant opportunities. -- Check out community resources for helpful tips to raise capital. - -### As a Contributor - -- [**Participate in governance:**](/what-is-celo/using-celo/protocol/governance/overview) Engage in current discussions and connect with the ecosystem. -- [**Participate in the community:**](https://calendar.google.com/calendar/u/0/r?cid=c_asn0b4c1emdgsq3urlh2ei2dig@group.calendar.google.com) Add the Community Calendar -- [**Contribute to local chapters:**](/what-is-celo/joining-celo/daos) Connect with the community, offer support, and mentor others. -- [**Sign up for Celo Signal:**](https://share.hsforms.com/1Qrhush1vSA2WIamd_yL4ow53n4j) If you are a Node Operator, Dapp Running Its Own Node, Exchange or Custodian, Owner who is Staking and Participating in Governance, or a Core Developer or Contributor - ---- - -## Social Media - -Follow to stay updated with the latest news about Celo. - -- [Celo on X](https://x.com/Celo) -- [Celo Devs on X](https://x.com/CeloDevs) -- [cLabs on X](https://x.com/cLabs) -- [Farcaster](https://farcaster.xyz/celo) -- [Reddit](https://www.reddit.com/r/celo/) -- [GitHub](https://github.com/celo-org/celo-monorepo) -- [Medium Blogs](https://medium.com/@celoorg) -- [LinkedIn](https://www.linkedin.com/company/celo-foundation) -- [Instagram](https://www.instagram.com/celoorg/) -- [YouTube](https://youtube.com/channel/UCCZgos_YAJSXm5QX5D5Wkcw) -- [Twitch](https://www.twitch.tv/celoorg) - -## Discussions - -Ask questions, find answers, and connect with the community. - -- [Celo Developer Chat on Discord](https://chat.celo.org/) -- [Celo Official Telegram](https://t.me/celoplatform) -- [Celo Builder Telegram](https://t.me/buildwithcelo) -- [Celo Forum](https://forum.celo.org/) -- [Celo Subreddit](https://www.reddit.com/r/celo/) diff --git a/_deprecated/what-is-celo/using-celo/bridged_tokens/tokens.mdx b/_deprecated/what-is-celo/using-celo/bridged_tokens/tokens.mdx deleted file mode 100644 index 2ff4cb070f..0000000000 --- a/_deprecated/what-is-celo/using-celo/bridged_tokens/tokens.mdx +++ /dev/null @@ -1,24 +0,0 @@ -| Symbol | Token Name | Contract Addresses | -| ------ | ---------- | ------------------ | -| 1INCH | 1INCH Token | L1: [0x111111111117dC0aa78b770fA6A738034120C302](https://etherscan.io/token/0x111111111117dC0aa78b770fA6A738034120C302)
L2: [0x28ba8d26f5f6710f42170ee545a0c953ca4997b9](https://celoscan.io/token/0x28ba8d26f5f6710f42170ee545a0c953ca4997b9) | -| AAVE | Aave Token | L1: [0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9](https://etherscan.io/token/0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9)
L2: [0xF6A54aff8c97f7AF3CC86dbaeE88aF6a7AaB6288](https://celoscan.io/token/0xF6A54aff8c97f7AF3CC86dbaeE88aF6a7AaB6288) | -| ACX | Across Protocol Token | L1: [0x44108f0223A3C3028F5Fe7AEC7f9bb2E66beF82F](https://etherscan.io/token/0x44108f0223A3C3028F5Fe7AEC7f9bb2E66beF82F)
L2: [0x3a05ef6467309f388f90bcc3d79a522e6c39fabb](https://celoscan.io/token/0x3a05ef6467309f388f90bcc3d79a522e6c39fabb) | -| LINK | Chainlink | L1: [0x514910771af9ca656af840dff83e8264ecf986ca](https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca)
L2: [0xf630876008a4ed9249fb4cac978ba16827f52e91](https://celoscan.io/token/0xf630876008a4ed9249fb4cac978ba16827f52e91) | -| CRV | Curve DAO Token | L1: [0xD533a949740bb3306d119CC777fa900bA034cd52](https://etherscan.io/token/0xD533a949740bb3306d119CC777fa900bA034cd52)
L2: [0x75184c282e55a7393053f0b8F4F3E7BeAE067fdC](https://celoscan.io/token/0x75184c282e55a7393053f0b8F4F3E7BeAE067fdC) | -| crvUSD | Curve.Fi USD Stablecoin | L1: [0xf939E0A03FB07F59A73314E73794Be0E57ac1b4E](https://etherscan.io/token/0xf939E0A03FB07F59A73314E73794Be0E57ac1b4E)
L2: [0x9efd56a126a0e3a8782db5fd5adb23a8dd9023c6](https://celoscan.io/token/0x9efd56a126a0e3a8782db5fd5adb23a8dd9023c6) | -| DAI | Dai Stablecoin | L1: [0x6B175474E89094C44Da98b954EedeAC495271d0F](https://etherscan.io/token/0x6B175474E89094C44Da98b954EedeAC495271d0F)
L2: [0xac177de2439bd0c7659c61f373dbf247d1f41abe](https://celoscan.io/token/0xac177de2439bd0c7659c61f373dbf247d1f41abe) | -| DOLA | Dola USD Stablecoin | L1: [0x865377367054516e17014CcdED1e7d814EDC9ce4](https://etherscan.io/token/0x865377367054516e17014CcdED1e7d814EDC9ce4)
L2: [0x31f01af056b7e829bd41e59e8ba3d2313d2b0ff3](https://celoscan.io/token/0x31f01af056b7e829bd41e59e8ba3d2313d2b0ff3) | -| GTC | Gitcoin | L1: [0xde30da39c46104798bb5aa3fe8b9e0e1f348163f](https://etherscan.io/token/0xde30da39c46104798bb5aa3fe8b9e0e1f348163f)
L2: [0xa80e318dc786c58b8bcb692579764f56f89ab27e](https://celoscan.io/token/0xa80e318dc786c58b8bcb692579764f56f89ab27e) | -| LUSD | LUSD Stablecoin | L1: [0x5f98805a4e8be255a32880fdec7f6728c6568ba0](https://etherscan.io/token/0x5f98805a4e8be255a32880fdec7f6728c6568ba0)
L2: [0xef6379fa3090310862a42f6c732dba2f20880f0a](https://celoscan.io/token/0xef6379fa3090310862a42f6c732dba2f20880f0a) | -| LDO | Lido DAO Token | L1: [0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32](https://etherscan.io/token/0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32)
L2: [0x6981f932c2ec5f9e15d44d7ef46859a133f544dd](https://celoscan.io/token/0x6981f932c2ec5f9e15d44d7ef46859a133f544dd) | -| MKR | Maker | L1: [0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2](https://etherscan.io/token/0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2)
L2: [0x918b13745de61380d5d3efddf51244c369f101d5](https://celoscan.io/token/0x918b13745de61380d5d3efddf51244c369f101d5) | -| POOL | PoolTogether | L1: [0x0cec1a9154ff802e7934fc916ed7ca50bde6844e](https://etherscan.io/token/0x0cec1a9154ff802e7934fc916ed7ca50bde6844e)
L2: [0xe00892b8636f0c7450177f89717539d656d870fb](https://celoscan.io/token/0xe00892b8636f0c7450177f89717539d656d870fb) | -| rETH | Rocket Pool ETH | L1: [0xae78736cd615f374d3085123a210448e74fc6393](https://etherscan.io/token/0xae78736cd615f374d3085123a210448e74fc6393)
L2: [0x55f3d16e6bd2b8b8e6599df6ef4593ce9dcae9ed](https://celoscan.io/token/0x55f3d16e6bd2b8b8e6599df6ef4593ce9dcae9ed) | -| RPL | Rocket Pool Protocol | L1: [0xD33526068D116cE69F19A9ee46F0bd304F21A51f](https://etherscan.io/token/0xD33526068D116cE69F19A9ee46F0bd304F21A51f)
L2: [0x73a363ed1526f5e02be99f51c59400a2c508312c](https://celoscan.io/token/0x73a363ed1526f5e02be99f51c59400a2c508312c) | -| sDAI | Savings Dai | L1: [0x83F20F44975D03b1b09e64809B757c47f942BEeA](https://etherscan.io/token/0x83F20F44975D03b1b09e64809B757c47f942BEeA)
L2: [0x4c430944d20410a16d5cec69b0cb66541b00a817](https://celoscan.io/token/0x4c430944d20410a16d5cec69b0cb66541b00a817) | -| XAUt | Tether Gold | L1: [0x68749665FF8D2d112Fa859AA293F07A622782F38](https://etherscan.io/token/0x68749665FF8D2d112Fa859AA293F07A622782F38)
L2: [0x3776228836bfcfc87cac36c28830b67759c02707](https://celoscan.io/token/0x3776228836bfcfc87cac36c28830b67759c02707) | -| UMA | UMA Voting Token v1 | L1: [0x04Fa0d235C4abf4BcF4787aF4CF447DE572eF828](https://etherscan.io/token/0x04Fa0d235C4abf4BcF4787aF4CF447DE572eF828)
L2: [0x4672ecbd03a1f93dd67310caecd3a8ef6397e72a](https://celoscan.io/token/0x4672ecbd03a1f93dd67310caecd3a8ef6397e72a) | -| UNI | Uniswap | L1: [0x1f9840a85d5af5bf1d1762f925bdaddc4201f984](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984)
L2: [0xeE571697998ec64e32B57D754D700c4dda2f2a0e](https://celoscan.io/token/0xeE571697998ec64e32B57D754D700c4dda2f2a0e) | -| WLD | Worldcoin | L1: [0x163f8C2467924be0ae7B5347228CABF260318753](https://etherscan.io/token/0x163f8C2467924be0ae7B5347228CABF260318753)
L2: [0x88c400d871829e381b53b55eee79145b4287461a](https://celoscan.io/token/0x88c400d871829e381b53b55eee79145b4287461a) | -| WBTC | Wrapped BTC | L1: [0x2260fac5e5542a773aa44fbcfedf7c193bc2c599](https://etherscan.io/token/0x2260fac5e5542a773aa44fbcfedf7c193bc2c599)
L2: [0x8aC2901Dd8A1F17a1A4768A6bA4C3751e3995B2D](https://celoscan.io/token/0x8aC2901Dd8A1F17a1A4768A6bA4C3751e3995B2D) | -| WETH | Wrapped Ether | L1: [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)
L2: [0xD221812de1BD094f35587EE8E174B07B6167D9Af](https://celoscan.io/token/0xD221812de1BD094f35587EE8E174B07B6167D9Af) | diff --git a/_deprecated/what-is-celo/using-celo/index.mdx b/_deprecated/what-is-celo/using-celo/index.mdx deleted file mode 100644 index 9a5c7fbf4e..0000000000 --- a/_deprecated/what-is-celo/using-celo/index.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Using Celo -og:description: A guide to using the Celo platform - from getting started to advanced operations -sidebarTitle: "Overview" ---- - - - -A comprehensive guide to using the Celo platform, from acquiring assets to managing them. - ---- - -## Introduction to Celo - -Celo makes it easy to transact with anyone around the world. Whether you're sending, receiving, swapping, or bridging assets, Celo provides a user-friendly ecosystem with fast transactions at a fraction of the cost of other crypto platforms. - -Celo is designed for fast, low-cost payments worldwide, making global financial tools accessible to anyone. Holders of CELO tokens can also participate in network governance, helping shape the platform's future. - -## Key Features - -### Gas Fees & Asset Acquisition - -Celo offers flexible gas fees that can be paid in various tokens (CELO, cUSD, cEUR, and even ETH in some wallets). This makes onboarding simpler for users new to crypto. - -- [Learn about gas fees and getting CELO](/what-is-celo/using-celo/gas-fees) -- Acquire Celo assets on [major exchanges](https://coinmarketcap.com/currencies/celo/markets/) - -### Cross-Chain Bridges - -Move assets between Celo and other blockchain networks like Ethereum, Polygon, and Solana using bridges: - -- [View all available bridges](/what-is-celo/using-celo/bridges) -- Popular options include [Squid Router](https://v2.app.squidrouter.com/), and [SmolRefuel](https://smolrefuel.com/?outboundChain=42220) (gas-free) - -### Decentralized Exchanges - -Swap and trade assets within the Celo ecosystem: - -- [Explore Celo exchanges](/what-is-celo/using-celo/exchanges) -- Popular choices include [Uniswap](https://app.uniswap.org/), [Ubeswap](https://app.ubeswap.org/#/swap), and [Mento](https://app.mento.org/) for stablecoin swaps - -### Asset Management - -- [Self-Custody CELO](/what-is-celo/using-celo/manage/self-custody) - Securely manage your own keys -- [ReleaseGold](/what-is-celo/using-celo/manage/release-gold) - Understand time-locked CELO distributions -- [Asset Management](/what-is-celo/using-celo/manage/asset) - Advanced asset operations - -## Participating in the Network - -As a Celo token holder, you can actively participate in the network's governance: - -- [Voting on Governance](/what-is-celo/using-celo/protocol/governance/voting-in-governance) - Participate in Celo governance decisions -- [Governance Parameters](/what-is-celo/using-celo/protocol/governance/governable-parameters) - Reference all governable parameters - -## Getting Support - -For questions, comments, and discussions, connect with the Celo community: - -- [Celo Forum](https://forum.celo.org/) -- [Discord](https://chat.celo.org/) - - -New to Celo? Start with the [Celo Overview](/home) for a complete introduction to the platform. - \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/manage/asset.mdx b/_deprecated/what-is-celo/using-celo/manage/asset.mdx deleted file mode 100644 index 55969e831a..0000000000 --- a/_deprecated/what-is-celo/using-celo/manage/asset.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Asset Management" -sidebarTitle: "Asset Management" -og:description: Access and account management for holding, exchanging, or sending Celo Dollars (cUSD) and Mento stablecoins. ---- - -Access and account management for holding, exchanging, or sending Celo Dollars (cUSD) and Mento stablecoins. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Prerequisites - -This guide assumes: - -- You have read [Key Management](/what-is-celo/about-celo-l1/validator/key-management/summary) on Celo -- You have installed the [Celo Command Line Interface](/cli/) (Celo CLI) - -## Choose a Node - -In order to execute the tasks listed below, you will need to point the Celo CLI to a node that is synchronized with the [Mainnet](/build-on-celo/network-overview). - -## Create an Account - -There are two ways to create an account: - -- (Recommended) use [accounts generated by Ledger](/wallet/ledger/setup), if you possess a [Ledger hardware wallet](https://shop.ledger.com/products/ledger-nano-s) -- Use CLI to [generate an account](/cli/account#celocli-accountnew) -- this approach is less secure and hence not recommended - -After creating an account, record its address in environment variables: - -```shell -export CELO_ACCOUNT_ADDRESS= -``` - -## Exchange CELO for Mento Stablecoins - -Once you have deposited CELO to your account, you can check your balance: - -```shell -celocli account:balance $CELO_ACCOUNT_ADDRESS -``` - -As an example of a common stablecoin swap, you can exchange CELO for cUSD using the following command. This exchanges CELO for stable tokens (cUSD by default) via the stability mechanism. Note that the unit of value is CELO Wei (1 CELO = 10^18 CELO Wei). - -```shell -celocli exchange:celo --value --from $CELO_ACCOUNT_ADDRESS -``` - -## Transfer Mento Stablecoins - -When you have sufficient balance, you can send Mento stablecoins such as cUSD to other accounts. Note that the unit of value is cUSD Wei (1 cUSD = 10^18 cUSD Wei). - -```shell -celocli transfer:dollars --from $CELO_ACCOUNT_ADDRESS --to --value -``` \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/manage/exchange.mdx b/_deprecated/what-is-celo/using-celo/manage/exchange.mdx deleted file mode 100644 index 67c448bae5..0000000000 --- a/_deprecated/what-is-celo/using-celo/manage/exchange.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Exchange Celo Assets -og:description: How to use the Celo exchange bot to exchange CELO and Celo stable tokens. -sidebarTitle: "Exchange Assets" ---- - -How to use the Celo exchange bot to exchange CELO and Celo stable tokens. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - - -The celo-exchange-bot is currently not being maintained. If you want to use please check and update dependencies to solve potential security vulnerabilities of old dependencies - - -## Celo Exchange Bot - -CELO (previously Celo Gold) can be exchanged for Celo stable tokens (e.g. Celo Dollar or Celo Euro) using Mento, an automated market maker that powers the [stability protocol](/what-is-celo/about-celo-l1/protocol/stability/doto). Mento is a Constant Product Market Maker (CPMM) that allows you to exchange CELO for Celo stable tokens and vice versa. Sales of Celo stable tokens to Mento in exchange for CELO burn the Celo stable tokens from supply, and sales of CELO to Mento in exchange for Celo stable tokens mint Celo stable tokens into supply. Trades with Mento incur slippage, meaning that Mento exchanges move the price out of favor of the trader. Generally, larger trade amounts incur more significant amounts of slippage. Mento also resets the price of CELO quoted in the Celo stable token every few minutes according to a [price oracle](/what-is-celo/about-celo-l1/protocol/stability/oracles). - -Because of slippage and the Mento price occasionally changing according to a price oracle, those who wish to mint Celo stable tokens into supply may wish to slowly sell CELO for Celo stable tokens over time, rather than in a single exchange. Executing a smaller volume exchange every few seconds over a period of time is likely to result in less slippage when minting Celo stable tokens. [celo-exchange-bot](https://github.com/celo-org/celo-exchange-bot) was created to easily allow community members to exchange CELO for Celo stable tokens over a period of time to avoid incurring significant amounts of slippage. - -## Running the bot - -[celo-exchange-bot](https://github.com/celo-org/celo-exchange-bot) is intended to be operated by the exchanger as it requires access to the source key, which must own CELO funds to exchange and is the account that performs the exchanges. Operating the bot requires some technical knowledge of dealing with keys and operating infrastructure. Currently, the bot requires the source key to be an HSM in Azure's Key Vault service. Information on how to use an Azure Cloud HSM can be found [here](/integration/cloud-hsm). - -See the repository's [README](https://github.com/celo-org/celo-exchange-bot) for information on building a Docker image and configurating the bot. Example infrastructure using Azure's [Container Instances](https://azure.microsoft.com/en-gb/services/container-instances/) is also provided in the repository [here](https://github.com/celo-org/celo-exchange-bot/tree/master/infrastructure-example). While the bot does require Azure Key Vault to be used for the source key and the provided example infrastructure is ran on Azure, the bot itself can be ran from anywhere as long as it's able to access its Azure Key Vault Cloud HSM. \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/manage/release-gold.mdx b/_deprecated/what-is-celo/using-celo/manage/release-gold.mdx deleted file mode 100644 index 726f7aa9a5..0000000000 --- a/_deprecated/what-is-celo/using-celo/manage/release-gold.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: "Understanding ReleaseGold" -sidebarTitle: "Release Gold" -og:description: Introduction to ReleaseGold including examples, use cases, and FAQ. ---- - -Introduction to ReleaseGold including examples, use cases, and FAQ. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## What is ReleaseGold? - -[`ReleaseGold`](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol) is a smart contract that enables CELO to be released programmatically to a beneficiary over a period of time. In a deployed `ReleaseGold` smart contract, only the CELO balance that has been released according to the release schedule can be withdrawn by the contract’s beneficiary. The unreleased CELO cannot be withdrawn, but can be used for specific functions in Celo’s Proof of Stake protocol, namely voting and validating. - -The intent of the `ReleaseGold` contract is to allow beneficiaries to participate in Celo’s Proof of Stake protocol with CELO that has not yet been fully released to them. Beneficiaries are able to lock CELO for voting and validating with the full `ReleaseGold` balance, including both released and unreleased CELO. - -Increasing the volume of CELO that can be used in Celo’s Proof of Stake consensus promotes network security and even greater decentralization. See below for details on specific features of the `ReleaseGold` contract, as well as how they are implemented. The [source code](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol) includes documentation, and technical readers are encouraged to find further details there. - -### Example - -To illustrate with an example, let’s consider a `ReleaseGold` contract deployed with a total balance of 100 CELO. For example purposes, we’ll assume this contract enables both voting and validating. - -Let's also assume the beneficiary is an individual who is receiving CELO based on a vesting schedule (or a ‘release schedule’). According to this release schedule, the beneficiary will receive 10% of the total CELO balance each month. - -In three months time after deployment, there will be 30 released CELO in the contract, because 10 CELO (10% of 100 CELO) was released each month, for 3 months. Now, the beneficiary can transfer this 30 CELO freely. - -The beneficiary does not yet have full rights to the remaining 70 unreleased CELO. However, this 70 CELO while unavailable for withdrawal, can still be used by the beneficiary for voting and validating. This unreleased balance will also continue to release at the rate of 10 CELO per month, until the total balance is empty. - -## Addresses Involved - -_Beneficiary_ - -The `beneficiary` address is the recipient of the CELO in the `ReleaseGold` contract. As the CELO is released over time, it is incrementally made withdrawable solely to the beneficiary. The beneficiary is also able to use both unreleased and released CELO to participate in Celo’s Proof of Stake consensus protocol, via locking gold and voting or validating. - -_Release Owner_ - -The `releaseOwner` is the address involved in administering the `ReleaseGold` contract. The release owner may be able to perform actions including [setting the liquidity provision](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol#L268) for the contract, setting the maximum withdrawal amount, or [revoking](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/ReleaseGold.sol#L362) the contract, depending on the ReleaseGold configuration. - -_Refund Address_ - -The `refundAddress` is the address where funds that have not been released will be sent if a `ReleaseGold` contract is revoked. Contracts that are not revocable do not have a `refundAddress`. - -## Use Cases for `ReleaseGold` - -Two anticipated use cases for `ReleaseGold` contracts are for “holders” and “earners”. Note that these are not specified in `ReleaseGold` explicitly, rather they represent sample configurations that the `ReleaseGold` contract supports. - -In the “holder” case, a recipient may have purchased or been awarded an amount of CELO, but is subject to a distribution schedule limiting the amount of CELO that can be liquidated at any given time. These recipients may be able to validate and vote with the full `ReleaseGold` balance, and also are not subject to the contract’s revocation by another party (eg. an employer). - -In the “earner” case, a grant recipient may have entered a legal contract wherein an exchange of services earns them an amount of CELO over a releasing, or vesting, schedule. These grants are characterized by extra restrictions because the total grant amount is still being _earned_. The `ReleaseGold` balance cannot be used for running a validator, but it can be used to vote for validators and governance proposals on the Celo network. Additionally, these contracts may be revocable and may be subject to the `liquidityProvision` flag, which prevents CELO distribution when markets are incapable of absorbing additional CELO without significant slippage. - -## Release Schedule - -In `ReleaseGold` smart contracts, a fixed amount of CELO becomes accessible to the `beneficiary` over time. - -The following arguments specify a ReleaseGold smart contract schedule: - -{/* make the below text code block because crowdin is messing it up */} - -- `releasePeriod` - the frequency, in seconds, at which CELO is released - - Some common values: monthly (2628000), every 3 months (7884000) -- `amountReleasedPerPeriod` - the amount of CELO to be released each `releasePeriod` -- `numReleasePeriods` - the number of `releasePeriods` in which CELO will be released -- `releaseCliff` - the time at which the release cliff expires. - -The total balance for the ReleaseGold account can be determined by multiplying the `numReleasePeriods` by `amountReleasedPerPeriod`. - -Similar to vesting-type schedules with cliffs used for other assets, ReleaseGold allows for a `releaseCliff` (expressed in seconds) before which the released CELO cannot be withdrawn by its beneficiary. A common value for this is `31536000`, which is 1 year. - -## Released and Unreleased CELO - -In deployed `ReleaseGold` accounts, you can conceptually think of CELO in two states -- released, and unreleased. There are other states including locked, but for the purposes of the contract, these are the two primary states to consider. - -Released CELO can be withdrawn to the `beneficiary` where it can be used freely. Unreleased CELO comes with some restrictions. Foremost, it cannot be withdrawn by the beneficiary. If `canVote` and `canValidate` are set to false, the beneficiary cannot vote or validate, respectively. - -If the contract permits voting and validating using the unreleased balance, the specific keys to perform these actions must first be authorized. For example, if the `beneficiary` desires to vote using their `ReleaseGold` contract, they must authorize a voting key to vote on the contract’s behalf. - -## FAQ - -Can I vote for validators, or run a validator using my `ReleaseGold` CELO balance? - -- Keep in mind that in a `ReleaseGold` contract, there is both released CELO, and unreleased CELO. You can always vote or validate with the released balance if you are the beneficiary. However, for unreleased CELO, you can only vote or validate if `canVote` or `canValidate` properties are respectively set to true on the contract . - -Can the `releaseOwner` access my CELO? - -- No, the `releaseOwner` cannot make transactions with the CELO balance in a `ReleaseGold` contract. However, they can perform some administrative functions if the permissions are given at time of deployment. For example, a `releaseOwner` cannot revoke a contract unless the property `revocable` is set to true when the contract is deployed. -- It is highly recommended to review the contract at its deployed address, to learn specific details of a `ReleaseGold` contract. - -Can I move the CELO released by the `ReleaseGold` contract to another address? - -- Of course! Once CELO is released and the cliff has passed, the beneficiary is free to do what they want with it. - -Why do I need to authorize separate keys for voting and validating? Can’t I do it using the private key for my beneficiary address? - -- You may use any keys for your voting and validating signers, so long as those keys are not for a registered account or for another signing purpose. This means you _could_ use your `beneficiary` address as one of your signing roles, but you would need another account for an additional role. - -Can I change the beneficiary? - -- Yes, but changing the beneficiary requires signatures from both the `releaseOwner` and the current `beneficiary` of the `ReleaseGold` contract. This is implemented as a two out of two multisig contract. - -What if I lose the private key associated with the beneficiary address? - -- Unfortunately, if you lose the private key for the beneficiary address, then you won't be able to access your funds. Please be careful in ownership of this key, as it’s loss is irreversible. - -What happens if there is a bug in the `ReleaseGold` contract? - -- The `ReleaseGold` contract has been reviewed by security firms, and has passed smart contract audits. That said, if any unforeseen bugs are found, it is possible to modify the contract and redeploy it. This process requires a 2/2 multisig agreement from both `releaseOwner` and `beneficiary`. - -What is the distribution ratio? - -- Some grants are subject to “distribution schedules,” which control the release of funds outside of a traditional vesting schedule for legal reasons. This schedule is controlled by the `distributionRatio` and is adjustable by the `releaseOwner`. \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/manage/self-custody.mdx b/_deprecated/what-is-celo/using-celo/manage/self-custody.mdx deleted file mode 100644 index 892f95939a..0000000000 --- a/_deprecated/what-is-celo/using-celo/manage/self-custody.mdx +++ /dev/null @@ -1,435 +0,0 @@ ---- -title: Self-Custody CELO -og:description: Account access and reward details for self-custodying holder of CELO on the Celo Mainnet. ---- - -Account access and reward details for self-custodying holder of CELO on the Celo Mainnet. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## Prerequisites - -This guide assumes: - -- You are self-custodying (you hold the private key to your address), and that you have provided that address directly to cLabs. If you are using a custody provider ([Anchorage](https://anchorage.com), [CoinList](https://coinlist.co), or others), please contact them for directions. - -- Your address is the beneficiary of a [ReleaseGold](/what-is-celo/using-celo/manage/release-gold) contract, which releases CELO programmatically to a beneficiary over a period of time. - -- You have been informed by cLabs that the `ReleaseGold` instance corresponding to your address has been deployed. - -- You have your private key held on a [Ledger Nano S or Ledger Nano X](/wallet/ledger/setup) device, and you have a second such device available for managing a voting key. If you only have a single Ledger available, see [below](#using-a-single-ledger). - - -**Warning**: Self-custodying keys have associated security and financial risks. Loss or theft of keys can result in irrecoverable loss of funds. This guide also requires technical knowledge. You should be comfortable with using a Command Line Interface (CLI) and understand the basics of how cryptographic network accounts work. - - -## Support - -If you have any questions or need assistance with these instructions, please contact cLabs or ask in the `#celo-holders` channel on [Celo's Discord server](https://chat.celo.org). Remember that Discord is a public channel: never disclose recovery phrases (also known as backup keys, or mnemonics), private keys, unsanitized log output, or personal information. - -Please refer to the [Ledger Troubleshooting](/wallet/ledger/to-celo-cli#troubleshooting) for issues using Ledgers with the Celo CLI. - -## Outline - -In this guide, you will: - -- Install the Celo CLI (and optionally, a local node to connect to the network) -- Access the `ReleaseGold` account associated with your address using your existing Ledger -- Authorize a voting key, which you will hold on a new, second Ledger -- Lock some of the Gold in your `ReleaseGold` account -- Use that Locked CELO to vote for Validator Groups to operate Celo's [Proof of Stake](/what-is-celo/about-celo-l1/protocol/pos/) network (and in doing so be ready to receive epoch rewards of 6% when the community enables them in a forthcoming governance proposal) - -## Preparing Ledgers - -You will need: - -- Your **Beneficiary Ledger**: One Ledger Nano S or X configured with your beneficiary key (used to produce the address you supplied cLabs). Once you have completed this guide, this will become a "cold wallet" that you can keep offline most of the time. - -- Your **Vote Signer Ledger:** One Ledger Nano S or X configured with a new, unused key. This will become a "warm wallet" you can use whenever you want to participate in validator elections or governance proposals. - -As a first step, follow [these instructions](/wallet/ledger/setup) for both Ledgers to install the Ledger Celo app, obtain and verify the associated addresses, and (recommended) run a test transaction on the Alfajores test network. - - -The latest version of the Celo Ledger app is 1.1.8. If you are already using a Ledger with an earlier version installed, please [upgrade](/wallet/ledger/setup). - - -The remainder of this guide assumes you are using the first address available on each Ledger. You can add the flags described in [these instructions](/wallet/ledger/setup) to commands below to use different addresses. - -### Using a single Ledger - -If you only have a single Ledger, and are comfortable losing the security advantage of keeping the beneficiary key offline when voting, you can configure a second address on the same Ledger as your voting key. - -First, read [these instructions](/wallet/ledger/setup) carefully. Then, wherever you see instructions to connect your Vote Signer Ledger, for each command line containing `--useLedger` also add `--ledgerCustomAddresses "[1]"`. If in doubt, [ask for help](#support). - -## Deployment - -If you haven't already, open a terminal window and install the [Celo CLI](/cli/): - -```bash - npm install -g @celo/celocli -``` - -If you have previously installed the CLI, ensure that you are using version 0.0.47 or later: - -```bash -celocli --version -``` - -And if not, upgrade by running the same command as above. - -You will now need to point the Celo CLI to a node that is synchronized with the [Mainnet](/build-on-celo/network-overview) network. There are two options: - -- **Local Celo Blockchain node**: You can run a full node on your local machine which will communicate - with other nodes and cryptographically verify all data it receives. Since this approach does not require you to trust the network, it is most secure. - - To do this, follow the tutorial for [running a full node](/cel2/operators/run-node) (and make sure to pass `--usb`). - - Then run: - - ```bash - celocli config:set --node http://localhost:8545 - ``` - -- **cLabs-operated node**: As an alternative to using your own node, you can use an existing transaction - node service. Forno, operated by cLabs, is one example. While this approach does not require you to deploy a node locally, it requires you to trust cLabs and the remote Forno nodes (in the same way you would trust a centralized web service). An attacker may be able to manipulate data returned to you from the service, which the CLI may rely on to complete operations. - - To use Forno, run this command: - - ```bash - celocli config:set --node https://forno.celo.org - ``` - -## Locate and verify your `ReleaseGold` contract address - -First, copy the beneficiary address into the clipboard, and set it in an environment variable: - -```bash -export CELO_BENEFICIARY_ADDRESS= -``` - -Next, you will find the address of the `ReleaseGold` contract deployed for your beneficiary address. The `ReleaseGold` contract has its own address and is separate from the beneficiary address, but there are certain aspects of it that can be controlled only by the beneficiary. For more details, please refer to the [Understanding ReleaseGold page](/what-is-celo/using-celo/manage/release-gold). - -Open the list of [all ReleaseGold deployments](https://storage.googleapis.com/celo-website/releasegold/CeloMainnetReleaseGoldAll.json) and locate your address (use Edit>Find in your browser, then paste the beneficiary address). Copy the matching value next to `ContractAddress` into your clipboard. - -If you cannot locate your address in these mappings, please contact cLabs. - -If you have more than one beneficiary address, you'll want to step through this guide and complete the steps for each one separately. - -Record the value of the `ContractAddress` in an environment variable: - -```bash -export CELO_RG_ADDRESS= -``` - -You should find your beneficiary account already has a very small CELO balance to pay for transaction fees (values are shown in wei, so For example, 1 CELO = 1000000000000000000): - -```bash -celocli account:balance $CELO_BENEFICIARY_ADDRESS -``` - -Next, check the details of your `ReleaseGold` contract: - -```bash -celocli releasecelo:show --contract $CELO_RG_ADDRESS -``` - -Verify the configuration, balance, and beneficiary details. You can find an explanation of these parameters on the [ReleaseGold](/what-is-celo/using-celo/manage/release-gold) page. - -If any of these details appear to be incorrect, please contact cLabs, and do not proceed with the remainder of this guide. - -If the configuration shows `canVote: true`, your contract allows you to participate in electing Validator Groups for Celo's Proof of Stake protocol, and potentially earn epoch rewards for doing so. Please continue to follow the remainder of this guide (or you can come back and continue at any time). - -Otherwise, you're all set. You don't need to take any further action right now. - -## Authorize Vote Signer Keys - -To allow you to keep your Beneficiary Ledger offline on a day-to-day basis, it’s recommended to use a separate [Authorized Vote Signer Account](/what-is-celo/about-celo-l1/validator/key-management/detailed#authorized-vote-signers) that will vote on behalf of the beneficiary. - - -A vote signer can either be another Ledger device or a cloud Hardware Security Module (HSM). Explore [this guide](/integration/cloud-hsm) to learn more about cloud HSM setup and celocli integration. - - -This is a two step process. First, you create a "proof of possession" that shows that the holder of the beneficiary key also holds the vote signer key. Then, you will use that when the beneficiary signs a transaction authorizing the vote signer key. This proves to the Celo network that a single entity holds both keys. - - -Connect your **Vote Signer Ledger** now, unlock it, and open the Celo application. - - -First, obtain your vote signer address: - -```bash -# Using the Vote Signer Ledger -celocli account:list --useLedger -``` - -Your address is listed under `Ledger Addresses`. Create an environment variable for your vote signer address. - -```bash -export CELO_VOTE_SIGNER_ADDRESS= -``` - -Then create the proof of possession: - -```bash -# Using the Vote Signer Ledger -celocli account:proof-of-possession --signer $CELO_VOTE_SIGNER_ADDRESS --account $CELO_RG_ADDRESS --useLedger -``` - -The Ledger `Celo app` will ask you to confirm the transaction. Toggle right on the device until you see `Sign Message` on screen. Press both buttons at the same time to confirm. - -Take note of the signature produced by the `proof-of-possession` command and create an environment variable for it. - -```bash -export CELO_VOTE_SIGNER_SIGNATURE= -``` - -Now switch ledgers. - - -Connect your **Beneficiary Ledger** now, unlock it, and open the Celo application. - - -Next, register the `ReleaseGold` contract as a “Locked CELO” account: - -```bash -# Using the Beneficiary Ledger -celocli releasecelo:create-account --contract $CELO_RG_ADDRESS --useLedger -``` - -You'll need to press right on the Ledger several times to review details of the transactions, then when the device says "Accept and send" press both buttons together. - -Check that the `ReleaseGold` contract address is associated with a registered Locked CELO Account: - -```bash -celocli account:show $CELO_RG_ADDRESS -``` - -Now, using the proof-of-possession you generated above, as the Locked CELO Account account, you will authorize the vote signing key to vote on the Locked CELO Account's behalf: - -```bash -# Using the Beneficiary Ledger -celocli releasecelo:authorize --contract $CELO_RG_ADDRESS --role=vote --signer $CELO_VOTE_SIGNER_ADDRESS --signature $CELO_VOTE_SIGNER_SIGNATURE --useLedger -``` - -Finally, verify that your signer was correctly authorized: - -```bash -celocli account:show $CELO_RG_ADDRESS -``` - -The `vote` address under `authorizedSigners` should match `$CELO_VOTE_SIGNER_ADDRESS`. - -The `ReleaseGold` contract was funded with an additional 1 CELO that it sends to the first vote signer account to be authorized. This allows the vote signer account to cover transaction fees. You can confirm this: - -```bash -celocli account:balance $CELO_VOTE_SIGNER_ADDRESS -``` - - -**Warning**: If you authorize a second vote signer, it will not be automatically funded by the `ReleaseGold` contract. You will need to transfer a fraction of 1 CELO from your beneficiary address to it in order to cover transaction fees when using it. - - -## Lock CELO - -To vote for Validator Groups and on governance proposals you will need to lock CELO. This is to keep the network secure by making sure each unit of CELO can only be used to vote once. - -Specify the amount of CELO you wish to lock (don’t include the `< >` braces). All amounts are given as wei, i.e., units of 10^-18 CELO. For example, 1 CELO = 1000000000000000000. - - -Make sure to leave at least 1 CELO unlocked to pay for transaction fees. - - -```bash -# Using the Beneficiary Ledger -celocli releasecelo:locked-gold --contract $CELO_RG_ADDRESS --action lock --useLedger --value -``` - -Check that your CELO was successfully locked. - -```bash -celocli lockedgold:show $CELO_RG_ADDRESS -``` - -## Vote for a Validator Group - -Similar to staking or delegating in other Proof of Stake cryptocurrency protocols, CELO holders can lock CELO and vote for Validator Groups on the Celo network. By doing this, not only do you contribute to the health and security of the network, but you can also earn [epoch rewards](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards). - -For more details, check out the [Voting for Validators page](/what-is-celo/about-celo-l1/validator/voting), which contains useful background on how voting Validator Elections work, as well as more guidance on how to select a Validator Group to vote for. For now, all you need to know is that: - -- in Celo, CELO holders vote for Validator Groups, not Validators directly -- you only earn epoch rewards if the Validator Group you voted for gets at least 1 Validator elected - -Keeping this in mind, you will need to find a Validator Group to vote for and copy its address. You can find this information on community validator explorers such as the [cLabs Validator explorer](/what-is-celo/about-celo-l1/validator/validator-explorer) and [Bi23 Labs' `thecelo` dashboard](https://thecelo.com). - -You can also see registered Validator Groups through the Celo CLI. This will display a list of Validator Groups, the number of votes they have received, the number of additional votes they are able to receive, and whether or not they are eligible to elect Validators: - -```bash -celocli election:list -``` - -Once you have found one or more Validator Groups you’d like to vote for, create an environment variable for its Group address (don’t include the `< >` braces): - -```bash -export CELO_VALIDATOR_GROUP_ADDRESS= -``` - -For each vote you will need to select the amount of locked CELO you wish to vote with. You can look up your balance again if you need to: - -```bash -celocli account:balance $CELO_RG_ADDRESS -``` - -All CELO amounts should be expressed in wei: that means 1 CELO = 1000000000000000000. Don’t include the `< >` braces in the line below. - -To vote, you will use your vote signer key, which is voting _on behalf of_ your Locked CELO account. - - -Connect your **Vote Signer Ledger** now, unlock it, and open the Celo application. - - -```bash -# Using the Vote Signer Ledger -celocli election:vote --from $CELO_VOTE_SIGNER_ADDRESS --for $CELO_VALIDATOR_GROUP_ADDRESS --useLedger --value -``` - -Verify that your votes were cast successfully. Since your Vote Signer account votes on behalf of the Celo Locked CELO account, you want to check the election status for that account: - -```bash -celocli election:show $CELO_RG_ADDRESS --voter -``` - -Your locked CELO votes should be displayed next to `pending` under `votes`. - -## The next day: Activate your Vote - -Your vote will apply starting at the next Validator Election, held once per day, and will continue to apply at each subsequent election until you change it. - -After that election has occurred, you will need to activate your vote. This will allow you to receive epoch rewards if in that election (or at any subsequent one, until you change your vote) the Validator Group for which you voted elected at least one Validator. Rewards will get added to your votes for that Group and will compound automatically. - - -Epoch lengths in Mainnet are set to be the number of blocks produced in a day. As a result, votes may need to be activated up to 24 hours after they are cast. - - -Check that your votes were cast in a previous epoch: - -```bash -celocli election:show $CELO_RG_ADDRESS --voter -``` - -Your vote should be displayed next to `pending` under `votes`. - - -Connect your **Vote Signer Ledger** now, unlock it, and open the Celo application. - - -Now activate your votes: - -```bash -# Using the Vote Signer Ledger -# You must do this in an epoch after the one you voted in: this may take up to 24h -celocli election:activate --from $CELO_VOTE_SIGNER_ADDRESS --useLedger -``` - -If you run `election:show` again, your vote should be displayed next to `active` under `votes`. - -Congratulations! You're all set. - -At the end of the epoch following your vote activation, you may receive voter rewards (if at least one Validator from the Validator Group for which you voted was elected). - -You can see rewards using: - -```bash -celocli rewards:show --voter $CELO_RG_ADDRESS -``` - -Or by searching for your `ReleaseGold` address on the [Block Explorer](https://explorer.celo.org) and clicking the "Celo Info" tab. - -## Next Steps - -You are now set up to participate in the Celo network! - -You might want to read more about [choosing a Validator Group](/what-is-celo/about-celo-l1/validator/voting) to vote for, and how [voter rewards](/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-locked-gold) are calculated. You can vote for up to ten different Groups from a single account. - -Now you've locked CELO, you can use it to participate in voting for or against [Governance proposals](/what-is-celo/using-celo/protocol/governance/voting-in-governance). You can do this without affecting any vote you have made for Validator Groups. - -You can also read more about how Celo's [Proof of Stake](/what-is-celo/about-celo-l1/protocol/pos/) and on-chain [Governance](/what-is-celo/using-celo/protocol/governance/overview) mechanisms work. - -## Revoking Votes - -At any point you can revoke votes cast for a Validator Group. For example, a Group may be performing poorly and affecting your rewards, and you may prefer to vote for another Group. - - -When you revoke your votes you will stop receiving voter rewards. - - -Specify the amount of CELO you wish to revoke (don’t include the `< >` braces). All CELO amounts should be expressed in 18 decimal places. For example, 1 CELO = 1000000000000000000. - - -Connect your **Vote Signer Ledger** now, unlock it, and open the Celo application. - - -Revoke votes for the Group: - -```bash -# Using the Vote Signer Ledger -celocli election:revoke --from $CELO_VOTE_SIGNER_ADDRESS --for $CELO_VALIDATOR_GROUP_ADDRESS --value --useLedger -``` - -You can immediately re-use this locked CELO to vote for another Group. - -## Unlocking and Withdrawing - -At some point, the terms of your `ReleaseGold` contract will allow you to withdraw funds and transfer them to your beneficiary address. - -There are actually several steps to this process: - -1. First, revoke all outstanding votes as above (including for governance proposals) -2. Unlock the non-voting Locked CELO, starting a 72 hour unlocking period -3. After the three day unlocking period is complete, withdraw the CELO back to the `ReleaseGold` contract -4. Assuming vesting and distribution requirements are met, withdraw the CELO to the beneficiary address - -Check the current status of outstanding votes: - -```bash -celocli election:show $CELO_RG_ADDRESS --voter -``` - -You can view the balance of locked CELO: - -```bash -celocli account:balance $CELO_RG_ADDRESS -``` - - -Connect your **Beneficiary Ledger** now, unlock it and open the Celo application. - - -Assuming you have non-voting Locked Celo, you can initiate the process to unlock: - -```bash -# Using the Beneficiary Ledger -celocli releasecelo:locked-gold --contract $CELO_RG_ADDRESS --action unlock --useLedger --value -``` - -After the 72 hour unlocking period has passed, withdraw the CELO back to the `ReleaseGold` contract: - -```bash -# Using the Beneficiary Ledger -celocli releasecelo:locked-gold --contract $CELO_RG_ADDRESS --action withdraw --useLedger --value -``` - -Finally, request that the `ReleaseGold` contract transfer an amount to your beneficiary address: - -```bash -# Using the Beneficiary Ledger -celocli releasecelo:withdraw --contract $CELO_RG_ADDRESS --useLedger --value -``` - -To vote with any CELO in your beneficiary account, you'll want to register it as a Locked CELO Account, authorize a new vote signing key for it, then lock CELO. \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/celo-token.mdx b/_deprecated/what-is-celo/using-celo/protocol/celo-token.mdx deleted file mode 100644 index 8bcb038c08..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/celo-token.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "CELO Token Duality" -sidebarTitle: "Celo Token" -og:description: Introduction to CELO and its compliance to the ERC20 standard. ---- - -Introduction to CELO and its compliance to the ERC20 standard. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -The CELO token is unique in its ability to function as both a native token and an ERC-20 compatible token. - -## What is Token Duality? - -Token duality means that **CELO functions both as the native currency of the Celo blockchain and as an ERC-20 compatible token**. This enables CELO tokens to be transferred in two ways: - -1. **Native transfers**, similar to how ETH is transferred on Ethereum. -2. **ERC-20 transfers**, using the standard ERC-20 interface. - -Regardless of the transfer method, CELO tokens **reflect in both the native account balance and the ERC-20 balance**. Unlike ETH/WETH, there is **no need for wrapping or unwrapping**. - ---- - -## Implementation Details - -### **Native Transfers and Balances** -- Native transfers and balance storage work exactly as they do on Ethereum. -- The CELO ERC-20 contract **reads native balances** and triggers native transfers via its ERC-20 interface. - -### **Reading Balances via ERC-20** -- The ERC-20 implementation does **not** store balances in contract storage. -- Instead, `balanceOf(address)` directly returns the **native balance**, ensuring consistency across both transfer types. - -### **Transfers via ERC-20** -- The `transfer` and `transferFrom` functions do **not** modify contract storage. -- Instead, these functions **initiate a native transfer**. -- Since Ethereum does not support native transfers from smart contracts, **Celo introduces a transfer precompile** to handle this. This precompile can only be called by the CELO token. - ---- - -By enabling seamless interoperability between native and ERC-20 transactions, **CELO remains highly flexible within the Ethereum and Celo ecosystems** without requiring additional conversion steps. \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/consensus.mdx b/_deprecated/what-is-celo/using-celo/protocol/consensus.mdx deleted file mode 100644 index 3cdf2c521d..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/consensus.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Consensus -og:description: Introduction to the Celo consensus mechanism. ---- - -Introduction to the Celo consensus mechanism. This page captures the key points about the proposed Security Council and its role in the Celo L2 Network. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - - -This page is a work in progress based on the [proposal for the Celo L2’s Security Council](https://forum.celo.org/t/proposing-celo-l2s-security-council/10578/1). For updates make sure to refer to the [Celo Forum](https://forum.celo.org). - - -### Celo L2 Security Council Overview - -- **Purpose**: - - To decentralize the Celo L2 Network. - - Manage key upgrades and security fixes. - -- **Responsibilities**: - - Upgrade L1 protocol contracts for Celo’s L2. - - Modify designations for roles like sequencers, proposers, and challengers. - - Execute urgent security fixes via hotfixes. - - Act independently in urgent situations for the network's best interest. - -- **Decentralization Goals**: - - Prevent any single entity from upgrading the system, modifying rollup state, or censoring transactions. - -- **Governance**: - - Regular Governance Process for Celo Core Contracts and Community Fund remains unchanged. - -- **Proposed Multisig Structure**: - - **2/2 Safe Multisig**: - - Members: cLabs Multisig and Celo Community Security Council. - - **cLabs Multisig**: 4 out of 5 multisig with a 75% threshold. - - **Celo Community Security Council**: 6/8 multisig with members from L2Beat, Hyperlane, Valora, Mento, Nitya Subramanian, Kris Kaczor, Tim Moreton, and Aaron Boyd. - - Ensures non-cLabs controlled quorum-blocking group. - -- **Security Standards**: - - Follow Optimism multisig security policy. - - Allow nested multisigs if all signers adhere to the security policy. diff --git a/_deprecated/what-is-celo/using-celo/protocol/escrow.mdx b/_deprecated/what-is-celo/using-celo/protocol/escrow.mdx deleted file mode 100644 index 4f1c68daaf..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/escrow.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Escrow" -sidebarTitle: "Escrow" -og:description: Introduction to the Celo Escrow contract and how to use it to withdraw, revoke, and reclaim funds. ---- - -Introduction to the Celo Escrow contract and how to use it to withdraw, revoke, and reclaim funds. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## What is the Escrow Contract? - -The `Escrow` contract utilizes Celo's Lightweight identity feature to allow users to _send payments to other users who don't yet have a public/private key pair or an address_. These payments are stored in this contract itself and can be either withdrawn by the intended recipient or reclaimed by the sender. This functionality supports _both_ versions of Celo's lightweight identity: identifier-based \(such as a phone number to address mapping\) and privacy-based. This gives applications that intend to use this contract some flexibility in deciding which version of identity they prefer to use. - -## How it works - -If Alice wants to send a payment to Bob, who doesn't yet have an associated address, she will send that payment to this `Escrow` contract and will also create a temporary public/private key pair. The associated temporary address will be referred to as the `paymentId`. Alice will then externally share the newly created temporary private key, also known as an _invitation_, to Bob, who will later use it to claim the payment. This paymentId will now be stored in this contract and will be mapped to relevant details related to this specific payment such as: the value of the payment, an optional identifier of the intended recipient, an optional amount of `attestations` the recipient must have before being able to withdraw the payment, an amount of time after which the sender can revoke the payment \(via the `expirySeconds` field - more on that in the "withdrawing" section below\), which asset is being transferred in this payment, etc. - -## Withdrawing - -The recipient of an escrowed payment can choose to withdraw their payment assuming they have successfully created their own public/private key pair and now have an address. To prove their identity, the recipient must be able to prove ownership of the paymentId's private key, which should have been given to them by the original sender. If the sender set a minimum number of attestations required to withdraw the payment, that will also be checked in order to successfully withdraw. Following the same example as above, if Bob wants to withdraw the payment Alice sent him, he must sign a message with the private key given to him by Alice. The message will be the address of Bob's newly created account. Bob will then be able to withdraw his payment by providing the paymentId and the v, r, and s outputs of the generated ECDSA signature. An escrowed payment may have `expirySeconds` set, which references the amount of time that must pass before the sender can revoke the payment. Note that after `expirySeconds` have passed, the payment recipient may _still withdraw the payment as long as it has not already been revoked_. - -## Revoking & Reclaiming - -Alice sends Bob an escrowed payment. Let's say Bob never withdraws it, or worse, the temporary private key he needs to withdraw the payment gets lost or sent to the wrong person. For this purpose, Celo's protocol also allows for senders to reclaim any unclaimed escrowed payment that they sent. After an escrowed payment's `expirySeconds` \(set by the sender on creation of the payment\) has passed, the sender of the payment can revoke the payment and reclaim their funds with just the paymentId. \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/governance/governable-parameters.mdx b/_deprecated/what-is-celo/using-celo/protocol/governance/governable-parameters.mdx deleted file mode 100644 index 2df896164f..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/governance/governable-parameters.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Governance Cheat Sheet" -sidebarTitle: "Governable Parameters" -og:description: List of governable parameters and governance restrictions on Celo. ---- - -List of governable parameters and governance restrictions on Celo. - ---- - -## Governable Parameters - -- The stability protocol, including the exchange -- What the protocol does with data feeds from Oracles -- Adding or removing Mento stablecoins -- Adding Mento stablecoins (or other ERC20s) for use in paying gas fees -- The identity protocol, including how phone number attestations works -- Linking of signers and off-chain metadata (e.g claims) to accounts -- On-chain governance itself -- MinimumClientVersion -- BlockGasLimit -- IntrinsicGasForAlternativeFeeCurrency - -## Things That Can't Be Modified By Governance - -- The protocol by which nodes communicate -- The format of block headers, block bodies, the fields in transactions, etc -- How nodes sync -- How nodes store their data locally -- Most parameters that affect the blockchain \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/governance/governance-toolkit.mdx b/_deprecated/what-is-celo/using-celo/protocol/governance/governance-toolkit.mdx deleted file mode 100644 index 6d4473e17c..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/governance/governance-toolkit.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Governance Toolkit -og:description: An overview of the tools, platforms, and resources available for participating in Celo Governance. ---- - -An overview of the tools, platforms, and resources available for participating in Celo Governance. - ---- - -## Mechanisms for Main Onchain Celo Governance Proposals - -* [**Celo Governance Contract**](https://celoscan.io/address/0xd533ca259b330c7a88f74e000a3faea2d63b7972#code): The onchain voting contract for Celo Governance. This is also the address of the Celo Community Treasury. -* [**Celo Mondo**](https://mondo.celo.org/): The UI friendly interface to Lock, Stake, Delegate and Vote. -* [**CeloCLI**](/cli): The command line interface for interacting with the Celo network, including governance proposals and voting. -* [**Celo Terminal**](https://celoterminal.com/): A desktop application allowing Celo chain interactions and governance participation. -* [**StakedCelo dApp**](https://app.stcelo.xyz/connect): An application that allows for liquid staking of Celo and voting on Governance proposals. - -### Mechanisms for Celo Public Goods Proposals - -* [**Celo Public Goods Snapshot**](https://snapshot.org/#/celopg.eth): A Locked CELO snapshot to allow votes to occur on Snapshot to decide about Celo Public Goods Proposals. - -### Mechanisms for Discussions - -* [**The Celo Forum**](https://forum.celo.org/): The platform for governance and community discussion. -* [**Discord**](https://discord.com/invite/celo): For informal governance discussion and feedback. -* [**Github**](https://github.com/celo-org/governance): Governance guidelines and CGP proposals are tracked via Github. - -## Celo Governance Guardians Overview - -Celo Governance is represented by Celo Governance Guardians who can help answer any questions about the governance process. -The curent Celo Governance Guardians (formerly known as CGP Editors), actively participating in the Governance Process, are: - -* **Guardian:** 0xj4an [Celo Forum](https://forum.celo.org/u/0xj4an-work), [Twitter](https://x.com/0xj4an) -* **Guardian:** Wade [Celo Forum](https://forum.celo.org/u/wade), [Twitter](https://x.com/0xZOZ) -* **Advisors Guardians:** - * Eric [Celo Forum](https://forum.celo.org/u/ericnakagawa), [Twitter](https://x.com/ericnakagawa) - * Anna [Celo Forum](https://forum.celo.org/u/annaalexa), [Twitter](https://x.com/AnnaAlexaK) - \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/governance/overview.mdx b/_deprecated/what-is-celo/using-celo/protocol/governance/overview.mdx deleted file mode 100644 index e1357c12c8..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/governance/overview.mdx +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Celo Governance -og:description: Overview of Celo governance and how the network is managed using the stakeholder proposal process. -sidebarTitle: "Overview" ---- - -This overview covers Celo governance and network management through the stakeholder proposal process. - ---- - -## What is Celo Governance? - -Celo uses a formal onchain governance mechanism to manage and upgrade the protocol such as for upgrading smart contracts, adding new stable currencies, or modifying the reserve target asset allocation. All changes must be agreed upon by CELO holders. A quorum threshold model is used to determine the number of votes needed for a proposal to pass. - - -For a detailed explanation of the entire governance process, and to view the latest proposals and discussions, make sure to check out the [Celo Governance GitHub repository](https://github.com/celo-org/governance). - - -## Stakeholder Proposal Process - -Changes are managed via the Celo `Governance` smart contract. This contract acts as an "owner" for making modifications to other protocol smart contracts. Such smart contracts are termed **governable**. The `Governance` contract itself is governable, and owned by itself. - - -Pleas follow [this guide to create a proposal](/what-is-celo/using-celo/protocol/governance/create-governance-proposal), but make sure to go through this page to fully understand the process before you do so. - - -## Phases - -### Overview - -The governance process follows three sequential phases, each with specific timing requirements: - -1. **Proposal Phase** - **Up to 4 weeks**: Each proposal starts in the proposal queue where community members can upvote it to improve its position relative to other queued proposals. Proposal authors should actively seek community support for upvotes (proposers may upvote their own proposals). The top 3 proposals are automatically promoted to the approval stage daily. Proposals remaining in the queue for 4 weeks will expire. - -2. **Approval and Referendum Phase** - in parallel: - - **Approval** - **24 hours**: During this single day window, the proposal must receive approval from the designated Approvers. - - - **Referendum** - **5 days**: Locked CELO holders vote YES or NO on the proposal during this period. - - Proposals that both meet the required quorum threshold and are successfully approved are promoted to the execution phase. - -3. **Execution Phase** - **Up to 3 days**: Any community member may trigger the execution of the approved proposal during this window. - -### Proposal - -Any user may submit a Proposal to the Governance smart contract, along with a small deposit of CELO. This deposit is required to avoid spam proposals, and is refunded to the proposer if the proposal reaches the Approval stage. A Proposal consists of a list of transactions, and a description URL where voters can get more information about the proposal. It is encouraged that this description URL points to a CGP document in the [celo-org/celo-proposals](https://github.com/celo-org/celo-proposals) repository. Transaction data in the proposal includes the destination address, data, and value. If the proposal passes, the included transactions will be executed by the `Governance` contract. - -Submitted proposals are added to the queue of proposals. While a proposal is on this queue, voters may use their Locked CELO to upvote the proposal. Once per day the top three proposals, by weight of the Locked CELO upvoting them, are dequeued and moved into the Approval phase. Note that if there are fewer than three proposals on the queue, all may be dequeued even if they have no upvotes. If a proposal has been on the queue for for more than 4 weeks, it expires and the deposit is forfeited. - -#### Types of Proposals - -Governance Proposals must fall within one of the following categories to be considered acceptable. - -|**Proposal Type**|**Governance Platform**|**Description**|**Submission Requirements**|**Quorum**|**Approval Threshold**| -| --- | --- | --- | --- | --- | --- | -|Celo Protocol Governance|Celo Governance Contracts|Celo Network decisions and Celo Protocol Improvements|Deposit of 10,000 Locked CELO.|Dynamic based on the current Celo Algorithm.|Dynamic based on the current Celo Algorithm.| -|Smart Contract Governance|Celo Governance Contracts|onchain smart contract changes|Deposit of 10,000 Locked CELO.|Dynamic based on the current Celo Algorithm.|Dynamic based on the current Celo Algorithm.| -|Celo Community Treasury Governance|Celo Governance Contracts|Funding proposals that do not fall within a current Celo Public Good Budget or aim to request over $500,000 in value in a single proposal.|Deposit of 10,000 Locked CELO.|Dynamic based on the current Celo Algorithm.|Dynamic based on the current Celo Algorithm.| -|Mento Governance|Celo Governance Contracts|Mento reserve and protocol decisions. To separate once, Mento will establish their own Governance system in 2024.|Deposit of 10,000 Locked CELO.|Dynamic based on the current Celo Algorithm.|Dynamic based on the current Celo Algorithm.| -|Celo Public Goods Governance|Celo Public Goods Snapshot|Program selection within approved Celo Public Goods budgets.|Minimum of 10,000 Locked CELO Balance|2.5M Celo|50%| - -#### Feedback and Review - -Proposals must be posted in the Celo Forum for review by the Celo community. It is required to post the proposal as a new discussion thread in the [Governance category](https://forum.celo.org/c/governance/12) and to mark it with **[DRAFT]** in the title. Proposal authors are expected to be responsive to feedback. - -A proposal needs to be up for discussion for at least **7 full days,** during which responsiveness from the author is mandatory. - -After a proposal has received feedback and has been presented on the governance call the proposal author shall update the proposal thread title from [Draft] to [Final]. Authors shall also include a summary of incorporated feedback as a comment on their proposal thread so future reviewers can understand the proposal's progress. If feedback was gathered outside of the Forum (e.g., on Discord), proposal authors should include relevant links. - -### Approval - -Every day, the top three proposals at the head of the queue pop off and move to the Approval phase. At this time, the original proposers are eligible to reclaim their Locked CELO deposit. In this phase, the proposal needs to be approved by the Approver. The Approver is initially a 3 of 9 multi-signature address held by individuals selected by the Celo Foundation, and will move to a DAO in the future. The Approval phase lasts 1 day and if the proposal is not approved in this window, it is considered expired and does not move on to the "Referendum" phase. - -### Referendum - -Once the Approval phase is over, approved proposals graduate to the referendum phase. Any user may vote YES, NO, or ABSTAIN on these proposals. Their vote's weight is determined by the weight of their Locked CELO. After the Referendum phase is over, which lasts five days, each proposal is marked as passed or failed as a function of the votes and the corresponding passing function parameters. - -In order for a proposal to pass, it must meet a minimum threshold for **participation**, and **agreement**: - -- Participation is the minimum portion of Locked CELO which must cast a vote for a proposal to pass. It exists to prevent proposals passing with very low participation. The participation requirement is calculated as a governable portion of the participation baseline, which is an exponential moving average of final participation in past governance proposals. -- Agreement is the portion of votes cast that must be YES votes for a proposal to pass. Each contract and function can define a required level of agreement, and the required agreement for a proposal is the maximum requirement among its constituent transactions. - -### Execution - -Proposals that graduate from the Referendum phase to the Execution phase may be executed by anyone, triggering a call operation code with the arguments defined in the proposal, originating from the Governance smart contract. Proposals expire from this phase after three days. - -## Cool-off period for failed proposals - -If a proposal is not accepted, a cool-off period is required for additional conversation and potential changes before the proposal can be resubmitted. There are two situations in which a cool-off period is required: - -1. If a proposal is rejected due to not reaching a quorum but having a majority of YES votes, the proposal is moved back to the discussion stage and may be submitted for a vote after waiting for 14 days. - -2. If a proposal is rejected and has a majority of NO votes, the proposal is moved back to the discussion stage and may be submitted for a vote after receiving approval from the Governance Guardians and waiting for 28 days. - -**Note**: In the event that a proposal meets or exceeds quorum, but is not approved in time, the proposers should be able to re-submit as soon as they are able. This would happen in a rare situations when approvers are unable to approve in the 72 hour window following a referendum vote. diff --git a/_deprecated/what-is-celo/using-celo/protocol/governance/smart-contracts-upgrades.mdx b/_deprecated/what-is-celo/using-celo/protocol/governance/smart-contracts-upgrades.mdx deleted file mode 100644 index cd97518a5f..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/governance/smart-contracts-upgrades.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Smart Contract Upgradeability" -sidebarTitle: "Smart Contracts Upgrades" ---- - -​Smart contracts deployed to an EVM blockchain like Celo are immutable. To allow for improvements, new features, and bug fixes, the Celo codebase uses the Proxy Upgrade Pattern. All of the core contracts owned by Governance are proxied. Thus, a smart contract implementation can be upgraded using the standard onchain governance process.​ - -## Upgrade risks - -​The core contracts define critical behavior of the Celo network such as CELO and Celo Dollar asset management or validator elections and rewards. Malicious or inadvertent contract bugs could compromise user balances or potentially cause harm, irreversible without a blockchain hard fork. - -Great care must be taken to ensure that any Governance proposal that modifies smart contract code will not break the existing system. To this end, the contracts have a well defined release process, which includes soliciting security audits from reputable third-party auditors. - -As Celo is a decentralized network, all Celo network participants are invited to participate in the governance proposals discussions on the forum. - -## Governance Hotfix Process - -The Governance Hotfix process uses a multisig approach to handle critical security patches that need to be deployed quickly without going through the standard governance timeline. - -The cadence and transparency of the standard onchain governance protocol make it poorly suited for proposals that patch issues that may compromise the security of the network, especially when the patch would reveal an exploitable bug in one of the core contracts. Instead, these sorts of changes are better suited for the more responsive hotfix protocol. - -The current process requires approval from both an approver multisig and the Security Council multisig. The list of Security Council signers remains fixed, which simplifies the approval process. If a hotfix is not executed within the specified execution time limit, it must be reset and re-approved. - -## Celo Blockchain Software Upgrades - -Some changes cannot be made through the onchain governance process alone. Examples include changes to the underlying consensus protocol and changes which would result in a hard-fork. diff --git a/_deprecated/what-is-celo/using-celo/protocol/governance/voting-in-governance-using-mondo.mdx b/_deprecated/what-is-celo/using-celo/protocol/governance/voting-in-governance-using-mondo.mdx deleted file mode 100644 index e572039c51..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/governance/voting-in-governance-using-mondo.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Voting on Governance with Celo Mondo -og:description: How to use Celo Mondo to participate in governance voting on the Celo network -sidebarTitle: "Vote with Celo Mondo" ---- - -Celo uses a formal onchain governance mechanism to manage and upgrade the protocol. This guide explains how to participate in governance using Celo Mondo. - ---- - -## What is Celo Mondo? - -Celo Mondo is a decentralized application for staking and governance within the Celo ecosystem. It enables users to lock and stake their CELO tokens to earn rewards and participate in the network's governance by voting on onchain proposals. - -## Using Celo Mondo for Governance - -With Celo Mondo, you can: - -- View active and past governance proposals -- Vote on proposals with your locked CELO -- Delegate your voting power to another address -- Track proposal status and outcomes - -## Getting Started - -- [Launch Celo Mondo](https://mondo.celo.org/governance) -- [Celo Mondo GitHub](https://github.com/celo-org/celo-mondo) -- [Become a Delegate](https://mondo.celo.org/delegate) - -## Staying Informed - -To stay up-to-date with all governance activities and proposals: - -- Sign up for the [Celo Signal mailing list](https://share.hsforms.com/1Qrhush1vSA2WIamd_yL4ow53n4j) -- Add the [Celo Signal public calendar](https://calendar.google.com/calendar/u/0/embed?src=c_9su6ich1uhmetr4ob3sij6kaqs@group.calendar.google.com) to track important dates and events -- Follow discussions on the [Celo Forum](https://forum.celo.org/) in the Governance category - -For more comprehensive information about Celo's governance system, see the [Governance Overview](/what-is-celo/using-celo/protocol/governance/overview) and [Voting in Governance](/what-is-celo/using-celo/protocol/governance/voting-in-governance) guides. \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/governance/voting-in-governance.mdx b/_deprecated/what-is-celo/using-celo/protocol/governance/voting-in-governance.mdx deleted file mode 100644 index 7528386513..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/governance/voting-in-governance.mdx +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: "CeloCLI for Governance Proposals" -sidebarTitle: "CeloCLI for Governance" -og:description: How to use the Celo CLI to participate in Goverance and create a Governance proposal. ---- - -How to use the [Celo CLI](/cli/) to participate in Goverance and create a Governance proposal. - ---- - -## Governance - -Celo uses a formal on-chain governance mechanism to manage and upgrade the protocol. More information about the Governance system can be found in the [Governance overview](/what-is-celo/using-celo/protocol/governance/overview). - - -In the following commands `` is used as a placeholder for something you should specify on the command line. - - -## Viewing Proposals - -A list of active proposals can be viewed with the following command: - -```bash -celocli governance:list -``` - -Included will be three lists of proposals by status: - -- **Queued** proposals have been submitted, but are not yet being considered. Voters can upvote proposals in this list, and proposals with the most upvotes from this list will be moved from the queue to be considered. -- **Dequeued** proposals are actively being considered and will pass through the Approval, Referendum, and Execution stages, as discussed in the [Governance overview](/what-is-celo/using-celo/protocol/governance/overview). -- **Expired** proposals are no longer being considered. - -## Understanding Proposal Details - -You can view information about a specific proposal with: - -```bash -celocli governance:show --proposalID= -``` - -For example, the proposal 14 on Mainnet was as follows: - -``` -Running Checks: - ✔ 14 is an existing proposal -proposal: - 0: - contract: Governance - function: setBaselineQuorumFactor - args: - 0: 500000000000000000000000 - params: - baselineQuorumFactor: 500000000000000000000000 (~5.000e+23) - value: 0 -metadata: - proposer: 0xF3EB910DA09B8AF348E0E5B6636da442cFa79239 - deposit: 100000000000000000000 (~1.000e+20) - timestamp: 1609961608 (~1.610e+9) - transactionCount: 1 - descriptionURL: https://github.com/celo-org/celo-proposals/blob/master/CGPs/0016.md -stage: Referendum -upvotes: 0 -votes: - Yes: 30992399904903465125627698 (~3.099e+25) - No: 0 - Abstain: 0 -passing: true -requirements: - constitutionThreshold: 0.7 - support: 0.99883105743491071638 - required: 29107673282861669327494319.531832308424 (~2.910e+25) - total: 30992399904903465125627698 (~3.099e+25) -isApproved: true -isProposalPassing: true -timeUntilStages: - referendum: past - execution: 57 minutes, 59 seconds - expiration: 3 days, 57 minutes, 59 seconds -``` - -To see how many votes a proposal needs to pass (depending on what type of commands are being executed), you can refer to the **requirements** section of the respose. - -In the proposal above, there is a **constitutionThreshold** target of "0.7" or 70% of votes must be in support, "0.998" or 99.8% of votes have currently voted "yes", the number of votes required to pass are 29.1M CELO, with 30.9M CELO currently voted in total. - -## Voting on Proposals - -When a proposal is Queued, you can upvote the proposal to indicate you'd like it to be considered. - - -If you are using a Ledger wallet, make sure to include `--useLedger` and `--ledgerAddresses` in the -following commands. - - -```bash -celocli governance:upvote --proposalID= --from= -``` - -At a defined frequency, which can be checked with the `celocli network:parameters` command, proposals can be dequeued, with the highest upvoted proposals being dequeued first. - -After a proposal is dequeued, it will first enter the Approval phase. -In this phase, the [Governance Approver](/what-is-celo/using-celo/protocol/governance/overview#approval) may choose to approve the proposal, which will allow it to proceed to the Referendum phase after the configured length of time. - -Once a proposal has reached the Referendum phase, it is open to community for voting. - -```bash -celocli governance:vote --proposalID= --value= --from= -``` - -## Executing a Proposal - -If a Governance Proposal receives enough votes and passes in the Referendum phase, it can be executed by anyone. - -```bash -celocli governance:execute --proposalID= --from= -``` - -## Vote Delegation - -[Contract Release 10](https://github.com/celo-org/celo-monorepo/issues/10375) introduced vote delegation, which allows the governance participant to delgate their voting power. - -### Delegating Votes - -You can delegate votes using the following command: - -```bash -celocli lockedgold:delegate --from --to --percent -``` - - -**NOTE**
-Currently, participants can only delegate to 10 delegatees. - - -You can view the max number of delegatees one can have using the following command: - -```bash -celocli lockedgold:max-delegatees-count -``` - -### Revoking Delegated Votes - -You can use the following command to revoke delegated votes: - -```bash -celocli lockedgold:revoke-delegate --from --to --percent -``` - -For example, If you have delegated 15% to the delegatee and pass 5% as `percent` then 5% will be subtracted from the 15% resulting in 10% delegation. - -### Total percent of Locked Celo delegated by an account - -You can use the following command to get the total percent of locked celo delegated by an account: - -```bash -celocli lockedgold:delegate-info --account -``` - -### List of Delegatees of a Delegator - -You can use the following command to get the list of delegatees of an account: - -```bash -celocli lockedgold:delegate-info --account -``` - -### Total Delegated Votes to an address - -You can use the following command to get the total delegated votes to an address: - -```bash -celocli lockedgold:delegate-info --account -``` - -## Staying Informed - -To stay up-to-date with all governance activities and proposals: - -- Sign up for the [Celo Signal mailing list](https://share.hsforms.com/1Qrhush1vSA2WIamd_yL4ow53n4j) -- Add the [Celo Signal public calendar](https://calendar.google.com/calendar/u/0/embed?src=c_9su6ich1uhmetr4ob3sij6kaqs@group.calendar.google.com) to track important dates and events -- Follow discussions on the [Celo Forum](https://forum.celo.org/) in the Governance category - -For more comprehensive information about Celo's governance system, see the [Governance Overview](/what-is-celo/using-celo/protocol/governance/overview) and [Voting in Governance](/what-is-celo/using-celo/protocol/governance/voting-in-governance) guides. \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/index.mdx b/_deprecated/what-is-celo/using-celo/protocol/index.mdx deleted file mode 100644 index 9bbf4de319..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/index.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Celo Protocol -og:description: Introduction to the Celo protocol, its implementation, and its relationship to Ethereum. -sidebarTitle: "Overview" ---- - - - -Introduction to the Celo protocol, its implementation, and its relationship to Ethereum. - - -As of block height 31,056,500 (March 26, 2025, 3:00 AM UTC), Celo is no longer a standalone Layer 1 blockchain—it is now an Ethereum Layer 2! -Some documentation may be outdated as updates are in progress. If you encounter issues, please [file a bug report](https://github.com/celo-org/docs/issues/new/choose). - -For the most up-to-date information, refer to our [Celo L2 documentation](/build#celo-l2-mainnet). - - ---- - -## What is the Celo Protocol? - -Celo's blockchain reference implementation is based on go-ethereum, the Go implementation of the Ethereum protocol. The project team is indebted to the Geth community for providing these shoulders to stand on and, while recognizing that Ethereum is an independent project with its own trajectory, hopes to contribute changes where it makes sense to do so. - -In addition to the blockchain client, there are some core components of the Celo protocol that are implemented at the smart contract level and even off-chain (e.g. phone number verification via SMS). Some of these core components have become their own protocol, e.g. Mento and Self. - -## Protocol Upgrades - -There are a number of substantial changes and additions have been made in service of Celo's product goals, including the following: - -- [Consensus](/what-is-celo/about-celo-l1/protocol/consensus) -- [Governance](/what-is-celo/using-celo/protocol/governance/overview/) -- [Stability Mechanism - Mento](https://www.mento.org/) -- [Transactions](/what-is-celo/about-celo-l1/protocol/transaction) -- [Identity - Self](https://self.xyz/) \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/transaction/overview.mdx b/_deprecated/what-is-celo/using-celo/protocol/transaction/overview.mdx deleted file mode 100644 index 942a31a125..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/transaction/overview.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: Transactions on Celo -og:description: Introduction to transactions on Celo. -sidebarTitle: "Overview" ---- - -In Celo's transition to a Layer 2 (L2) solution, several key changes have been proposed to the network's tokenomics, particularly concerning gas pricing and transaction fee allocation. - ---- - - -This section is a work in progress and based on the ["The Great Celo Halvening - Proposed Tokenomics in the Era of Celo L2"](https://forum.celo.org/t/the-great-celo-halvening-proposed-tokenomics-in-the-era-of-celo-l2/9701/1). Please check the [forum](https://forum.celo.org/) for the latest information. - - -## Gas Pricing Mechanism - -Celo employs a gas pricing model based on **EIP-1559**, which dynamically adjusts the base fee to manage network demand. This mechanism ensures that gas prices respond to network congestion, increasing during high demand periods and decreasing when demand is low. The protocol sets a **base fee floor** to prevent the base fee from falling below a certain threshold, safeguarding the network against spam transactions and uncontrolled state growth. - -## Fee Abstraction - -A notable feature of Celo's network is **fee abstraction**, allowing users to pay transaction fees -using approved ERC-20 tokens such as USDT, USDC, cUSD, and others, in addition to the native CELO -token. This flexibility simplifies the user experience by eliminating the need to hold a separate -CELO balance for gas fees. To utilize this feature, transactions include a `feeCurrency` field -specifying the token for gas payment. It's important to note that transactions specifying non-CELO -gas currencies incur approximately 50,000 additional gas units. - -Celo allows paying gas fees in currencies other than the native currency. The tokens that can be -used to pay gas fees are controlled via governance and the list of tokens allowed is maintained in -FeeCurrencyWhitelist.sol. Fee abstraction on Celo works with EOAs. No paymaster required! Learn all -about [fee abstraction](/developer/fee-abstraction). - -## Transaction Fee Allocation Post-L2 Transition - -With the shift to L2, the allocation of transaction fees has been restructured to support the network's evolving operational needs: - -- **Carbon Offset Fund**: 10% of transaction fees continue to support the carbon offset fund, maintaining Celo's environmental commitment. This adjustment reflects the network's reduced carbon footprint following the L2 upgrade. - -- **Network Operations**: The remaining 90% of transaction fees are allocated to essential network operations, including: - - - **Data Availability**: Ensuring that transaction data is accessible and secure. - - - **Layer 1 Fees**: Covering costs associated with interactions between Celo's L2 and the Ethereum mainnet. - - - **Sequencer and Batcher Operations**: Supporting the infrastructure that orders and batches transactions on the network. - - - **Revenue Sharing with the OP-Stack**: Complying with the Superchain Ecosystem requirements, which involve sharing revenue with the OP-Stack. - -This reallocation ensures that transaction fees are utilized effectively to maintain network sustainability and operational efficiency in the L2 environment. - -## Conclusion - -Celo's transition to L2 introduces significant changes to gas pricing and transaction fee allocation, aligning with the network's goals of sustainability, user accessibility, and robust operational support. These adjustments are designed to enhance the overall efficiency and resilience of the Celo ecosystem. \ No newline at end of file diff --git a/_deprecated/what-is-celo/using-celo/protocol/transaction/transaction-types.mdx b/_deprecated/what-is-celo/using-celo/protocol/transaction/transaction-types.mdx deleted file mode 100644 index d8614509f2..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/transaction/transaction-types.mdx +++ /dev/null @@ -1,489 +0,0 @@ ---- -title: Transaction Types on Celo -og:description: This page contains an explainer on transaction types supported on Celo and a demo to make specific transactions. -sidebarTitle: "Transaction Types" ---- - -This page contains an explainer on transaction types supported on Celo and a demo to make specific transactions. - ---- - -## Summary - -Celo has support for all Ethereum transaction types (i.e. "100% Ethereum compatibility") and a single Celo transaction type. - -### Actively Supported on Celo - -| Chain | Transaction type | # | Specification | Recommended | Support | Comment | -| ----------------------------------------------------------------------- | -------------------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | --------- | -------------------------------------------------------- | -| | Dynamic fee transaction v2 | `123` | [CIP-64](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0064.md) | ✅ | Active 🟢 | Supports paying gas in custom fee currencies | -| | Set code transaction | `4` | [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) | Available since the Isthmus hardfork | -| | Dynamic fee transaction | `2` | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) ([CIP-42](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0042.md)) | ✅ | Active 🟢 | Typical Ethereum transaction | -| | Access list transaction | `1` | [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) ([CIP-35](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0035.md)) | ❌ | Active 🟢 | Does not support dynamically changing _base fee_ per gas | -| | Legacy transaction | `0` | [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) ([CIP-35](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0035.md)) | ❌ | Active 🟢 | Does not support dynamically changing _base fee_ per gas | - -### Deprecated on Celo - -| Chain | Transaction type | # | Specification | 　 Support | Comment | -| ------------------------------------------------------------------- | ----------------------- | ----- | -------------------------------------------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| | Dynamic fee transaction | `124` | [CIP-42](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0042.md) | Deprecated 🔴 | Deprecation warning published in [Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md#deprecation-warning) and no longer supported following the transition to Celo L2 | -| | Legacy transaction | `0` | Celo Mainnet launch ([Blockchain client v1.0.0](https://github.com/celo-org/celo-blockchain/tree/celo-v1.0.0)) | Deprecated 🔴 | Deprecation warning published in [Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md#deprecation-warning) and no longer supported following the transition to Celo L2 | - -The stages of support are: - -- **Active support** 🟢: the transaction type is supported and recommended for use. -- **Security support** 🟠: the transaction type is supported but not recommended for use - because it might be deprecated in the future. -- **Deprecated** 🔴: the transaction type is not supported and not recommended for use. - -### Client Library Support - -Legend: - -- = - support for the recommended Ethereum transaction type (`2`) -- = support - for the recommended Celo transaction type (`123`) -- ✅ = available -- ❌ = not available - -| Client library | Language | | since | | since | Comment | -| --------------------- | :------: | :---------------------------------------------------------------------: | :---: | :------------------------------------------------------------------ | --------------------------------------------------------------------------- | ------------------------------------------------ | -| `viem` | TS/JS | ✅ | | ✅ | >[1.19.5][1] | --- | -| `ethers` | TS/JS | ✅ | | ❌ | | Support via fork in
`celo-ethers-wrapper` | -| `celo-ethers-wrapper` | TS/JS | ✅ | | ✅ | >[2.0.0](https://github.com/jmrossy/celo-ethers-wrapper/releases/tag/2.0.0) | --- | -| `web3js` | TS/JS | ✅ | | ❌ | | Support via fork in
`contractkit` | -| `contractkit` | TS/JS | ✅ | | ✅ | >[5.0.0](https://github.com/celo-org/celo-monorepo/releases/tag/v5.0) | --- | -| `Web3j` | Java | ✅ | | ❌ | | --- | -| `rust-ethers` | Rust | ✅ | | ❌ | | --- | -| `brownie` | Python | ✅ | | ❌ | | --- | - -[1]: https://github.com/wevm/viem/blob/main/src/CHANGELOG.md#1195 - -## Background - -### Legacy Transactions - -Ethereum originally had one format for transactions (now called "legacy transactions"). -A legacy transaction contains the following transaction parameters: -`nonce`, `gasPrice`, `gasLimit`, `recipient`, `amount`, `data`, and `chaindId`. - -To produce a valid "legacy transaction": - -1. the **transaction parameters** are [RLP-encoded](https://eth.wiki/fundamentals/rlp): - - ``` - RLP([nonce, gasprice, gaslimit, recipient, amount, data, chaindId, 0, 0]) - ``` - -1. the RLP-encoded transaction is hashed (using Keccak256). - -1. the hash is signed with a private key using the ECDSA algorithm, which generates the `v`, `r`, - and `s` **signature parameters**. - -1. the transaction _and_ signature parameters above are RLP-encoded to produce a valid **signed - transaction**: - - ``` - RLP([nonce, gasprice, gaslimit, recipient, amount, data, v, r, s]) - ``` - -A valid signed transaction can then be submitted on-chain, and its raw parameters can be -parsed by RLP-decoding the transaction. - -### Typed Transactions - -Over time, the Ethereum community has sought to add new types of transactions -such as dynamic fee transactions -([EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559)) -or optional access list transactions -([EIP-2930: Optional access lists](https://eips.ethereum.org/EIPS/eip-2930)) -to supported new desired behaviors on the network. - -To allow new transactions to be supported without breaking support with the -legacy transaction format, the concept of **typed transactions** was proposed in -[EIP-2718: Typed Transaction Envelope](https://eips.ethereum.org/EIPS/eip-2718), which introduces -a new high-level transaction format that is used to implement all future transaction types. - -### Distinguishing Between Legacy and Typed Transactions - -Whereas a valid "legacy transaction" is simply an RLP-encoded list of -**transaction parameters**, a valid "typed transactions" is an arbitrary byte array -prepended with a **transaction type**, where: - -- a **transaction type**, is a number between 0 (`0x00`) and 127 (`0x7f`) representing - the type of the transaction, and - -- a **transaction payload**, is arbitrary byte data that encodes raw transaction parameters - in compliance with the specified transaction type. - -To distinguish between legacy transactions and typed transactions at the client level, -the EIP designers observed that the **first byte** of a legacy transaction would never be in the range -`[0, 0x7f]` (or `[0, 127]`), and instead always be in the range `[0xc0, 0xfe]` (or `[192, 254]`). - -With that observation, transactions can be decoded with the following heuristic: - -- read the first byte of a transaction -- if it's bigger than `0x7f` (`127`), then it's a **legacy transaction**. To decode it, you - must read _all_ bytes (including the first byte just read) and interpret them as a - legacy transaction. -- else, if it's smaller or equal to `0x7f` (`127`), then it's a **typed transaction**. To decode - it you must read the _remaining_ bytes (excluding the first byte just read) and interpret them - according to the specified transaction type. - -Every transaction type is defined in an EIP, which specifies how to _encode_ as well as _decode_ -transaction payloads. This means that a typed transaction can only be interpreted with knowledge of -its transaction type and a relevant decoder. - -## List of Transaction Types on Celo - -### Legacy Transaction (`0`) - - -This transaction type is 100% compatible with Ethereum and has no Celo-specific parameters. - - -Although legacy transactions are never formally prepended with the `0x00` transaction type, -they are commonly referred to as "type 0" transactions. - -- This transaction is defined as follows: - - ``` - RLP([nonce, gasprice, gaslimit, recipient, amount, data, v, r, s]) - ``` - -- It was introduced on Ethereum during Mainnet launch on [Jul 30, 2015](https://en.wikipedia.org/wiki/Ethereum) - as specified in the [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf). - -- It was introduced on Celo during the - [Celo Donut hard fork](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0027.md) - on [May 19, 2021](https://blog.celo.org/donut-hardfork-is-live-on-celo-585e2e294dcb) - as specified in [CIP-35: Support for Ethereum-compatible transactions](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0035.md). - -### Access List Transaction (`1`) - - -This transaction type is 100% compatible with Ethereum and has no Celo-specific parameters. - - -- This transaction is defined as follows: - - ``` - 0x01 || RLP([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS]) - ``` - -- It was introduced on Ethereum during the Ethereum Berlin hard fork on - [Apr, 15 2021](https://ethereum.org/en/history/#berlin) as specified in - [EIP-2930: Optional access lists](https://eips.ethereum.org/EIPS/eip-2930). - -- It was introduced on Celo during the - [Celo Donut hard fork](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0027.md) - on [May 19, 2021](https://blog.celo.org/donut-hardfork-is-live-on-celo-585e2e294dcb) - as specified in [CIP-35: Support for Ethereum-compatible transactions](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0035.md). - -### Dynamic Fee Transaction (`2`) - - -This transaction type is 100% compatible with Ethereum and has no Celo-specific parameters. - - -- This transaction is defined as follows: - - ``` - 0x02 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS]) - ``` - -- It was introduced on Ethereum during the Ethereum London hard fork on - [Aug, 5 2021](https://ethereum.org/en/history/#london) as specified in - [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559). - -- It was introduced on Celo during the - [Celo Espresso hard fork](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0041.md) - on [Mar 8, 2022](https://blog.celo.org/brewing-the-espresso-hardfork-92a696af1a17) as specified - in [CIP-42: Modification to EIP-1559](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0042.md) - -### Set Code Transaction (`4`) - - -This transaction type is 100% compatible with Ethereum and has no Celo-specific parameters. - - -- This transaction is defined as follows: - - ``` - 0x04 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, authorizationList, signatureYParity, signatureR, signatureS]) - ``` - -- It was introduced on Ethereum during the Ethereum Pectra hard fork on - [May, 7 2025](https://ethereum.org/en/history/#pectra) as specified in - [EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702). - -- It is scheduled for support on Celo during the - [Celo Isthmus](/infra-partners/notices/isthmus-upgrade) hardfork. - -### Legacy Transaction (`0`) - - -This transaction type is no longer supported following the migration to Celo L2. - - - -This transaction is not compatible with Ethereum and has three Celo-specific -parameters: `feecurrency`, `gatewayfeerecipient`, and `gatewayfee`. - - -- This transaction is defined as follows: - - ``` - RLP([nonce, gasprice, gaslimit, feecurrency, gatewayfeerecipient, gatewayfee, recipient, amount, data, v, r, s]) - ``` - -- It was introduced on Celo during Mainnet launch on - [Apr 22, 2020](https://dune.com/queries/3106924/5185945) as specified in - [Blockchain client v1.0.0](https://github.com/celo-org/celo-blockchain/tree/celo-v1.0.0). - -### Dynamic Fee Transaction (`124`) - - -This transaction type is no longer supported following the migration to Celo L2. - - - -This transaction is not compatible with Ethereum and has three Celo-specific -parameters: `feecurrency`, `gatewayfeerecipient`, and `gatewayfee`. - - -> **Warning** -> This transaction type is scheduled for deprecation. A deprecation warning was published in the -> [Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md#deprecation-warning) -> on [Sep 26, 2023](https://forum.celo.org/t/mainnet-alfajores-gingerbread-hard-fork-release-sep-26-17-00-utc/6499). - -- This transaction is defined as follows: - - ``` - 0x7c || RLP([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, feecurrency, gatewayfeerecipient, gatewayfee, destination, amount, data, access_list, v, r, s]) - ``` - -- It was introduced on Celo during the - [Celo Espresso hard fork](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0041.md) - on [Mar 8, 2022](https://blog.celo.org/brewing-the-espresso-hardfork-92a696af1a17) as specified - in [CIP-42: Modification to EIP-1559](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0042.md). - -### Dynamic Fee Transaction v2 (`123`) - - -This transaction is not compatible with Ethereum and has one Celo-specific -parameter: `feecurrency`. - - -- This transaction is defined as follows: - - ``` - 0x7b || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, feeCurrency, v, r, s]) - ``` - -- It was introduced on Celo during the - [Celo Gingerbread hard fork](https://github.com/celo-org/celo-proposals/blob/8260b49b2ec9a87ded6727fec7d9104586eb0752/CIPs/cip-0062.md) - on [Sep 26, 2023](https://forum.celo.org/t/mainnet-alfajores-gingerbread-hard-fork-release-sep-26-17-00-utc/6499) - as specified in - [CIP-64: New Transaction Type: Celo Dynamic Fee v2](https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-0064.md) - -## How to Send Transactions - -### Import Dependencies - - - - - -```ts -import { - createPublicClient, - createWalletClient, - hexToBigInt, - http, - parseEther, - parseGwei, -} from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { celoAlfajores } from "viem/chains"; -import "dotenv/config"; // use to read private key from environment variable -``` - - - - - -### Create Public and Wallet Client - - - - - -```ts -const PRIVATE_KEY = process.env.PRIVATE_KEY; - -/** - * Boilerplate to create a viem client - */ -const account = privateKeyToAccount(`0x${PRIVATE_KEY}`); -const publicClient = createPublicClient({ - chain: celoAlfajores, - transport: http(), -}); -const walletClient = createWalletClient({ - chain: celoAlfajores, // Celo testnet - transport: http(), -}); -``` - - - - - -### Function to Print Transaction Receipt - - - - - - ```ts - function printFormattedTransactionReceipt(transactionReceipt: any) { - - const { - blockHash, - blockNumber, - contractAddress, - cumulativeGasUsed, - effectiveGasPrice, - from, - gasUsed, - logs, - logsBloom, - status, - to, - transactionHash, - transactionIndex, - type, - feeCurrency, - gatewayFee, - gatewayFeeRecipient - } = transactionReceipt; - - const filteredTransactionReceipt = { - type, - status, - transactionHash, - from, - to - }; - - console.log(`Transaction details:`, filteredTransactionReceipt, `\n`); - } - ``` - - - - - -### Code to Send Transaction Type (0) - - - - - - ```ts - /** - - Transation type: 0 (0x00) - - Name: "Legacy" - - Description: Ethereum legacy transaction - */ - async function demoLegacyTransactionType() { - console.log(`Initiating legacy transaction...`); - const transactionHash = await walletClient.sendTransaction({ - account, // Sender - to: "0x70997970c51812dc3a010c7d01b50e0d17dc79c8", // Recipient (illustrative address) - value: parseEther("0.01"), // 0.01 CELO - gasPrice: parseGwei("20"), // Special field for legacy transaction type - }); - - const transactionReceipt = await publicClient.waitForTransactionReceipt({ - hash: await transactionHash, - }); - - printFormattedTransactionReceipt(transactionReceipt); - } - ``` - - - - - -### Code to Send Transaction Type (2) - - - - - - ```ts - /** - * Transaction type: 2 (0x02) - * Name: "Dynamic fee" - * Description: Ethereum EIP-1559 transaction - */ - async function demoDynamicFeeTransactionType() { - console.log(`Initiating dynamic fee (EIP-1559) transaction...`); - const transactionHash = await walletClient.sendTransaction({ - account, // Sender - to: "0x70997970c51812dc3a010c7d01b50e0d17dc79c8", // Recipient (illustrative address) - value: parseEther("0.01"), // 0.01 CELO - maxFeePerGas: parseGwei("10"), // Special field for dynamic fee transaction type (EIP-1559) - maxPriorityFeePerGas: parseGwei("10"), // Special field for dynamic fee transaction type (EIP-1559) - }); - - const transactionReceipt = await publicClient.waitForTransactionReceipt({ - hash: await transactionHash, - }); - - printFormattedTransactionReceipt(transactionReceipt); - } - ``` - - - - - -### Code to Send Transaction Type (123) - - - - - - ```ts - /** - * Transaction type: 123 (0x7b) - * Name: "Dynamic fee" - * Description: Celo dynamic fee transaction (with custom fee currency) - */ - async function demoFeeCurrencyTransactionType() { - console.log(`Initiating custom fee currency transaction...`); - const transactionHash = await walletClient.sendTransaction({ - account, // Sender - to: "0x70997970c51812dc3a010c7d01b50e0d17dc79c8", // Recipient (illustrative address) - value: parseEther("0.01"), // 0.01 CELO - feeCurrency: "0x874069Fa1Eb16D44d622F2e0Ca25eeA172369bC1", // cUSD fee currency - maxFeePerGas: parseGwei("10"), // Special field for dynamic fee transaction type (EIP-1559) - maxPriorityFeePerGas: parseGwei("10"), // Special field for dynamic fee transaction type (EIP-1559) - }); - - const transactionReceipt = await publicClient.waitForTransactionReceipt({ - hash: await transactionHash, - }); - - printFormattedTransactionReceipt(transactionReceipt); - } - ``` - - - - diff --git a/_deprecated/what-is-celo/using-celo/protocol/transaction/tx-comment-encryption.mdx b/_deprecated/what-is-celo/using-celo/protocol/transaction/tx-comment-encryption.mdx deleted file mode 100644 index 0946312da1..0000000000 --- a/_deprecated/what-is-celo/using-celo/protocol/transaction/tx-comment-encryption.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Encrypted Payment Comments" -sidebarTitle: "TX Comment Encryption" -og:description: Overview of encrypted payment comments and its technical details related to symmetric and asymmetric encryption. ---- - -In this section, you will find detailed information about the various transaction types supported on Celo, including encrypted payment comments and their technical details, as well as insights into gas pricing and fee abstraction. - ---- - -## Introduction to Comment Encryption - -As part of Celo's identity protocol, a public encryption key is stored along with a user's address in the `Accounts` contract. - -Both the address key pair and the encryption key pair are derived from the backup phrase. When sending a transaction the encryption key of the recipient is retrieved when getting his or her address. The comment is then encrypted using a 128 bit hybrid encryption scheme \(ECDH on secp256k1 with AES-128-CTR\). This system ensures that comments can only be read by the sending and receiving parties and that messages will be recovered when restoring a wallet from its backup phrase. - -## Comment Encryption Technical Details - -A 128 bit randomly generated session key, sk, is generated and used to symmetrically encrypt the comment. sk is asymmetrically encrypted to the sender and to the recipient. - -‌`Encrypted = ECIES(sk, to=pubSelf) | ECIES(sk, to=pubOther) | AES(ke=sk, km=sk, comment)` - -### ‌Symmetric Encryption \(AES-128-CTR\) - -- Takes encryption key, ke, and MAC key, km, and the data to encrypt, plaintext -- Cipher: AES-128-CTR using a randomly generated iv -- Authenticate iv \| ciphertext using HMAC with SHA-256 and km -- Return iv \| ciphertext \| mac - -### Asymmetric Encryption \(ECIES\) - -1. Takes data to encrypt, plaintext, and the public key of the recipient, pubKeyTo -2. Generate an ephemeral keypair, ephemPubKey and ephemPrivKey -3. Derive 32 bytes of key material, k, from ECDH between ephemPrivKey and pubKeyTousing ConcatKDF \(specified as NIST 800-56C Rev 1 One Step KDF\) with SHA-256 for H\(x\) -4. The encryption key, ke, is the first 128 bits of k -5. The MAC key, km, is SHA-256 of the second 128 bits of k -6. Encrypt the plaintext symmetrically with AES-128-CTR using ke, km, and a random iv -7. Return ephemPubKey \| AES-128-CTR-HMAC\(ke, km, plaintext\) where the public key needs to be uncompressed \(current limitation with decrypt\). \ No newline at end of file From 1880ab77f532f48b8bb8ed080d22d6050811fdba Mon Sep 17 00:00:00 2001 From: Paul Lange Date: Mon, 24 Aug 2026 11:32:49 +0200 Subject: [PATCH 2/5] docs: flatten 49 redirect chains to their final destination --- docs.json | 98 +++++++++++++++++++++++++++---------------------------- 1 file changed, 49 insertions(+), 49 deletions(-) diff --git a/docs.json b/docs.json index d6f7c0707e..c5a26913e9 100644 --- a/docs.json +++ b/docs.json @@ -728,7 +728,7 @@ }, { "source": "/blog/2022/03/04/Celo%20CLI:%20A%20Practical%20Guide%20to%20Energize%20your%20Celo%20Toolkit", - "destination": "/cli" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/blog/2022/03/04/Celo%20Composer%20-%20Easily%20Build%20Full-Stack%20Mobile%20dApps%20on%20Celo", @@ -908,7 +908,7 @@ }, { "source": "/celo-codebase/protocol/oracles/oracles-on-celo", - "destination": "/developer/oracles" + "destination": "/tooling/oracles" }, { "source": "/celo-codebase/protocol/oracles/redstone-protocol-how-to", @@ -1064,31 +1064,31 @@ }, { "source": "/celo-codebase/wallet", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/celo-codebase/wallet/how-the-wallet-works/invitations", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/celo-codebase/wallet/how-the-wallet-works/README", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/celo-codebase/wallet/how-the-wallet-works/sending-and-requesting-payments", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/celo-codebase/wallet/how-the-wallet-works/ultralight-node-sync", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/celo-codebase/wallet/how-the-wallet-works/verification", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/celo-codebase/wallet/intro", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/celo-gold-holder-guide/ledger", @@ -1212,15 +1212,15 @@ }, { "source": "/celo-sdk", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/celo-sdk/celo-dapp-gallery", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/celo-sdk/contractkit", - "destination": "/developer/contractkit" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/celo.org", @@ -1376,7 +1376,7 @@ }, { "source": "/command-line-interface/introduction", - "destination": "/cli" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/command-line-interface/lockedgold", @@ -1432,7 +1432,7 @@ }, { "source": "/blog/2022/05/10/A%20Boilerplate%20guide%20to%20Airdropping%20on%20Celo", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/blog/2022/05/10/Getting%20started%20with%20DAOs%20on%20Celo", @@ -1444,11 +1444,11 @@ }, { "source": "/blog/2022/05/19/3%20Simple%20Steps%20to%20Get%20Started%20with%20Valora%20on%20Celo", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/blog/2022/05/20/ContractKit%20-%20A%20Practical%20Guide%20to%20Interacting%20with%20the%20Celo%20Core%20Contracts", - "destination": "/developer/contractkit" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/blog/2022/05/24/Celo%20Dappstarter:%20Extend%20and%20Customize%20your%20Full-Stack%20Mobile%20dApps", @@ -1456,7 +1456,7 @@ }, { "source": "/blog/2022/06/14/How%20to%20quickly%20build%20an%20NFT%20collection%20on%20Celo", - "destination": "/build/build-with-thirdweb/celo-nft-drop-tutorial" + "destination": "/tooling/dev-environments/thirdweb/thirdweb" }, { "source": "/blog/tags/celo.org", @@ -1500,11 +1500,11 @@ }, { "source": "/developer-guide", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-guide/celo-dapp-gallery", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-guide/celo-for-eth-devs", @@ -1512,7 +1512,7 @@ }, { "source": "/developer-guide/contractkit", - "destination": "/developer/contractkit" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-guide/contractkit/contracts-wrappers-registry", @@ -1580,11 +1580,11 @@ }, { "source": "/developer-guide/overview", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-guide/overview/celo-dapp-gallery", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-guide/overview/celo-for-eth-devs", @@ -1596,11 +1596,11 @@ }, { "source": "/developer-guide/overview/introduction", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-guide/overview/introduction/contractkit", - "destination": "/developer/contractkit" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-guide/sdk-code-reference/summary-2/classes/_wrappers_reserve_.reservewrapper", @@ -1608,7 +1608,7 @@ }, { "source": "/developer-guide/start", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-guide/start/develop-on-windows", @@ -1624,11 +1624,11 @@ }, { "source": "/developer-guide/start/web-dapp", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-resources/celo-dapp-gallery", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-resources/celo-for-eth-devs", @@ -1644,7 +1644,7 @@ }, { "source": "/developer-resources/contractkit/index", - "destination": "/developer/contractkit" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-resources/contractkit/migrating-to-contractkit-v1", @@ -1672,7 +1672,7 @@ }, { "source": "/developer-resources/deploy-dapp", - "destination": "/developer/deploy" + "destination": "/tooling/dev-environments" }, { "source": "/developer-resources/deploy-hardhat", @@ -1688,7 +1688,7 @@ }, { "source": "/developer-resources/deploy-truffle", - "destination": "/developer/deploy" + "destination": "/tooling/dev-environments" }, { "source": "/developer-resources/develop-on-windows", @@ -1696,7 +1696,7 @@ }, { "source": "/developer-resources/ethers-js-wrapper", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-resources/forno/index", @@ -1744,7 +1744,7 @@ }, { "source": "/developer-resources/overview", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer-resources/testnet-wallet", @@ -1752,7 +1752,7 @@ }, { "source": "/developer-resources/use-contractkit", - "destination": "/developer/contractkit" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-resources/using-mac", @@ -1764,23 +1764,23 @@ }, { "source": "/developer-resources/walkthroughs/no-code-erc20", - "destination": "/build" + "destination": "/build-on-celo" }, { "source": "/developer-resources/walkthroughs/no-code-erc721", - "destination": "/build" + "destination": "/build-on-celo" }, { "source": "/developer-resources/walkthroughs/hello-celo", - "destination": "/build" + "destination": "/build-on-celo" }, { "source": "/developer-resources/walkthroughs/web-dapp", - "destination": "/build" + "destination": "/build-on-celo" }, { "source": "/developer-resources/walkthroughs/valora-wc-v1", - "destination": "/build" + "destination": "/build-on-celo" }, { "source": "/developer/build-on-minipay", @@ -1852,7 +1852,7 @@ }, { "source": "/developer/evm-tools", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/developer/fee-currency", @@ -1888,7 +1888,7 @@ }, { "source": "/es/learn/evm-compatible-tooling", - "destination": "/developer" + "destination": "/tooling/overview" }, { "source": "/faqs", @@ -2040,11 +2040,11 @@ }, { "source": "/getting-started/using-the-cli", - "destination": "/cli" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/getting-started/using-the-mobile-wallet", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/getting-started/validator-troubleshooting-faq", @@ -2052,11 +2052,11 @@ }, { "source": "/getting-started/wallets", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/getting-started/wallets/index", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/getting-started/wallets/using-metamask-with-celo", @@ -2092,15 +2092,15 @@ }, { "source": "/getting-started/wallets#celo-compatible-wallets", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/getting-started/wallets#celo-native-wallets", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/getting-started/wallets#celowalletapp", - "destination": "/wallet" + "destination": "/tooling/wallets" }, { "source": "/holder/asset", @@ -2376,11 +2376,11 @@ }, { "source": "/v/master/developer-guide/start/hello-mobile-dapp", - "destination": "/build" + "destination": "/build-on-celo" }, { "source": "/v/master/developer-guide/start/hellocelo", - "destination": "/build" + "destination": "/build-on-celo" }, { "source": "/v/master/getting-started/baklava-testnet", From 28c8c1f0fca248e9d5751fd6be374b0e9dc9a9d4 Mon Sep 17 00:00:00 2001 From: Paul Lange Date: Mon, 24 Aug 2026 11:33:06 +0200 Subject: [PATCH 3/5] docs: re-point 162 dead-end redirects, remove the 3-entry /glossary cycle --- docs.json | 324 ++++++++++++++++++++++++++---------------------------- 1 file changed, 156 insertions(+), 168 deletions(-) diff --git a/docs.json b/docs.json index c5a26913e9..1c7808df7b 100644 --- a/docs.json +++ b/docs.json @@ -724,7 +724,7 @@ }, { "source": "/blog/2022/03/04/3%20Simple%20Steps%20to%20Connect%20your%20MetaMask%20Wallet%20To%20Celo", - "destination": "/wallet/metamask/setup" + "destination": "/tooling/wallets/metamask/use" }, { "source": "/blog/2022/03/04/Celo%20CLI:%20A%20Practical%20Guide%20to%20Energize%20your%20Celo%20Toolkit", @@ -732,15 +732,15 @@ }, { "source": "/blog/2022/03/04/Celo%20Composer%20-%20Easily%20Build%20Full-Stack%20Mobile%20dApps%20on%20Celo", - "destination": "/tooling/sdks/composer-kit" + "destination": "/tooling/libraries-sdks/composer-kit" }, { "source": "/blog/2022/03/06/6%20Steps%20to%20Quickly%20Build%20Smart%20Contracts%20on%20Celo%20with%20Remix", - "destination": "/tooling/deploy/remix" + "destination": "/tooling/dev-environments/remix" }, { "source": "/blog/2022/03/07/Truffle%20and%20Celo%20%7C%20The%20Ultimate%20Guide%20to%20Deploy%20Celo%20dApps%20with%20Truffle", - "destination": "/tooling/deploy" + "destination": "/tooling/dev-environments" }, { "source": "/cel2/builders", @@ -748,7 +748,7 @@ }, { "source": "/cel2/eclair", - "destination": "/tooling/testnets/" + "destination": "/tooling/testnets/celo-sepolia" }, { "source": "/cel2/l2-operator-guide", @@ -776,35 +776,35 @@ }, { "source": "/celo-codebase/protocol/bridging/bridging-native-assets", - "destination": "/developer/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/bridging/bridging-to-celo", - "destination": "/developer/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/bridging/bridging-tokens-with-etherscan", - "destination": "/developer/bridges/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/bridging/migrating-to-optics-v2", - "destination": "/developer/bridges/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/bridging/optics-bridge-faq", - "destination": "/developer/bridges/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/bridging/optics-gui", - "destination": "/developer/bridges/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/bridging/optics-gui-kr", - "destination": "/developer/bridges/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/bridging/optics-gui-zh_cn", - "destination": "/developer/bridges/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/consensus", @@ -900,11 +900,11 @@ }, { "source": "/celo-codebase/protocol/optics", - "destination": "/developer/bridges/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/celo-codebase/protocol/oracles/band-protocol-how-to", - "destination": "/developer/oracles/band-protocol" + "destination": "/tooling/oracles/band-protocol" }, { "source": "/celo-codebase/protocol/oracles/oracles-on-celo", @@ -912,11 +912,11 @@ }, { "source": "/celo-codebase/protocol/oracles/redstone-protocol-how-to", - "destination": "/developer/oracles/redstone" + "destination": "/tooling/oracles/redstone" }, { "source": "/celo-codebase/protocol/plumo", - "destination": "/legacy/protocol" + "destination": "/legacy/overview" }, { "source": "/celo-codebase/protocol/proof-of-stake", @@ -1092,11 +1092,11 @@ }, { "source": "/celo-gold-holder-guide/ledger", - "destination": "/wallet/ledger/setup" + "destination": "/tooling/wallets/ledger/setup" }, { "source": "/celo-gold-holder-guide/ledger#install-the-celo-cli", - "destination": "/wallet/ledger/to-celo-cli" + "destination": "/tooling/wallets/ledger/to-celo-cli" }, { "source": "/celo-gold-holder-guide/quick-start", @@ -1108,7 +1108,7 @@ }, { "source": "/celo-gold-holder-guide/voting-validators", - "destination": "/wallet/staking" + "destination": "/legacy/validator/voting" }, { "source": "/celo-holder-guide/celo-exchange-bot", @@ -1120,15 +1120,15 @@ }, { "source": "/celo-holder-guide/connecting-ledger-celo-terminal-wallet", - "destination": "/wallet/ledger/to-celo-terminal" + "destination": "/tooling/wallets/ledger/to-celo-terminal" }, { "source": "/celo-holder-guide/connecting-ledger-celo-web-wallet", - "destination": "/wallet/ledger/to-celo-web" + "destination": "/tooling/wallets/ledger/to-celo-web" }, { "source": "/celo-holder-guide/connecting-ledger-celocli", - "destination": "/wallet/ledger/to-celo-cli" + "destination": "/tooling/wallets/ledger/to-celo-cli" }, { "source": "/celo-holder-guide/cusd", @@ -1144,7 +1144,7 @@ }, { "source": "/celo-holder-guide/ledger", - "destination": "/wallet/ledger/setup" + "destination": "/tooling/wallets/ledger/setup" }, { "source": "/celo-holder-guide/owners", @@ -1164,7 +1164,7 @@ }, { "source": "/celo-holder-guide/voting-validators", - "destination": "/wallet/staking" + "destination": "/legacy/validator/voting" }, { "source": "/celo-owner-guide/celo-exchange-bot", @@ -1184,7 +1184,7 @@ }, { "source": "/celo-owner-guide/ledger", - "destination": "/wallet/ledger/setup" + "destination": "/tooling/wallets/ledger/setup" }, { "source": "/celo-owner-guide/quick-start", @@ -1196,7 +1196,7 @@ }, { "source": "/celo-owner-guide/quick-start#vote-for-a-validator-group", - "destination": "/wallet/staking" + "destination": "/legacy/validator/voting" }, { "source": "/celo-owner-guide/release-gold", @@ -1208,7 +1208,7 @@ }, { "source": "/celo-owner-guide/voting-validators", - "destination": "/wallet/staking" + "destination": "/legacy/validator/voting" }, { "source": "/celo-sdk", @@ -1228,151 +1228,151 @@ }, { "source": "/cli/autocomplete", - "destination": "/cli/autocomplete" + "destination": "/tooling/libraries-sdks/cli/autocomplete" }, { "source": "/cli/commands/account", - "destination": "/cli/account" + "destination": "/tooling/libraries-sdks/cli/account" }, { "source": "/cli/commands/commands", - "destination": "/cli/commands" + "destination": "/tooling/libraries-sdks/cli/commands" }, { "source": "/cli/commands/config", - "destination": "/cli/config" + "destination": "/tooling/libraries-sdks/cli/config" }, { "source": "/cli/commands/dkg", - "destination": "/cli/dkg" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/cli/commands/election", - "destination": "/cli/election" + "destination": "/tooling/libraries-sdks/cli/election" }, { "source": "/cli/commands/exchange", - "destination": "/cli/exchange" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/cli/commands/governance", - "destination": "/cli/governance" + "destination": "/tooling/libraries-sdks/cli/governance" }, { "source": "/cli/commands/help", - "destination": "/cli/help" + "destination": "/tooling/libraries-sdks/cli/help" }, { "source": "/cli/commands/identity", - "destination": "/cli/identity" + "destination": "/tooling/libraries-sdks/cli/identity" }, { "source": "/cli/commands/lockedgold", - "destination": "/cli/lockedgold" + "destination": "/tooling/libraries-sdks/cli/lockedcelo" }, { "source": "/cli/commands/multisig", - "destination": "/cli/multisig" + "destination": "/tooling/libraries-sdks/cli/multisig" }, { "source": "/cli/commands/network", - "destination": "/cli/network" + "destination": "/tooling/libraries-sdks/cli/network" }, { "source": "/cli/commands/node", - "destination": "/cli/node" + "destination": "/tooling/libraries-sdks/cli/node" }, { "source": "/cli/commands/oracle", - "destination": "/cli/oracle" + "destination": "/tooling/libraries-sdks/cli/oracle" }, { "source": "/cli/commands/plugins", - "destination": "/cli/plugins" + "destination": "/tooling/libraries-sdks/cli/plugins" }, { "source": "/cli/commands/registry", - "destination": "/cli/commands" + "destination": "/tooling/libraries-sdks/cli/commands" }, { "source": "/cli/commands/releasegold", - "destination": "/cli/releasecelo" + "destination": "/tooling/libraries-sdks/cli/releasecelo" }, { "source": "/cli/commands/reserve", - "destination": "/cli/commands" + "destination": "/tooling/libraries-sdks/cli/commands" }, { "source": "/cli/commands/rewards", - "destination": "/cli/rewards" + "destination": "/tooling/libraries-sdks/cli/rewards" }, { "source": "/cli/commands/transfer", - "destination": "/cli/transfer" + "destination": "/tooling/libraries-sdks/cli/transfer" }, { "source": "/cli/commands/validator", - "destination": "/cli/validator" + "destination": "/tooling/libraries-sdks/cli/validator" }, { "source": "/cli/commands/validatorgroup", - "destination": "/cli/validatorgroup" + "destination": "/tooling/libraries-sdks/cli/validatorgroup" }, { "source": "/command-line-interface/account", - "destination": "/cli/account" + "destination": "/tooling/libraries-sdks/cli/account" }, { "source": "/command-line-interface/autocomplete", - "destination": "/cli/autocomplete" + "destination": "/tooling/libraries-sdks/cli/autocomplete" }, { "source": "/command-line-interface/commands", - "destination": "/cli/commands" + "destination": "/tooling/libraries-sdks/cli/commands" }, { "source": "/command-line-interface/commands/account#celocli-account-new", - "destination": "/cli/account" + "destination": "/tooling/libraries-sdks/cli/account" }, { "source": "/command-line-interface/commands/exchange", - "destination": "/cli/exchange" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/command-line-interface/commands/exchange%5B/TD%5D", - "destination": "/cli/exchange" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/command-line-interface/config", - "destination": "/cli/config" + "destination": "/tooling/libraries-sdks/cli/config" }, { "source": "/command-line-interface/dkg", - "destination": "/cli/dkg" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/command-line-interface/election", - "destination": "/cli/election" + "destination": "/tooling/libraries-sdks/cli/election" }, { "source": "/command-line-interface/exchange", - "destination": "/cli/exchange" + "destination": "/tooling/libraries-sdks/cli" }, { "source": "/command-line-interface/governance", - "destination": "/cli/governance" + "destination": "/tooling/libraries-sdks/cli/governance" }, { "source": "/command-line-interface/grandamento", - "destination": "/cli/commands" + "destination": "/tooling/libraries-sdks/cli/commands" }, { "source": "/command-line-interface/help", - "destination": "/cli/help" + "destination": "/tooling/libraries-sdks/cli/help" }, { "source": "/command-line-interface/identity", - "destination": "/cli/identity" + "destination": "/tooling/libraries-sdks/cli/identity" }, { "source": "/command-line-interface/introduction", @@ -1380,55 +1380,55 @@ }, { "source": "/command-line-interface/lockedgold", - "destination": "/cli/lockedgold" + "destination": "/tooling/libraries-sdks/cli/lockedcelo" }, { "source": "/command-line-interface/multisig", - "destination": "/cli/multisig" + "destination": "/tooling/libraries-sdks/cli/multisig" }, { "source": "/command-line-interface/network", - "destination": "/cli/network" + "destination": "/tooling/libraries-sdks/cli/network" }, { "source": "/command-line-interface/node", - "destination": "/cli/node" + "destination": "/tooling/libraries-sdks/cli/node" }, { "source": "/command-line-interface/oracle", - "destination": "/cli/oracle" + "destination": "/tooling/libraries-sdks/cli/oracle" }, { "source": "/command-line-interface/plugins", - "destination": "/cli/plugins" + "destination": "/tooling/libraries-sdks/cli/plugins" }, { "source": "/command-line-interface/releasegold", - "destination": "/cli/releasecelo" + "destination": "/tooling/libraries-sdks/cli/releasecelo" }, { "source": "/command-line-interface/reserve", - "destination": "/cli/commands" + "destination": "/tooling/libraries-sdks/cli/commands" }, { "source": "/command-line-interface/rewards", - "destination": "/cli/rewards" + "destination": "/tooling/libraries-sdks/cli/rewards" }, { "source": "/command-line-interface/transfer", - "destination": "/cli/transfer" + "destination": "/tooling/libraries-sdks/cli/transfer" }, { "source": "/command-line-interface/validator", - "destination": "/cli/validator" + "destination": "/tooling/libraries-sdks/cli/validator" }, { "source": "/command-line-interface/validatorgroup", - "destination": "/cli/validatorgroup" + "destination": "/tooling/libraries-sdks/cli/validatorgroup" }, { "source": "/blog/2022/03/18/Hardhat%20and%20Celo%20%7C%20The%20Ultimate%20Guide%20to%20Deploy%20Celo%20dApps%20using%20Hardhat", - "destination": "/developer/deploy/hardhat" + "destination": "/tooling/dev-environments/hardhat" }, { "source": "/blog/2022/05/10/A%20Boilerplate%20guide%20to%20Airdropping%20on%20Celo", @@ -1440,7 +1440,7 @@ }, { "source": "/blog/2022/05/11/Plumo%20-%20An%20Ultralight%20Blockchain%20Client%20on%20Celo", - "destination": "/legacy/protocol" + "destination": "/legacy/overview" }, { "source": "/blog/2022/05/19/3%20Simple%20Steps%20to%20Get%20Started%20with%20Valora%20on%20Celo", @@ -1452,7 +1452,7 @@ }, { "source": "/blog/2022/05/24/Celo%20Dappstarter:%20Extend%20and%20Customize%20your%20Full-Stack%20Mobile%20dApps", - "destination": "/developer/sdks/composer-kit" + "destination": "/tooling/libraries-sdks/composer-kit" }, { "source": "/blog/2022/06/14/How%20to%20quickly%20build%20an%20NFT%20collection%20on%20Celo", @@ -1496,7 +1496,7 @@ }, { "source": "/contract-addresses", - "destination": "/contracts" + "destination": "/tooling/contracts/core-contracts" }, { "source": "/developer-guide", @@ -1508,7 +1508,7 @@ }, { "source": "/developer-guide/celo-for-eth-devs", - "destination": "/developer/migrate/from-ethereum" + "destination": "/build-on-celo" }, { "source": "/developer-guide/contractkit", @@ -1516,35 +1516,35 @@ }, { "source": "/developer-guide/contractkit/contracts-wrappers-registry", - "destination": "/developer/contractkit/contracts-wrappers-registry" + "destination": "/tooling/libraries-sdks/contractkit/contracts-wrappers-registry" }, { "source": "/developer-guide/contractkit/migrating-to-contractkit-v1", - "destination": "/developer/contractkit/migrating-to-contractkit-v1" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-guide/contractkit/migrating-to-contractkit-v2", - "destination": "/developer/contractkit/migrating-to-contractkit-v2" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-guide/contractkit/notes-web3-with-contractkit", - "destination": "/developer/contractkit/notes-web3-with-contractkit" + "destination": "/tooling/libraries-sdks/contractkit/usage" }, { "source": "/developer-guide/contractkit/odis", - "destination": "/developer/contractkit/odis" + "destination": "/tooling/libraries-sdks/contractkit/odis" }, { "source": "/developer-guide/contractkit/setup", - "destination": "/developer/contractkit/setup" + "destination": "/tooling/libraries-sdks/contractkit/setup" }, { "source": "/developer-guide/contractkit/usage", - "destination": "/developer/contractkit/setup" + "destination": "/tooling/libraries-sdks/contractkit/setup" }, { "source": "/developer-guide/development-chain", - "destination": "/developer/setup/development-chain" + "destination": "/tooling/dev-environments" }, { "source": "/developer-guide/forno", @@ -1588,7 +1588,7 @@ }, { "source": "/developer-guide/overview/celo-for-eth-devs", - "destination": "/developer/migrate/from-ethereum" + "destination": "/build-on-celo" }, { "source": "/developer-guide/overview/integrations/custody", @@ -1604,7 +1604,7 @@ }, { "source": "/developer-guide/sdk-code-reference/summary-2/classes/_wrappers_reserve_.reservewrapper", - "destination": "/developer/contractkit/contracts-wrappers-registry" + "destination": "/tooling/libraries-sdks/contractkit/contracts-wrappers-registry" }, { "source": "/developer-guide/start", @@ -1612,11 +1612,11 @@ }, { "source": "/developer-guide/start/develop-on-windows", - "destination": "/developer/setup/windows" + "destination": "/tooling/overview" }, { "source": "/developer-guide/start/development-chain", - "destination": "/developer/setup/development-chain" + "destination": "/tooling/dev-environments" }, { "source": "/developer-guide/start/wallet-connect", @@ -1632,15 +1632,15 @@ }, { "source": "/developer-resources/celo-for-eth-devs", - "destination": "/developer/migrate/from-ethereum" + "destination": "/build-on-celo" }, { "source": "/developer-resources/contractkit/contracts-wrappers-registry", - "destination": "/developer/contractkit/contracts-wrappers-registry" + "destination": "/tooling/libraries-sdks/contractkit/contracts-wrappers-registry" }, { "source": "/developer-resources/contractkit/data-encryption-key", - "destination": "/developer/contractkit/data-encryption-key" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-resources/contractkit/index", @@ -1648,27 +1648,27 @@ }, { "source": "/developer-resources/contractkit/migrating-to-contractkit-v1", - "destination": "/developer/contractkit/migrating-to-contractkit-v1" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-resources/contractkit/migrating-to-contractkit-v2", - "destination": "/developer/contractkit/migrating-to-contractkit-v2" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/developer-resources/contractkit/notes-web3-with-contractkit", - "destination": "/developer/contractkit/notes-web3-with-contractkit" + "destination": "/tooling/libraries-sdks/contractkit/usage" }, { "source": "/developer-resources/contractkit/odis", - "destination": "/developer/contractkit/odis" + "destination": "/tooling/libraries-sdks/contractkit/odis" }, { "source": "/developer-resources/contractkit/setup", - "destination": "/developer/contractkit/setup" + "destination": "/tooling/libraries-sdks/contractkit/setup" }, { "source": "/developer-resources/contractkit/usage", - "destination": "/developer/contractkit/setup" + "destination": "/tooling/libraries-sdks/contractkit/setup" }, { "source": "/developer-resources/deploy-dapp", @@ -1676,15 +1676,15 @@ }, { "source": "/developer-resources/deploy-hardhat", - "destination": "/developer/deploy/hardhat" + "destination": "/tooling/dev-environments/hardhat" }, { "source": "/developer-resources/deploy-remix", - "destination": "/developer/deploy/remix" + "destination": "/tooling/dev-environments/remix" }, { "source": "/developer-resources/deploy-replit", - "destination": "/developer/setup/replit" + "destination": "/tooling/dev-environments" }, { "source": "/developer-resources/deploy-truffle", @@ -1692,7 +1692,7 @@ }, { "source": "/developer-resources/develop-on-windows", - "destination": "/developer/setup/windows" + "destination": "/tooling/overview" }, { "source": "/developer-resources/ethers-js-wrapper", @@ -1748,7 +1748,7 @@ }, { "source": "/developer-resources/testnet-wallet", - "destination": "/developer/setup/wallet" + "destination": "/tooling/wallets/metamask/add-celo-testnet-to-metamask" }, { "source": "/developer-resources/use-contractkit", @@ -1756,11 +1756,11 @@ }, { "source": "/developer-resources/using-mac", - "destination": "/developer/setup/mac" + "destination": "/tooling/dev-environments" }, { "source": "/developer-resources/walkthroughs/development-chain", - "destination": "/developer/setup/development-chain" + "destination": "/tooling/dev-environments" }, { "source": "/developer-resources/walkthroughs/no-code-erc20", @@ -1860,7 +1860,7 @@ }, { "source": "/developer/indexer", - "destination": "/tooling/indexers" + "destination": "/tooling/indexers/overview" }, { "source": "/developer/indexer/overview", @@ -1920,7 +1920,7 @@ }, { "source": "/general/ecosystem/governance", - "destination": "/home/protocol/governance" + "destination": "/home/protocol/governance/overview" }, { "source": "/general/ecosystem/overview", @@ -1978,10 +1978,6 @@ "source": "/getting-started/choosing-a-network", "destination": "/build-on-celo/network-overview" }, - { - "source": "/getting-started/glossary", - "destination": "/glossary" - }, { "source": "/getting-started/hosted-nodes", "destination": "/tooling/nodes/overview" @@ -2060,35 +2056,35 @@ }, { "source": "/getting-started/wallets/using-metamask-with-celo", - "destination": "/wallet/metamask/setup" + "destination": "/tooling/wallets/metamask/use" }, { "source": "/getting-started/wallets/using-metamask-with-celo/manual-setup", - "destination": "/wallet/metamask/setup" + "destination": "/tooling/wallets/metamask/use" }, { "source": "/getting-started/wallets/using-metamask-with-celo/manual-setup#adding-a-celo-network-to-metamask", - "destination": "/wallet/metamask/setup" + "destination": "/tooling/wallets/metamask/use" }, { "source": "/getting-started/wallets/using-metamask-with-celo/manual-setup#adding-tokens-eg-cusd-ceur", - "destination": "/wallet/metamask/setup" + "destination": "/tooling/wallets/metamask/use" }, { "source": "/getting-started/wallets/using-metamask-with-celo/manual-setup#sending-assets-to-metamask", - "destination": "/wallet/metamask/setup" + "destination": "/tooling/wallets/metamask/use" }, { "source": "/getting-started/wallets/using-metamask-with-celo/manual-setup#setup", - "destination": "/wallet/metamask/setup" + "destination": "/tooling/wallets/metamask/use" }, { "source": "/getting-started/wallets/using-metamask-with-celo/using-a-ledger-with-metamask", - "destination": "/wallet/ledger/to-metamask" + "destination": "/tooling/wallets/ledger/setup" }, { "source": "/getting-started/wallets/using-metamask-with-celo#importing-via-private-key", - "destination": "/wallet/metamask/import" + "destination": "/tooling/wallets/metamask/import" }, { "source": "/getting-started/wallets#celo-compatible-wallets", @@ -2184,15 +2180,15 @@ }, { "source": "/protocol/bridge", - "destination": "/tooling/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/protocol/bridges", - "destination": "/tooling/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/protocol/bridging", - "destination": "/tooling/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/protocol/consensus/index", @@ -2216,11 +2212,11 @@ }, { "source": "/protocol/cross-chain-messaging", - "destination": "/developer/bridges/cross-chain-messaging" + "destination": "/tooling/bridges/cross-chain-messaging" }, { "source": "/protocol/governance", - "destination": "/home/protocol/governance" + "destination": "/home/protocol/governance/overview" }, { "source": "/protocol/identity/index", @@ -2256,55 +2252,55 @@ }, { "source": "/protocol/pos/epoch-rewards", - "destination": "/home/protocol/pos/epoch-rewards" + "destination": "/legacy/protocol/pos/epoch-rewards" }, { "source": "/protocol/pos/epoch-rewards-carbon-offsetting-fund", - "destination": "/home/protocol/pos/epoch-rewards-carbon-offsetting-fund" + "destination": "/home/protocol/epoch-rewards/carbon-offsetting-fund" }, { "source": "/protocol/pos/epoch-rewards-community-fund", - "destination": "/home/protocol/pos/epoch-rewards-community-fund" + "destination": "/home/protocol/epoch-rewards/community-fund" }, { "source": "/protocol/pos/epoch-rewards-locked-gold", - "destination": "/home/protocol/pos/epoch-rewards-locked-gold" + "destination": "/legacy/protocol/pos/epoch-rewards-locked-gold" }, { "source": "/protocol/pos/epoch-rewards-validator", - "destination": "/home/protocol/pos/epoch-rewards-validator" + "destination": "/legacy/protocol/pos/epoch-rewards-validator" }, { "source": "/protocol/pos/index", - "destination": "/home/protocol/pos" + "destination": "/legacy/protocol/pos" }, { "source": "/protocol/pos/locked-gold", - "destination": "/home/protocol/pos/locked-gold" + "destination": "/legacy/protocol/pos/locked-gold" }, { "source": "/protocol/pos/penalties", - "destination": "/home/protocol/pos/penalties" + "destination": "/legacy/protocol/pos/penalties" }, { "source": "/protocol/pos/validator-elections", - "destination": "/home/protocol/pos/validator-elections" + "destination": "/legacy/protocol/pos/validator-elections" }, { "source": "/protocol/pos/validator-groups", - "destination": "/home/protocol/pos/validator-groups" + "destination": "/legacy/protocol/pos/validator-groups" }, { "source": "/protocol/pos/validator-rewards", - "destination": "/home/protocol/pos/validator-rewards" + "destination": "/legacy/protocol/pos/epoch-rewards-validator" }, { "source": "/protocol/proof-of-stake", - "destination": "/home/protocol/pos" + "destination": "/legacy/protocol/pos" }, { "source": "/protocol/randomness", - "destination": "/home/protocol/randomness" + "destination": "/legacy/protocol/randomness" }, { "source": "/protocol/socialconnect", @@ -2312,7 +2308,7 @@ }, { "source": "/protocol/stability", - "destination": "/home/protocol/stability" + "destination": "/legacy/protocol/stability" }, { "source": "/protocol/transaction/erc20-transaction-fees", @@ -2332,15 +2328,15 @@ }, { "source": "/protocol/transaction/overview", - "destination": "/home/protocol/transaction/overview" + "destination": "/home/protocol/transactions/overview" }, { "source": "/protocol/transaction/transaction-types", - "destination": "/home/protocol/transaction/transaction-types" + "destination": "/home/protocol/transactions/transaction-types" }, { "source": "/protocol/transaction/tx-comment-encryption", - "destination": "/home/protocol/transaction/tx-comment-encryption" + "destination": "/home/protocol/transactions/tx-comment-encryption" }, { "source": "/token-addresses", @@ -2356,7 +2352,7 @@ }, { "source": "/v/master/developer-guide/overview", - "destination": "/tooling" + "destination": "/tooling/overview" }, { "source": "/v/master/developer-guide/overview/introduction", @@ -2364,7 +2360,7 @@ }, { "source": "/v/master/developer-guide/overview/introduction/contractkit", - "destination": "/tooling/contractkit" + "destination": "/tooling/libraries-sdks/contractkit" }, { "source": "/v/master/developer-guide/overview/introduction/forno", @@ -2484,23 +2480,23 @@ }, { "source": "/validator/run/alfajores", - "destination": "/legacy/validator/run" + "destination": "/legacy/validator/run/mainnet" }, { "source": "/validator/run/baklava", - "destination": "/legacy/validator/run" + "destination": "/legacy/validator/run/mainnet" }, { "source": "/validator/run/celo-devnet", - "destination": "/legacy/validator/run" + "destination": "/legacy/validator/run/mainnet" }, { "source": "/validator/run/celo-testnet", - "destination": "/legacy/validator/run" + "destination": "/legacy/validator/run/mainnet" }, { "source": "/validator/run/mainnet", - "destination": "/legacy/validator/run" + "destination": "/legacy/validator/run/mainnet" }, { "source": "/validator/security", @@ -2516,11 +2512,11 @@ }, { "source": "/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-carbon-offsetting-fund", - "destination": "/home/protocol/pos/epoch-rewards-carbon-offsetting-fund" + "destination": "/home/protocol/epoch-rewards/carbon-offsetting-fund" }, { "source": "/what-is-celo/about-celo-l1/protocol/pos/epoch-rewards-community-fund", - "destination": "/home/protocol/pos/epoch-rewards-community-fund" + "destination": "/home/protocol/epoch-rewards/community-fund" }, { "source": "/what-is-celo/about-celo-l1/validator/celo-signal", @@ -2530,17 +2526,13 @@ "source": "/what-is-celo/joining-celo/contributors/code-of-conduct", "destination": "https://celo.org/code-of-conduct" }, - { - "source": "/what-is-celo/using-celo/glossary", - "destination": "/glossary" - }, { "source": "/what-is-celo/using-celo/protocol/governance", "destination": "/home/protocol/governance/overview" }, { "source": "/what-is-celo/using-celo/protocol/penalties", - "destination": "/infra-partners/operators/penalties" + "destination": "/contribute-to-celo/community-rpc-nodes/penalties" }, { "source": "/why-celo", @@ -2848,11 +2840,11 @@ }, { "source": "/network/eclair", - "destination": "/tooling/testnets/" + "destination": "/tooling/testnets/celo-sepolia" }, { "source": "/network/eclair/:slug*", - "destination": "/tooling/testnets/" + "destination": "/tooling/testnets/celo-sepolia" }, { "source": "/network/mainnet", @@ -3106,10 +3098,6 @@ "source": "/learn/:slug*", "destination": "/home/:slug*" }, - { - "source": "/glossary", - "destination": "/glossary" - }, { "source": "/key-concepts", "destination": "/home/index" @@ -3128,7 +3116,7 @@ }, { "source": "/developer/bridges", - "destination": "/tooling/bridges" + "destination": "/tooling/bridges/bridges" }, { "source": "/developer/dynamic", @@ -3140,7 +3128,7 @@ }, { "source": "/developer/particle-network", - "destination": "/tooling/libraries-sdks/particle-network" + "destination": "/tooling/libraries-sdks/celo-sdks" }, { "source": "/developer/portal", From 431a02875c8aacaa0b604a66a2397579b52832c9 Mon Sep 17 00:00:00 2001 From: Paul Lange Date: Mon, 24 Aug 2026 11:33:28 +0200 Subject: [PATCH 4/5] ci: add report-only orphan-page check (scripts/check-orphans.sh) --- .github/workflows/docs-validation.yml | 5 ++++ scripts/check-orphans.sh | 38 +++++++++++++++++++++++++++ 2 files changed, 43 insertions(+) create mode 100755 scripts/check-orphans.sh diff --git a/.github/workflows/docs-validation.yml b/.github/workflows/docs-validation.yml index 8dfa11c689..19ca13b9cf 100644 --- a/.github/workflows/docs-validation.yml +++ b/.github/workflows/docs-validation.yml @@ -22,3 +22,8 @@ jobs: - name: Check for broken links run: npx mintlify broken-links + + - name: Check for orphan pages + # Report-only until the existing orphans are resolved (#2253 removes this). + continue-on-error: true + run: bash scripts/check-orphans.sh diff --git a/scripts/check-orphans.sh b/scripts/check-orphans.sh new file mode 100755 index 0000000000..f975033040 --- /dev/null +++ b/scripts/check-orphans.sh @@ -0,0 +1,38 @@ +#!/usr/bin/env bash +# Report .mdx pages that are not referenced anywhere in the docs.json +# navigation tree. Report-only in CI for now (issue #2252); issue #2253 +# makes orphans fail CI once the existing ones are resolved. +set -euo pipefail + +cd "$(dirname "$0")/.." + +nav_pages=$(mktemp) +mdx_files=$(mktemp) +trap 'rm -f "$nav_pages" "$mdx_files"' EXIT + +# Every page path referenced in navigation: walk all objects that carry a +# "pages" array and keep only its string entries (nested groups are objects +# and are reached separately via the recursive descent). +jq -r '.navigation | .. | objects | select(has("pages")) | .pages[] | strings' docs.json \ + | sort -u > "$nav_pages" + +# Every .mdx page in the repo, as a root-relative path without extension. +# snippets/ holds reusable fragments, not pages; submodules/ is excluded +# defensively (empty on CI checkouts, but its upstream repo carries docs). +find . -name '*.mdx' \ + -not -path './node_modules/*' \ + -not -path './snippets/*' \ + -not -path './submodules/*' \ + | sed 's|^\./||; s|\.mdx$||' | sort -u > "$mdx_files" + +orphans=$(comm -23 "$mdx_files" "$nav_pages") + +if [ -z "$orphans" ]; then + echo "No orphan pages found." + exit 0 +fi + +count=$(printf '%s\n' "$orphans" | wc -l | tr -d ' ') +echo "Found $count orphan page(s): .mdx files not referenced in docs.json navigation:" +printf '%s\n' "$orphans" +exit 1 From 99e84f6cf09688b6e99f651bb8400a6412026d4c Mon Sep 17 00:00:00 2001 From: Paul Lange Date: Mon, 24 Aug 2026 11:55:45 +0200 Subject: [PATCH 5/5] docs(repo): drop deleted _deprecated/ from AGENTS.md directory list --- AGENTS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index 1fd61e1ec5..8c53c56f39 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -8,7 +8,7 @@ Structural work in progress is tracked in the restructure epic, [#2266](https:// - A [Mintlify](https://mintlify.com) site. Content is MDX; navigation, redirects and theme live in `docs.json`. There is no build step beyond the Mintlify CLI. - `docs.json` is the single source of truth for what is reachable. **A file on disk is unreachable until it is listed under `navigation`.** -- Content directories today: `home/`, `build-on-celo/`, `tooling/`, `contribute-to-celo/`, `infra-partners/`, `specs/`, `legacy/`. `_deprecated/` is slated for deletion — never add to it. +- Content directories today: `home/`, `build-on-celo/`, `tooling/`, `contribute-to-celo/`, `infra-partners/`, `specs/`, `legacy/`. - `snippets/` holds reusable JSX/MDX (`/snippets/ColoredText.jsx`, `/snippets/YouTube.jsx`, `/snippets/AddNetworkButton.jsx`). Import with an absolute path after the frontmatter: `import {YouTube} from '/snippets/YouTube.jsx'`. - Static assets: `img/`, `images/`, `assets/`, `logo/`.