Ethereum EthHelper Address = [0x2784a755690453035f32Ac5e28c52524d127AfE2](https://etherscan.io/address/0x2784a755690453035f32Ac5e28c52524d127AfE2)
- Polygon EthHelper Address = [0xa489b8981ae5652C9Dd6515848cB8Dbecae5E1B0](https://polygonscan.com/address/0xa489b8981ae5652C9Dd6515848cB8Dbecae5E1B0)
- Celo Domain ID = 1667591279
- Polygon Domain ID = 1886350457
- Ethereum Domain ID = 6648936
- 0x4fc16De11deAc71E8b2Db539d82d93BE4b486892
- 0x3a5846882C0d5F8B0FA4bB04dc90C013104d125d
- Address = [0x4fc16De11deAc71E8b2Db539d82d93BE4b486892](https://etherscan.io/address/0x4fc16De11deAc71E8b2Db539d82d93BE4b486892)
- Address = [0x3a5846882C0d5F8B0FA4bB04dc90C013104d125d](https://polygonscan.com/address/0x3a5846882C0d5F8B0FA4bB04dc90C013104d125d)
- Address = [0x1548cf5cf7dBd93f4dA11f45fCce315573d21B60](https://explorer.celo.org/address/0x1548cf5cf7dBd93f4dA11f45fCce315573d21B60/transactions)
- Address = [0xB6bB41B1fb8c381b002C405B8abB5D1De0C0abFE](https://polygonscan.com/address/0xB6bB41B1fb8c381b002C405B8abB5D1De0C0abFE)
- Celo Domain ID = 1667591279
- Polygon Domain ID = 1886350457
- Ethereum Domain ID = 6648936
- Avalanche Domain ID = 1635148152
- 0x6a39909e805A3eaDd2b61fFf61147796ca6aBB47
-
-**After: 24 Zeros after 0x Prefix**
-0x0000000000000000000000006a39909e805A3eaDd2b61fFf61147796ca6aBB47
-
-:::
-
-* Select **write** > **sign the transaction** > then **send** it to the network.
-
-## Wait
-
-Wait for a moment for your transaction to finalize on the network.
diff --git a/docs/celo-codebase/protocol/bridging/migrating-to-optics-v2.md b/docs/celo-codebase/protocol/bridging/migrating-to-optics-v2.md
deleted file mode 100644
index 7c3677d58f..0000000000
--- a/docs/celo-codebase/protocol/bridging/migrating-to-optics-v2.md
+++ /dev/null
@@ -1,218 +0,0 @@
----
-title: Migrating to Optics v2
-description: How to migrate tokens from Optics v1 to v2.
-
----
-
-import YouTube from '@components/YouTube';
-import ImageWrapper from '@components/ImageWrapper'
-
-# Migrating to Optics v2
-
-This tutorial will guide you from Optics v1 to Optics v2.
-
----
-
-The v2 Optics Bridge is live! The launch of v2 was announced in [this post to the Celo Forum](https://forum.celo.org/t/optics-v2-is-live/2554).
-
-All v1 Optics Bridge users should migrate their v1 tokens to v2 tokens. Learn more [here](https://forum.celo.org/t/optics-recovery-mode/2452/34).
-
-You have three options to choose from:
-
-[Option 1](#option-1): **VERY EASY** Use the Mobius Migrator to swap Optics v1 for Optic v2 (1 for 1).
-
-* [1 Easily Migrate Optics Bridge Tokens to v2](#1---easily-migrate-optics-bridge-tokens-to-v2)
-
-[Option 2](#option-2): **MODERATE** You can swap your v1 tokens to a an alternative token on Celo using Ubeswap, Mobius, or Sushiswap, then swap those tokens for Optics v2 tokens. __Please note that as more tokens are bridged out of v1, it will become harder and possibly more expensive to swap your tokens.__
-
-* 2a — [Swap Affected Token for Unaffected Token](#2a---swap-affected-tokens-for-unaffected-tokens)
-* 2b — [Swap Unaffected Tokens for Optics v2 Tokens](#2b---swap-unaffected-tokens-for-optics-v2-tokens)
-
-[Option 3](#option-3): **HARDEST** You can bridge your affected v1 tokens to Ethereum or Polygon, and then back to Celo over the Optics v2 Bridge.
-
-* 3a — [Bridge Affected Tokens Out and Back](#3a---bridge-affected-tokens-out-and-back)
-* 3b — [Bridge Back to Celo](#3b---bridge-back-from-ethereum-to-celo-using-optics-v2)
-
-Depending on the available liquidity on AMMs, gas fees on the Ethereum network, and the total amount of tokens to be migrated, and the amount of effort you’re willing to spend you must choose whichever option makes the most sense.
-
----
-
-## Option 1
-
-| SUSHI: | 0x29dFce9c22003A4999930382Fd00f9Fd6133Acd1 |
| WETH: | 0x122013fd7dF1C6F636a5bb8f03108E876548b455 |
| WBTC: | 0xBAAB46E28388d2779e6E31Fd00cF0e5Ad95E327B |
| USDC: | 0xef4229c8c3250C675F21BCefa42f58EfbfF6002a |
| USDCPOS (Polygon): | 0x1bfc26cE035c368503fAE319Cc2596716428ca44 |
| USDT: | 0x88eeC49252c8cbc039DCdB394c0c2BA2f1637EA0 |
| DAI: | 0x90Ca507a5D4458a4C6C6249d186b6dCb02a5BCCd |
| CELO: | 0x471ece3750da237f93b8e339c536989b8978a438 |
| CUSD: | 0x765DE816845861e75A25fCA122bb6898B8B1282a |
| CEUR: | 0xD8763CBa276a3738E6DE85b4b3bF5FDed6D6cA73 |
| WMATIC: | 0x2E3487F967DF2Ebc2f236E16f8fCAeac7091324D |
| CUSD: | 0xd8f3208c045dd69d27938346275165998359d8ff |
| CELO: | 0xc95dc0eceec11ab8b2bfa1aff3c223c5dc006fad |
| SUSHI: | 0x6b3595068778dd592e39a122f4f5a5cf09c90fe2 |
| WETH: | 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 |
| WBTC: | 0x2260fac5e5542a773aa44fbcfedf7c193bc2c599 |
| UNI: | 0x1f9840a85d5af5bf1d1762f925bdaddc4201f984 |
| LINK: | 0x514910771af9ca656af840dff83e8264ecf986ca |
| USDC: | 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 |
| USDT: | 0xdac17f958d2ee523a2206206994597c13d831ec7 |
| DAI: | 0x6b175474e89094c44da98b954eedeac495271d0f |
| CEUR: | 0x977453366b8d205f5c9266b6ba271e850a814a50 |
| SUSHI: | 0xa84b7d339570eb053939810f56ab6eef2e0b38cd |
| WETH: | 0xac24381947d4f44c2da58881547c0c38196beb07 |
| WBTC: | 0x15d25a3c47037c133210ab90adae4d51365a1108 |
| USDC: | 0x22d9c9fc91ebd595af762ed4c9d5cc1d92cabf59 |
| USDCPOS (Polygon): | 0x2791bca1f2de4661ed88a30c99a7a9449aa84174 |
| USDT: | 0x91ff78ae858498e6f6e884f78b6e5be892c706af |
| DAI: | 0x795a8ec05f0c4f0eea7388378b1b890f851c5001 |
| CELO: | 0x4764ea6d06ce4e503d0bb323913c1e96dcd1a943 |
| CUSD: | 0x151517af77b06d9593f3ed41abecdd349316e006 |
| CEUR: | 0x2f0173dfe97a7dc670d5a10b35c4263cfecfa853 |
| WMATIC: | 0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270 |
-
-The sending (or “home”) chain produces a series of documents ("messages") that needs notarization. A notary (called the “updater”) is contracted to sign it. The notary can produce a fraudulent copy, but they will be punished by having their bond and license publicly revoked. When this happens, everyone relying on the notary learns that the notary is malicious. All the notary's customers can immediately block the notary and prevent any malicious access to their accounts.
-
-## How does Optics work?
-
-Optics is patterned after optimistic systems. It sees an attestation of some data, and accepts it as valid after a timer elapses. While the timer is running, honest participants have a chance to respond to the attestation and/or submit fraud proofs.
-
-Unlike most optimistic systems, Optics spans multiple chains. The sending chain is the source of truth, and contains the “Home” contract where messages are enqueued. Messages are committed to in a merkle tree (the “message tree”). The root of this tree is notarized by the updater and relayed to the receiving chain in an “update”. Updates are signed by the updater. They commit to the previous root and a new root.
-
-Any chain can maintain a “Replica” contract, which holds knowledge of the updater and the current root. Signed updates are held by the Replica, and accepted after a timeout. The Replica effectively replays a series of updates to reach the same root as the Home chain. Because the root commits to the message tree, once the root has been transmitted this way, the message can be proven and processed.
-
-This leaves open the possibility that the Updater signs a fraudulent update. Unlike an optimistic rollup, Optics permits fraud. This is the single most important change to the security model. Importantly, fraud can always be proven to the Home contract on the sending chain. Because of this, the updater must submit a bonded stake on the sending chain. Fraud can always be proven on the sending chain, and the bond can be slashed as punishment.
-
-Unfortunately, certain types of fraud can't be objectively proven on the receiving chain; Replicas can't know which messages the home chain intended to send and therefore can't check message tree validity in all cases. However, if a message is falsified by an Updater and submitted to the Replica, that update is public. This means that any honest actor can prove this fraud on the original Home contract and cause slashing. There is no way to hide fraud.
-
-In addition, because the Replica waits to process messages, Optics guarantees that honest dapps can always prevent processing of dishonest messages. Fraud is always public knowledge before the fraudulent message is processed. In this sense, Optics (like atomic swaps and other locally verified systems) includes a requirement for honest users to stay online. We have built a robust system for delegating this responsibility.
-
-All off-chain observers can be immediately convinced of fraud (as they can check the home chain). This means that the validity of a message sent by Optics is not 100% guaranteed.
-
-Instead, Optics guarantees the following:
-
-- Fraud is costly
-- All users can learn about fraud
-- All users can block a fraudulent message before they are accepted
-
- In other words, rather than using a globally verifiable fraud-proof, Optics relies on local verification by participants. This tradeoff allows Optics to save 90% on gas fees compared to pessimistic relays, while still maintaining a high degree of security.
-
-## Optics Architecture
-
-Optics contains several on-chain and off-chain components. For convenience, we’ll be referring to the Home and Replica as contracts, when in fact they are several contracts working together.
-
-
-
-
-
-## On-chain (Contracts)
-
-### Home
-
-The home contract is responsible for managing production of the message tree and holding custody of the updater bond.
-
-__It performs the following functions:__
-
-- Expose a "send message" API to other contracts on the home chain
-- Enforce the message format
-- Commit messages to the message tree
-- Maintain a queue of tree roots
-- Slash the updater's bond
- - Double-update proofs
- - Improper update proofs
-
-### Replica
-
-The replica contract is responsible for managing optimistic replication and dispatching messages to end recipients.
-
-__It performs the following functions:__
-
-- Maintain a queue of pending updates
-- Finalize updates as their timeouts elapse
-- Accept double-update proofs
-- Validate message inclusion proofs
-- Enforce the message format
-- Ensure messages are processed in order
-- Dispatch messages to their destination
-- Off-chain (Agents)
-
-### Updater
-
-The updater is responsible for signing attestations of new roots.
-
-__It is an off-chain actor that does the following:__
-
-- Observe the home chain contract
-- Sign attestations to new roots
-- Publish the signed attestation to the home chain
-
-### Watcher
-
-The watcher observes the Updater's interactions with the Home contract (by watching the Home contract) and reacts to malicious or faulty attestations. It also observes any number of replicas to ensure the Updater does not bypass the Home and go straight to a replica.
-
-__It is an off-chain actor that does the following:__
-
-- Observe the home
-- Observe 1 or more replicas
-- Maintain a DB of seen updates
-- Submit double-update proofs
-- Submit invalid update proofs
-- If configured, issue an emergency halt transaction
-
-### Relayer
-
-The relayer forwards updates from the home to one or more replicas.
-
-__It is an off-chain actor that does the following:__
-
-- Observe the home
-- Observe 1 or more replicas
-- Polls home for new signed updates (since replica's current root) and submits them to replica
-- Polls replica for confirmable updates (that have passed their optimistic time window) and confirms if available (updating replica's current root)
-
-### Processor
-
-The processor proves the validity of pending messages and sends them to end recipients.
-
-__It is an off-chain actor that does the following:__
-
-- Observe the home
-- Maintain local merkle tree with all leaves
-- Observe 1 or more replicas
-- Maintain list of messages corresponding to each leaf
-- Generate and submit merkle proofs for pending (unproven) messages
-- Dispatch proven messages to end recipients
-
-## How Optics passes messages between chains
-
-
-
-
-
-Optics creates an authenticated data structure on a home chain, and relays updates to that data structure on any number of replicas. As a result, the home chain and all replicas will agree on the state of the data structure. By embedding data ("messages") in this data structure we can propagate it between chains with a high degree of confidence.
-
-The home chain enforces rules on the creation of this data structure. In the current design, this data structure is a sparse merkle tree based on the design used in the eth2 deposit contract. This tree commits to the vector of all previous messages. The home chain enforces an addressing and message scheme for messages and calculates the tree root. This root will be propagated to the replicas. The home chain maintains a queue of roots (one for each message).
-
-The home chain elects an "updater" that must attest to the state of the message tree. The updater places a bond on the home chain and is required to periodically sign attestations (updates or U). Each attestation contains the root from the previous attestation (U_prev), and a new root (U_new).
-
-The home chain slashes when it sees two conflicting updates (U_i and U_i' where U_i_prev == U_i'_prev && U_i_new != U_i'_new) or a single update where U_new is not an element of the queue. The new root MUST be a member of the queue. E.g a list of updates U_1...U_i should follow the form [(A, B), (B, C), (C, D)...].
-
-Semantically, updates represent a batch commitment to the messages between the two roots. Updates contain one or more messages that ought to be propagated to the replica chain. Updates may occur at any frequency, as often as once per message. Because updates are chain-independent, any home chain update may be presented to any replica, and any replica update may be presented to the home chain. In other words, data availability of signed updates is guaranteed by each chain.
-
-Before accepting an update, a replica places it into a queue of pending updates. Each update must wait for some time parameter before being accepted. While a replica can't know that an update is certainly valid, the waiting system guarantees that fraud is publicly visible on the home chain before being accepted by the replica. In other words, the security guarantee of the system is that all frauds may be published by any participant, all published frauds may be slashed, and all participants have a window to react to any fraud. Therefore updates that are not blacklisted by participants are sufficiently trustworthy for the replica to accept.
-
-## Optical Channels for Cross-Chain Communication
-
-Optics sends messages from one chain to another in the form of raw bytes. A cross-chain application that wishes to use Optics will need to define the rules for sending and receiving messages for its use case.
-
-Each cross-chain application must implement its own messaging protocol. By convention, we call the contracts that implement this protocol the application's Router contracts. Their function is broadly similar to routers in local networks. They ensure that incoming and outgoing messages are in the protocol-defined format, and facilitate handling and dispatch.
-
-__These Router contracts must:__
-
-- maintain a permissioned set of the contract(s) on remote chains from which it will accept messages via Optics — this could be a single owner of the application on one chain; it could be a registry of other applications implementing the same rules on various chains
-- encode messages in a standardized format, so they can be decoded by the Router contract on the destination chain
-- handle messages from remote Router contracts
-- dispatch messages to remote Router contracts
-
- By implementing these pieces of functionality within a Router contract and deploying it across multiple chains, we create a working cross-chain application using a common language and set of rules. Applications of this kind may use Optics as the cross-chain courier for sending and receiving messages to each other.
-
-## Benefits and Trade-offs of the Optics Architecture
-
-__Benefits__ | __Challenges__
--- | --
-Broadcast channel | 1-of-N fraud-proof trust model
-Cheap | Liveness failure if updater goes down
-One-solution fits all | Updater could voluntarily forfeit bond to try to pass forged messages
-Simple |
-
-The benefit of Optics is that the broadcast channel allows for a single-producer, multi-consumer model. This ensures that 1 accumulator can communicate with any number of receiving chains. It’s also much cheaper than other options, allowing updates and proofs to cost <100k gas and be checked by only 1 signature. With Optics, one-solution fits all meaning that constraints on receiving chains are minimal (1 hash function + 1 signature check). There is no implementation or security difference between Proof of Stake and Proof of Work chains. There is also many fewer LoC than a Relay, much lower design maintenance overhead, and much less expertise required to maintain and operate.
-
-We’ve been careful to address all concerns with the Optics system and have designed solutions that allow for optimal speed, cost, and security of the network. For example, we rely on fraud publication rather than fraud proofs to improve the speed and cost of sending messages. In this security model, any potential fraud is disincentivized and costly, and all participants will always learn of any potential fraud with plenty of time to mitigate harm.
diff --git a/docs/celo-codebase/protocol/oracles/oracles-on-celo.md b/docs/celo-codebase/protocol/oracles/oracles-on-celo.md
deleted file mode 100644
index 892752efb9..0000000000
--- a/docs/celo-codebase/protocol/oracles/oracles-on-celo.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Oracles on Celo
-description: A list of oracles available on the Celo network.
----
-
-# Oracles on Celo
-
-This page lists Oracles running on the Celo network.
-
-Here lists all on-chain Oracles:
-
-* [Celo Reserve Oracles](/celo-codebase/protocol/stability/oracles)
-* [RedStone Oracles](redstone-protocol-how-to.md)
-* [Band Protocol](band-protocol-how-to.md)
\ No newline at end of file
diff --git a/docs/celo-codebase/protocol/plumo.md b/docs/celo-codebase/protocol/plumo.md
deleted file mode 100644
index 9ecc45b062..0000000000
--- a/docs/celo-codebase/protocol/plumo.md
+++ /dev/null
@@ -1,220 +0,0 @@
----
-title: Plumo Ultralight Sync
-description: Introduction to Plumo (Ultralight Sync), it's core concepts, architecture, process, and implementation.
----
-
-# Plumo Ultralight Sync
-
-Introduction to Plumo Ultralight Sync, it's core concepts, architecture, process, and implementation.
-
-___
-
-## What is Plumo Ultralight Sync?
-
-Plumo is a zk-SNARK based system that allows mobile and resource constrained nodes on the Celo network to sync to the Celo blockchain faster and with less data. It accomplishes this by using zero-knowledge proofs, which allow the quick verification of the chain syncing computation without having to run it locally.
-
-## Background
-
-Celo is a mobile-first blockchain platform with a mission to enable the conditions for prosperity across the world. This means that may of Celo and the Valora wallet's first users will be in emerging markets. In these countries, while mobile phone penetration has significantly increased, data plans and device hardware still lags. This means that for average users, data is a scarce commodity and devices are underpowered in compute relative to the latest and greatest iPhone or Android devices.
-
-If these users are to trustlessly sync and interact with a blockchain network, they'll need to run a [light client](https://www.parity.io/what-is-a-light-client/) on devices. However, traditional light clients in proof of work (PoW) blockchains need to download every block header, which grows linearly with new blocks. Over time, this becomes untenable, and even light clients [take minutes to sync](https://ethereum.stackexchange.com/questions/82568/whats-the-status-of-ethereum-light-client).
-
-### Proof of Stake Light Clients
-
-Celo uses a proof of stake (PoS) consensus sytem, enabling it to offer a better light client sync experience, right off the bat:
-
-1. First, Celo light clients only need to download epoch block headers, which contain information about the current validator set. [The validator set](/celo-codebase/protocol/consensus/validator-set-differences.md) in Celo changes once every epoch, roughly about once per day. This means instead of downloading a block header for every block on the Celo network, they can just download one a day.
-
-2. Second, Celo uses BLS signatures to aggregate validator signatures. Similar to Tendermint consensus, Celo's IBFT consensus mechanism requires a quorum of 2/3 or more validators to sign each block to commit it to the blockchain. Instead of having each of these signatures be separately stored on-chain, Celo uses BLS signatures which can combine them into one signature per block.
-
-These two innovations reduce the time and data required to sync significantly, but over time, sync time continues to increase. One option is to [checkpoint](https://decentralizedthoughts.github.io/2019-09-13-dont-trust-checkpoint/) the chain ever so frequently so that clients do not need to sync from the genesis block. This certainly alleviates the challenge, but checkpointing requires getting consensus and agreement from the community, which can take time. What if there were a way to "checkpoint" cryptographically?
-
-### Enter Plumo
-
-This is where Plumo comes in. Plumo zk-SNARKs allow light clients to quickly verify transitions from epoch X to epoch X + Y, where Y is hundreds of epochs. This means that instead of verifying each epoch, light clients can "hop" from SNARK to SNARK until they reach the latest proof. From there, they can download the remaining epoch block headers to sync to the head of the chain.
-
-The Plumo proofs are generated by a prover that can be run by multiple nodes across the Celo network. Proofs are then requested by light clients on the modified light client protocol. Light clients are able to verify proofs using the verification key that is included with the binary.
-
-Using Plumo, light clients can drastically reduce the amount of data and time required to trustlessly sync with the Celo blockchain. But one more step is required for Plumo to be live on the Celo network -- the Plumo MPC setup.
-
-## Plumo MPC Setup
-
-In order to generate the prover and verifier keys for the Plumo SNARK circuit, it is necessary to run a multi-party computation (MPC).
-
-An MPC is a cryptographic mechanism for different parties to jointly perform a computation. SNARK circuits require a “trusted setup” where a shared secret is used to generate public parameters that can be used to prove and verify SNARKs. If one person ran this setup, then they could potentially prove incorrect things by exploiting a backdoor in the circuit. However, with an MPC, this setup process is split amongst tens or hundreds of contributors, and if even one of the participants is honest (keeps their inputs private), then the system will be secure.
-
-In the case of the Plumo Ceremony, this collective computation will be a series of joint actions done by a group of participants from within the Celo community and beyond.
-
-## How to Contribute
-
-The Plumo MPC setup is broken up into two phases:
-
-* Phase 1 - Powers of Tau
- - The output of this phase can be used for either Groth16 circuits up to the size of the phase, or universal proving systems such as PLONK and Marlin.
-* Phase 2 - Plumo circuit
- - In this phase, the participants contribute to the Plumo circuit keys, which would be used by provers to create proofs and verifiers to verify them.
-
-Phase 1 will take place starting early December 2020, and continue until January 2021. It will consist of multiple rounds of 6–10 contributors each running the Plumo setup for approximately 36 hours. While much of the activity is passive and involves simply running the computation continuously, contributors should not expect to use their machines for other intensive activies through the duration of the setup.
-
-Phase 2 will commence roughly a month after Phase 1.
-
-Contributors will also receieve a gift for the time and efforts, and be recognized for their contributions to the Celo network.
-
-### Pre-requisites
-
-You can run the contributor software locally or on cloud VMs, but desktop machines are preferable. The minimum machine requirements are detailed below:
-
-#### Machine requirements:
-
-- CPU model newer than 2016
-- Minimum processor requirements:
- - 2.6GHz, 6 cores, 12 threads, OR
- - 2.3GHz, 8 cores, 16 threads, OR
- - 3.6GHz, 4 cores, 4 threads
-- Operating system: Linux, macOS, Windows
-- Recommended internet connection speed: 10Mbit upload
-
-With these kind of machines, participiation in the setup should take around 30 hours, potentially a bit more or much less, depending on your specific hardware and internet connection.
-
-## Running the Setup
-
-### Phase 1
-
-The instructions below are for the first phase of the Plumo setup, Powers of Tau.
-
-#### Generate your address
-
-The first step to participating is generating your Celo address in a secure location.
-
-* Obtain the `generate` binary:
- * Option one - compile the `generate` binary:
- * Install Rust 1.49 using `rustup install 1.49.0`. If you don't have `rustup` installed, follow the instructions in https://rustup.rs/. If you're using an Apple M1 machine, install the beta version of Rust using `rustup install beta`.
- * `git clone https://github.com/celo-org/snark-setup-operator`
- * `cd snark-setup-operator`
- * `git checkout ac3d5603256fc250500e00bae21ba646dd316d6f`
- * `cargo build --release --bin generate`
- * Now you can use `./target/release/generate`
- * Option two - if you prefer using a precompiled binary, download the `generate` binary corresponding to your OS from [here](https://github.com/celo-org/snark-setup-operator/releases/tag/v1.1.3).
-* Use `b2sum` to check the hash of the binary against the hash in the download page by running `b2sum FILE`, where `FILE` is the `contribute` binary name for your OS. If you don't have `b2sum` installed, you can download it from `https://github.com/dchest/b2sum`, for example.
-* Run it in a command line - navigate in the command line to the relevant folder - and follow the instructions.
- * When asked to `Enter some entropy for your Plumo seed:`, you can use any source of entropy.
- * Make sure to save your passphrase - you will need it later.
- * If you are using a USB thumbdrive, you can use the flag `--keys-file KEYS_FILE`, passing in the respective file path to save the key on the drive itself.
-* Send the address generated to plumo@celo.org.
-* Keep the resulting `plumo.keys` file. Ideally, it will be stored in a location that's easy to destroy afterwards, such as a USB thumbdrive.
-
-#### Run the Contributor software
-
-Next you'll obtain the `contribute` binary and begin contributing to the Plumo setup.
-
-cLabs is running the coordinator server, which has a list of approved participant addresses. Additionally, cLabs is running a few verifiers that verify contributions on-demand, allowing the setup to make progress.
-
-* After receiving confirmation from cLabs, obtain the `contribute` binary:
- * Option one - compile the `contribute` binary:
- * Install Rust 1.49 using `rustup install 1.49.0`. If you don't have `rustup` installed, follow the instructions in https://rustup.rs/. If you're using an Apple M1 machine, install the beta version of Rust using `rustup install beta`.
- * `git clone https://github.com/celo-org/snark-setup-operator`
- * `cd snark-setup-operator`
- * `git checkout ac3d5603256fc250500e00bae21ba646dd316d6f`
- * `cargo build --release --bin contribute`
- * Now you can use `./target/release/contribute`
- * Option two - if you prefer using a precompiled binary, download the `contribute` binary corresponding to your OS from [here](https://github.com/celo-org/snark-setup-operator/releases/tag/v1.1.3).
-* Use `b2sum` to check the hash of the binary against the hash in the download page by running `b2sum FILE`, where `FILE` is the `contribute` binary name for your OS. If you don't have `b2sum` installed, you can download it from `https://github.com/dchest/b2sum`, for example.
-* Run it as follows, assuming your keys reside in KEYS_FILE:
- * Windows users: `./contribute-windows.exe --keys-file KEYS_FILE`
- * macOS users: `./contribute-macos --keys-file KEYS_FILE`
- * Linux users: `./contribute-linux --keys-file KEYS_FILE`
-
- For example, assuming you're using Linux and your keys reside in `/mnt/plumo/plumo.keys`, you'd run: `./contribute-linux --keys-file /mnt/plumo/plumo.keys`.
-* You will be asked for your passphrase - enter the same one from earlier.
- * Follow the same process from earlier when prompted for additional entropy.
-* Wait until you see 0/256 on the progress bar. This means that your contribution has started, and you are succesfully running the contributor binary.
-
-Once this is running, you can leave the machine running -- no direct action is needed. This will run for about ~36 hours, after which the software will terminate running and you will have finished contributing to the Plumo setup!
-
-### Phase 2
-
-The instructions below are for the second phase of the Plumo setup, the Plumo circuit.
-
-#### Generate your address
-
-The first step to participating is generating your Celo address in a secure location.
-
-* Obtain the `generate` binary:
- * Option one - compile the `generate` binary:
- * Install Rust 1.52 using `rustup install 1.52.1`. If you don't have `rustup` installed, follow the instructions in https://rustup.rs/. If you're using an Apple M1 machine, install the beta version of Rust using `rustup install beta`.
- * `git clone https://github.com/celo-org/snark-setup-operator`
- * `cd snark-setup-operator`
- * `git checkout 33717c3b0869c605e6c3627446e916f268712e00`
- * `cargo build --release --bin generate`
- * Now you can use `./target/release/generate`
- * Option two - if you prefer using a precompiled binary, download the `generate` binary corresponding to your OS from [here](https://github.com/celo-org/snark-setup-operator/releases/tag/v1.2.2).
-* Use `b2sum` to check the hash of the binary against the hash in the download page by running `b2sum FILE`, where `FILE` is the `contribute` binary name for your OS. If you don't have `b2sum` installed, you can download it from `https://github.com/dchest/b2sum`, for example.
-* Run it in a command line - navigate in the command line to the relevant folder - and follow the instructions.
- * When asked to `Enter some entropy for your Plumo seed:`, you can use any source of entropy.
- * Make sure to save your passphrase - you will need it later.
- * If you are using a USB thumbdrive, you can use the flag `--keys-file KEYS_FILE`, passing in the respective file path to save the key on the drive itself.
-* Send the address generated to plumo@celo.org.
-* Keep the resulting `plumo.keys` file. Ideally, it will be stored in a location that's easy to destroy afterwards, such as a USB thumbdrive.
-
-#### Run the Contributor software
-
-Next you'll obtain the `contribute` binary and begin contributing to the Plumo setup.
-
-cLabs is running the coordinator server, which has a list of approved participant addresses. Additionally, cLabs is running a few verifiers that verify contributions on-demand, allowing the setup to make progress.
-
-* After receiving confirmation from cLabs, obtain the `contribute` binary:
- * Option one - compile the `contribute` binary:
- * Install Rust 1.52 using `rustup install 1.52.1`. If you don't have `rustup` installed, follow the instructions in https://rustup.rs/. If you're using an Apple M1 machine, install the beta version of Rust using `rustup install beta`.
- * `git clone https://github.com/celo-org/snark-setup-operator`
- * `cd snark-setup-operator`
- * `git checkout 33717c3b0869c605e6c3627446e916f268712e00`
- * `cargo build --release --bin contribute`
- * Now you can use `./target/release/contribute`
- * Option two - if you prefer using a precompiled binary, download the `contribute` binary corresponding to your OS from [here](https://github.com/celo-org/snark-setup-operator/releases/tag/v1.2.2).
-* Use `b2sum` to check the hash of the binary against the hash in the download page by running `b2sum FILE`, where `FILE` is the `contribute` binary name for your OS. If you don't have `b2sum` installed, you can download it from `https://github.com/dchest/b2sum`, for example.
-* Run it as follows, assuming your keys reside in KEYS_FILE:
- * Windows users: `./contribute-windows.exe --keys-file KEYS_FILE`
- * macOS users: `./contribute-macos --keys-file KEYS_FILE`
- * Linux users: `./contribute-linux --keys-file KEYS_FILE`
-
- For example, assuming you're using Linux and your keys reside in `/mnt/plumo/plumo.keys`, you'd run: `./contribute-linux --keys-file /mnt/plumo/plumo.keys`.
-* You will be asked for your passphrase - enter the same one from earlier.
- * Follow the same process from earlier when prompted for additional entropy.
-* Wait until you see 0/256 on the progress bar. This means that your contribution has started, and you are succesfully running the contributor binary.
-
-Once this is running, you can leave the machine running -- no direct action is needed. This will run for about ~36 hours, after which the software will terminate running and you will have finished contributing to the Plumo setup!
-
-### Publish your attestation
-
-The `contribute` binary produces a `plumo.attestation` file that contains a signature with your address. After your participation finishes (and not before!), please post it (here)[https://github.com/celo-org/plumo-ceremony-attestations] by creating a new issue! If you use precompiled binaries, be sure to mention you've verified the binary hashes posted on the releases page match the downloaded files.
-
-If you don't have access to the `plumo.attestation` anymore, that's still OK, you can fill in the other details in the issue.
-
-### Troubleshooting
-
-This section contains some common issues contributors may run into while running the setup software. If you have any questions, please reach out on the #plumo channel in the [Celo Discord server](https://discord.gg/6yWMkgM). It is recommended that you have another device to be able to reach out in case of persistent issues.
-
-**Permissions:**
-- You may need to change the permissions on both the `generate` and `contribute` files to be able to run them. For example, on macOS, you can run `chmod u+x generate-macos contribute-macos`.
-- On Windows, you might be presented with a warning that this program is from an unsigned developer. Click "run anyway" to continue.
-- On macOS, you might be shown a "permission denied" error. This is because it's a downloaded file and is by default in quarantine. You can remove it from quarantine by running `xattr -d com.apple.quarantine contribute-macos`. See here for more details: https://superuser.com/questions/526920/how-to-remove-quarantine-from-file-permissions-in-os-x.
-
-**Hardware:**
-- Disable sleep - if your machine is automatically set to sleep or turn hard disks off, it's best to switch these options off.
-- Battery - it's best to connect the machine to an outlet, as the setup is computationally intensive and would drain a battery fast.
-- Frozen machine - if your computer freezes, don't worry -- the Plumo setup software is using all the threads on the CPU, and it should resolve itself.
-
-If either of these happen, don't worry - stop and restart the contribution program and re-enter the passphrase to continue.
-
-**Network:**
-- If you have issues uploading your contributions, it could be that you have some other processes that are consuming your bandwidth. Make sure to quit any processes such as:
- - A Nest or home camera uploading feeds
- - Torrenting / seeding any files
- - Backup services
-
-## Additional Resources
-- [Plumo Paper](https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-plumo_celolightclient.pdf)
-- [Plumo Celo Improvement Proposal](https://github.com/celo-org/celo-proposals/pull/41)
-- [Zero Knowledge Summit Presentation on Plumo](https://www.youtube.com/watch?v=2e0XpWgFKLg)
-- [Transcript of Plumo presentation at Stanford Blockchain Conference](https://diyhpl.us/wiki/transcripts/stanford-blockchain-conference/2020/celo-ultralight-client/)
-- [Zero Knowledge Summit Presentation on the Plumo setup system, Espero](https://www.youtube.com/watch?v=LKbDNc-LrA4)
diff --git a/docs/celo-codebase/protocol/proof-of-stake/carbon-offsetting-fund.md b/docs/celo-codebase/protocol/proof-of-stake/carbon-offsetting-fund.md
deleted file mode 100644
index a7e1d68492..0000000000
--- a/docs/celo-codebase/protocol/proof-of-stake/carbon-offsetting-fund.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Carbon Offsetting Fund
-slug: /celo-codebase/protocol/proof-of-stake/epoch-rewards/carbon-offsetting-fund
-description: Introduction to the Carbon Offsetting fund, its purpose, and governance process.
----
-# Carbon Offsetting Fund
-
-Introduction to the Carbon Offsetting fund, its purpose, and governance process.
-
-___
-
-## What is the Carbon Offsetting Fund?
-
-The Carbon Offsetting Fund provides for making the infrastructure of the Celo platform carbon-negative, by making a transfer every epoch to an organization that commits to using those assets off-chain for carbon offsetting projects.
-
-## Governance
-
-Through the [on-chain governance process](/celo-codebase/protocol/governance.md), CELO holders can set the fraction of the total desired epoch rewards, initially planned to be 0.1%, that is received by the carbon offsetting fund, and the address of a carbon offsetting partner to which to direct these transfers. The on-target amount is adjusted by the epoch [rewards multiplier](/celo-codebase/protocol/proof-of-stake/epoch-rewards.md), as with all epoch rewards.
diff --git a/docs/celo-codebase/protocol/proof-of-stake/community-fund.md b/docs/celo-codebase/protocol/proof-of-stake/community-fund.md
deleted file mode 100644
index 3467363326..0000000000
--- a/docs/celo-codebase/protocol/proof-of-stake/community-fund.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Celo Community Fund
-slug: /celo-codebase/protocol/proof-of-stake/epoch-rewards/community-fund
-description: Introduction to the community fund, its assets, and its relationship to the on-chain reserve.
----
-# Community Fund
-
-Introduction to the community fund, its assets, and its relationship to the on-chain reserve.
-
-___
-
-## What is the Community Fund?
-
-The Community Fund provides for general upkeep of the Celo platform. CELO holders decide how to allocate these funds through governance proposals. Funds might be used to pay bounties for bugs or vulnerabilities, security audits, or grants for protocol development.
-
-## Community Fund Assets
-
-The Community Fund receives assets from three sources:
-
-- The Community Fund obtains a desired epoch reward defined as a fraction of the total desired epoch rewards \(governable, initially planned to be $$25\%$$\). This amount is subject to adjustment up or down in the event of under- or over-spending against the epoch rewards target schedule. The Community Fund epoch rewards may be redirected to [bolster the Reserve](#bolstering-the-reserve).
-
-- The Community Fund is the default destination for slashed assets.
-
-- The Community Fund also receives the 'base' portion of [transaction fees](celo-codebase/protocol/transactions/gas-pricing.md).
-
-## Bolstering the Reserve
-
-The rewards to the Community Fund are automatically redirected to the on-chain reserve during times in which the reserve ratio (the ratio of aggregate reserve value of on-chain CELO and the off-chain reserve of crypto-assets over stablecoin market capitalization) is below a cutoff value. This cutoff reduces from two to one over the first of 25 years in a linear fashion and remains at one afterwards.
diff --git a/docs/celo-codebase/protocol/stability/index.md b/docs/celo-codebase/protocol/stability/index.md
deleted file mode 100644
index e265b27e79..0000000000
--- a/docs/celo-codebase/protocol/stability/index.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Celo Stability Mechanism Overview
-slug: /celo-codebase/protocol/stability
-description: Overview of the Celo protocol's Stability Mechanisms.
----
-import YouTube from '@components/YouTube';
-import PageRef from '@components/PageRef';
-
-# Stability Mechanism
-
-Overview of the Celo protocol's Stability Mechanisms.
-
-___
-
-## Stability of Celo's Stablecoin Protocol
-
-