We usually have many development efforts going on at once with the node, the GUI, and the contracts. Check out the project tracker (linked below) to see the current development status.
We do not usually give time frames unless something is visibly near completion on the project tracker. This includes features, contracts, and integration with other projects. If something is immediately pending to be merged within the code base, it will be visible as an open PR (pull request) in the repository.
We are always looking for talented and experienced individuals. Please visit our careers page.
You can set up a node to run on a test network or the Ethereum mainnet right now. The node will not be able to participate in fulfilling service agreement requests yet, but will in the near future. However, it can be used to fulfill requests sent to your oracle contract address and you can add external adapters to it for extending its functionality.
You will be able to run a Chainlink node with 0 LINK, however, you will not be able to participate in requests that require a deposit until you’ve earned some LINK first.
Requesters may specify an amount of LINK that all nodes must deposit as a penalty fee in case the node doesn’t fulfill the request. However, since penalty fees are optional, not all requests will require it.
No. Ganache is a mock testnet and it doesn't work with Chainlink because of that. To use the features of the network, you need to deploy your contract on a real environment: one of the testnets or mainnets. The full list of supported environments can be found here.
The hardware requirements of the Chainlink node are very minimal to operate. It should run with 1 core and 1 GB of RAM, though you may want to up the RAM to 2 GB for better reliability. However, connectivity to an Ethereum client is required for communication with the blockchain. If you decide to run your own Ethereum client, you will want to run that on a separate machine. Hardware requirements of Ethereum clients may change over time.
- Running a Chainlink Node
- Development Setup Guide
- StackExchange Answer
- All Ethereum Hardware Questions
The Chainlink node can fulfill requests from open (unauthenticated) APIs out-of-the-box, without the need for External Adapters as long as you've added the jobs in the Fulfilling Requests guide. For these requests, requesters would supply the URL to the open API they wish each node to retrieve, and the Chainlink node will use its core adapters to fulfill the request.
If you would like to provide access to an API which requires authentication, you will need to create a job specific for that API, either with an external adapter or by using the parameters of the HttpGet adapter.
Currently, the community maintains lists of available external adapters.
The Chainlink Market keeps a list of node operators registered with them across multiple networks.
You can use our Truffle Box to get started by unboxing a developer-focused template.
If you already have a project started and would like to integrate Chainlink, you can add Chainlink to your existing project by using our
chainlink NPM package.
Yes, the Chainlink node can connect to most APIs out-of-the-box. Some APIs require authentication by providing request headers for the operator's API key, which the Chainlink node supports. Additionally, external adapters allow for connectivity to any resource as long as the adapter conforms to a minimal JSON specification for communicating to and from the Chainlink node.
You can use the Chainlink Market to select nodes for your requests. Then with the node's oracle contract address and Job ID, you will use the
sendChainlinkRequestTo method to create requests to oracles.
Currently, the EthTX core adapter can only write values that are up to 32 bytes onto a blockchain. If the value is larger than 32 bytes, the data may need to be returned by making multiple requests.
The LINK token is an ERC677 token that inherits functionality from the ERC20 token standard and allows token transfers to contain a data payload. It is used to pay node operators for retrieving data for smart contracts and also for deposits placed by node operators as required by contract creators.
Any wallet that handles ERC20 tokens should work fine. The ERC677 token standard that the LINK token implements still retains all functionality of ERC20 tokens.
A phase indicates the underlying aggregator implementation has been updated. Phases are only relevant 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.
They do, in the best-case scenario. However, a round can time out if it doesn't reach consensus, so that would technically be a timed out round, which carries over the answer from the previous round. Though roundIds can seemingly jump significantly when the phaseId is updated, because of how that combination of phaseId+roundId is stored in the proxy.
updatedAt is the timestamp of an answered round while answeredInRound is the round it was updated in.
You can check answeredInRound against the current roundId. If answeredInRound is less than roundId, the answer is being carried over. If answeredInRound is equal to roundId, then the answer is fresh.
A read can revert if the caller is requesting details of a round that was invalid (perhaps, not being answered yet), which basically is just relevant to a roundId which is greater than a uint32 or 0. It hasn't happened yet, however you can prevent this from happening if you add a check on the roundId.
Why is latestAnswer reported at 8 decimals for some contracts, but for other contracts it is reported with 18 decimals?
For crypto quotes, 18 decimals is typically used because they usually require more precision. For FX quotes, 8 decimals are used because that is the precision data sources typically report them at.
Updated about a month ago