ava-labs · martineckardt · Feb 24, 2025 · Feb 21, 2025 · Feb 23, 2025
@@ -26,8 +26,8 @@ The Metrics API, along with the Data API are the driving force behind every grap
 ### Metrics API Features
 - **Chain Throughput**: Retrieve detailed metrics on gas consumption, Transactions Per Second (TPS), and gas prices, including rolling windows of data for granular analysis.
 - **Cumulative Metrics**: Access cumulative data on addresses, contracts, deployers, and transaction counts, providing insights into network growth over time.
-- **Staking Information**: Obtain staking-related data, including the number of validators and delegators, along with their respective weights, across different subnets.
-- **Blockchains and Subnets**: Get information about supported blockchains, including EVM Chain IDs, blockchain IDs, and subnet associations, facilitating multi-chain analytics.
+- **Staking Information**: Obtain staking-related data, including the number of validators and delegators, along with their respective weights, across different L1s.
+- **Blockchains and L1s**: Get information about supported blockchains, including EVM Chain IDs, blockchain IDs, and L1s associations, facilitating multi-chain analytics.
 - **Composite Queries**: Perform advanced queries by combining different metric types and conditions, enabling detailed and customizable data retrieval.
 
 ## What is the AvaCloudSDK?

@@ -20,7 +20,7 @@ With the Webhooks API, you can monitor real-time events on the Avalanche C-Chain
 - **Real-time notifications:** Receive immediate updates on specified on-chain activities without polling.
 - **Customizable:** Specify the desired event type to listen for, customizing notifications according to individual requirements.
 - **Secure:** Employ shared secrets and signature-based verification to guarantee that notifications originate from a trusted source.
-- **Broad Coverage:** Support for C-chain mainnet, testnet, and subnets within the Avalanche ecosystem, ensuring wide-ranging monitoring capabilities.
+- **Broad Coverage:** Support for C-chain mainnet, testnet, and L1s within the Avalanche ecosystem, ensuring wide-ranging monitoring capabilities.
 
 ### Use Cases:
 - **NFT Marketplace Transactions:** Get alerts for NFT minting, transfers, auctions, bids, sales, and other interactions within NFT marketplaces.

@@ -1,6 +1,6 @@
 ---
 title: Create & Deploy a Blockchain
-description: Learn how you can configure and launch your subnet using AvaCloud.
+description: Learn how you can configure and launch your L1 using AvaCloud.
 updated: 2024-05-31
 authors: [ashucoder9]
 icon: Terminal

@@ -39,7 +39,7 @@ Make sure you replace the binary name with the actual binary name of your Precom
 Next, launch the Avalanche L1 with your custom VM:
 
 ```bash
-avalanche subnet deploy myblockchain
+avalanche blockchain deploy myblockchain
 ```
 
 After around 1 minute the blockchain should have been created and some more output should appear in the terminal. You'll also see the RPC URL of your blockchain in the terminal.
@@ -10,7 +10,7 @@ Sending a message is nothing more than a simple contract call to the Interchain
 
 <img src="/common-images/teleporter/teleporter-source.png" width="400" class="mx-auto"/>
 
-The dApp on the Source Subnet has to call the `sendCrossChainMessage` function of the Interchain Messaging contract. The Interchain Messaging contract implements the `ITeleporterMessenger` interface below. Note that the dApp itself does not have to implement the interface.
+The dApp on the Source L1 has to call the `sendCrossChainMessage` function of the Interchain Messaging contract. The Interchain Messaging contract implements the `ITeleporterMessenger` interface below. Note that the dApp itself does not have to implement the interface.
 
 ```solidity title="/lib/teleporter/contracts/src/Teleporter/ITeleporterMessenger.sol"
 pragma solidity 0.8.18;
@@ -44,7 +44,7 @@ interface ITeleporterMessenger {
     );
 
     /**
-     * @dev Called by transactions to initiate the sending of a cross subnet message.
+     * @dev Called by transactions to initiate the sending of a cross L1 message.
      */
 	function sendCrossChainMessage(TeleporterMessageInput calldata messageInput)
         external

@@ -107,7 +107,7 @@ contract SenderOnCChain {
     function sendMessage(address destinationAddress, string calldata message) external {
         messenger.sendCrossChainMessage(
             TeleporterMessageInput({
-                // Replace with blockchainID of your Subnet (see instructions in Readme)
+                // Replace with blockchainID of your L1 (see instructions in Readme)
                 destinationBlockchainID: 0x6391b85bafc78f1b10aec35695c2399c2fb7fff9f3b18ea903f77345e9e96e3e, // [!code highlight]
                 destinationAddress: destinationAddress,
                 feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),

@@ -10,7 +10,7 @@ To receive a message we need to enable our cross-L1 dApps to being called by the
 
 ![](/course-images/teleporter/teleporter-source-destination-with-relayer.png)
 
-The Interchain Messaging does not know our contract and what functions it has. Therefore, our dApp on the destination Subnet has to implement the ITeleporterReceiver interface. It is very straight forward and only requires a single method for receiving the message that then can be called by the Interchain Messaging contract:
+The Interchain Messaging does not know our contract and what functions it has. Therefore, our dApp on the destination L1 has to implement the ITeleporterReceiver interface. It is very straight forward and only requires a single method for receiving the message that then can be called by the Interchain Messaging contract:
 
 ```solidity
 pragma solidity 0.8.18;
@@ -37,7 +37,7 @@ interface ITeleporterReceiver {
 The function receiveTeleporterMessage has three parameters:
 
 - **`originChainID`**: The chainID where the message originates from, meaning where the user or contract called the `sendCrossChainMessage` function of the Interchain Messaging contract
-- **`originSenderAddress`**: The address of the user or contract that called the `sendCrossChainMessage` function of the Interchain Messaging contract on the origin Subnet
+- **`originSenderAddress`**: The address of the user or contract that called the `sendCrossChainMessage` function of the Interchain Messaging contract on the origin L1
 - **`message`**: The message encoded in bytes
 
 An example for a contract being able to receive Interchain Messaging messages and storing these in a mapping could look like this:

@@ -57,7 +57,7 @@ If the verification is successful, the message is executed.
 
 ## Why doesn't the AWM Relayer also aggregate the BLS Public Keys?
 
-The BLS public key aggregation has to be done by every validator of the destination subnet. Some may ask why we don't perform this action off-chain through the AWM Relayer and attach it to the message (similar to the BLS signature aggregation).
+The BLS public key aggregation has to be done by every validator of the destination L1. Some may ask why we don't perform this action off-chain through the AWM Relayer and attach it to the message (similar to the BLS signature aggregation).
 
 Even though this would make the verification much faster, there is a security issue here. How can we be sure that the aggregated public key actually represents the public keys of the signing validators? How do we know that the AWM Relayer did not just create a bunch of public keys and an aggregated signature of these?
 

@@ -45,7 +45,7 @@ The general config contains among others the following parameters:
 
 ## Source Blockchain Configs
 
-Next is the configuration for our source blockchain. This is the configuration of the blockchain where messages will be initiated and picked up. The relayer will aggregate the signatures of the validators of that Subnet. 
+Next is the configuration for our source blockchain. This is the configuration of the blockchain where messages will be initiated and picked up. The relayer will aggregate the signatures of the validators of that L1. 
 
 ```json
 {

@@ -34,7 +34,7 @@ As you can see the `TeleporterMessageInput` allows you to specify an array of ad
 ```solidity
 messenger.sendCrossChainMessage( 
     TeleporterMessageInput({
-        // Replace with blockchainID of your Subnet (see instructions in Readme)
+        // Replace with blockchainID of your L1 (see instructions in Readme)
         destinationBlockchainID: 0x3861e061737eaeb8d00f0514d210ad1062bfacdb4bd22d1d1f5ef876ae3a8921,
         destinationAddress: destinationAddress, 
         feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),
@@ -50,7 +50,7 @@ If you want to restrict the message to a certain relayer, you can simply add the
 ```solidity
 messenger.sendCrossChainMessage( 
     TeleporterMessageInput({
-        // Replace with blockchainID of your Subnet (see instructions in Readme)
+        // Replace with blockchainID of your L1 (see instructions in Readme)
         destinationBlockchainID: 0x3861e061737eaeb8d00f0514d210ad1062bfacdb4bd22d1d1f5ef876ae3a8921,
         destinationAddress: destinationAddress, 
         feeInfo: TeleporterFeeInfo({feeTokenAddress: address(0), amount: 0}),

@@ -63,7 +63,7 @@ You will get an output like this:
 
 ```
 +--------+-------+----------+--------------------------------------------+---------------+-------------------+---------------+
-|  KIND  | NAME  |  SUBNET  |                  ADDRESS                   |     TOKEN     |      BALANCE      |    NETWORK    |
+|  KIND  | NAME  |    L1    |                  ADDRESS                   |     TOKEN     |      BALANCE      |    NETWORK    |
 +--------+-------+----------+--------------------------------------------+---------------+-------------------+---------------+
 | stored | myAddress | myblockchain | 0x302Ce9b6346E477ecb774aF73E908a4971B7ce2E | NAT (Native)  |         0 | Local Network |
 +        +       +          +--------------------------------------------+---------------+-------------------+---------------+

@@ -66,7 +66,7 @@ avalanche key list --local --keys ewoq  --blockchains c,myblockchain --tokens $E
 
 ```bash
 +--------+------+---------+--------------------------------------------+---------------+------------------+---------------+
-|  KIND  | NAME | SUBNET  |                  ADDRESS                   |     TOKEN     |     BALANCE      |    NETWORK    |
+|  KIND  | NAME |   L1    |                  ADDRESS                   |     TOKEN     |     BALANCE      |    NETWORK    |
 +--------+------+---------+--------------------------------------------+---------------+------------------+---------------+
 | stored | ewoq | myblockchain |                                        | TOK (0x0D18.)|               0  | Local Network |
 +        +      +----------+--------------------------------------------+---------------+-----------------+---------------+
@@ -106,7 +106,7 @@ avalanche key list --local --keys ewoq  --blockchains c,myblockchain --tokens $E
 
 ```bash
 +--------+------+----------+--------------------------------------------+---------------+-----------------+---------------+
-|  KIND  | NAME |  SUBNET  |                  ADDRESS                   |     TOKEN     |     BALANCE     |    NETWORK    |
+|  KIND  | NAME |    L1    |                  ADDRESS                   |     TOKEN     |     BALANCE     |    NETWORK    |
 +--------+------+----------+--------------------------------------------+---------------+-----------------+---------------+
 | stored | ewoq | myblockchain | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC | TOK (0x0D18.) |   100.000000000 | Local Network |
 +        +      +----------+--------------------------------------------+---------------+-----------------+---------------+

@@ -30,7 +30,7 @@ By using the **relayer service**, gas costs for transactions made through the br
 This integration is especially useful for bridging clients who are not familiar with Web3, as it removes the need for them to manage gas tokens during the cross-chain asset transfer process. Once set up, the relayer infrastructure includes:
 
 1. A **relaying node** to handle transactions.
-2. A **relayer wallet** funded with gas tokens from the subnet.
+2. A **relayer wallet** funded with gas tokens from the L1.
 3. A **trusted forwarder contract** that securely relays transactions.
 
 With this setup, users benefit from a gas-free experience when interacting with your bridge, making cross-chain transfers and other actions seamless and accessible.
@@ -41,9 +41,7 @@ The `ITeleporterReceiver` interface provides a single method. All contracts that
 
 ## Data Flow
 
-<div align="center">
-  <img src="https://github.com/ava-labs/icm-contracts/blob/main/resources/TeleporterDataFlowDiagram.png?raw=true"/>
-</div>
+![image showing teleporter data flow diagram from L1A to L1B](/images/teleporter-data-flow-diagram.png)
 
 ## Properties
-Original file line number
+Diff line change
@@ Expand Up @@
     ## Source Blockchain Configs
-    Next is the configuration for our source blockchain. This is the configuration of the blockchain where messages will be initiated and picked up. The relayer will aggregate the signatures of the validators of that Subnet.
+    Next is the configuration for our source blockchain. This is the configuration of the blockchain where messages will be initiated and picked up. The relayer will aggregate the signatures of the validators of that L1.
     ```json
     {
@@ Expand Down @@