Open in app

Sign in

Write

Sign in

ChainLink: Detailed review on the project

Paradigm
Paradigm
Published in
41 min readMar 27, 2019

Table of Contents

Introduction
Technology
Architectural Overview
- On-Chain Architecture
- Off-Chain Architecture
Oracle Security
ChainLink Decentralization Approach
ChainLink Security Services
Team
Partnerships
Use case
Social metrics
Markets and volume
TA
Competitors
Roadmap
Token Mechanics
Token Metrics
Summary

Introduction

The ChainLink network provides reliable tamper-proof inputs and outputs for complex smart contracts on any blockchain.

Building a truly valuable smart contract requires the use of multiple inputs to prove contractual performance, as well as multiple outputs to affect outside systems and/or send payment to complete the smart contract. ChainLink provides smart contracts with the inputs and outputs they need to reach its full potential.

Smart contracts require secure middleware to connect them to real world data. This external data will trigger the contract, creating the need for its high reliability.

ChainLink’s decentralized oracle network provides the same security guarantees as smart contracts themselves. By allowing multiple ChainLinks to evaluate the same data before it becomes a trigger, any one point of failure gets eliminated, and the overall value of a smart contract that is highly secure, reliable, and trustworthy is maintained.

Technology

Architectural Overview

ChainLink’s core functional objective is to bridge two environments: on-chain and offchain. ChainLink will initially be built on Ethereum, but team intends for it to support all leading smart contract networks for both off-chain and cross-chain interactions. In both its on and off-chain versions, ChainLink has been designed with modularity in mind. Every piece of the ChainLink system is upgradable, so that different components can be replaced as better techniques and competing implementations arise.

Figure 1: ChainLink workflow: 1) USER-SC makes an on-chain request; 2) CHAINLINK-SC logs an event for the oracles; 3) ChainLink core picks up the event and routes the assignment to an adapter; 4) ChainLink adapter performs a request to an external API; 5) ChainLink adapter processes the response and passes it back to the core; 6) ChainLink core reports the data to CHAINLINK-SC; 7) CHAINLINK-SC aggregates responses and passes them back as a single response to USER-SC.

On-Chain Architecture

As an oracle service, ChainLink nodes return replies to data requests or queries made by or on behalf of a user contract, which ChainLink’s team refers to as requesting contracts and denote by USER-SC. ChainLink’s on-chain interface to requesting contracts is itself an on-chain contract that ChainLink’s team denotes by CHAINLINK-SC.

Behind CHAINLINK-SC, ChainLink has an on-chain component consisting of three main contracts:

a reputation contract,

an order-matching contract,

and an aggregating contract.

The reputation contract keeps track of oracle-service-provider performance metrics. The order-matching smart contract takes a proposed service level agreement, logs the SLA parameters, and collects bids from oracle providers. It then selects bids using the reputation contract and finalizes the oracle SLA. The aggregating contract collects the oracle providers’ responses and calculates the final collective result of the ChainLink query. It also feeds oracle provider metrics back into the reputation contract. ChainLink contracts are designed in a modular manner, allowing for them to be configured or replaced by users as needed.

The on-chain work flow has three steps:

1) oracle selection,

2) data reporting,

3) result aggregation.

Oracle Selection. An oracle services purchaser specifies requirements that make up a service level agreement (SLA) proposal. The SLA proposal includes details such as query parameters and the number of oracles needed by the purchaser. Additionally, the purchaser specifies the reputation and aggregating contracts to be used for the rest of the agreement.

Using the reputation maintained on-chain, along with a more robust set of data gathered from logs of past contracts, purchasers can manually sort, filter, and select oracles via off-chain listing services. ChainLink’s team intentions is for ChainLink to maintain one such listing service, collecting all ChainLink-related logs and verifying the binaries of listed oracle contracts. The data used to generate listings will be pulled from the blockchain, allowing for alternative oracle-listing services to be built. Purchasers will submit SLA proposals to oracles off-chain, and come to agreement before finalizing the SLA on-chain.

Manual matching is not possible for all situations. For example, a contract may need to request oracle services dynamically in response to its load. Automated solutions solve this problem and enhance usability. For these reasons, automated oracle matching is also being proposed by ChainLink through the use of order-matching contracts.

Once the purchaser has specified their SLA proposal, instead of contacting the oracles directly, they will submit the SLA to an order-matching contract. The submission of the proposal to the order-matching contract triggers a log that oracle providers can monitor and filter based on their capabilities and service objectives. ChainLink nodes then choose whether to bid on the proposal or not, with the contract only accepting bids from nodes that meet the SLA’s requirements. When an oracle service provider bids on a contract, they commit to it, specifically by attaching the penalty amount that would be lost due to their misbehavior, as defined in the SLA.

Bids are accepted for the entirety of the bidding window. Once the SLA has received enough qualified bids and the bidding window has ended, the requested number of oracles is selected from the pool of bids. Penalty payments that were offered during the bidding process are returned to oracles who were not selected, and a finalized SLA record is created. When the finalized SLA is recorded it triggers a log notifying the selected oracles. The oracles then perform the assignment detailed by the SLA.

Data Reporting. Once the new oracle record has been created, the off-chain oracles execute the agreement and report back on-chain.

Result Aggregation. Once the oracles have revealed their results to the oracle contract, their results will be fed to the aggregating contract. The aggregating contract tallies the collective results and calculates a weighted answer. The validity of each oracle response is then reported to the reputation contract. Finally, the weighted answer is returned to the specified contract function in USER-SC.

Detecting outlying or incorrect values is a problem that is specific to each type of data feed and application. For instance, detecting and rejecting outlying answers before averaging may be necessary for numeric data but not boolean. For this reason, there will not be a specific aggregating contract, but a configurable contract address which is specified by the purchaser. ChainLink will include a standard set of aggregating contracts, but customized contracts may also be specified, provided they conform to the standard calculation interface.

Off-Chain Architecture

Off-chain, ChainLink initially consists of a network of oracle nodes connected to the Ethereum network, and ChainLink’s team intends for it to support all leading smart contract networks. These nodes independently harvest responses to off-chain requests. Their individual responses are aggregated via one of several possible consensus mechanisms into a global response that is returned to a requesting contract USER-SC. The ChainLink nodes are powered by the standard open source core implementation which handles standard blockchain interactions, scheduling, and connecting with common external resources. Node operators may choose to add software extensions, known as external adapters, that allow the operators to offer additional specialized off-chain services. ChainLink nodes have already been deployed alongside both public blockchains and private networks in enterprise settings; enabling the nodes to run in a decentralized manner is the motivation for the ChainLink network.

ChainLink Core. The core node software is responsible for interfacing with the blockchain, scheduling, and balancing work across its various external services. Work done by ChainLink nodes is formatted as assignments. Each assignment is a set of smaller job specifications, known as subtasks, which are processed as a pipeline. Each subtask has a specific operation it performs, before passing its result onto the next subtask, and ultimately reaching a final result. ChainLink’s node software comes with a few subtasks built in, including HTTP requests, JSON parsing, and conversion to various blockchain formats.

External Adapters. Beyond the built-in subtask types, custom subtasks can be defined by creating adapters. Adapters are external services with a minimal REST API. By modeling adapters in a service-oriented manner, programs in any programming language can be easily implemented simply by adding a small intermediate API in front of the program. Similarly, interacting with complicated multi-step APIs can be simplified to individual subtasks with parameters.

Subtask Schemas. The team anticipates that many adapters will be open sourced, so that services can be audited and run by various community members. With many different types of adapters being developed by many different developers, ensuring compatibility between adapters is essential.

ChainLink currently operates with a schema system based on JSON Schema, to specify what inputs each adapter needs and how they should be formatted. Similarly, adapters specify an output schema to describe the format of each subtask’s output.

Oracle Security

In order to explain ChainLink’s security architecture, it must first be explained why security is important — and what it means.

Why must oracles be secure? If a smart contract security gets a false data feed, it might payout the incorrect party, if smart contract insurance data feeds can be tampered with by the insured party there may be insurance fraud, and if GPS data given to a trade finance contract can be modified after it leaves the data provider, payment can be released for goods that haven’t arrived.

Generally, a well-functioning blockchain, with its ledger or bulletin-board abstraction, offers very strong security properties. Users rely on the blockchain as a functionality that correctly validates transactions and prevents data from being altered. They treat it in effect like a trusted third party. A supporting oracle service must offer a level of security commensurate with that of the blockchain it supports. An oracle too must therefore serve users as an effective trusted third party, providing correct and timely responses with very high probability. The security of any system is only as strong as its weakest link, so a highly trustworthy oracle is required to preserve the trustworthiness of a well-engineered blockchain.

Defining oracle security: An ideal view. In order to reason about oracle security, we must first define it. An instructive, principled way to reason about oracle security stems from the following thought experiment. Imagine that a trusted third party (TTP) — an ideal entity or functionality that always carries out instructions faithfully to the letter — were tasked with running an oracle. We’ll denote this oracle by ORACLE (using all caps in general to denote an entity fully trusted by users), and suppose that the TTP obtains data from a perfectly trustworthy data source Src. Given this magical service ORACLE, what instructions would we ask it to carry out?

Figure 2: Behavior of an ideal oracle ORACLE is defined by steps: 1) Accept request; 2) Obtain data; 3) Return data. Additionally, to protect the confidentiality of a request, upon decrypting it, ORACLE never uses or reveals the data it contains, except to query Src.

To achieve the property of integrity, also referred to as the authenticity property, it should simply be asked that ORACLE perform the following steps:

1. Accept request: Ingest from a smart contract USER-SC a request Req = (Src, τ, q) that specifies a target data source Src, a time or range of times τ, and a query q;

2. Obtain data: Send query q to Src at time τ;

3. Return data: On receiving answer a, return a to the smart contract.

These simple instructions, correctly carried out, define a strong, meaningful, but simple notion of security. Intuitively, they dictate that ORACLE acts as a trustworthy bridge between Src and USER-SC. For example, if Src is https://www.FountOfKnowledge.com, τ is 4 p.m., and q = “price for ticker INTC”, the integrity of ORACLE guarantees that it will provide USER-SC with exactly the price of INTC as queried at 4 p.m. at https://www.FountOfKnowledge.com.

Confidentiality is another desirable property for oracles. As USER-SC sends Req to ORACLE in the clear on the blockchain, Req is public. There are many situations in which Req is sensitive and its publication could be harmful. If USER-SC is a flight insurance contract, for example, and sends ORACLE a query Req regarding a particular user’s flight (q = “Ether Air Flight 338”), the result would be that a user’s flight plans are revealed to the whole world. If USER-SC is a contract for financial trading, Req could leak information about a user’s trades and portfolio. There are many other examples, of course.

To protect the confidentiality of Req, it can be required that data in Req was encrypted under a (public key) belonging to ORACLE. Continuing to leverage the TTP nature of ORACLE, the information-flow constraint could then simply be given to ORACLE:

Upon decrypting Req, never reveal or use data in Req except to query Src.

There are other important oracle properties, such as availability, the last of the classical CIA (Confidentiality-Integrity-Availability) triad. A truly ideal service ORACLE, of course, would never go down. Availability also encompasses more subtle properties such as censorship resistance: An honest ORACLE will not single out particular smart contracts and deny their requests.

The concept of a trusted third party is similar to the notion of an ideal functionality used to prove the security of cryptographic protocols in certain models. We can also model a blockchain in similar terms, conceptualizing it in terms of a TTP that maintains an ideal bulletin board. Its instructions are to accept transactions, validate them, serialize them, and maintain them permanently on the bulletin board, an append-only data structure.

Why the ideal oracle (ORACLE) is hard to achieve. There is, of course, no perfectly trustworthy data source Src. Data may be benignly or maliciously corrupted due to faulty web sites, cheating service providers, or honest mistakes.

If Src isn’t trustworthy, then even if ORACLE does operate exactly like a TTP as instructed above, it still doesn’t completely meet the notion of security ChainLink’s team wants. Given a faulty source Src, the integrity property defined above no longer means that an oracle’s answer a is correct. If the true price of Intel is $40 and https://www.FountOfKnowledge.com misreports it as $50, for example, then ORACLE will send the incorrect value a = $50 to USER-SC. This problem is unavoidable when using a single source Src. ORACLE simply has no way to know whether the answers Src provides to its queries are correct.

A bigger issue, of course, is the fact that ChainLink’s TTP for ORACLE is just an abstraction. No service provider is unconditionally trustworthy. Even the best-intentioned may be buggy or hacked. So there is no way to for a user or smart contract to have absolute assurance that a service ORACLE will carry out its instructions faithfully.

ChainLink reasons about its security protocols in terms of this ideal functionality ORACLE. The goal in ChainLink is to achieve a real world system with properties as close as possible to those of ORACLE under realistic trust assumptions.

For simplicity in what follows, the complete set of ChainLink contracts, i.e., its full on-chain functionality (not just its interface 10 to requesting contracts) is now denoted by CHAINLINK-SC . The multiple individual contracts actually used in the system architecture are thereby abstracted away .

ChainLink Decentralization Approach

three basic complementary approaches to ensuring against faulty nodes proposed are:

  1. Distribution of data sources;
  2. Distribution of oracles;
  3. and Use of trusted hardware.

As some media platforms do not support subscripts later in the text, they will be replaced by a symbol “-”, where it is appropriate

Example: equals A-1

Distributing sources
A simple way to deal with a faulty single source Src is to obtain data from multiple sources, i.e., distribute the data source. A trustworthy ORACLE can query a collection of sources Src-1, Src-2, . . . , Src-k, obtain responses a-1, a-2, . . . , a-k, and aggregate them into a single answer A = agg(a-1, a-2, . . . , a-k). ORACLE might do this in any of a number of ways. One, for example, is majority voting. If a majority of sources return the identical value a, the function agg returns a; otherwise it returns an error. In this case, provided that a majority (> k/2) sources are functioning correctly, ORACLE will always return a correct value A.

Many alternative functions agg can ensure robustness against erroneous data or handle fluctuations in data values over time (e.g, stock prices). For example, agg might discard outliers (e.g., the largest and smallest values ai) and output the mean of the remaining ones.

Of course, faults may be correlated across data sources in a way that weakens the assurances provided by aggregation. If site Src-1 = EchoEcho.com obtains its data from Src-2 = TheHorsesMouth.com, an error at Src-2 will always imply an error at Src-1. More subtle correlations between data sources can also occur. ChainLink also proposes to pursue research into mapping and reporting the independence of data sources in an easily digestible way so that oracles and users can avoid undesired correlations.

Figure 3: Requests are distributed across both oracles and data sources. This figure shows an example of such two-level distribution.

Distributing oracles

Just as sources can be distributed, ChainLink’s ideal service ORACLE itself can be approximated as a distributed system. This is to say that instead of a single monolithic oracle node O, we can instead have a collection of n different oracle nodes {O-1, O-2, . . . , O-n}. Each oracle O-i contacts its own distinct set of data sources which may or may not overlap with those of other oracles. O-i aggregates responses from its data sources and outputs its own distinct answer A-i to a query Req.

Some of these oracles may be faulty. So clearly the set of all oracles’ answers A-1, A-2, . . . , A-n will need to be aggregated in a trustworthy way into a single, authoritative value A. But given the possibility of faulty oracles, where and how will this aggregation happen in ChainLink?

Initial solution: In-contract aggregation. The initial proposed solution in ChainLink will be a simple one called in-contract aggregation. CHAINLINK-SC — which, again, denotes the on-chain part of ChainLink — will itself aggregate oracle responses. (Alternatively, CHAINLINK-SC may call another aggregation contract, but for conceptual simplicity we assume that the two components form a single contract.) In other words, CHAINLINK-SC will compute A = Agg(A1, A2, . . . , An) for some function Agg (similar to agg, as described above), and send the result A to USER-SC.

This approach is practical for small n, and has several distinct benefits:

  • Conceptual simplicity: Despite the fact that the oracle is distributed, a single entity, CHAINLINK-SC, performs aggregation by executing Agg.
  • Trustworthiness: As CHAINLINK-SC’s code can be publicly inspected, its correct behavior can be verified. (CHAINLINK-SC will be a relatively small, simple piece of code.) Additionally, CHAINLINK-SC’s execution is fully visible on chain. Thus users, i.e., creators of USER-SC, can achieve a high degree of trust in CHAINLINK-SC.
  • Flexibility: CHAINLINK-SC can implement most desired aggregation functions Agg — the majority function, averaging, etc.

Simple as it is, this approach presents a novel and interesting technical challenge, namely the problem of freeloading. A cheating oracle O-z can observe the response A-i of another oracle O-i and copy it. In this way, oracle O-z avoids the expense of querying data sources, which may charge per-query fees. Freeloading weakens security by undermining the diversity of data source queries and also disincentivizes oracles from responding quickly: Responding slowly and freeloading is a cheaper strategy.

ChainLink’s team suggest a well known solution to this problem, namely the use of a commit / reveal scheme. In a first round, oracles send CHAINLINK-SC cryptographic commitments to their responses. After CHAINLINK-SC has received a quorum of responses, it initiates a second round in which oracles reveal their responses.

Algorithm 1 shows a simple sequential protocol that guarantees availability given 3f+1 nodes. It uses a commit / reveal scheme to prevent freeloading. Oracle responses are decommitted, and thus exposed to a potential freeloader only after all commitments have been made, thereby excluding the freeloader from copying other oracles’ responses.

On-chain protocols can leverage block times to support synchronous protocol designs. In ChainLink, however, oracle nodes obtain data from sources that may have highly variable response times, and decommitment times by nodes can vary due to, e.g., use of different gas prices in Ethereum. To ensure the fastest possible protocol responsiveness, therefore, Alg. 1 is designed as an asynchronous protocol.

Here, Commit-r(A) denotes a commitment of value A with witness r, while SID denotes the set of valid session ids. The protocol assumes authenticated channels among all players.

It is easy to see that Alg. 1 will terminate successfully. Given 3f + 1 nodes in total, at most f are faulty, so at least 2f + 1 will send commitments in Step 4. Of those commitments, at most f come from faulty nodes, so at least f + 1 come from honest nodes. All such commitments will eventually be decommitted.

Additionally, it is easy to see that A will be correct in Alg.1. Of the f + 1 decommitments on the single value A, at least one has to come from an honest node.

In-contract aggregation via Alg. 1 will be the main approach supported by ChainLink in the short term. The proposed initial implementation will involve a more sophisticated, concurrent variant of the algorithm. ChainLink’s longer-term proposal is reflected in the rather more complicated protocol OCA (Off-Chain Aggregation) specified in Algorithms 2 and 3 in Appendix A. OCA is an off-chain aggregation protocol that minimizes on-chain transaction costs. That protocol also includes payment to oracle nodes and ensures against payments to freeloaders.

Algorithm 1 InChainAgg(

) (code for CHAINLINK-SC)

1: Wait until Req is received from USER-SC.

2: sid ←$ SID

3: Broadcast (request, sid).

4: Wait until set C of 2f + 1 messages (commit,

,sid) from distinct O-i are received.

5: Broadcast (committed, sid).

6: Wait until set D of f + 1 distinct valid decommitments (decommit,(r-i , A-i),sid) are received where, for some A, all A-i = A.

7: Send (Answer, A, sid) to USER-SC.

Medium-term strategy: Off-chain aggregation. In-contract aggregation has a key disadvantage: Cost. It incurs the cost of transmitting and processing onchain O(n) oracle messages (commits and reveals for A-1, A-2, . . . , A-n). In permissioned blockchains, this overhead may be acceptable. In permissionless blockchains with onchain transaction fees such as Ethereum, if n is large, the costs can be prohibitive. A more cost-effective approach is to aggregate oracle responses off-chain and transmit a single message to CHAINLINK-SC A. ChainLink’s team proposes deployment of this approach, called off-chain aggregation, in the medium-to-long term.

The problem of achieving a consensus value A in the face of potentially faulty nodes is much like the problem of consensus that underpins blockchains themselves. Given a predetermined set of oracles, one might consider using a classical Byzantine Fault Tolerant (BFT) consensus algorithm to compute A. Classical BFT protocols, however, aim to ensure that at the end of a protocol invocation, all honest nodes store the same value, e.g., in a blockchain, that all nodes store the same fresh block. In ChainLink’s oracle setting, the goal is slightly different. ChainLink’s team wants to ensure that CHAINLINK-SC (and then USER-SC) obtains aggregate answer A = Agg(A-1, A-2, . . . , A-n) without participating in the consensus protocol and without needing to receive answers from multiple oracles. The problem of freeloading, moreover, still needs to be addressed.

The ChainLink system proposes the use of a simple protocol involving threshold signatures. Such signatures can be realized using any of a number of signature schemes, but are especially simple to implement using Schnorr signatures. In this approach, oracles have a collective public key pk and a corresponding private key sk that is shared among O-1, O-2, . . . , O-n in a (t, n)-threshold manner. Such a sharing means that every node O-i has a distinct private / public keypair (sk-i , pk-i ). O-i can generate a partial signature

that can be verified with respect to pk-i.

Figure 4: Sig-sk[A] can be achieved by any n/2+1 of the oracles.

The key feature of this setup is that partial signatures on the same value A can be aggregated across any set of t oracles to yield a single valid collective signature Σ = Sig-sk[A] on an answer A. No set of t − 1 oracles, however, can produce a valid signature on any value. The single signature Σ thus implicitly embodies the partial signatures of at least t oracles.

Threshold signatures can be realized naïvely by letting Σ consist explicitly of a set of t valid, independent signatures from individual nodes. Threshold signatures have similar security properties to this naïve approach. But they provide a significant onchain performance improvement: They reduce the size and cost of verifying Σ by a factor of t.

With this setup, it would seem that oracles can just generate and broadcast partial signatures until t such partial signatures enable the computation of Σ. Again, though, the problem of freeloading arises. It must therefore be ensured that oracles genuinely obtain data from their designated sources, rather than cheating and copying A-i from another oracle. ChinLink’s solution involves a financial mechanism: An entity PROVIDER (realizable as a smart contract) rewards only oracles that have sourced original data for their partial signatures.

In a distributed setting, determining which oracles qualify for payment turns out to be tricky. Oracles may intercommunicate off-chain and there is no longer a single authoritative entity (CHAINLINK-SC) receiving responses and are therefore unable to identify eligible payees directly among participating oracles. Consequently, PROVIDER must obtain evidence of misbehavior from the oracles themselves, some of which may be untrustworthy. ChainLink’s team proposes the use of consensus-like mechanisms in the solution for ChainLink to ensure that PROVIDER does not pay freeloading oracles.

The off-chain aggregation system the team proposes for ChainLink, with accompanying security proof sketches. It makes use of a distributed protocol based on threshold signatures that provides resistance to freeloading by f<n/3 oracles. ChainLink’s team believes resistance to freeloading is an interesting new technical problem.

ChainLink Security Services

Thanks to the protocols that were just described, ChainLink proposes to ensure availability and correctness in the face of up to f faulty oracles. Additionally, trusted hardware is being actively considered as a secure approach toward protecting against corrupted oracles providing incorrect responses. Trusted hardware, however, may not provide definitive protection for three reasons. First, it will not be deployed in initial versions of the ChainLink network. Second, some users may not trust trusted hardware. Finally, trusted hardware cannot protect against node downtime, only against node misbehavior. Users will therefore wish to to ensure that they can choose the most reliable oracles and minimize the probability of USER-SC relying on > f faulty oracles.

To this end, ChainLink’s team proposes the use of four key security services: a Validation System, a Reputation System, a Certification Service, and a Contract-Upgrade Service. All of these services may initially be run by one company or group interested in launching the ChainLink network, but are designed to operate strictly accordingly to ChainLink’s philosophy of decentralized design. ChainLink’s proposed security services cannot block oracle node participation or alter oracle responses. The first three services only provide ratings or guidance to users, while the Contract-Upgrade Service is entirely optional for users. Additionally, these services are designed to support independent providers, whose participation should be encouraged so that users will eventually have multiple security services among which to choose.

Validation System

The ChainLink Validation System monitors on-chain oracle behavior, providing an objective performance metric that can guide user selection of oracles. It will seek to monitor oracles for:

  • Availability: The Validation System should record failures by an oracle to respond in a timely way to queries. It will compile ongoing uptime statistics.
  • Correctness: The Validation System should record apparent erroneous responses by an oracle as measured by deviations from responses provided by peers.

In the initial, on-chain aggregation system in ChainLink, such monitoring is straightforward, as all oracle activity is visible to CHAINLINK-SC.

Recall, however, that in the off-chain aggregation system envisaged for ChainLink, it’s the oracles themselves that perform aggregation. Consequently, CHAINLINK-SC does not have direct visibility into oracle responses and cannot itself monitor availability and correctness.

Fortunately, oracles digitally sign their responses, and thus, as a side effect, generate non-repudiable evidence of their answers. ChinLink’s proposed approach will therefore be to realize the validation service as a smart contract that would reward oracles for submitting evidence of deviating responses. In other words, oracles would be incentivized to report apparently erroneous behavior.

Availability is somewhat trickier to monitor, as oracles of course don’t sign their failures to respond. Instead, a proposed protocol enhancement would require oracles to digitally sign attestations to the set of responses they have received from other oracles. The validation contract would then accept (and again reward) submission of sets of attestations that demonstrate consistent non-responsiveness by an underperforming oracle to its peers.

In both the on-chain and off-chain cases, availability and correctness statistics for oracles will be visible on-chain. Users / developers will thus be able to view them in real time through an appropriate front end, such as a Dapp in Ethereum or an equivalent application for a permissioned blockchain.

Reputation System

The Reputation System proposed for ChainLink would record and publish user ratings of oracle providers and nodes, offering a means for users to evaluate oracle performance holistically. Validator System reports are likely to be a major factor in determining oracle reputations and placing these reputations on a firm footing of trust. Factors beyond on-chain history, though, can provide essential information about oracle node security profiles. These may include users’ familiarity with oracles’ brands, operating entities, and architectures. The team envisions the ChainLink Reputation System to include a basic on-chain component where users’ ratings would be available for other smart contracts to reference. Additionally, reputation metrics should be easily accessible off-chain where larger amounts of data can be efficiently processed and more flexibly weighted.

For a given oracle operator, the Reputation System is initially proposed as supporting the following metrics, both at the granularity of specific assignment types, and also in general for all types supported by a node:

  • Total number of assigned requests: The total number of past requests that an oracle has agreed to, both fulfilled and unfulfilled.
  • Total number of completed requests: The total number of past requests that an oracle has fulfilled. This can be averaged over number of requests assigned to calculate completion rate.
  • Total number of accepted requests: The total number of requests that have been deemed acceptable by calculating contracts when compared with peer responses. This can be averaged over total assigned or total completed requests to get insight into accuracy rates.
  • Average time to respond: While it may be necessary to give oracle responses time for confirmation, the timeliness of their responses will be helpful in determining future timeliness. Average response time is calculated based on completed requests.
  • Amount of penalty payments: If penalty payments were locked in to assure a node operator’s performance, the result would be a financial metric of an oracle provider’s commitment not to engage in an “exit scam” attack, where the provider takes users’ money and doesn’t provide services. This metric would involve both a temporal and a financial dimension.

High-reputation services are strongly incentivized in any market to behave correctly and ensure high availability and performance. Negative user feedback will pose a significant risk to brand value, as do the penalties associated with misbehavior. Consequently, ChainLink’s team anticipates a virtuous circle in which well-functioning oracles develop good reputations and good reputations give rise to incentives for continued high performance.

Certification Service

While ChainLink’s Validation and Reputation Systems are intended to address a broad range of faulty behaviors by oracles and is proposed as a way to ensure system integrity in the vast majority of cases, ChainLink may also include an additional mechanism called a Certification Service. Its goal is to prevent and/or remediate rare but catastrophic events, specifically en bloc cheating in the form of Sybil and mirroring attacks.

Sybil and mirroring attacks. Both ChainLink’s simple and in-contract aggregation protocols seek to prevent freeloading in the sense of dishonest nodes copying honest nodes’ answers. But neither protects against Sybil attacks. Such attacks involve an adversary that controls multiple, ostensibly independent oracles. This adversary can attempt to dominate the oracle pool, causing more than f oracles to participate in the aggregation protocol and provide false data at strategic times, e.g., in order to influence large transactions in high-value contracts. Quorums of cheating oracles can also arise not just under the control of a single adversary, but also through collusion among multiple adversaries. Attacks or faults involving > f oracles are especially pernicious in that they are undetectable from on-chain behavior alone.

Additionally, to reduce operational costs, a Sybil attacker can adopt a behavior called mirroring, in which it causes oracles to send individual responses based on data obtained from a single data-source query. In other words, misbehaving oracles may share data off-chain but pretend to source data independently. Mirroring benefits an adversary whether or not it chooses to send false data. It poses a much less serious security threat than data falsification, but does slightly degrade security in that it eliminates the error correction resulting from diversified queries against a given source Src. For example, if https://www.datasource.com emits erroneous data due to, say, a sporadically triggered bug, multiple queriers may still obtain a correct majority result.

Sybil attacks resulting in false data, mirroring, and collusion in general may be eliminated by the use of trusted hardware in ChainLink’s long-term strategy.

Certification Service design. The ChainLink Certification Service would seek to provide general integrity and availability assurance, detecting and helping prevent mirroring and colluding oracle quorums in the short-to-medium term. The Certification Service would issue endorsements of high-quality oracle providers. ChainLink’s team emphasizes again, as noted above, that the service will only rate providers for the benefit of users. It is not meant to dictate oracle node participation or non-participation in the system.

The Certification Service supports endorsements based on several features of oracle deployment and behavior. It would monitor the Validation System statistics on oracles and perform post-hoc spot-checking of on-chain answers — particularly for high-value transactions — comparing them with answers obtained directly from reputable data sources. With sufficient demand for an oracle provider’s data, ChainLink’s team expects there to be enough economic incentive to justify off-chain audits of oracle providers, confirming compliance with relevant security standards, such as relevant controls in the Cloud Security Alliance (CSA) Cloud Controls Matrix, as well as providing useful security information that they conduct proper audits of oracles’ source and bytecode for their smart contracts.

In addition to the reputation metrics, automated on-chain and automated offchain systems for fraud detection, the Certification Service is planned as a means to identify Sybil attacks and other malfeasance that automated on-chain systems cannot. For example, if all nodes agree that the moon is made of green cheese, they can cause USER-SC to ingest this false fact. MOON COMPONENTS = {GREEN CHEESE} will be recorded on the blockchain, however, and visible in a post-hoc review.

Contract-Upgrade Service

As recent smart contract hacks have shown, coding bulletproof smart contracts is an extremely challenging exercise. And even if a smart contract has been correctly programmed, environmental changes or bugs can still result in vulnerabilities.

For this reason, ChainLink’s team proposes a Contract-Upgrade Service. The team emphasizes that use of this service is entirely optional and in control of users.

In the short term, if vulnerabilities are discovered, the Contract-Upgrade Service would simply make a new set of supporting oracle contracts available in ChainLink. Newly created requesting smart contracts will then be able to migrate to the new set of oracle contracts.

Unfortunately, though, existing ones would be stuck with the old, potentially vulnerable set. In the longer term, therefore, CHAINLINK-SC would support a flag (MIGFLAG) in oracle calls from requesting contracts indicating whether or not a call should be forwarded to a new CHAINLINK-SC should one become available. Set by default (i.e., if the flag is missing) to false, MIGFLAG would enable requesting contracts to benefit from automatic forwarding and thus migration to the new version of CHAINLINK-SC. In order to activate forwarding, a user will cause her requesting contract to issue ChainLink requests with MIGFLAG = true. (Users can engineer their smart contracts so that they change this flag upon receiving an instruction to do so on-chain from an authorized contract administrator.)

Migration of users to new oracle contracts functions as a kind of “escape hatch,” something long advocated for by blockchain researchers as a mechanism to fix bugs and remediate hacks without resorting to such cumbersome approaches as whitehat hacking or hard forks. Migration to the updated contracts will be visible on the blockchain, and available to audit for users to review before upgrading.

ChainLink’s team recognizes nonetheless that some users will not feel comfortable with any one group controlling an escape hatch in the form of migration / forwarding. Forced migration could empower the migrating contract’s controller, or a hacker who compromises relevant credentials, to undertake malicious activity, such as changing oracle responses. It is for this reason that requesting contracts have full control of the forwarding feature and can thus opt out of escape-hatch activation. Additionally, in accordance with ChainLink’s focus on decentralization, ChainLink’s team expects that providers will be able to support multiple versions of CHAINLINK-SC developed by the community.

Design Principles

As team continues their work on ChainLink, the team will seek to prioritize the following core values:

  • Decentralization for secure and open systems. Decentralization is not only the foundation of the tamperproof properties of blockchains, but the basis of their permissionless nature. By continuing to build decentralized systems, ChainLink’s team aims to further enable permissionless development within the ecosystem. ChainLink’s team believes that decentralization is a crucial component for a globally thriving ecosystem with long-term sustainability.
  • Modularity for simple, flexible system design. ChainLink’s team appreciates the philosophy of building small tools which do one thing well. Simple components can be easily reasoned about and thus securely combined into larger systems. ChainLink’s team believes that modularity not only enables upgradable systems, but facilitates decentralization. Wherever key pieces of ChainLink depend on or are managed by too few parties, ChainLink’s team will seek to design an ecosystem which allows for competing implementations to be used.
  • Open source for secure, extensible systems. ChainLink is made possible by standing on the shoulders of many open source projects. ChainLink’s team values the community and will continue to contribute by developing ChainLink in an open source manner. ChainLink’s team plans to engage continually with developers, academics, and security experts for peer review. ChainLink’s team encourages testing, audits, and formal proofs of security, all with the aim of creating a platform whose robustness and security can support future innovations

Source.

Team

Source: ChainLink website.

Sergey Nazarov — CEO.

Starting his career at FirstMark Capital, he left to join the cryptocurrency revolution in 2011. He firmly believes blockchain technology has the ability to change the way societies distribute wealth, enforce contracts, and share critical information.

Steve Ellis — CTO.

Previously a software engineer and team lead at Pivotal Labs, where he worked on securing sensitive HIPAA compliant data and building scalable payments automation software. He’s a big fan of Ethereum, Bitcoin and the decentralized future.

Dimitri Roche — Software Engineer.

Dimitri was previously a software engineer at Pivotal Labs and McKinsey. Going on to lead engineering teams at large companies like infogroup. He’s excited about the positive societal impact of smart contracts, through the fairness and transparency they create.

Mark Oblad — Head of Operations.

Mark began his career at Gunderson Dettmer, helping manage the growth of leading global hedge funds. Going on to build Valcu, a technical leader in contracts automation software, where Mark saw the large potential of externally connected smart contracts.

Alex Kwiatkowski — Software Engineer.

Alex is an experienced software engineer who previously worked at Pivotal Labs and Northpass, building secure and highly scalable enterprise software. He’s excited about the positive impact that well made smart contracts will have on the world’s global financial system.

John Barker — Software Engineer.

After an academic career studying the security of the Tor network, John went on to lead development teams that have built some of the largest big data processing systems, while also making open-source contributions to leading projects like the Rust programming language.

Dan Kochis — Global Head of BD & Partnerships.

Dan has a long history of closing deals that help companies reach their next stage of growth globally. He was integral to Alibaba’s first US acquisition, various worldwide strategic partnerships worth over $120MM in annual revenue, and corporate exits totaling over $4bn.

Adelyn Zhou — Director of Marketing.

Adelyn is an experienced growth marketer, whose senior roles at her previous companies have led them to be acquired by industry leaders like Amazon. Adelyn is also an expert in Applied Artificial Intelligence, and believes smart contracts have a large contribution to make in that field.

Thomas Hodges — Integration Engineer.

Thomas is an experienced integration engineer, helping plan and manage large software deployments for enterprise customers. He is also a big fan of ChainLink, and the decentralized future.

Rory Piant — Community Manager.

Rory is an experienced community manager, with a genuine passion for seeing worthwhile technologies like ChainLink get adopted by the larger smart contracts and cryptocurrency communities.

Advisors

Source: ChainLink website.

Ari Juels — Technical Advisor.

Ari is a professor of computer science in the Jacobs Institute at Cornell Tech and a co-director of IC3 (Initiative for Cryptocurrencies and Contracts). He was previously the chief scientist of RSA.

Andrew Miller — Technical Advisor.

Andrew is a well known leader in decentralized consensus research and secure blockchain infrastructure. He’s an associate professor of computer science at the University of Illinois and an advisor to both Zcash and Tezos.

Evan Cheng — Technical Advisor.

Evan is one of the creators of LLVM which generates the low level machine code running every Apple device, as well as much of Google, Nvidia, and Intel. He is currently Director of Engineering at Facebook.

Tom Gonser — Advisor.

Tom is the founder of DocuSign, the leading e-signature company that revolutionized digital contracts. He is a seasoned entrepreneur, executive and board member who has created billions of dollars in enterprise value.

Hudson Jameson — Technical Advisor.

Hudson is the Ethereum community manager, a well known authority on smart contracts, and the Ethereum development roadmap. He’s written about why he’s supporting our work.

Jake Brukhman — Advisor.

Jake was previously the CTO at Triton Research, going on to launch CoinFund, one of the leading research groups focused on web 3.0 and blockchain-based infrastructure.

Brian Lio — Advisor.

Brian is the CEO of Smith+Crown, a widely accepted leader in blockchain research. Providing in-depth analysis of both ongoing token sales and the larger evolution of decentralized technology over the past 2 years.

Partnerships

Synthetix

Provable (former Oracalize)

Celer

Bodhi and Naka Chain

Katallassos

STK

Mobilum

ETHA

Olympus Labs

RTrade Technologies Ltd

Kaiko

Wanchain

Hydrogen

Kaleido (ConsenSys)

bZx

Town Crier (Acquired by Chainlink)

Morpheus.Network

Web3

BraveNewCoin

GameDex

MARKET Protocol

OpenLaw (ConsenSys)

Accord Project

ZeppelinOS

ClinTex

  • Announced: July 2017
  • Clintex Annoucement: ClinTex Partners with Chainlink
  • ChainLink’s Annoucement: on Rory’s list of partnerships in the Official Chainlink Telegram

Source

Use case

Oracles, ideally, provide a trustless (or at least near-trustless) way of getting extrinsic (i.e., “rea-world” or off-chain) information, such as the results of football games, the price of gold, or truly random numbers, onto the Ethereum platform for smart contracts to use. They can also be used to relay data securely to DApp frontends directly. Oracles can therefore be thought of as a mechanism for bridging the gap between the off-chain world and smart contracts. Allowing smart contracts to enforce contractual relationships based on real-world events and data broadens their scope dramatically.

Some more examples of data that might be provided by oracles include:

  • Random numbers/entropy from physical sources such as quantum/thermal processes: e.g., to fairly select a winner in a lottery smart contract
  • Parametric triggers indexed to natural hazards: e.g., triggering of catastrophe bond smart contracts, such as Richter scale measurements for an earthquake bond
  • Exchange rate data: e.g., for accurate pegging of cryptocurrencies to fiat currency
  • Capital markets data: e.g., pricing baskets of tokenized assets/securities
  • Benchmark reference data: e.g., incorporating interest rates into smart financial derivatives
  • Static/pseudostatic data: security identifiers, country codes, currency codes, etc.
  • Time and interval data: for event triggers grounded in precise time measurements
  • Weather data: e.g., insurance premium calculations based on weather forecasts
  • Political events: for prediction market resolution
  • Sporting events: for prediction market resolution and fantasy sports contracts
  • Geolocation data: e.g., as used in supply chain tracking
  • Damage verification: for insurance contracts
  • Events occurring on other blockchains: interoperability functions
  • Ether market price: e.g., for fiat gas price oracles
  • Flight statistics: e.g., as used by groups and clubs for flight ticket pooling

Source

Social metrics

Github metrics
Social media activity

Markets and volume

Information from Coinmarketcap.com:

Information from Etherscan.io:

Information from Coinlib.io:

TA

ChainLink form a bullish pennant pattern which is most commonly breaks to the upside.

Competitors

Microsoft Coco

Confidential Consortium Blockchain Framework, an open-source system that enables high-scale, confidential blockchain networks that meet all key enterprise requirements — providing a means to accelerate production enterprise adoption of blockchain technology.

Microsoft achieves this by designing specifically for confidential consortiums, where nodes and actors are explicitly declared and controlled. Based on these requirements, the framework presents an alternative approach to ledger construction, giving enterprises the scalability, distributed governance and enhanced confidentiality they need without sacrificing the inherent security and immutability they expect.

Leveraging the power of existing blockchain protocols, trusted execution environments (TEEs) such as Intel SGX and Windows Virtual Secure Mode (VSM), distributed systems and cryptography, the Confidential Consortium Blockchain Framework enables enterprise-ready blockchain networks that deliver:

  • Throughput and latency approaching database speeds.
  • Richer, more flexible, business-specific confidentiality models.
  • Network policy management through distributed governance.
  • Support for non-deterministic transactions.

By providing these capabilities, the framework offers a trusted foundation with which existing blockchain protocols can be integrated to deliver complete, enterprise-ready ledger solutions, opening up broad, high scale scenarios across industries, and furthering blockchain’s ability to digital transform business.

Oraclize (Rebranded into Provable)

Oraclize is the leading oracle service for smart contracts and blockchain applications, serving thousands of requests every day on platforms like Ethereum, Rootstock, R3 Corda, Hyperledger Fabric and EOS.

The solution developed by Oraclize is to demonstrate that the data fetched from the original data-source is genuine and untampered. This is accomplished by accompanying the returned data together with a document called authenticity proof. The authenticity proofs can build upon different technologies such as auditable virtual machines and Trusted Execution Environments.

This solution elegantly solves the Oracle Problem:

  • Blockchain Application’s developers and the users of such applications don’t have to trust Oraclize; the security model is maintained.
  • Data providers don’t have to modify their services in order to be compatible with blockchain protocols. Smart contracts can directly access data from Web sites or APIs.
  • Oraclize engine can be easily integrated with both private and public instances of different blockchain protocols.

Hivemind

Hivemind is a Peer-to-Peer Oracle Protocol which absorbs accurate data into a blockchain so that Bitcoin-users can speculate in Prediction Markets. These markets have the potential to revolutionize the emergence and diffusion of knowledge in society.

An “oracle corporation” model attempts to guarantee that a group of self-selected, anonymous, greedy users will always resolve contract-outcomes honestly. Outcomes are established by weighted-vote, according to users’ ownership of a second type of “VoteCoin”, of which there are a constant amount (granting Sybil-immunity). Ownership of the VoteCoins is redistributed according to a Schelling Coordination Game, which destabilizes malicious cartels only. Large individual malicious-votes are discouraged through collapse in the market value of Votecoins and threat of (rare, Sybil-resistant) Miner Vetoes and Overrides. Like equities, VoteCoins are tradable and pay dividends over time, removing the incentive for an “exit scam”.

Aeternity

In very simple terms, æternity is a new blockchain platform, but it is also a vision for the future. This vision is being realized by a global community of believers, convinced in the disruptive potential of scalable, public blockchain technology. It is a movement that aims to propose decentralized, trustless alternatives to the existing governance, economic and financial intermediaries.

From a technological point of view, æternity is a public, open-source, blockchain-based distributed computing and digital-asset platform that builds upon decentralized cryptographic P2P technology. The platform is open to anyone, anywhere in the world to use.

A crucial feature for most contracts, whether encoded as text or as code, is the ability to refer to values from the environment. The æternity Oracle Machine provides real-world data to the blockchain. Each user can ask questions about the environment and the oracle provides the answer. The consensus mechanism comes into play in case of disagreement.

Mobius

Mobius integrates the old internet with the new decentralized internet of value. Just as Stripe integrates payment processing into apps, Mobius (MOBI) integrates the blockchain ecosystem into apps. The simple public APIs abstract away the underlying complexity of blockchain integration and development; so any developer can build modular constructs on the blockchain without specific domain expertise. As a result, Mobius makes it easy to connect any application, device, or data stream to the blockchain ecosystem. The live DApp Store allows every developer to securely distribute and scale cross-blockchain applications for mass adoption. The MVP use-case is the live DApp Store that makes it trivial for developers to accept in-app cryptocurrency payments. The Mobius protocol encompasses standards for interoperable blockchain login, payment, smart contracts, governance, and oracles.

Witnet

Witnet is a decentralized oracle network (DON) that connects smart contracts to the

outer world. Generally speaking, it allows any piece of software to retrieve the contents published at any web address at a certain point in time, with complete and verifiable proof of its integrity and without blindly trusting any third party.

Witnet runs on a blockchain with a native protocol token (called Wit), which miners called witnesses earn by retrieving, attesting and delivering web contents for clients. On the other hand, clients spend Wit to pay witnesses for their Retrieve-Attest-Deliver (RAD) work. Witnesses also compete to mine blocks with considerable rewards, but Witnet mining power is proportional to their previous performance in terms of honesty and trustworthiness — this is, their reputation as witnesses. This creates a powerful incentive for witnesses to do their work honestly, protect their reputation and not to deceive the network.

Roadmap

Nonexistent.

Token Mechanics

The ChainLink network utilizes the LINK token to pay ChainLink Node operators for the retrieval of data from off-chain data feeds, formatting of data into blockchain readable formats, off-chain computation, and uptime guarantees they provide as operators. In order for a smart contract on networks like Ethereum to use a ChainLink node, they will need to pay their chosen ChainLink Node Operator using LINK tokens, with prices being set by the node operator based on demand for the off-chain resource their ChainLink provides, and the supply of other similar resources. The LINK token is an ERC20 token, with the additional ERC223 “transfer and call” functionality of transfer(address,uint256,bytes), allowing tokens to be received and processed by contracts within a single transaction.

Source

When a user creates a smart contract, they’ll be able to put a price (in LINK) on how much they’re willing to pay for the data retrieval. Nodes will bid on those smart contracts by paying the penalty fee (in LINK) if the smart contract creator has decided to set an amount for the penalty fee. Nodes not selected will be able to withdraw their LINK that they spent on bidding. Nodes that were selected will be able to withdraw their penalty fee and rewards for data retrieval after they have submitted data which was accepted by the smart contract.

As the node returns acceptable data to the smart contract, it will be paid (in LINK) for both partial and whole (whichever is relevant) completion. For example, if an assignment is to retrieve a data point from a data provider once, then upon completion, the node would be paid for 100% of the assignment. Another example, if an assignment is to retrieve a data point from a provider every day for 30 days, then each time the node returns acceptable data to the smart contract, it will be paid as a percentage of the total assignment.

Payment for assignment completion and penalty withdrawals accumulate over time, instead of automatically being released back to the node’s Ethereum address. The node operator will need to pay the gas fee in order to withdraw the accumulated LINK.

Source

Token Metrics

ICO Token Price: 1 LINK = 0.11 USD (0.00038462 ETH)

Source

Summary

Team: Team with early involvement in crypto, and good prior experience
Idea: Crucial for the market, working and easily implemented oracles will be a great adoption driver for cryptomarket
Whitepaper: Whitepaper is good in technical part, but lacks important information like token metrics and token mechanics, some additional info can be found on Github though
Roadmap: Nonexistent

This project has been around for quite some time, but it was mostly under radar until 2017, when it got a moment to shine when a lot of hype was generated in 4chan. ChainLink is well known for its weak involvement with community, though in the last few months this trend is changing — tweets are more frequent and a lot of partnerships are announced and confirmed.

ChainLink is quite ambitious, it tries to create blockchain agnostic middle layer which will make smart contracts reach higher places with its oracles. Working decentralized oracles are a gamechanger on this market, with right partnerships it is hard to imagine just how big ChainLink’s capitalization will be. ChainLink already has some working oracles, and even show-cased some for SWIFT, securing a place on Sibos. This created a lot of speculations and does so even now, especially since it is stated on ChainLink’s website that “We work with Banking Technology Leaders like SWIFT, helping connect banks to smart contracts with Enterprise Grade Oracles”. Unfortunately no additional nor further info or confirmation is given so this remains as a highly speculated topic. Not too long ago there were some speculations about NASDAQ partnering with ChainLink, well, it was because of Brave New Coin (BNC), BNC is working with Chainlink as their data provider. Nasdaq is working with BNC to release Bitcoin Liquid Index (BLX) and the Ethereum Liquid Index (ELX) indexes so people are assuming ChainLink will be used in order to get that price data.

ChainLink got a lot of partners which plan to use its oracles and that is very good for this project, since for some time it had literally 0 marketing and this will at least increase awareness about this project as well as build stronger ecosystem.

ChainLink has a number of competitors from both traditional and crypto companies, most of the crypto-competitors are quite new, or only partly overlap with ChainLink (like Aeternity, which is more of a EOS-ETH competitor) while competitors like Microsoft COCO or Provable (which became ChainLink’s partner recently) have a drawback of being a centralized oracle service.

On the downside ChainLink is lacking economical papers with incentives for node operators, it would be nice to see use of proceeds, as well as distribution of 35% of the tokens which were reserved for incentivizing the ecosystem and well, despite the fact that high activity can be seen on Github and Pivot, it would still be nice to see a roadmap. All these point are associated with ChainLink’s weak interaction with community, but since testnet is active for quite a long time and mainnet is somewhere soon to be launched, it would be nice to see more transparent company.

To sum it up, ChainLink is a promising project with some working features (on testnet), a number of strong partnerships and a lot of speculations.

This is not financial advice.

Subscribe to detailed companies’ updates by Paradigm!

Medium. Twitter. Telegram. Reddit.

Blockchain
Chainlink
Cryptocurrency
Crypto

--

--

Paradigm
Paradigm

Published in Paradigm

2.5K Followers
Last published 13 hours ago

Paradigm is an ecosystem that incorporates a venture fund, a research agency and an accelerator focused on crypto, DLT, neuroscience, space technologies, robotics, and biometrics — technologies that combined together will alter how we perceive reality.

Paradigm
Paradigm

Written by Paradigm

3.7K Followers
1 Following

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams