final

Author: gfletcher-cll

src/config/sidebar/ccip-dynamic.ts

@@ -179,14 +179,8 @@ export const CCIP_SIDEBAR_CONTENT: SectionEntry[] = [
       },
       {
         title: "Offchain Architecture",
-        url: "ccip/concepts/architecture/offchain",
+        url: "ccip/concepts/architecture/offchain/overview",
         // Universal
-        children: [
-          {
-            title: "Overview",
-            url: "ccip/concepts/architecture/offchain/overview",
-          },
-        ],
       },
       {
         title: "Cross-Chain Token (CCT)",

src/content/ccip/concepts/architecture/offchain/index.mdx

@@ -17,7 +17,7 @@ import { ClickToZoom } from "@components"
 CCIP's offchain architecture includes the following:
 
 - **Decentralized Oracle Networks (DONs)**: Running offchain consensus using the Offchain Reporting Protocol (OCR).
-- **Interaction Components**: Managing communication between the CCIP DONs and the RMN.
+- **Interaction Components**: Managing communication between the CCIP DONs.
 
 ## Components
 
@@ -35,30 +35,6 @@ With the CCIP v1.6 architecture, there is a single DON called the Role DON that
 
 **Note**: For simplicity, we sometimes refer to the nodes running the Commit OCR Plugin as the Committing DON and those running the Executing OCR Plugin as the Executing DON. However, these are not separate oracle networks; they are subsets of the same Role DON, distinguished solely by their assigned roles.
 
-## Role DON: Diagram and Explanation
-
-<ClickToZoom
-  src="/images/ccip/ccip-hl-v1.7.png"
-  alt="CCIP Offchain Architecture"
-  style="display: block; margin: 2rem auto; max-height: 60vh; width: auto;"
-/>
-
-Let's take an example from the diagram above to understand the key components. The diagram shows a Commit OCR instance configured for a destination chain (Chain C). Key details include:
-
-- **Commit Role DON**
-  - Represents all participating nodes.
-  - Within the Role DON, a specific group of nodes—sometimes called a "sub-committee"—may be assigned chain-specific roles.
-
-- **Chain-Specific Roles** (as illustrated)
-  - **Green Rectangle**: Nodes observe Chain A (i.e., they read from Chain A).
-  - **Orange Rectangle**: Nodes observe Chain B.
-  - **Blue Rectangle**: Nodes write commit reports to Chain C.
-  - **Overlap**: Note that groups may overlap. For example, the four nodes in the bottom-left corner of the Role DON might not connect to Chain A or Chain C, demonstrating flexibility in node participation.
-  - **Interaction with RMN**: The Commit OCR interacts with RMN nodes to receive RMN blessings. These blessings act as independent attestations of the validity of source chain observations and are used to form a consolidated set of merkle roots.
-- **Configuration and Role Validation**:
-  - Node roles are configured on the Home Chain (i.e., Ethereum) through specific contracts.
-  - The node software reads from the **CCIP Home** and **RMN Home** contracts to verify that each node is authorized for its role—whether for making observations or providing RMN blessings.
-
 ## High Level Flow
 
 Below are the high-level steps for the Commit OCR process and the Executing OCR process.

src/content/ccip/concepts/architecture/offchain/overview.mdx

@@ -46,7 +46,7 @@ Token developers retain complete ownership of their token contracts, token pools
 
 #### Defense-in-Depth Security
 
-The CCT standard leverages Chainlink's industry-standard oracle networks, which secure over $16 trillion in Total Value Enabled (TVE). This strong foundation is further enhanced by additional layers of protection, such as the Risk Management Network and configurable transfer rate limits, providing comprehensive security for cross-chain operations.
+The CCT standard leverages Chainlink's industry-standard oracle networks, which secure over $16 trillion in Total Value Enabled (TVE). This strong foundation is further enhanced by additional layers of protection, such as configurable transfer rate limits, providing comprehensive security for cross-chain operations.
 
 #### Programmable Token Transfers
 

src/content/ccip/concepts/architecture/offchain/risk-management-network.mdx

@@ -38,8 +38,10 @@ Given the [inherent risks of cross-chain interoperability](/resources/bridge-ris
 
 CCIP provides several key security benefits:
 
-- Multiple independent nodes run by independent key holders.
-- Two decentralized networks all executing and verifying every cross-chain transaction.
+- **Proven Decentralized Architecture**: CCIP uses multiple decentralized oracle networks (DONs) to validate each cross-chain transaction, leveraging the same time-tested infrastructure powering Chainlink Data Feeds which have been used by hundreds of DeFi applications to enable $26T in transaction value over a period of nearly 6 years of in-production operation.
+- **Rate Limiting**: CCIP offers a rate limiting feature that enables owners to establish and configure rate limiting policies for Cross-Chain Tokens, which are enforced at both the source and destination chains. This provides an enterprise-grade security feature to ensure operational continuity and limit blast radius in failure scenarios.
+- **Timelocked Upgrades**: All onchain security-critical configuration changes and upgrades to core CCIP infrastructure must pass through a Role-based Access Control Timelock contract, where CCIP node operators can veto the upgrade during the review period or explicitly approve the upgrade during time-sensitive circumstances.
+- **High-Quality, Sybil-Resistant Node Operators**: CCIP uses the same globally distributed, security-reviewed, public node operators that secure other services on the Chainlink platform, as well as validate leading blockchain networks and operate traditional Web2 telecommunication infrastructure. Each independent node in CCIP is run by an independent organization who have extensive DevOps expertise and robust security practices around private key management.
 
 <ClickToZoom
   src="/images/ccip/ccip-hl-v1.7.png"
@@ -73,11 +75,11 @@ For example, a user could transfer tokens to a lending protocol with instruction
 
 With CCIP, you send transactions with data (arbitrary messaging), tokens, or both data and tokens (programmable token transfer). The receiver of a CCIP transaction varies by blockchain family:
 
-| CCIP capability             | What is sent    | Receiving account types                                                                 |
-| --------------------------- | --------------- | --------------------------------------------------------------------------------------- |
-| Arbitrary Messaging         | Data            | EVM: Smart contracts only<br />SVM: Programs only                                       |
-| Token Transfer              | Tokens          | EVM: Smart contracts and EOAs<br />SVM: User wallets or program-controlled PDAs         |
-| Programmable Token Transfer | Data and tokens | EVM: Smart contracts only<br />SVM: Data to programs, tokens to program-controlled PDAs |
+| CCIP capability             | What is sent    | Receiving account types                                                                                                                            |
+| --------------------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Arbitrary Messaging         | Data            | EVM: Smart contracts only<br />SVM: Programs only<br />Aptos: Modules only                                                                         |
+| Token Transfer              | Tokens          | EVM: Smart contracts and EOAs<br />SVM: User wallets or program-controlled PDAs<br />Aptos: User accounts or modules deployed to resource accounts |
+| Programmable Token Transfer | Data and tokens | EVM: Smart contracts only<br />SVM: Data to programs, tokens to program-controlled PDAs<br />Aptos: Modules deployed to resource accounts          |
 
 **Note**: On EVM chains, EOAs cannot receive messages. On Solana (SVM), programs work with Program Derived Addresses (PDAs) to manage token reception.