diff --git a/public/changelog.json b/public/changelog.json index 054ec2ced81..7595eb19524 100644 --- a/public/changelog.json +++ b/public/changelog.json @@ -2309,6 +2309,34 @@ "title": "Streams scheduled for deprecation", "topic": "Data Streams" }, + { + "category": "release", + "date": "2026-06-18", + "description": "CRE CLI version 1.21.0 is now available. Using `--unsigned` or `--changeset` with `--secrets-auth=browser` or a private registry now produces a clear upfront error instead of a confusing failure mid-operation.\n\nUpdate your CLI by running `cre update` when prompted, or follow the [CLI Installation guide](https://docs.chain.link/cre/getting-started/cli-installation) for fresh installations.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.20.0...v1.21.0)", + "title": "CRE CLI v1.21.0 — MSIG Mode Guard", + "topic": "CRE" + }, + { + "category": "release", + "date": "2026-06-12", + "description": "CRE CLI version 1.20.0 is now available. Simulation resource limits now match production — including higher execution concurrency, doubled gas limits, and larger payload caps for HTTP action and ConfidentialHTTP.\n\nUpdate your CLI by running `cre update` when prompted, or follow the [CLI Installation guide](https://docs.chain.link/cre/getting-started/cli-installation) for fresh installations.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.19.0...v1.20.0)", + "title": "CRE CLI v1.20.0 — Simulation Limits Match Production", + "topic": "CRE" + }, + { + "category": "release", + "date": "2026-06-11", + "description": "Go SDK version 1.12.0 adds Solana mainnet chain selectors and workflow bindings, enabling production workflows that target Solana mainnet.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-sdk-go/compare/v1.11.0...v1.12.0)", + "title": "Go SDK v1.12.0 — Solana Mainnet", + "topic": "CRE" + }, + { + "category": "release", + "date": "2026-06-11", + "description": "CRE CLI version 1.19.0 is now available. A new `--listen` flag for `cre workflow simulate` keeps the simulator alive and reruns it for each incoming HTTP POST or EVM log trigger event, making it easier to iterate on trigger-driven workflows. Browser OAuth secrets auth is now enabled in production (with a fix for flows that broke when the default `CRE_ETH_PRIVATE_KEY` placeholder was set). Workflow output for deploy, activate, and pause now shows the resolved DON Family. The CLI also auto-resolves RPC endpoints for the capability registry chain and prompts for consent during secrets operations.\n\nUpdate your CLI by running `cre update` when prompted, or follow the [CLI Installation guide](https://docs.chain.link/cre/getting-started/cli-installation) for fresh installations.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.18.0...v1.19.0)", + "title": "CRE CLI v1.19.0 — `--listen` for Simulate, Browser Secrets in Production", + "topic": "CRE" + }, { "category": "release", "date": "2026-06-04", @@ -3514,6 +3542,20 @@ "title": "CRE CLI v1.16.0 — ADI Mainnet Support", "topic": "CRE" }, + { + "category": "release", + "date": "2026-05-21", + "description": "Go SDK version 1.11.0 adds `private-testnet-rhyolite` EVM capabilities for the Rhyolite private testnet.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-sdk-go/compare/v1.10.0...v1.11.0)", + "title": "Go SDK v1.11.0 — Rhyolite Testnet Support", + "topic": "CRE" + }, + { + "category": "release", + "date": "2026-05-20", + "description": "Go SDK version 1.10.0 adds ADI mainnet (`adi-mainnet`) EVM capabilities, enabling workflows that target ADI mainnet.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-sdk-go/compare/v1.9.0...v1.10.0)", + "title": "Go SDK v1.10.0 — ADI Mainnet Support", + "topic": "CRE" + }, { "category": "release", "date": "2026-05-14", @@ -3521,6 +3563,13 @@ "title": "CRE CLI v1.15.0 — Tenant-Scoped Chains and Chain Expansion", "topic": "CRE" }, + { + "category": "release", + "date": "2026-05-13", + "description": "Go SDK version 1.9.0 adds ADI testnet (`adi-testnet`) and Celo Sepolia (`celo-sepolia`) EVM capabilities, enabling simulation and deployment to these networks.\n\n[See all changes on GitHub](https://github.com/smartcontractkit/cre-sdk-go/compare/v1.8.0...v1.9.0)", + "title": "Go SDK v1.9.0 — ADI Testnet and Celo Sepolia Support", + "topic": "CRE" + }, { "category": "release", "date": "2026-05-08", diff --git a/src/config/versions/index.ts b/src/config/versions/index.ts index 78397ef747e..2c97720f38a 100644 --- a/src/config/versions/index.ts +++ b/src/config/versions/index.ts @@ -77,8 +77,11 @@ export const VERSIONS = { }, // CRE CLI Versions — update LATEST here for each new release "cre-cli": { - LATEST: "v1.18.0", + LATEST: "v1.21.0", ALL: [ + "v1.21.0", + "v1.20.0", + "v1.19.0", "v1.18.0", "v1.17.0", "v1.16.0", @@ -92,6 +95,9 @@ export const VERSIONS = { "v1.8.0", ] as const, RELEASE_DATES: { + "v1.21.0": "2026-06-18T00:00:00Z", + "v1.20.0": "2026-06-12T00:00:00Z", + "v1.19.0": "2026-06-11T00:00:00Z", "v1.18.0": "2026-06-04T00:00:00Z", "v1.17.0": "2026-05-28T00:00:00Z", "v1.16.0": "2026-05-22T00:00:00Z", diff --git a/src/content/cre/guides/operations/simulating-workflows.mdx b/src/content/cre/guides/operations/simulating-workflows.mdx index e24a47858a9..13765fb87ec 100644 --- a/src/content/cre/guides/operations/simulating-workflows.mdx +++ b/src/content/cre/guides/operations/simulating-workflows.mdx @@ -5,7 +5,7 @@ title: "Simulating Workflows" metadata: description: "Simulate your workflows: learn to simulate CRE workflows with real API and testnet calls before deploying them." datePublished: "2025-11-04" - lastModified: "2025-11-04" + lastModified: "2026-06-11" --- import { Aside, CopyText } from "@components" @@ -112,6 +112,19 @@ cre workflow simulate my-workflow --non-interactive --trigger-index 0 --target s second, etc., based on their order in your code. +## Listen mode + +The `--listen` flag keeps the simulator alive and re-runs it for each incoming trigger event, instead of compiling and executing once then exiting. + +- **HTTP triggers**: starts a local HTTP server on port `2000`. Each POST request triggers a fresh simulation run. +- **EVM log triggers**: watches the configured chain and re-runs on each matching log event. + +```bash +cre workflow simulate my-workflow --listen --target staging-settings +``` + +This is useful during active development — make a code change, resave, send another event, and see the result immediately without restarting the CLI. See [Testing HTTP Triggers in Simulation](/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation) for a detailed walkthrough with HTTP triggers. + ## The `--broadcast` flag By default, the simulator performs a **dry run** for onchain write operations. It prepares the transaction but does not broadcast it to the blockchain. diff --git a/src/content/cre/guides/workflow/using-evm-client/forwarder-directory-go.mdx b/src/content/cre/guides/workflow/using-evm-client/forwarder-directory-go.mdx index 89931e553bc..28195398db1 100644 --- a/src/content/cre/guides/workflow/using-evm-client/forwarder-directory-go.mdx +++ b/src/content/cre/guides/workflow/using-evm-client/forwarder-directory-go.mdx @@ -7,7 +7,7 @@ pageId: "evm-forwarder-directory" metadata: description: "Find forwarder contract addresses for CRE workflows on supported EVM networks." datePublished: "2025-11-04" - lastModified: "2026-05-22" + lastModified: "2026-06-24" --- import { Aside, CopyText } from "@components" @@ -16,6 +16,12 @@ import { Aside, CopyText } from "@components" For a complete list of supported networks and version requirements, see [Supported Networks](/cre/supported-networks). + + This page lists forwarder contract addresses for CRE workflows, organized by network. ## How to Use This Page @@ -49,66 +55,67 @@ If you configure forwarder validation in your consumer contract, **remember to u These `MockKeystoneForwarder` addresses are used when running `cre workflow simulate` with the `--broadcast` flag. Use these addresses **only** during local development and testing. +The tables below reflect chains commonly enabled for simulation. Your tenant may have a different set — run [`cre workflow supported-chains`](/cre/reference/cli/workflow#cre-workflow-supported-chains) for the authoritative list and mock forwarder addresses for your organization. + ### Simulation Mainnets -| Network | Chain Name | Mock Forwarder Address | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------ | -| ADI Mainnet | | | -| Arbitrum One | | | -| Avalanche | | | -| Base | | | -| BNB Chain | | | -| Celo | | | -| Ethereum Mainnet | | | -| Gnosis Chain | | | -| Hyperliquid Mainnet | | | -| Ink | | | -| Jovay Mainnet | | | -| Linea | | | -| Mantle | | | -| MegaETH | | | -| OP Mainnet | | | -| Pharos Mainnet | | | -| Plasma | | | -| Polygon | | | -| Scroll | | | -| Sonic | | | -| World Chain | | | -| XLayer Mainnet | | | -| ZKSync Era | | | +| Network | Chain Name | Mock Forwarder Address | +| ------------------- | ----------------------------------------------------- | ------------------------------------------------------------------ | +| Arbitrum One | | | +| Avalanche | | | +| Base | | | +| BNB Chain | | | +| Celo | | | +| Ethereum Mainnet | | | +| Gnosis Chain | | | +| Hyperliquid Mainnet | | | +| Ink | | | +| Jovay Mainnet | | | +| Linea | | | +| Mantle | | | +| MegaETH | | | +| OP Mainnet | | | +| Pharos Mainnet | | | +| Plasma | | | +| Polygon | | | +| Scroll | | | +| Sonic | | | +| World Chain | | | +| XLayer Mainnet | | | +| ZKSync Era | | | ### Simulation Testnets -| Network | Chain Name | Mock Forwarder Address | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------- | ------------------------------------------------------------------ | -| ADI Testnet | | | -| Apechain Curtis | | | -| Arc Testnet | | | -| Arbitrum Sepolia | | | -| Avalanche Fuji | | | -| Base Sepolia | | | -| BNB Chain Testnet | | | -| Celo Sepolia | | | -| Cronos Testnet | | | -| Ethereum Sepolia | | | -| Gnosis Chiado | | | -| Hyperliquid Testnet | | | -| Ink Sepolia | | | -| Jovay Testnet | | | -| Linea Sepolia | | | -| Mantle Sepolia | | | -| MegaETH Testnet 2 | | | -| OP Sepolia | | | -| Pharos Atlantic Testnet | | | -| Plasma Testnet | | | -| Polygon Amoy | | | -| Scroll Sepolia | | | -| Sonic Testnet | | | -| TAC Testnet | | | -| Unichain Sepolia | | | -| World Chain Sepolia | | | -| XLayer Testnet | | | -| ZKSync Era Sepolia | | | +| Network | Chain Name | Mock Forwarder Address | +| ----------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------ | +| ADI Testnet | | | +| Apechain Curtis | | | +| Arc Testnet | | | +| Arbitrum Sepolia | | | +| Avalanche Fuji | | | +| Base Sepolia | | | +| BNB Chain Testnet | | | +| Celo Sepolia | | | +| Cronos Testnet | | | +| Ethereum Sepolia | | | +| Gnosis Chiado | | | +| Hyperliquid Testnet | | | +| Ink Sepolia | | | +| Jovay Testnet | | | +| Linea Sepolia | | | +| Mantle Sepolia | | | +| MegaETH Testnet 2 | | | +| OP Sepolia | | | +| Pharos Atlantic Testnet | | | +| Plasma Testnet | | | +| Polygon Amoy | | | +| Scroll Sepolia | | | +| Sonic Testnet | | | +| TAC Testnet | | | +| Unichain Sepolia | | | +| World Chain Sepolia | | | +| XLayer Testnet | | | +| ZKSync Era Sepolia | | | ## Production Forwarders @@ -125,7 +132,7 @@ These `KeystoneForwarder` addresses are used by deployed workflows. Use these ad | BNB Chain | | | | Celo | | | | Ethereum Mainnet | | | -| Gnosis Chain | | | +| Gnosis Chain | | | | Hyperliquid Mainnet | | | | Ink | | | | Jovay Mainnet | | | @@ -156,7 +163,7 @@ These `KeystoneForwarder` addresses are used by deployed workflows. Use these ad | Celo Sepolia | | | | Cronos Testnet | | | | Ethereum Sepolia | | | -| Gnosis Chiado | | | +| Gnosis Chiado | | | | Hyperliquid Testnet | | | | Ink Sepolia | | | | Jovay Testnet | | | diff --git a/src/content/cre/guides/workflow/using-evm-client/forwarder-directory-ts.mdx b/src/content/cre/guides/workflow/using-evm-client/forwarder-directory-ts.mdx index bfcca90c269..8fea0aae045 100644 --- a/src/content/cre/guides/workflow/using-evm-client/forwarder-directory-ts.mdx +++ b/src/content/cre/guides/workflow/using-evm-client/forwarder-directory-ts.mdx @@ -7,7 +7,7 @@ pageId: "evm-forwarder-directory" metadata: description: "Find forwarder contract addresses for CRE workflows on supported EVM networks." datePublished: "2025-11-04" - lastModified: "2026-05-22" + lastModified: "2026-06-24" --- import { Aside, CopyText } from "@components" @@ -16,6 +16,12 @@ import { Aside, CopyText } from "@components" For a complete list of supported networks and version requirements, see [Supported Networks](/cre/supported-networks). + + This page lists forwarder contract addresses for CRE workflows, organized by network. ## How to Use This Page @@ -49,66 +55,67 @@ If you configure forwarder validation in your consumer contract, **remember to u These `MockKeystoneForwarder` addresses are used when running `cre workflow simulate` with the `--broadcast` flag. Use these addresses **only** during local development and testing. +The tables below reflect chains commonly enabled for simulation. Your tenant may have a different set — run [`cre workflow supported-chains`](/cre/reference/cli/workflow#cre-workflow-supported-chains) for the authoritative list and mock forwarder addresses for your organization. + ### Simulation Mainnets -| Network | Chain Name | Mock Forwarder Address | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------ | -| ADI Mainnet | | | -| Arbitrum One | | | -| Avalanche | | | -| Base | | | -| BNB Smart Chain | | | -| Celo | | | -| Ethereum Mainnet | | | -| Gnosis Chain | | | -| Hyperliquid Mainnet | | | -| Ink | | | -| Jovay Mainnet | | | -| Linea | | | -| Mantle | | | -| MegaETH | | | -| OP Mainnet | | | -| Pharos Mainnet | | | -| Plasma | | | -| Polygon | | | -| Scroll | | | -| Sonic | | | -| World Chain | | | -| XLayer Mainnet | | | -| ZKSync Era | | | +| Network | Chain Name | Mock Forwarder Address | +| ------------------- | ----------------------------------------------------- | ------------------------------------------------------------------ | +| Arbitrum One | | | +| Avalanche | | | +| Base | | | +| BNB Smart Chain | | | +| Celo | | | +| Ethereum Mainnet | | | +| Gnosis Chain | | | +| Hyperliquid Mainnet | | | +| Ink | | | +| Jovay Mainnet | | | +| Linea | | | +| Mantle | | | +| MegaETH | | | +| OP Mainnet | | | +| Pharos Mainnet | | | +| Plasma | | | +| Polygon | | | +| Scroll | | | +| Sonic | | | +| World Chain | | | +| XLayer Mainnet | | | +| ZKSync Era | | | ### Simulation Testnets -| Network | Chain Name | Mock Forwarder Address | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------- | ------------------------------------------------------------------ | -| ADI Testnet | | | -| Apechain Curtis | | | -| Arc Testnet | | | -| Arbitrum Sepolia | | | -| Avalanche Fuji | | | -| Base Sepolia | | | -| BSC Testnet | | | -| Celo Sepolia | | | -| Cronos Testnet | | | -| Ethereum Sepolia | | | -| Gnosis Chiado | | | -| Hyperliquid Testnet | | | -| Ink Sepolia | | | -| Jovay Testnet | | | -| Linea Sepolia | | | -| Mantle Sepolia | | | -| MegaETH Testnet 2 | | | -| OP Sepolia | | | -| Pharos Atlantic Testnet | | | -| Plasma Testnet | | | -| Polygon Amoy | | | -| Scroll Sepolia | | | -| Sonic Testnet | | | -| TAC Testnet | | | -| Unichain Sepolia | | | -| World Chain Sepolia | | | -| XLayer Testnet | | | -| ZKSync Era Sepolia | | | +| Network | Chain Name | Mock Forwarder Address | +| ----------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------ | +| ADI Testnet | | | +| Apechain Curtis | | | +| Arc Testnet | | | +| Arbitrum Sepolia | | | +| Avalanche Fuji | | | +| Base Sepolia | | | +| BSC Testnet | | | +| Celo Sepolia | | | +| Cronos Testnet | | | +| Ethereum Sepolia | | | +| Gnosis Chiado | | | +| Hyperliquid Testnet | | | +| Ink Sepolia | | | +| Jovay Testnet | | | +| Linea Sepolia | | | +| Mantle Sepolia | | | +| MegaETH Testnet 2 | | | +| OP Sepolia | | | +| Pharos Atlantic Testnet | | | +| Plasma Testnet | | | +| Polygon Amoy | | | +| Scroll Sepolia | | | +| Sonic Testnet | | | +| TAC Testnet | | | +| Unichain Sepolia | | | +| World Chain Sepolia | | | +| XLayer Testnet | | | +| ZKSync Era Sepolia | | | ## Production Forwarders @@ -125,7 +132,7 @@ These `KeystoneForwarder` addresses are used by deployed workflows. Use these ad | BNB Smart Chain | | | | Celo | | | | Ethereum Mainnet | | | -| Gnosis Chain | | | +| Gnosis Chain | | | | Hyperliquid Mainnet | | | | Ink | | | | Jovay Mainnet | | | @@ -156,7 +163,7 @@ These `KeystoneForwarder` addresses are used by deployed workflows. Use these ad | Celo Sepolia | | | | Cronos Testnet | | | | Ethereum Sepolia | | | -| Gnosis Chiado | | | +| Gnosis Chiado | | | | Hyperliquid Testnet | | | | Ink Sepolia | | | | Jovay Testnet | | | diff --git a/src/content/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation.mdx b/src/content/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation.mdx index c550e082f2a..2de4e867891 100644 --- a/src/content/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation.mdx +++ b/src/content/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation.mdx @@ -5,7 +5,7 @@ date: Last Modified metadata: description: "Test HTTP triggers locally with the CRE simulator: provide JSON payloads interactively or via command-line flags for rapid development." datePublished: "2025-11-10" - lastModified: "2025-11-10" + lastModified: "2026-06-11" --- import { Aside, CodeHighlightBlockMulti } from "@components" @@ -45,6 +45,24 @@ cre workflow simulate my-http-workflow --target staging-settings The simulator will detect your HTTP trigger and prompt you to select it from available triggers. +## Listen mode + +Use `--listen` to keep the simulator alive between runs. Instead of simulating once and exiting, the CLI starts a local HTTP server on port `2000` and re-runs the simulator every time it receives a POST request — no need to restart between tests. + +```bash +cre workflow simulate my-http-workflow --listen --target staging-settings +``` + +Once running, send payloads with any HTTP client: + +```bash +curl -X POST http://localhost:2000 \ + -H "Content-Type: application/json" \ + -d '{"userId":"123","action":"purchase","amount":100}' +``` + +Each POST triggers a fresh simulation run. Press `Ctrl+C` to stop. + ## Providing input data You have three ways to provide JSON input to your HTTP trigger during simulation: diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index 418404d2296..aaaa9383c81 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -514,10 +514,60 @@ To help us assist you faster, please include: # Release Notes Source: https://docs.chain.link/cre/release-notes -Last Updated: 2026-06-04 +Last Updated: 2026-06-18 This page provides detailed release notes for CRE. It includes information on new features, significant changes, and known limitations. +## CLI v1.21.0 - June 18, 2026 + +**CRE CLI version 1.21.0 is now available.** + +- **MSIG mode guard**: Using `--unsigned` or `--changeset` with `--secrets-auth=browser` or a private registry now produces a clear upfront error instead of a confusing failure mid-operation. + +**How to update:** + +- **Automatic update**: When you run any CRE command, the CLI will automatically detect if a newer version is available and prompt you to update. Simply run `cre update` to install the latest version. +- **Fresh installation**: If you're installing the CLI for the first time, follow the [CLI Installation guide](/cre/getting-started/cli-installation). + +[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.20.0...v1.21.0) + +## CLI v1.20.0 - June 12, 2026 + +**CRE CLI version 1.20.0 is now available.** + +- **Simulation limits aligned with production**: The local simulator's resource limits now match production. Notable increases: execution concurrency (10 → 50), EVM transaction gas limit (5M → 10M), chain write report size (5 KB → 50 KB), HTTP action payload sizes (10 KB request / 100 KB response → 120 KB / 250 KB), and ConfidentialHTTP payload sizes (10 KB / 100 KB → 125 KB / 500 KB). Workflows that previously hit local-only caps should now simulate more faithfully. + +**How to update:** + +- **Automatic update**: When you run any CRE command, the CLI will automatically detect if a newer version is available and prompt you to update. Simply run `cre update` to install the latest version. +- **Fresh installation**: If you're installing the CLI for the first time, follow the [CLI Installation guide](/cre/getting-started/cli-installation). + +[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.19.0...v1.20.0) + +## CLI v1.19.0 - June 11, 2026 + +**CRE CLI version 1.19.0 is now available.** + +- **`--listen` flag for `cre workflow simulate`**: A new `--listen` flag keeps the simulator alive and re-runs it for each incoming event — HTTP POST requests on port 2000 or matching EVM log trigger events. Use it when iterating on trigger-driven workflows without restarting the simulator between runs. Also added `--evm-receipt-timeout` (default `1m`) to control how long the simulator waits for an EVM transaction receipt. +- **Browser OAuth secrets auth in production**: Browser-based OAuth authentication for secrets is now fully enabled in production environments. A related fix prevents secrets flows from failing when the default `CRE_ETH_PRIVATE_KEY` placeholder is set in your environment. +- **DON Family shown in workflow output**: The `DON Family` field is now displayed in the details section after `cre workflow deploy`, `activate`, and `pause`. The underlying resolution now uses your tenant's platform default instead of the embedded config, so the displayed value reflects what the platform actually uses. +- **Capability registry RPC auto-resolution**: The CLI now resolves RPC endpoints for the capability registry chain automatically and prompts for consent when needed, removing the need to configure these connections manually in your secrets workflows. + +**How to update:** + +- **Automatic update**: When you run any CRE command, the CLI will automatically detect if a newer version is available and prompt you to update. Simply run `cre update` to install the latest version. +- **Fresh installation**: If you're installing the CLI for the first time, follow the [CLI Installation guide](/cre/getting-started/cli-installation). + +[See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.18.0...v1.19.0) + +## Go SDK v1.12.0 - June 11, 2026 + +**Go SDK version 1.12.0** adds Solana mainnet support. + +- **Solana mainnet**: Solana mainnet chain selectors and workflow bindings are now included in the SDK, enabling production workflows that target Solana mainnet. + +[See all changes on GitHub](https://github.com/smartcontractkit/cre-sdk-go/compare/v1.11.0...v1.12.0) + ## CLI v1.18.0 - June 4, 2026 **CRE CLI version 1.18.0 is now available.** @@ -558,6 +608,22 @@ This page provides detailed release notes for CRE. It includes information on ne [See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.15.0...v1.16.0) +## Go SDK v1.11.0 - May 21, 2026 + +**Go SDK version 1.11.0** adds private Rhyolite testnet support. + +- **`private-testnet-rhyolite` support**: EVM capabilities for the Rhyolite private testnet are now included. Use the `private-testnet-rhyolite` chain name when building workflows that target this network. + +[See all changes on GitHub](https://github.com/smartcontractkit/cre-sdk-go/compare/v1.10.0...v1.11.0) + +## Go SDK v1.10.0 - May 20, 2026 + +**Go SDK version 1.10.0** adds ADI mainnet support. + +- **ADI mainnet**: EVM capabilities for ADI mainnet (`adi-mainnet`) are now included, supporting workflows deployed to ADI mainnet. + +[See all changes on GitHub](https://github.com/smartcontractkit/cre-sdk-go/compare/v1.9.0...v1.10.0) + ## CLI v1.15.0 - May 14, 2026 **CRE CLI version 1.15.0 is now available.** @@ -589,6 +655,14 @@ This page provides detailed release notes for CRE. It includes information on ne [See all changes on GitHub](https://github.com/smartcontractkit/cre-cli/compare/v1.13.0...v1.14.0) +## Go SDK v1.9.0 - May 13, 2026 + +**Go SDK version 1.9.0** adds ADI testnet and Celo Sepolia support. + +- **ADI testnet and Celo Sepolia**: EVM capabilities for ADI testnet (`adi-testnet`) and Celo Sepolia (`celo-sepolia`) are now included, enabling simulation and deployment to these networks. + +[See all changes on GitHub](https://github.com/smartcontractkit/cre-sdk-go/compare/v1.8.0...v1.9.0) + ## CLI v1.13.0 - April 30, 2026 **CRE CLI version 1.13.0 is now available.** @@ -1535,7 +1609,7 @@ This section provides detailed guides for each available trigger type: # Testing HTTP Triggers in Simulation Source: https://docs.chain.link/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation -Last Updated: 2025-11-10 +Last Updated: 2026-06-11 During development, you can test your HTTP trigger workflows locally using the `cre workflow simulate` command. The simulator allows you to provide test payloads without setting up authorization keys or JWT authentication. @@ -1570,6 +1644,24 @@ cre workflow simulate my-http-workflow --target staging-settings The simulator will detect your HTTP trigger and prompt you to select it from available triggers. +## Listen mode + +Use `--listen` to keep the simulator alive between runs. Instead of simulating once and exiting, the CLI starts a local HTTP server on port `2000` and re-runs the simulator every time it receives a POST request — no need to restart between tests. + +```bash +cre workflow simulate my-http-workflow --listen --target staging-settings +``` + +Once running, send payloads with any HTTP client: + +```bash +curl -X POST http://localhost:2000 \ + -H "Content-Type: application/json" \ + -d '{"userId":"123","action":"purchase","amount":100}' +``` + +Each POST triggers a fresh simulation run. Press `Ctrl+C` to stop. + ## Providing input data You have three ways to provide JSON input to your HTTP trigger during simulation: @@ -5519,7 +5611,7 @@ Yes. Once you call `runtime.Rand()` and get a `*rand.Rand` object, you can reuse # Simulating Workflows Source: https://docs.chain.link/cre/guides/operations/simulating-workflows -Last Updated: 2025-11-04 +Last Updated: 2026-06-11 Workflow simulation is a local execution environment that **compiles your workflow to WebAssembly (WASM)** and runs it on **your machine**. It allows you to test and debug your workflow logic before deploying it. The simulator makes real calls to public testnets and live HTTP endpoints, giving you high confidence that your code will work as expected when deployed. @@ -5623,6 +5715,19 @@ cre workflow simulate my-workflow --non-interactive --trigger-index 0 --target s second, etc., based on their order in your code. +## Listen mode + +The `--listen` flag keeps the simulator alive and re-runs it for each incoming trigger event, instead of compiling and executing once then exiting. + +- **HTTP triggers**: starts a local HTTP server on port `2000`. Each POST request triggers a fresh simulation run. +- **EVM log triggers**: watches the configured chain and re-runs on each matching log event. + +```bash +cre workflow simulate my-workflow --listen --target staging-settings +``` + +This is useful during active development — make a code change, resave, send another event, and see the result immediately without restarting the CLI. See [Testing HTTP Triggers in Simulation](/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation) for a detailed walkthrough with HTTP triggers. + ## The `--broadcast` flag By default, the simulator performs a **dry run** for onchain write operations. It prepares the transaction but does not broadcast it to the blockchain. @@ -7478,7 +7583,7 @@ CRE uses a simple role-based access control system with two roles: # Linking Wallet Keys Source: https://docs.chain.link/cre/organization/linking-keys -Last Updated: 2025-11-04 +Last Updated: 2026-06-24 Before you can deploy workflows to the public onchain registry (`deployment-registry: "onchain:ethereum-mainnet"`), you must link a public key address to your CRE organization. This process registers your wallet address onchain in the Workflow Registry contract—the smart contract on Ethereum Mainnet that stores and manages public CRE workflows—associating it with your organization and allowing you to deploy and manage workflows through the onchain registry. @@ -7498,7 +7603,7 @@ Key linking is the process of connecting a blockchain wallet address to your CRE **Important constraints:** - **One organization per address**: Each wallet address can only be linked to one CRE organization at a time. If you need to use the same address with a different organization, you must first [unlink it](#unlinking-a-key) from the current organization. -- **Maximum 2 keys per organization**: Each organization can link a maximum of 2 web3 keys. If you need to link a third key, you must first [unlink](#unlinking-a-key) one of the existing keys. +- **Per-organization key limit**: The number of web3 keys your organization can link is subject to your plan quota. See [Service Quotas](/cre/service-quotas#registry-quotas) for the current limit. To request an increase, [contact us](/cre/support-feedback). However, an organization can have multiple wallet addresses linked to it, allowing team members to use their own addresses or enabling separation between development, staging, and production environments. @@ -7655,7 +7760,7 @@ Linked Owners: ## Linking multiple addresses -Your organization can link **up to 2 wallet addresses**. Each individual address can only be linked to one organization at a time. +Your organization can link more than one wallet address, subject to your plan's key limit. See [Service Quotas](/cre/service-quotas#registry-quotas) for the current limit, or [contact us](/cre/support-feedback) to request an increase. Each individual address can only be linked to one organization at a time. This is useful for: @@ -8816,7 +8921,7 @@ When you run this command, the CLI will: # Workflow Commands Source: https://docs.chain.link/cre/reference/cli/workflow -Last Updated: 2026-05-14 +Last Updated: 2026-06-11 The `cre workflow` commands manage workflows throughout their entire lifecycle, from local testing to deployment and ongoing management. @@ -8889,17 +8994,19 @@ cre workflow simulate [flags] **Flags:** -| Flag | Description | -| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `--broadcast` | Broadcast onchain write transactions (default: `false`). Without this flag, a dry run is performed | -| `-g, --engine-logs` | Enable non-fatal engine logging | -| `--non-interactive` | Run without prompts; requires `--trigger-index` (see the line below) and inputs for the selected trigger type | -| `--trigger-index ` | Selects which handler to run (0-based position). If your workflow has multiple handlers, `0` is the first, `1` is the second, etc. Required with `--non-interactive` | -| `--http-payload ` | HTTP trigger payload as JSON string or path to a JSON file. File paths are resolved relative to the directory where you ran the command. For HTTP triggers only | -| `--evm-tx-hash ` | Transaction hash (`0x...`) containing the event that triggered your workflow. For EVM log triggers only | -| `--evm-event-index ` | Which log/event within the transaction to use (0-based position). If the transaction emitted multiple events, `0` is the first, `1` is the second, etc. For EVM log triggers only | -| `--limits ` | Production limits to enforce during simulation: `default` (embedded prod limits), a path to a limits JSON file (e.g. from `cre workflow limits export`), or `none` to disable. See [Testing Production Limits](/cre/guides/operations/understanding-limits) (default: `default`) | -| `--skip-type-checks` | Skip TypeScript type checking during compilation. Speeds up iteration in development; not recommended for production builds | +| Flag | Description | +| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `--broadcast` | Broadcast onchain write transactions (default: `false`). Without this flag, a dry run is performed | +| `-g, --engine-logs` | Enable non-fatal engine logging | +| `--listen` | Keep the simulator alive and re-run it for each incoming trigger event. For HTTP triggers, listens for POST requests on port `2000`. For EVM log triggers, watches the chain and re-runs on each matching event. Useful when iterating on trigger-driven workflows without restarting the simulator between runs | +| `--non-interactive` | Run without prompts; requires `--trigger-index` (see the line below) and inputs for the selected trigger type | +| `--trigger-index ` | Selects which handler to run (0-based position). If your workflow has multiple handlers, `0` is the first, `1` is the second, etc. Required with `--non-interactive` | +| `--http-payload ` | HTTP trigger payload as JSON string or path to a JSON file. File paths are resolved relative to the directory where you ran the command. For HTTP triggers only | +| `--evm-tx-hash ` | Transaction hash (`0x...`) containing the event that triggered your workflow. For EVM log triggers only | +| `--evm-event-index ` | Which log/event within the transaction to use (0-based position). If the transaction emitted multiple events, `0` is the first, `1` is the second, etc. For EVM log triggers only | +| `--evm-receipt-timeout ` | How long to wait for an EVM transaction receipt before timing out (e.g. `30s`, `2m`). For EVM log triggers only (default: `1m`) | +| `--limits ` | Production limits to enforce during simulation: `default` (embedded prod limits), a path to a limits JSON file (e.g. from `cre workflow limits export`), or `none` to disable. See [Testing Production Limits](/cre/guides/operations/understanding-limits) (default: `default`) | +| `--skip-type-checks` | Skip TypeScript type checking during compilation. Speeds up iteration in development; not recommended for production builds | **Examples:** @@ -8930,6 +9037,18 @@ cre workflow simulate [flags] cre workflow simulate my-workflow --non-interactive --trigger-index 1 --evm-tx-hash 0x420721d7d00130a03c5b525b2dbfd42550906ddb3075e8377f9bb5d1a5992f8e --evm-event-index 0 --target staging-settings ``` +- Listen mode — re-run on every HTTP trigger POST (port 2000) + + ```bash + cre workflow simulate ./my-workflow --listen --target local-simulation + ``` + +- Listen mode — re-run on every matching EVM log event + + ```bash + cre workflow simulate ./my-workflow --listen --trigger-index 1 --target staging-settings + ``` + +## Listen mode + +The `--listen` flag keeps the simulator alive and re-runs it for each incoming trigger event, instead of compiling and executing once then exiting. + +- **HTTP triggers**: starts a local HTTP server on port `2000`. Each POST request triggers a fresh simulation run. +- **EVM log triggers**: watches the configured chain and re-runs on each matching log event. + +```bash +cre workflow simulate my-workflow --listen --target staging-settings +``` + +This is useful during active development — make a code change, resave, send another event, and see the result immediately without restarting the CLI. See [Testing HTTP Triggers in Simulation](/cre/guides/workflow/using-triggers/http-trigger/testing-in-simulation) for a detailed walkthrough with HTTP triggers. + ## The `--broadcast` flag By default, the simulator performs a **dry run** for onchain write operations. It prepares the transaction but does not broadcast it to the blockchain. @@ -7019,7 +7124,7 @@ CRE uses a simple role-based access control system with two roles: # Linking Wallet Keys Source: https://docs.chain.link/cre/organization/linking-keys -Last Updated: 2025-11-04 +Last Updated: 2026-06-24 Before you can deploy workflows to the public onchain registry (`deployment-registry: "onchain:ethereum-mainnet"`), you must link a public key address to your CRE organization. This process registers your wallet address onchain in the Workflow Registry contract—the smart contract on Ethereum Mainnet that stores and manages public CRE workflows—associating it with your organization and allowing you to deploy and manage workflows through the onchain registry. @@ -7039,7 +7144,7 @@ Key linking is the process of connecting a blockchain wallet address to your CRE **Important constraints:** - **One organization per address**: Each wallet address can only be linked to one CRE organization at a time. If you need to use the same address with a different organization, you must first [unlink it](#unlinking-a-key) from the current organization. -- **Maximum 2 keys per organization**: Each organization can link a maximum of 2 web3 keys. If you need to link a third key, you must first [unlink](#unlinking-a-key) one of the existing keys. +- **Per-organization key limit**: The number of web3 keys your organization can link is subject to your plan quota. See [Service Quotas](/cre/service-quotas#registry-quotas) for the current limit. To request an increase, [contact us](/cre/support-feedback). However, an organization can have multiple wallet addresses linked to it, allowing team members to use their own addresses or enabling separation between development, staging, and production environments. @@ -7196,7 +7301,7 @@ Linked Owners: ## Linking multiple addresses -Your organization can link **up to 2 wallet addresses**. Each individual address can only be linked to one organization at a time. +Your organization can link more than one wallet address, subject to your plan's key limit. See [Service Quotas](/cre/service-quotas#registry-quotas) for the current limit, or [contact us](/cre/support-feedback) to request an increase. Each individual address can only be linked to one organization at a time. This is useful for: @@ -8418,7 +8523,7 @@ When you run this command, the CLI will: # Workflow Commands Source: https://docs.chain.link/cre/reference/cli/workflow -Last Updated: 2026-05-14 +Last Updated: 2026-06-11 The `cre workflow` commands manage workflows throughout their entire lifecycle, from local testing to deployment and ongoing management. @@ -8491,17 +8596,19 @@ cre workflow simulate [flags] **Flags:** -| Flag | Description | -| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `--broadcast` | Broadcast onchain write transactions (default: `false`). Without this flag, a dry run is performed | -| `-g, --engine-logs` | Enable non-fatal engine logging | -| `--non-interactive` | Run without prompts; requires `--trigger-index` (see the line below) and inputs for the selected trigger type | -| `--trigger-index ` | Selects which handler to run (0-based position). If your workflow has multiple handlers, `0` is the first, `1` is the second, etc. Required with `--non-interactive` | -| `--http-payload ` | HTTP trigger payload as JSON string or path to a JSON file. File paths are resolved relative to the directory where you ran the command. For HTTP triggers only | -| `--evm-tx-hash ` | Transaction hash (`0x...`) containing the event that triggered your workflow. For EVM log triggers only | -| `--evm-event-index ` | Which log/event within the transaction to use (0-based position). If the transaction emitted multiple events, `0` is the first, `1` is the second, etc. For EVM log triggers only | -| `--limits ` | Production limits to enforce during simulation: `default` (embedded prod limits), a path to a limits JSON file (e.g. from `cre workflow limits export`), or `none` to disable. See [Testing Production Limits](/cre/guides/operations/understanding-limits) (default: `default`) | -| `--skip-type-checks` | Skip TypeScript type checking during compilation. Speeds up iteration in development; not recommended for production builds | +| Flag | Description | +| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `--broadcast` | Broadcast onchain write transactions (default: `false`). Without this flag, a dry run is performed | +| `-g, --engine-logs` | Enable non-fatal engine logging | +| `--listen` | Keep the simulator alive and re-run it for each incoming trigger event. For HTTP triggers, listens for POST requests on port `2000`. For EVM log triggers, watches the chain and re-runs on each matching event. Useful when iterating on trigger-driven workflows without restarting the simulator between runs | +| `--non-interactive` | Run without prompts; requires `--trigger-index` (see the line below) and inputs for the selected trigger type | +| `--trigger-index ` | Selects which handler to run (0-based position). If your workflow has multiple handlers, `0` is the first, `1` is the second, etc. Required with `--non-interactive` | +| `--http-payload ` | HTTP trigger payload as JSON string or path to a JSON file. File paths are resolved relative to the directory where you ran the command. For HTTP triggers only | +| `--evm-tx-hash ` | Transaction hash (`0x...`) containing the event that triggered your workflow. For EVM log triggers only | +| `--evm-event-index ` | Which log/event within the transaction to use (0-based position). If the transaction emitted multiple events, `0` is the first, `1` is the second, etc. For EVM log triggers only | +| `--evm-receipt-timeout ` | How long to wait for an EVM transaction receipt before timing out (e.g. `30s`, `2m`). For EVM log triggers only (default: `1m`) | +| `--limits ` | Production limits to enforce during simulation: `default` (embedded prod limits), a path to a limits JSON file (e.g. from `cre workflow limits export`), or `none` to disable. See [Testing Production Limits](/cre/guides/operations/understanding-limits) (default: `default`) | +| `--skip-type-checks` | Skip TypeScript type checking during compilation. Speeds up iteration in development; not recommended for production builds | **Examples:** @@ -8532,6 +8639,18 @@ cre workflow simulate [flags] cre workflow simulate my-workflow --non-interactive --trigger-index 1 --evm-tx-hash 0x420721d7d00130a03c5b525b2dbfd42550906ddb3075e8377f9bb5d1a5992f8e --evm-event-index 0 --target staging-settings ``` +- Listen mode — re-run on every HTTP trigger POST (port 2000) + + ```bash + cre workflow simulate ./my-workflow --listen --target local-simulation + ``` + +- Listen mode — re-run on every matching EVM log event + + ```bash + cre workflow simulate ./my-workflow --listen --trigger-index 1 --target staging-settings + ``` +