Your smart contracts connected to real world data, events and payments.

home link

reference material Whitepaper.pdf


Exchanges that listed the coin
To be released
Project introduction

Chainlink has been trying to solve the problem that the external platform, external link and API are not connected in the process of implementing the existing smart contract function and it provides the service as an intermediate role to link external link and data to smart contract. They say

Executives and partners

Sergey Nazarov


Steve Ellis


Dimitri Roche

Software Engineer

Mark Oblad

Head of Operations

Alex Kwiatkowski

Software Engineer



Latest News

There is no news posted at the moment
Please leave a message of support for the team

go to leave a message


Chainlink Hackathon Champio...

Three teams at the 2018 September ETH San Francisco Hackathon won the Chainlink hackathon prizes for their implementations of Chainlink on the Ethereum blockchain.Hackathon entrants pit their technical skills against each other over a 36-hour weekend to build a working blockchain application. Chainlink awarded prizes to the teams with the most creative and compelling prototypes of Chainlink. As the applications of off-chain data to on-chain smart contracts are endless, we saw huge variety in projects ranging from political voting, to cryptocurrency finance, to contract uptime guarantees.Taking the $1,000 third prize was B3PO, a project that merges robotics and blockchain technology. The team created a system that handwrites blockchain-validated information on an absentee voting ballot to be sent through the mail. It’s a provocative workaround for voting on the blockchain.The idea was born when software engineer Moyukh Sen learned of a swing race in his hometown of Buffalo, New York a few weeks before the hackathon. He knew that college students away from their hometowns wanted to vote, but most don’t know the first step of the absentee ballot process. To solve this problem, Sen’s team bought a $200 robot from Amazon and got to work. He built a robot that would handwrite absentee ballots using smart contracts secured on the blockchain. By partnering with university clubs around the country — blockchain meetups, robotics groups, and political clubs — he hopes B3PO will make it simple for students to cast their absentee votes no matter where they are. The end of this video shows the finished robot in action:“Getting that dynamic ballot data into the smart contract on-chain requires an oracle service, and Chainlink is a great fit for that,” said Sen. “Google aggregates a lot of voter data as a service, so we wrote an adapter between Chainlink and the Google voter API. It was very simple to do and has great democratic benefits.” prize of $2,000 went to Link Set, a project aimed at crypto traders who want a more automated trading experience. As values shift across your portfolio of tokens, Link Set can rebalance your cryptocurrency portfolio, automatically executing trades based on real-world price changes. Additionally, traders can create a basket of cryptocurrencies that rebalances over time, similar to starting your own S&P 500.“We’re familiar with standard exchange-traded funds that let you track an index. We were interested in doing that with crypto,” said Link Set team member Sharad Shekar. “Autonomous rebalancing could revolutionize the way cryptocurrency investment works.” Team member Edmund Miller adds, “The goal was to make a trustless system and that was easily managed by Chainlink.”Taking first prize and $4,000, “solo hacker” Xuefeng Zhu won the Chainlink hackathon. His application, Micro Subscription, holds cloud providers accountable to their guarantees by monitoring server uptime data. Micro Subscription uses an on-chain oracle to establish a smart contract between the user and the provider. It pays out according to a company’s stated service level agreement (SLA) and ensures the customer doesn’t pay for any downtime.“Paying for cloud service by flat rate requires more capital flow,” Zhu said. “My project lets the user pay for what they use, like by-the-minute phone service.”These hackathon winners show a variety of applications demonstrating how bringing secure external data to a blockchain paradigm can impact our world today and in the future. Hackathon Champions Reveal Their Winning Projects was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 11. 05

Running a Chainlink Node fo...

This article serves as a guide for new Chainlink node operators interested in learning what it takes to run a node. While this document is neutral towards any operating system, it does require some familiarity with the command line, which is commonly used by Linux and Mac users. Additionally, it is perfectly fine to run a Chainlink node in a test setting on your local machine. There is no requirement to purchase a cloud hosting plan. However, you may want to consider doing so when running your Chainlink node on the Ethereum main net as its ability (or inability due to downtime) to respond to requests will affect your reputation.If you would like a shorter, less-detailed guide, please visit our official documentation on running a Chainlink node here.There are two ways to run a Chainlink node. The first is to install all required development dependencies, download the code base, and compile a binary on your local machine. The second is simply to run a Docker image that we keep up to date as part of our continuous delivery process. This guide focuses on the latter method because it is easier and more approachable for most audiences. If you have extensive systems or development experience, feel free to follow the complete setup guide for a Chainlink development environment here.The first step is to install Docker-CE. Docker-CE (community edition) is a free version of Docker that you can use to spin up containers without having to pay for enterprise-level support. After clicking the Docker-CE link, select your operating system on the left side-bar and follow the installation instructions. Once complete, continue to the next step.Next, the Chainlink node requires an active connection to an Ethereum client to communicate with smart contracts on the blockchain. We will want to have an Ethereum client running and synced before we start the Chainlink node. Again, the easiest way to do this is with Docker. Geth and Parity offer official images through Docker, and are very easy to run. Both follow the same basic steps: download the image, create a volume, run the image. It doesn’t matter which client you prefer.To download the Geth (ethereum/client-go) Docker image, run the following command:docker pull ethereum/client-go:stableThis will download the Geth client to run as a containerized application on your local machine. Next, create a directory for blockchain data so that you don’t need to re-sync the entire blockchain every time you restart the image. This is done with a simple command:mkdir ~/.geth-ropstenThis creates an empty directory that we will use for Geth’s Docker image every time it’s run. Finally, you’ll want to run the image itself, using the directory we just created and giving it parameters to make it easy for the Chainlink node to connect to it:docker run --name eth -p 8546:8546 -v ~/.geth-ropsten:/geth -it \ ethereum/client-go:stable --testnet --syncmode light --ws \ --wsaddr --wsorigins="*" --datadir /gethWith this command, we are enabling websockets, a required protocol, for the Chainlink node to connect with. We are giving the container the name eth, using the directory that we created in the second command, and telling it to run on the Ropsten test network. This also runs the Ethereum client in light mode, which keeps the blockchain data minimal. Since there are security concerns about running a light client, it is not recommended to do so on the Ethereum main net.If you want to run the Parity client instead of Geth, the commands are essentially the same. The only difference is the name of the image and directory. You can download the latest Parity Docker image by running:docker pull parity/parity:stableThen create a persistent directory just for Parity:mkdir ~/.parity-ropstenAnd finally, run the Parity image:docker run -h eth --name eth -p 8546:8546 \ -v ~/.parity-ropsten:/home/parity/.local/share/io.parity.ethereum/ \ -it parity/parity:stable --chain=ropsten \ --ws-interface=all --ws-origins="all" --light \ --base-path /home/parity/.local/share/io.parity.ethereum/Once the Ethereum client completes syncing, we’re ready to run the Chainlink node.Similar to our steps with the Ethereum client, we’ll first download the latest Chainlink image from Docker:docker pull smartcontract/chainlink:latestWe’re using the “:latest” tag because it is kept up to date with our code repository on Github. We also want to create a persistent directory for the Chainlink node so that we don’t need to start over every time we restart the image:mkdir ~/.chainlink-ropstenNext, we do a little setup to configure the Chainlink node. Chainlink uses environment variables for configuration. Before we run the node, we need to create a file to be passed into the Docker image which contains our desired values. On Linux and Mac, create this file by simply running:echo "ROOT=/chainlinkLOG_LEVEL=debugETH_URL=ws://eth:8546ETH_CHAIN_ID=3MIN_OUTGOING_CONFIRMATIONS=2MIN_INCOMING_CONFIRMATIONS=0LINK_CONTRACT_ADDRESS=0x20fe562d797a42dcb3399062ae9546cd06f63280CHAINLINK_TLS_PORT=0CHAINLINK_DEV=trueALLOW_ORIGINS=*" > .envThe values for the “ETH_CHAIN_ID” and “LINK_CONTRACT_ADDRESS” are populated with values specific to the Ropsten test network. If you want to run the node on a different network, just change these values. The file is saved typically with the name “.env” but you can name it whatever you like. The next command assumes that the file name is “.env”. If yours is named differently, you will need to update the following command.Now, we’re ready to run the Chainlink node:docker run --link eth -p 6688:6688 \ -v ~/.chainlink-ropsten:/chainlink \ -it --env-file=.env \ smartcontract/chainlink nThis starts the Chainlink node using the values stored in the environment file you previously created, and links it to the running Ethereum client’s Docker image. The first time running the Chainlink node, you will be prompted for a password, followed by a password confirmation. This is for your Ethereum keystore file used by the node. We use the Chainlink node to manage the Ethereum keys instead of the Ethereum client. This means there’s no need to run your Ethereum client with an unlocked account while the JSON-RPC port is open. The Chainlink node’s key will be the one that signs transactions, which are answers to requests, for smart contracts. It will need some ETH to write to the blockchain. Once the node displays your Ethereum address (after the next step), you can obtain Ropsten ETH for it here.Next, it will prompt you for an API Email and Password. This will be used for interacting with the Chainlink node through the API, command-line, or the GUI. Enter an email and a strong password, preferably different than your keystore password, to complete the setup process. You need to wait for the Ethereum node to complete syncing before the Chainlink node is fully operational.If all goes well, you should see the node running and receiving block headers from the Ethereum client. You can also point your browser to http://localhost:6688 and see the GUI.The Chainlink Sign In PageLogin using the API Email and Password that you set when you first ran the Chainlink node. Once signed in, you will see the admin dashboard.The Chainlink Admin DashboardCongratulations! If you made it this far, you are a node operator!Your next steps are to add some jobs and play around with the node on an Ethereum test network. Go ahead and check out our guide on how to fulfill your own contracts until aggregation is implemented.If you have any questions, feel free to ask on our Telegram channel and we’ll be glad to help you.Additional Resources:Official SiteOfficial DocumentationOfficial TelegramOfficial TwitterGithub RepositoryDeveloper WikiDeveloper ChatRopsten LINK FaucetRunning a Chainlink Node for the First Time was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 09. 03

Viewing Chainlink Transacti...

To begin, you can watch the transactions of the deployed LINK token contract on Ropsten here. This link filters for the event topics of data requests. Click on a transaction and go to the Event Logs tab and you’ll notice some of the events contain a lot more data than the others. Those are the requests for data, and you can change the Hex drop-down to Text on the last few entries and see part of the payload.See the URL and the path that makes up the payload of the request.You can also use a CBOR decoder to view the full payload in plain text:We use CBOR to encode requests for data.For example, here is a transaction of one of my tests. First, you can see that the beginning of the Input Data, 0x620cae68, is the function selector of requestEthereumPrice(string) when you hash it with Keccak-256. Then, if you convert the input data to UTF8, you’ll see that I used “USD” for my input parameter.USD is the input parameter used.Going to the Event Logs tab of that transaction, you can again see the requesting payload, and the address of the oracle contract that I used, here. On the oracle contract, you’ll see the transaction that my node created to fulfill the request here, and again, you can convert the Input Data to UTF8 to see the value that was given.696.64 is the value given to the oracle contract.Additionally, you can go to the Event Logs tab, and directly obtain the hex value sent to the contract:Topics[2] contains the requested value.Once you enter the value of the last topic (Topics[2]) into a hex-to-string converter, you can see the value:The requesting contract wanted bytes returned.If you would like to deploy contracts or run your own Chainlink node on Ropsten, check out the examples on our Github. You can now create your own contracts to utilize Chainlink on Ropsten. Feel free to ask us questions on Gitter!Viewing Chainlink Transactions on the Ropsten Testnet was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 05. 17

Debugging Chainlink with Vi...

This guide is geared towards those who may be new developers, or maybe just new to Golang. Debugging is an essential part of programming, and can greatly enhance your understanding of the system you are working on. In this guide, you will be shown how to set up Visual Studio Code for use with the Golang language. VS Code is a lightweight graphical code editor that allows for extensions (plugins) to be installed in order to add features, similar to Atom and Sublime Text.RequirementsA complete development environment for ChainlinkDelveVisual Studio CodeSet up Visual Studio CodeInstall the Go ExtensionLaunch VS Code Quick Open (Ctrl+P) and run: ext install Go. This will bring you to the extensions marketplace where you can install the Go extension. After installing, click the Reload button and the interface will refresh briefly.To open the Chainlink project, type Ctrl+K Ctrl+O to bring up the Open Folder dialog. Navigate to your $GOPATH/src/ directory and open it.Select the main.go file in the root directory and notice a dialog appears at the bottom-right of the screen. Click the Install All button. This will install the Go Tools in VS Code to make reading the code and development easier.Set Launch ParametersType Ctrl+Shift+D to bring up the Debug controls and click the Gear icon near the top-left to configure a launch.json. To run the Chainlink node against DevNet, you can use the following options by copying and pasting the text below over the entire file (you’ll want to replace the LINK_CONTRACT_ADDRESS with the address of your deployed LinkToken contract.{ "version": "0.2.0", "configurations": [ { "name": "DevNet", "type": "go", "request": "launch", "mode": "debug", "remotePath": "", "port": 2345, "host": "", "program": "${workspaceRoot}", "env": { "LOG_LEVEL": "debug", "ROOT": "./internal/devnet", "ETH_URL": "ws://localhost:18546", "ETH_CHAIN_ID": 17, "TX_MIN_CONFIRMATIONS": "0", "TASK_MIN_CONFIRMATIONS": "0", "USERNAME": "chainlink", "PASSWORD": "twochains", "LINK_CONTRACT_ADDRESS": "0x83e41643c2598c4d6a78d68cf506bf209a22ba5d"}, "args": ["node", "-p", "T.tLHkcmwePT/p,]sYuntjwHKAsrhm#4eRs4LuKHwvHejWYAC2JP4M8HimwgmbaZ"], "showLog": true } ]}After saving, you’ll notice a new folder, .vscode was created at the root of the project. You’ll want to make sure to add that to your global gitignore so that it is not included when you create pull requests.Run in Debug ModeFirst, you’ll want to run the DevNet image in its own window.$ cd $GOPATH/src/$ ./internal/bin/devnetThen, back in Visual Studio Code, you’ll start debugging by hitting F5 or clicking the “play” icon in the debug window at the top-left. If successful, you should see the same output on the “Debug Console” tab at the bottom as you would if you were to run the Chainlink node in a terminal window.You’ll also see a debug file created at the root of the project. You’ll want to add that to your global .gitignore as well.BreakpointsIn order to step through the code, you’ll want to set a breakpoint where you want to begin stepping. To do this, you’ll first stop debugging the running program by clicking the “stop” button at the top of the screen. Then, find a line that you want the program to pause execution. A good starting point to understand the flow of a run is in the services/job_runner.go file, with the BuildRun function. You can click anywhere on that line and hit the F9 button on your keyboard, or click the red dot next to the line number to add a breakpoint. Repeat those same steps to remove a breakpoint.Now, start the node again, and add a job if there isn’t one already present. You can use this JobSpec to start with:$ chainlink c '{"initiators":[{"type":"web"}],"tasks":[{"type":"HttpGet","url":""},{"type":"JsonParse","path":["USD"]},{"type":"noop"}]}'Then take note of the value for the “ID” field returned on the top table. You can start a run (replacing $JOBID with your actual job ID) in the TERMINAL tab by running:$ chainlink r $JOBIDVS Code should pause at the BuildRun function. You can step through the code by hitting the F10 button on your keyboard, and F11 will allow you to “step into” functions. Notice the panels on the Debug tab, Variables and Call Stack, have been populated with information about the running program. Simply type the variable name at the > prompt in the Debug Console and hit Enter to get more information about the variable, but you’ll want to click the carrot to expand the properties. You can also get more information from variables by querying them in the Debug Console tab.For example:> job.Initiators[0] # hit enter<>ID:0JobID:"1f0daf1b11664da89b9675dc05a4b993"Type:"web"Schedule:""Time:<>Ran:falseAddress:<>When you want the program to resume like normal, hit the F5 button.Hopefully this guide has been useful to you and will help you with debugging and adding features to Chainlink! If you have any questions, feel free to bring them up on our Slack (email for access) or Gitter.Debugging Chainlink with Visual Studio Code was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


18. 04. 25

ChainLink White Paper — Sec...

This section of the ChainLink white paper dives into further detail on some of the properties of the ideal oracle solution proposed in Section 3. There are three main sub-sections: oracle confidentiality, infrastructure changes, and off-chain computation.In regards to oracle confidentiality, trusted hardware is introduced as a better solution to protect against faulty nodes. The Town Crier oracle is comprised of a network of nodes running trusted hardware, and operating on Ethereum’s blockchain. Trusted hardware via Intel’s Software Guard eXtensions (SGX) improves upon previous secure computing methods in that its program execution can be cryptographically verified. Trusted hardware allows software to be executed within a protected environment referred to as an enclave. Within the enclave, the data and code cannot be viewed or modified by any party, including the node operator. Data can even consist of usernames and passwords, and API keys can be provided an a query to the nodes without the possibility of eavesdropping even on a compromised machine.Allowing for inputs and queries to remain confidential is difficult when dealing with third party oracles because in order for a query to tell an oracle provider how and where to obtain data, traditionally, that query would need to be revealed to the oracle. Then the oracle would also be able to see the response, which is undesirable for confidentiality.The benefit of trusted hardware running SGX is that queries can be given to an oracle, that query can be decrypted, its data retrieved and processed, and encrypted to be returned to the smart contract, all within the enclave. An example of trusted hardware being utilized with confidential data is how flight information can be relayed using Town Crier (TC) smart contracts. Confidential flight information can be given to an oracle running a SGX enclave and return a simple yes or no answer back to the user to be written on the blockchain. Another example is trading games on Steam. TC can allow usernames and passwords to be given within a query, verify game ownership, and transfer that ownership within a smart contract.The simplified abstraction for SGX is as follows:Hardcoded: The private key, unique to each oracleAssume: The program operating within the enclave has methods Initialize and ResumeInitialize: - Untrusted code Initializes the enclave - The attestation of the code within the enclave and its output is generated - The attestation is signed to verify that the code was running with the output produced within the enclave - The result along with the signed attestation is returnedResume: - Untrusted code calls the Resume method with a session identifier and input parameters - An output is produced from the code within the enclave (called with the Resume method) - The output is returnedThe authenticity of an oracle running SGX is defined by its signature. The input parameters which were given as part of the query are combined with the attestation along with the time of the execution and are signed with the oracle’s private key. These parameters cannot be reproduced in such a way that would allow the returning of modified data to be accepted within the system.Infrastructure changes on a large scale would need to be implemented in order for data to securely be returned to nodes in a verifiable manner without trusted hardware, but can also be used to further enhance the security and confidentiality provided by trusted hardware. For example, HTTPS does not allow for the digital signature of data, but an extension of TLS, TLS-N, could be used to improve oracle security by allowing servers to sign sessions with clients. TLS-N looks promising, but it does have some limitations. Data sources would need to individually enable the extension in order for oracles to take advantage of it. It provides no capability to aggregate data off-chain. It would increase the transaction cost within smart contracts. Providing credentials would be a one-time use, instead of continued use within a smart contract.Further changes to off-chain computation are also proposed in this section. Oracles may need to connect to API endpoints multiple times using the supplied credentials. In order to do this, the ability to securely manage those credentials within an enclave would need to be developed. Currently, off-chain data processing is limited to a regex-based language. The goal for the future is to have most, if not all, off-chain computation be accomplished within oracles. These oracles would then feed the results of the computation back to the smart contract. This would reduce the cost for smart contracts, and by making use of trusted hardware, would improve confidentiality.The key take away from this section should be learning about how SGX improves the oracle’s security within the ChainLink network. I tried to take away the math associated with Figure 5 so that it would make sense for anyone to read it. However, the concept of running a program within an enclave can still be difficult to understand.Read the ChainLink white paper here.ChainLink White Paper — Section 6 — Long-Term Technical Strategy was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


17. 11. 21

ChainLink White Paper — Sec...

As the title states, Section 3 of the ChainLink white paper gives an overview of the ChainLink oracle security. The section creates a scenario depicting the perfect oracle solution, then adds layers of complexity and explains why it is difficult to achieve such an environment.Security is important to have on each individual oracle (node) so that the data is reliably delivered to smart contracts without being tampered with. We trust the blockchain because it is immutable and verifiable, therefore, oracles should also be proportionately secure themselves.An example of the perfect oracle security is then given. In a perfect world, we would have an impeccable data source, and a trusted third party running an oracle. The oracle would accept requests from smart contracts, obtain the requested data from the data source (over a secure channel), and return that data to the smart contract (digitally signed). In this scenario, we rely on the integrity of both the trusted third party (which is running the oracle) and the data source providing the data.Then a layer of complexity is added to the above scenario: confidentiality. When the smart contract creator creates a query, that would have been sent over plain-text to the oracle, which is undesirable. We add the requirement of encrypting the query sent to the oracle, so that it is not visible to the outside world. However, this adds a new problem: now the oracle can see the query once it has been decrypted. We are now relying again on the integrity of the trusted third party running the oracle.Another layer of complexity is added in the form of availability. Not only must the oracle remain online, but it also must appropriately respond to all requests. Meaning, it won’t choose to ignore or deny requests that its owner doesn’t agree with. This is similar to the underlying blockchain, in that nodes that operate on the blockchain layer do not censor certain transactions, they simply accept, validate, write, and maintain them accordingly.Finally, the ideal oracle represented in the “perfect world” scenario above is difficult to achieve because there are multiple factors that could compromise the integrity of the data given back to the smart contract. In the real-world, the data source itself could be compromised or report incorrect data. This sort of issue can be alleviated by using multiple data sources for a given assignment. Also, the notion of a trusted third party running an oracle is unrealistic simply because there could be bugs in the software running the oracle, or its system could be hacked or compromised itself. This would prevent the oracle from performing as its intended.The purpose of this section was to describe the ideal definition of an oracle for the ChainLink network. Though no such perfect oracle exists, the goal is to come as close as possible to the oracle in the “perfect world” scenario. This is one of the less-techy sections, but is critical for understanding the reasons why decentralization and trusted hardware is necessary for the secure and reliable delivery of data to the blockchain.See the ChainLink white paper here.ChainLink White Paper — Section 3— Oracle Security was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


17. 11. 17

ChainLink White Paper — Sec...

This section explains in detail the potential solutions for centralized data sources, centralized oracles, and trusting that those oracles are returning valid and accurate data. The section has two main subsections and distributing sources, distributing oracles. It also covers in detail the in-contract aggregation algorithm and provides an insight into the planned off-chain aggregation solution.Distributing sources is a way to ensure data validity by obtaining the result of a query from multiple providers of the same (or similar) data. A single oracle may retrieve data from multiple data sources using the same query and aggregate them into an answer. As mentioned in Section 2 (page 6) of the white paper, the method of aggregation can be customized specific to the data which is being processed (like discarding outliers). Additional problems related to distributed data sources is where one data provider obtains and releases information which it received from another data provider directly. This could result in invalid data coming from two separate data sources.Distributing oracles is the major advantage of the ChainLink network. This is a distributed system of oracles (the term “nodes” can be used interchangeably within the ChainLink network) contacting multiple data sources (some overlapping, some distinct) returning a single answer.In-contract aggregation will be used with the initial implementation of the ChainLink network. The aggregated answers from each node will be ran through a smart contract which will compute the final answer A to return to the user-created smart contract. Using in-contract aggregation provides value in that it remains simple, trustworthy, and flexible. The smart contract is available on the public blockchain and may be audited for errors.However, in-contract aggregation has a problem with oracles simply copying other oracles and returning the copied answer so that they don’t need to query a data source, called freeloading. Algorithm 1 (below) shows how freeloading can be eliminated by using a commit / reveal scheme. This means that each oracle will reveal their answer in the form of a commitment to the contract, which prevents other nodes from seeing the provided answer. After enough commitment messages have been received in the aggregation smart contract (this can vary due to block times and data provider response speed), nodes will reveal their answer within the decommit message.Algorithm 1: In-Contract Aggregation1. Wait until a query is received from the user-created smart contract2. Select nodes from the set of all valid session IDs3. Broadcast the query to the selected nodes4. Wait until commit messages are received from enough oracles to account for faulty nodes5. Broadcast that enough messages were received6. Wait until decommitments are received from enough oracles to account for honest nodes7. Send the answer along with the nodes that provided it to the user-created smart contractOff-chain aggregation is the longer-term solution for the ChainLink network and addresses the key problem that persists with in-contract aggregation, transaction cost. As more oracles (or nodes) are used, the transaction cost increases. Off-chain aggregation allows ChainLink to send a single aggregated answer to the smart contract, so that no matter how many oracles are used, it is still one transaction. Obtaining consensus of an aggregated answer in ChainLink will be different than Byzantine Fault Tolerant algorithms because the smart contract needs to receive an answer without participating in the aggregation itself. Consensus is accomplished by allowing each oracle generate a partial signature of its answer which together would create a verifiable signed answer from the collection of answers provided by all participating oracles. Freeloading is prevented in off-chain aggregation by requiring each oracle to obtain their data from the data provider instead of from one another.Section 4 ends here, but there is still a need to explain the algorithm mentioned for off-chain aggregation. Below is the simplified version of algorithm 2. The term enough is used frequently, and in all cases is used to account for faulty nodes.Algorithm 2: Distributed Oracle1. Receive a partial secret key2. Receive individual aggregate answer from the data source3. Create a partial signature with the partial secret key and answer4. Broadcast the partial signature with the answer and session ID5. Wait until enough nodes have committed their answers6. Send commitments to provider smart contract7. Broadcast the prepared message request8. Wait until enough prepared messages have been received9. Broadcast the decommitment with the partial signature10. Wait until enough decommitments are received from enough oracles11. If no valid whole signature has been received by the on-chain smart contract a. Aggregate the received decommitments into a valid signature b. Send the valid signatures to the on-chain smart contract c. Send the decommitments to the provider smart contractFinally, the algorithm for reward oracles is simplified below.Algorithm 3: Reward Oracles1. Wait until enough nodes have committed their answers and decommitment messages are received2. Send reward to oracles included in the accepted decommitment setThat wraps up Section 4 and it’s associated algorithms within the Off-Chain Aggregation appendix. The key take-away from this section is understanding how the commit / reveal scheme works. It’s basically a way to reveal that you (as an oracle) have an answer (the commit phase), and only reveal that answer after all other oracles have also made their commitments (reveal phase). Check out the ChainLink white paper here.ChainLink White Paper — Section 4 — ChainLink Decentralization Approach was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


17. 11. 13

ChainLink White Paper — Sec...

The Architectural Overview gives the detailed view for how ChainLink fits between the blockchain and the internet. It also provides the technical outlook for how the network will operate. ChainLink is going to be developed on Ethereum initially, with support for other blockchains and cross-chains at a later date. There is also a focus keeping the system separated so that any piece may be easily upgraded. The architectural overview is comprised of only two (but both very important) sub-sections: On-Chain Architecture and Off-Chain Architecture.On-Chain Architecture is the initial implementation for the ChainLink network. In this method, the majority of the work is done within smart contracts and the retrieving of the data is done within the node. The user-created smart contract is what supplies the query supplied by the smart contract creator for the nodes to individually carry out.The ChainLink smart contract’s on-chain components are comprised of a reputation contract, and order-matching contract, and an aggregating contract. The reputation contract is what keeps track of the metrics discussed in Section 5. The order-matching contract takes the parameters set by the smart contract creator and accepts bids from individual nodes according to the SLA. Finally, the aggregating contract is what collects each node’s answer and provides a final result to the user’s query (as well as provide metrics to the reputation contract). On-chain aggregation is broken into three steps: oracle selection, data reporting, and result aggregation.In oracle selection, the smart contract creator (or end-user) specifies the criteria needed by the smart contract, like what information they would like to gather and the number of and reputation of the nodes to be used in the assignment (assignment is another word used for the work required of the nodes). A listing service will be provided to make the oracle selection process easier on the smart contract creator. This will allow the smart contract creator to submit the assignment through the listing service (off-chain), but the final SLA will be met on-chain. Additionally, it may be possible to automatically determine which nodes would be best suited for the assignment with an order-matching contract. This would be possible with the use of rules configured on each node to determine whether they would automatically bid on the assignment or not. If an assignment matches the node’s own criteria, it will bid by paying the configured penalty amount (an amount that would be lost if the node returns unacceptable data). Nodes which were not accepted by the assignment will immediately be able to withdraw their penalty payment bid, and those that were selected will start the assignment.In data reporting, the nodes simply carry out the assignment as defined by the SLA. This means the node would connect to their API endpoints, process the data through their adapters, digitally sign their responses, and return their answers on-chain.In result aggregation, nodes reveal their results to the aggregating contract, which calculates an answer for the contract creator’s query. The aggregation contract uses each oracle’s response to report to the reputation contract its validity and timeliness. An additional property of the aggregation contract is that it is entirely configurable by the smart contract creator. In order to deal with varying answers, the smart contract creator my wish to configure the aggregation contract to ignore outlying answers before calculating an average, for example.The off-chain architecture is made up of the nodes which make up the ChainLink network. Each node must individually connect to other off-chain resources via API calls in order to gather responses for assignments. External adapters may be employed in order to extend the available connections for 3rd party API endpoints.The ChainLink core software is what translates off-chain data (data which was gathered via an API endpoint) into a way that can be read on-chain. It also handles the details of an assignment, including carrying out an assignment’s sub-tasks as they are configured and scheduled by the smart contract creator.External adapters are needed for connecting to 3rd party API endpoints. They can be written in any language as long as they conform to the schema defined by ChainLink. External adapters may also chain off one another, accepting the response of one adapter in order to produce another result.That’s all for this section of the ChainLink white paper. Also see this page which summarizes the ChainLink Smart Contract Process. Let me know what you think and feel free to leave any feedback.ChainLink White Paper — Section 2 — Architectural Overview was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


17. 11. 11

ChainLink White Paper — Sec...

I thought it’d be fun and informative to break up the whitepaper into easily-digestible chunks so that everyone can get a greater understanding of ChainLink and we can have a more focused discussion. Today, let’s look at a section of the white paper that isn’t commonly discussed in whole, Section 5, ChainLink Security Services. ChainLink Security Services encompasses 4 key security services: a validation system, a reputation system, a certification service, and a contract-upgrade service. The first three services provide guidance to users of the ChainLink system, and the last service is optional for users. We end the section with the LINK token usage.First, the validation system actively monitors each node on the ChainLink network. Nodes will be rated within this system based on their availability and correctness. Availability is measured by the node’s ability to respond to messages specifically for the purpose of uptime statistics. This means that if your node goes offline for any reason, it will negatively affect its availability rating. However, instead of a constant network “ping” for each node, this uptime will be measured as nodes digitally sign their responses and send to other nodes (for off-chain aggregation). Correctness is measured by comparing the node’s responses to the responses provided by other nodes in a given assignment. So any deviation of the node’s response outside of what the average from all node responses returned for an assignment would negatively affect this rating. Availability and correctness of nodes will be visible on-chain, meaning node listing services will be able to display these statistics publicly about all nodes on the ChainLink network.The reputation system will also contain on-chain history which can be publicly referenced with a listing service (and other smart contracts). This is probably the part of the Security Section that most of us are familiar with, as it defines the majority of the factors in which individual nodes are rated on (except for the two in the previous section). The reputation system keeps track of a node’s total number of assigned, completed, and accepted requests, the average time to respond, and the amount of penalty payments. The total number of assigned requests includes both the fulfilled and unfulfilled assignments (in case the node is still executing an assignment). The total number of completed requests includes all past requests and can be averaged with the assigned requests to make a completion rate for the node. The total number of accepted requests is the number of requests that have been accepted when comparing to the node’s peer responses. This can also be averaged with other metrics for an accuracy rate on the node. The average time to respond is calculated based on a node’s completed requests. And finally, the amount of penalty payments shows how much a node has locked into its assignment. The overall purpose of the reputation system is to provide incentive for nodes to product honest data in a timely manner so that they may be chosen more often.The certification service is used to prevent nodes from cheating with their answers. One form of attack, freeloading, is discussed in other sections of the white paper, but the certification service is focused on different types of attacks, sybil and mirroring. A sybil attack is where an attacker would control multiple nodes in the ChainLink network, attempting to control enough so that their falsified answer would be accepted as the correct answer given to a smart contract. Mirroring could also be used by compromised nodes to obtain their data from one another, instead of querying a data source individually. The long-term plan against both attacks is to utilize trusted hardware (Intel SGX), but until then, the certification service will detect and help prevent these attacks by issuing endorsements of high-quality oracle providers. These endorsements would be based on the node’s rating within the validation system and would perform spot-checking of answers compared to other trusted nodes. The certification service also introduces the need for off-chain audits of nodes to ensure that they comply with security standards. Finally, the security service will perform reviews of answers after they have been given to the smart contract to ensure that the data has not been falsified.The contract-upgrade service is an optional service that users of the ChainLink network can choose to utilize if they wish to have security updates applied to their smart contracts. If or when vulnerabilities are discovered, the contract-upgrade service would make a new smart contract based on the existing one, and migrate it along with its assignments to the upgraded contract. A flag (as an instruction of code) can be used to indicate use of the upgraded contract instead of the old one. All changes made by the contract-upgrade service would be visible on-chain and available for audit even before upgrading. Understanding that some users won’t feel comfortable with a single entity (ChainLink, in this case) controlling smart contract migration and forwarding, the power to utilize this service remains with the smart contract creator.Finally, the LINK token usage is discussed at the end of the section. ChainLink uses the LINK token to pay node operators for retrieving and formatting data. Additional work via adapters can also be accomplished within the node’s software, including aggregation and other computation methods. A node’s uptime and other reputation-based metrics act as guarantees that the node will respond accordingly. The node operators set their own prices for data retrieval and computation to be paid in LINK tokens.That’s it for the ChainLink Security Services section of the white paper. Everything here is summarized directly from the white paper, just hopefully in a way that makes it a little easier to understand. If you think this is a good idea to break down the sections like this, let me know and I’ll keep doing this. I don’t plan on going in any particular order (what fun would that be?) since much of the white paper can be read from any point as long as you have a general understanding of what ChainLink is doing.Be sure to check out the white paper directly, here: White Paper — Section 5 — ChainLink Security Services was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.


17. 11. 07

Transaction History
Transaction History Address
Bithumb Short cut
CoinBene Short cut
CoinAll Short cut
Paribu Short cut
BKEX Short cut
Cat.Ex Short cut
Hubi Short cut
CoinEx Short cut
Bitrue Short cut
CoinPlace Short cut
Mercatox Short cut
Huobi Global Short cut
Kyber Network Short cut
Binance Short cut
Bitkub Short cut
OKEx Short cut Short cut
LiveCoin Short cut
Switcheo Network Short cut
AirSwap Short cut
Huobi Korea Short cut
Radar Relay Short cut
COSS Short cut
Iquant Short cut
IDEX Short cut
DDEX Short cut
ProBit Short cut
Security verification

There is security verification of the project
Why security verification is necessary?

Read more


* Written questions can not be edited.

* The questions will be answered directly by the token team.

Platform ERC20
Hard cap -
Audit -
Stage -
Location -