smartcontractkit · khadni · Dec 12, 2025 · Dec 12, 2025 · Dec 12, 2025 · Dec 12, 2025
@@ -135,6 +135,8 @@ jobs:
   linkcheck-internal:
     needs: setup
     runs-on: ubuntu-latest
+    permissions:
+      contents: read
     steps:
       - name: Checkout Repo
         uses: actions/checkout@v6
@@ -159,9 +161,20 @@ jobs:
             echo "node_modules not found, installing dependencies..."
             npm ci --prefer-offline --no-audit
           fi
+
+      - name: Build Site
+        run: npm run build
 
       - name: Check Internal Links
-        run: npm run linkcheck-internal
+        uses: lycheeverse/lychee-action@a8c4c7cb88f0c7386610c35eb25108e448569cb0 # v2.7.0
+        with:
+          args: >-
+            --root-dir $GITHUB_WORKSPACE/.vercel/output/static
+            --config lychee.toml
+            '.vercel/output/static/**/*.html'
+          fail: true
+          format: markdown
+          jobSummary: true
 
   # Job 4: Check Types
   typecheck:

@@ -0,0 +1,41 @@
+# Lychee Link Checker Configuration
+# https://lychee.cli.rs/
+
+# Only check local files (no network requests)
+offline = true
+
+# Check links in code blocks
+include_verbatim = true
+
+# Don't show progress bar (better for CI)
+no_progress = true
+
+# Patterns to exclude from link checking
+exclude = [
+    # CSS files
+    'assets/.*\.css$',
+    '_astro/.*\.css$',
+
+    # Dynamic pages with query params
+    '/ccip/directory/.*',
+    '/data-feeds/price-feeds/addresses\?.*',
+    '/data-feeds/smartdata/addresses\?.*',
+
+    # Other files
+    'sitemap-index\.xml',
+    '@vite/client',
+
+    # Database connection strings
+    'postgresql:',
+    'mysql:',
+]
+
+# Paths to exclude from scanning (won't check links on these pages)
+exclude_path = [
+    'ccip/api-reference/evm/v162/.*',
+    'ccip/api-reference/evm/v163/.*',
+]
+
+# TODO: Re-enable fragment checking once Astro slug generation compatibility is resolved
+# include_fragments = true
+# Astro's heading ID generation and lychee's GitHub-style kebab-case expectations
@@ -183,7 +183,7 @@ go mod tidy
 <Aside type="note" title="Funding Your Account">
   This step submits an onchain transaction, which requires gas. Before running the simulation, verify that the account
   associated with the private key from [Part
-  1](/cre/getting-started/part-1-project-setup#step-3-configure-the-environment) is funded with sufficient Sepolia ETH.
+  1](/cre/getting-started/part-1-project-setup-go#set-up-your-private-key) is funded with sufficient Sepolia ETH.
   An unfunded account will cause the transaction to fail, often with an error message like `gas required exceeds
   allowance`.
   <br/>

@@ -184,7 +184,7 @@ These helpers are great for production code, but we use the explicit approach he
 <Aside type="note" title="Funding Your Account">
   This step submits an onchain transaction, which requires gas. Before running the simulation, verify that the account
   associated with the private key from [Part
-  1](/cre/getting-started/part-1-project-setup#step-3-configure-your-workflow) is funded with sufficient Sepolia ETH.
+  1](/cre/getting-started/part-1-project-setup-ts#set-up-your-private-key) is funded with sufficient Sepolia ETH.
   An unfunded account will cause the transaction to fail, often with an error message like `gas required exceeds
   allowance`.
   <br/>

@@ -258,7 +258,7 @@ By default, `cre workflow simulate` performs a dry run without broadcasting tran
 cre workflow simulate my-workflow --broadcast --target staging-settings
 ```
 
-See the [CLI Reference](/cre/reference/cli#cre-workflow-simulate) for more details.
+See the [CLI Reference](/cre/reference/cli/workflow#cre-workflow-simulate) for more details.
 
 ## Troubleshooting
 

@@ -17,7 +17,7 @@ The `http.Client` is the SDK's interface for the underlying [HTTP Capability](/c
 All HTTP requests are wrapped in a consensus mechanism to provide a single, reliable result. The SDK provides two ways to do this:
 
 - **[`http.SendRequest`](#1-the-httpsendrequest-pattern-recommended):** (Recommended) A high-level helper function that simplifies making requests.
-- **[`cre.RunInNodeMode`](#2-the-cre-runinnodemode-pattern-low-level):** The lower-level pattern for more complex scenarios.
+- **[`cre.RunInNodeMode`](#2-the-creruninnodemode-pattern-low-level):** The lower-level pattern for more complex scenarios.
 
 ## Prerequisites
 

@@ -124,7 +124,7 @@ Here are common patterns for formatting reports. Choose the one that matches you
 | Pattern                                                                                                 | When to use                                               |
 | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
 | [**Pattern 1: Report in body**](#pattern-1-report-in-body-simplest)                                     | Your API accepts raw binary data and handles decoding     |
-| [**Pattern 2: Report + signatures in body**](#pattern-2-report-signatures-in-body)                      | Your API needs everything concatenated in one binary blob |
+| [**Pattern 2: Report + signatures in body**](#pattern-2-report--signatures-in-body)                     | Your API needs everything concatenated in one binary blob |
 | [**Pattern 3: Report in body, signatures in headers**](#pattern-3-report-in-body-signatures-in-headers) | Your API needs signatures separated for easier parsing    |
 | [**Pattern 4: JSON-formatted report**](#pattern-4-json-formatted-report)                                | Your API only accepts JSON payloads                       |
 

@@ -126,7 +126,7 @@ Here are common patterns for formatting reports. Choose the one that matches you
 | Pattern                                                                                                 | When to use                                               |
 | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
 | [**Pattern 1: Report in body**](#pattern-1-report-in-body-simplest)                                     | Your API accepts raw binary data and handles decoding     |
-| [**Pattern 2: Report + signatures in body**](#pattern-2-report-signatures-in-body)                      | Your API needs everything concatenated in one binary blob |
+| [**Pattern 2: Report + signatures in body**](#pattern-2-report--signatures-in-body)                     | Your API needs everything concatenated in one binary blob |
 | [**Pattern 3: Report in body, signatures in headers**](#pattern-3-report-in-body-signatures-in-headers) | Your API needs signatures separated for easier parsing    |
 | [**Pattern 4: JSON-formatted report**](#pattern-4-json-formatted-report)                                | Your API only accepts JSON payloads                       |
 

@@ -20,8 +20,8 @@ This is a generic interface passed as the final argument to `cre.RunInNodeMode`.
 
 There are two primary ways to specify an aggregation method:
 
-1. [**Using Built-in Functions**](/cre/reference/sdk/consensus-go/#1-built-in-aggregation-functions): For simple types, you can use functions like [`ConsensusMedianAggregation`](/cre/reference/sdk/consensus/#consensusmedianaggregationt).
-1. [**Using Struct Tags**](/cre/reference/sdk/consensus-go/#2-aggregation-via-struct-tags): For complex types (structs), you can use [`ConsensusAggregationFromTags`](/cre/reference/sdk/consensus/#aggregation-via-struct-tags).
+1. [**Using Built-in Functions**](/cre/reference/sdk/consensus-go/#1-built-in-aggregation-functions): For simple types, you can use functions like [`ConsensusMedianAggregation`](/cre/reference/sdk/consensus-go#consensusmedianaggregationt).
+1. [**Using Struct Tags**](/cre/reference/sdk/consensus-go/#2-aggregation-via-struct-tags): For complex types (structs), you can use [`ConsensusAggregationFromTags`](/cre/reference/sdk/consensus-go#2-aggregation-via-struct-tags).
 
 ## 1. Built-in aggregation functions
 

@@ -21,7 +21,7 @@ This is a generic type passed as the second argument to `runtime.runInNodeMode()
 There are two primary ways to specify an aggregation method:
 
 1. [**Using built-in functions**](/cre/reference/sdk/consensus-ts#1-built-in-aggregation-functions): For simple types, use functions like [`consensusMedianAggregation()`](#consensusmedianaggregationt).
-1. [**Using field-based aggregation**](/cre/reference/sdk/consensus-ts#2-field-based-aggregation-for-objects): For complex types (objects), use [`ConsensusAggregationByFields()`](#consensusaggregationbyfields).
+1. [**Using field-based aggregation**](/cre/reference/sdk/consensus-ts#2-field-based-aggregation-for-objects): For complex types (objects), use [`ConsensusAggregationByFields()`](#consensusaggregationbyfieldstfields).
 
 ## 1. Built-in aggregation functions
 

@@ -50,7 +50,7 @@ These interfaces provide access to capabilities and manage the execution context
 
 - **`cre.Runtime` ("Easy Mode")**: Passed to your main trigger callback, this represents the **DON's (Decentralized Oracle Network) execution context**. It is used for operations that are already guaranteed to be Byzantine Fault Tolerant (BFT). When you use the `Runtime`, you ask the network to execute something, and CRE handles the underlying complexity to ensure you get back one final, secure, and trustworthy result. A common use case is writing a transaction to a blockchain with the EVM client.
 
-- **`cre.NodeRuntime` ("Manual Mode")**: Represents an **individual node's execution context**. This is used when a BFT guarantee cannot be provided automatically (e.g., calling a third-party API). You tell each node to perform a task on its own, and each node returns its own individual answer. You are then responsible for telling the SDK how to combine them into a single, trusted result by providing a consensus and aggregation algorithm. It is used exclusively inside a [`RunInNodeMode`](#sdkruninnodemode) block and is provided by that function—you do not get this type directly in your handler's callback.
+- **`cre.NodeRuntime` ("Manual Mode")**: Represents an **individual node's execution context**. This is used when a BFT guarantee cannot be provided automatically (e.g., calling a third-party API). You tell each node to perform a task on its own, and each node returns its own individual answer. You are then responsible for telling the SDK how to combine them into a single, trusted result by providing a consensus and aggregation algorithm. It is used exclusively inside a [`RunInNodeMode`](#creruninnodemode) block and is provided by that function—you do not get this type directly in your handler's callback.
 
 To learn more about how to aggregate results from `NodeRuntime`, see the [Consensus & Aggregation](/cre/reference/sdk/consensus) reference.
 

@@ -132,7 +132,7 @@ Now you are ready to compile and run the workflow. The workflow code (`workflow.
    <Aside type="note" title="Onchain Writes are Dry Runs by Default">
      The `--broadcast` flag is included here because this workflow performs an onchain write. By default, the `simulate`
      command performs a dry run and will not broadcast the transaction without this flag. For more details, see the `cre
-     workflow simulate` [reference](/cre/reference/cli#cre-workflow-simulate).
+     workflow simulate` [reference](/cre/reference/cli/workflow#cre-workflow-simulate).
    </Aside>
 
    You will first see a `Workflow compiled` message, followed by the trigger selection menu.

@@ -123,7 +123,7 @@ Now you are ready to compile and run the workflow. The single `main.ts` file you
    <Aside type="note" title="Onchain Writes are Dry Runs by Default">
      The `--broadcast` flag is included here because this workflow performs an onchain write. By default, the `simulate`
      command performs a dry run and will not broadcast the transaction without this flag. For more details, see the `cre
-     workflow simulate` [reference](/cre/reference/cli#cre-workflow-simulate).
+     workflow simulate` [reference](/cre/reference/cli/workflow#cre-workflow-simulate).
    </Aside>
 
    You will first see a `Workflow compiled` message, followed by the trigger selection menu.

@@ -44,7 +44,7 @@ starkli --version
 0.2.8 (f59724e)
 ```
 
-Follow the official [installation guide](<(https://book.starkli.rs/installation)>) if necessary.
+Follow the official [installation guide](https://book.starkli.rs/installation) if necessary.
 
 ### Read data from a Chainlink Price Feed
 

@@ -23,7 +23,7 @@ The table below lists all networks supported by Data Streams, each with verifier
 
 ## Streams Trade implementation (Onchain Lookup)
 
-[Streams Trade](streams-trade), the alternative implementation, allows smart contracts to access Data Streams onchain using the [`StreamsLookup`](/data-streams/getting-started) capability integrated with [Chainlink Automation](/chainlink-automation).
+[Streams Trade](/data-streams/streams-trade), the alternative implementation, allows smart contracts to access Data Streams onchain using the [`StreamsLookup`](/data-streams/getting-started) capability integrated with [Chainlink Automation](/chainlink-automation).
 
 Streams Trade is currently available on the following networks:
 

@@ -177,7 +177,7 @@ You'll start with the set up of your Rust project, installing the SDK and pastin
     ).build()?;
     ```
 
-    This configuration also specifies the `rest_url`, which is the base URL for the API, along with the WebSocket endpoint [for subscribing to a streamed data report](rust-sdk-stream). In this example, both are set to the testnet URLs for Data Streams.
+    This configuration also specifies the `rest_url`, which is the base URL for the API, along with the WebSocket endpoint [for subscribing to a streamed data report](/data-streams/tutorials/rust-sdk-stream). In this example, both are set to the testnet URLs for Data Streams.
 
     See the [Rust SDK Reference](/data-streams/reference/data-streams-api/rust-sdk#configuration-reference) page for more configuration options.
 

@@ -231,7 +231,7 @@ In this tutorial, you'll learn how to use the [Data Streams SDK](/data-streams/r
    ).build()?;
    ```
 
-   This configuration also specifies the `rest_url`, which is the base URL for the API, along with the WebSocket endpoint [for subscribing to a streamed data report](rust-sdk-stream). In this example, both are set to the testnet URLs for Data Streams.
+   This configuration also specifies the `rest_url`, which is the base URL for the API, along with the WebSocket endpoint for subscribing to a streamed data report. In this example, both are set to the testnet URLs for Data Streams.
 
    See the [Rust SDK Reference](/data-streams/reference/data-streams-api/rust-sdk#configuration-reference) page for more configuration options.
 

@@ -62,7 +62,7 @@ Your _deployer account_ is the main account that you will use to deploy the loot
 - Ensure the deployer account owns all the assets you wish to distribute as rewards.
 - To deploy this contract on testnets, ensure the deployer account has testnet LINK and testnet ETH (Sepolia). Use the [LINK faucet](https://faucets.chain.link/) to retrieve 20 testnet LINK and 0.1 Sepolia ETH.
 - Ensure the deployer account has enough LINK to fund the [VRF subscription](/vrf/v2/subscription). If you don't already have a VRF subscription, the deployment script will create and fund one for you.
-  - [Estimate the minimum subscription balance](/vrf/v2/estimating-costs#estimate-minimum-subscription-balance) that VRF requires to process your randomness request. The minimum subscription balance provides a buffer against gas volatility, and only the actual cost of your request will be deducted from your account. If your subscription is underfunded, your VRF request will be [pending](/vrf/v2/subscription/ui#pending) for 24 hours. If that happens, check the [Subscription Manager](https://vrf.chain.link]) to see the additional balance needed.
+  - [Estimate the minimum subscription balance](/vrf/v2/estimating-costs#estimate-minimum-subscription-balance) that VRF requires to process your randomness request. The minimum subscription balance provides a buffer against gas volatility, and only the actual cost of your request will be deducted from your account. If your subscription is underfunded, your VRF request will be [pending](/vrf/v2/subscription/ui#pending) for 24 hours. If that happens, check the [Subscription Manager](https://vrf.chain.link) to see the additional balance needed.
   - The initial funding amount is set to 10 LINK. Optionally, you can modify the initial funding amount in [`network-config.ts`](https://github.com/smartcontractkit/quickstarts-lootbox/blob/main/network-config.ts).
 
 - [Create a second account in your MetaMask wallet](https://support.metamask.io/hc/en-us/articles/360015289452-How-to-create-an-additional-account-in-your-wallet). This account is called the _receiving account_ in this tutorial, and its address is called the _opener address_. You will use this receiving account to open a test lootbox and receive the rewards as a user. [Configure the account](https://support.metamask.io/hc/en-us/articles/360015489031-How-to-display-tokens-in-MetaMask) to display the rewards that you want to distribute from the lootbox.
@@ -236,7 +236,7 @@ The [deploy script](https://github.com/smartcontractkit/quickstarts-lootbox/blob
 
     [Estimate the minimum subscription balance](/vrf/v2/estimating-costs#estimate-minimum-subscription-balance) that VRF requires to process your randomness request. The minimum subscription balance provides a buffer against gas volatility, and only the actual cost of your request will be deducted from your account.
 
-    If your subscription is underfunded, your VRF request will be [pending](/vrf/v2/subscription/ui#pending) for 24 hours. If this happens, check the [Subscription Manager](https://vrf.chain.link]) to see the additional balance needed.
+    If your subscription is underfunded, your VRF request will be [pending](/vrf/v2/subscription/ui#pending) for 24 hours. If this happens, check the [Subscription Manager](https://vrf.chain.link) to see the additional balance needed.
 
     </Aside>