From ecfae81e7518c645d48796d45ad92b6f22d03faa Mon Sep 17 00:00:00 2001 From: Emmanuel Jacquier Date: Mon, 11 May 2026 11:11:24 -0400 Subject: [PATCH 1/8] Migration guide for CLF to CRE --- src/config/sidebar.ts | 5 + src/content/cre/llms-full-go.txt | 310 +++++++++++++++++ src/content/cre/llms-full-ts.txt | 291 ++++++++++++++++ .../cre/reference/clf-migration-go.mdx | 317 ++++++++++++++++++ .../cre/reference/clf-migration-ts.mdx | 298 ++++++++++++++++ 5 files changed, 1221 insertions(+) create mode 100644 src/content/cre/reference/clf-migration-go.mdx create mode 100644 src/content/cre/reference/clf-migration-ts.mdx diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts index 050c88a6dd2..5bfbe07e35f 100644 --- a/src/config/sidebar.ts +++ b/src/config/sidebar.ts @@ -699,6 +699,11 @@ export const SIDEBAR: Partial> = { url: "cre/reference/gelato-migration", highlightAsCurrent: ["cre/reference/gelato-migration-ts", "cre/reference/gelato-migration-go"], }, + { + title: "Migrate from Chainlink Functions", + url: "cre/reference/clf-migration", + highlightAsCurrent: ["cre/reference/clf-migration-ts", "cre/reference/clf-migration-go"], + }, ], }, ], diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index 20d7606bf8d..7ca8023da2e 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -16020,6 +16020,316 @@ Or explore the SDK reference for detailed API documentation: --- +# Migrate from Chainlink Functions to Chainlink CRE +Source: https://docs.chain.link/cre/reference/clf-migration-go +Last Updated: 2026-05-11 + + + +This guide is for developers with production Chainlink Functions (CLF) subscriptions migrating their requests to the Chainlink Runtime Environment (CRE) before mainnet shutdown on **August 12, 2026**. + +The 80% CLF use case is "fetch off-chain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer. + +## Overview + +In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback. + +In CRE, the unit of execution is a **workflow** - a Go (or TypeScript) project compiled to WebAssembly and registered with the network. Workflows are started by **triggers** (cron schedule, HTTP request, or on-chain log event), can perform multiple steps (HTTP fetches, on-chain reads, on-chain writes, calls to other capabilities) wrapped in your own business logic, and write data on-chain through a signed-report flow that any contract implementing `IReceiver` can consume. + +Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an off-chain relayer collapse into a single workflow. + +## Chain support + +CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. Canonical list: [Supported Networks](/cre/supported-networks-go). + +Mainnet and the corresponding testnet share a row when they share parity status; rows are split where they diverge. + +| Chain | CLF | CRE | +| :-------------------------------- | :-- | :-- | +| Ethereum / Sepolia | ✅ | ✅ | +| Arbitrum One / Arbitrum Sepolia | ✅ | ✅ | +| Base / Base Sepolia | ✅ | ✅ | +| Polygon / Polygon Amoy | ✅ | ✅ | +| OP Mainnet / OP Sepolia | ✅ | ✅ | +| Avalanche / Avalanche Fuji | ✅ | ✅ | +| ZKSync Era / ZKSync Era Sepolia | ✅ | ✅ | +| Celo (mainnet) | ✅ | ✅ | +| Celo Alfajores (testnet) | ✅ | ❌ | +| Soneium / Soneium Minato | ✅ | ❌ | +| BNB Chain / BNB Chain Testnet | ❌ | ✅ | +| Gnosis Chain / Gnosis Chiado | ❌ | ✅ | +| Hyperliquid / Hyperliquid Testnet | ❌ | ✅ | +| Ink / Ink Sepolia | ❌ | ✅ | +| Jovay / Jovay Testnet | ❌ | ✅ | +| Linea / Linea Sepolia | ❌ | ✅ | +| Mantle / Mantle Sepolia | ❌ | ✅ | +| MegaETH / MegaETH Testnet 2 | ❌ | ✅ | +| Pharos / Pharos Atlantic Testnet | ❌ | ✅ | +| Plasma / Plasma Testnet | ❌ | ✅ | +| Scroll / Scroll Sepolia | ❌ | ✅ | +| Sonic / Sonic Testnet | ❌ | ✅ | +| World Chain / World Chain Sepolia | ❌ | ✅ | +| XLayer / XLayer Testnet | ❌ | ✅ | +| Apechain Curtis (testnet) | ❌ | ✅ | +| Arc Testnet | ❌ | ✅ | +| Cronos Testnet | ❌ | ✅ | +| TAC Testnet | ❌ | ✅ | +| Unichain Sepolia (testnet) | ❌ | ✅ | + +## Terminology + +| Chainlink Functions | Chainlink CRE | +| :-------------------------------------------------- | :------------------------------------------------------------------------- | +| `FunctionsClient` consumer contract | `IReceiver` consumer contract (use `ReceiverTemplate`) | +| `_sendRequest()` from a consumer | Workflow trigger: Cron, HTTP, or EVM Log | +| Inline JavaScript source (Deno sandbox) | Go (or TypeScript) workflow compiled to WASM (not compatible with node.js) | +| `Functions.makeHttpRequest()` | `http.SendRequest()` | +| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver | +| DON-hosted / remote-hosted secrets | Vault DON + `secrets.yaml` + `runtime.GetSecret()` | +| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `cre-sdk-go`, `cre-cli`, `cre-templates` | +| Functions Playground UI | CRE CLI `cre workflow simulate` | +| Automation Time-based Upkeep → `sendRequest()` | Built-in Cron trigger - no Automation upkeep needed | +| `donId` + router address per chain | Chain selector + forwarder address per chain | + +## Configuration + +A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project with the following files: + +- **`main.go`** - workflow code: trigger registration, handler logic, capability calls. +- **`config..json`** - non-secret runtime config (API URLs, contract addresses, chain selectors). +- **`secrets.yaml`** - secret declarations; values supplied via `.env`/env vars locally and via the Vault DON in production. +- **`workflow.yaml`** - workflow metadata: name, owner, secrets path, target network. +- **`project.yaml`** - project-level CRE settings. + +There is no equivalent in CLF, where the entire program is a string passed to `_sendRequest()`. + +## Triggers + +CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, off-chain trigger, reaction to an event) requires gluing CLF together with Automation, an off-chain cron, or a custom indexer. CRE makes the trigger first-class. + +### Time-based + +Replaces "Automation Time-based Upkeep calling `sendRequest()`." Use a cron trigger directly. + +```go +cronTrigger := cron.Trigger(&cron.Config{Schedule: "0 */5 * * * *"}) // every 5 min +cre.Handler(cronTrigger, onCronTrigger) +``` + +Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix with `TZ=` for timezone-aware scheduling. + +### HTTP triggers + +Replaces "user transaction → `sendRequest()`" or off-chain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. + +```go +httpTrigger := http.Trigger(&http.Config{ + AuthorizedKeys: []*http.AuthorizedKey{ + {Type: http.KeyType_EVM, Key: "0xYourAuthorizedSigner"}, + }, +}) +cre.Handler(httpTrigger, onHTTPTrigger) +``` + +`AuthorizedKeys` is required for deployed workflows; an empty config is only valid in simulation. + +### Onchain events + +Replaces "off-chain listener observes an event → Solidity transaction → calls `sendRequest()`." Native EVM Log trigger watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. + +```go +logTrigger := evmClient.LogTrigger(&evm.LogTriggerConfig{ + Addresses: [][]byte{ /* contract address bytes */ }, + Topics: [][]byte{ /* event signature hash bytes */ }, +}) +cre.Handler(logTrigger, onLog) +``` + +### Per-block triggers + +CRE does not offer a "fire on every block" trigger; for high-frequency on-chain reactions, use the EVM Log trigger with a `LATEST` confidence level. For periodic state polling, use a cron trigger and call `evmClient.CallContract()` from the handler. + +## Task authoring and output + +### Language and runtime + +CLF runs an inline JavaScript string (NodeJS) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. + +CRE workflows are full Go (or TypeScript) projects compiled to WebAssembly. You manage dependencies with Go modules and run `cre workflow simulate` for a local execution that mirrors production. The handler is single-threaded; SDK capability calls return an object that you resolve with `.Await()` (Go) or `.result()` (TypeScript). + +### HTTP / API calls + +Direct replacement for `Functions.makeHttpRequest()`. Supports GET and POST; consensus aggregation is automatic. + +```go +apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await() +if err != nil { + return err +} + +res, err := http.SendRequest(runtime, &http.Request{ + Url: "https://api.example.com/price", + Method: "GET", + Headers: map[string]string{ + "Authorization": "Bearer " + apiKey.Value, + }, +}).Await() +``` + +Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `CacheSettings` so the request is only executed once across the DON. Use `runtime.Now()` (not `time.Now()`) for any timestamps included in a request payload. + +### Onchain reads + +CLF has no built-in on-chain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. + +In CRE, users can read on-chain state directly inside the handler that comes with built-in chain connectivity: + +```go +evmClient := evm.NewClient(CHAIN_SELECTOR) +result, err := evmClient.CallContract(runtime, &evm.CallContractRequest{ + To: CONTRACT_ADDRESS, + Data: callData, + BlockNumber: evm.LastFinalizedBlockNumber, +}).Await() +``` + +You can also still use HTTP requests to interact with your own RPCs. + +### Onchain writes + +This is the biggest structural change. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. + +Two steps: ABI-encode the payload and call `runtime.GenerateReport()`; then submit the signed report with `evmClient.WriteReport()`. + +```go +package main + +import ( + "github.com/smartcontractkit/cre-sdk-go/cre" + "github.com/smartcontractkit/cre-sdk-go/capabilities/networking/http" + "github.com/smartcontractkit/cre-sdk-go/capabilities/blockchain/evm" + "github.com/smartcontractkit/cre-sdk-go/capabilities/scheduler/cron" +) + +func onCronTrigger(runtime cre.Runtime, _ *cron.Payload) (any, error) { + apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await() + if err != nil { + return nil, err + } + + res, err := http.SendRequest(runtime, &http.Request{ + Url: "https://api.example.com/price", + Headers: map[string]string{ + "Authorization": "Bearer " + apiKey.Value, + }, + }).Await() + if err != nil { + return nil, err + } + + price := parsePrice(res.Body) // ABI-encoded uint256 + payload := encodePayload(price) + + report, err := runtime.GenerateReport(&cre.ReportRequest{ + EncodedPayload: payload, + }).Await() + if err != nil { + return nil, err + } + + evmClient := evm.NewClient(CHAIN_SELECTOR) + _, err = evmClient.WriteReport(runtime, &evm.WriteReportRequest{ + Receiver: RECEIVER_ADDRESS, + Report: report, + GasConfig: &evm.GasConfig{GasLimit: 200000}, + }).Await() + return nil, err +} + +func InitWorkflow() (cre.Workflow, error) { + trigger := cron.Trigger(&cron.Config{Schedule: "*/5 * * * *"}) + return cre.Workflow{ + cre.Handler(trigger, onCronTrigger), + }, nil +} +``` + +Receiver contract: + +```solidity +import {ReceiverTemplate} from "@chainlink/cre-contracts/ReceiverTemplate.sol"; + +contract PriceReceiver is ReceiverTemplate { + uint256 public price; + + constructor(address forwarder) ReceiverTemplate(forwarder) {} + + function _onReport(bytes calldata /* metadata */, bytes calldata payload) internal override { + price = abi.decode(payload, (uint256)); + } +} +``` + +Forwarder addresses are network-specific. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See CRE documentation to learn how to permission your `IReceiver`. + +### Secrets + +CLF supports DON-hosted (uploaded once via the Functions toolkit) and user-hosted (gist URL passed at request time) secrets. CRE consolidates this through the Vault DON. + +- **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var. +- **Deployed:** upload to Vault DON via `cre secrets create`. +- **In code:** `runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()` works the same in both environments. + +Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must re-supply API keys and tokens through the CRE Vault. Fetch secrets sequentially, not in parallel. + +## Monitoring + +The CRE dashboard provides per-workflow execution history, handler logs (via `runtime.Logger()`), per-step timings, consensus outcomes, and on-chain submission status, replacing the per-request views in the Functions Subscription Manager. Failed executions and reverted on-chain writes surface directly in the workflow detail view. + +## Deployment and lifecycle + +| Action | Chainlink Functions | Chainlink CRE | +| :---------------- | :-------------------------------------------------------------- | :----------------------------------------------------------------------------- | +| Author code | Inline JS string in your consumer contract | Go/TypeScript project; `cre workflow init` to scaffold | +| Local test | Functions Playground / `simulateScript` | `cre workflow simulate` | +| Deploy | Deploy `FunctionsClient` consumer; create and fund subscription | Deploy `IReceiver` consumer; `cre workflow deploy`; activate workflow | +| Update logic | Re-deploy consumer (source baked into requests) or update gist | `cre workflow update` (workflow code only; receiver unchanged) | +| Pause | Cancel subscription / set consumer flag | `cre workflow pause` | +| Delete | Remove consumer; withdraw remaining LINK from the subscription | `cre workflow delete` | +| Manage secrets | DON-hosted upload via toolkit, expires after threshold | `cre secrets create / update / delete` against Vault DON | +| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | Built-in email alerts on workflow failures; UI showing executions and DON logs | + +## Get started + +1. Install the CRE CLI: see [Getting Started](/cre/getting-started/cli-installation). +2. Authenticate with the email associated with your Chainlink account. +3. `cre workflow init` to scaffold a Go project; replace the trigger and handler with the equivalents from the Triggers + Task authoring sections above. +4. Deploy a `ReceiverTemplate`-based consumer contract on your target chain using the correct forwarder address. +5. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports on-chain. + +For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo. + +### Reference template for CLF migration + +The closest one-to-one mapping for the typical CLF use case ("fetch off-chain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both Go and TypeScript: + +- [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go) +- [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts) + +It demonstrates each piece of the migration end-to-end: + +- A **cron trigger** scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a **log trigger** variant (replaces an off-chain listener reacting to an on-chain event). +- An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.GetSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets). +- ABI-encoding the result, calling `runtime.GenerateReport()` to produce a signed report, and submitting it with `evmClient.WriteReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow). +- A complete project layout — `main.go`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source. + +If your CLF script also reads on-chain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.CallContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. + +--- + # Project Setup Commands Source: https://docs.chain.link/cre/reference/cli/project-setup-go Last Updated: 2026-03-26 diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt index 8f433c9bae5..a8be9dafde0 100644 --- a/src/content/cre/llms-full-ts.txt +++ b/src/content/cre/llms-full-ts.txt @@ -15947,6 +15947,297 @@ Or explore the SDK reference for detailed API documentation: --- +# Migrate from Chainlink Functions to Chainlink CRE +Source: https://docs.chain.link/cre/reference/clf-migration-ts +Last Updated: 2026-05-11 + + + +This guide is for developers with production Chainlink Functions (CLF) subscriptions migrating their requests to the Chainlink Runtime Environment (CRE) before mainnet shutdown on **August 12, 2026**. + +The 80% CLF use case is "fetch off-chain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer. + +## Overview + +In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback. + +In CRE, the unit of execution is a **workflow** - a TypeScript (or Go) project compiled to WebAssembly and registered with the network. Workflows are started by **triggers** (cron schedule, HTTP request, or on-chain log event), can perform multiple steps (HTTP fetches, on-chain reads, on-chain writes, calls to other capabilities) wrapped in your own business logic, and write data on-chain through a signed-report flow that any contract implementing `IReceiver` can consume. + +Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an off-chain relayer collapse into a single workflow. + +## Chain support + +CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. Canonical list: [Supported Networks](/cre/supported-networks-ts). + +Mainnet and the corresponding testnet share a row when they share parity status; rows are split where they diverge. + +| Chain | CLF | CRE | +| :-------------------------------- | :-- | :-- | +| Ethereum / Sepolia | ✅ | ✅ | +| Arbitrum One / Arbitrum Sepolia | ✅ | ✅ | +| Base / Base Sepolia | ✅ | ✅ | +| Polygon / Polygon Amoy | ✅ | ✅ | +| OP Mainnet / OP Sepolia | ✅ | ✅ | +| Avalanche / Avalanche Fuji | ✅ | ✅ | +| ZKSync Era / ZKSync Era Sepolia | ✅ | ✅ | +| Celo (mainnet) | ✅ | ✅ | +| Celo Alfajores (testnet) | ✅ | ❌ | +| Soneium / Soneium Minato | ✅ | ❌ | +| BNB Chain / BNB Chain Testnet | ❌ | ✅ | +| Gnosis Chain / Gnosis Chiado | ❌ | ✅ | +| Hyperliquid / Hyperliquid Testnet | ❌ | ✅ | +| Ink / Ink Sepolia | ❌ | ✅ | +| Jovay / Jovay Testnet | ❌ | ✅ | +| Linea / Linea Sepolia | ❌ | ✅ | +| Mantle / Mantle Sepolia | ❌ | ✅ | +| MegaETH / MegaETH Testnet 2 | ❌ | ✅ | +| Pharos / Pharos Atlantic Testnet | ❌ | ✅ | +| Plasma / Plasma Testnet | ❌ | ✅ | +| Scroll / Scroll Sepolia | ❌ | ✅ | +| Sonic / Sonic Testnet | ❌ | ✅ | +| World Chain / World Chain Sepolia | ❌ | ✅ | +| XLayer / XLayer Testnet | ❌ | ✅ | +| Apechain Curtis (testnet) | ❌ | ✅ | +| Arc Testnet | ❌ | ✅ | +| Cronos Testnet | ❌ | ✅ | +| TAC Testnet | ❌ | ✅ | +| Unichain Sepolia (testnet) | ❌ | ✅ | + +## Terminology + +| Chainlink Functions | Chainlink CRE | +| :-------------------------------------------------- | :------------------------------------------------------------------------- | +| `FunctionsClient` consumer contract | `IReceiver` consumer contract (use `ReceiverTemplate`) | +| `_sendRequest()` from a consumer | Workflow trigger: Cron, HTTP, or EVM Log | +| Inline JavaScript source (Deno sandbox) | TypeScript (or Go) workflow compiled to WASM (not compatible with node.js) | +| `Functions.makeHttpRequest()` | `runtime.http.sendRequest()` | +| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver | +| DON-hosted / remote-hosted secrets | Vault DON + `secrets.yaml` + `runtime.getSecret()` | +| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `@chainlink/cre-sdk`, `cre-cli`, `cre-templates` | +| Functions Playground UI | CRE CLI `cre workflow simulate` | +| Automation Time-based Upkeep → `sendRequest()` | Built-in Cron trigger - no Automation upkeep needed | +| `donId` + router address per chain | Chain selector + forwarder address per chain | + +## Configuration + +A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project with the following files: + +- **`main.ts`** - workflow code: trigger registration, handler logic, capability calls. +- **`config.json`** - non-secret runtime config (API URLs, contract addresses, chain selectors). +- **`secrets.yaml`** - secret declarations; values supplied via `.env`/env vars locally and via the Vault DON in production. +- **`workflow.yaml`** - workflow metadata: name, owner, secrets path, target network. +- **`project.yaml`** - project-level CRE settings. + +There is no equivalent in CLF, where the entire program is a string passed to `_sendRequest()`. + +## Triggers + +CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, off-chain trigger, reaction to an event) requires gluing CLF together with Automation, an off-chain cron, or a custom indexer. CRE makes the trigger first-class. + +### Time-based + +Replaces "Automation Time-based Upkeep calling `sendRequest()`." Use a cron trigger directly. + +```ts +const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" }) // every 5 min +``` + +Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix with `TZ=` for timezone-aware scheduling. + +### HTTP triggers + +Replaces "user transaction → `sendRequest()`" or off-chain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. + +```ts +const trigger = cre.capabilities.http.trigger({ + authorizedKeys: [{ type: "EVM", key: "0xYourAuthorizedSigner" }], +}) +``` + +`authorizedKeys` is required for deployed workflows; an empty config is only valid in simulation. + +### Onchain events + +Replaces "off-chain listener observes an event → Solidity transaction → calls `sendRequest()`." Native EVM Log trigger watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. + +```ts +const trigger = evmClient.logTrigger({ + addresses: [ + /* base64-encoded contract address */ + ], + topics: [ + /* base64-encoded event signature hash */ + ], +}) +``` + +### Per-block triggers + +CRE does not offer a "fire on every block" trigger; for high-frequency on-chain reactions, use the EVM Log trigger with a `LATEST` confidence level. For periodic state polling, use a cron trigger and call `evmClient.callContract()` from the handler. + +## Task authoring and output + +### Language and runtime + +CLF runs an inline JavaScript string (NodeJS) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. + +CRE workflows are full TypeScript (QuickJS) or Go projects compiled to WebAssembly. You manage dependencies with your normal package manager and run `cre workflow simulate` for a local execution that mirrors production. The handler is single-threaded; SDK capability calls return an object that you resolve with `.result()` (TypeScript) or `.Await()` (Go). + +### HTTP / API calls + +Direct replacement for `Functions.makeHttpRequest()`. Supports GET and POST; consensus aggregation is automatic. + +```ts +const apiKey = await runtime.getSecret({ id: "API_KEY" }).result() + +const res = await runtime.http + .sendRequest({ + url: "https://api.example.com/price", + method: "GET", + headers: { Authorization: `Bearer ${apiKey}` }, + }) + .result() + +const price = BigInt(Math.round(res.json().price * 100)) +``` + +Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `cacheSettings` so the request is only executed once across the DON. Use `runtime.now()` (not `Date.now()`) for any timestamps included in a request payload. + +### Onchain reads + +CLF has no built-in on-chain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. + +In CRE, users can read on-chain state directly inside the handler that comes with built-in chain connectivity: + +```ts +const evm = new cre.evm.EVMClient(CHAIN_SELECTOR) +const result = await evm + .callContract({ + to: CONTRACT_ADDRESS, + data: encodeFunctionData({ abi, functionName: "latestAnswer" }), + blockNumber: cre.evm.LAST_FINALIZED_BLOCK_NUMBER, + }) + .result() +``` + +You can also still use HTTP requests to interact with your own RPCs. + +### Onchain writes + +This is the biggest structural change. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. + +Two steps: ABI-encode the payload and call `runtime.report()`; then submit the signed report with `evmClient.writeReport()`. + +```ts +import { cre } from "@chainlink/cre-sdk" +import { encodeAbiParameters } from "viem" + +export async function main() { + const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" }) + + cre.handler(trigger, async (runtime) => { + const apiKey = await runtime.getSecret({ id: "API_KEY" }).result() + const res = await runtime.http + .sendRequest({ + url: "https://api.example.com/price", + headers: { Authorization: `Bearer ${apiKey}` }, + }) + .result() + + const price = BigInt(Math.round(res.json().price * 100)) + const payload = encodeAbiParameters([{ type: "uint256" }], [price]) + + const report = await runtime.report(payload).result() + const evm = new cre.evm.EVMClient(CHAIN_SELECTOR) + await evm + .writeReport({ + receiver: RECEIVER_ADDRESS, + report, + gasLimit: "200000", + }) + .result() + }) + + return cre.workflow() +} +``` + +Receiver contract: + +```solidity +import {ReceiverTemplate} from "@chainlink/cre-contracts/ReceiverTemplate.sol"; + +contract PriceReceiver is ReceiverTemplate { + uint256 public price; + + constructor(address forwarder) ReceiverTemplate(forwarder) {} + + function _onReport(bytes calldata /* metadata */, bytes calldata payload) internal override { + price = abi.decode(payload, (uint256)); + } +} +``` + +Forwarder addresses are network-specific. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See CRE documentation to learn how to permission your `IReceiver`. + +### Secrets + +CLF supports DON-hosted (uploaded once via the Functions toolkit) and user-hosted (gist URL passed at request time) secrets. CRE consolidates this through the Vault DON. + +- **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var. +- **Deployed:** upload to Vault DON via `cre secrets create`. +- **In code:** `runtime.getSecret({ id: "API_KEY" }).result()` works the same in both environments. + +Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must re-supply API keys and tokens through the CRE Vault. Fetch secrets sequentially, not in parallel. + +## Monitoring + +The CRE dashboard provides per-workflow execution history, handler logs (via `runtime.log()`), per-step timings, consensus outcomes, and on-chain submission status, replacing the per-request views in the Functions Subscription Manager. Failed executions and reverted on-chain writes surface directly in the workflow detail view. + +## Deployment and lifecycle + +| Action | Chainlink Functions | Chainlink CRE | +| :---------------- | :-------------------------------------------------------------- | :----------------------------------------------------------------------------- | +| Author code | Inline JS string in your consumer contract | TypeScript/Go project; `cre workflow init` to scaffold | +| Local test | Functions Playground / `simulateScript` | `cre workflow simulate` | +| Deploy | Deploy `FunctionsClient` consumer; create and fund subscription | Deploy `IReceiver` consumer; `cre workflow deploy`; activate workflow | +| Update logic | Re-deploy consumer (source baked into requests) or update gist | `cre workflow update` (workflow code only; receiver unchanged) | +| Pause | Cancel subscription / set consumer flag | `cre workflow pause` | +| Delete | Remove consumer; withdraw remaining LINK from the subscription | `cre workflow delete` | +| Manage secrets | DON-hosted upload via toolkit, expires after threshold | `cre secrets create / update / delete` against Vault DON | +| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | Built-in email alerts on workflow failures; UI showing executions and DON logs | + +## Get started + +1. Install the CRE CLI: see [Getting Started](/cre/getting-started/cli-installation). +2. Authenticate with the email associated with your Chainlink account. +3. `cre workflow init` to scaffold a TypeScript project; replace the trigger and handler with the equivalents from the Triggers + Task authoring sections above. +4. Deploy a `ReceiverTemplate`-based consumer contract on your target chain using the correct forwarder address. +5. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports on-chain. + +For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo. + +### Reference template for CLF migration + +The closest one-to-one mapping for the typical CLF use case ("fetch off-chain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both TypeScript and Go: + +- [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts) +- [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go) + +It demonstrates each piece of the migration end-to-end: + +- A **cron trigger** scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a **log trigger** variant (replaces an off-chain listener reacting to an on-chain event). +- An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.getSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets). +- ABI-encoding the result, calling `runtime.report()` to produce a signed report, and submitting it with `evmClient.writeReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow). +- A complete project layout — `main.ts`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source. + +If your CLF script also reads on-chain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.callContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. + +--- + # Project Setup Commands Source: https://docs.chain.link/cre/reference/cli/project-setup-ts Last Updated: 2026-03-26 diff --git a/src/content/cre/reference/clf-migration-go.mdx b/src/content/cre/reference/clf-migration-go.mdx new file mode 100644 index 00000000000..47c9d55a120 --- /dev/null +++ b/src/content/cre/reference/clf-migration-go.mdx @@ -0,0 +1,317 @@ +--- +section: cre +date: Last Modified +title: "Migrate from Chainlink Functions to Chainlink CRE" +pageId: "clf-migration" +sdkLang: "go" +metadata: + description: "Migrate from Chainlink Functions (CLF) to Chainlink CRE. Concept mapping, chain support, triggers, task authoring, secrets, onchain writes, deployment, and monitoring." + datePublished: "2026-05-11" + lastModified: "2026-05-11" +--- + +import { Aside } from "@components" + + + +This guide is for developers with production Chainlink Functions (CLF) subscriptions migrating their requests to the Chainlink Runtime Environment (CRE) before mainnet shutdown on **August 12, 2026**. + +The 80% CLF use case is "fetch off-chain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer. + +## Overview + +In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback. + +In CRE, the unit of execution is a **workflow** - a Go (or TypeScript) project compiled to WebAssembly and registered with the network. Workflows are started by **triggers** (cron schedule, HTTP request, or on-chain log event), can perform multiple steps (HTTP fetches, on-chain reads, on-chain writes, calls to other capabilities) wrapped in your own business logic, and write data on-chain through a signed-report flow that any contract implementing `IReceiver` can consume. + +Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an off-chain relayer collapse into a single workflow. + +## Chain support + +CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. Canonical list: [Supported Networks](/cre/supported-networks-go). + +Mainnet and the corresponding testnet share a row when they share parity status; rows are split where they diverge. + +| Chain | CLF | CRE | +| :-------------------------------- | :-- | :-- | +| Ethereum / Sepolia | ✅ | ✅ | +| Arbitrum One / Arbitrum Sepolia | ✅ | ✅ | +| Base / Base Sepolia | ✅ | ✅ | +| Polygon / Polygon Amoy | ✅ | ✅ | +| OP Mainnet / OP Sepolia | ✅ | ✅ | +| Avalanche / Avalanche Fuji | ✅ | ✅ | +| ZKSync Era / ZKSync Era Sepolia | ✅ | ✅ | +| Celo (mainnet) | ✅ | ✅ | +| Celo Alfajores (testnet) | ✅ | ❌ | +| Soneium / Soneium Minato | ✅ | ❌ | +| BNB Chain / BNB Chain Testnet | ❌ | ✅ | +| Gnosis Chain / Gnosis Chiado | ❌ | ✅ | +| Hyperliquid / Hyperliquid Testnet | ❌ | ✅ | +| Ink / Ink Sepolia | ❌ | ✅ | +| Jovay / Jovay Testnet | ❌ | ✅ | +| Linea / Linea Sepolia | ❌ | ✅ | +| Mantle / Mantle Sepolia | ❌ | ✅ | +| MegaETH / MegaETH Testnet 2 | ❌ | ✅ | +| Pharos / Pharos Atlantic Testnet | ❌ | ✅ | +| Plasma / Plasma Testnet | ❌ | ✅ | +| Scroll / Scroll Sepolia | ❌ | ✅ | +| Sonic / Sonic Testnet | ❌ | ✅ | +| World Chain / World Chain Sepolia | ❌ | ✅ | +| XLayer / XLayer Testnet | ❌ | ✅ | +| Apechain Curtis (testnet) | ❌ | ✅ | +| Arc Testnet | ❌ | ✅ | +| Cronos Testnet | ❌ | ✅ | +| TAC Testnet | ❌ | ✅ | +| Unichain Sepolia (testnet) | ❌ | ✅ | + +## Terminology + +| Chainlink Functions | Chainlink CRE | +| :-------------------------------------------------- | :------------------------------------------------------------------------- | +| `FunctionsClient` consumer contract | `IReceiver` consumer contract (use `ReceiverTemplate`) | +| `_sendRequest()` from a consumer | Workflow trigger: Cron, HTTP, or EVM Log | +| Inline JavaScript source (Deno sandbox) | Go (or TypeScript) workflow compiled to WASM (not compatible with node.js) | +| `Functions.makeHttpRequest()` | `http.SendRequest()` | +| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver | +| DON-hosted / remote-hosted secrets | Vault DON + `secrets.yaml` + `runtime.GetSecret()` | +| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `cre-sdk-go`, `cre-cli`, `cre-templates` | +| Functions Playground UI | CRE CLI `cre workflow simulate` | +| Automation Time-based Upkeep → `sendRequest()` | Built-in Cron trigger - no Automation upkeep needed | +| `donId` + router address per chain | Chain selector + forwarder address per chain | + +## Configuration + +A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project with the following files: + +- **`main.go`** - workflow code: trigger registration, handler logic, capability calls. +- **`config..json`** - non-secret runtime config (API URLs, contract addresses, chain selectors). +- **`secrets.yaml`** - secret declarations; values supplied via `.env`/env vars locally and via the Vault DON in production. +- **`workflow.yaml`** - workflow metadata: name, owner, secrets path, target network. +- **`project.yaml`** - project-level CRE settings. + +There is no equivalent in CLF, where the entire program is a string passed to `_sendRequest()`. + +## Triggers + +CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, off-chain trigger, reaction to an event) requires gluing CLF together with Automation, an off-chain cron, or a custom indexer. CRE makes the trigger first-class. + +### Time-based + +Replaces "Automation Time-based Upkeep calling `sendRequest()`." Use a cron trigger directly. + +```go +cronTrigger := cron.Trigger(&cron.Config{Schedule: "0 */5 * * * *"}) // every 5 min +cre.Handler(cronTrigger, onCronTrigger) +``` + +Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix with `TZ=` for timezone-aware scheduling. + +### HTTP triggers + +Replaces "user transaction → `sendRequest()`" or off-chain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. + +```go +httpTrigger := http.Trigger(&http.Config{ + AuthorizedKeys: []*http.AuthorizedKey{ + {Type: http.KeyType_EVM, Key: "0xYourAuthorizedSigner"}, + }, +}) +cre.Handler(httpTrigger, onHTTPTrigger) +``` + +`AuthorizedKeys` is required for deployed workflows; an empty config is only valid in simulation. + +### Onchain events + +Replaces "off-chain listener observes an event → Solidity transaction → calls `sendRequest()`." Native EVM Log trigger watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. + +```go +logTrigger := evmClient.LogTrigger(&evm.LogTriggerConfig{ + Addresses: [][]byte{ /* contract address bytes */ }, + Topics: [][]byte{ /* event signature hash bytes */ }, +}) +cre.Handler(logTrigger, onLog) +``` + +### Per-block triggers + +CRE does not offer a "fire on every block" trigger; for high-frequency on-chain reactions, use the EVM Log trigger with a `LATEST` confidence level. For periodic state polling, use a cron trigger and call `evmClient.CallContract()` from the handler. + +## Task authoring and output + +### Language and runtime + +CLF runs an inline JavaScript string (NodeJS) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. + +CRE workflows are full Go (or TypeScript) projects compiled to WebAssembly. You manage dependencies with Go modules and run `cre workflow simulate` for a local execution that mirrors production. The handler is single-threaded; SDK capability calls return an object that you resolve with `.Await()` (Go) or `.result()` (TypeScript). + +### HTTP / API calls + +Direct replacement for `Functions.makeHttpRequest()`. Supports GET and POST; consensus aggregation is automatic. + +```go +apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await() +if err != nil { + return err +} + +res, err := http.SendRequest(runtime, &http.Request{ + Url: "https://api.example.com/price", + Method: "GET", + Headers: map[string]string{ + "Authorization": "Bearer " + apiKey.Value, + }, +}).Await() +``` + +Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `CacheSettings` so the request is only executed once across the DON. Use `runtime.Now()` (not `time.Now()`) for any timestamps included in a request payload. + +### Onchain reads + +CLF has no built-in on-chain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. + +In CRE, users can read on-chain state directly inside the handler that comes with built-in chain connectivity: + +```go +evmClient := evm.NewClient(CHAIN_SELECTOR) +result, err := evmClient.CallContract(runtime, &evm.CallContractRequest{ + To: CONTRACT_ADDRESS, + Data: callData, + BlockNumber: evm.LastFinalizedBlockNumber, +}).Await() +``` + +You can also still use HTTP requests to interact with your own RPCs. + +### Onchain writes + +This is the biggest structural change. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. + +Two steps: ABI-encode the payload and call `runtime.GenerateReport()`; then submit the signed report with `evmClient.WriteReport()`. + +```go +package main + +import ( + "github.com/smartcontractkit/cre-sdk-go/cre" + "github.com/smartcontractkit/cre-sdk-go/capabilities/networking/http" + "github.com/smartcontractkit/cre-sdk-go/capabilities/blockchain/evm" + "github.com/smartcontractkit/cre-sdk-go/capabilities/scheduler/cron" +) + +func onCronTrigger(runtime cre.Runtime, _ *cron.Payload) (any, error) { + apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await() + if err != nil { + return nil, err + } + + res, err := http.SendRequest(runtime, &http.Request{ + Url: "https://api.example.com/price", + Headers: map[string]string{ + "Authorization": "Bearer " + apiKey.Value, + }, + }).Await() + if err != nil { + return nil, err + } + + price := parsePrice(res.Body) // ABI-encoded uint256 + payload := encodePayload(price) + + report, err := runtime.GenerateReport(&cre.ReportRequest{ + EncodedPayload: payload, + }).Await() + if err != nil { + return nil, err + } + + evmClient := evm.NewClient(CHAIN_SELECTOR) + _, err = evmClient.WriteReport(runtime, &evm.WriteReportRequest{ + Receiver: RECEIVER_ADDRESS, + Report: report, + GasConfig: &evm.GasConfig{GasLimit: 200000}, + }).Await() + return nil, err +} + +func InitWorkflow() (cre.Workflow, error) { + trigger := cron.Trigger(&cron.Config{Schedule: "*/5 * * * *"}) + return cre.Workflow{ + cre.Handler(trigger, onCronTrigger), + }, nil +} +``` + +Receiver contract: + +```solidity +import {ReceiverTemplate} from "@chainlink/cre-contracts/ReceiverTemplate.sol"; + +contract PriceReceiver is ReceiverTemplate { + uint256 public price; + + constructor(address forwarder) ReceiverTemplate(forwarder) {} + + function _onReport(bytes calldata /* metadata */, bytes calldata payload) internal override { + price = abi.decode(payload, (uint256)); + } +} +``` + +Forwarder addresses are network-specific. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See CRE documentation to learn how to permission your `IReceiver`. + +### Secrets + +CLF supports DON-hosted (uploaded once via the Functions toolkit) and user-hosted (gist URL passed at request time) secrets. CRE consolidates this through the Vault DON. + +- **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var. +- **Deployed:** upload to Vault DON via `cre secrets create`. +- **In code:** `runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()` works the same in both environments. + +Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must re-supply API keys and tokens through the CRE Vault. Fetch secrets sequentially, not in parallel. + +## Monitoring + +The CRE dashboard provides per-workflow execution history, handler logs (via `runtime.Logger()`), per-step timings, consensus outcomes, and on-chain submission status, replacing the per-request views in the Functions Subscription Manager. Failed executions and reverted on-chain writes surface directly in the workflow detail view. + +## Deployment and lifecycle + +| Action | Chainlink Functions | Chainlink CRE | +| :---------------- | :-------------------------------------------------------------- | :----------------------------------------------------------------------------- | +| Author code | Inline JS string in your consumer contract | Go/TypeScript project; `cre workflow init` to scaffold | +| Local test | Functions Playground / `simulateScript` | `cre workflow simulate` | +| Deploy | Deploy `FunctionsClient` consumer; create and fund subscription | Deploy `IReceiver` consumer; `cre workflow deploy`; activate workflow | +| Update logic | Re-deploy consumer (source baked into requests) or update gist | `cre workflow update` (workflow code only; receiver unchanged) | +| Pause | Cancel subscription / set consumer flag | `cre workflow pause` | +| Delete | Remove consumer; withdraw remaining LINK from the subscription | `cre workflow delete` | +| Manage secrets | DON-hosted upload via toolkit, expires after threshold | `cre secrets create / update / delete` against Vault DON | +| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | Built-in email alerts on workflow failures; UI showing executions and DON logs | + +## Get started + +1. Install the CRE CLI: see [Getting Started](/cre/getting-started/cli-installation). +1. Authenticate with the email associated with your Chainlink account. +1. `cre workflow init` to scaffold a Go project; replace the trigger and handler with the equivalents from the Triggers + Task authoring sections above. +1. Deploy a `ReceiverTemplate`-based consumer contract on your target chain using the correct forwarder address. +1. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports on-chain. + +For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo. + +### Reference template for CLF migration + +The closest one-to-one mapping for the typical CLF use case ("fetch off-chain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both Go and TypeScript: + +- [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go) +- [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts) + +It demonstrates each piece of the migration end-to-end: + +- A **cron trigger** scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a **log trigger** variant (replaces an off-chain listener reacting to an on-chain event). +- An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.GetSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets). +- ABI-encoding the result, calling `runtime.GenerateReport()` to produce a signed report, and submitting it with `evmClient.WriteReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow). +- A complete project layout — `main.go`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source. + +If your CLF script also reads on-chain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.CallContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. diff --git a/src/content/cre/reference/clf-migration-ts.mdx b/src/content/cre/reference/clf-migration-ts.mdx new file mode 100644 index 00000000000..e6e8ff19438 --- /dev/null +++ b/src/content/cre/reference/clf-migration-ts.mdx @@ -0,0 +1,298 @@ +--- +section: cre +date: Last Modified +title: "Migrate from Chainlink Functions to Chainlink CRE" +pageId: "clf-migration" +sdkLang: "ts" +metadata: + description: "Migrate from Chainlink Functions (CLF) to Chainlink CRE. Concept mapping, chain support, triggers, task authoring, secrets, onchain writes, deployment, and monitoring." + datePublished: "2026-05-11" + lastModified: "2026-05-11" +--- + +import { Aside } from "@components" + + + +This guide is for developers with production Chainlink Functions (CLF) subscriptions migrating their requests to the Chainlink Runtime Environment (CRE) before mainnet shutdown on **August 12, 2026**. + +The 80% CLF use case is "fetch off-chain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer. + +## Overview + +In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback. + +In CRE, the unit of execution is a **workflow** - a TypeScript (or Go) project compiled to WebAssembly and registered with the network. Workflows are started by **triggers** (cron schedule, HTTP request, or on-chain log event), can perform multiple steps (HTTP fetches, on-chain reads, on-chain writes, calls to other capabilities) wrapped in your own business logic, and write data on-chain through a signed-report flow that any contract implementing `IReceiver` can consume. + +Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an off-chain relayer collapse into a single workflow. + +## Chain support + +CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. Canonical list: [Supported Networks](/cre/supported-networks-ts). + +Mainnet and the corresponding testnet share a row when they share parity status; rows are split where they diverge. + +| Chain | CLF | CRE | +| :-------------------------------- | :-- | :-- | +| Ethereum / Sepolia | ✅ | ✅ | +| Arbitrum One / Arbitrum Sepolia | ✅ | ✅ | +| Base / Base Sepolia | ✅ | ✅ | +| Polygon / Polygon Amoy | ✅ | ✅ | +| OP Mainnet / OP Sepolia | ✅ | ✅ | +| Avalanche / Avalanche Fuji | ✅ | ✅ | +| ZKSync Era / ZKSync Era Sepolia | ✅ | ✅ | +| Celo (mainnet) | ✅ | ✅ | +| Celo Alfajores (testnet) | ✅ | ❌ | +| Soneium / Soneium Minato | ✅ | ❌ | +| BNB Chain / BNB Chain Testnet | ❌ | ✅ | +| Gnosis Chain / Gnosis Chiado | ❌ | ✅ | +| Hyperliquid / Hyperliquid Testnet | ❌ | ✅ | +| Ink / Ink Sepolia | ❌ | ✅ | +| Jovay / Jovay Testnet | ❌ | ✅ | +| Linea / Linea Sepolia | ❌ | ✅ | +| Mantle / Mantle Sepolia | ❌ | ✅ | +| MegaETH / MegaETH Testnet 2 | ❌ | ✅ | +| Pharos / Pharos Atlantic Testnet | ❌ | ✅ | +| Plasma / Plasma Testnet | ❌ | ✅ | +| Scroll / Scroll Sepolia | ❌ | ✅ | +| Sonic / Sonic Testnet | ❌ | ✅ | +| World Chain / World Chain Sepolia | ❌ | ✅ | +| XLayer / XLayer Testnet | ❌ | ✅ | +| Apechain Curtis (testnet) | ❌ | ✅ | +| Arc Testnet | ❌ | ✅ | +| Cronos Testnet | ❌ | ✅ | +| TAC Testnet | ❌ | ✅ | +| Unichain Sepolia (testnet) | ❌ | ✅ | + +## Terminology + +| Chainlink Functions | Chainlink CRE | +| :-------------------------------------------------- | :------------------------------------------------------------------------- | +| `FunctionsClient` consumer contract | `IReceiver` consumer contract (use `ReceiverTemplate`) | +| `_sendRequest()` from a consumer | Workflow trigger: Cron, HTTP, or EVM Log | +| Inline JavaScript source (Deno sandbox) | TypeScript (or Go) workflow compiled to WASM (not compatible with node.js) | +| `Functions.makeHttpRequest()` | `runtime.http.sendRequest()` | +| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver | +| DON-hosted / remote-hosted secrets | Vault DON + `secrets.yaml` + `runtime.getSecret()` | +| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `@chainlink/cre-sdk`, `cre-cli`, `cre-templates` | +| Functions Playground UI | CRE CLI `cre workflow simulate` | +| Automation Time-based Upkeep → `sendRequest()` | Built-in Cron trigger - no Automation upkeep needed | +| `donId` + router address per chain | Chain selector + forwarder address per chain | + +## Configuration + +A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project with the following files: + +- **`main.ts`** - workflow code: trigger registration, handler logic, capability calls. +- **`config.json`** - non-secret runtime config (API URLs, contract addresses, chain selectors). +- **`secrets.yaml`** - secret declarations; values supplied via `.env`/env vars locally and via the Vault DON in production. +- **`workflow.yaml`** - workflow metadata: name, owner, secrets path, target network. +- **`project.yaml`** - project-level CRE settings. + +There is no equivalent in CLF, where the entire program is a string passed to `_sendRequest()`. + +## Triggers + +CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, off-chain trigger, reaction to an event) requires gluing CLF together with Automation, an off-chain cron, or a custom indexer. CRE makes the trigger first-class. + +### Time-based + +Replaces "Automation Time-based Upkeep calling `sendRequest()`." Use a cron trigger directly. + +```ts +const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" }) // every 5 min +``` + +Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix with `TZ=` for timezone-aware scheduling. + +### HTTP triggers + +Replaces "user transaction → `sendRequest()`" or off-chain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. + +```ts +const trigger = cre.capabilities.http.trigger({ + authorizedKeys: [{ type: "EVM", key: "0xYourAuthorizedSigner" }], +}) +``` + +`authorizedKeys` is required for deployed workflows; an empty config is only valid in simulation. + +### Onchain events + +Replaces "off-chain listener observes an event → Solidity transaction → calls `sendRequest()`." Native EVM Log trigger watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. + +```ts +const trigger = evmClient.logTrigger({ + addresses: [ + /* base64-encoded contract address */ + ], + topics: [ + /* base64-encoded event signature hash */ + ], +}) +``` + +### Per-block triggers + +CRE does not offer a "fire on every block" trigger; for high-frequency on-chain reactions, use the EVM Log trigger with a `LATEST` confidence level. For periodic state polling, use a cron trigger and call `evmClient.callContract()` from the handler. + +## Task authoring and output + +### Language and runtime + +CLF runs an inline JavaScript string (NodeJS) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. + +CRE workflows are full TypeScript (QuickJS) or Go projects compiled to WebAssembly. You manage dependencies with your normal package manager and run `cre workflow simulate` for a local execution that mirrors production. The handler is single-threaded; SDK capability calls return an object that you resolve with `.result()` (TypeScript) or `.Await()` (Go). + +### HTTP / API calls + +Direct replacement for `Functions.makeHttpRequest()`. Supports GET and POST; consensus aggregation is automatic. + +```ts +const apiKey = await runtime.getSecret({ id: "API_KEY" }).result() + +const res = await runtime.http + .sendRequest({ + url: "https://api.example.com/price", + method: "GET", + headers: { Authorization: `Bearer ${apiKey}` }, + }) + .result() + +const price = BigInt(Math.round(res.json().price * 100)) +``` + +Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `cacheSettings` so the request is only executed once across the DON. Use `runtime.now()` (not `Date.now()`) for any timestamps included in a request payload. + +### Onchain reads + +CLF has no built-in on-chain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. + +In CRE, users can read on-chain state directly inside the handler that comes with built-in chain connectivity: + +```ts +const evm = new cre.evm.EVMClient(CHAIN_SELECTOR) +const result = await evm + .callContract({ + to: CONTRACT_ADDRESS, + data: encodeFunctionData({ abi, functionName: "latestAnswer" }), + blockNumber: cre.evm.LAST_FINALIZED_BLOCK_NUMBER, + }) + .result() +``` + +You can also still use HTTP requests to interact with your own RPCs. + +### Onchain writes + +This is the biggest structural change. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. + +Two steps: ABI-encode the payload and call `runtime.report()`; then submit the signed report with `evmClient.writeReport()`. + +```ts +import { cre } from "@chainlink/cre-sdk" +import { encodeAbiParameters } from "viem" + +export async function main() { + const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" }) + + cre.handler(trigger, async (runtime) => { + const apiKey = await runtime.getSecret({ id: "API_KEY" }).result() + const res = await runtime.http + .sendRequest({ + url: "https://api.example.com/price", + headers: { Authorization: `Bearer ${apiKey}` }, + }) + .result() + + const price = BigInt(Math.round(res.json().price * 100)) + const payload = encodeAbiParameters([{ type: "uint256" }], [price]) + + const report = await runtime.report(payload).result() + const evm = new cre.evm.EVMClient(CHAIN_SELECTOR) + await evm + .writeReport({ + receiver: RECEIVER_ADDRESS, + report, + gasLimit: "200000", + }) + .result() + }) + + return cre.workflow() +} +``` + +Receiver contract: + +```solidity +import {ReceiverTemplate} from "@chainlink/cre-contracts/ReceiverTemplate.sol"; + +contract PriceReceiver is ReceiverTemplate { + uint256 public price; + + constructor(address forwarder) ReceiverTemplate(forwarder) {} + + function _onReport(bytes calldata /* metadata */, bytes calldata payload) internal override { + price = abi.decode(payload, (uint256)); + } +} +``` + +Forwarder addresses are network-specific. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See CRE documentation to learn how to permission your `IReceiver`. + +### Secrets + +CLF supports DON-hosted (uploaded once via the Functions toolkit) and user-hosted (gist URL passed at request time) secrets. CRE consolidates this through the Vault DON. + +- **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var. +- **Deployed:** upload to Vault DON via `cre secrets create`. +- **In code:** `runtime.getSecret({ id: "API_KEY" }).result()` works the same in both environments. + +Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must re-supply API keys and tokens through the CRE Vault. Fetch secrets sequentially, not in parallel. + +## Monitoring + +The CRE dashboard provides per-workflow execution history, handler logs (via `runtime.log()`), per-step timings, consensus outcomes, and on-chain submission status, replacing the per-request views in the Functions Subscription Manager. Failed executions and reverted on-chain writes surface directly in the workflow detail view. + +## Deployment and lifecycle + +| Action | Chainlink Functions | Chainlink CRE | +| :---------------- | :-------------------------------------------------------------- | :----------------------------------------------------------------------------- | +| Author code | Inline JS string in your consumer contract | TypeScript/Go project; `cre workflow init` to scaffold | +| Local test | Functions Playground / `simulateScript` | `cre workflow simulate` | +| Deploy | Deploy `FunctionsClient` consumer; create and fund subscription | Deploy `IReceiver` consumer; `cre workflow deploy`; activate workflow | +| Update logic | Re-deploy consumer (source baked into requests) or update gist | `cre workflow update` (workflow code only; receiver unchanged) | +| Pause | Cancel subscription / set consumer flag | `cre workflow pause` | +| Delete | Remove consumer; withdraw remaining LINK from the subscription | `cre workflow delete` | +| Manage secrets | DON-hosted upload via toolkit, expires after threshold | `cre secrets create / update / delete` against Vault DON | +| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | Built-in email alerts on workflow failures; UI showing executions and DON logs | + +## Get started + +1. Install the CRE CLI: see [Getting Started](/cre/getting-started/cli-installation). +1. Authenticate with the email associated with your Chainlink account. +1. `cre workflow init` to scaffold a TypeScript project; replace the trigger and handler with the equivalents from the Triggers + Task authoring sections above. +1. Deploy a `ReceiverTemplate`-based consumer contract on your target chain using the correct forwarder address. +1. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports on-chain. + +For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo. + +### Reference template for CLF migration + +The closest one-to-one mapping for the typical CLF use case ("fetch off-chain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both TypeScript and Go: + +- [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts) +- [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go) + +It demonstrates each piece of the migration end-to-end: + +- A **cron trigger** scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a **log trigger** variant (replaces an off-chain listener reacting to an on-chain event). +- An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.getSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets). +- ABI-encoding the result, calling `runtime.report()` to produce a signed report, and submitting it with `evmClient.writeReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow). +- A complete project layout — `main.ts`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source. + +If your CLF script also reads on-chain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.callContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. From b94a5651304869420b41efa72af32466b96477fa Mon Sep 17 00:00:00 2001 From: Emmanuel Jacquier Date: Mon, 11 May 2026 11:23:47 -0400 Subject: [PATCH 2/8] updated chain to link to existing page --- src/content/cre/llms-full-go.txt | 38 ++----------------- src/content/cre/llms-full-ts.txt | 38 ++----------------- .../cre/reference/clf-migration-go.mdx | 38 ++----------------- .../cre/reference/clf-migration-ts.mdx | 38 ++----------------- 4 files changed, 12 insertions(+), 140 deletions(-) diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index 7ca8023da2e..c657eb13677 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -16043,41 +16043,9 @@ Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and m ## Chain support -CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. Canonical list: [Supported Networks](/cre/supported-networks-go). - -Mainnet and the corresponding testnet share a row when they share parity status; rows are split where they diverge. - -| Chain | CLF | CRE | -| :-------------------------------- | :-- | :-- | -| Ethereum / Sepolia | ✅ | ✅ | -| Arbitrum One / Arbitrum Sepolia | ✅ | ✅ | -| Base / Base Sepolia | ✅ | ✅ | -| Polygon / Polygon Amoy | ✅ | ✅ | -| OP Mainnet / OP Sepolia | ✅ | ✅ | -| Avalanche / Avalanche Fuji | ✅ | ✅ | -| ZKSync Era / ZKSync Era Sepolia | ✅ | ✅ | -| Celo (mainnet) | ✅ | ✅ | -| Celo Alfajores (testnet) | ✅ | ❌ | -| Soneium / Soneium Minato | ✅ | ❌ | -| BNB Chain / BNB Chain Testnet | ❌ | ✅ | -| Gnosis Chain / Gnosis Chiado | ❌ | ✅ | -| Hyperliquid / Hyperliquid Testnet | ❌ | ✅ | -| Ink / Ink Sepolia | ❌ | ✅ | -| Jovay / Jovay Testnet | ❌ | ✅ | -| Linea / Linea Sepolia | ❌ | ✅ | -| Mantle / Mantle Sepolia | ❌ | ✅ | -| MegaETH / MegaETH Testnet 2 | ❌ | ✅ | -| Pharos / Pharos Atlantic Testnet | ❌ | ✅ | -| Plasma / Plasma Testnet | ❌ | ✅ | -| Scroll / Scroll Sepolia | ❌ | ✅ | -| Sonic / Sonic Testnet | ❌ | ✅ | -| World Chain / World Chain Sepolia | ❌ | ✅ | -| XLayer / XLayer Testnet | ❌ | ✅ | -| Apechain Curtis (testnet) | ❌ | ✅ | -| Arc Testnet | ❌ | ✅ | -| Cronos Testnet | ❌ | ✅ | -| TAC Testnet | ❌ | ✅ | -| Unichain Sepolia (testnet) | ❌ | ✅ | +CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. + +For the canonical, up-to-date list of supported chains, see [Supported Networks](/cre/supported-networks-go). ## Terminology diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt index a8be9dafde0..375d04efcb6 100644 --- a/src/content/cre/llms-full-ts.txt +++ b/src/content/cre/llms-full-ts.txt @@ -15970,41 +15970,9 @@ Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and m ## Chain support -CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. Canonical list: [Supported Networks](/cre/supported-networks-ts). - -Mainnet and the corresponding testnet share a row when they share parity status; rows are split where they diverge. - -| Chain | CLF | CRE | -| :-------------------------------- | :-- | :-- | -| Ethereum / Sepolia | ✅ | ✅ | -| Arbitrum One / Arbitrum Sepolia | ✅ | ✅ | -| Base / Base Sepolia | ✅ | ✅ | -| Polygon / Polygon Amoy | ✅ | ✅ | -| OP Mainnet / OP Sepolia | ✅ | ✅ | -| Avalanche / Avalanche Fuji | ✅ | ✅ | -| ZKSync Era / ZKSync Era Sepolia | ✅ | ✅ | -| Celo (mainnet) | ✅ | ✅ | -| Celo Alfajores (testnet) | ✅ | ❌ | -| Soneium / Soneium Minato | ✅ | ❌ | -| BNB Chain / BNB Chain Testnet | ❌ | ✅ | -| Gnosis Chain / Gnosis Chiado | ❌ | ✅ | -| Hyperliquid / Hyperliquid Testnet | ❌ | ✅ | -| Ink / Ink Sepolia | ❌ | ✅ | -| Jovay / Jovay Testnet | ❌ | ✅ | -| Linea / Linea Sepolia | ❌ | ✅ | -| Mantle / Mantle Sepolia | ❌ | ✅ | -| MegaETH / MegaETH Testnet 2 | ❌ | ✅ | -| Pharos / Pharos Atlantic Testnet | ❌ | ✅ | -| Plasma / Plasma Testnet | ❌ | ✅ | -| Scroll / Scroll Sepolia | ❌ | ✅ | -| Sonic / Sonic Testnet | ❌ | ✅ | -| World Chain / World Chain Sepolia | ❌ | ✅ | -| XLayer / XLayer Testnet | ❌ | ✅ | -| Apechain Curtis (testnet) | ❌ | ✅ | -| Arc Testnet | ❌ | ✅ | -| Cronos Testnet | ❌ | ✅ | -| TAC Testnet | ❌ | ✅ | -| Unichain Sepolia (testnet) | ❌ | ✅ | +CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. + +For the canonical, up-to-date list of supported chains, see [Supported Networks](/cre/supported-networks-ts). ## Terminology diff --git a/src/content/cre/reference/clf-migration-go.mdx b/src/content/cre/reference/clf-migration-go.mdx index 47c9d55a120..6aaa9264059 100644 --- a/src/content/cre/reference/clf-migration-go.mdx +++ b/src/content/cre/reference/clf-migration-go.mdx @@ -31,41 +31,9 @@ Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and m ## Chain support -CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. Canonical list: [Supported Networks](/cre/supported-networks-go). - -Mainnet and the corresponding testnet share a row when they share parity status; rows are split where they diverge. - -| Chain | CLF | CRE | -| :-------------------------------- | :-- | :-- | -| Ethereum / Sepolia | ✅ | ✅ | -| Arbitrum One / Arbitrum Sepolia | ✅ | ✅ | -| Base / Base Sepolia | ✅ | ✅ | -| Polygon / Polygon Amoy | ✅ | ✅ | -| OP Mainnet / OP Sepolia | ✅ | ✅ | -| Avalanche / Avalanche Fuji | ✅ | ✅ | -| ZKSync Era / ZKSync Era Sepolia | ✅ | ✅ | -| Celo (mainnet) | ✅ | ✅ | -| Celo Alfajores (testnet) | ✅ | ❌ | -| Soneium / Soneium Minato | ✅ | ❌ | -| BNB Chain / BNB Chain Testnet | ❌ | ✅ | -| Gnosis Chain / Gnosis Chiado | ❌ | ✅ | -| Hyperliquid / Hyperliquid Testnet | ❌ | ✅ | -| Ink / Ink Sepolia | ❌ | ✅ | -| Jovay / Jovay Testnet | ❌ | ✅ | -| Linea / Linea Sepolia | ❌ | ✅ | -| Mantle / Mantle Sepolia | ❌ | ✅ | -| MegaETH / MegaETH Testnet 2 | ❌ | ✅ | -| Pharos / Pharos Atlantic Testnet | ❌ | ✅ | -| Plasma / Plasma Testnet | ❌ | ✅ | -| Scroll / Scroll Sepolia | ❌ | ✅ | -| Sonic / Sonic Testnet | ❌ | ✅ | -| World Chain / World Chain Sepolia | ❌ | ✅ | -| XLayer / XLayer Testnet | ❌ | ✅ | -| Apechain Curtis (testnet) | ❌ | ✅ | -| Arc Testnet | ❌ | ✅ | -| Cronos Testnet | ❌ | ✅ | -| TAC Testnet | ❌ | ✅ | -| Unichain Sepolia (testnet) | ❌ | ✅ | +CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. + +For the canonical, up-to-date list of supported chains, see [Supported Networks](/cre/supported-networks-go). ## Terminology diff --git a/src/content/cre/reference/clf-migration-ts.mdx b/src/content/cre/reference/clf-migration-ts.mdx index e6e8ff19438..0edc64c32a8 100644 --- a/src/content/cre/reference/clf-migration-ts.mdx +++ b/src/content/cre/reference/clf-migration-ts.mdx @@ -31,41 +31,9 @@ Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and m ## Chain support -CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. Canonical list: [Supported Networks](/cre/supported-networks-ts). - -Mainnet and the corresponding testnet share a row when they share parity status; rows are split where they diverge. - -| Chain | CLF | CRE | -| :-------------------------------- | :-- | :-- | -| Ethereum / Sepolia | ✅ | ✅ | -| Arbitrum One / Arbitrum Sepolia | ✅ | ✅ | -| Base / Base Sepolia | ✅ | ✅ | -| Polygon / Polygon Amoy | ✅ | ✅ | -| OP Mainnet / OP Sepolia | ✅ | ✅ | -| Avalanche / Avalanche Fuji | ✅ | ✅ | -| ZKSync Era / ZKSync Era Sepolia | ✅ | ✅ | -| Celo (mainnet) | ✅ | ✅ | -| Celo Alfajores (testnet) | ✅ | ❌ | -| Soneium / Soneium Minato | ✅ | ❌ | -| BNB Chain / BNB Chain Testnet | ❌ | ✅ | -| Gnosis Chain / Gnosis Chiado | ❌ | ✅ | -| Hyperliquid / Hyperliquid Testnet | ❌ | ✅ | -| Ink / Ink Sepolia | ❌ | ✅ | -| Jovay / Jovay Testnet | ❌ | ✅ | -| Linea / Linea Sepolia | ❌ | ✅ | -| Mantle / Mantle Sepolia | ❌ | ✅ | -| MegaETH / MegaETH Testnet 2 | ❌ | ✅ | -| Pharos / Pharos Atlantic Testnet | ❌ | ✅ | -| Plasma / Plasma Testnet | ❌ | ✅ | -| Scroll / Scroll Sepolia | ❌ | ✅ | -| Sonic / Sonic Testnet | ❌ | ✅ | -| World Chain / World Chain Sepolia | ❌ | ✅ | -| XLayer / XLayer Testnet | ❌ | ✅ | -| Apechain Curtis (testnet) | ❌ | ✅ | -| Arc Testnet | ❌ | ✅ | -| Cronos Testnet | ❌ | ✅ | -| TAC Testnet | ❌ | ✅ | -| Unichain Sepolia (testnet) | ❌ | ✅ | +CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. + +For the canonical, up-to-date list of supported chains, see [Supported Networks](/cre/supported-networks-ts). ## Terminology From f2aa79b427259f13f207875b7676d366dd074dff Mon Sep 17 00:00:00 2001 From: devin distefano Date: Tue, 12 May 2026 16:56:06 -0500 Subject: [PATCH 3/8] updates: crosslinking, various updates --- src/content/cre/llms-full-go.txt | 115 ++++++++++-------- src/content/cre/llms-full-ts.txt | 110 +++++++++-------- .../cre/reference/clf-migration-go.mdx | 115 ++++++++++-------- .../cre/reference/clf-migration-ts.mdx | 110 +++++++++-------- 4 files changed, 248 insertions(+), 202 deletions(-) diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index c657eb13677..6ab4b3b2569 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -16029,44 +16029,44 @@ Last Updated: 2026-05-11 sidebar to switch to the TypeScript version. -This guide is for developers with production Chainlink Functions (CLF) subscriptions migrating their requests to the Chainlink Runtime Environment (CRE) before mainnet shutdown on **August 12, 2026**. +This guide is for developers with production [Chainlink Functions (CLF)](/chainlink-functions) subscriptions migrating their requests to the [Chainlink Runtime Environment (CRE)](/cre) before mainnet shutdown on **August 12, 2026**. -The 80% CLF use case is "fetch off-chain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer. +The 80% CLF use case is "fetch offchain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written onchain to an `IReceiver` consumer. -## Overview +## How CLF and CRE differ In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback. -In CRE, the unit of execution is a **workflow** - a Go (or TypeScript) project compiled to WebAssembly and registered with the network. Workflows are started by **triggers** (cron schedule, HTTP request, or on-chain log event), can perform multiple steps (HTTP fetches, on-chain reads, on-chain writes, calls to other capabilities) wrapped in your own business logic, and write data on-chain through a signed-report flow that any contract implementing `IReceiver` can consume. +In CRE, the unit of execution is a [**workflow**](/cre/key-terms#workflow) - a Go (or TypeScript) project compiled to WebAssembly and registered with the network. Workflows are started by [**triggers**](/cre/key-terms#trigger) (cron schedule, HTTP request, or onchain log event), can perform multiple steps (HTTP fetches, onchain reads, onchain writes, calls to other [capabilities](/cre/key-terms#capability)) wrapped in your own business logic, and write data onchain through a signed-report flow that any contract implementing `IReceiver` can consume. -Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an off-chain relayer collapse into a single workflow. +Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an offchain relayer collapse into a single workflow. ## Chain support CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. -For the canonical, up-to-date list of supported chains, see [Supported Networks](/cre/supported-networks-go). +For the canonical, up-to-date list of supported chains on CRE, see [Supported Networks](/cre/supported-networks-go). ## Terminology -| Chainlink Functions | Chainlink CRE | -| :-------------------------------------------------- | :------------------------------------------------------------------------- | -| `FunctionsClient` consumer contract | `IReceiver` consumer contract (use `ReceiverTemplate`) | -| `_sendRequest()` from a consumer | Workflow trigger: Cron, HTTP, or EVM Log | -| Inline JavaScript source (Deno sandbox) | Go (or TypeScript) workflow compiled to WASM (not compatible with node.js) | -| `Functions.makeHttpRequest()` | `http.SendRequest()` | -| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver | -| DON-hosted / remote-hosted secrets | Vault DON + `secrets.yaml` + `runtime.GetSecret()` | -| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `cre-sdk-go`, `cre-cli`, `cre-templates` | -| Functions Playground UI | CRE CLI `cre workflow simulate` | -| Automation Time-based Upkeep → `sendRequest()` | Built-in Cron trigger - no Automation upkeep needed | -| `donId` + router address per chain | Chain selector + forwarder address per chain | +| Chainlink Functions | Chainlink CRE | +| :--------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| [`FunctionsClient` consumer contract](/chainlink-functions/api-reference/functions-client) | [`IReceiver` consumer contract](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) (use `ReceiverTemplate`) | +| [`_sendRequest()` from a consumer](/chainlink-functions/api-reference/functions-client) | Workflow trigger: [Cron](/cre/guides/workflow/using-triggers/cron-trigger-go), [HTTP](/cre/guides/workflow/using-triggers/http-trigger/overview-go), or [EVM Log](/cre/guides/workflow/using-triggers/evm-log-trigger-go) | +| Inline [JavaScript source](/chainlink-functions/api-reference/javascript-source) (Deno sandbox) | Go (or TypeScript) workflow compiled to WASM (not compatible with node.js) | +| [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source) | [`http.SendRequest()`](/cre/guides/workflow/using-http-client) | +| [`fulfillRequest(requestId, response, err)` callback](/chainlink-functions/api-reference/functions-client) | [`_onReport(metadata, payload)` on the receiver](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) | +| [DON-hosted / remote-hosted secrets](/chainlink-functions/resources/secrets) | [Vault DON + `secrets.yaml` + `runtime.GetSecret()`](/cre/guides/workflow/secrets) | +| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `cre-sdk-go`, `cre-cli`, `cre-templates` | +| [Functions Playground UI](/chainlink-functions/resources/simulation) / `simulateScript` | CRE CLI [`cre workflow simulate`](/cre/guides/operations/simulating-workflows) | +| [Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) → `sendRequest()` | Built-in [Cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-go) - no Automation upkeep needed | +| `donId` + router address per chain | Chain selector + [forwarder address](/cre/guides/workflow/using-evm-client/forwarder-directory-go) per chain | ## Configuration -A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project with the following files: +A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project ([full configuration reference](/cre/reference/project-configuration-go)) with the following files: -- **`main.go`** - workflow code: trigger registration, handler logic, capability calls. +- **`main.go`** - workflow code: trigger registration, [handler](/cre/key-terms#handler) logic, [capability](/cre/key-terms#capability) calls. - **`config..json`** - non-secret runtime config (API URLs, contract addresses, chain selectors). - **`secrets.yaml`** - secret declarations; values supplied via `.env`/env vars locally and via the Vault DON in production. - **`workflow.yaml`** - workflow metadata: name, owner, secrets path, target network. @@ -16076,11 +16076,11 @@ There is no equivalent in CLF, where the entire program is a string passed to `_ ## Triggers -CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, off-chain trigger, reaction to an event) requires gluing CLF together with Automation, an off-chain cron, or a custom indexer. CRE makes the trigger first-class. +CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, offchain trigger, reaction to an event) requires gluing CLF together with Automation, an offchain cron, or a custom indexer. CRE makes the [trigger](/cre/guides/workflow/using-triggers/overview) first-class. ### Time-based -Replaces "Automation Time-based Upkeep calling `sendRequest()`." Use a cron trigger directly. +Replaces "[Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) calling `sendRequest()`." Use a [cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-go) directly. ```go cronTrigger := cron.Trigger(&cron.Config{Schedule: "0 */5 * * * *"}) // every 5 min @@ -16091,7 +16091,7 @@ Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix ### HTTP triggers -Replaces "user transaction → `sendRequest()`" or off-chain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. +Replaces "user transaction → `sendRequest()`" or offchain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. See the [HTTP trigger guide](/cre/guides/workflow/using-triggers/http-trigger/overview-go) for full configuration details. ```go httpTrigger := http.Trigger(&http.Config{ @@ -16106,7 +16106,7 @@ cre.Handler(httpTrigger, onHTTPTrigger) ### Onchain events -Replaces "off-chain listener observes an event → Solidity transaction → calls `sendRequest()`." Native EVM Log trigger watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. +Replaces "offchain listener observes an event → Solidity transaction → calls `sendRequest()`." The [EVM Log trigger](/cre/guides/workflow/using-triggers/evm-log-trigger-go) watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. ```go logTrigger := evmClient.LogTrigger(&evm.LogTriggerConfig{ @@ -16118,19 +16118,26 @@ cre.Handler(logTrigger, onLog) ### Per-block triggers -CRE does not offer a "fire on every block" trigger; for high-frequency on-chain reactions, use the EVM Log trigger with a `LATEST` confidence level. For periodic state polling, use a cron trigger and call `evmClient.CallContract()` from the handler. +CRE does not offer a "fire on every block" trigger; for high-frequency onchain reactions, use the EVM Log trigger with a [`LATEST` confidence level](/cre/concepts/finality-go). For periodic state polling, use a cron trigger and call `evmClient.CallContract()` from the handler. ## Task authoring and output + + ### Language and runtime -CLF runs an inline JavaScript string (NodeJS) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. +CLF runs an inline JavaScript string (Node.js) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. -CRE workflows are full Go (or TypeScript) projects compiled to WebAssembly. You manage dependencies with Go modules and run `cre workflow simulate` for a local execution that mirrors production. The handler is single-threaded; SDK capability calls return an object that you resolve with `.Await()` (Go) or `.result()` (TypeScript). +CRE workflows are full Go (or TypeScript) projects compiled to WebAssembly. You manage dependencies with Go modules and run `cre workflow simulate` for a local execution that mirrors production. The [handler](/cre/key-terms#handler) is single-threaded; SDK capability calls return an object that you resolve with `.Await()` (Go) or `.result()` (TypeScript). ### HTTP / API calls -Direct replacement for `Functions.makeHttpRequest()`. Supports GET and POST; consensus aggregation is automatic. +Direct replacement for [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source). Supports GET and POST; consensus aggregation is automatic. See [API Interactions](/cre/guides/workflow/using-http-client) for full documentation. ```go apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await() @@ -16147,13 +16154,13 @@ res, err := http.SendRequest(runtime, &http.Request{ }).Await() ``` -Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `CacheSettings` so the request is only executed once across the DON. Use `runtime.Now()` (not `time.Now()`) for any timestamps included in a request payload. +Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `CacheSettings` so the request is only executed once across the DON. Use `runtime.Now()` (not `time.Now()`) for any timestamps included in a request payload — see [Using Time in Workflows](/cre/guides/workflow/time-in-workflows-go). ### Onchain reads -CLF has no built-in on-chain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. +CLF has no built-in onchain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. -In CRE, users can read on-chain state directly inside the handler that comes with built-in chain connectivity: +In CRE, users can read onchain state directly inside the handler that comes with built-in chain connectivity (see [Onchain Read guide](/cre/guides/workflow/using-evm-client/onchain-read-go)): ```go evmClient := evm.NewClient(CHAIN_SELECTOR) @@ -16168,7 +16175,7 @@ You can also still use HTTP requests to interact with your own RPCs. ### Onchain writes -This is the biggest structural change. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. +This is the biggest structural change. In CLF, the DON posts the response to your consumer's [`fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback](/chainlink-functions/api-reference/functions-client). In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. See the full [Onchain Write guide](/cre/guides/workflow/using-evm-client/onchain-write/overview-go). Two steps: ABI-encode the payload and call `runtime.GenerateReport()`; then submit the signed report with `evmClient.WriteReport()`. @@ -16198,8 +16205,8 @@ func onCronTrigger(runtime cre.Runtime, _ *cron.Payload) (any, error) { return nil, err } - price := parsePrice(res.Body) // ABI-encoded uint256 - payload := encodePayload(price) + price := parsePrice(res.Body) // project-specific helper: parse and scale the response body + payload := encodePayload(price) // project-specific helper: ABI-encode the value report, err := runtime.GenerateReport(&cre.ReportRequest{ EncodedPayload: payload, @@ -16241,34 +16248,38 @@ contract PriceReceiver is ReceiverTemplate { } ``` -Forwarder addresses are network-specific. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See CRE documentation to learn how to permission your `IReceiver`. +Chain selectors and forwarder addresses are network-specific; see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory-go) and [Supported Networks](/cre/supported-networks-go) for the values to substitute for `CHAIN_SELECTOR` and `RECEIVER_ADDRESS`. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) to learn how to permission your `IReceiver`. ### Secrets -CLF supports DON-hosted (uploaded once via the Functions toolkit) and user-hosted (gist URL passed at request time) secrets. CRE consolidates this through the Vault DON. +CLF supports [DON-hosted secrets](/chainlink-functions/resources/secrets) (uploaded once via the Functions toolkit) and [user-hosted secrets](/chainlink-functions/tutorials/api-use-secrets-gist) (gist URL passed at request time). CRE [consolidates this through the Vault DON](/cre/guides/workflow/secrets). - **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var. - **Deployed:** upload to Vault DON via `cre secrets create`. - **In code:** `runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()` works the same in both environments. -Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must re-supply API keys and tokens through the CRE Vault. Fetch secrets sequentially, not in parallel. + ## Monitoring -The CRE dashboard provides per-workflow execution history, handler logs (via `runtime.Logger()`), per-step timings, consensus outcomes, and on-chain submission status, replacing the per-request views in the Functions Subscription Manager. Failed executions and reverted on-chain writes surface directly in the workflow detail view. +The [CRE dashboard](/cre/guides/operations/monitoring-workflows) provides per-workflow execution history, handler logs (via `runtime.Logger()`), per-step timings, [consensus](/cre/concepts/consensus-computing) outcomes, and onchain submission status, replacing the per-request views in the [Functions Subscription Manager](/chainlink-functions/resources/subscriptions). Failed executions and reverted onchain writes surface directly in the workflow detail view. ## Deployment and lifecycle -| Action | Chainlink Functions | Chainlink CRE | -| :---------------- | :-------------------------------------------------------------- | :----------------------------------------------------------------------------- | -| Author code | Inline JS string in your consumer contract | Go/TypeScript project; `cre workflow init` to scaffold | -| Local test | Functions Playground / `simulateScript` | `cre workflow simulate` | -| Deploy | Deploy `FunctionsClient` consumer; create and fund subscription | Deploy `IReceiver` consumer; `cre workflow deploy`; activate workflow | -| Update logic | Re-deploy consumer (source baked into requests) or update gist | `cre workflow update` (workflow code only; receiver unchanged) | -| Pause | Cancel subscription / set consumer flag | `cre workflow pause` | -| Delete | Remove consumer; withdraw remaining LINK from the subscription | `cre workflow delete` | -| Manage secrets | DON-hosted upload via toolkit, expires after threshold | `cre secrets create / update / delete` against Vault DON | -| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | Built-in email alerts on workflow failures; UI showing executions and DON logs | +| Action | Chainlink Functions | Chainlink CRE | +| :---------------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Author code | Inline JS string in your consumer contract | Go/TypeScript project; `cre workflow init` to scaffold | +| Local test | [Functions Playground](/chainlink-functions/resources/simulation) / `simulateScript` | [`cre workflow simulate`](/cre/guides/operations/simulating-workflows) | +| Deploy | Deploy `FunctionsClient` consumer; [create and fund subscription](/chainlink-functions/resources/subscriptions) | Deploy `IReceiver` consumer; [`cre workflow deploy`](/cre/guides/operations/deploying-workflows); [activate workflow](/cre/guides/operations/activating-pausing-workflows) | +| Update logic | Re-deploy consumer (source baked into requests) or update gist | [`cre workflow update`](/cre/guides/operations/updating-deployed-workflows) (workflow code only; receiver unchanged) | +| Pause | Cancel subscription / set consumer flag | [`cre workflow pause`](/cre/guides/operations/activating-pausing-workflows) | +| Delete | Remove consumer; withdraw remaining LINK from the subscription | [`cre workflow delete`](/cre/guides/operations/deleting-workflows) | +| Manage secrets | [DON-hosted upload](/chainlink-functions/resources/secrets) via toolkit, expires after threshold | [`cre secrets create / update / delete`](/cre/guides/workflow/secrets) against Vault DON | +| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | [Built-in email alerts on workflow failures; UI showing executions and DON logs](/cre/guides/operations/monitoring-workflows) | ## Get started @@ -16276,25 +16287,25 @@ The CRE dashboard provides per-workflow execution history, handler logs (via `ru 2. Authenticate with the email associated with your Chainlink account. 3. `cre workflow init` to scaffold a Go project; replace the trigger and handler with the equivalents from the Triggers + Task authoring sections above. 4. Deploy a `ReceiverTemplate`-based consumer contract on your target chain using the correct forwarder address. -5. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports on-chain. +5. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports onchain. For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo. ### Reference template for CLF migration -The closest one-to-one mapping for the typical CLF use case ("fetch off-chain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both Go and TypeScript: +The closest one-to-one mapping for the typical CLF use case ("fetch offchain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both Go and TypeScript: - [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go) - [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts) It demonstrates each piece of the migration end-to-end: -- A **cron trigger** scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a **log trigger** variant (replaces an off-chain listener reacting to an on-chain event). +- A [**cron trigger**](/cre/guides/workflow/using-triggers/cron-trigger-go) scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a [**log trigger**](/cre/guides/workflow/using-triggers/evm-log-trigger-go) variant (replaces an offchain listener reacting to an onchain event). - An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.GetSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets). - ABI-encoding the result, calling `runtime.GenerateReport()` to produce a signed report, and submitting it with `evmClient.WriteReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow). - A complete project layout — `main.go`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source. -If your CLF script also reads on-chain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.CallContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. +If your CLF script also reads onchain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.CallContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. --- diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt index 375d04efcb6..83f9e13b0d9 100644 --- a/src/content/cre/llms-full-ts.txt +++ b/src/content/cre/llms-full-ts.txt @@ -15956,17 +15956,17 @@ Last Updated: 2026-05-11 sidebar to switch to the Go version. -This guide is for developers with production Chainlink Functions (CLF) subscriptions migrating their requests to the Chainlink Runtime Environment (CRE) before mainnet shutdown on **August 12, 2026**. +This guide is for developers with production [Chainlink Functions (CLF)](/chainlink-functions) subscriptions migrating their requests to the [Chainlink Runtime Environment (CRE)](/cre) before mainnet shutdown on **August 12, 2026**. -The 80% CLF use case is "fetch off-chain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer. +The 80% CLF use case is "fetch offchain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written onchain to an `IReceiver` consumer. -## Overview +## How CLF and CRE differ In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback. -In CRE, the unit of execution is a **workflow** - a TypeScript (or Go) project compiled to WebAssembly and registered with the network. Workflows are started by **triggers** (cron schedule, HTTP request, or on-chain log event), can perform multiple steps (HTTP fetches, on-chain reads, on-chain writes, calls to other capabilities) wrapped in your own business logic, and write data on-chain through a signed-report flow that any contract implementing `IReceiver` can consume. +In CRE, the unit of execution is a [**workflow**](/cre/key-terms#workflow) - a TypeScript (or Go) project compiled to WebAssembly and registered with the network. Workflows are started by [**triggers**](/cre/key-terms#trigger) (cron schedule, HTTP request, or onchain log event), can perform multiple steps (HTTP fetches, onchain reads, onchain writes, calls to other [capabilities](/cre/key-terms#capability)) wrapped in your own business logic, and write data onchain through a signed-report flow that any contract implementing `IReceiver` can consume. -Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an off-chain relayer collapse into a single workflow. +Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an offchain relayer collapse into a single workflow. ## Chain support @@ -15976,24 +15976,24 @@ For the canonical, up-to-date list of supported chains, see [Supported Networks] ## Terminology -| Chainlink Functions | Chainlink CRE | -| :-------------------------------------------------- | :------------------------------------------------------------------------- | -| `FunctionsClient` consumer contract | `IReceiver` consumer contract (use `ReceiverTemplate`) | -| `_sendRequest()` from a consumer | Workflow trigger: Cron, HTTP, or EVM Log | -| Inline JavaScript source (Deno sandbox) | TypeScript (or Go) workflow compiled to WASM (not compatible with node.js) | -| `Functions.makeHttpRequest()` | `runtime.http.sendRequest()` | -| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver | -| DON-hosted / remote-hosted secrets | Vault DON + `secrets.yaml` + `runtime.getSecret()` | -| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `@chainlink/cre-sdk`, `cre-cli`, `cre-templates` | -| Functions Playground UI | CRE CLI `cre workflow simulate` | -| Automation Time-based Upkeep → `sendRequest()` | Built-in Cron trigger - no Automation upkeep needed | -| `donId` + router address per chain | Chain selector + forwarder address per chain | +| Chainlink Functions | Chainlink CRE | +| :--------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| [`FunctionsClient` consumer contract](/chainlink-functions/api-reference/functions-client) | [`IReceiver` consumer contract](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) (use `ReceiverTemplate`) | +| [`_sendRequest()` from a consumer](/chainlink-functions/api-reference/functions-client) | Workflow trigger: [Cron](/cre/guides/workflow/using-triggers/cron-trigger-ts), [HTTP](/cre/guides/workflow/using-triggers/http-trigger/overview-ts), or [EVM Log](/cre/guides/workflow/using-triggers/evm-log-trigger-ts) | +| Inline [JavaScript source](/chainlink-functions/api-reference/javascript-source) (Deno sandbox) | TypeScript (or Go) workflow compiled to WASM (not compatible with node.js) | +| [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source) | [`runtime.http.sendRequest()`](/cre/guides/workflow/using-http-client) | +| [`fulfillRequest(requestId, response, err)` callback](/chainlink-functions/api-reference/functions-client) | [`_onReport(metadata, payload)` on the receiver](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) | +| [DON-hosted / remote-hosted secrets](/chainlink-functions/resources/secrets) | [Vault DON + `secrets.yaml` + `runtime.getSecret()`](/cre/guides/workflow/secrets) | +| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `@chainlink/cre-sdk`, `cre-cli`, `cre-templates` | +| [Functions Playground UI](/chainlink-functions/resources/simulation) / `simulateScript` | CRE CLI [`cre workflow simulate`](/cre/guides/operations/simulating-workflows) | +| [Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) → `sendRequest()` | Built-in [Cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-ts) - no Automation upkeep needed | +| `donId` + router address per chain | Chain selector + [forwarder address](/cre/guides/workflow/using-evm-client/forwarder-directory-ts) per chain | ## Configuration -A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project with the following files: +A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project ([full configuration reference](/cre/reference/project-configuration-ts)) with the following files: -- **`main.ts`** - workflow code: trigger registration, handler logic, capability calls. +- **`main.ts`** - workflow code: trigger registration, [handler](/cre/key-terms#handler) logic, [capability](/cre/key-terms#capability) calls. - **`config.json`** - non-secret runtime config (API URLs, contract addresses, chain selectors). - **`secrets.yaml`** - secret declarations; values supplied via `.env`/env vars locally and via the Vault DON in production. - **`workflow.yaml`** - workflow metadata: name, owner, secrets path, target network. @@ -16003,11 +16003,11 @@ There is no equivalent in CLF, where the entire program is a string passed to `_ ## Triggers -CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, off-chain trigger, reaction to an event) requires gluing CLF together with Automation, an off-chain cron, or a custom indexer. CRE makes the trigger first-class. +CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, offchain trigger, reaction to an event) requires gluing CLF together with Automation, an offchain cron, or a custom indexer. CRE makes the [trigger](/cre/guides/workflow/using-triggers/overview) first-class. ### Time-based -Replaces "Automation Time-based Upkeep calling `sendRequest()`." Use a cron trigger directly. +Replaces "[Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) calling `sendRequest()`." Use a [cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-ts) directly. ```ts const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" }) // every 5 min @@ -16017,7 +16017,7 @@ Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix ### HTTP triggers -Replaces "user transaction → `sendRequest()`" or off-chain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. +Replaces "user transaction → `sendRequest()`" or offchain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. See the [HTTP trigger guide](/cre/guides/workflow/using-triggers/http-trigger/overview-ts) for full configuration details. ```ts const trigger = cre.capabilities.http.trigger({ @@ -16029,9 +16029,10 @@ const trigger = cre.capabilities.http.trigger({ ### Onchain events -Replaces "off-chain listener observes an event → Solidity transaction → calls `sendRequest()`." Native EVM Log trigger watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. +Replaces "offchain listener observes an event → Solidity transaction → calls `sendRequest()`." The [EVM Log trigger](/cre/guides/workflow/using-triggers/evm-log-trigger-ts) watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. ```ts +const evmClient = new cre.evm.EVMClient(CHAIN_SELECTOR) const trigger = evmClient.logTrigger({ addresses: [ /* base64-encoded contract address */ @@ -16044,19 +16045,26 @@ const trigger = evmClient.logTrigger({ ### Per-block triggers -CRE does not offer a "fire on every block" trigger; for high-frequency on-chain reactions, use the EVM Log trigger with a `LATEST` confidence level. For periodic state polling, use a cron trigger and call `evmClient.callContract()` from the handler. +CRE does not offer a "fire on every block" trigger; for high-frequency onchain reactions, use the EVM Log trigger with a [`LATEST` confidence level](/cre/concepts/finality-ts). For periodic state polling, use a cron trigger and call `evmClient.callContract()` from the handler. ## Task authoring and output + + ### Language and runtime -CLF runs an inline JavaScript string (NodeJS) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. +CLF runs an inline JavaScript string (Node.js) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. -CRE workflows are full TypeScript (QuickJS) or Go projects compiled to WebAssembly. You manage dependencies with your normal package manager and run `cre workflow simulate` for a local execution that mirrors production. The handler is single-threaded; SDK capability calls return an object that you resolve with `.result()` (TypeScript) or `.Await()` (Go). +CRE TypeScript workflows run in a [QuickJS WASM runtime](/cre/concepts/typescript-wasm-runtime) — not Node.js or Deno. npm packages that rely on Node built-ins, native addons, or Deno APIs will not work. Pure-JS packages are generally fine. You manage dependencies with your normal package manager and run `cre workflow simulate` for a local execution that mirrors production. The [handler](/cre/key-terms#handler) is single-threaded; SDK capability calls return an object that you resolve with `.result()` (TypeScript) or `.Await()` (Go). ### HTTP / API calls -Direct replacement for `Functions.makeHttpRequest()`. Supports GET and POST; consensus aggregation is automatic. +Direct replacement for [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source). Supports GET and POST; consensus aggregation is automatic. See [API Interactions](/cre/guides/workflow/using-http-client) for full documentation. ```ts const apiKey = await runtime.getSecret({ id: "API_KEY" }).result() @@ -16072,13 +16080,13 @@ const res = await runtime.http const price = BigInt(Math.round(res.json().price * 100)) ``` -Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `cacheSettings` so the request is only executed once across the DON. Use `runtime.now()` (not `Date.now()`) for any timestamps included in a request payload. +Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `cacheSettings` so the request is only executed once across the DON. Use `runtime.now()` (not `Date.now()`) for any timestamps included in a request payload — see [Using Time in Workflows](/cre/guides/workflow/time-in-workflows-ts). ### Onchain reads -CLF has no built-in on-chain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. +CLF has no built-in onchain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. -In CRE, users can read on-chain state directly inside the handler that comes with built-in chain connectivity: +In CRE, users can read onchain state directly inside the handler that comes with built-in chain connectivity (see [Onchain Read guide](/cre/guides/workflow/using-evm-client/onchain-read-ts)): ```ts const evm = new cre.evm.EVMClient(CHAIN_SELECTOR) @@ -16095,7 +16103,7 @@ You can also still use HTTP requests to interact with your own RPCs. ### Onchain writes -This is the biggest structural change. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. +This is the biggest structural change. In CLF, the DON posts the response to your consumer's [`fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback](/chainlink-functions/api-reference/functions-client). In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. See the full [Onchain Write guide](/cre/guides/workflow/using-evm-client/onchain-write/overview-ts). Two steps: ABI-encode the payload and call `runtime.report()`; then submit the signed report with `evmClient.writeReport()`. @@ -16149,34 +16157,38 @@ contract PriceReceiver is ReceiverTemplate { } ``` -Forwarder addresses are network-specific. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See CRE documentation to learn how to permission your `IReceiver`. +Chain selectors and forwarder addresses are network-specific; see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory-ts) and [Supported Networks](/cre/supported-networks-ts) for the values to substitute for `CHAIN_SELECTOR` and `RECEIVER_ADDRESS`. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) to learn how to permission your `IReceiver`. ### Secrets -CLF supports DON-hosted (uploaded once via the Functions toolkit) and user-hosted (gist URL passed at request time) secrets. CRE consolidates this through the Vault DON. +CLF supports [DON-hosted secrets](/chainlink-functions/resources/secrets) (uploaded once via the Functions toolkit) and [user-hosted secrets](/chainlink-functions/tutorials/api-use-secrets-gist) (gist URL passed at request time). CRE [consolidates this through the Vault DON](/cre/guides/workflow/secrets). - **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var. - **Deployed:** upload to Vault DON via `cre secrets create`. - **In code:** `runtime.getSecret({ id: "API_KEY" }).result()` works the same in both environments. -Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must re-supply API keys and tokens through the CRE Vault. Fetch secrets sequentially, not in parallel. + ## Monitoring -The CRE dashboard provides per-workflow execution history, handler logs (via `runtime.log()`), per-step timings, consensus outcomes, and on-chain submission status, replacing the per-request views in the Functions Subscription Manager. Failed executions and reverted on-chain writes surface directly in the workflow detail view. +The [CRE dashboard](/cre/guides/operations/monitoring-workflows) provides per-workflow execution history, handler logs (via `runtime.log()`), per-step timings, [consensus](/cre/concepts/consensus-computing) outcomes, and onchain submission status, replacing the per-request views in the [Functions Subscription Manager](/chainlink-functions/resources/subscriptions). Failed executions and reverted onchain writes surface directly in the workflow detail view. ## Deployment and lifecycle -| Action | Chainlink Functions | Chainlink CRE | -| :---------------- | :-------------------------------------------------------------- | :----------------------------------------------------------------------------- | -| Author code | Inline JS string in your consumer contract | TypeScript/Go project; `cre workflow init` to scaffold | -| Local test | Functions Playground / `simulateScript` | `cre workflow simulate` | -| Deploy | Deploy `FunctionsClient` consumer; create and fund subscription | Deploy `IReceiver` consumer; `cre workflow deploy`; activate workflow | -| Update logic | Re-deploy consumer (source baked into requests) or update gist | `cre workflow update` (workflow code only; receiver unchanged) | -| Pause | Cancel subscription / set consumer flag | `cre workflow pause` | -| Delete | Remove consumer; withdraw remaining LINK from the subscription | `cre workflow delete` | -| Manage secrets | DON-hosted upload via toolkit, expires after threshold | `cre secrets create / update / delete` against Vault DON | -| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | Built-in email alerts on workflow failures; UI showing executions and DON logs | +| Action | Chainlink Functions | Chainlink CRE | +| :---------------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Author code | Inline JS string in your consumer contract | TypeScript/Go project; `cre workflow init` to scaffold | +| Local test | [Functions Playground](/chainlink-functions/resources/simulation) / `simulateScript` | [`cre workflow simulate`](/cre/guides/operations/simulating-workflows) | +| Deploy | Deploy `FunctionsClient` consumer; [create and fund subscription](/chainlink-functions/resources/subscriptions) | Deploy `IReceiver` consumer; [`cre workflow deploy`](/cre/guides/operations/deploying-workflows); [activate workflow](/cre/guides/operations/activating-pausing-workflows) | +| Update logic | Re-deploy consumer (source baked into requests) or update gist | [`cre workflow update`](/cre/guides/operations/updating-deployed-workflows) (workflow code only; receiver unchanged) | +| Pause | Cancel subscription / set consumer flag | [`cre workflow pause`](/cre/guides/operations/activating-pausing-workflows) | +| Delete | Remove consumer; withdraw remaining LINK from the subscription | [`cre workflow delete`](/cre/guides/operations/deleting-workflows) | +| Manage secrets | [DON-hosted upload](/chainlink-functions/resources/secrets) via toolkit, expires after threshold | [`cre secrets create / update / delete`](/cre/guides/workflow/secrets) against Vault DON | +| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | [Built-in email alerts on workflow failures; UI showing executions and DON logs](/cre/guides/operations/monitoring-workflows) | ## Get started @@ -16184,25 +16196,25 @@ The CRE dashboard provides per-workflow execution history, handler logs (via `ru 2. Authenticate with the email associated with your Chainlink account. 3. `cre workflow init` to scaffold a TypeScript project; replace the trigger and handler with the equivalents from the Triggers + Task authoring sections above. 4. Deploy a `ReceiverTemplate`-based consumer contract on your target chain using the correct forwarder address. -5. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports on-chain. +5. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports onchain. For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo. ### Reference template for CLF migration -The closest one-to-one mapping for the typical CLF use case ("fetch off-chain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both TypeScript and Go: +The closest one-to-one mapping for the typical CLF use case ("fetch offchain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both TypeScript and Go: - [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts) - [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go) It demonstrates each piece of the migration end-to-end: -- A **cron trigger** scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a **log trigger** variant (replaces an off-chain listener reacting to an on-chain event). +- A [**cron trigger**](/cre/guides/workflow/using-triggers/cron-trigger-ts) scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a [**log trigger**](/cre/guides/workflow/using-triggers/evm-log-trigger-ts) variant (replaces an offchain listener reacting to an onchain event). - An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.getSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets). - ABI-encoding the result, calling `runtime.report()` to produce a signed report, and submitting it with `evmClient.writeReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow). - A complete project layout — `main.ts`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source. -If your CLF script also reads on-chain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.callContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. +If your CLF script also reads onchain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.callContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. --- diff --git a/src/content/cre/reference/clf-migration-go.mdx b/src/content/cre/reference/clf-migration-go.mdx index 6aaa9264059..84dae1e7c1b 100644 --- a/src/content/cre/reference/clf-migration-go.mdx +++ b/src/content/cre/reference/clf-migration-go.mdx @@ -17,44 +17,44 @@ import { Aside } from "@components" sidebar to switch to the TypeScript version. -This guide is for developers with production Chainlink Functions (CLF) subscriptions migrating their requests to the Chainlink Runtime Environment (CRE) before mainnet shutdown on **August 12, 2026**. +This guide is for developers with production [Chainlink Functions (CLF)](/chainlink-functions) subscriptions migrating their requests to the [Chainlink Runtime Environment (CRE)](/cre) before mainnet shutdown on **August 12, 2026**. -The 80% CLF use case is "fetch off-chain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer. +The 80% CLF use case is "fetch offchain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written onchain to an `IReceiver` consumer. -## Overview +## How CLF and CRE differ In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback. -In CRE, the unit of execution is a **workflow** - a Go (or TypeScript) project compiled to WebAssembly and registered with the network. Workflows are started by **triggers** (cron schedule, HTTP request, or on-chain log event), can perform multiple steps (HTTP fetches, on-chain reads, on-chain writes, calls to other capabilities) wrapped in your own business logic, and write data on-chain through a signed-report flow that any contract implementing `IReceiver` can consume. +In CRE, the unit of execution is a [**workflow**](/cre/key-terms#workflow) - a Go (or TypeScript) project compiled to WebAssembly and registered with the network. Workflows are started by [**triggers**](/cre/key-terms#trigger) (cron schedule, HTTP request, or onchain log event), can perform multiple steps (HTTP fetches, onchain reads, onchain writes, calls to other [capabilities](/cre/key-terms#capability)) wrapped in your own business logic, and write data onchain through a signed-report flow that any contract implementing `IReceiver` can consume. -Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an off-chain relayer collapse into a single workflow. +Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an offchain relayer collapse into a single workflow. ## Chain support CRE supports every chain CLF runs on today **except Soneium** (mainnet and Minato testnet) and **Celo Alfajores** testnet. CRE also runs on a long list of networks that CLF never supported. -For the canonical, up-to-date list of supported chains, see [Supported Networks](/cre/supported-networks-go). +For the canonical, up-to-date list of supported chains on CRE, see [Supported Networks](/cre/supported-networks-go). ## Terminology -| Chainlink Functions | Chainlink CRE | -| :-------------------------------------------------- | :------------------------------------------------------------------------- | -| `FunctionsClient` consumer contract | `IReceiver` consumer contract (use `ReceiverTemplate`) | -| `_sendRequest()` from a consumer | Workflow trigger: Cron, HTTP, or EVM Log | -| Inline JavaScript source (Deno sandbox) | Go (or TypeScript) workflow compiled to WASM (not compatible with node.js) | -| `Functions.makeHttpRequest()` | `http.SendRequest()` | -| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver | -| DON-hosted / remote-hosted secrets | Vault DON + `secrets.yaml` + `runtime.GetSecret()` | -| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `cre-sdk-go`, `cre-cli`, `cre-templates` | -| Functions Playground UI | CRE CLI `cre workflow simulate` | -| Automation Time-based Upkeep → `sendRequest()` | Built-in Cron trigger - no Automation upkeep needed | -| `donId` + router address per chain | Chain selector + forwarder address per chain | +| Chainlink Functions | Chainlink CRE | +| :--------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| [`FunctionsClient` consumer contract](/chainlink-functions/api-reference/functions-client) | [`IReceiver` consumer contract](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) (use `ReceiverTemplate`) | +| [`_sendRequest()` from a consumer](/chainlink-functions/api-reference/functions-client) | Workflow trigger: [Cron](/cre/guides/workflow/using-triggers/cron-trigger-go), [HTTP](/cre/guides/workflow/using-triggers/http-trigger/overview-go), or [EVM Log](/cre/guides/workflow/using-triggers/evm-log-trigger-go) | +| Inline [JavaScript source](/chainlink-functions/api-reference/javascript-source) (Deno sandbox) | Go (or TypeScript) workflow compiled to WASM (not compatible with node.js) | +| [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source) | [`http.SendRequest()`](/cre/guides/workflow/using-http-client) | +| [`fulfillRequest(requestId, response, err)` callback](/chainlink-functions/api-reference/functions-client) | [`_onReport(metadata, payload)` on the receiver](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) | +| [DON-hosted / remote-hosted secrets](/chainlink-functions/resources/secrets) | [Vault DON + `secrets.yaml` + `runtime.GetSecret()`](/cre/guides/workflow/secrets) | +| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `cre-sdk-go`, `cre-cli`, `cre-templates` | +| [Functions Playground UI](/chainlink-functions/resources/simulation) / `simulateScript` | CRE CLI [`cre workflow simulate`](/cre/guides/operations/simulating-workflows) | +| [Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) → `sendRequest()` | Built-in [Cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-go) - no Automation upkeep needed | +| `donId` + router address per chain | Chain selector + [forwarder address](/cre/guides/workflow/using-evm-client/forwarder-directory-go) per chain | ## Configuration -A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project with the following files: +A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project ([full configuration reference](/cre/reference/project-configuration-go)) with the following files: -- **`main.go`** - workflow code: trigger registration, handler logic, capability calls. +- **`main.go`** - workflow code: trigger registration, [handler](/cre/key-terms#handler) logic, [capability](/cre/key-terms#capability) calls. - **`config..json`** - non-secret runtime config (API URLs, contract addresses, chain selectors). - **`secrets.yaml`** - secret declarations; values supplied via `.env`/env vars locally and via the Vault DON in production. - **`workflow.yaml`** - workflow metadata: name, owner, secrets path, target network. @@ -64,11 +64,11 @@ There is no equivalent in CLF, where the entire program is a string passed to `_ ## Triggers -CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, off-chain trigger, reaction to an event) requires gluing CLF together with Automation, an off-chain cron, or a custom indexer. CRE makes the trigger first-class. +CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, offchain trigger, reaction to an event) requires gluing CLF together with Automation, an offchain cron, or a custom indexer. CRE makes the [trigger](/cre/guides/workflow/using-triggers/overview) first-class. ### Time-based -Replaces "Automation Time-based Upkeep calling `sendRequest()`." Use a cron trigger directly. +Replaces "[Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) calling `sendRequest()`." Use a [cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-go) directly. ```go cronTrigger := cron.Trigger(&cron.Config{Schedule: "0 */5 * * * *"}) // every 5 min @@ -79,7 +79,7 @@ Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix ### HTTP triggers -Replaces "user transaction → `sendRequest()`" or off-chain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. +Replaces "user transaction → `sendRequest()`" or offchain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. See the [HTTP trigger guide](/cre/guides/workflow/using-triggers/http-trigger/overview-go) for full configuration details. ```go httpTrigger := http.Trigger(&http.Config{ @@ -94,7 +94,7 @@ cre.Handler(httpTrigger, onHTTPTrigger) ### Onchain events -Replaces "off-chain listener observes an event → Solidity transaction → calls `sendRequest()`." Native EVM Log trigger watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. +Replaces "offchain listener observes an event → Solidity transaction → calls `sendRequest()`." The [EVM Log trigger](/cre/guides/workflow/using-triggers/evm-log-trigger-go) watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. ```go logTrigger := evmClient.LogTrigger(&evm.LogTriggerConfig{ @@ -106,19 +106,26 @@ cre.Handler(logTrigger, onLog) ### Per-block triggers -CRE does not offer a "fire on every block" trigger; for high-frequency on-chain reactions, use the EVM Log trigger with a `LATEST` confidence level. For periodic state polling, use a cron trigger and call `evmClient.CallContract()` from the handler. +CRE does not offer a "fire on every block" trigger; for high-frequency onchain reactions, use the EVM Log trigger with a [`LATEST` confidence level](/cre/concepts/finality-go). For periodic state polling, use a cron trigger and call `evmClient.CallContract()` from the handler. ## Task authoring and output + + ### Language and runtime -CLF runs an inline JavaScript string (NodeJS) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. +CLF runs an inline JavaScript string (Node.js) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. -CRE workflows are full Go (or TypeScript) projects compiled to WebAssembly. You manage dependencies with Go modules and run `cre workflow simulate` for a local execution that mirrors production. The handler is single-threaded; SDK capability calls return an object that you resolve with `.Await()` (Go) or `.result()` (TypeScript). +CRE workflows are full Go (or TypeScript) projects compiled to WebAssembly. You manage dependencies with Go modules and run `cre workflow simulate` for a local execution that mirrors production. The [handler](/cre/key-terms#handler) is single-threaded; SDK capability calls return an object that you resolve with `.Await()` (Go) or `.result()` (TypeScript). ### HTTP / API calls -Direct replacement for `Functions.makeHttpRequest()`. Supports GET and POST; consensus aggregation is automatic. +Direct replacement for [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source). Supports GET and POST; consensus aggregation is automatic. See [API Interactions](/cre/guides/workflow/using-http-client) for full documentation. ```go apiKey, err := runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await() @@ -135,13 +142,13 @@ res, err := http.SendRequest(runtime, &http.Request{ }).Await() ``` -Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `CacheSettings` so the request is only executed once across the DON. Use `runtime.Now()` (not `time.Now()`) for any timestamps included in a request payload. +Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `CacheSettings` so the request is only executed once across the DON. Use `runtime.Now()` (not `time.Now()`) for any timestamps included in a request payload — see [Using Time in Workflows](/cre/guides/workflow/time-in-workflows-go). ### Onchain reads -CLF has no built-in on-chain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. +CLF has no built-in onchain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. -In CRE, users can read on-chain state directly inside the handler that comes with built-in chain connectivity: +In CRE, users can read onchain state directly inside the handler that comes with built-in chain connectivity (see [Onchain Read guide](/cre/guides/workflow/using-evm-client/onchain-read-go)): ```go evmClient := evm.NewClient(CHAIN_SELECTOR) @@ -156,7 +163,7 @@ You can also still use HTTP requests to interact with your own RPCs. ### Onchain writes -This is the biggest structural change. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. +This is the biggest structural change. In CLF, the DON posts the response to your consumer's [`fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback](/chainlink-functions/api-reference/functions-client). In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. See the full [Onchain Write guide](/cre/guides/workflow/using-evm-client/onchain-write/overview-go). Two steps: ABI-encode the payload and call `runtime.GenerateReport()`; then submit the signed report with `evmClient.WriteReport()`. @@ -186,8 +193,8 @@ func onCronTrigger(runtime cre.Runtime, _ *cron.Payload) (any, error) { return nil, err } - price := parsePrice(res.Body) // ABI-encoded uint256 - payload := encodePayload(price) + price := parsePrice(res.Body) // project-specific helper: parse and scale the response body + payload := encodePayload(price) // project-specific helper: ABI-encode the value report, err := runtime.GenerateReport(&cre.ReportRequest{ EncodedPayload: payload, @@ -229,34 +236,38 @@ contract PriceReceiver is ReceiverTemplate { } ``` -Forwarder addresses are network-specific. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See CRE documentation to learn how to permission your `IReceiver`. +Chain selectors and forwarder addresses are network-specific; see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory-go) and [Supported Networks](/cre/supported-networks-go) for the values to substitute for `CHAIN_SELECTOR` and `RECEIVER_ADDRESS`. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) to learn how to permission your `IReceiver`. ### Secrets -CLF supports DON-hosted (uploaded once via the Functions toolkit) and user-hosted (gist URL passed at request time) secrets. CRE consolidates this through the Vault DON. +CLF supports [DON-hosted secrets](/chainlink-functions/resources/secrets) (uploaded once via the Functions toolkit) and [user-hosted secrets](/chainlink-functions/tutorials/api-use-secrets-gist) (gist URL passed at request time). CRE [consolidates this through the Vault DON](/cre/guides/workflow/secrets). - **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var. - **Deployed:** upload to Vault DON via `cre secrets create`. - **In code:** `runtime.GetSecret(&cre.SecretRequest{Id: "API_KEY"}).Await()` works the same in both environments. -Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must re-supply API keys and tokens through the CRE Vault. Fetch secrets sequentially, not in parallel. + ## Monitoring -The CRE dashboard provides per-workflow execution history, handler logs (via `runtime.Logger()`), per-step timings, consensus outcomes, and on-chain submission status, replacing the per-request views in the Functions Subscription Manager. Failed executions and reverted on-chain writes surface directly in the workflow detail view. +The [CRE dashboard](/cre/guides/operations/monitoring-workflows) provides per-workflow execution history, handler logs (via `runtime.Logger()`), per-step timings, [consensus](/cre/concepts/consensus-computing) outcomes, and onchain submission status, replacing the per-request views in the [Functions Subscription Manager](/chainlink-functions/resources/subscriptions). Failed executions and reverted onchain writes surface directly in the workflow detail view. ## Deployment and lifecycle -| Action | Chainlink Functions | Chainlink CRE | -| :---------------- | :-------------------------------------------------------------- | :----------------------------------------------------------------------------- | -| Author code | Inline JS string in your consumer contract | Go/TypeScript project; `cre workflow init` to scaffold | -| Local test | Functions Playground / `simulateScript` | `cre workflow simulate` | -| Deploy | Deploy `FunctionsClient` consumer; create and fund subscription | Deploy `IReceiver` consumer; `cre workflow deploy`; activate workflow | -| Update logic | Re-deploy consumer (source baked into requests) or update gist | `cre workflow update` (workflow code only; receiver unchanged) | -| Pause | Cancel subscription / set consumer flag | `cre workflow pause` | -| Delete | Remove consumer; withdraw remaining LINK from the subscription | `cre workflow delete` | -| Manage secrets | DON-hosted upload via toolkit, expires after threshold | `cre secrets create / update / delete` against Vault DON | -| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | Built-in email alerts on workflow failures; UI showing executions and DON logs | +| Action | Chainlink Functions | Chainlink CRE | +| :---------------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Author code | Inline JS string in your consumer contract | Go/TypeScript project; `cre workflow init` to scaffold | +| Local test | [Functions Playground](/chainlink-functions/resources/simulation) / `simulateScript` | [`cre workflow simulate`](/cre/guides/operations/simulating-workflows) | +| Deploy | Deploy `FunctionsClient` consumer; [create and fund subscription](/chainlink-functions/resources/subscriptions) | Deploy `IReceiver` consumer; [`cre workflow deploy`](/cre/guides/operations/deploying-workflows); [activate workflow](/cre/guides/operations/activating-pausing-workflows) | +| Update logic | Re-deploy consumer (source baked into requests) or update gist | [`cre workflow update`](/cre/guides/operations/updating-deployed-workflows) (workflow code only; receiver unchanged) | +| Pause | Cancel subscription / set consumer flag | [`cre workflow pause`](/cre/guides/operations/activating-pausing-workflows) | +| Delete | Remove consumer; withdraw remaining LINK from the subscription | [`cre workflow delete`](/cre/guides/operations/deleting-workflows) | +| Manage secrets | [DON-hosted upload](/chainlink-functions/resources/secrets) via toolkit, expires after threshold | [`cre secrets create / update / delete`](/cre/guides/workflow/secrets) against Vault DON | +| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | [Built-in email alerts on workflow failures; UI showing executions and DON logs](/cre/guides/operations/monitoring-workflows) | ## Get started @@ -264,22 +275,22 @@ The CRE dashboard provides per-workflow execution history, handler logs (via `ru 1. Authenticate with the email associated with your Chainlink account. 1. `cre workflow init` to scaffold a Go project; replace the trigger and handler with the equivalents from the Triggers + Task authoring sections above. 1. Deploy a `ReceiverTemplate`-based consumer contract on your target chain using the correct forwarder address. -1. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports on-chain. +1. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports onchain. For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo. ### Reference template for CLF migration -The closest one-to-one mapping for the typical CLF use case ("fetch off-chain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both Go and TypeScript: +The closest one-to-one mapping for the typical CLF use case ("fetch offchain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both Go and TypeScript: - [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go) - [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts) It demonstrates each piece of the migration end-to-end: -- A **cron trigger** scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a **log trigger** variant (replaces an off-chain listener reacting to an on-chain event). +- A [**cron trigger**](/cre/guides/workflow/using-triggers/cron-trigger-go) scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a [**log trigger**](/cre/guides/workflow/using-triggers/evm-log-trigger-go) variant (replaces an offchain listener reacting to an onchain event). - An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.GetSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets). - ABI-encoding the result, calling `runtime.GenerateReport()` to produce a signed report, and submitting it with `evmClient.WriteReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow). - A complete project layout — `main.go`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source. -If your CLF script also reads on-chain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.CallContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. +If your CLF script also reads onchain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.CallContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. diff --git a/src/content/cre/reference/clf-migration-ts.mdx b/src/content/cre/reference/clf-migration-ts.mdx index 0edc64c32a8..bfb876be3a2 100644 --- a/src/content/cre/reference/clf-migration-ts.mdx +++ b/src/content/cre/reference/clf-migration-ts.mdx @@ -17,17 +17,17 @@ import { Aside } from "@components" sidebar to switch to the Go version. -This guide is for developers with production Chainlink Functions (CLF) subscriptions migrating their requests to the Chainlink Runtime Environment (CRE) before mainnet shutdown on **August 12, 2026**. +This guide is for developers with production [Chainlink Functions (CLF)](/chainlink-functions) subscriptions migrating their requests to the [Chainlink Runtime Environment (CRE)](/cre) before mainnet shutdown on **August 12, 2026**. -The 80% CLF use case is "fetch off-chain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written on-chain to an `IReceiver` consumer. +The 80% CLF use case is "fetch offchain data over HTTP and return it to a consumer contract." That maps cleanly to a CRE workflow: a trigger (Cron, HTTP, or EVM Log) → an HTTP fetch → a signed report written onchain to an `IReceiver` consumer. -## Overview +## How CLF and CRE differ In CLF, you trigger an execution by calling `sendRequest()` on your Functions consumer contract, which calls `_sendRequest()` on the Functions Router with an inline JavaScript source string. The DON runs the JS, reaches consensus on the return value, and posts it back to your consumer's `fulfillRequest()` callback. -In CRE, the unit of execution is a **workflow** - a TypeScript (or Go) project compiled to WebAssembly and registered with the network. Workflows are started by **triggers** (cron schedule, HTTP request, or on-chain log event), can perform multiple steps (HTTP fetches, on-chain reads, on-chain writes, calls to other capabilities) wrapped in your own business logic, and write data on-chain through a signed-report flow that any contract implementing `IReceiver` can consume. +In CRE, the unit of execution is a [**workflow**](/cre/key-terms#workflow) - a TypeScript (or Go) project compiled to WebAssembly and registered with the network. Workflows are started by [**triggers**](/cre/key-terms#trigger) (cron schedule, HTTP request, or onchain log event), can perform multiple steps (HTTP fetches, onchain reads, onchain writes, calls to other [capabilities](/cre/key-terms#capability)) wrapped in your own business logic, and write data onchain through a signed-report flow that any contract implementing `IReceiver` can consume. -Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an off-chain relayer collapse into a single workflow. +Functionally, CRE is a superset of CLF: anything CLF does today, CRE does, and most multi-step patterns that previously required CLF + Automation + an offchain relayer collapse into a single workflow. ## Chain support @@ -37,24 +37,24 @@ For the canonical, up-to-date list of supported chains, see [Supported Networks] ## Terminology -| Chainlink Functions | Chainlink CRE | -| :-------------------------------------------------- | :------------------------------------------------------------------------- | -| `FunctionsClient` consumer contract | `IReceiver` consumer contract (use `ReceiverTemplate`) | -| `_sendRequest()` from a consumer | Workflow trigger: Cron, HTTP, or EVM Log | -| Inline JavaScript source (Deno sandbox) | TypeScript (or Go) workflow compiled to WASM (not compatible with node.js) | -| `Functions.makeHttpRequest()` | `runtime.http.sendRequest()` | -| `fulfillRequest(requestId, response, err)` callback | `_onReport(metadata, payload)` on the receiver | -| DON-hosted / remote-hosted secrets | Vault DON + `secrets.yaml` + `runtime.getSecret()` | -| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `@chainlink/cre-sdk`, `cre-cli`, `cre-templates` | -| Functions Playground UI | CRE CLI `cre workflow simulate` | -| Automation Time-based Upkeep → `sendRequest()` | Built-in Cron trigger - no Automation upkeep needed | -| `donId` + router address per chain | Chain selector + forwarder address per chain | +| Chainlink Functions | Chainlink CRE | +| :--------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| [`FunctionsClient` consumer contract](/chainlink-functions/api-reference/functions-client) | [`IReceiver` consumer contract](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) (use `ReceiverTemplate`) | +| [`_sendRequest()` from a consumer](/chainlink-functions/api-reference/functions-client) | Workflow trigger: [Cron](/cre/guides/workflow/using-triggers/cron-trigger-ts), [HTTP](/cre/guides/workflow/using-triggers/http-trigger/overview-ts), or [EVM Log](/cre/guides/workflow/using-triggers/evm-log-trigger-ts) | +| Inline [JavaScript source](/chainlink-functions/api-reference/javascript-source) (Deno sandbox) | TypeScript (or Go) workflow compiled to WASM (not compatible with node.js) | +| [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source) | [`runtime.http.sendRequest()`](/cre/guides/workflow/using-http-client) | +| [`fulfillRequest(requestId, response, err)` callback](/chainlink-functions/api-reference/functions-client) | [`_onReport(metadata, payload)` on the receiver](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) | +| [DON-hosted / remote-hosted secrets](/chainlink-functions/resources/secrets) | [Vault DON + `secrets.yaml` + `runtime.getSecret()`](/cre/guides/workflow/secrets) | +| `@chainlink/functions-toolkit`, Hardhat Starter Kit | `@chainlink/cre-sdk`, `cre-cli`, `cre-templates` | +| [Functions Playground UI](/chainlink-functions/resources/simulation) / `simulateScript` | CRE CLI [`cre workflow simulate`](/cre/guides/operations/simulating-workflows) | +| [Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) → `sendRequest()` | Built-in [Cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-ts) - no Automation upkeep needed | +| `donId` + router address per chain | Chain selector + [forwarder address](/cre/guides/workflow/using-evm-client/forwarder-directory-ts) per chain | ## Configuration -A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project with the following files: +A CRE project is a code repo, not a stringified JS source. The CLI (`cre`) scaffolds a project ([full configuration reference](/cre/reference/project-configuration-ts)) with the following files: -- **`main.ts`** - workflow code: trigger registration, handler logic, capability calls. +- **`main.ts`** - workflow code: trigger registration, [handler](/cre/key-terms#handler) logic, [capability](/cre/key-terms#capability) calls. - **`config.json`** - non-secret runtime config (API URLs, contract addresses, chain selectors). - **`secrets.yaml`** - secret declarations; values supplied via `.env`/env vars locally and via the Vault DON in production. - **`workflow.yaml`** - workflow metadata: name, owner, secrets path, target network. @@ -64,11 +64,11 @@ There is no equivalent in CLF, where the entire program is a string passed to `_ ## Triggers -CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, off-chain trigger, reaction to an event) requires gluing CLF together with Automation, an off-chain cron, or a custom indexer. CRE makes the trigger first-class. +CLF has exactly one entry path: a Solidity transaction calling `sendRequest()`. Anything else (scheduled execution, offchain trigger, reaction to an event) requires gluing CLF together with Automation, an offchain cron, or a custom indexer. CRE makes the [trigger](/cre/guides/workflow/using-triggers/overview) first-class. ### Time-based -Replaces "Automation Time-based Upkeep calling `sendRequest()`." Use a cron trigger directly. +Replaces "[Automation Time-based Upkeep](/chainlink-functions/tutorials/automate-functions) calling `sendRequest()`." Use a [cron trigger](/cre/guides/workflow/using-triggers/cron-trigger-ts) directly. ```ts const trigger = cre.capabilities.cron.trigger({ schedule: "*/5 * * * *" }) // every 5 min @@ -78,7 +78,7 @@ Standard 5- or 6-field cron expressions; minimum interval is 30 seconds. Prefix ### HTTP triggers -Replaces "user transaction → `sendRequest()`" or off-chain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. +Replaces "user transaction → `sendRequest()`" or offchain webhook → Solidity transaction → `sendRequest()`. The workflow exposes an HTTPS endpoint on the CRE gateway; callers POST a JSON payload signed with an authorized EVM key. See the [HTTP trigger guide](/cre/guides/workflow/using-triggers/http-trigger/overview-ts) for full configuration details. ```ts const trigger = cre.capabilities.http.trigger({ @@ -90,9 +90,10 @@ const trigger = cre.capabilities.http.trigger({ ### Onchain events -Replaces "off-chain listener observes an event → Solidity transaction → calls `sendRequest()`." Native EVM Log trigger watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. +Replaces "offchain listener observes an event → Solidity transaction → calls `sendRequest()`." The [EVM Log trigger](/cre/guides/workflow/using-triggers/evm-log-trigger-ts) watches a contract address, signature event, and optional topic filters and fires the handler with the decoded event. ```ts +const evmClient = new cre.evm.EVMClient(CHAIN_SELECTOR) const trigger = evmClient.logTrigger({ addresses: [ /* base64-encoded contract address */ @@ -105,19 +106,26 @@ const trigger = evmClient.logTrigger({ ### Per-block triggers -CRE does not offer a "fire on every block" trigger; for high-frequency on-chain reactions, use the EVM Log trigger with a `LATEST` confidence level. For periodic state polling, use a cron trigger and call `evmClient.callContract()` from the handler. +CRE does not offer a "fire on every block" trigger; for high-frequency onchain reactions, use the EVM Log trigger with a [`LATEST` confidence level](/cre/concepts/finality-ts). For periodic state polling, use a cron trigger and call `evmClient.callContract()` from the handler. ## Task authoring and output + + ### Language and runtime -CLF runs an inline JavaScript string (NodeJS) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. +CLF runs an inline JavaScript string (Node.js) in a per-request sandbox. Each request is independent; there is no project, no dependencies, no compile step. -CRE workflows are full TypeScript (QuickJS) or Go projects compiled to WebAssembly. You manage dependencies with your normal package manager and run `cre workflow simulate` for a local execution that mirrors production. The handler is single-threaded; SDK capability calls return an object that you resolve with `.result()` (TypeScript) or `.Await()` (Go). +CRE TypeScript workflows run in a [QuickJS WASM runtime](/cre/concepts/typescript-wasm-runtime) — not Node.js or Deno. npm packages that rely on Node built-ins, native addons, or Deno APIs will not work. Pure-JS packages are generally fine. You manage dependencies with your normal package manager and run `cre workflow simulate` for a local execution that mirrors production. The [handler](/cre/key-terms#handler) is single-threaded; SDK capability calls return an object that you resolve with `.result()` (TypeScript) or `.Await()` (Go). ### HTTP / API calls -Direct replacement for `Functions.makeHttpRequest()`. Supports GET and POST; consensus aggregation is automatic. +Direct replacement for [`Functions.makeHttpRequest()`](/chainlink-functions/api-reference/javascript-source). Supports GET and POST; consensus aggregation is automatic. See [API Interactions](/cre/guides/workflow/using-http-client) for full documentation. ```ts const apiKey = await runtime.getSecret({ id: "API_KEY" }).result() @@ -133,13 +141,13 @@ const res = await runtime.http const price = BigInt(Math.round(res.json().price * 100)) ``` -Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `cacheSettings` so the request is only executed once across the DON. Use `runtime.now()` (not `Date.now()`) for any timestamps included in a request payload. +Caveats: 3xx redirects are not followed - point at the resolved URL directly. For non-idempotent POSTs, set `cacheSettings` so the request is only executed once across the DON. Use `runtime.now()` (not `Date.now()`) for any timestamps included in a request payload — see [Using Time in Workflows](/cre/guides/workflow/time-in-workflows-ts). ### Onchain reads -CLF has no built-in on-chain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. +CLF has no built-in onchain read; users typically pre-fetch state in Solidity before calling `_sendRequest()`, or read it inside the JS via an RPC HTTP call. -In CRE, users can read on-chain state directly inside the handler that comes with built-in chain connectivity: +In CRE, users can read onchain state directly inside the handler that comes with built-in chain connectivity (see [Onchain Read guide](/cre/guides/workflow/using-evm-client/onchain-read-ts)): ```ts const evm = new cre.evm.EVMClient(CHAIN_SELECTOR) @@ -156,7 +164,7 @@ You can also still use HTTP requests to interact with your own RPCs. ### Onchain writes -This is the biggest structural change. In CLF, the DON posts the response to your consumer's `fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback. In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. +This is the biggest structural change. In CLF, the DON posts the response to your consumer's [`fulfillRequest(bytes32 requestId, bytes response, bytes err)` callback](/chainlink-functions/api-reference/functions-client). In CRE, the workflow generates a cryptographically signed report and submits it to a consumer contract that implements `IReceiver` - typically by extending `ReceiverTemplate`. The handler is `_onReport(bytes metadata, bytes payload)`. See the full [Onchain Write guide](/cre/guides/workflow/using-evm-client/onchain-write/overview-ts). Two steps: ABI-encode the payload and call `runtime.report()`; then submit the signed report with `evmClient.writeReport()`. @@ -210,34 +218,38 @@ contract PriceReceiver is ReceiverTemplate { } ``` -Forwarder addresses are network-specific. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See CRE documentation to learn how to permission your `IReceiver`. +Chain selectors and forwarder addresses are network-specific; see the [Forwarder Directory](/cre/guides/workflow/using-evm-client/forwarder-directory-ts) and [Supported Networks](/cre/supported-networks-ts) for the values to substitute for `CHAIN_SELECTOR` and `RECEIVER_ADDRESS`. Use `MockKeystoneForwarder` for local simulation and the production `KeystoneForwarder` per chain when deploying. See [Building Consumer Contracts](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts) to learn how to permission your `IReceiver`. ### Secrets -CLF supports DON-hosted (uploaded once via the Functions toolkit) and user-hosted (gist URL passed at request time) secrets. CRE consolidates this through the Vault DON. +CLF supports [DON-hosted secrets](/chainlink-functions/resources/secrets) (uploaded once via the Functions toolkit) and [user-hosted secrets](/chainlink-functions/tutorials/api-use-secrets-gist) (gist URL passed at request time). CRE [consolidates this through the Vault DON](/cre/guides/workflow/secrets). - **Locally:** declare the name in `secrets.yaml`, supply the value via a `.env` file or env var. - **Deployed:** upload to Vault DON via `cre secrets create`. - **In code:** `runtime.getSecret({ id: "API_KEY" }).result()` works the same in both environments. -Important: **DON-hosted CLF secrets cannot be exported.** When migrating, you must re-supply API keys and tokens through the CRE Vault. Fetch secrets sequentially, not in parallel. + ## Monitoring -The CRE dashboard provides per-workflow execution history, handler logs (via `runtime.log()`), per-step timings, consensus outcomes, and on-chain submission status, replacing the per-request views in the Functions Subscription Manager. Failed executions and reverted on-chain writes surface directly in the workflow detail view. +The [CRE dashboard](/cre/guides/operations/monitoring-workflows) provides per-workflow execution history, handler logs (via `runtime.log()`), per-step timings, [consensus](/cre/concepts/consensus-computing) outcomes, and onchain submission status, replacing the per-request views in the [Functions Subscription Manager](/chainlink-functions/resources/subscriptions). Failed executions and reverted onchain writes surface directly in the workflow detail view. ## Deployment and lifecycle -| Action | Chainlink Functions | Chainlink CRE | -| :---------------- | :-------------------------------------------------------------- | :----------------------------------------------------------------------------- | -| Author code | Inline JS string in your consumer contract | TypeScript/Go project; `cre workflow init` to scaffold | -| Local test | Functions Playground / `simulateScript` | `cre workflow simulate` | -| Deploy | Deploy `FunctionsClient` consumer; create and fund subscription | Deploy `IReceiver` consumer; `cre workflow deploy`; activate workflow | -| Update logic | Re-deploy consumer (source baked into requests) or update gist | `cre workflow update` (workflow code only; receiver unchanged) | -| Pause | Cancel subscription / set consumer flag | `cre workflow pause` | -| Delete | Remove consumer; withdraw remaining LINK from the subscription | `cre workflow delete` | -| Manage secrets | DON-hosted upload via toolkit, expires after threshold | `cre secrets create / update / delete` against Vault DON | -| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | Built-in email alerts on workflow failures; UI showing executions and DON logs | +| Action | Chainlink Functions | Chainlink CRE | +| :---------------- | :-------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Author code | Inline JS string in your consumer contract | TypeScript/Go project; `cre workflow init` to scaffold | +| Local test | [Functions Playground](/chainlink-functions/resources/simulation) / `simulateScript` | [`cre workflow simulate`](/cre/guides/operations/simulating-workflows) | +| Deploy | Deploy `FunctionsClient` consumer; [create and fund subscription](/chainlink-functions/resources/subscriptions) | Deploy `IReceiver` consumer; [`cre workflow deploy`](/cre/guides/operations/deploying-workflows); [activate workflow](/cre/guides/operations/activating-pausing-workflows) | +| Update logic | Re-deploy consumer (source baked into requests) or update gist | [`cre workflow update`](/cre/guides/operations/updating-deployed-workflows) (workflow code only; receiver unchanged) | +| Pause | Cancel subscription / set consumer flag | [`cre workflow pause`](/cre/guides/operations/activating-pausing-workflows) | +| Delete | Remove consumer; withdraw remaining LINK from the subscription | [`cre workflow delete`](/cre/guides/operations/deleting-workflows) | +| Manage secrets | [DON-hosted upload](/chainlink-functions/resources/secrets) via toolkit, expires after threshold | [`cre secrets create / update / delete`](/cre/guides/workflow/secrets) against Vault DON | +| Monitor and Debug | No alerts; DON logs UI with onchain transaction data only | [Built-in email alerts on workflow failures; UI showing executions and DON logs](/cre/guides/operations/monitoring-workflows) | ## Get started @@ -245,22 +257,22 @@ The CRE dashboard provides per-workflow execution history, handler logs (via `ru 1. Authenticate with the email associated with your Chainlink account. 1. `cre workflow init` to scaffold a TypeScript project; replace the trigger and handler with the equivalents from the Triggers + Task authoring sections above. 1. Deploy a `ReceiverTemplate`-based consumer contract on your target chain using the correct forwarder address. -1. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports on-chain. +1. `cre workflow simulate` to test locally, then `cre workflow deploy`. Migrate one workflow at a time and decommission the corresponding CLF consumer once the CRE workflow is producing reports onchain. For end-to-end runnable examples covering different use cases, see the [`smartcontractkit/cre-templates`](https://github.com/smartcontractkit/cre-templates) repo. ### Reference template for CLF migration -The closest one-to-one mapping for the typical CLF use case ("fetch off-chain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both TypeScript and Go: +The closest one-to-one mapping for the typical CLF use case ("fetch offchain data over HTTP and return it to a consumer contract") is the **Custom Data Feed** starter template, available in both TypeScript and Go: - [`starter-templates/custom-data-feed/cre-custom-data-feed-ts`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-ts) - [`starter-templates/custom-data-feed/cre-custom-data-feed-go`](https://github.com/smartcontractkit/cre-templates/tree/main/starter-templates/custom-data-feed/cre-custom-data-feed-go) It demonstrates each piece of the migration end-to-end: -- A **cron trigger** scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a **log trigger** variant (replaces an off-chain listener reacting to an on-chain event). +- A [**cron trigger**](/cre/guides/workflow/using-triggers/cron-trigger-ts) scheduling the workflow (replaces an Automation Time-based Upkeep calling `sendRequest()`) and a [**log trigger**](/cre/guides/workflow/using-triggers/evm-log-trigger-ts) variant (replaces an offchain listener reacting to an onchain event). - An **HTTP fetch** against an external API with credentials pulled from the Vault DON via `runtime.getSecret()` (replaces `Functions.makeHttpRequest()` + DON-hosted secrets). - ABI-encoding the result, calling `runtime.report()` to produce a signed report, and submitting it with `evmClient.writeReport()` to a `ReceiverTemplate`-based consumer contract (replaces the `fulfillRequest()` callback flow). - A complete project layout — `main.ts`, `config.json`, `secrets.yaml`, `workflow.yaml`, `project.yaml`, contracts, and bindings — that can be cloned and adapted to your existing CLF source. -If your CLF script also reads on-chain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.callContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. +If your CLF script also reads onchain state via an RPC HTTP call, the [`building-blocks/read-data-feeds`](https://github.com/smartcontractkit/cre-templates/tree/main/building-blocks/read-data-feeds) example shows the native `evmClient.callContract()` replacement covered in the [Onchain reads](#onchain-reads) section above. From 39d620769777d479d9ffb7825a6a6b3b651e8252 Mon Sep 17 00:00:00 2001 From: devin distefano Date: Tue, 12 May 2026 17:03:54 -0500 Subject: [PATCH 4/8] update deprecation notice on clf page --- src/content/chainlink-functions/getting-started.mdx | 3 --- src/content/chainlink-functions/index.mdx | 3 --- src/content/chainlink-functions/llms-full.txt | 4 ---- .../common/ChainlinkAutomation.astro | 2 +- .../common/cre-callout-automation.mdx | 7 +++++++ .../chainlink-functions/common/cre-callout.mdx | 10 ++++++---- src/layouts/DocsLayout.astro | 2 ++ 7 files changed, 16 insertions(+), 15 deletions(-) create mode 100644 src/features/chainlink-automation/common/cre-callout-automation.mdx diff --git a/src/content/chainlink-functions/getting-started.mdx b/src/content/chainlink-functions/getting-started.mdx index 03997098f3e..b3f9af20181 100644 --- a/src/content/chainlink-functions/getting-started.mdx +++ b/src/content/chainlink-functions/getting-started.mdx @@ -13,11 +13,8 @@ whatsnext: import { Aside, CopyText, CodeSample, ClickToZoom } from "@components" import { Tabs } from "@components/Tabs" -import ChainlinkFunctions from "@features/chainlink-functions/common/ChainlinkFunctions.astro" import { YouTube } from "@astro-community/astro-embed-youtube" - - Learn how to make requests to the Chainlink Functions Decentralized Oracle Network (DON) and make any computation or API calls offchain. Chainlink Functions is available on several blockchains (see the [supported networks page](/chainlink-functions/supported-networks)), but this guide uses Sepolia to simplify access to testnet funds. Complete the following tasks to get started with Chainlink Functions: - Set up your web3 wallet and fund it with testnet tokens. diff --git a/src/content/chainlink-functions/index.mdx b/src/content/chainlink-functions/index.mdx index 988a30af7b9..03c0934966d 100644 --- a/src/content/chainlink-functions/index.mdx +++ b/src/content/chainlink-functions/index.mdx @@ -12,9 +12,6 @@ whatsnext: --- import { Aside } from "@components" -import ChainlinkFunctions from "@features/chainlink-functions/common/ChainlinkFunctions.astro" - - Chainlink Functions provides your smart contracts access to trust-minimized compute infrastructure, allowing you to fetch data from APIs and perform custom computation. Your smart contract sends source code in a request to a [Decentralized Oracle Network (DON)](/chainlink-functions/resources/concepts), and each node in the DON executes the code in a serverless environment. The DON then aggregates all the independent return values from each execution and sends the final result back to your smart contract. diff --git a/src/content/chainlink-functions/llms-full.txt b/src/content/chainlink-functions/llms-full.txt index 771ba03a57b..03896c566b2 100644 --- a/src/content/chainlink-functions/llms-full.txt +++ b/src/content/chainlink-functions/llms-full.txt @@ -397,8 +397,6 @@ const myArr = new Uint8Array(ARRAY_LENGTH) # Getting Started Source: https://docs.chain.link/chainlink-functions/getting-started - - Learn how to make requests to the Chainlink Functions Decentralized Oracle Network (DON) and make any computation or API calls offchain. Chainlink Functions is available on several blockchains (see the [supported networks page](/chainlink-functions/supported-networks)), but this guide uses Sepolia to simplify access to testnet funds. Complete the following tasks to get started with Chainlink Functions: - Set up your web3 wallet and fund it with testnet tokens. @@ -876,8 +874,6 @@ Now that you understand the structure of the API. Let's delve into the JavaScrip # Chainlink Functions Source: https://docs.chain.link/chainlink-functions - - Chainlink Functions provides your smart contracts access to trust-minimized compute infrastructure, allowing you to fetch data from APIs and perform custom computation. Your smart contract sends source code in a request to a [Decentralized Oracle Network (DON)](/chainlink-functions/resources/concepts), and each node in the DON executes the code in a serverless environment. The DON then aggregates all the independent return values from each execution and sends the final result back to your smart contract. Chainlink Functions eliminates the need for you to manage your own Chainlink node and provides decentralized offchain computation and consensus, ensuring that a minority of the network cannot manipulate the response sent back to your smart contract. diff --git a/src/features/chainlink-automation/common/ChainlinkAutomation.astro b/src/features/chainlink-automation/common/ChainlinkAutomation.astro index bf4bc6b154b..f2ae77c1b24 100644 --- a/src/features/chainlink-automation/common/ChainlinkAutomation.astro +++ b/src/features/chainlink-automation/common/ChainlinkAutomation.astro @@ -2,7 +2,7 @@ import StreamsLookupInterfaceComponent from "./StreamsLookupInterface.mdx" import ILogAutomationComponent from "./iLogAutomation.mdx" import DeprecationCalloutComponent from "./deprecation.mdx" -import CreCalloutComponent from "./cre-callout.mdx" +import CreCalloutComponent from "./cre-callout-automation.mdx" export type Props = { section?: "ilogautomation" | "streamslookup" diff --git a/src/features/chainlink-automation/common/cre-callout-automation.mdx b/src/features/chainlink-automation/common/cre-callout-automation.mdx new file mode 100644 index 00000000000..3d34ef39ee5 --- /dev/null +++ b/src/features/chainlink-automation/common/cre-callout-automation.mdx @@ -0,0 +1,7 @@ +import { Aside } from "@components" + + diff --git a/src/features/chainlink-functions/common/cre-callout.mdx b/src/features/chainlink-functions/common/cre-callout.mdx index 3d34ef39ee5..57b7854c50e 100644 --- a/src/features/chainlink-functions/common/cre-callout.mdx +++ b/src/features/chainlink-functions/common/cre-callout.mdx @@ -1,7 +1,9 @@ import { Aside } from "@components" -