Validator Manager Docs + Cleanup (#1929)

* add OKX OS * 1922 okx integration page (#1925) * add code to okxos.mdx * Update okxos.mdx * Update okxos.mdx * nit formatting * add disclaimer, change import to require * update note on API Key storage * update descriptions and add code * update code example description * update code snippets * add transaction checking * add get tx * add bash script * nit spelling * update conclusion * Update okxos.mdx * nit:formatting * fix broken links * rm elastic subnets, rm wagmi subnet reference * add evm-l1 section + redirects * validator manager docs * fix FolderCode icon * rewardmanager info, nits, fix broken links --------- Signed-off-by: Owen <owenwahlgren@gmail.com> Co-authored-by: Julian Martinez <73849597+Julian-dev28@users.noreply.github.com>
ava-labs · Nov 6, 2024 · b1c6e3b · b1c6e3b
1 parent 732354e
commit b1c6e3b
Show file tree

Hide file tree

Showing 50 changed files with 746 additions and 626 deletions.
diff --git a/.github/linkChecker.ts b/.github/linkChecker.ts
@@ -5,7 +5,7 @@ import { sync as globSync } from 'glob';
 
 const baseUrl = 'http://localhost:3000'; // base url of the website
 
-const whitelist = ["crates.io", "softwaretestinghelp.com", "coinbase.com", "assets.website-files.com", "moralis.io"] // some websites return 404 for head requests, so we need to whitelist them, (fix: pass header -H 'Accept: text/html' and parse text/html)
+const whitelist = ["crates.io", "softwaretestinghelp.com", "coinbase.com", "assets.website-files.com", "moralis.io", "1rpc.io"] // some websites return 404 for head requests, so we need to whitelist them, (fix: pass header -H 'Accept: text/html' and parse text/html)
                                 // see https://github.com/rust-lang/crates.io/issues/788
 
 interface LinkCheckResult {

diff --git a/app/(home)/page.client.tsx b/app/(home)/page.client.tsx
@@ -5,7 +5,7 @@ import React, {
   Fragment,
   type ReactElement,
 } from 'react';
-import { IndentDecrease, Layers, MailIcon, MonitorCheck, Settings, SproutIcon, SquareGanttChart, TerminalIcon, Webhook, HomeIcon, BadgeDollarSign, CpuIcon, Files, Folder, Globe, Link, SquareIcon, ArrowLeftRight, Coins, SquareCode, SquareStackIcon, Triangle, ChevronDownIcon } from 'lucide-react';
+import { IndentDecrease, Layers, MailIcon, MonitorCheck, Settings, SproutIcon, SquareGanttChart, TerminalIcon, Webhook, HomeIcon, FolderCode, BadgeDollarSign, CpuIcon, Files, Folder, Globe, Link, SquareIcon, ArrowLeftRight, Coins, SquareCode, SquareStackIcon, Triangle, ChevronDownIcon } from 'lucide-react';
 import { RootToggle } from 'fumadocs-ui/components/layout/root-toggle';
 import { Menu, Transition } from '@headlessui/react'
 
@@ -125,13 +125,19 @@ export function HamburgerMenu(): React.ReactElement {
         url: '/dapps',
       },
       {
-        title: 'Avalanche L1s',
+        title: 'Avalanche CLI',
         description: 'Build Your L1 Blockchain',
         icon: <Layers />,
         url: '/avalanche-l1s',
       },
       {
-        title: 'Virtual Machines',
+        title: 'EVM L1s',
+        description: 'Customize the Ethereum VM',
+        icon: <FolderCode />,
+        url: '/evm-l1s',
+      },
+      {
+        title: 'Custom Virtual Machines',
         description: 'Customize Your Execution Layer',
         icon: <IndentDecrease />,
         url: '/virtual-machines',

diff --git a/app/layout.config.tsx b/app/layout.config.tsx
@@ -2,7 +2,7 @@ import { type BaseLayoutProps, type DocsLayoutProps } from 'fumadocs-ui/layout';
 import { Title, HomeTitle } from '@/app/layout.client';
 import { docsPageTree } from '@/utils/docs-loader';
 import { RootToggle } from 'fumadocs-ui/components/layout/root-toggle';
-import { MailIcon, SproutIcon, SquareGanttChart, IndentDecrease, Layers, MonitorCheck, Settings, Webhook } from 'lucide-react';
+import { MailIcon, SproutIcon, SquareGanttChart, IndentDecrease, Layers, MonitorCheck, Settings, Webhook, Server, FolderCode } from 'lucide-react';
 
 // home page configuration (HomeTitle includes hamburger menu)
 export const homebaseOptions: BaseLayoutProps = {
@@ -68,13 +68,19 @@ export const docsOptions: DocsLayoutProps = {
             url: '/dapps',
           },
           {
-            title: 'Avalanche L1s',
+            title: 'Avalanche CLI',
             description: 'Build Your L1 Blockchain',
             icon: <Layers />,
             url: '/avalanche-l1s',
           },
           {
-            title: 'Virtual Machines',
+            title: 'EVM L1s',
+            description: 'Customize the Ethereum VM',
+            icon: <FolderCode />,
+            url: '/evm-l1s',
+          },
+          {
+            title: 'Custom Virtual Machines',
             description: 'Customize Your Execution Layer',
             icon: <IndentDecrease />,
             url: '/virtual-machines',

diff --git a/components/mermaid.tsx b/components/mermaid.tsx
@@ -0,0 +1,19 @@
+"use client";
+import React, { useEffect } from "react";
+import mermaid from "mermaid";
+
+mermaid.initialize({
+  startOnLoad: true,
+});
+
+type MermaidProps = {
+  readonly chart: string;
+};
+
+const Mermaid = ({ chart }: MermaidProps): JSX.Element => {
+  useEffect(() => mermaid.contentLoaded(), []);
+
+  return <div className="mermaid">{chart}</div>;
+};
+
+export default Mermaid;
diff --git a/content/docs/avalanche-l1s/add-utility/cross-chain-bridge.mdx b/content/docs/avalanche-l1s/add-utility/cross-chain-bridge.mdx
diff --git a/...t/docs/avalanche-l1s/elastic-avalanche-l1s/make-avalanche-l1-permissionless.mdx b/...t/docs/avalanche-l1s/elastic-avalanche-l1s/make-avalanche-l1-permissionless.mdx
@@ -3,6 +3,8 @@ title: Make Avalanche L1 Permissionless
 description: Learn how to transform a Permissioned Avalanche L1 into an Elastic Avalanche L1.
 ---
 
+> Elastic L1s / Elastic Subnets have been deprecated. Please check out the PoS Validator Manager instead
+
 Elastic Avalanche L1s are permissionless Avalanche L1s. More information can be found [here](/avalanche-l1s/elastic-avalanche-l1s/parameters).
 
 This how-to guide focuses on taking an already created permissioned Avalanche L1 and transforming it to an elastic (or permissionless) Avalanche L1.

diff --git a/content/docs/avalanche-l1s/elastic-avalanche-l1s/parameters.mdx b/content/docs/avalanche-l1s/elastic-avalanche-l1s/parameters.mdx
@@ -3,6 +3,8 @@ title: Parameters
 description: Learn about the different parameters of Elastic Avalanche L1s.
 ---
 
+> Elastic L1s / Elastic Subnets have been deprecated. Please check out the PoS Validator Manager instead
+
 Avalanche Permissioned Avalanche L1s can be turned into Elastic Avalanche L1s via the `TransformSubnetTx` transaction. `TransformSubnetTx` specifies a set of structural parameters for the Elastic Avalanche L1.
 
 This reference document describes these structural parameters and illustrates the constraints they must satisfy.

diff --git a/content/docs/avalanche-l1s/meta.json b/content/docs/avalanche-l1s/meta.json
@@ -14,22 +14,14 @@
     "deploy-a-avalanche-l1/production-infrastructure",
     "deploy-a-avalanche-l1/multisig-auth",
     "deploy-a-avalanche-l1/custom-virtual-machine",
-    "---Elastic Avalanche L1s---",
-    "elastic-avalanche-l1s/make-avalanche-l1-permissionless",
-    "elastic-avalanche-l1s/parameters",
     "---Maintain an Avalanche L1---",
     "maintain/view-avalanche-l1s",
     "maintain/pause-resume",
     "maintain/delete-avalanche-l1",
     "maintain/transfer-pchain-funds",
-    "---Add Utility on an Avalanche L1---",
-    "add-utility/deploy-smart-contract",
-    "add-utility/testnet-faucet",
-    "add-utility/cross-chain-bridge",
     "---Upgrade an Avalanche L1---",
     "...upgrade",
     "---Miscellaneous---",
-    "wagmi-avalanche-l1",
     "troubleshooting"
   ]
 }
diff --git a/content/docs/avalanche-l1s/upgrade/customize-avalanche-l1.mdx b/content/docs/avalanche-l1s/upgrade/customize-avalanche-l1.mdx
@@ -427,262 +427,9 @@ In the amount field you can specify either decimal or hex string. This will mint
 
 ### Configuring Dynamic Fees[](#configuring-dynamic-fees "Direct link to heading")
 
-You can configure the parameters of the dynamic fee algorithm on chain using the `FeeConfigManager`. In order to activate this feature, you will need to provide the `FeeConfigManager` in the genesis:
-
-```json
-{
-  "config": {
-    "feeManagerConfig": {
-      "blockTimestamp": 0,
-      "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"]
-    }
-  }
-}
-```
-
-The precompile implements the `FeeManager` interface which includes the same `AllowList` interface used by ContractNativeMinter, TxAllowList, etc. For an example of the `AllowList` interface, see the [TxAllowList](#allowlist-interface) above.
-
-The `Stateful Precompile` contract powering the `FeeConfigManager` adheres to the following Solidity interface at `0x0200000000000000000000000000000000000003` (you can load this interface and interact directly in Remix). It can be also found in [IFeeManager.sol](https://github.com/ava-labs/subnet-evm/blob/5faabfeaa021a64c2616380ed2d6ec0a96c8f96d/contract-examples/contracts/IFeeManager.sol):
-
-```solidity
-//SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-import "./IAllowList.sol";
-
-interface IFeeManager is IAllowList {
-  struct FeeConfig {
-    uint256 gasLimit;
-    uint256 targetBlockRate;
-    uint256 minBaseFee;
-    uint256 targetGas;
-    uint256 baseFeeChangeDenominator;
-    uint256 minBlockGasCost;
-    uint256 maxBlockGasCost;
-    uint256 blockGasCostStep;
-  }
-  event FeeConfigChanged(
-    address indexed sender,
-    FeeConfig oldFeeConfig,
-    FeeConfig newFeeConfig
-  );
-
-  // Set fee config fields to contract storage
-  function setFeeConfig(
-    uint256 gasLimit,
-    uint256 targetBlockRate,
-    uint256 minBaseFee,
-    uint256 targetGas,
-    uint256 baseFeeChangeDenominator,
-    uint256 minBlockGasCost,
-    uint256 maxBlockGasCost,
-    uint256 blockGasCostStep
-  ) external;
-
-  // Get fee config from the contract storage
-  function getFeeConfig()
-    external
-    view
-    returns (
-      uint256 gasLimit,
-      uint256 targetBlockRate,
-      uint256 minBaseFee,
-      uint256 targetGas,
-      uint256 baseFeeChangeDenominator,
-      uint256 minBlockGasCost,
-      uint256 maxBlockGasCost,
-      uint256 blockGasCostStep
-    );
-
-  // Get the last block number changed the fee config from the contract storage
-  function getFeeConfigLastChangedAt()
-    external
-    view
-    returns (uint256 blockNumber);
-}
-```
-
-FeeConfigManager precompile uses `IAllowList` interface directly, meaning that it uses the same `AllowList` interface functions like `readAllowList` and `setAdmin`, `setManager`, `setEnabled`, `setNone`. For more information see [AllowList Solidity interface](#allowlist-interface).
-
-In addition to the `AllowList` interface, the FeeConfigManager adds the following capabilities:
-
-- `getFeeConfig`: retrieves the current dynamic fee config
-- `getFeeConfigLastChangedAt`: retrieves the timestamp of the last block where the fee config was updated
-- `setFeeConfig`: sets the dynamic fee config on chain (see [here](#fee-config) for details on the fee config parameters). This function can only be called by an `Admin`, `Manager` or `Enabled` address.
-- `FeeConfigChanged`: an event that is emitted when the fee config is updated. Topics include the sender, the old fee config, and the new fee config.
-
-You can also get the fee configuration at a block with the `eth_feeConfig` RPC method. For more information see [here](/api-reference/subnet-evm-api#eth_feeconfig).
-
-#### Initial Fee Config Configuration[](#initial-fee-config-configuration "Direct link to heading")
-
-It's possible to enable this precompile with an initial configuration to activate its effect on activation timestamp. This provides a way to define your fee structure to take effect at the activation.
-
-To use the initial configuration, you need to specify the fee config in `initialFeeConfig` field in your genesis or upgrade file:
-
-```json
-{
-  "feeManagerConfig": {
-    "blockTimestamp": 0,
-    "initialFeeConfig": {
-      "gasLimit": 20000000,
-      "targetBlockRate": 2,
-      "minBaseFee": 1000000000,
-      "targetGas": 100000000,
-      "baseFeeChangeDenominator": 48,
-      "minBlockGasCost": 0,
-      "maxBlockGasCost": 10000000,
-      "blockGasCostStep": 500000
-    }
-  }
-}
-```
-
-This will set the fee config to the values specified in the `initialFeeConfig` field. For further information about precompile initial configurations see [Initial Precompile Configurations](#initial-precompile-configurations).
-
-### Changing Fee Reward Mechanisms[](#changing-fee-reward-mechanisms "Direct link to heading")
-
-Fee reward mechanism can be configured with this stateful precompile contract called as `RewardManager`. Configuration can include burning fees, sending fees to a predefined address, or enabling fees to be collected by block producers. This precompile can be configured as follows in the genesis file:
-
-```json
-{
-  "config": {
-    "rewardManagerConfig": {
-      "blockTimestamp": 0,
-      "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"]
-    }
-  }
-}
-```
-
-`adminAddresses` denotes admin accounts who can add other `Admin` or `Enabled` accounts. `Admin`, `Manager` and `Enabled` are both eligible to change the current fee mechanism.
-
-The precompile implements the `RewardManager` interface which includes the `AllowList` interface. For an example of the `AllowList` interface, see the [TxAllowList](#allowlist-interface) above.
-
-The `Stateful Precompile` contract powering the `RewardManager` adheres to the following Solidity interface at `0x0200000000000000000000000000000000000004` (you can load this interface and interact directly in Remix). It can be also found in [IRewardManager.sol](https://github.com/ava-labs/subnet-evm/blob/5faabfeaa021a64c2616380ed2d6ec0a96c8f96d/contract-examples/contracts/IRewardManager.sol):
-
-```solidity
-//SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-import "./IAllowList.sol";
-
-interface IRewardManager is IAllowList {
-  // RewardAddressChanged is the event logged whenever reward address is modified
-  event RewardAddressChanged(
-    address indexed sender,
-    address indexed oldRewardAddress,
-    address indexed newRewardAddress
-  );
-
-  // FeeRecipientsAllowed is the event logged whenever fee recipient is modified
-  event FeeRecipientsAllowed(address indexed sender);
-
-  // RewardsDisabled is the event logged whenever rewards are disabled
-  event RewardsDisabled(address indexed sender);
-
-  // setRewardAddress sets the reward address to the given address
-  function setRewardAddress(address addr) external;
-
-  // allowFeeRecipients allows block builders to claim fees
-  function allowFeeRecipients() external;
-
-  // disableRewards disables block rewards and starts burning fees
-  function disableRewards() external;
-
-  // currentRewardAddress returns the current reward address
-  function currentRewardAddress() external view returns (address rewardAddress);
-
-  // areFeeRecipientsAllowed returns true if fee recipients are allowed
-  function areFeeRecipientsAllowed() external view returns (bool isAllowed);
-}
-```
-
-`RewardManager` precompile uses `IAllowList` interface directly, meaning that it uses the same `AllowList` interface functions like `readAllowList` and `setAdmin`, `setEnabled`, `setNone`. For more information see [AllowList Solidity interface](#allowlist-interface).
-
-In addition to the `AllowList` interface, the `RewardManager` adds the following capabilities:
-
-- `setRewardAddress`: sets the address to which fees are sent. This address can be a contract or a user address. The address becomes the required coinbase address for the blocks that this mechanism is enabled on. Meaning that it will receive the fees collected from the transactions in the block. Receiving fees will not call any contract functions or fallback functions. It will simply increase the balance of the address by the amount of fees.  
-- `allowFeeRecipients`: enables block producers to claim fees. This will allow block producers to claim fees by specifying their own addresses in their chain configs. See [here](#fee-recipient) for more information on how to specify the fee recipient address in the chain config.
-- `disableRewards`: disables block rewards and starts burning fees.
-- `currentRewardAddress`: returns the current reward address. This is the address to which fees are sent. It can include black hole address (`0x010...0`) which means that fees are burned. It can also include a predefined hash (`0x0000000000000000000000000000000000000000`) denoting custom fee recipients are allowed. It's advised to use the `areFeeRecipientsAllowed` function to check if custom fee recipients are allowed first.
-- `areFeeRecipientsAllowed`: returns true if custom fee recipients are allowed.
-- `RewardAddressChanged`: an event that is emitted when the reward address is updated. Topics include the sender, the old reward address, and the new reward address.
-- `FeeRecipientsAllowed`: an event that is emitted when fee recipients are allowed. Topics include the sender.
-- `RewardsDisabled`: an event that is emitted when rewards are disabled. Topics include the sender.
-
-These 3 mechanisms (burning, sending to a predefined address, and enabling fees to be collected by block producers) cannot be enabled at the same time. Enabling one mechanism will take over the previous mechanism. For example, if you enable `allowFeeRecipients` and then enable `disableRewards`, the `disableRewards` will take over and fees will be burned.
-
-Note that reward addresses or fee recipient addresses are not required to be an admin or enabled account.
-
-#### Initial Configuration[](#initial-configuration "Direct link to heading")
-
-It's possible to enable this precompile with an initial configuration to activate its effect on activation timestamp. This provides a way to enable the precompile without an admin address to change the fee reward mechanism. This can be useful for networks that require a one-time reward mechanism change without specifying any admin addresses. Without this initial configuration, the precompile will inherit the `feeRecipients` mechanism activated at genesis. Meaning that if `allowFeeRecipients` is set to true in the genesis file, the precompile will be enabled with the `allowFeeRecipients` mechanism. Otherwise it will keep burning fees. To use the initial configuration, you need to specify the initial reward mechanism in `initialRewardConfig` field in your genesis or upgrade file.
-
-In order to allow custom fee recipients, you need to specify the `allowFeeRecipients` field in the `initialRewardConfig`:
-
-```json
-{
-  "rewardManagerConfig": {
-    "blockTimestamp": 0,
-    "initialRewardConfig": {
-      "allowFeeRecipients": true
-    }
-  }
-}
-```
-
-In order to set an address to receive all transaction rewards, you need to specify the `rewardAddress` field in the `initialRewardConfig`:
-
-```json
-{
-  "rewardManagerConfig": {
-    "blockTimestamp": 0,
-    "initialRewardConfig": {
-      "rewardAddress": "0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"
-    }
-  }
-}
-```
-
-In order to disable rewards and start burning fees, you need to leave all fields in the `initialRewardConfig` empty:
-
-```json
-{
-  "rewardManagerConfig": {
-    "blockTimestamp": 0,
-    "initialRewardConfig": {}
-  }
-}
-```
-
-However this is different than the default behavior of the precompile. If you don't specify the `initialRewardConfig` field, the precompile will inherit the `feeRecipients` mechanism activated at genesis. Meaning that if `allowFeeRecipients` is set to true in the genesis file, the precompile will be enabled with the `allowFeeRecipients` mechanism. Otherwise it will keep burning fees. Example configuration for this case:
-
-```json
-{
-  "rewardManagerConfig": {
-    "blockTimestamp": 0,
-    "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"]
-  }
-}
-```
-
-If `allowFeeRecipients` and `rewardAddress` are both specified in the `initialRewardConfig` field then an error will be returned and precompile won't be activated. For further information about precompile initial configurations see [Initial Precompile Configurations](#initial-precompile-configurations).
 
 ### Avalanche Warp Messaging[](#avalanche-warp-messaging "Direct link to heading")
 
-Warp Precompile enabled cross-blockchain communication between other Layer 1s and primary-network (C-Chain). In order to use Warp messaging, Subnet-EVM chains must activate their Warp precompiles. Warp can be activated with the following lines in upgrade.json:
-
-```json
-{
-  "warpConfig": {
-    "blockTimestamp": (uint),
-    "quorumNumerator": (uint)
-  }
-}
-```
-
-`blockTimestamp` must be set to a timestamp after Durango date. `quorumNumerator` is the stake percentage of validators that must sign a Warp message for it to be considered valid. It must be set to a value between 33 and 100. The default value is 67. The `warpConfig` precompile can be later disabled by setting `disable` to `true` in the upgrade.json file.
-
-If you want to use Warp messaging in an existing Subnet-EVM chain, you should coordinate an upgrade with `upgrade.json`. See [Network Upgrades: Enable/Disable Precompiles](#network-upgrades-enabledisable-precompiles) for more information.
-
 <Callout type="warn">
 Currently Warp Precompile can only be activated in Mainnet after Durango occurs. Durango in Mainnet is set at 11 AM ET (4 PM UTC) on Wednesday, March 6th, 2024. If you plan to use Warp messaging in your own Subnet-EVM chain in Mainnet you should upgrade to AvalancheGo 1.11.11 or later and coordinate your precompile upgrade. Warp Config's "blockTimestamp" must be set after `1709740800`, Durango date (11 AM ET (4 PM UTC) on Wednesday, March 6th, 2024).
 </Callout>