A Chainlink reviewed node receives the benefits of being listed in our documentation and being added to the Chainlink Explorer. Getting added to our documentation is not a requirement in order to run a node. You are free to run a node and utilize 3rd party listing services in order for smart contracts to send requests to your Chainlink node.
To get started, please follow the Running a Chainlink Node to initially setup your node and then follow the Fulfilling Requests guide to deploy and utilize your oracle contract. We take security very seriously, and as a Chainlink reviewed node operator that will be part of the Chainlink network, we feel that you should as well. We have guidance on our Best Security Practices page that will get you started. Please use that as a reference to setup and secure your node's infrastructure.
Your choice of infrastructure provider or operating system is entirely up to you. However, you will be expected to know how to secure systems within that infrastructure. Be sure to choose a provider that you are comfortable maintaining.
Once setup, please operate your node on the Ropsten test network for at least 1 week prior to requesting us to review your performance. You will be expected to send requests to your own node in order to prove responsiveness. We will view these requests via your oracle contract to verify that you have a sufficient amount of requests during this one week period. By doing this, we can ensure that requesters/users of the Chainlink network will have a moderately reliable Chainlink node to utilize for external data.
You can follow the Fulfilling Requests guide to see how to send requests through your own node on the test networks. You should use the contract that the guide has you deploy to send requests to your Chainlink node during this time. In order to gauge the responsiveness of your node, we're looking to see at least 144 requests per day, and at least 6 per hour. You're free to automate this however you like, including using the Chainlink node to ping your contract via a Cron-initiated job.
Once your Ropsten Chainlink node has been operational and in use for at least 1 week, you may request to be added to the Ropsten Explorer. We will review, approve the name you choose to be listed as, and provide you with authentication for connectivity. Operating with connectivity to Explorer will allow requesters to view the status of their requests and allow monitoring of uptime.
The technical review is to ensure that your infrastructure is secure, updatable, and that your setup can handle failover and disaster recovery scenarios in a timely manner. Be ready to demonstrate your infrastructure by showing the node failing over to a secondary instance and applying rolling updates without downtime.
If approved, we will add you to the Decentralized Oracles (Testnet) page. If you are self-hosting your own Ethereum clients, we recommend add your Ethereum clients to Ethstats.net, but this is not required. At this point, you will also be added to main net's Explorer where your main net requests will be discoverable and your node's uptime will be tracked. If after another week, your Ropsten and main net nodes have shown that they have not missed any responses or had any significant downtime, we will add you to the main net listing page. You do not need to run recurring requests through your main net node. We may delay adding you to the main net listing page due to lack of responsiveness or downtime.
If you are self-hosting your Ethereum nodes, you will be listed along with the other node operators who are also self-hosting their own Ethereum nodes. If you are using a 3rd party service for communicating with the Ethereum blockchain, you will be listed along with nodes which are also using that same service. This is to provide requesters with the most transparent information regarding the nodes they utilize for their smart contracts.
The optional identity interview is to provide additional protection against the possibility of a sybil attack on an oracle network which your node may participate in. A sybil attack can occur if a single node operator can present multiple nodes in one network, and therefore take control over the network itself.
Please be ready to provide the following information in your identity review:
The official Node Operator Name that you want to be visible on the main net's explorer for your node
Proof of incorporation for the entity providing the service as a node operator, or a copy of any Government issued identification to confirm your identity if you're operating it personally.
A photo of you holding your ID and a piece of paper stating your Chainlink's official name, along with your identity review date.
When your identity review is complete and your accompanying documentation has been submitted and verified, we will provide a Sybil Resistant Status for your node, which is visible on the main net's Explorer.
Sybil Resistant Status is only given for the benefit of users and is not meant to dictate oracle node participation or non-participation in the system. The primary goal of this approach is to avoid the creation of oracle networks where multiple separate nodes are actually run by one individual. Though utilizing multiple nodes improves the chances of sybil resistance, having an oracle network made up of multiple identity reviewed node operators increases it to a much greater degree.