From bfe7bb373e5a8cfdc906cd6e75d7ce5ecca9494b Mon Sep 17 00:00:00 2001 From: devin distefano Date: Thu, 9 Apr 2026 15:23:48 -0500 Subject: [PATCH 1/2] ts verification + go break --- src/config/sidebar.ts | 4 + ...rkflows.mdx => verifying-workflows-go.mdx} | 14 +- .../operations/verifying-workflows-ts.mdx | 139 ++++++++++ src/content/cre/llms-full-go.txt | 222 ++++++++-------- src/content/cre/llms-full-ts.txt | 244 ++++++++++-------- 5 files changed, 392 insertions(+), 231 deletions(-) rename src/content/cre/guides/operations/{verifying-workflows.mdx => verifying-workflows-go.mdx} (95%) create mode 100644 src/content/cre/guides/operations/verifying-workflows-ts.mdx diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts index 0436ac0c4cf..97e571ce9cf 100644 --- a/src/config/sidebar.ts +++ b/src/config/sidebar.ts @@ -378,6 +378,10 @@ export const SIDEBAR: Partial> = { { title: "Verifying Workflows", url: "cre/guides/operations/verifying-workflows", + highlightAsCurrent: [ + "cre/guides/operations/verifying-workflows-ts", + "cre/guides/operations/verifying-workflows-go", + ], }, { title: "Deleting Workflows", diff --git a/src/content/cre/guides/operations/verifying-workflows.mdx b/src/content/cre/guides/operations/verifying-workflows-go.mdx similarity index 95% rename from src/content/cre/guides/operations/verifying-workflows.mdx rename to src/content/cre/guides/operations/verifying-workflows-go.mdx index b908234afef..cd1446b67db 100644 --- a/src/content/cre/guides/operations/verifying-workflows.mdx +++ b/src/content/cre/guides/operations/verifying-workflows-go.mdx @@ -2,10 +2,12 @@ section: cre date: Last Modified title: "Verifying Workflows" +sdkLang: "go" +pageId: "operations-verifying-workflows" metadata: description: "Learn how to verify workflow identity, validate workflows onchain in consumer contracts, and enable third-party verification using reproducible builds." datePublished: "2026-03-19" - lastModified: "2026-03-19" + lastModified: "2026-04-09" --- import { Aside } from "@components" @@ -63,12 +65,10 @@ Follow these practices to ensure only authorized workflows can interact with you ## Third-party verification - - Third-party verification allows customers or auditors to independently confirm that a deployed workflow matches its source code. The deployer shares the workflow source, and the verifier uses the CRE CLI to compute the workflow hash and compare it against the onchain workflow ID. +Go workflows are verifiable by default and do not require a template or Docker. + ### Steps for the workflow developer 1. **Add a `.env.public` file** to your workflow folder with `GOTOOLCHAIN` set to the Go toolchain version you use to build the workflow. Pinning that version helps reproducible builds across machines and environments. Add this file _before_ running `cre workflow deploy`. @@ -81,7 +81,7 @@ Third-party verification allows customers or auditors to independently confirm t Use the same toolchain string you build with; `go version` reports it (for example `go1.23.0 linux/amd64` → use `go1.23.0`). -2. **Share your workflow source** with the customer. Provide a zip archive or repository link that includes all workflow files, including `.env.public`. Exclude `.env` files that contain private keys or secrets. +2. **Share your workflow source** with the verifier. Provide a zip archive or repository link that includes all workflow files, including `.env.public`. Exclude `.env` files that contain private keys or secrets. ### Steps for the verifier @@ -92,7 +92,7 @@ Third-party verification allows customers or auditors to independently confirm t 3. **Run `cre workflow hash`** to compute the workflow hash: ```bash - cre workflow hash ./workflow-folder --public_key=0xYourDeployerAddress + cre workflow hash ./workflow-folder --public_key 0xYourDeployerAddress ``` Replace `./workflow-folder` with the path to the workflow source and `0xYourDeployerAddress` with the deployer's public address. diff --git a/src/content/cre/guides/operations/verifying-workflows-ts.mdx b/src/content/cre/guides/operations/verifying-workflows-ts.mdx new file mode 100644 index 00000000000..7df8ee41a3d --- /dev/null +++ b/src/content/cre/guides/operations/verifying-workflows-ts.mdx @@ -0,0 +1,139 @@ +--- +section: cre +date: Last Modified +title: "Verifying Workflows" +sdkLang: "ts" +pageId: "operations-verifying-workflows" +metadata: + description: "Learn how to verify workflow identity, validate workflows onchain in consumer contracts, and enable third-party verification using reproducible builds." + datePublished: "2026-03-19" + lastModified: "2026-04-09" +--- + +import { Aside } from "@components" + +Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. + +## Workflow ID + +The workflow ID is a unique hash that serves as the primary identifier for your workflow throughout its lifecycle. It is computed locally during [`cre workflow deploy`](/cre/reference/cli/workflow#cre-workflow-deploy) from the following inputs: + +- **workflowOwner**: The deployer's address +- **workflowName**: The name specified in your workflow +- **Compiled workflow binary**: The WASM binary produced from your workflow code +- **Config file contents**: The contents of your workflow's config file +- **Secrets hash**: An empty string placeholder for secrets + +Because the workflow ID is derived from these inputs, it deterministically represents a specific version of your workflow code and configuration. + + + +Use [`cre workflow hash`](/cre/reference/cli/workflow#cre-workflow-hash) to inspect the workflow ID before deploying. This lets you preview the ID without submitting an onchain transaction. + +For more details on deployment and updates, see [Deploying Workflows](/cre/guides/operations/deploying-workflows) and [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows). + +## Verifying workflows onchain + +When a workflow writes onchain, the consumer contract receives both the report data and metadata through the `onReport` callback. The metadata contains information you can use to verify the source of the report: + +- **`workflowId`** (`bytes32`): The unique workflow hash +- **`workflowName`** (`bytes10`): The workflow name, hash-encoded +- **`workflowOwner`** (`address`): The address that deployed the workflow + +See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) for the full `IReceiver` interface and metadata structure. + +### Workflow name encoding + +The `workflowName` in metadata is not stored as a plain string. It is a SHA256 hash of the workflow name, truncated to `bytes10`. See [how workflow names are encoded](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#how-workflow-names-are-encoded) for the full encoding process. + +### Security best practices + +Follow these practices to ensure only authorized workflows can interact with your consumer contract: + +- **Verify `msg.sender`**: Always check that `msg.sender` is the expected forwarder address. See the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory) for addresses by network. +- **Permission on workflow ID**: Use `setExpectedWorkflowId` from `ReceiverTemplate` to restrict which workflow can call your contract. + + + +## Third-party verification + +Third-party verification allows customers or auditors to independently confirm that a deployed workflow matches its source code. The deployer shares the workflow source, and the verifier uses the CRE CLI to compute the workflow hash and compare it against the onchain workflow ID. + +TypeScript workflows use Docker to produce reproducible builds. The same source always produces the same WASM binary hash because the build runs inside a pinned Docker image with a locked dependency tree. + +### Prerequisites + +- [CRE CLI](/cre/getting-started/cli-installation) installed +- [Docker Desktop](https://www.docker.com/products/docker-desktop/) running +- `make` available in your PATH (included with Xcode Command Line Tools on macOS; install via your package manager on Linux) + +### Steps for the workflow developer + +1. **Use the [`verifiable-build-ts` template](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/verifiable-build/verifiable-build-ts)** as the starting point for your workflow. This template includes the `Dockerfile`, `Makefile`, and `Dockerfile.lock` required to produce reproducible builds. + +2. **Generate the lockfile** by running `make lock` from inside the `workflow/` directory. Re-run this whenever you change dependencies in `package.json`: + + ```bash + cd workflow + make lock + ``` + + This generates `bun.lock` inside a Docker container to ensure cross-platform consistency. Always commit the updated `bun.lock` so that verifiers can reproduce your build. + +3. **Share your workflow source** with the verifier. Provide a zip archive or repository link that includes all workflow files and the committed `bun.lock`. Exclude `.env` files that contain private keys or secrets. + +### Steps for the verifier + +1. [**Install the CRE CLI**](/cre/getting-started/cli-installation). No login or deploy access is required for hash verification. + +2. **Start Docker Desktop.** When `cre workflow hash` runs, it detects that the workflow uses a pre-built WASM path and invokes `make build`. The Makefile then uses Docker to reproduce the WASM binary. + +3. **Clone or unzip** the shared workflow repository. + +4. **Run `cre workflow hash`** from the project root directory to compute the workflow hash: + + ```bash + cre workflow hash workflow --public_key --target production-settings + ``` + + Replace `` with the deployer's public address (for example, `0xb0f2D38245dD6d397ebBDB5A814b753D56c30715`). + +5. **Compare the output** with the workflow ID observed onchain. The `Workflow hash` value corresponds to the onchain workflow ID: + + ``` + Compiling workflow... + ✓ Workflow compiled + Binary hash: 03c77e16354e5555f9a74e787f9a6aa0d939e9b8e4ddff06542b7867499c58ea + Config hash: 3bdaebcc2f639d77cb248242c1d01c8651f540cdbf423d26fe3128516fd225b6 + Workflow hash: 001de36f9d689b57f2e4f1eaeda1db5e79f7991402e3611e13a5c930599c2297 + ``` + + If the workflow hash matches the onchain workflow ID, the deployed workflow matches the shared source code. + + + +### How reproducible builds work + +When `cre workflow hash` runs on this template, it detects `workflow-path: ./wasm/workflow.wasm` in `workflow.yaml` and delegates compilation to `make build` rather than compiling TypeScript directly: + +1. `make build` on the host starts a Docker build targeting `linux/amd64`. +2. Inside the container, `bun install --frozen-lockfile` installs exact dependency versions from `bun.lock`. +3. The workflow is compiled to a WASM binary (`workflow.wasm`). +4. The binary is exported back to the host. + +Because the build runs inside a pinned Docker image with a locked dependency tree, the same source always produces the same binary hash. + +## Learn more + +- [Deploying Workflows](/cre/guides/operations/deploying-workflows) +- [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows) +- [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) +- [CRE CLI Workflow Reference](/cre/reference/cli/workflow) diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index b426f7da5a0..b1d1d664652 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -6142,118 +6142,6 @@ For complete setup instructions, configuration requirements, and step-by-step gu --- -# Verifying Workflows -Source: https://docs.chain.link/cre/guides/operations/verifying-workflows -Last Updated: 2026-03-19 - -Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. - -## Workflow ID - -The workflow ID is a unique hash that serves as the primary identifier for your workflow throughout its lifecycle. It is computed locally during [`cre workflow deploy`](/cre/reference/cli/workflow#cre-workflow-deploy) from the following inputs: - -- **workflowOwner**: The deployer's address -- **workflowName**: The name specified in your workflow -- **Compiled workflow binary**: The WASM binary produced from your workflow code -- **Config file contents**: The contents of your workflow's config file -- **Secrets hash**: An empty string placeholder for secrets - -Because the workflow ID is derived from these inputs, it deterministically represents a specific version of your workflow code and configuration. - - - -Use [`cre workflow hash`](/cre/reference/cli/workflow#cre-workflow-hash) to inspect the workflow ID before deploying. This lets you preview the ID without submitting an onchain transaction. - -For more details on deployment and updates, see [Deploying Workflows](/cre/guides/operations/deploying-workflows) and [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows). - -## Verifying workflows onchain - -When a workflow writes onchain, the consumer contract receives both the report data and metadata through the `onReport` callback. The metadata contains information you can use to verify the source of the report: - -- **`workflowId`** (`bytes32`): The unique workflow hash -- **`workflowName`** (`bytes10`): The workflow name, hash-encoded -- **`workflowOwner`** (`address`): The address that deployed the workflow - -See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) for the full `IReceiver` interface and metadata structure. - -### Workflow name encoding - -The `workflowName` in metadata is not stored as a plain string. It is a SHA256 hash of the workflow name, truncated to `bytes10`. See [how workflow names are encoded](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#how-workflow-names-are-encoded) for the full encoding process. - -### Security best practices - -Follow these practices to ensure only authorized workflows can interact with your consumer contract: - -- **Verify `msg.sender`**: Always check that `msg.sender` is the expected forwarder address. See the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory) for addresses by network. -- **Permission on workflow ID**: Use `setExpectedWorkflowId` from `ReceiverTemplate` to restrict which workflow can call your contract. - - - -## Third-party verification - - - -Third-party verification allows customers or auditors to independently confirm that a deployed workflow matches its source code. The deployer shares the workflow source, and the verifier uses the CRE CLI to compute the workflow hash and compare it against the onchain workflow ID. - -### Steps for the workflow developer - -1. **Add a `.env.public` file** to your workflow folder with `GOTOOLCHAIN` set to the Go toolchain version you use to build the workflow. Pinning that version helps reproducible builds across machines and environments. Add this file *before* running `cre workflow deploy`. - - Example (replace with your own version—the tag below is not prescriptive): - - ``` - GOTOOLCHAIN=go1.23.0 - ``` - - Use the same toolchain string you build with; `go version` reports it (for example `go1.23.0 linux/amd64` → use `go1.23.0`). - -2. **Share your workflow source** with the customer. Provide a zip archive or repository link that includes all workflow files, including `.env.public`. Exclude `.env` files that contain private keys or secrets. - -### Steps for the verifier - -1. [**Install the CRE CLI**](/cre/getting-started/cli-installation). No login or deploy access is required for hash verification. - -2. **Unzip or clone** the shared workflow repository. - -3. **Run `cre workflow hash`** to compute the workflow hash: - - ```bash - cre workflow hash ./workflow-folder --public_key=0xYourDeployerAddress - ``` - - Replace `./workflow-folder` with the path to the workflow source and `0xYourDeployerAddress` with the deployer's public address. - -4. **Compare the output** with the workflow ID observed onchain. The `Workflow hash` value in the output corresponds to the onchain workflow ID: - - ``` - Binary hash: 0dcbb19de3c22edfe61605a970eb6d42199df91ac3e992cd3f2e33cb13efbb4c - Config hash: 3bdaebcc2f639d77cb248242c1d01c8651f540cdbf423d26fe3128516fd225b6 - Workflow hash: 004fff5bb1ae05cc16e453f8ad564f5e8b0eae1945ec22f3d0adfc0339954d56 - ``` - - If the workflow hash matches the onchain workflow ID, the deployed workflow matches the shared source code. - - - -## Learn more - -- [Deploying Workflows](/cre/guides/operations/deploying-workflows) -- [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows) -- [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) -- [CRE CLI Workflow Reference](/cre/reference/cli/workflow) - ---- - # Deleting Workflows Source: https://docs.chain.link/cre/guides/operations/deleting-workflows Last Updated: 2025-11-04 @@ -11469,6 +11357,116 @@ You've now mastered the complete CRE development workflow! --- +# Verifying Workflows +Source: https://docs.chain.link/cre/guides/operations/verifying-workflows-go +Last Updated: 2026-04-09 + +Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. + +## Workflow ID + +The workflow ID is a unique hash that serves as the primary identifier for your workflow throughout its lifecycle. It is computed locally during [`cre workflow deploy`](/cre/reference/cli/workflow#cre-workflow-deploy) from the following inputs: + +- **workflowOwner**: The deployer's address +- **workflowName**: The name specified in your workflow +- **Compiled workflow binary**: The WASM binary produced from your workflow code +- **Config file contents**: The contents of your workflow's config file +- **Secrets hash**: An empty string placeholder for secrets + +Because the workflow ID is derived from these inputs, it deterministically represents a specific version of your workflow code and configuration. + + + +Use [`cre workflow hash`](/cre/reference/cli/workflow#cre-workflow-hash) to inspect the workflow ID before deploying. This lets you preview the ID without submitting an onchain transaction. + +For more details on deployment and updates, see [Deploying Workflows](/cre/guides/operations/deploying-workflows) and [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows). + +## Verifying workflows onchain + +When a workflow writes onchain, the consumer contract receives both the report data and metadata through the `onReport` callback. The metadata contains information you can use to verify the source of the report: + +- **`workflowId`** (`bytes32`): The unique workflow hash +- **`workflowName`** (`bytes10`): The workflow name, hash-encoded +- **`workflowOwner`** (`address`): The address that deployed the workflow + +See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) for the full `IReceiver` interface and metadata structure. + +### Workflow name encoding + +The `workflowName` in metadata is not stored as a plain string. It is a SHA256 hash of the workflow name, truncated to `bytes10`. See [how workflow names are encoded](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#how-workflow-names-are-encoded) for the full encoding process. + +### Security best practices + +Follow these practices to ensure only authorized workflows can interact with your consumer contract: + +- **Verify `msg.sender`**: Always check that `msg.sender` is the expected forwarder address. See the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory) for addresses by network. +- **Permission on workflow ID**: Use `setExpectedWorkflowId` from `ReceiverTemplate` to restrict which workflow can call your contract. + + + +## Third-party verification + +Third-party verification allows customers or auditors to independently confirm that a deployed workflow matches its source code. The deployer shares the workflow source, and the verifier uses the CRE CLI to compute the workflow hash and compare it against the onchain workflow ID. + +Go workflows are verifiable by default and do not require a template or Docker. + +### Steps for the workflow developer + +1. **Add a `.env.public` file** to your workflow folder with `GOTOOLCHAIN` set to the Go toolchain version you use to build the workflow. Pinning that version helps reproducible builds across machines and environments. Add this file *before* running `cre workflow deploy`. + + Example (replace with your own version—the tag below is not prescriptive): + + ``` + GOTOOLCHAIN=go1.23.0 + ``` + + Use the same toolchain string you build with; `go version` reports it (for example `go1.23.0 linux/amd64` → use `go1.23.0`). + +2. **Share your workflow source** with the verifier. Provide a zip archive or repository link that includes all workflow files, including `.env.public`. Exclude `.env` files that contain private keys or secrets. + +### Steps for the verifier + +1. [**Install the CRE CLI**](/cre/getting-started/cli-installation). No login or deploy access is required for hash verification. + +2. **Unzip or clone** the shared workflow repository. + +3. **Run `cre workflow hash`** to compute the workflow hash: + + ```bash + cre workflow hash ./workflow-folder --public_key 0xYourDeployerAddress + ``` + + Replace `./workflow-folder` with the path to the workflow source and `0xYourDeployerAddress` with the deployer's public address. + +4. **Compare the output** with the workflow ID observed onchain. The `Workflow hash` value in the output corresponds to the onchain workflow ID: + + ``` + Binary hash: 0dcbb19de3c22edfe61605a970eb6d42199df91ac3e992cd3f2e33cb13efbb4c + Config hash: 3bdaebcc2f639d77cb248242c1d01c8651f540cdbf423d26fe3128516fd225b6 + Workflow hash: 004fff5bb1ae05cc16e453f8ad564f5e8b0eae1945ec22f3d0adfc0339954d56 + ``` + + If the workflow hash matches the onchain workflow ID, the deployed workflow matches the shared source code. + + + +## Learn more + +- [Deploying Workflows](/cre/guides/operations/deploying-workflows) +- [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows) +- [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) +- [CRE CLI Workflow Reference](/cre/reference/cli/workflow) + +--- + # Using Secrets in Simulation Source: https://docs.chain.link/cre/guides/workflow/secrets/using-secrets-simulation-go Last Updated: 2025-11-04 diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt index 5ecc4acdf00..8b533047706 100644 --- a/src/content/cre/llms-full-ts.txt +++ b/src/content/cre/llms-full-ts.txt @@ -5241,118 +5241,6 @@ For complete setup instructions, configuration requirements, and step-by-step gu --- -# Verifying Workflows -Source: https://docs.chain.link/cre/guides/operations/verifying-workflows -Last Updated: 2026-03-19 - -Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. - -## Workflow ID - -The workflow ID is a unique hash that serves as the primary identifier for your workflow throughout its lifecycle. It is computed locally during [`cre workflow deploy`](/cre/reference/cli/workflow#cre-workflow-deploy) from the following inputs: - -- **workflowOwner**: The deployer's address -- **workflowName**: The name specified in your workflow -- **Compiled workflow binary**: The WASM binary produced from your workflow code -- **Config file contents**: The contents of your workflow's config file -- **Secrets hash**: An empty string placeholder for secrets - -Because the workflow ID is derived from these inputs, it deterministically represents a specific version of your workflow code and configuration. - - - -Use [`cre workflow hash`](/cre/reference/cli/workflow#cre-workflow-hash) to inspect the workflow ID before deploying. This lets you preview the ID without submitting an onchain transaction. - -For more details on deployment and updates, see [Deploying Workflows](/cre/guides/operations/deploying-workflows) and [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows). - -## Verifying workflows onchain - -When a workflow writes onchain, the consumer contract receives both the report data and metadata through the `onReport` callback. The metadata contains information you can use to verify the source of the report: - -- **`workflowId`** (`bytes32`): The unique workflow hash -- **`workflowName`** (`bytes10`): The workflow name, hash-encoded -- **`workflowOwner`** (`address`): The address that deployed the workflow - -See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) for the full `IReceiver` interface and metadata structure. - -### Workflow name encoding - -The `workflowName` in metadata is not stored as a plain string. It is a SHA256 hash of the workflow name, truncated to `bytes10`. See [how workflow names are encoded](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#how-workflow-names-are-encoded) for the full encoding process. - -### Security best practices - -Follow these practices to ensure only authorized workflows can interact with your consumer contract: - -- **Verify `msg.sender`**: Always check that `msg.sender` is the expected forwarder address. See the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory) for addresses by network. -- **Permission on workflow ID**: Use `setExpectedWorkflowId` from `ReceiverTemplate` to restrict which workflow can call your contract. - - - -## Third-party verification - - - -Third-party verification allows customers or auditors to independently confirm that a deployed workflow matches its source code. The deployer shares the workflow source, and the verifier uses the CRE CLI to compute the workflow hash and compare it against the onchain workflow ID. - -### Steps for the workflow developer - -1. **Add a `.env.public` file** to your workflow folder with `GOTOOLCHAIN` set to the Go toolchain version you use to build the workflow. Pinning that version helps reproducible builds across machines and environments. Add this file *before* running `cre workflow deploy`. - - Example (replace with your own version—the tag below is not prescriptive): - - ``` - GOTOOLCHAIN=go1.23.0 - ``` - - Use the same toolchain string you build with; `go version` reports it (for example `go1.23.0 linux/amd64` → use `go1.23.0`). - -2. **Share your workflow source** with the customer. Provide a zip archive or repository link that includes all workflow files, including `.env.public`. Exclude `.env` files that contain private keys or secrets. - -### Steps for the verifier - -1. [**Install the CRE CLI**](/cre/getting-started/cli-installation). No login or deploy access is required for hash verification. - -2. **Unzip or clone** the shared workflow repository. - -3. **Run `cre workflow hash`** to compute the workflow hash: - - ```bash - cre workflow hash ./workflow-folder --public_key=0xYourDeployerAddress - ``` - - Replace `./workflow-folder` with the path to the workflow source and `0xYourDeployerAddress` with the deployer's public address. - -4. **Compare the output** with the workflow ID observed onchain. The `Workflow hash` value in the output corresponds to the onchain workflow ID: - - ``` - Binary hash: 0dcbb19de3c22edfe61605a970eb6d42199df91ac3e992cd3f2e33cb13efbb4c - Config hash: 3bdaebcc2f639d77cb248242c1d01c8651f540cdbf423d26fe3128516fd225b6 - Workflow hash: 004fff5bb1ae05cc16e453f8ad564f5e8b0eae1945ec22f3d0adfc0339954d56 - ``` - - If the workflow hash matches the onchain workflow ID, the deployed workflow matches the shared source code. - - - -## Learn more - -- [Deploying Workflows](/cre/guides/operations/deploying-workflows) -- [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows) -- [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) -- [CRE CLI Workflow Reference](/cre/reference/cli/workflow) - ---- - # Deleting Workflows Source: https://docs.chain.link/cre/guides/operations/deleting-workflows Last Updated: 2025-11-04 @@ -10986,6 +10874,138 @@ You've now mastered the complete CRE development workflow! --- +# Verifying Workflows +Source: https://docs.chain.link/cre/guides/operations/verifying-workflows-ts +Last Updated: 2026-04-09 + +Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. + +## Workflow ID + +The workflow ID is a unique hash that serves as the primary identifier for your workflow throughout its lifecycle. It is computed locally during [`cre workflow deploy`](/cre/reference/cli/workflow#cre-workflow-deploy) from the following inputs: + +- **workflowOwner**: The deployer's address +- **workflowName**: The name specified in your workflow +- **Compiled workflow binary**: The WASM binary produced from your workflow code +- **Config file contents**: The contents of your workflow's config file +- **Secrets hash**: An empty string placeholder for secrets + +Because the workflow ID is derived from these inputs, it deterministically represents a specific version of your workflow code and configuration. + + + +Use [`cre workflow hash`](/cre/reference/cli/workflow#cre-workflow-hash) to inspect the workflow ID before deploying. This lets you preview the ID without submitting an onchain transaction. + +For more details on deployment and updates, see [Deploying Workflows](/cre/guides/operations/deploying-workflows) and [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows). + +## Verifying workflows onchain + +When a workflow writes onchain, the consumer contract receives both the report data and metadata through the `onReport` callback. The metadata contains information you can use to verify the source of the report: + +- **`workflowId`** (`bytes32`): The unique workflow hash +- **`workflowName`** (`bytes10`): The workflow name, hash-encoded +- **`workflowOwner`** (`address`): The address that deployed the workflow + +See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) for the full `IReceiver` interface and metadata structure. + +### Workflow name encoding + +The `workflowName` in metadata is not stored as a plain string. It is a SHA256 hash of the workflow name, truncated to `bytes10`. See [how workflow names are encoded](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#how-workflow-names-are-encoded) for the full encoding process. + +### Security best practices + +Follow these practices to ensure only authorized workflows can interact with your consumer contract: + +- **Verify `msg.sender`**: Always check that `msg.sender` is the expected forwarder address. See the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory) for addresses by network. +- **Permission on workflow ID**: Use `setExpectedWorkflowId` from `ReceiverTemplate` to restrict which workflow can call your contract. + + + +## Third-party verification + +Third-party verification allows customers or auditors to independently confirm that a deployed workflow matches its source code. The deployer shares the workflow source, and the verifier uses the CRE CLI to compute the workflow hash and compare it against the onchain workflow ID. + +TypeScript workflows use Docker to produce reproducible builds. The same source always produces the same WASM binary hash because the build runs inside a pinned Docker image with a locked dependency tree. + +### Prerequisites + +- [CRE CLI](/cre/getting-started/cli-installation) installed +- [Docker Desktop](https://www.docker.com/products/docker-desktop/) running +- `make` available in your PATH (included with Xcode Command Line Tools on macOS; install via your package manager on Linux) + +### Steps for the workflow developer + +1. **Use the [`verifiable-build-ts` template](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/verifiable-build/verifiable-build-ts)** as the starting point for your workflow. This template includes the `Dockerfile`, `Makefile`, and `Dockerfile.lock` required to produce reproducible builds. + +2. **Generate the lockfile** by running `make lock` from inside the `workflow/` directory. Re-run this whenever you change dependencies in `package.json`: + + ```bash + cd workflow + make lock + ``` + + This generates `bun.lock` inside a Docker container to ensure cross-platform consistency. Always commit the updated `bun.lock` so that verifiers can reproduce your build. + +3. **Share your workflow source** with the verifier. Provide a zip archive or repository link that includes all workflow files and the committed `bun.lock`. Exclude `.env` files that contain private keys or secrets. + +### Steps for the verifier + +1. [**Install the CRE CLI**](/cre/getting-started/cli-installation). No login or deploy access is required for hash verification. + +2. **Start Docker Desktop.** When `cre workflow hash` runs, it detects that the workflow uses a pre-built WASM path and invokes `make build`. The Makefile then uses Docker to reproduce the WASM binary. + +3. **Clone or unzip** the shared workflow repository. + +4. **Run `cre workflow hash`** from the project root directory to compute the workflow hash: + + ```bash + cre workflow hash workflow --public_key --target production-settings + ``` + + Replace `` with the deployer's public address (for example, `0xb0f2D38245dD6d397ebBDB5A814b753D56c30715`). + +5. **Compare the output** with the workflow ID observed onchain. The `Workflow hash` value corresponds to the onchain workflow ID: + + ``` + Compiling workflow... + ✓ Workflow compiled + Binary hash: 03c77e16354e5555f9a74e787f9a6aa0d939e9b8e4ddff06542b7867499c58ea + Config hash: 3bdaebcc2f639d77cb248242c1d01c8651f540cdbf423d26fe3128516fd225b6 + Workflow hash: 001de36f9d689b57f2e4f1eaeda1db5e79f7991402e3611e13a5c930599c2297 + ``` + + If the workflow hash matches the onchain workflow ID, the deployed workflow matches the shared source code. + + + +### How reproducible builds work + +When `cre workflow hash` runs on this template, it detects `workflow-path: ./wasm/workflow.wasm` in `workflow.yaml` and delegates compilation to `make build` rather than compiling TypeScript directly: + +1. `make build` on the host starts a Docker build targeting `linux/amd64`. +2. Inside the container, `bun install --frozen-lockfile` installs exact dependency versions from `bun.lock`. +3. The workflow is compiled to a WASM binary (`workflow.wasm`). +4. The binary is exported back to the host. + +Because the build runs inside a pinned Docker image with a locked dependency tree, the same source always produces the same binary hash. + +## Learn more + +- [Deploying Workflows](/cre/guides/operations/deploying-workflows) +- [Updating Deployed Workflows](/cre/guides/operations/updating-deployed-workflows) +- [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) +- [CRE CLI Workflow Reference](/cre/reference/cli/workflow) + +--- + # Using Secrets in Simulation Source: https://docs.chain.link/cre/guides/workflow/secrets/using-secrets-simulation-ts Last Updated: 2025-11-04 From 90edf1841152a24d0bd4cbb11594a8d08c640387 Mon Sep 17 00:00:00 2001 From: devin distefano Date: Fri, 10 Apr 2026 13:35:54 -0500 Subject: [PATCH 2/2] added a little callout for go/ts on verifiability page --- src/content/cre/guides/operations/verifying-workflows-go.mdx | 5 +++++ src/content/cre/guides/operations/verifying-workflows-ts.mdx | 5 +++++ src/content/cre/llms-full-go.txt | 5 +++++ src/content/cre/llms-full-ts.txt | 5 +++++ 4 files changed, 20 insertions(+) diff --git a/src/content/cre/guides/operations/verifying-workflows-go.mdx b/src/content/cre/guides/operations/verifying-workflows-go.mdx index cd1446b67db..6fe5f3cac95 100644 --- a/src/content/cre/guides/operations/verifying-workflows-go.mdx +++ b/src/content/cre/guides/operations/verifying-workflows-go.mdx @@ -12,6 +12,11 @@ metadata: import { Aside } from "@components" + + Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. ## Workflow ID diff --git a/src/content/cre/guides/operations/verifying-workflows-ts.mdx b/src/content/cre/guides/operations/verifying-workflows-ts.mdx index 7df8ee41a3d..87cb0e9077c 100644 --- a/src/content/cre/guides/operations/verifying-workflows-ts.mdx +++ b/src/content/cre/guides/operations/verifying-workflows-ts.mdx @@ -12,6 +12,11 @@ metadata: import { Aside } from "@components" + + Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. ## Workflow ID diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index b1d1d664652..acae26c366c 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -11361,6 +11361,11 @@ You've now mastered the complete CRE development workflow! Source: https://docs.chain.link/cre/guides/operations/verifying-workflows-go Last Updated: 2026-04-09 + + Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. ## Workflow ID diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt index 8b533047706..72d1e818958 100644 --- a/src/content/cre/llms-full-ts.txt +++ b/src/content/cre/llms-full-ts.txt @@ -10878,6 +10878,11 @@ You've now mastered the complete CRE development workflow! Source: https://docs.chain.link/cre/guides/operations/verifying-workflows-ts Last Updated: 2026-04-09 + + Workflow verification ensures the integrity and authenticity of your workflows across deployment, onchain execution, and third-party auditing. This guide explains how workflow IDs are computed, how to verify workflows in consumer contracts, and how to enable independent verification by third parties. ## Workflow ID