format

Author: aelmanaa

src/content/ccip/api-reference/aptos/v1.6.0/receiver.mdx

@@ -49,7 +49,6 @@ public fun ccip_receive<T: key>(
 1.  **Module Registration**: Your module must be registered as a valid receiver by calling `receiver_registry::register_receiver`. This is typically done once during your module's initialization and requires defining a unique, empty `ProofType` struct.
 
 2.  **Account Type**:
-
     - If your module will handle tokens, it **must** be deployed to a **Resource Account**.
     - If your module is data-only, it can be deployed to a regular user account or a code object account.
 

src/content/ccip/concepts/architecture/onchain/aptos/components.mdx

@@ -26,17 +26,14 @@ This section provides more detail on the Onchain components for Aptos.
 **CCIP messages can be sent in any of the following combinations (terminology adapts to the destination blockchain):**
 
 - **User Account → User Account / EOA / Wallet**
-
   - **Supported Message Type**: Token-only transfers.
   - **Reason**: The recipient is a simple user account that does not have executable code. While a data payload can be sent in the CCIP message, the recipient account has no way to act upon or process that data.
 
 - **User Account → Module / Smart Contract / Program**
-
   - **Supported Message Type**: Token transfers, arbitrary data, and programmable token transfers (data + tokens).
   - **Reason**: The receiving module is designed with a `ccip_receive` function that can be programmed to handle incoming tokens, process arbitrary data, or both simultaneously according to your application's logic.
 
 - **Module / Smart Contract / Program → User Account / EOA / Wallet**
-
   - **Supported Message Type**: Token-only transfers.
   - **Reason**: Similar to the first case, the destination is a simple user account that cannot execute logic to process an incoming data payload.
 
@@ -78,21 +75,17 @@ The `ccip_onramp::onramp` module is an internal CCIP module that handles the cor
 When the Router forwards a `ccip_send` request, the OnRamp performs the following actions:
 
 - **Validations**
-
   - Ensures that the destination chain is not cursed.
   - Verifies that the sender is on the allowlist if one is enabled for the destination lane.
 
 - **Fee Collection**
-
   - Withdraws the pre-calculated fee amount from the sender's specified `fee_token_store`, defaulting to the user's primary store if `0x0` is provided.
 
 - **Token Handling**
-
   - If the message involves token transfers, it initiates a secure callback pattern by calling the `Token Admin Dispatcher`.
   - The dispatcher uses the `Token Admin Registry` to store the message context (sender, receiver, etc.) before invoking the correct `Token Pool` to `lock_or_burn` the assets.
 
 - **Nonce Management**
-
   - For ordered messages, it calls the `Nonce Manager` to retrieve and increment the sender's nonce for that destination.
 
 - **Event Emission**
@@ -116,7 +109,6 @@ During the **Commit Phase**, the following steps occur:
    The Committing DON calls the `commit` function on the `OffRamp` with a report that includes Merkle roots and price updates.
 
 1. **Validation**:
-
    - The `OffRamp` verifies the DON's signatures.
    - It verifies any "blessed" Merkle roots.
 

src/content/ccip/concepts/architecture/onchain/aptos/overview.mdx

@@ -66,9 +66,7 @@ On the Aptos destination blockchain, an onchain module called the `OffRamp` rece
 This outlines the process when initiating a CCIP transaction from the Aptos blockchain.
 
 1. **Preparation**
-
    - The Sender (a user's wallet or another module) prepares the information for a CCIP Message, including:
-
      - **Receiver**: A byte array representing the destination address (e.g., a 20-byte EVM address).
      - **Data payload**: Arbitrary bytes to be delivered to the receiver.
      - **Tokens and amounts** (if applicable).
@@ -80,13 +78,10 @@ This outlines the process when initiating a CCIP transaction from the Aptos bloc
    - The Sender prepares to call the `ccip_router::router::ccip_send` entry function. Unlike EVM and SVM chains, a separate token approve transaction is not required. The user's signature on the `ccip_send` transaction itself authorizes the CCIP modules to withdraw the necessary tokens and fees from the sender's account.
 
 1. **Sending**
-
    - When the `ccip_send` transaction is executed:
-
      - The `Router` module, as the entry point, performs initial validations and forwards the call to the appropriate `OnRamp` module.
 
      - The `OnRamp` module executes the core logic:
-
        - Verifications: It ensures that the destination chain is not cursed by checking with the `RMN Remote` module.
        - Fee Collection: It withdraws the required fee from the sender's fungible asset store. If the fee_token_store address is specified as 0x0, the module automatically resolves to the primary_fungible_store corresponding to the sender's account and the chosen fee_token.
        - Sequence Management: It increments the sequence number for the given destination chain. If required, it also interacts with the `Nonce Manager` to handle ordered message nonces.
@@ -98,27 +93,23 @@ This outlines the process when initiating a CCIP transaction from the Aptos bloc
      - Event Emission: A unique messageId is generated, and the `OnRamp` emits a `CCIPMessageSent` event containing the full, sequenced message details.
 
 1. **Initial Offchain Processing**
-
    - The CCIP Committing DON monitors the Aptos blockchain for the `CCIPMessageSent` event and begins processing the message offchain to prepare it for commitment on the destination chain.
 
 ### Destination Blockchain (Aptos)
 
 This outlines the process when Aptos is the receiving chain for a CCIP message.
 
 1. **Commit Phase**
-
    - The final OCR report from the Committing DON, containing Merkle roots of batched messages and any price updates, is submitted to the `OffRamp` module's `commit` function.
    - The `OffRamp` verifies the DON's signatures.
    - If the report includes blessed Merkle roots, the `OffRamp` verifies the RMN signatures.
    - If the report contains price updates, the `OffRamp` calls the `Fee Quoter` module to update its onchain token and gas price data.
    - The `OffRamp` stores the verified Merkle root and emits a `CommitReportAccepted` event, confirming the messages are ready for execution.
 
 1. **Secondary Offchain Processing**
-
    - The CCIP Executing DON monitors for the `CommitReportAccepted` event. For each message in the committed batch, the DON computes its specific Merkle proof. Each message is then submitted in a separate transaction to the Aptos blockchain.
 
 1. **Execution Phase**
-
    - When the Executing DON calls the `OffRamp` module's `execute` function, the `OffRamp` first verifies the message's Merkle proof against a stored Merkle root. It performs several validations, including checking the `RMN Remote` module and ensuring the message has not already been executed.
      - If the message includes tokens, the `OffRamp` calls the `Token Admin Dispatcher`. This dispatcher follows a secure callback pattern using the `Token Admin Registry`: it initiates a `release_or_mint` operation, which invokes the correct Token Pool. The pool then calls the registry to get its input data, mints or releases the tokens, and sets the output. The released tokens are then deposited into the receiver's primary fungible store.
      - If the message contains arbitrary data, the `OffRamp` calls the `Receiver Dispatcher`. The dispatcher does not pass the message data directly. Instead, it securely stores the payload in the `Receiver Registry` and then triggers the `ccip_receive` entry function of the registered receiver module. The receiver module, in turn, must call receiver_registry::`get_receiver_input` within its own execution to securely fetch the message payload it is meant to process.

src/content/ccip/concepts/architecture/onchain/aptos/upgradability.mdx

@@ -23,7 +23,6 @@ On the Aptos blockchain, upgradability primarily happens in two ways:
    Many CCIP modules (like `onramp`, `offramp`, `fee_quoter`) expose public entry functions that allow authorized accounts to adjust operational parameters. These functions modify onchain data stored in resources without requiring a new deployment.
 
    Examples include:
-
    - Enabling support for a new destination chain.
    - Updating fee parameters.
 
@@ -34,7 +33,6 @@ On the Aptos blockchain, upgradability primarily happens in two ways:
    Aptos allows for module code to be upgraded in-place. This means a code upgrade for the CCIP protocol involves publishing the new, updated module bytecode to the existing Object address.
 
    Because the Object address remains unchanged:
-
    - External modules and off-chain clients that interact with CCIP do not need to update their stored addresses.
    - They seamlessly begin interacting with the new code after the upgrade is published.
 

src/content/ccip/tutorials/aptos/destination/prerequisites.mdx

@@ -102,7 +102,6 @@ By defining these addresses in the `Move.toml` file, the example modules can int
 ## Wallets
 
 - **EVM Wallet and Private Key**: To send transactions from an EVM chain (like Ethereum Sepolia), you need a wallet and its private key.
-
   - Set up a wallet like [MetaMask](https://metamask.io/).
   - You will need to export the private key for the account you intend to send _from_. Follow the [official MetaMask guide](https://support.metamask.io/configure/accounts/how-to-export-an-accounts-private-key/) to obtain your private key and add it to the `.env` file as shown below.
 

src/content/ccip/tutorials/aptos/destination/programmatic-token-transfers.mdx

@@ -185,7 +185,6 @@ Execution state for CCIP message <YOUR_CCIP_MESSAGE_ID> is SUCCESS
 Once execution is successful, you need to verify that your module correctly forwarded the tokens.
 
 - **Check the Event**: You can manually verify that your module emitted the correct `ForwardedTokens` event by using the [Aptos Explorer](https://explorer.aptoslabs.com/?network=testnet).
-
   1.  Search for your receiver module's address (the one you provided with `--aptosReceiver`).
   1.  In the `Transactions` tab, find the latest transaction that calls the `offramp::execute` function.
   1.  Click on the transaction and navigate to the `Events` tab.

src/content/ccip/tutorials/aptos/destination/token-transfers.mdx

@@ -108,12 +108,10 @@ Copy the `account` value from the output and **prepend `0x` to it** and note it
 <Aside type="caution" title="Critical Settings">
 
 - **Required Parameters**
-
   - **`receiver`**: **MUST** be the recipient's 32-byte Aptos wallet address
   - **`data`**: **MUST** be empty (`0x`) for token-only transfers
 
 - **Aptos Destination Configuration**
-
   - **`gasLimit`**: Set to `0` (no module execution required)
   - **`allowOutOfOrderExecution`**: **MUST** be `true` for Aptos destinations