CCIP is now live for all developers. See what's new.



An adapter or task is a piece of software responsible for executing a specific piece of functionality. A Chainlink node comes with a number of Adapters built-in, commonly known as Core Adapters, but can also be extended via Bridges to connect with user-defined External Adapters.


The result produced from an oracle service, after all safety checks and aggregations have been performed.


Bridge is the connection between a Chainlink node and an External Adapter. The External Adapter runs as a separate service, and a Bridge facilitates communication between the node and one of these adapters.

If you would like to add a new External Adapter to your node, you create a new Bridge either in the GUI or the CLI. Within the Chainlink node, a bridge must have a unique name, but can share the same URL with other bridges. You can also set a different number of default confirmations for each bridge, and an additional payment amount. Once the bridge is added to the node, its name can then be used as a task type in Jobs.

Consumer (Contract)

Recipient of an Answer provided by an Oracle. The Consumer is commonly a contract, and is also commonly the same entity that requested the Answer, but does not have to be. We have a helper function, addExternalRequest, that gives consuming contracts the ability to safely check answers it receives without requesting them itself.

Encumbrance parameters

Encumbrance parameters are the part of a service agreement that can be enforced onchain. Information on encumbrance parameters can be found on our Wiki.

External adapter

External adapters are what make Chainlink easily extensible, providing simple integration of custom computations and specialized APIs.

A Chainlink node communicates with external adapters by sending a POST request with a JSON data payload. More information can be found on the external adapter page.

Function selector

A function selector specifies the function to be called in Ethereum. It is the first four bytes of the call data for a function call in an Ethereum transaction. Solidity contracts have a built-in helper method to access the function selector by using this.myFunction.selector, where myFunction is a non-overloaded function in the contract.


Triggers the execution of a Job Spec.


Short-hand for a Job Spec.

Job run

The Job Run is the artifact documenting the outcome of executing a Job. The Job Run is made up of a Task and a Run Result representing the ultimate outcome of the Job Run.


The ID associated to a given Job Spec. This will be unique per-node, even with the same contents within the spec itself.

Job spec

The Job Specification is the specification of a piece of work to be completed by an Oracle Node. The Job Spec is made up of two main parts:

  • The Task Type or the External Initiator: Defines the ways a Job can be triggered to execute.
  • The Task list: The tasks that specify all of the computation steps to perform when executing a Job Spec. The Task list is sometimes referred to as the Job Pipeline because all of the Tasks' operations are performed in order, with the result being fed into the next task.


Entity which connects computations on blockchains with offchain resources. Typically made up of two components: the Oracle Node (offchain) and the Oracle Contract (onchain).

Oracle contract

The onchain component of an Oracle. The Oracle Contract is the interface through which Consuming Contracts pass and receive data with offchain resources.

Oracle node

The offchain component of an Oracle.


For data feeds, a phase indicates the underlying aggregator implementation has been updated. Phases are relevant only for the EACAggregatorProxys. You can think of a roundId on the proxies as a large number containing data for two numbers (phaseId + roundId). The roundId is pulled from the aggregator's implementation and combined by bit shifting with the latest phaseId of the proxy.


A Smart Contract or Externally Owned Account which requests data from an Oracle. The Requester does not have to be the same entity as the Consumer but commonly is the same.

Run result

A Run Result is the result of executing a Job Spec.

Run status

Each Job Run has a status field indicating its current progress. The Run Status can be in one of the following states:

  • Unstarted
  • In Progress
  • Pending Confrimations
  • Pending Bridge
  • Pending Sleep
  • Errored
  • Completed


The ID associated with a given Service Agreement.

Service agreement

The Service agreement consists of a Job Spec and a set of encumbrance parameters that is shared among a creator and multiple Chainlink nodes. Information on service agreements can be found on our Wiki.


Another short-hand for a Job Spec.


A v2 job task.

Task spec

The Task Spec is the definition for an individual task to be performed within the job specification by a specific adapter. The Task Spec always includes a type field which specifies which adapter will execute it. Optionally, a Task Spec can specify additional params which will be passed on to its adapter, and confirmations which specify how many confirmations a Task Run needs before executing.

Task run

The result of the individual Task Spec's execution. A Task Run includes the Task Spec that it used for input and the Run Result which was the output of the execution.

Stay updated on the latest Chainlink news