Key Terms and Concepts

This page defines the fundamental terms and concepts for the Chainlink Runtime Environment (CRE).

High-level concepts

The all-in-one orchestration layer unlocking institutional-grade smart contracts—data-connected, compliance-ready, privacy-preserving, and interoperable across blockchains and existing systems

Decentralized Oracle Network (DON)

A decentralized, peer-to-peer network of independent nodes that work together to execute a specific task. In CRE, there are two primary types of DONs: Workflow DONs that orchestrates the workflow, and specialized Capability DONs that execute specific tasks like blockchain interactions.

Control plane

How you manage a workflow's lifecycle (deploy, activate, pause, update, delete) and its secrets. CRE supports two modes, selected per target via user-workflow.deployment-registry in workflow.yaml:

  • Web3 key — operations sign onchain transactions to the public Workflow Registry contract on Ethereum Mainnet. Requires a linked wallet key and gas for registry transactions. Used when deployment-registry: "onchain:ethereum-mainnet".
  • Auth only — operations are authorized by your CRE login session against the Chainlink-hosted private registry. No wallet, no Ethereum Mainnet RPC, and no gas are required for registry management. Used when deployment-registry: "private".

See Choosing your registry for the deploy-time view and Auth modes for the secrets equivalent.

Public workflow

A workflow whose lifecycle is managed through the public onchain Workflow Registry. In workflow.yaml, this is selected with deployment-registry: "onchain:ethereum-mainnet".

Private workflow

A workflow whose lifecycle is managed through the Chainlink-hosted private registry. In workflow.yaml, this is selected with deployment-registry: "private". Private workflow management is centralized and offchain.

Private does not mean confidential. A private workflow uses a private registry for management, but its execution is not confidential unless it explicitly uses a confidential execution feature or capability.

Confidential workflow or confidential execution

Execution that uses a confidential runtime, TEE, enclave, or confidential capability to protect data during execution. This is separate from registry selection. Confidential execution does not require the private registry, and a workflow can use confidential execution while still being managed through the public onchain registry.

Workflow architecture

Workflow

A workflow uses the CRE SDK (Go or TypeScript) and comprises one or more handlers, which define the logic that executes when events (triggers) occur. CRE compiles the workflow to a WASM binary and runs it on a Workflow DON.

Handler

The basic building block of a workflow, created using the cre.Handler function. It connects a single Trigger event to a single Callback function.

Trigger

An event source that initiates the execution of a handler's callback function. Examples include Cron trigger, HTTP trigger, and EVM Log trigger. Learn more in the Trigger capability page.

Callback

A function that contains your core logic. It is executed by the Workflow DON every time its corresponding trigger fires.

The developer's toolkit: The CRE SDK

Runtime & NodeRuntime

Short-lived objects passed to your callback function during a specific execution. The key difference between Runtime and NodeRuntime is who is responsible for creating a single, trusted result from the work of many nodes.

  • Runtime: Think of it as the "Easy Mode". It is used for operations that are guaranteed to be Byzantine Fault Tolerant (BFT). You ask the network to execute something, and CRE handles the underlying complexity to ensure you get back one final, secure, and trustworthy result.

  • NodeRuntime: Think of this as the "Manual Mode". It is used when a BFT guarantee cannot be provided automatically (e.g. calling a standard API). You tell each node to perform a task on its own. Each node returns its own individual answer, and you are responsible for telling the SDK how to combine them into a single, trusted result by providing an aggregation algorithm. This is always used inside a cre.RunInNodeMode block.

Learn more about Consensus and Aggregation.

SDK Clients: EVMClient & HTTPClient

The primary SDK clients you use inside a callback to interact with capabilities. For example, you use an EVM client to read from a smart contract and an HTTP client to make offchain API requests.

Language-specific implementations:

  • Go SDK: evm.Client and http.Client
  • TypeScript SDK: EVMClient and HTTPClient classes

Bindings (Go SDK only)

A Go package generated from a smart contract's ABI using the cre generate-bindings CLI command. Bindings create a type-safe Go interface for a specific smart contract, abstracting away the low-level complexity of ABI encoding and decoding.

Using generated bindings is the recommended best practice for Go workflows, as they provide helper methods for:

  • Reading from view/pure functions.
  • Encoding data structures for onchain writes.
  • Creating triggers for and decoding event logs.

This makes your workflow code cleaner, safer, and easier to maintain. Learn more in the Generating Contract Bindings guide.

Note for TypeScript: The TypeScript SDK uses Viem for type-safe contract interactions with manual ABI definitions instead of generated bindings.

Async Patterns

Asynchronous operations in the SDK (like contract reads or HTTP requests) return a placeholder for a future result:

  • Go SDK: Operations return a Promise, and you must call .Await() to pause execution and wait for the result.
  • TypeScript SDK: Operations return an object with a .result() method that you call to wait for the result.

Secrets

Securely managed credentials (e.g., API keys) made available to your workflow at runtime. Secrets can be fetched within a callback using the runtime's secret retrieval method:

  • Go SDK: runtime.GetSecret()
  • TypeScript SDK: runtime.getSecret()

Underlying architectural concepts

Capability

A conceptual, decentralized "microservice" that is backed by its own DON. Capabilities are the fundamental building blocks of the CRE platform (e.g., HTTP Fetch, EVM Read). You do not interact with them directly; instead, you use the SDK's developer-facing clients (like evm.Client) to invoke them.

Consensus

The mechanism by which a DON comes to a single, reliable, and tamper-proof result, even if individual nodes observe slightly different data. Consensus is what makes the outputs of capabilities secure and trustworthy.

Where to go next?

  • Getting Started: Start building your first workflow.
  • About CRE: Learn more about the vision and high-level architecture of CRE.

Get the latest Chainlink content straight to your inbox.