Chainlink Developers

Welcome to the Chainlink documentation site. You'll find comprehensive guides and documentation to help you start working with Chainlink as quickly as possible, as well as support if you get stuck. Click here for an introductory walkthrough on how to create a Chainlink request on the Ropsten test network!

Building on Chainlink? Click here to get started!

Get Started

Adapter

An Adapter 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. Core Adapters offered by the Chainlink Node by default:

Answer

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

Bridge

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 Job Specifications.

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 on-chain. 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 developers 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.

Initiator

Triggers the execution of a Job Spec.

Available initiators are:

  • runlog
  • cron
  • ethlog
  • runat
  • web
  • execagreement

Currently only the runlog and execagreement can be used with payment to the node operator. These initiators will use the node configured MINIMUM_CONTRACT_PAYMENT, plus any additional payment if there is a bridge in the given JobID or SAID configured with a payment specified, to determine whether or not enough payment was sent along with the request.

Job

Short-hand for a Job Spec.

JobID

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

Job Run

The Job Run is the artifact documenting the outcome of executing a Job Spec. The Job Run is made up of one set of Request Parameters, a TaskRun for each Task Spec in the Job Spec, and a Run Result representing the ultimate outcome of the Job Run.

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:

  1. The Initiator list, initiators, lists out all of the ways a Job Spec can be triggered to execute.
  2. The Task list, tasks, which specifies all of the 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.

Oracle

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

Oracle Contract

The on-chain component of an Oracle. The Oracle Contract is the interface through which Consuming Contracts pass and receive data with off-chain resources.

Oracle Node

The off-chain component of an Oracle.

Requester

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.

Request Parameters

When a Job Run is requested, the full definition of all Task Specs may be filled in. The Requester can specify the rest of the Job Spec definition when requesting a Job Run by passing a JSON payload with the request. The JSON will be merged with each Task Spec before executing each Task Run.

Run

Short-hand for a Job Run, sometimes a Task Run.

Run Result

A Run Result is the result of executing a Job Spec or Task Spec. A Run Result is made up of a JSON blob, a Run Status, and an optional error field. Run Results are stored on Job Runs and Task Runs.

Run Status

Each Job Run and Task 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

SAID

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.

Spec

Another short-hand for a Job Spec.

Task

Short-hand for a Task Spec.

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.

Updated about a year ago

Glossary


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.