sync: coreth PR #1392: chore: Add lint link check job

.github/CONTRIBUTING.md

@@ -1,50 +1,47 @@
 # Contributing
 
-Thank you for considering to help out with the source code! We welcome
-contributions from anyone on the internet, and are grateful for even the
-smallest of fixes!
-
-If you'd like to contribute to subnet-evm, please fork, fix, commit and send a
-pull request for the maintainers to review and merge into the main code base. If
-you wish to submit more complex changes though, please check up with the core
-devs first on [Discord](https://chat.avalabs.org) to
-ensure those changes are in line with the general philosophy of the project
-and/or get some early feedback which can make both your efforts much lighter as
-well as our review and merge procedures quick and simple.
+Thank you for considering to help out with the source code! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes!
+
+If you'd like to contribute to subnet-evm, please fork, fix, commit and send a pull request for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check up with the core devs first on [Discord](https://chat.avalabs.org) to ensure those changes are in line with the general philosophy of the project and/or get some early feedback which can make both your efforts much lighter as well as our review and merge procedures quick and simple.
 
 ## Coding guidelines
 
-Please make sure your contributions adhere to our coding and documentation
-guidelines:
+Please make sure your contributions adhere to our coding guidelines:
 
 - Code must adhere to the official Go
   [formatting](https://go.dev/doc/effective_go#formatting) guidelines
   (i.e. uses [gofmt](https://pkg.go.dev/cmd/gofmt)).
+- Code must be documented adhering to the official Go
+  [commentary](https://go.dev/doc/effective_go#commentary) guidelines.
 - Pull requests need to be based on and opened against the `master` branch.
 - Pull reuqests should include a detailed description
-- Commits are required to be signed. See [here](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
+- Commits are required to be signed. See the [commit signature verification documentation](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
   for information on signing commits.
 - Commit messages should be prefixed with the package(s) they modify.
   - E.g. "eth, rpc: make trace configs optional"
 
-### Mocks
+## Can I have feature X
+
+Before you submit a feature request, please check and make sure that it isn't possible through some other means.
+
+## Mocks
 
 Mocks are auto-generated using [mockgen](https://pkg.go.dev/go.uber.org/mock/mockgen) and `//go:generate` commands in the code.
 
-- To **re-generate all mocks**, use the command below from the root of the project:
+- To **re-generate all mocks**, use the task below from the root of the project:
 
-    ```sh
-    go generate -run mockgen ./...
-    ```
+  ```sh
+  task generate-mocks
+  ```
 
-* To **add** an interface that needs a corresponding mock generated:
-  * if the file `mocks_generate_test.go` exists in the package where the interface is located, either:
-    * modify its `//go:generate go tool -modfile=tools/go.mod mockgen` to generate a mock for your interface (preferred); or
-    * add another `//go:generate go tool -modfile=tools/go.mod mockgen` to generate a mock for your interface according to specific mock generation settings
-  * if the file `mocks_generate_test.go` does not exist in the package where the interface is located, create it with content (adapt as needed):
+- To **add** an interface that needs a corresponding mock generated:
+  - if the file `mocks_generate_test.go` exists in the package where the interface is located, either:
+    - modify its `//go:generate go tool -modfile=tools/go.mod mockgen` to generate a mock for your interface (preferred); or
+    - add another `//go:generate go tool -modfile=tools/go.mod mockgen` to generate a mock for your interface according to specific mock generation settings
+  - if the file `mocks_generate_test.go` does not exist in the package where the interface is located, create it with content (adapt as needed):
 
     ```go
-    // Copyright (C) 2019-2025, Ava Labs, Inc. All rights reserved.
+    // Copyright (C) 2025-2025, Ava Labs, Inc. All rights reserved.
     // See the file LICENSE for licensing terms.
 
     package mypackage
@@ -58,26 +55,29 @@ Mocks are auto-generated using [mockgen](https://pkg.go.dev/go.uber.org/mock/moc
 - To **remove** an interface from having a corresponding mock generated:
   1. Edit the `mocks_generate_test.go` file in the directory where the interface is defined
   1. If the `//go:generate` mockgen command line:
-      * generates a mock file for multiple interfaces, remove your interface from the line
-      * generates a mock file only for the interface, remove the entire line. If the file is empty, remove `mocks_generate_test.go` as well.
+      - generates a mock file for multiple interfaces, remove your interface from the line
+      - generates a mock file only for the interface, remove the entire line. If the file is empty, remove `mocks_generate_test.go` as well.
 
 ## Tool Dependencies
 
 This project uses `go tool` to manage development tool dependencies in `tools/go.mod`. This isolates tool dependencies from the main application dependencies and provides consistent, version-locked tools across the team.
 
 ### Managing Tools
 
-* To **add a new tool**:
+- To **add a new tool**:
+
   ```sh
   go get -tool -modfile=tools/go.mod example.com/tool/cmd/toolname@version
   ```
 
-* To **upgrade a tool**:
+- To **upgrade a tool**:
+
   ```sh
   go get -tool -modfile=tools/go.mod example.com/tool/cmd/toolname@newversion
   ```
 
-* To **run a tool manually**:
+- To **run a tool manually**:
+
   ```sh
   go tool -modfile=tools/go.mod toolname [args...]
   ```

.github/ISSUE_TEMPLATE/bug_report.md

@@ -31,4 +31,4 @@ Which OS you used to reveal the bug.
 **Additional context**
 Add any other context about the problem here.
 
-Avalanche Bug Bounty program can be found [here](https://immunefi.com/bug-bounty/avalanche/information/).
+You can submit a bug on the [Avalanche Bug Bounty program page](https://hackenproof.com/avalanche/avalanche-protocol).

.github/ISSUE_TEMPLATE/feature_spec.md

@@ -16,4 +16,4 @@ Include a description of the changes to be made to the code along with alternati
 that were considered, including pro/con analysis where relevant.
 
 **Open questions**
-Questions that are still being discussed.
+Questions that are still being discussed

.github/pull_request_template.md

@@ -1,3 +1,4 @@
+<!-- markdownlint-disable MD041 -->
 ## Why this should be merged
 
 ## How this works

.github/workflows/ci.yml

@@ -35,6 +35,14 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: ./scripts/run_task.sh check-avalanchego-version
+  links-lint:
+    name: Markdown Links Lint
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: umbrelladocs/action-linkspector@de84085e0f51452a470558693d7d308fbb2fa261 #v1.2.5
+        with:
+          fail_level: any
 
   unit_test:
     name: Golang Unit Tests (${{ matrix.os }})

README.md

@@ -5,11 +5,11 @@
 [![CodeQL](https://github.com/ava-labs/subnet-evm/actions/workflows/codeql-analysis.yml/badge.svg)](https://github.com/ava-labs/subnet-evm/actions/workflows/codeql-analysis.yml)
 [![License](https://img.shields.io/github/license/ava-labs/subnet-evm)](https://github.com/ava-labs/subnet-evm/blob/master/LICENSE)
 
-[Avalanche](https://docs.avax.network/avalanche-l1s) is a network composed of multiple blockchains.
+[Avalanche](https://build.avax.network/docs/avalanche-l1s) is a network composed of multiple blockchains.
 Each blockchain is an instance of a Virtual Machine (VM), much like an object in an object-oriented language is an instance of a class.
 That is, the VM defines the behavior of the blockchain.
 
-Subnet EVM is the [Virtual Machine (VM)](https://docs.avax.network/learn/virtual-machines) that defines the Subnet Contract Chains. Subnet EVM is a simplified version of [Coreth VM (C-Chain)](https://github.com/ava-labs/coreth).
+Subnet EVM is the [Virtual Machine (VM)](https://build.avax.network/docs/quick-start/virtual-machines) that defines the Subnet Contract Chains. Subnet EVM is a simplified version of [Coreth VM (C-Chain)](https://github.com/ava-labs/coreth).
 
 This chain implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality.
 
@@ -44,11 +44,11 @@ The Subnet EVM supports the following API namespaces:
 
 Only the `eth` namespace is enabled by default.
 Subnet EVM is a simplified version of [Coreth VM (C-Chain)](https://github.com/ava-labs/coreth).
-Full documentation for the C-Chain's API can be found [here](https://build.avax.network/docs/api-reference/c-chain/api).
+Full documentation for the C-Chain's API can be found in the [builder docs](https://build.avax.network/docs/rpcs/c-chain).
 
 ## Compatibility
 
-The Subnet EVM is compatible with almost all Ethereum tooling, including [Remix](https://docs.avax.network/build/dapp/smart-contracts/remix-deploy), [Metamask](https://docs.avax.network/build/dapp/chain-settings), and [Foundry](https://docs.avax.network/build/dapp/smart-contracts/toolchains/foundry).
+Subnet-EVM is compatible with almost all Ethereum tooling, including [Foundry](https://build.avax.network/academy/blockchain/solidity-foundry/03-smart-contracts/03-foundry-quickstart) and [Remix](https://build.avax.network/docs/avalanche-l1s/add-utility/deploy-smart-contract#using-remix).
 
 **Note:** Subnet-EVM and Avalanche C-Chain currently implement the Ethereum Cancun fork and do not yet support newer hardforks (such as Pectra). Since Solidity v0.8.30 switched its default target EVM version to Pectra, contracts compiled with default settings may emit bytecode using instructions/features that Avalanche does not support.
 To avoid this mismatch, explicitly set the Solidity compiler’s `evmVersion` to `cancun` when deploying to Subnet-EVM or the C-Chain.
@@ -73,7 +73,7 @@ To support these changes, there have been a number of changes to the SubnetEVM b
 
 ### Clone Subnet-evm
 
-First install Go 1.24.9 or later. Follow the instructions [here](https://go.dev/doc/install). You can verify by running `go version`.
+First install Go 1.24.9 or later. Follow the instructions on the [go docs](https://go.dev/doc/install). You can verify by running `go version`.
 
 Set `$GOPATH` environment variable properly for Go to look for Go Workspaces. Please read [this](https://go.dev/doc/code) for details. You can verify by running `echo $GOPATH`.
 
@@ -97,8 +97,8 @@ To run a local network, it is recommended to use the [avalanche-cli](https://git
 
 There are two options when using the Avalanche-CLI:
 
-1. Use an official Subnet-EVM release: <https://docs.avax.network/subnets/build-first-subnet>
-2. Build and deploy a locally built (and optionally modified) version of Subnet-EVM: <https://docs.avax.network/subnets/create-custom-subnet>
+1. Use an official Subnet-EVM release: <https://build.avax.network/docs/tooling/avalanche-cli/create-avalanche-l1>
+1. Build and deploy a locally built (and optionally modified) version of Subnet-EVM: <https://build.avax.network/docs/tooling/avalanche-cli/create-deploy-avalanche-l1s/deploy-with-custom-vm>
 
 ## Releasing
 

RELEASES.md

@@ -1,3 +1,5 @@
+<!-- markdownlint-disable MD024 -->
+
 # Release Notes
 
 ## [v0.8.1](https://github.com/ava-labs/subnet-evm/releases/tag/v0.8.1)
@@ -201,7 +203,7 @@ The plugin version is unchanged at 37 and is compatible with AvalancheGo version
 - Added following new database options:
   - `"use-standalone-database"` (`bool`): If true it enables creation of standalone database. If false it uses the GRPC Database provided by AvalancheGo. Default is nil and creates the standalone database only if there is no accepted block in the AvalancheGo database (node has not accepted any blocks for this chain)
   - `"database-type"` (`string`): Specifies the type of database to use. Must be one of `pebbledb`, `leveldb` or `memdb`. memdb is an in-memory, non-persisted database. Default is `pebbledb`
-  - `"database-config-file"` (`string`): Path to the database config file. Config file is changed for every database type. See [docs](https://docs.avax.network/api-reference/avalanche-go-configs-flags#database-config) for available configs per database type. Ignored if --config-file-content is specified
+  - `"database-config-file"` (`string`): Path to the database config file. Config file is changed for every database type. See [docs](https://build.avax.network/docs/nodes/configure/configs-flags#database-config) for available configs per database type. Ignored if --config-file-content is specified
   - `"database-config-file-content"` (`string`): As an alternative to `database-config-file`, it allows specifying base64 encoded database config content
   - `"database-path"` (`string`): Specifies the directory to which the standalone database is persisted. Defaults to "`$HOME/.avalanchego/chainData/{chainID}`"
   - `"database-read-only"` (`bool`) : Specifies if the standalone database should be a read-only type. Defaults to false

SECURITY.md

@@ -5,14 +5,14 @@ responsible disclosures. Valid reports will be eligible for a reward (terms and
 
 ## Reporting a Vulnerability
 
-**Please do not file a public ticket** mentioning the vulnerability. To disclose a vulnerability submit it through our [Bug Bounty Program](https://immunefi.com/bug-bounty/avalanche/information/).
+**Please do not file a public ticket** mentioning the vulnerability. To disclose a vulnerability submit it through our [Bug Bounty Program](https://immunefi.com/bug-bounty/avalabs/information/).
 
 Vulnerabilities must be disclosed to us privately with reasonable time to respond, and avoid compromise of other users and accounts, or loss of funds that are not your own. We do not reward spam or
 social engineering vulnerabilities.
 
 Do not test for or validate any security issues in the live Avalanche networks (Mainnet and Fuji testnet), confirm all exploits in a local private testnet.
 
-Please refer to the [Bug Bounty Page](https://immunefi.com/bug-bounty/avalanche/information/) for the most up-to-date program rules and scope.
+Please refer to the [Bug Bounty Page](https://immunefi.com/bug-bounty/avalabs/information/) for the most up-to-date program rules and scope.
 
 ## Supported Versions
 

cmd/evm/README.md

@@ -622,4 +622,4 @@ There are many test cases in the [`cmd/evm/testdata`](./testdata) directory.
 These fixtures are used to power the `t8n` tests in
 [`t8n_test.go`](./t8n_test.go). The best way to verify correctness of new `evm`
 implementations is to execute these and verify the output and error codes match
-the expected values.
+the expected values.

cmd/precompilegen/template-readme.md

@@ -2,7 +2,7 @@ There are some must-be-done changes waiting in the generated file. Each area req
 Additionally there are other files you need to edit to activate your precompile.
 These areas are highlighted with comments "ADD YOUR PRECOMPILE HERE".
 For testing take a look at other precompile tests in contract_test.go and config_test.go in other precompile folders.
-See the tutorial in <https://docs.avax.network/subnets/hello-world-precompile-tutorial> for more information about precompile development.
+See the tutorial in <https://build.avax.network/academy/blockchain/solidity-foundry/04-hello-world-part-1/01-intro> for more information about precompile development.
 
 General guidelines for precompile development:
 

cmd/simulator/README.md

@@ -24,11 +24,11 @@ To confirm that you built successfully, run the simulator and print the version:
 
 This should give the following output:
 
-```
+```bash
 v0.1.0
 ```
 
-To run the load simulator, you must first start an EVM based network. The load simulator works on both the C-Chain and Subnet-EVM, so we will start a single node network and run the load simulator on the C-Chain.
+To run the load simulator, you must first start an EVM based network. The load simulator works on both the C-Chain and Subnet-EVM, so we will start a single node network and run the load simulator on a Subnet-EVM blockchain.
 
 To start a single node network, follow the instructions from the AvalancheGo [README](https://github.com/ava-labs/avalanchego#building-avalanchego) to build from source.
 
@@ -45,9 +45,9 @@ The `--sybil-protection-enabled=false` flag is only suitable for local testing.
 1. Ignore stake weight on the P-Chain and count each connected peer as having a stake weight of 1
 2. Automatically opts in to validate every Subnet
 
-Once you have AvalancheGo running locally, it will be running an HTTP Server on the default port `9650`. This means that the RPC Endpoint for the C-Chain will be http://127.0.0.1:9650/ext/bc/C/rpc and ws://127.0.0.1:9650/ext/bc/C/ws for WebSocket connections.
+Once you have AvalancheGo running locally, it will be running an HTTP Server on the default port `9650`. This means that the RPC Endpoint for your Subnet-EVM blockchain will be `http://127.0.0.1:9650/ext/bc/BLOCKCHAIN_ID/rpc` and `ws://127.0.0.1:9650/ext/bc/BLOCKCHAIN_ID/ws` for WebSocket connections, where `BLOCKCHAIN_ID` is the blockchain ID of your deployed Subnet-EVM instance.
 
-Now, we can run the simulator command to simulate some load on the local C-Chain for 30s:
+Now, we can run the simulator command to simulate some load on the local Subnet-EVM blockchain:
 
 ```bash
 ./simulator --timeout=1m --workers=1 --max-fee-cap=300 --max-tip-cap=10 --txs-per-worker=50