fixing links (#2590)

* fixing links

* fix sherry links

* fix precompile links

* fix tenderly links

* fix tenderly links

* build dapps update links

* updated links docs avalanche-l1s

* updated links docs interoperability

* updated links docs custom VMs

* updated links docs nodes & validators

* updated links docs tooling

Author: navillanueva

content/docs/avalanche-l1s/elastic-avalanche-l1s/make-avalanche-l1-permissionless.mdx

@@ -11,7 +11,7 @@ This how-to guide focuses on taking an already created permissioned Avalanche L1
 
 ## Prerequisites
 
-- [Avalanche-CLI installed](/docs/tooling/guides/get-avalanche-cli)
+- [Avalanche-CLI installed](/docs/tooling/get-avalanche-cli)
 - You have deployed a permissioned Avalanche L1 on [local](/docs/avalanche-l1s/deploy-a-avalanche-l1/local-network), on [Fuji](/docs/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet) or on [Mainnet](/docs/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet)
 
 Getting Started[​](#getting-started "Direct link to heading")

content/docs/avalanche-l1s/evm-configuration/allowlist.mdx

@@ -59,8 +59,8 @@ The AllowList interface is implemented by multiple precompiles in the Subnet-EVM
 
 Several precompiles in Subnet-EVM use the AllowList interface:
 
-- [Native Minter](/docs/virtual-machines/default-precompiles/nativeminter)
-- [Fee Manager](/docs/virtual-machines/default-precompiles/feemanager)
-- [Reward Manager](/docs/virtual-machines/default-precompiles/rewardmanager)
-- [Contract Deployer Allow List](/docs/virtual-machines/default-precompiles/deployerallowlist)
-- [Transaction Allow List](/docs/virtual-machines/default-precompiles/transactionallowlist)
+- [Native Minter](/docs/avalanche-l1s/evm-configuration/tokenomics#native-minter)
+- [Fee Manager](/docs/avalanche-l1s/evm-configuration/transaction-fees#fee-manager)
+- [Reward Manager](/docs/avalanche-l1s/evm-configuration/transaction-fees#reward-manager)
+- [Contract Deployer Allow List](/docs/avalanche-l1s/evm-configuration/permissions#contract-deployer-allowlist)
+- [Transaction Allow List](/docs/avalanche-l1s/evm-configuration/permissions#transaction-allowlist)

content/docs/avalanche-l1s/evm-configuration/permissions.mdx

@@ -10,7 +10,7 @@ The Subnet-EVM provides two powerful precompiles for managing permissions on you
 - **Contract Deployer Allowlist**: Control which addresses can deploy smart contracts
 - **Transaction Allowlist**: Control which addresses can submit transactions
 
-Both precompiles use the [AllowList interface](/docs/avalanche-l1s/allowlist) to manage permissions with a consistent role-based system.
+Both precompiles use the [AllowList interface](/docs/avalanche-l1s/evm-configuration/allowlist) to manage permissions with a consistent role-based system.
 
 ## Contract Deployer Allowlist
 
@@ -64,12 +64,12 @@ By enabling this feature, you can define which addresses are allowed to submit t
 
 ## Permissions Management
 
-Both precompiles use the [AllowList interface](/docs/avalanche-l1s/allowlist) to manage permissions. This provides a consistent way to:
+Both precompiles use the [AllowList interface](/docs/avalanche-l1s/evm-configuration/allowlist) to manage permissions. This provides a consistent way to:
 - Assign and revoke permissions
 - Manage admin and manager roles
 - Control who can deploy contracts or submit transactions
 
-For detailed information about the role-based permission system and available functions, see the [AllowList interface documentation](/docs/avalanche-l1s/allowlist).
+For detailed information about the role-based permission system and available functions, see the [AllowList interface documentation](/docs/avalanche-l1s/evm-configuration/allowlist).
 
 ## Implementation
 

content/docs/avalanche-l1s/evm-configuration/tokenomics.mdx

@@ -9,7 +9,7 @@ The tokenomics of your Avalanche L1 blockchain is a crucial aspect that determin
 
 - Initial token allocation in genesis
 - Dynamic token minting through the Native Minter precompile
-- Fee burning or redistribution mechanisms (via [Transaction Fees & Gas](/docs/avalanche-l1s/default-precompiles/transaction-fees))
+- Fee burning or redistribution mechanisms (via [Transaction Fees & Gas](/docs/avalanche-l1s/evm-configuration/transaction-fees))
 
 ## Initial Token Supply
 
@@ -90,7 +90,7 @@ interface INativeMinter {
 }
 ```
 
-The Native Minter precompile uses the [AllowList interface](/docs/avalanche-l1s/allowlist) to restrict access to its functionality with the following roles.
+The Native Minter precompile uses the [AllowList interface](/docs/avalanche-l1s/evm-configuration/allowlist) to restrict access to its functionality with the following roles.
 
 ## Tokenomics Best Practices
 

content/docs/avalanche-l1s/evm-configuration/transaction-fees.mdx

@@ -10,7 +10,7 @@ The Subnet-EVM provides two powerful precompiles for managing transaction fees a
 - **Fee Manager**: Configure dynamic fee parameters and gas costs
 - **Reward Manager**: Control how transaction fees are distributed or burned
 
-Both precompiles use the [AllowList interface](/docs/avalanche-l1s/allowlist) to restrict access to their functionality.
+Both precompiles use the [AllowList interface](/docs/avalanche-l1s/evm-configuration/allowlist) to restrict access to their functionality.
 
 ## Fee Manager
 
@@ -62,7 +62,7 @@ The Fee Manager allows configuration of the following parameters:
 
 ### Access Control and Additional Features
 
-The FeeManager precompile uses the [AllowList interface](/docs/avalanche-l1s/allowlist) to restrict access to its functionality.
+The FeeManager precompile uses the [AllowList interface](/docs/avalanche-l1s/evm-configuration/allowlist) to restrict access to its functionality.
 
 In addition to the AllowList interface, the FeeManager adds the following capabilities:
 

content/docs/avalanche-l1s/upgrade/considerations.mdx

@@ -64,7 +64,7 @@ This will download the archive to the machine. Unpack it like this (use the corr
 tar xvf subnet-evm_0.2.9_linux_amd64.tar.gz
 ```
 
-This will unpack and place the contents of the archive in the current directory, file `subnet-evm` is the plugin binary. You need to stop the node now (if the node is running as a service, use `sudo systemctl stop avalanchego` command). You need to place that file into the plugins directory where the AvalancheGo binary is located. If the node is installed using the install script, the path will be `~/avalanche-node/plugins` Instead of the `subnet-evm` filename, VM binary needs to be named as the VM ID of the chain on the Avalanche L1. For example, for the [WAGMI Avalanche L1](https://subnets-test.avax.network/wagmi) that VM ID is `srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy`. So, the command to copy the new plugin binary would look like:
+This will unpack and place the contents of the archive in the current directory, file `subnet-evm` is the plugin binary. You need to stop the node now (if the node is running as a service, use `sudo systemctl stop avalanchego` command). You need to place that file into the plugins directory where the AvalancheGo binary is located. If the node is installed using the install script, the path will be `~/avalanche-node/plugins` Instead of the `subnet-evm` filename, VM binary needs to be named as the VM ID of the chain on the Avalanche L1. For example, for the [WAGMI Avalanche L1](/docs/avalanche-l1s/wagmi-avalanche-l1) that VM ID is `srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy`. So, the command to copy the new plugin binary would look like:
 
 ```bash
 cp subnet-evm ~/avalanche-node/plugins/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy

content/docs/avalanche-l1s/upgrade/customize-avalanche-l1.mdx

@@ -744,7 +744,7 @@ By default, up to 32 transactions from priority addresses (max 16 per address) a
 
 ### Fee Recipient[​](#fee-recipient "Direct link to heading")
 
-This works together with [`allowFeeRecipients`](#setting-a-custom-fee-recipient) and [RewardManager precompile](#changing-fee-reward-mechanisms) to specify where the fees should be sent to.
+This works together with [`allowFeeRecipients`](#setting-a-custom-fee-recipient) and [RewardManager precompile](/docs/avalanche-l1s/evm-configuration/transaction-fees#reward-manager) to specify where the fees should be sent to.
 
 With `allowFeeRecipients` enabled, validators can specify their addresses to collect fees.
 

content/docs/avalanche-l1s/upgrade/durango-upgrade.mdx

@@ -38,9 +38,9 @@ Subnet-EVM Native Precompiles will start emitting events with the Durango networ
 
 ### Custom Events[​](#custom-events "Direct link to heading")
 
-Events above are already introduced and handled in Subnet-EVM native precompiles. If you have a custom precompile, you can start emitting your custom events using Durango activation. In order to do this you can define your custom event in your solidity interface and regenerate the go bindings using `precompilegen` tool, for more information see [here](/docs/virtual-machines/evm-customization/generating-your-precompile).
+Events above are already introduced and handled in Subnet-EVM native precompiles. If you have a custom precompile, you can start emitting your custom events using Durango activation. In order to do this you can define your custom event in your solidity interface and regenerate the go bindings using `precompilegen` tool, for more information see [here](/docs/virtual-machines/custom-precompiles/create-precompile).
 
-Generally you will generate an `event.go` file in addition to your existing precompile files. You need to implement how to emit your events and your events' gas costs, as in [hello world example](/docs/virtual-machines/evm-customization/defining-precompile#event-file). In this guide we will use the hello world example to demonstrate how to emit custom events. The event that will be introduced is:
+Generally you will generate an `event.go` file in addition to your existing precompile files. You need to implement how to emit your events and your events' gas costs, as in [hello world example](/docs/virtual-machines/custom-precompiles/defining-precompile#event-file). In this guide we will use the hello world example to demonstrate how to emit custom events. The event that will be introduced is:
 
 ```go
 event GreetingChanged(address indexed sender, string oldGreeting, string newGreeting)

content/docs/avalanche-l1s/validator-manager/remove-validator.mdx

@@ -5,7 +5,7 @@ description: Learn how to remove validators from your Avalanche L1 blockchain.
 
 ### Remove a Validator
 
-Validator exit is initiated with a call to `initializeEndValidation` on the `ValidatorManager`. Only the validator owner may initiate exit. For `PoSValidatorManagers` a `ValidationUptimeMessage` Warp message may optionally be provided in order to calculate the staking rewards; otherwise the latest received uptime will be used (see [(PoS only) Submit an Uptime Proof](#pos-only-submit-an-uptime-proof)). This proof may be requested directly from the L1 validators, which will provide it in a `ValidationUptimeMessage` Warp message. If the uptime is not sufficient to earn validation rewards, the call to `initializeEndValidation` will fail. `forceInitializeEndValidation` acts the same as `initializeEndValidation`, but bypasses the uptime-based rewards check. Once `initializeEndValidation` or `forceInitializeEndValidation` is called, staking rewards cease accruing for `PoSValidatorManagers`.
+Validator exit is initiated with a call to `initializeEndValidation` on the `ValidatorManager`. Only the validator owner may initiate exit. For `PoSValidatorManagers` a `ValidationUptimeMessage` Warp message may optionally be provided in order to calculate the staking rewards; otherwise the latest received uptime will be used (see [(PoS only) Submit an Uptime Proof](/docs/avalanche-l1s/validator-manager/contract#pos-only-submit-an-uptime-proof)). This proof may be requested directly from the L1 validators, which will provide it in a `ValidationUptimeMessage` Warp message. If the uptime is not sufficient to earn validation rewards, the call to `initializeEndValidation` will fail. `forceInitializeEndValidation` acts the same as `initializeEndValidation`, but bypasses the uptime-based rewards check. Once `initializeEndValidation` or `forceInitializeEndValidation` is called, staking rewards cease accruing for `PoSValidatorManagers`.
 
 The `ValidatorManager` constructs an `L1ValidatorWeightMessage` Warp message with the weight set to `0`. This is delivered to the P-Chain as the payload of a `SetL1ValidatorWeightTx`. The P-Chain acknowledges the validator exit by signing an `L1ValidatorRegistrationMessage` with `valid=0`, which is delivered to the `ValidatorManager` by calling `completeEndValidation`. The validation is removed from the contract's state, and for `PoSValidatorManagers`, staking rewards are disbursed and stake is returned.
 
@@ -18,7 +18,7 @@ Disabled L1 validators can re-activate at any time by increasing their balance w
 
 ### (PoS only) Remove a Delegator
 
-Delegators removal may be initiated by calling `initializeEndDelegation`, as long as churn restrictions are not violated. Similar to `initializeEndValidation`, an uptime proof may be provided to be used to determine delegator rewards eligibility. If no proof is provided, the latest known uptime will be used (see [(PoS only) Submit an Uptime Proof](#pos-only-submit-an-uptime-proof)). The validator's weight is updated on the P-Chain by the same mechanism used to register a delegator. The `L1ValidatorWeightMessage` from the P-Chain is delivered to the `PoSValidatorManager` in the call to `completeEndDelegation`.
+Delegators removal may be initiated by calling `initializeEndDelegation`, as long as churn restrictions are not violated. Similar to `initializeEndValidation`, an uptime proof may be provided to be used to determine delegator rewards eligibility. If no proof is provided, the latest known uptime will be used (see [(PoS only) Submit an Uptime Proof](/docs/avalanche-l1s/validator-manager/contract#pos-only-submit-an-uptime-proof)). The validator's weight is updated on the P-Chain by the same mechanism used to register a delegator. The `L1ValidatorWeightMessage` from the P-Chain is delivered to the `PoSValidatorManager` in the call to `completeEndDelegation`.
 
 Either the delegator owner or the validator owner may initiate removing a delegator. This is to prevent the validator from being unable to remove itself due to churn limitations if it has too high a proportion of the Subnet's total weight due to delegator additions. The validator owner may only remove Delegators after the minimum stake duration has elapsed.
 

content/docs/cross-chain/teleporter/teleporter-on-devnet.mdx

@@ -9,7 +9,7 @@ For more information on cross chain messaging through Teleporter and Warp, check
 
 - [Cross Chain References](/docs/cross-chain)
 
-Note that currently only [Subnet-EVM](https://github.com/ava-labs/subnet-evm) and [Subnet-EVM-Based](/docs/virtual-machines/evm-customization/introduction) virtual machines support Teleporter.
+Note that currently only [Subnet-EVM](https://github.com/ava-labs/subnet-evm) and [Subnet-EVM-Based](/docs/virtual-machines/evm-l1-customization) virtual machines support Teleporter.
 
 ## Prerequisites
 
@@ -70,7 +70,7 @@ Notice some details here:
 
 - Two smart contracts are deployed to the Avalanche L1: Teleporter Messenger and Teleporter Registry
 - Both Teleporter smart contracts are also deployed to `C-Chain`
-- [AWM Teleporter Relayer](https://github.com/ava-labs/awm-relayer) is installed and configured as a service into one of the nodes (A Relayer [listens](/docs/cross-chain/teleporter/overview#data-flow) for new messages being generated on a source Avalanche L1 and sends them to the destination Avalanche L1.)
+- [AWM Teleporter Relayer](https://github.com/ava-labs/icm-services/tree/main/relayer is installed and configured as a service into one of the nodes (A Relayer [listens](/docs/cross-chain/teleporter/overview#data-flow) for new messages being generated on a source Avalanche L1 and sends them to the destination Avalanche L1.)
 
 CLI configures the Relayer to enable every Avalanche L1 to send messages to all other Avalanche L1s. If you add more Avalanche L1s to the Devnet, the Relayer will be automatically reconfigured.
 

content/docs/cross-chain/teleporter/teleporter-on-local-network.mdx

@@ -6,11 +6,11 @@ This how-to guide focuses on deploying Teleporter-enabled Avalanche L1s to a loc
 
 After this tutorial, you would have created and deployed two Avalanche L1s to the local network and have enabled them to cross-communicate with each other and with the local C-Chain (through Teleporter and the underlying Warp technology.)
 
-Note that currently only [Subnet-EVM](https://github.com/ava-labs/subnet-evm) and [Subnet-EVM-Based](/docs/virtual-machines/evm-customization/introduction) virtual machines support Teleporter.
+Note that currently only [Subnet-EVM](https://github.com/ava-labs/subnet-evm) and [Subnet-EVM-Based](/docs/virtual-machines/evm-l1-customization) virtual machines support Teleporter.
 
 ## Prerequisites
 
-- [Avalanche-CLI installed](/docs/tooling/guides/get-avalanche-cli)
+- [Avalanche-CLI installed](/docs/tooling/get-avalanche-cli)
 
 ## Create Avalanche L1 Configurations
 
@@ -100,7 +100,7 @@ Notice some details here:
 
 - Two smart contracts are deployed to each Avalanche L1: Teleporter Messenger and Teleporter Registry
 - Both Teleporter smart contracts are also deployed to `C-Chain` in the Local Network
-- [AWM Teleporter Relayer](https://github.com/ava-labs/awm-relayer) is installed, configured and executed in background (A Relayer [listens](/docs/cross-chain/teleporter/overview#data-flow) for new messages being generated on a source Avalanche L1 and sends them to the destination Avalanche L1.)
+- [AWM Teleporter Relayer](https://github.com/ava-labs/icm-services/tree/main/relayer) is installed, configured and executed in background (A Relayer [listens](/docs/cross-chain/teleporter/overview#data-flow) for new messages being generated on a source Avalanche L1 and sends them to the destination Avalanche L1.)
 
 CLI configures the Relayer to enable every Avalanche L1 to send messages to all other Avalanche L1s. If you add more Avalanche L1s, the Relayer will be automatically reconfigured.
 

content/docs/dapps/advanced-tutorials/exchange-integration.mdx

@@ -10,12 +10,12 @@ integrate with the EVM-Compatible Avalanche C-Chain.
 
 For teams that already
 support ETH, supporting the C-Chain is as straightforward as spinning up an
-Avalanche node (which has the [same API](https://eth.wiki/json-rpc/API) as
+Avalanche node (which has the [same API](https://ethereum.org/en/developers/docs/apis/json-rpc/) as
 [`go-ethereum`](https://geth.ethereum.org/docs/rpc/server)) and populating
 Avalanche's ChainID (43114) when constructing transactions.
 
 Additionally, Ava Labs maintains an implementation of the [Rosetta
-API](https://www.rosetta-api.org/) for the C-Chain called
+API](https://docs.cdp.coinbase.com/mesh/docs/welcome) for the C-Chain called
 [avalanche-rosetta](https://github.com/ava-labs/avalanche-rosetta). You can
 learn more about this standardized integration path on the attached Rosetta API
 website.
@@ -93,13 +93,13 @@ above config example.
 
 ## Integration Using Rosetta
 
-[Rosetta](https://www.rosetta-api.org/) is an open-source specification and set
+[Rosetta](https://docs.cdp.coinbase.com/mesh/docs/welcome) is an open-source specification and set
 of tools that makes integrating with different blockchain networks easier by
 presenting the same set of APIs for every network. The Rosetta API is made up of
 2 core components, the [Data
-API](https://www.rosetta-api.org/docs/data_api_introduction.html) and the
+API](https://docs.cdp.coinbase.com/mesh/docs/api-data) and the
 [Construction
-API](https://www.rosetta-api.org/docs/construction_api_introduction.html).
+API](https://docs.cdp.coinbase.com/mesh/docs/api-construction).
 
 Together, these APIs allow for anyone to read and write to blockchains in a
 standard format over a standard communication protocol. The specifications for