Chainlink CRE (Chainlink Runtime Environment) is Chainlink’s orchestration layer. You write a workflow in Go or TypeScript, made of a trigger and a callback, and Chainlink decentralized oracle networks (DONs) run each step of it with consensus. One workflow can read an API, reach agreement on what it returned and write the result onchain. CRE is also the replacement Chainlink points to for Functions and Automation, both now deprecated.
This guide explains the building blocks (workflows, triggers, capabilities and DONs), why every capability call is agreed by a network and not a single server, how you build and deploy a workflow and where CRE stands today. Everything here comes from Chainlink’s documentation and posts, which we cite at the end, and from a few commands we ran ourselves, which we label.
In short: a CRE workflow is code compiled to WebAssembly. A Workflow DON watches its triggers (a schedule, an HTTP request or an onchain event) and coordinates a callback. The callback uses capabilities (HTTP, EVM read and write, Solana read and write) that run on their own DONs with Byzantine Fault Tolerant consensus. Anyone with an account can build and simulate. Deploying needs approval.
What CRE Is
Chainlink’s documentation calls CRE “the all-in-one orchestration layer” for institutional-grade smart contracts that are data-connected, compliance-ready, privacy-preserving and interoperable across blockchains and existing systems. In plain terms, it is a place to run the off-chain logic that surrounds a smart contract. Every operation runs across multiple independent nodes with Byzantine Fault Tolerant consensus, so Chainlink says workflows “inherit the same security guarantees as blockchain transactions”.
A smart contract cannot call an API, check a bank balance or run a heavy calculation. Teams used to handle that with a mix of services: an oracle for data, a keeper for scheduled actions, an offchain relayer to glue them together. Chainlink’s migration guide says most multi-step patterns that previously needed Functions, Automation and an offchain relayer “collapse into a single workflow” on CRE.
Chainlink’s launch post gives an example of what that looks like for a stablecoin issuer. The issuer starts a workflow, which calls Proof of Reserve for a secure mint check and then triggers a mint in the stablecoin smart contract. Before the tokens go to the depositor, that contract checks the Automated Compliance Engine to confirm the address is not blacklisted (see our guide to Chainlink ACE). Once approved, the workflow calls Chainlink CCIP to move the funds across chains. Several services, one program, one definition of what happens in which order.
The idea was announced at SmartCon 2024 on 30 October 2024 as “a major upgrade to the Chainlink Platform”. If you need the wider picture first, what Chainlink is covers the oracle network that CRE builds on.
How a Workflow Runs: Triggers, Capabilities and DONs
The workflow and its handlers
A workflow is code written with the CRE SDK in Go or TypeScript. CRE compiles it to a WebAssembly (WASM) binary and runs it on a Workflow DON. Inside it you define one or more handlers.
A handler connects exactly one trigger to one callback. The trigger is an event source. The callback is a function that holds your logic. A workflow can have several handlers, and the same callback can serve several triggers.
Callbacks are stateless. Each time a trigger fires, it starts a fresh execution and nothing persists between executions. If you need state, it lives onchain or in an external system you call.
Triggers
Chainlink documents four trigger types:
- Cron: fires on a schedule. Cron expressions have 5 or 6 fields and the minimum interval is 30 seconds.
- HTTP: fires when an external system sends a request to the workflow’s endpoint. Deployed HTTP triggers require authorization keys.
- EVM Log: fires when a smart contract on a supported EVM chain emits a given event.
- Solana Log: the same for programs on Solana.
Capabilities
A capability is a modular service that does one job. Chainlink lists these:
- HTTP: fetch and post data from external APIs with decentralized consensus.
- Confidential HTTP: privacy-preserving API calls that execute in an enclave.
- EVM read and write: read onchain state and write verified results to EVM chains.
- Solana read and write: the same for Solana.
You never address a capability’s network directly. The SDK gives you clients, such as an EVM client, a Solana client and an HTTP client, and a call on a client returns a promise-like value. In TypeScript you call .result() on it. In Go you call .Await(). Calls can run in parallel before you wait for them.
Workflow DON and Capability DONs
CRE uses two kinds of DON:
- A Workflow DON watches the triggers and coordinates the execution.
- A Capability DON executes one specific capability. Each capability has its own independent DON, optimized for that task.
Chainlink’s 2024 announcement describes the design as akin to a microservice per capability: each capability in a workflow is run by a separate DON, instead of one DON executing every capability of a workflow as in the earlier architecture. The post quotes Uri Sarid, Chainlink Labs Chief Architect, on how the pieces connect: CRE uses “DON-to-DON communications to connect the various capability DONs”.
The Chainlink documentation we read does not state how many nodes a Workflow DON or a Capability DON has, which fault threshold they use or which node operators run them. We do not guess at those numbers. If you want to understand what operating a node involves in general, what a Chainlink node operator does covers it.
From result to onchain write
When the callback finishes, it encodes its result. The Workflow DON then produces a report: a package of payload bytes, report context and DON signatures. A report can be sent offchain, or written onchain. For an onchain write, the signed report goes through the CRE KeystoneForwarder contract to a consumer contract that implements the IReceiver interface, which then acts on the data.
Secrets are handled separately. A workflow reads them with a secrets call, and in production they are held by the Vault DON, which stores them threshold-encrypted.
Consensus: Why Every Capability Call Is Agreed by a DON
A single server calling an API gives you the answer that one server saw. A DON gives you an answer the network agreed on. Chainlink’s documentation describes it this way: during execution, each node in the DON performs the requested task independently, and the results are cryptographically verified and aggregated through a Byzantine Fault Tolerant (BFT) consensus protocol. The aim is a single, correct and consistent outcome even if some nodes fail or misbehave.
For capabilities where Chainlink can provide that guarantee itself, you do nothing. For others, such as calling a standard API, the nodes may each see something different, so you decide how to combine their answers. The SDK has two modes:
Runtime: operations that are already BFT. Chainlink calls it easy mode.NodeRuntime: you run a function on every node in node mode and supply an aggregation, for example the median of the values or a requirement that all values are identical.
The following fragment is condensed from Chainlink’s own tutorial, “Part 2: Fetching Offchain Data” (see the tutorial page). We shortened it and did not run it. The full sample from the docs compiles with the same CLI and SDK versions. Each node fetches a random number from an API, and the median is the agreed result:
const fetchMathResult = (nodeRuntime: NodeRuntime<Config>): bigint => {
const httpClient = new HTTPClient()
const req = { url: nodeRuntime.config.apiUrl, method: "GET" as const }
const resp = httpClient.sendRequest(nodeRuntime, req).result()
const bodyText = new TextDecoder().decode(resp.body)
return BigInt(bodyText.trim())
}
// inside the callback: every node runs fetchMathResult,
// and the median of their answers becomes the result
const result = runtime.runInNodeMode(fetchMathResult, consensusMedianAggregation())().result()One caveat matters when you test. In local simulation, consensus uses a single-node model. Real multi-node BFT consensus only happens in a deployed workflow. A passing simulation therefore tells you your logic works, not that your aggregation survives disagreement between nodes.
CRE also needs a shared clock. runtime.now() returns DON Time, a timestamp computed by an Off-Chain Reporting (OCR) plugin and agreed by the participating nodes. Chainlink says not to treat it as a high-precision clock.
What stays visible to node operators
By default, a workflow’s code and data run on Workflow DON nodes, where node operators can in principle inspect what is being computed. Chainlink offers two ways to narrow that. Confidential HTTP, in production since 25 February 2026, makes API calls from inside an enclave. Confidential Workflows run a handler’s whole callback in an enclave and are marked as beta. Check the current access terms before you plan around either.
Building One: the cre CLI and SDKs
You work with CRE through the cre command line tool, which Chainlink also calls the Chainlink Developer Platform CLI. Installers exist for macOS, Linux and Windows, and the binaries are on the cre-cli releases page on GitHub. As of 21 October 2026 the latest release there is v1.39.0, while the documentation’s release notes still list v1.38.0 as newest, so expect the two to drift. The TypeScript SDK is the npm package @chainlink/cre-sdk. The Go SDK is the cre-sdk-go repository in the smartcontractkit GitHub organization.
The typical loop in the CLI reference is cre init to create a project from a template, then cre generate-bindings for contract bindings, cre workflow simulate to test and cre workflow deploy once you have approval. cre templates list shows the example workflows maintained by Chainlink, including hello-world workflows in Go and TypeScript, one that reads Data Feeds and one that migrates an Automation upkeep.
A minimal workflow
This is Chainlink’s hello-world TypeScript workflow from “Part 1: Project Setup and Simulation”, (see the tutorial page). It has one handler: a cron trigger and a callback that logs a line and returns a string.
import { CronCapability, handler, Runner, type Runtime } from "@chainlink/cre-sdk"
type Config = {
schedule: string
}
const onCronTrigger = (runtime: Runtime<Config>): string => {
runtime.log("Hello world! Workflow triggered.")
return "Hello world!"
}
const initWorkflow = (config: Config) => {
const cron = new CronCapability()
return [handler(cron.trigger({ schedule: config.schedule }), onCronTrigger)]
}
export async function main() {
const runner = await Runner.newRunner<Config>()
await runner.run(initWorkflow)
}We built this file locally with cre workflow build using CLI v1.39.0 and @chainlink/cre-sdk 1.23.0, and it compiled to a WASM binary. TypeScript builds need Bun installed: without it the CLI stops with “bun is required for TypeScript workflows but was not found in PATH”. The docs’ configuration sets the schedule to */30 * * * * *, which is every 30 seconds.
Simulate first
cre workflow simulate compiles the workflow to WASM and runs it on your machine. Chainlink is explicit that simulation makes real calls to live APIs and public EVM chains. You pick a trigger interactively or with flags, and --broadcast sends real transactions, so use it with care.
Simulation needs a CRE account. We checked this without logging in. With the CLI v1.39.0 installed, cre workflow simulate and cre init both stopped with “authentication required”, while cre version, cre templates list and cre workflow build ran normally. We did not create an account, so we did not run a simulation ourselves. The output below is an excerpt of the output shown in Chainlink’s Part 1 tutorial (the tutorial’s last two lines are left out). We did not produce it, and the sample is timestamped 3 November 2025, so the format may differ in the current CLI:
Workflow compiled
2025-11-03T19:04:21Z [SIMULATION] Simulator Initialized
2025-11-03T19:04:21Z [SIMULATION] Running trigger trigger=cron-trigger@1.0.0
2025-11-03T19:04:21Z [USER LOG] Hello world! Workflow triggered.
Workflow Simulation Result:
"Hello world!"Deploy needs approval
Deploying is where the gate sits. Chainlink’s deploy access page says: “Deploying workflows to a Chainlink DON requires approval.” You check your status with cre account access or submit a request from the terminal, and the form asks for a purpose: hackathon, evaluation or production integration.
cre workflow deploy registers the compiled workflow in a Workflow Registry. There are two modes. The public onchain registry lives on Ethereum Mainnet and needs a linked wallet key and gas. The private registry is hosted by Chainlink, is managed offchain and uses your login for authentication. Chainlink notes that private does not mean confidential. The service quota page lists limits such as three workflows per organization on the private registry, and says the values are subject to change.
CRE and the Rest of Chainlink
CRE sits next to existing Chainlink products, and the documentation is clear about which ones it replaces:
- Functions: deprecated. Chainlink’s migration guide gives 30 June 2026 for mainnet and 15 June 2026 for testnet. It calls CRE a superset of Functions: Cron, HTTP and EVM Log triggers plus an HTTP fetch and a signed report to a receiver contract cover the request and fulfil pattern.
- Automation: deprecated. v1.x was deprecated on 30 June 2026 and v2.1 on 31 July 2026. Time-based upkeeps map to a Cron trigger and log-trigger upkeeps to an EVM Log trigger, and the Automation registry becomes the CRE workflow registry.
- Streams Trade: the product that combined Data Streams with Automation. Chainlink’s Data Streams documentation says it is being deprecated in favor of CRE. Data Streams reports themselves are a separate product, described in our Data Streams guide.
- OCR: Chainlink has not announced that CRE replaces it. OCR is the protocol by which nodes aggregate observations into one report that a quorum signs and a contract verifies onchain. CRE uses an OCR plugin for DON Time.
- Data Feeds: Chainlink does not say CRE replaces them. A CRE template reads Data Feeds from a workflow, and the launch post’s stablecoin example calls Proof of Reserve.
- CCIP and ACE: workflows can call CCIP to move funds across chains, and the contracts they trigger can check ACE for compliance, as in the stablecoin example above.
If you run production code on Functions or Automation, the practical step is to read the migration guides, which include an automation-migration-ts template.
Where It Stands Today
The status is easy to misstate, so here are the dates and the wording from Chainlink’s sources, as of 23 October 2026:
- 30 October 2024: CRE announced at SmartCon 2024.
- 4 November 2025: Chainlink’s release notes say CRE “is now live”. Building and simulating workflows was available, and deploying to a DON was Early Access.
- Now: the documentation says deploying requires approval, while building and simulating need an account but no approval. The service quota page says registry quotas are “being actively tuned ahead of general availability”. We found no general availability announcement or date.
CRE changes quickly. Solana reads and Solana log triggers arrived on 19 October 2026, after Solana writes. The chain list grows often, so we do not print a count here. The documentation covers EVM chains and Solana, and cre workflow supported-chains (after you log in) shows the chains enabled for your organization. Check the supported networks page before you plan around a specific chain.
On adoption, we only repeat what Chainlink says, with the date. Chainlink’s launch post of 4 November 2025 says 21X, an EU-regulated onchain exchange for tokenized securities, adopted CRE in production for post-trade data, and that Crypto Finance (Deutsche Börse Group) used it to orchestrate a Proof of Reserve feed. It describes Westpac Institutional Bank and Imperium Markets as implementing CRE in Project Acacia, and Swift, Euroclear and other market participants as part of an industry initiative on corporate actions. These are Chainlink’s statements, and the pilots are pilots. We have not verified anything newer from a primary source.
For the oracle side of the picture, see Matrixed.Link’s Chainlink oracle services. The example code in Chainlink’s docs carries its own disclaimer: it is provided as is, has not been audited and should not be used in production without your own audit.
Sources & References
- Chainlink Documentation, What is Chainlink Runtime Environment (CRE)?
- Chainlink Documentation, Key Terms and Concepts
- Chainlink Documentation, Capabilities
- Chainlink Documentation, Triggers
- Chainlink Documentation, Consensus Computing
- Chainlink Documentation, Part 1: Project Setup and Simulation
- Chainlink Documentation, Part 2: Fetching Offchain Data
- Chainlink Documentation, Simulating Workflows
- Chainlink Documentation, CRE CLI Reference
- Chainlink Documentation, Deploy Access
- Chainlink Documentation, Service Quotas
- Chainlink Documentation, CRE Release Notes
- Chainlink Documentation, Supported Networks
- Chainlink Documentation, Migrate from Chainlink Functions
- Chainlink Documentation, Migrate from Chainlink Automation
- Chainlink Documentation, Data Streams Architecture
- Chainlink Documentation, Off-Chain Reporting
- Chainlink Blog, Introducing Chainlink Runtime Environment (CRE)
- Chainlink Blog, Chainlink Runtime Environment Now Live
- GitHub, smartcontractkit/cre-cli releases
Work with Matrixed.Link
Matrixed.Link operates Chainlink oracle infrastructure, validator nodes and full-stack blockchain infrastructure for protocols and institutions that need institutional-grade reliability. Official Chainlink node operator running Data Feeds, CRE, SVR and Proof of Reserve. ISO/IEC 27001:2022 certified. AAA-rated provider on StakingRewards.
Contact Matrixed.Link to discuss Chainlink oracle infrastructure for your protocol.
