Job Types

This guide outlines different job types.

Solidity cron jobs

Executes a job on a schedule. Does not rely on any kind of external trigger.

Spec format

type            = "cron"
schemaVersion   = 1
evmChainID      = 1
schedule        = "CRON_TZ=UTC * */20 * * * *"
externalJobID       = "0EEC7E1D-D0D2-476C-A1A8-72DFB6633F01"
observationSource   = """
    fetch    [type="http" method=GET url="https://chain.link/ETH-USD"]
    parse    [type="jsonparse" path="data,price"]
    multiply [type="multiply" times=100]

    fetch -> parse -> multiply
"""

Unique fields

schedule: the frequency with which the job is to be run. There are two ways to specify this:
- Traditional UNIX cron format, but with 6 fields, not 5. The extra field allows for "seconds" granularity. Note: you must specify the CRON_TZ=... parameter if you use this format.
- @ shorthand, e.g. @every 1h. This shorthand does not take account of the node's timezone, rather, it simply begins counting down the moment that the job is added to the node (or the node is rebooted). As such, no CRON_TZ parameter is needed.

For all supported schedules, please refer to the cron library documentation.

Job type specific pipeline variables

$(jobSpec.databaseID): the ID of the job spec in the local database. You shouldn't need this in 99% of cases.
$(jobSpec.externalJobID): the globally-unique job ID for this job. Used to coordinate between node operators in certain cases.
$(jobSpec.name): the local name of the job.
$(jobRun.meta): a map of metadata that can be sent to a bridge, etc.

Executes a job upon receipt of an explicit request made by a user. The request is detected via a log emitted by an Oracle or Operator contract. This is similar to the legacy ethlog/runlog style of jobs.

Spec format

type                = "directrequest"
schemaVersion       = 1
evmChainID          = 1
name                = "example eth request event spec"
contractAddress     = "0x613a38AC1659769640aaE063C651F48E0250454C"

# Optional fields:
# requesters        = [
#   "0xAaAA1F8ee20f5565510b84f9353F1E333e753B7a",
#   "0xBbBb70f0E81c6F3430dfDc9fa02fB22bDD818c4E"
# ]
# minContractPaymentLinkJuels = "100000000000000"
# externalJobID = "0EEC7E1D-D0D2-476C-A1A8-72DFB6633F02"
# minIncomingConfirmations = 10

observationSource   = """
    ds          [type="http" method=GET url="http://example.com"]
    ds_parse    [type="jsonparse" path="USD"]
    ds_multiply [type="multiply" times=100]

    ds -> ds_parse -> ds_multiply
"""

Shared fields

See shared fields.

Unique fields

contractAddress: The Oracle or Operator contract to monitor for requests
requesters: Optional - Allows whitelisting requesters
minContractPaymentLinkJuels Optional - Allows you to specify a job-specific minimum contract payment
minIncomingConfirmations Optional - Allows you to specify a job-specific MIN_INCOMING_CONFIRMATIONS value, must be greater than global MIN_INCOMING_CONFIRMATIONS

Job type specific pipeline variables

$(jobSpec.databaseID): the ID of the job spec in the local database. You shouldn't need this in 99% of cases.
$(jobSpec.externalJobID): the globally-unique job ID for this job. Used to coordinate between node operators in certain cases.
$(jobSpec.name): the local name of the job.
$(jobRun.meta): a map of metadata that can be sent to a bridge, etc.
$(jobRun.logBlockHash): the block hash in which the initiating log was received.
$(jobRun.logBlockNumber): the block number in which the initiating log was received.
$(jobRun.logTxHash): the transaction hash that generated the initiating log.
$(jobRun.logAddress): the address of the contract to which the initiating transaction was sent.
$(jobRun.logTopics): the log's topics (indexed fields).
$(jobRun.logData): the log's data (non-indexed fields).
$(jobRun.blockReceiptsRoot) : the root of the receipts trie of the block (hash).
$(jobRun.blockTransactionsRoot) : the root of the transaction trie of the block (hash).
$(jobRun.blockStateRoot) : the root of the final state trie of the block (hash).

Examples

Get > Uint256 job

Let's assume that a user makes a request to an oracle to call a public API, retrieve a number from the response, remove any decimals and return uint256.

The smart contract example can be found here.
The job spec example can be found here.

Get > Int256 job

Let's assume that a user makes a request to an oracle to call a public API, retrieve a number from the response, remove any decimals and return int256.

The job spec example can be found here.

Get > Bool job

Let's assume that a user makes a request to an oracle to call a public API, retrieve a boolean from the response and return bool.

The job spec example can be found here.

Get > String job

Let's assume that a user makes a request to an oracle and would like to fetch a string from the response.

The smart contract example can be found here.
The job spec example can be found here.

Get > Bytes job

Let's assume that a user makes a request to an oracle and would like to fetch bytes from the response (meaning a response that contains an arbitrary-length raw byte data).

The smart contract example can be found here.
The job spec example can be found here.

Multi-Word job

Let's assume that a user makes a request to an oracle and would like to fetch multiple words in one single request.

The smart contract example can be found here.
The job spec example can be found here.

Existing job

Using an existing Oracle Job makes your smart contract code more succinct. Let's assume that a user makes a request to an oracle that leverages Etherscan External Adapter to retrieve the gas price.

The smart contract example can be found here.
The job spec example can be found here.

Flux Monitor Jobs

The Flux Monitor job type is for continually-updating data feeds that aggregate responses from multiple oracles. The oracles servicing the feed submit rounds based on several triggers:

An occasional poll, which must show that there has been sufficient deviation from an offchain data source before a new result is submitted
New rounds initiated by other oracles on the feeds. If another oracle notices sufficient deviation, all other oracles will submit their current observations as well.
A heartbeat, which ensures that even if no deviation occurs, we submit a new result to prove liveness. This can take one of two forms:
- The "idle timer", which begins counting down each time a round is started
- The "drumbeat", which simply ticks at a steady interval, much like a cron job

Spec format

type              = "fluxmonitor"
schemaVersion     = 1
name              = "example flux monitor spec"
contractAddress   = "0x3cCad4715152693fE3BC4460591e3D3Fbd071b42"
externalJobID     = "0EEC7E1D-D0D2-476C-A1A8-72DFB6633F03"

threshold = 0.5
absoluteThreshold = 0.0 # optional

idleTimerPeriod   = "1s"
idleTimerDisabled = false

pollTimerPeriod   = "1m"
pollTimerDisabled = false

drumbeatEnabled  = true
drumbeatSchedule = "CRON_TZ=UTC * */20 * * * *"

observationSource = """
    // data source 1
    ds1 [type="http" method=GET url="https://pricesource1.com"
         requestData="{\\"coin\\": \\"ETH\\", \\"market\\": \\"USD\\"}"]
    ds1_parse [type="jsonparse" path="data,result"]

    // data source 2
    ds2 [type="http" method=GET url="https://pricesource2.com"
         requestData="{\\"coin\\": \\"ETH\\", \\"market\\": \\"USD\\"}"]
    ds2_parse [type="jsonparse" path="data,result"]

    ds1 -> ds1_parse -> medianized_answer
    ds2 -> ds2_parse -> medianized_answer

    medianized_answer [type=median]
"""

Shared fields

See shared fields.

Unique fields

contractAddress: the address of the FluxAggregator contract that manages the feed.
threshold: the percentage threshold of deviation from the previous onchain answer that must be observed before a new set of observations are submitted to the contract.
absoluteThreshold: the absolute numerical deviation that must be observed from the previous onchain answer before a new set of observations are submitted to the contract. This is primarily useful with data that can legitimately sometimes hit 0, as it's impossible to calculate a percentage deviation from 0.
idleTimerPeriod: the amount of time (after the start of the last round) after which a new round will be automatically initiated, regardless of any observed offchain deviation.
idleTimerDisabled: whether the idle timer is used to trigger new rounds.
drumbeatEnabled: whether the drumbeat is used to trigger new rounds.
drumbeatSchedule: the cron schedule of the drumbeat. This field supports the same syntax as the cron job type (see the cron library documentation for details). CRON_TZ is required.
pollTimerPeriod: the frequency with which the offchain data source is checked for deviation against the previously submitted onchain answer.
pollTimerDisabled: whether the occasional deviation check is used to trigger new rounds.
Notes:
- For duration parameters, the maximum unit of time is h (hour). Durations of a day or longer must be expressed in hours.
- If no time unit is provided, the default unit is nanoseconds, which is almost never what you want.

Job type specific pipeline variables

$(jobSpec.databaseID): the ID of the job spec in the local database. You shouldn't need this in 99% of cases.
$(jobSpec.externalJobID): the globally-unique job ID for this job. Used to coordinate between node operators in certain cases.
$(jobSpec.name): the local name of the job.
$(jobRun.meta): a map of metadata that can be sent to a bridge, etc.

Keeper jobs

Keeper jobs occasionally poll a smart contract method that expresses whether something in the contract is ready for some onchain action to be performed. When it's ready, the job executes that onchain action.

Examples:

Liquidations
Rebalancing portfolios
Rebase token supply adjustments
Auto-compounding
Limit orders

Spec format

type            = "keeper"
schemaVersion   = 1
evmChainID      = 1
name            = "example keeper spec"
contractAddress = "0x7b3EC232b08BD7b4b3305BE0C044D907B2DF960B"
fromAddress     = "0xa8037A20989AFcBC51798de9762b351D63ff462e"

Shared fields

See shared fields.

Unique fields

evmChainID: The numeric chain ID of the chain on which Chainlink Automation Registry is deployed
contractAddress: The address of the Chainlink Automation Registry contract to poll and update
fromAddress: The Oracle node address from which to send updates
externalJobID: This is an optional field. When omitted it will be generated

Offchain reporting jobs

Offchain Reporting (OCR) jobs are used very similarly to Flux Monitor jobs. They update data feeds with aggregated data from many Chainlink oracle nodes. However, they do this aggregation using a cryptographically-secure offchain protocol that makes it possible for only a single node to submit all answers from all participating nodes during each round (with proofs that the other nodes' answers were legitimately provided by those nodes), which saves a significant amount of gas.

The node starts offchainreporting jobs only when OCR.Enabled is true. The default is false, and the node then logs Off-chain reporting disabled and registers no delegate.

Bootstrap node

Every OCR cluster requires at least one bootstrap node as a kind of "rallying point" that enables the other nodes to find one another. Bootstrap nodes do not participate in the aggregation protocol and do not submit answers to the feed.

Spec format

type               = "offchainreporting"
schemaVersion      = 1
evmChainID         = 1
contractAddress    = "0x27548a32b9aD5D64c5945EaE9Da5337bc3169D15"
p2pBootstrapPeers  = [
    "/dns4/chain.link/tcp/1234/p2p/16Uiu2HAm58SP7UL8zsnpeuwHfytLocaqgnyaYKP8wu7qRdrixLju",
]
isBootstrapPeer = true
externalJobID   = "0EEC7E1D-D0D2-476C-A1A8-72DFB6633F05"

Shared fields

See shared fields.

Unique fields

contractAddress: The address of the OffchainReportingAggregator contract.
evmChainID: The chain ID of the EVM chain in which the job will operate.
p2pBootstrapPeers: A list of libp2p dial addresses of the other bootstrap nodes helping oracle nodes find one another on the network. It is used with P2P networking stack V1 as follows:

p2pBootstrapPeers = [ "/dns4/HOST_NAME_OR_IP/tcp/PORT/p2p/BOOTSTRAP_NODE'S_P2P_ID" ]
p2pv2Bootstrappers: A list of libp2p dial addresses of the other bootstrap nodes helping oracle nodes find one another on the network. It is used with P2P networking stack V2 as follows:

p2pv2Bootstrappers = [ "BOOTSTRAP_NODE'S_P2P_ID@HOST_NAME_OR_IP:PORT" ]
isBootstrapPeer: This must be set to true.

Job type specific pipeline variables

$(jobSpec.databaseID): The ID of the job spec in the local database. You shouldn't need this in 99% of cases.
$(jobSpec.externalJobID): The globally-unique job ID for this job. Used to coordinate between node operators in certain cases.
$(jobSpec.name): The local name of the job.
$(jobRun.meta): A map of metadata that can be sent to a bridge, etc.

Oracle node

Oracle nodes, on the other hand, are responsible for submitting answers.

Spec format

type               = "offchainreporting"
schemaVersion      = 1
evmChainID         = 1
name               = "OCR: ETH/USD"
contractAddress    = "0x613a38AC1659769640aaE063C651F48E0250454C"
externalJobID      = "0EEC7E1D-D0D2-476C-A1A8-72DFB6633F06"
p2pPeerID          = "12D3KooWApUJaQB2saFjyEUfq6BmysnsSnhLnY5CF9tURYVKgoXK"
p2pBootstrapPeers  = [
    "/dns4/chain.link/tcp/1234/p2p/16Uiu2HAm58SP7UL8zsnpeuwHfytLocaqgnyaYKP8wu7qRdrixLju",
]
isBootstrapPeer    = false
keyBundleID        = "7f993fb701b3410b1f6e8d4d93a7462754d24609b9b31a4fe64a0cb475a4d934"
monitoringEndpoint = "chain.link:4321"
transmitterAddress = "0xF67D0290337bca0847005C7ffD1BC75BA9AAE6e4"
observationTimeout = "10s"
blockchainTimeout  = "20s"
contractConfigTrackerSubscribeInterval = "2m"
contractConfigTrackerPollInterval = "1m"
contractConfigConfirmations = 3
observationSource = """
    // data source 1
    ds1          [type="bridge" name=eth_usd]
    ds1_parse    [type="jsonparse" path="one,two"]
    ds1_multiply [type="multiply" times=100]

    // data source 2
    ds2          [type="http" method=GET url="https://chain.link/eth_usd"
                  requestData="{\\"hi\\": \\"hello\\"}"]
    ds2_parse    [type="jsonparse" path="three,four"]
    ds2_multiply [type="multiply" times=100]

    ds1 -> ds1_parse -> ds1_multiply -> answer
    ds2 -> ds2_parse -> ds2_multiply -> answer

    answer [type=median]
"""

Shared fields

See shared fields.

Unique fields

contractAddress: The address of the OffchainReportingAggregator contract.
evmChainID: The chain ID of the EVM chain in which the job will operate.
p2pPeerID: The base58-encoded libp2p public key of this node.
p2pBootstrapPeers: A list of libp2p dial addresses of the other bootstrap nodes helping oracle nodes find one another on the network. It is used with P2P networking stack V1 as follows: p2pBootstrapPeers = [ "/dns4/<host name or ip>/tcp/<port>/p2p/<bootstrap node's P2P ID>" ]
p2pv2Bootstrappers: A list of libp2p dial addresses of the other bootstrap nodes helping oracle nodes find one another on the network. It is used with P2P networking stack V2 as follows:

p2pv2Bootstrappers = [ "<bootstrap node's P2P ID>@<host name or ip>:<port>" ]
keyBundleID: The hash of the OCR key bundle to be used by this node. The Chainlink node keystore manages these key bundles. Use the node Key Management UI or the chainlink keys ocr sub-commands in the CLI to create and manage key bundles.
monitoringEndpoint: The URL of the telemetry endpoint to send OCR metrics to.
transmitterAddress: The Ethereum address from which to send aggregated submissions to the OCR contract.
observationTimeout: The maximum duration to wait before an offchain request for data is considered to be failed/unfulfillable.
blockchainTimeout: The maximum duration to wait before an onchain request for data is considered to be failed/unfulfillable.
contractConfigTrackerSubscribeInterval: The interval at which to retry subscribing to onchain config changes if a subscription has not yet successfully been made.
contractConfigTrackerPollInterval: The interval at which to proactively poll the onchain config for changes.
contractConfigConfirmations: The number of blocks to wait after an onchain config change before considering it worthy of acting upon.

Job type specific pipeline variables

$(jobSpec.databaseID): The ID of the job spec in the local database. You shouldn't need this in 99% of cases.
$(jobSpec.externalJobID): The globally-unique job ID for this job. Used to coordinate between node operators in certain cases.
$(jobSpec.name): The local name of the job.
$(jobRun.meta): A map of metadata that can be sent to a bridge, etc.

Webhook Jobs

Webhook jobs can be initiated by HTTP request, either by a user or external initiator.

This is an example webhook job:

type            = "webhook"
schemaVersion   = 1
externalInitiators = [
  { name = "my-external-initiator-1", spec = "{\"foo\": 42}" },
  { name = "my-external-initiator-2", spec = "{}" }
]
observationSource   = """
    parse_request  [type="jsonparse" path="data,result" data="$(jobRun.requestBody)"]
    multiply       [type="multiply" input="$(parse_request)" times="100"]
    send_to_bridge [type="bridge" name="my_bridge" requestData="{ \\"result\\": $(multiply) }"]

    parse_request -> multiply -> send_to_bridge
"""

All webhook jobs can have runs triggered by a logged in user.

Webhook jobs may additionally specify zero or more external initiators, which can also trigger runs for this job. The name must exactly match the name of the referred external initiator. The external initiator definition here must contain a spec which defines the JSON payload that will be sent to the External Initiator on job creation if the external initiator has a URL. If you don't care about the spec, you can simply use the empty JSON object.

Unique fields

externalInitiators - an array of {name, spec} objects, where name is the name registered with the node, and spec is the job spec to be forwarded to the external initiator when it is created.

Shared fields

See shared fields.

Job type specific pipeline variables

$(jobSpec.databaseID): the ID of the job spec in the local database. You shouldn't need this in 99% of cases.
$(jobSpec.externalJobID): the globally-unique job ID for this job. Used to coordinate between node operators in certain cases.
$(jobSpec.name): the local name of the job.
$(jobRun.meta): a map of metadata that can be sent to a bridge, etc.
$(jobRun.requestBody): the body of the request that initiated the job run.

VRF jobs

The vrf job type watches a VRF coordinator contract for randomness requests and fulfills them by submitting the verifiable random proof. It covers both VRF v2 and VRF v2plus. The job pipeline uses the VRF V2 task or VRF V2Plus task to generate the proof.

Spec format

type                     = "vrf"
schemaVersion            = 1
name                     = "VRF"
coordinatorAddress       = "0x..."
evmChainID               = "1"
minIncomingConfirmations = 3
publicKey                = "0x..."
fromAddresses            = ["0x1111111111111111111111111111111111111111"]
pollPeriod               = "5s"
observationSource        = """
decode_log   [type=ethabidecodelog
              abi="RandomWordsRequested(bytes32 indexed keyHash,uint256 requestId,uint256 preSeed,uint64 indexed subId,uint16 minimumRequestConfirmations,uint32 callbackGasLimit,uint32 numWords,address indexed sender)"
              data="$(jobRun.logData)"
              topics="$(jobRun.logTopics)"]
vrf          [type=vrfv2
              publicKey="$(jobSpec.publicKey)"
              requestBlockHash="$(jobRun.logBlockHash)"
              requestBlockNumber="$(jobRun.logBlockNumber)"
              topics="$(jobRun.logTopics)"]
estimate_gas [type=estimategaslimit
              to="0x..."
              multiplier="1.1"
              data="$(vrf.output)"]
simulate     [type=ethcall
              to="0x..."
              gas="$(estimate_gas)"
              gasPrice="$(jobSpec.maxGasPrice)"
              extractRevertReason=true
              contract="0x..."
              data="$(vrf.output)"]
decode_log -> vrf -> estimate_gas -> simulate
"""

Shared fields

See shared fields.

Unique fields

coordinatorAddress: the address of the VRF coordinator contract to watch for requests.
publicKey: the public key of the VRF key that this job uses to generate proofs.
minIncomingConfirmations: the minimum number of block confirmations before a request is fulfilled.
evmChainID: the chain ID of the EVM chain in which the job will operate.
fromAddresses: one or more addresses from which to submit fulfillment transactions. If left blank, a random address is selected on every send for the given chain ID.
pollPeriod: how often the job polls for new VRF requests.
requestedConfsDelay: optional. The number of blocks to wait, in addition to minIncomingConfirmations, before fulfilling a request. Defaults to 0.
requestTimeout: optional. The timeout for a request. Defaults to 24 hours.
gasLanePrice: optional. The gas lane price for this job. If the keys in fromAddresses do not have the given gas price, the job does not start.
chunkSize: optional. The number of pending VRF v2 requests to process in parallel. Defaults to 20.
backoffInitialDelay: the amount of time to wait before retrying a failed request after the first failure.
backoffMaxDelay: the maximum amount of time to wait before retrying a failed request.
batchCoordinatorAddress: the address of the batch VRF coordinator to use. Required if batchFulfillmentEnabled is true.
batchFulfillmentEnabled: whether the job uses the batch VRF coordinator to fulfill requests.
batchFulfillmentGasMultiplier: the multiplier used to determine the final gas estimate for batch fulfillment.
customRevertsPipelineEnabled: whether the job runs the custom reverted transactions pipeline alongside the VRF listener.
vrfOwnerAddress: the address of the VRFOwner contract to use. VRF v2 only.

Job type specific pipeline variables

$(jobSpec.publicKey): the public key of the VRF key that this job uses.
$(jobSpec.maxGasPrice): the maximum gas price configured for the job.
$(jobRun.logBlockHash): the block hash in which the initiating log was received.
$(jobRun.logBlockNumber): the block number in which the initiating log was received.
$(jobRun.logTopics): the log's topics (indexed fields).

Blockhash store jobs

The blockhashstore job type watches VRF coordinator contracts for unfulfilled requests and stores the blockhashes they need into a BlockhashStore contract. This lets a request still be fulfilled after its request block leaves the EVM blockhash window.

Spec format

type                         = "blockhashstore"
schemaVersion                = 1
name                         = "blockhashstore"
coordinatorV2Address         = "0x..."
waitBlocks                   = 59
lookbackBlocks               = 159
blockhashStoreAddress        = "0x..."
trustedBlockhashStoreAddress = "0x..."
trustedBlockhashStoreBatchSize = 20
heartbeatPeriod              = "1h"
pollPeriod                   = "23s"
runTimeout                   = "10s"
evmChainID                   = "1"
fromAddresses                = ["0x1111111111111111111111111111111111111111"]

Shared fields

See shared fields.

Unique fields

coordinatorV1Address: a legacy VRF v1 field, kept for API and database compatibility. Non-zero values are rejected at spec validation.
coordinatorV2Address: the VRF v2 coordinator to watch for unfulfilled requests. If empty, no v2 coordinator is watched.
coordinatorV2PlusAddress: the VRF v2plus coordinator to watch for unfulfilled requests. If empty, no v2plus coordinator is watched.
waitBlocks: the minimum age of blocks whose hashes should be stored.
lookbackBlocks: the maximum age of blocks whose hashes should be stored.
blockhashStoreAddress: the address of the BlockhashStore contract to store blockhashes into.
trustedBlockhashStoreAddress: the address of the trusted BlockhashStore contract to store blockhashes into.
trustedBlockhashStoreBatchSize: the number of blockhashes to store in a single batch.
heartbeatPeriod: the period at which a blockhash is stored into the blockhash store contract even when nothing needs it, so that a blockhash is always available to anchor to.
pollPeriod: how often recent blocks are scanned for blockhash storage.
runTimeout: the timeout for a single run of the blockhash store feeder.
evmChainID: the chain ID for monitoring and storing blockhashes.
fromAddresses: the sender addresses used to store blockhashes.

Block header feeder jobs

The blockheaderfeeder job type stores blockhashes for a batch of recent blocks into a BatchBlockhashStore contract, so that blockhashes remain available after the EVM blockhash window.

Spec format

type                       = "blockheaderfeeder"
schemaVersion              = 1
name                       = "blockheaderfeeder"
coordinatorV2Address       = "0x..."
waitBlocks                 = 59
lookbackBlocks             = 159
blockhashStoreAddress      = "0x..."
batchBlockhashStoreAddress = "0x..."
getBlockhashesBatchSize    = 20
storeBlockhashesBatchSize  = 20
pollPeriod                 = "23s"
runTimeout                 = "10s"
evmChainID                 = "1"
fromAddresses              = ["0x1111111111111111111111111111111111111111"]

Shared fields

See shared fields.

Unique fields

coordinatorV1Address: a legacy VRF v1 field, kept for API and database compatibility. Non-zero values are rejected at spec validation.
coordinatorV2Address: the VRF v2 coordinator to watch for unfulfilled requests. If empty, no v2 coordinator is watched.
coordinatorV2PlusAddress: the VRF v2plus coordinator to watch for unfulfilled requests. If empty, no v2plus coordinator is watched.
waitBlocks: the minimum age of blocks whose hashes should be stored.
lookbackBlocks: the maximum age of blocks whose hashes should be stored.
blockhashStoreAddress: the address of the BlockhashStore contract to store blockhashes into.
batchBlockhashStoreAddress: the address of the BatchBlockhashStore contract to store blockhashes into.
getBlockhashesBatchSize: the RPC call batch size for retrieving blockhashes.
storeBlockhashesBatchSize: the RPC call batch size for storing blockhashes.
pollPeriod: how often recent blocks are scanned for blockhash storage.
runTimeout: the timeout for a single run of the block header feeder.
evmChainID: the chain ID for monitoring and storing blockhashes.
fromAddresses: the sender addresses used to store blockhashes.

Offchain reporting 2 jobs

Offchain Reporting 2 (OCR2) jobs use the second generation of the offchain reporting protocol. The job type is offchainreporting2. The protocol details, such as the plugin that consumes the reports, are selected by the job itself rather than by the node.

The node starts offchainreporting2 jobs only when OCR2.Enabled is true. The default is false, and the node then logs Off-chain reporting v2 disabled.

Spec format

type               = "offchainreporting2"
schemaVersion      = 1
name               = "OCR2: ETH/USD"
relay              = "evm"
contractID         = "0x613a38AC1659769640aaE063C651F48E0250454C"
p2pv2Bootstrappers = ["12D3KooWApUJaQB2saFjyEUfq6BmysnsSnhLnY5CF9tURYVKgoXK@10.0.0.1:9999"]
transmitterID      = "0xF67D0290337bca0847005C7ffD1BC75BA9AAE6e4"
pluginType         = "median"
observationSource  = """
    ds          [type=http method=GET url="https://chain.link/ETH-USD"];
    ds_parse    [type=jsonparse path="data.price" separator="."];
    ds_multiply [type=multiply times=100];
    ds -> ds_parse -> ds_multiply;
"""

[relayConfig]
chainID = "1"

[pluginConfig]

Shared fields

See shared fields.

Unique fields

relay: the relay identifier in RelayID.Network form, for example evm.
contractID: the address of the contract that the DON reports on.
feedID: optional. The feed ID that the job reports on.
chainID: the chain ID. This field is deprecated in favor of the chainID key inside relayConfig.
relayConfig: relay-specific configuration.
p2pv2Bootstrappers: a list of peer_id@ip_address:port strings that identify the bootstrap nodes of the P2P network.
ocrKeyBundleID: the OCR key bundle that this node uses to sign reports.
transmitterID: the address from which to submit aggregated reports.
monitoringEndpoint: the URL of the telemetry endpoint to send OCR metrics to.
blockchainTimeout: the maximum duration to wait before an onchain request for data is considered to be failed or unfulfillable.
contractConfigTrackerPollInterval: the interval at which to proactively poll the onchain config for changes.
contractConfigConfirmations: the number of blocks to wait after an onchain config change before considering it worthy of acting upon.
onchainSigningStrategy: the strategy used to select the onchain signing key.
pluginType: the OCR2 plugin that consumes the reports, for example median.
pluginConfig: plugin-specific configuration.
captureEATelemetry: whether to capture telemetry for the external adapter calls made by the pipeline.
allowNoBootstrappers: whether the job may start without any bootstrappers. Useful where the node is not configured to conduct consensus.

Bootstrap jobs

A bootstrap job configures a node as a bootstrap peer. A bootstrap node does not take part in the aggregation protocol; it lets the other nodes of a DON find one another. The bootstrap job type is used for OCR2, CCIP, and other DONs that use the offchain reporting protocol.

The node starts bootstrap jobs only when OCR2.Enabled is true. The default is false.

Spec format

type               = "bootstrap"
schemaVersion      = 1
name               = "bootstrap"
relay              = "evm"
contractID         = "0x613a38AC1659769640aaE063C651F48E0250454C"

[relayConfig]
chainID = "1"

Shared fields

See shared fields.

Unique fields

relay: the relay identifier in RelayID.Network form, for example evm.
contractID: the contract that the DON reports on.
feedID: optional. The feed ID that the DON reports on.
relayConfig: relay-specific configuration.
monitoringEndpoint: the URL of the telemetry endpoint to send OCR metrics to.
blockchainTimeout: the maximum duration to wait before an onchain request for data is considered to be failed or unfulfillable.
contractConfigTrackerPollInterval: the interval at which to proactively poll the onchain config for changes.
contractConfigConfirmations: the number of blocks to wait after an onchain config change before considering it worthy of acting upon.

Stream jobs

A stream job runs a pipeline on demand and publishes the results to a Data Streams feed. Each run must produce at least one stream ID, either from the top-level streamID field or from a streamID tag on a task in the pipeline.

Spec format

type              = "stream"
schemaVersion     = 1
name              = "ETH-USD stream"
streamID          = 1234
observationSource = """
    ds          [type=http method=GET url="https://chain.link/ETH-USD"];
    ds_parse    [type=jsonparse path="data.price" separator="."];
    ds_multiply [type=multiply times=100];
    ds -> ds_parse -> ds_multiply;
"""

Shared fields

See shared fields.

Unique fields

streamID: optional. The stream ID that receives the final output of the pipeline run. Tasks in the pipeline may also carry a streamID tag. At least one stream ID must be present.

Gateway jobs

A gateway job configures the node's gateway, which brokers connections between workflow nodes and external services. The gatewayConfig block holds the gateway settings. See Gateway configuration for the meaning of each setting.

Spec format

type          = "gateway"
schemaVersion = 1
name          = "Gateway"

[gatewayConfig.ConnectionManagerConfig]
AuthGatewayId            = "gateway"
AuthChallengeLen         = 10
AuthTimestampToleranceSec = 5
HeartbeatIntervalSec     = 20

[gatewayConfig.NodeServerConfig]
Path                 = "/node"
Port                 = 8080
HandshakeTimeoutMillis = 1000
MaxRequestBytes      = 100000
ReadTimeoutMillis    = 1000
RequestTimeoutMillis = 10000
WriteTimeoutMillis   = 1000

[gatewayConfig.UserServerConfig]
Path                 = "/user"
Port                 = 8081
ContentTypeHeader    = "application/jsonrpc"
MaxRequestBytes      = 100000
ReadTimeoutMillis    = 1000
RequestTimeoutMillis = 10000
WriteTimeoutMillis   = 1000
CORSEnabled          = false
CORSAllowedOrigins   = []

[gatewayConfig.HTTPClientConfig]
MaxResponseBytes = 100000000

Shared fields

See shared fields.

Unique fields

gatewayConfig: the gateway configuration. It holds a ConnectionManagerConfig block, a NodeServerConfig block, a UserServerConfig block, an HTTPClientConfig block, and a list of Dons.

Standard capabilities jobs

A standardcapabilities job starts a capability binary that the node hosts. The node launches the command in command and passes it the value of config.

Spec format

type                = "standardcapabilities"
schemaVersion       = 1
name                = "some-capability"
forwardingAllowed   = false
command             = "/home/capabilities/some_capability_linux_amd64"
config              = ""

Shared fields

See shared fields.

Unique fields

command: the path to the capability binary that the node launches.
config: the configuration passed to the capability.
oracle_factory: the oracle factory configuration for the capability.

CCIP jobs

The ccip job type starts a CCIP capability DON. Its configuration is defined by the CCIP capability, which is documented with the product rather than here.

The node starts ccip jobs only when OCR2.Enabled is true. The default is false.

Unique fields

p2pV2Bootstrappers: a list of peer_id@ip_address:port strings that identify the bootstrap nodes of the P2P network. These bootstrappers are used to bootstrap all CCIP DONs.
capabilityVersion: the semantic version of the CCIP capability. This version must exist in the onchain capability registry.
capabilityLabelledName: the labelled name of the CCIP capability. It corresponds to the labelled name of the capability in the onchain capability registry.
ocrKeyBundleIDs: a mapping from chain type to OCR key bundle ID, for example {"evm": "evm_key_bundle_id"}.
relayConfigs: relay-specific configuration, keyed by chain family.
p2pKeyID: the ID of the node's P2P key. It must be present in the capability registry, otherwise the job does not start correctly.
pluginConfig: plugin-specific configuration.

CCV committee verifier jobs

The ccvcommitteeverifier job type starts a CCV committee verifier capability. Its configuration is defined by the CCV capability, which is documented with the product rather than here.

Unique fields

committeeVerifierConfig: the TOML configuration for the CCV committee verifier. The configuration is multichain, using chain selectors as keys where applicable.

CCV executor jobs

The ccvexecutor job type starts a CCV executor capability. Its configuration is defined by the CCV capability, which is documented with the product rather than here.

Unique fields

executorConfig: the TOML configuration for the CCV executor. The configuration is multichain, using chain selectors as keys where applicable.

CRE settings jobs

The cresettings job type carries the settings for the Chainlink Runtime Environment on this node. It is managed by the product rather than written by node operators.

Unique fields

hash: the hash of the settings payload.
settings: the settings payload.

Job Types

Get the latest Chainlink content straight to your inbox.