# Welcome Building a Cross-chain Platform Powering the Data Economy on Polkadot ![](/files/-MK94l88f8OzW71mmZhW) KYL Official ERC-20 Contract is [0x67B6D479c7bB412C54e03dCA8E1Bc6740ce6b99C](https://etherscan.io/address/0x67B6D479c7bB412C54e03dCA8E1Bc6740ce6b99C) # Project Overview The Data Infrastructure for DeFi and Web 3.0 Powered by Polkadot ## Introduction **Kylin Network aims to be a Modular & Configurable DeData Infrastructure & Economy to feed Complete, Accurate & Validated Data to DeFi & all things Web3.0 on Time & Reliably.** Oracles have mainly been developed for Ethereum, price feeds, and Defi. Costs of running these architectures use gas and incur costs that are not practical, limiting the scope of what oracles can achieve. There is no legally binding agreement between consumers and providers of data. Consumers have to compromise between security, reliability, authenticity, and data delivery speed. There are barely any standards with regard to oracle safety and interoperability because the market has been monopolized with one vision from one selfish player. There is no transparency and traceability of data provenance. Users cannot choose the provenance of their data and how it is treated. There is no democratization of the data management process, and conflict resolution is tainted with poor voting technology. Incentives are not convincing people to participate. An oracle system cannot function without a strong DAO and conflict resolution mechanism. This is why Kylin is pushing toward the democratization of the data management process with robust dispute resolution mechanisms and a voting system, which allows for assessing and strengthening the validity of a vote. There is no way to solve the oracle problem but giving a configurable framework for democratically creating and managing oracle system entities allows the consumer to evaluate and mitigate the risks while acting in full knowledge of the situation. A service level agreement (SLA) between the providers and consumers of data on the transparency and traceability of data provenance, specifying where the data came from, can offload some of the responsibility from the non-perfect performance of the oracle systems to the consumer. Never reaching perfection but striving for the best way to agglomerate data, Kylin suggests a transparent multi-level oracle data agglomeration system allowing for a better balance of security, authenticity, persistency, and speed, also providing alternative fallbacks to help make the oracle data more reliable and resilient. To put this system in motion, Kylin is proposing data feed ownership management with NFT and metadata as part of a strong and vibrant free Data market where the forces of capitalism can intertwine with ideals of a better life for everyone at a realistic operational cost. Just like robots are replacing our workforce, old ways of governing and doing business, which allow human nature to skew evolution, are going to fade out in favor of machine-based systems which decentralize human activity where it is needed. From controlling the narrative to manipulating markets, these ”medieval institutions” are going to suffer the same fate as any organic system and be decentralized if need be by the driving force of evolution. Kylin is latching on to that force by bringing decentralized data to the masses. ![](/files/-MK3caIcpGtjvo6GW2hs) ## Team Interest The Kylin team comprises talents from different fields of the digital world, ranging from data science, project operation, and full-stack development to cryptocurrency, early adopters, and evangelists. This team believes it is a group of strong exponents of reforming the status quo and making substantial contributions that can propel us into the next stage of data feeding, data exchange, and data analytics. Although oracles and web3 middlewares altogether have become an area of high interest in the blockchain world, and many projects have been working on the issue, our team finds that from a practical perspective, and through a number of people in our network that have explored integrating them or others, they find the price feed queries too expensive. Indeed, quite a few projects we are aware of just decided to use centralized data feeds, and this applies generally to on-chain feeding of data, especially to the growing number of web3 middlewares scaling the potentials of the technology. Although there’s a growing demand for web3 middlewares to level the transaction costs, quicken transactions speed, avert on-chain congestion etcetera, there is ample room for a data framework to meet the needs of this web3 middleware. Kylin seeks to create a modular and configurable data framework such that the democratization of the data management is possible via a multi-level oracle data agglomeration for balance, security, authenticity, persistence & speed. Additionally, we believe that via Polkadot we can ensure a cost-effective solution that data consumers and Dapp Builders will actually use over centralized sources. # Background Why We Need Better Data Infrastructure? ## About DeFi Finance is always one of the most practical application scenarios, and there is no exception in the blockchain industry. DeFi (Decentralized Finance) is a representative of blockchain finance. It refers to transactions that cut off the middlemen involved in the legacy finance systems, including decentralized exchanging, insurance, lending, etcetera. For example, in decentralized lending, cryptocurrency users can mortgage their digital currency to the DeFi platform by providing liquidity to obtain interest, known as liquidity rewards, and they can also borrow from the DeFi platform, which is one of the few bright spots on-chain in recent years. ![](/files/-MGCsKfVr1dGcmLdoVpi) Yet, at the bottom of every DeFi protocol, there is a dependence on Web3 middlewares, especially Oracles, because of no oracles, no DeFi. The truth of that claim is seen when Finance is considered to be price-based transactions. We need correct prices for every trade, every position we create and liquidate, as well as collateralization. A smart contract is not smart unless it’s reliably connected to accurate data which exists off-chain. Web3 data frameworks, including oracles which are hybrid contracts that connect on-chain contracts with off-chain data querying components, become the next most critical infrastructure piece before DeFi and other next-generation dApps can grow from an experiment to compete and eat the legacy alternatives. ## About Web3.0 Although the definition of web 3.0 varies from person to person, it all begins with a movement away from the centralization of services like search engines, social media, and chat applications that are dependent on a single organization to function, which can be easily abused, as countless cases demonstrate. The internet today has been transformed into a top-down system or surveillance capitalism dominated by a few big players whose power is derived from their control over your data. The web 3.0 initiatives advocate the possibility of data being returned to the control of the people who generate it. It is considered a move that is going to reverse the current information and social dilemmas we are faced with and create a more frictionless and humane virtual economy. ![](/files/-MK4CxkM1VOYMM2HqUHI) [Polkadot](https://polkadot.network/) is an open-source project led by the[ Web3 Foundation](https://web3.foundation/). It is a sharded protocol that connects different blockchain networks. ### **Polkadot** Polkadot consists of two parts: Relaychain and Parachain. * **Relaychain:** This is Polkadot's core, which is responsible for network security, consensus, and cross-chain interoperability. * **Parachain:** These are sovereign blockchains with custom tokens and optimized functionality for specific use cases. Parachain connection to Relaychain is priced on a pay-as-you-go basis or a continuous connectivity lease. ### **Substrate** [Substrate](https://www.substrate.io/) comes with everything you need to build your blockchain. Use Substrate’s pallets to create what you want easily, or craft your own custom logic. Substrate makes building a blockchain far faster, easier, and safer than ever before. ### **Web3 Middlewares** Middlewares, fondly described as “software glue,” are computer softwares that renders supporting services to the main applications beyond those its operating system can provide. Following the general definition given by Red Hat, an open-source software provider, *Middleware is software that provides common services and capabilities to applications outside of what’s offered by the operating system. Data management, application services, messaging, authentication, and API management are all commonly handled by middleware. Middleware helps developers build applications more efficiently. It acts like the connective tissue between applications, data, and users.* Web3’s dependency on middleware weighs heavier as it’s adopted into new spheres and penetrates mainstream adoption. Beyond the peer-to-peer payments system initially intended, the distributed ledger technology and its theme has been applied to solve a myriad of other problems, from data management and social interactions to gaming and governance. All of these have raised the need for it to depend on “tools” or infrastructures that will extend the capabilities of the technology. Distributed peer-to-peer storage networks have sprung up to handle the challenges of storage, state channels, roll-ups & L2 chains to raise scalability, oracles the off-chain data communication issues, and much more. ## About Oracle Oracle is the system that provides an out-of-chain data source for in-chain smart contracts. The word oracle comes from Greek mythology, representing the people who can communicate with gods and see the future vision. In the context of blockchain, the oracle is the system that can answer the external problems of blockchain and the bridge connecting in-chain and out-of-chain data. In ideal conditions, oracle is a free-of-trust system, which means that they do not need to be trusted as they operate according to the principle of decentralization. There has been a wave of projects trying to solve this problem. Most of them get price feeds from external data sources such as centralized exchanges through trusted nodes. Then data is uploaded to the blockchain to be used by different DeFi protocols. There is one fundamental issue with this solution is that price data has not been effectively verified. While some other DeFi protocols get their price feeds from decentralized exchanges. The problem here is that these prices can be easily manipulated due to low transaction volumes. Blockchain-empowered smart contracts are isolated from the internet world and cannot access external data directly. Computation within the smart contract is also excessively expensive and limited by resource capacity. The ideal oracle that works for DeFi should include the following characteristics: * **Accuracy:** The prices can accurately reflect market prices. * **Timeliness:** The prices can react quickly to the changes in market prices. * **Cost of Attack:** The Cost of manipulating the prices is extremely high. * **Decentralization:** The price is generated and verified in a decentralized and permissionless system. Oracle should deliver data to the most: * **Accuracy:** Data should be more precise and less approximate. * **Validity:** Data should correspond to the real world * **Reliability:** Data should always be available * **Timeliness:** Data should not be out of date * **Relevance:** Data should be pertinent and useful * **Completeness:** Data should be whole and useful | **Project** | **Description** | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Chainlink](https://chain.link/) | Chainlink is a decentralized network that provides information (oracles) to smart contracts, aims to solve the problem of off-chain information sourcing by smart contracts for their execution parameters. | | [Band Protocol](https://bandprotocol.com/) | Band Protocol offers a decentralized data oracle by making data readily available to be queried on-chain, using a delegated proof of stake ("dPoS") to ensure data integrity. | | [Nest Protocol](https://nestprotocol.org/#) | NEST oracles solve the problem of the on-chain price through decentralized incentive schemes, that is, price oracles. | | [Tellor](https://www.tellor.io/) | Tellor is a decentralized oracle on Ethereum enabling censorship-resistant access to off-chain data. | | [DOS Network](https://dos.network/) | DOS Network is a decentralized oracle service supporting multiple heterogeneous blockchains. | ## About Data Infrastructure Data Economy is a trillion-dollar business. Nevertheless, Oracle is just one part of the data infrastructure in the blockchain industry. Data is essential for the modern age. It is the infrastructure that underlies the whole economy. It underpins public service transformation, business innovation, and democratic engagement. It connects multiple sectors necessary for a functional society. Data infrastructure includes technology, processes, and organizations. Data infrastructures like our road infrastructures help you get from A to B – data and its complete infrastructure should help you get to a decision. Unfortunately, blockchain technology, classic chains, in particular, was not conceived with the need for data in mind. It was designed and developed to be an isolated deterministic environment for secure transactions until the realization of more possibilities and use cases made it necessary. As such, it is seriously lacking data infrastructures because the industry is still in its embryonic stage, the need for data wasn’t considered at conception; making the web3 data sector even younger than the technology, and there is yet to be a standardized and adoptable protocol for data needs for all sectors thus creating some insuperable hurdles. | Project | **Description** | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [The Graph](https://thegraph.com/) | The Graph is an indexing protocol for querying networks like Ethereum and IPFS. Anyone can build and publish open APIs, called subgraphs, making data easily accessible. | | [Covalent](https://www.covalenthq.com/) | Covalent provides a unified API to bring full transparency and visibility to assets across all blockchain networks. | | [Ocean Protocol](https://oceanprotocol.com/) | Ocean Protocol helps developers build marketplaces and other apps to privately & securely publish, exchange, and consume data. | | [Dune Analytics](https://duneanalytics.com/) | Dune Analytics allows users to instantly create and share analysis of Ethereum data. | | [Infura](https://infura.io/) | Infura's development suite provides instant, scalable API access to the Ethereum and IPFS networks. | | [Subscan](https://www.subscan.io/) | Subscan is a blockchain explorer built for Substrate based networks. | # Existing Problems The Web3 Data Chasm Blockchains are designed to maintain truth inside of its often deterministic walled garden. This is where its security strength lies, in its isolation. However, the applications of this technology extend beyond tokens, price feeds, and decentralized finance, aka DeFi. The myriad of possibilities for the web3 technology is suffocated because data, which is like oxygen to computer network systems, are fenced out. Some of these problems due to the nature of blockchain technology include; **Inaccessible / Expensive Off-chain Data Querying Services & Analytics** \ Technical overhead and network costs are heavy limiting factors for the oracles which have been built on Ethereum. They limit the use cases of oracles because the running cost far outweighs all of its benefits, shortening its scope. This explains why most Oracles applications fall to DeFi and exchange price feeds. Other types of data feeds are strangled even before they find good use and are rendered inaccessible for potentially transforming use cases just because the cost may not be worth it. **Chain-Specific & Unscalable Data Feeds** \ When the cost hurdle is scaled, it would be of great economic benefit if one validated Data feed could be streamed across chains, i.e, in terms of being a chain-agnostic feed. However, present data feeds are mostly single-chain compatible, given the nature of the blockchain on which the solution was built, which also affects its performance in handling queries. **Centralized Data Feeding Oracles** \ This is the central topic of the oracle problem. The aim of distributed systems is entirely defeated if they eventually rely on centralized sources for their data. However, this is the case today. “Decentralized” networks of oracles are usually controlled by a central authority capable of influencing the decisions of the network of oracles and the data feed, or they are somewhat dependent on one another. It’s not unheard of to see DeFi protocols fetching price feeds from centralized exchanges which are, unknown to them, dependent on one another via API’s. **Non-synergistic Middleware Data Framework** \ Web3 technology development presents a lot of opportunities. As such, several companies are racing to deploy solutions to solve one problem or the other, sadly without coordination and standards. Hence, these solutions that solve different pieces of the puzzle do not come with fitting edges to frictionlessly integrate or synergize with solutions before the subsequent ones. They usually do not take the form of money legos as DeFi is now commonly referred to because of their compatibility. This slows down the collective development of this web iteration towards the majority adoption point. **Dev-Unfriendly Data Validation Layer** \ Not only does the present solution suffer compatibility issues, but working with them to build dApps is not as easy. Web3 middleware implementation already has some level of difficulty, and not many builders can work with integrating them into their project even when necessary. The required level of abstraction to level the playing field for developers to jump in, implement and build amazing real-world solutions. # Technical Architecture Kylin’s vision is to solve the Web3 Data Gap is a configurable data framework that allows for * Democratically creating and managing oracle system entities * Service level agreement (SLA) between the providers and consumers of data * Multi-level oracle data agglomeration allowing to balance security, authenticity, persistency, and speed * Democratization of the data management process * Transparency and traceability of data provenance * Free data market * A voting system allows for assessing and strengthening the validity of a vote. ## Solutions To actualize the envisioned future of bridging the Web3 chasm, the Kylin network is building a number of components that make up the DeData infrastructure. This includes * The Kylin Oracle Pallet & API * Dynamically & Statically Sized Oracles * Democracy Pallet * An Enhanced Voting System * Dynamic NFTs & DeData Marketplace.\
* **The Kylin Oracle Pallet & API** The Kylin Oracle nodes are collators to the PCHU parachain, which is validated by the relay chain to the Polkadot network. Our API allows us to save to a Postgres database the results of calls to built-in or custom endpoints. The aim of Kylin Network is to **create a configurable Oracle** to give users a sense of assurance and responsibility to the consumer about selected choices. The creators of a data feed of the oracle can specify what their oracles are and which algorithms they are using so the consumers of this feed can freely choose if they want to consume the data with the full knowledge of their choice. Systemizing knowledge and dividing oracles into modules can enhance security and manage user expectancies. ![](https://lh5.googleusercontent.com/IAkHlLW55vlotJ8r1De0ORUxYUrepvv0cPaA3wPRFda1FEsFa-4P0HGKhINi7PpK3i8uEDny9mr1Jt-xki3zdtjvsdisSx9AX7m7xbxCRaY13JDyrqzxGGxhqFmPLXTkWLIIafXa_z7eVgJaNoxl8MI) **Oracle System Manifest** Given that the Kylin Network will be a Multi-level Oracle Data agglomeration, a procedure is required to keep track of ownership, source of data, and other pertinent information. Keeping track of who owns the data, where the data comes from, when it was collected, and which algorithm was used to treat it can be recorded in this manifest that can be published with each block. This implies that the data sources are known before the feed is published in the primary oracle. **Service level agreement (SLA)** \ \ This contract is necessary to ensure that a data consumer gets what was ordered. A service-level agreement (SLA) is a contract between a service provider and its customers that documents what services the provider will furnish and defines the service standards the provider is obligated to meet. More specifically, in the context of the Kylin configurable oracle system, it is an agreement that the user accepts the configuration the provider selected when creating the data feed. This agreement can be renewed with each block and can take the form of a Ricardian contract or JSON object. The user can opt-out of this contract by subscribing to a different feed. A Ricardian contract is a digital contract that functions as a legally binding agreement between two parties based on agreed-upon terms and conditions. The contract is cryptographically signed and verified using the blockchain but is readable by both people and machines. **Adherence to standards** Although this effort is in the early stages, efforts from a community of oracle builders have been made to promote best practices, collaboration, and interoperability by putting forward standards through EIP-2362. Best practices will be found here: And will consist of: * Failure cases * API/Data specs * Dispute considerations * Admin Control * Aggregator architecture * Repository of know oracle hacks * Liveness * Usage * Audits **Aggregation and validation of oracle results** * **Input Data types** \ As mentioned in section 3.1, the system should provide for data types other than numerical. The basic needs for running the iteration of this paper are: \- Numerical The input/output type specified in EIP-2362 is int256 \ • Small string Initially 256 Bytes \ • Light bytecode Initially 256 Bytes \ \ Data is kept small in size for the chain buffer for storage and computation considerations. Limitations may be disregarded for the buffers residing on the OCW. The data must conform to the format specified in the SLA. * **Output Data types** \ EIP-2362 contains specifications for returning numerical values as: \ 1 returns ( int256 value , uint256 timestamp , uint256 statusCode ); Since the substrate is coded in rust, this function will now be in the case of a string: \ 1 fn returns ( value : String , timestamp : u32 , statusCode : u32 ){} In the case of an integer value: 1 fn returns ( value : u32 , timestamp : u32 , statusCode : u32 ){} In the case of bytecode: \ 1 use bytes ::{ BytesMut , BufMut }; \ 2 fn returns ( value : bytes , timestamp : u32 , statusCode : u32 ){}
# Benefits of Kylin's Configurable Oracle **Type of Data** The first use of blockchain oracles was for price feeds. As third-generation blockchains emerged, the need for a source of truth other than numerical is manifesting, and consumers would want to subscribe to a variety of feed Types. **Selection of various trusted APIs** \ \ In the case of a price feed, for example, using a single spot price is highly unreliable because it represents the price at which buyers and sellers are willing to accept on the spot on a certain exchange. The system using this feed will be dysfunctional if the API goes down or is a victim of manipulation. It is discouraged to use this value alone, and a proper selection of several reliable APIs will ensure an accurate and persistent feed. The creators should be able to select from a list of approved APIs, passing down this trust to consumers who can choose to use the data because they know where it came from and how it was aggregated or treated with each SLA they are signing with each feed. **Trusted algorithms** \ \ Much investigation still needs to be done most efficiently to obtain the most representative value from running queues or static buffers. The ability to choose this will allow users to research and either select the most efficient configuration according to their needs (speed vs. security vs. authenticity) or choose a default setting with conscious knowledge of the advantages or consequences of using that feed. **Private chains** \ \ If data remains within the enterprise context, the company should be able to create custom feeds containing private datasets, it wants to work with for its consumers or applications. **Push oracles** \ \ In the case where data needs to be obtained from democratically varied sources, the contribution of any community member wanting to contribute to a feed by pushing data onto the chain for a reward could bring a dimension of variety appealing to the creator of a feed. \
# Multiple Oracles - Dynamically & Statically Sized Oracles We will be using three buffers: two dynamically sized buffers focused on speed for the push-based reporters and OCW and one global stricter static buffer for the on-chain oracle focused on security. The oracle on the OCWs will be collecting data from various APIs. The oracle on the push-based reporter buffer will accept transactions through an extrinsic. Their results can then be aggregated in the main Kylin runtime Oracle. Since the results of the OCW are intended for the next block, this could mean a sample rate of 12 seconds. On the other hand, if the user wishes, he can use the OCW buffer every 6 seconds while being aware he/she is sacrificing security for speed. The faster aggregation allows for the publication of a manifest specifying data provenance before the publication of the data. *Note: A similar concept of multiple oracles has been used as a fallback mechanism by Liquity -* [*https://www.liquity.org/*](https://www.liquity.org/) **Kylin Runtime Oracle** \ \ This oracle is centered on security and democratization. Reporters feeding this oracle will be oracles themselves: An OCW pull-based pool of API reporters and a push-based pool from the community at large. Mirroring attacks are when the data feeders are willing to freeload another data feeder’s response to minimize their cost of data provision. The first step in addressing these attacks is to identify the reporter in the SLA, which the querier signs. Furthermore, mechanisms should be put in place that ensures the confidentiality of the data sent by the data feeders. A commitment scheme achieves this confidentiality. Each data feeder should send a commitment of the plain data as an encrypted message to the receiver(Kylin Oracle Runtime Buffer). Later, the sender can reveal the original plain data and verify its authenticity using the commitment scheme. **Kylin OCW Pull Oracle** \ \ The off-chain workers are part of the Kylin collator without being part of the runtime. They have direct access to storage and can be leveraged to prevent some of the common attacks. They are also, by their nature, able to run intensive and demanding computations without affecting the runtime. Their work will be verified by ZK proof, and their result can either be used right away(speed) or sent to the Kylin runtime Oracle buffer for subsequent treatment(security) as the consumer chooses in the SLA. **Kylin Push reporters Oracle**. \ \ Push reporters are contributors calling an extrinsic to submit a value to the chain. Their values are selected at random to populate the pool, from which a final value will be calculated before it is sent to the Kylin runtime oracle buffer. There is a cost to calling this extrinsic, but the reward absorbs this cost once the reporter’s value enters the buffer and is used to calculate the final result. **FIFO / circular buffer sampling for numeric type** Aggregation buffers in the form of a FIFO queue are the traditional data structure used to evaluate data coming from multiple sources. Calculations of one buffer sample per block can give different results according to the algorithm used. In any case, the user should be able to configure which algorithms he/she wants to use, and this algorithm should be specified in the config/SLA. The type of algorithm used is the data structure parameters and rules applied to the reporters. Factors that will govern our research for the aggregation buffers:
* Various inputs: push, and OCW pull reporter values * Variable queue size * Random sample rate * Weighted/Moving average * Mean * Median * Median filters(Neighboring pixel value) * Quantization * Time-weighted median price * Median Absolute Deviation * Accepted same value over 2/3 of the buffer * Ban period If the value of OCW or push reporter is over or below the value of an accepted spread. * No two OCW or pull-based reporters should be allowed to submit twice in the same sample period. Select storage. * Binary/Quicksort for median * Aggregation Errors management * Time-weighted average price **API Pooling for inbound pull of data feed** \ It is highly recommended to aggregate the results given by multiple APIs in order to get the most accurate data. When a smart contract requests an off-chain state/data, the pull-based inbound oracle receives the request from the caller contract, and gathers the state from off-chain components, Furthermore, it sends the state back to the caller using a transaction. This process is transparent as it is implemented using smart contracts that communicate via delegated calls. A pull-based inbound oracle’s performance is constrained by the transaction rate of the blockchain network and the time needed to collect external data once the request is made to the oracle. Response time depends on the network speeds, which can cause a bottleneck. This will be mediated by immediate access to the runtime of the OCW. **Extrinsic Pooling for inbound push of data feed** \ A push-based inbound oracle uses off-chain components to monitor external state/data changes and proactively inject any updates into the blockchain, enhancing the performance as the calling entity does not need to wait for the oracle to collect data. In traditional systems, if the use case needs to resolve temporal conflicts, the history oracle pattern could complement push-based inbound oracle to provide historical values of off-chain data. In these patterns, how the data came into existence is invisible and cannot be mediated, but because a manifest generated by the system can be provided to the user and the rules of a strict and discriminatory buffer queue, the effects of data manipulation will be lessened. In the case of inbound push-based reporters, participants could need to stake the transaction fee amounts several times before gaining rewards obtained in fees from the buffer snapshot within that time frame, protecting the system against DDOS attacks and preventing collusion because the manipulation cost is higher than the rewards obtained. **Zero Knowledge proofs** \ The calculations on the OCW occur off-chain and will need to be verified. This is a perfect use case for zero-knowledge proofs. ZKP is the method by which one party (the prover) can prove to another party (the verifier) that a given statement is valid while the prover avoids conveying any additional information apart from the fact that the statement is indeed true. **Filtering arbitration and triggering** \ Data should be vetted before it reaches the blockchain for irrelevant/illegal data. A keeper or arbitrator can initially filter the data for integrity and pertinence while watching the state trigger appropriate actions on Sybil blockchains. This entity can act as an automated custodian allowing for the outsourcing of regular maintenance tasks in a trust minimized and decentralized manner. # Democracy Pallet The sudo or root command is necessary to create feeds at the time of this writing. The underlying truth is that it is not possible to separate DAO governance and oracles. This procedure is revised to allow for community support of this procedure and others that should undergo the process of community approval. Following the procedure, the community will endorse a proposal for the creation of a feed and eventually vote on the pertinence of this feed. The outcome of this vote should confirm that all tests, criteria, and concerns have been addressed and approved for interaction with the system. **Interface** * Propose: Submits a sensitive action, represented as a hash. Requires a deposit. * Second: Signals agreement with a proposal, moves it higher on the proposal queue, and requires a matching deposit to the original. * Vote: Votes in a referendum, either the vote is ”Aye” to enact the proposal or ”Nay” to keep the status quo. * Unvote: Cancel a previous vote, this must be done by the voter before the vote ends. * Delegate: Delegates the voting power (tokens \* conviction) to another account. * Undelegate: Stops the delegation of voting power to another account. **Democracy Pallet Use Cases** * **Submit data feed** \ *(a) Submit as a proposal* \ *(b) Obtain community endorsements* \ *After the proposal period ends, a data feed (Dynamic NFT) is created and is put up for sale on a decentralized data market. Possibility of this step financing the vote. i.e., Anyone satisfying the criteria for the vote could get paid to vote. See democracy pallet enhancements.* \ *(c) Select APIs* \ *(d) Select OCW aggregation buffer algorithm* \ *(e) Select reporters aggregation buffer algorithm* \ *(f) Select Kylin Oracle runtime aggregation buffer algorithm* \ *(g) Create Service level agreement. Include APIs and algorithms, test runs, and data schema validation as part of this step* \ *(h) Community vote on data feed creation Publication of config upon successful vote. Users can select config for their feed according to their preferences.* \ *(i) User/dapps request to query feed* \ *(j) Users sign SLA agreeing to configuration, terms, and conditions* \ *(k) Possibility to delete data Feed* \ *Service level agreement resiliation* * **Register API** \ *(a) Submitted as a proposal* \ *(b) Obtain community endorsements* \ *(c) Create Service level agreement* \ *(d) Vote on API provider Vote is based on reputation or any other pertinent info.* \ *(e) Users sign SLA agreeing to configuration, terms, and conditions* * **Register Reporter** \ *(a) Submitted as a proposal* \ *(b) Obtain community endorsements* \ *(c) Create Service level agreement* \ *(d) Vote on reporter Vote is based on reputation or any other pertinent info.* \ *(e) Users sign SLA agreeing to configuration, terms, and conditions* * **Register keeper/arbitrator** \ (a) Submitted as a proposal (b) Obtain community endorsements (c) Create Service level agreement (d) Vote on keeper/arbitrator Vote is based on reputation or any other pertinent info. (e) Users sign SLA agreeing to configuration, terms, and conditions (f) Permissions i. Blacklisting reporters ii. Emergency stop of feed # An Enhanced Voting System **Augmented Democracy** \ \ Human oracles and dispute resolution Individuals with specialized knowledge/ skills in a particular field can also serve as oracles. They can research and verify the authenticity of the information from various sources and translate that information to blockchain rules. Since human oracles can verify their identity using cryptography, the possibility of a fraudster faking and providing corrupted data is relatively very low. Voting-based strategies raise issues for incentivized platforms. There is a term called ”lazy equilibrium,” a form of verifier’s dilemma where voters always return the same answer to questions to secure profits without performing works for correctness. This is one scenario that could be addressed by a mechanism that ensures the body of voters agrees on a set of facts before the vote, thus certifying that the problem does not reside in the vote but in the questionable will of some of the voters. The community could then propose to redo the vote or cast out bad actors. This concept is suggested as an enhancement to the voting process, not a solution. When combined with other methods, a cleaner vote could eventually be distilled. In the same way, that renewable clean energy has to be gathered from different sources. **Augmented Voting** \ \ Augmented voting is a vote where the participants are required to take a test to enable their right to vote on a particular question/issue/dispute. This concept seeks to abstract the diverging beliefs in a group of voters in favor of outlining their overlapping credence. * Diminishes the amount of diverging knowledge * Educates voters * Promotes votes for the truth and common good * Helps determine if the outcome of a vote is emotional or irrational * Solidifies the value of the outcome of a vote * Promotes unity ![](/files/56dssKWBpBCif2maSGW9) How do we ensure the tests are accurate and based on facts? The solution lies in a modified application of token-curated registries. The Kilt Protocol (Polkadot-network) has built a successful approach that bonifies this method and brings it closer to our use case, token curated attesters. For this to work, the questions and information gathered have to abide by the following criteria: * There is an objective answer to the particular question. * The answer is publicly observable. * The answer is very cheap to observe. From the kilt protocol white paper: The expert must be careful in her decisions since doing bad job results in being dismissed (expelled from the list by the curators), damaging her reputation, and finally losing her income. Therefore, this system disincentivizes bribes or bad decisions. In the same frame of mind, we want to adopt this method to validate the pertinence and authenticity of the questions for the test that will enable community members to vote. # Token Curated Tests Grids Token curated test grids are decentrally-curated grids with intrinsic economic incentives for token holders to curate contents judiciously. Again from Kilt: Token holders have a tactical incentive to challenge and reject every candidate to their registry In the interest of increasing their holdings, this is at odds with their strategic interest of increasing the value of their holdings. An empty list is of no interest to consumers, so candidates would not bother applying to it. Candidates drive fundamental demand for a registry’s intrinsic token, so by behaving tactically rather than strategically, token holders go against their interest and incur a potentially severe financial loss. Generally, it is in the interest of economically rational token holders to behave strategically and curate a high-quality list. The augmented democracy protocol suggests using the same tripartite proving structure as Kilt: Verifier, claimer, and attester, but the latter one is responsible for curating the list of contributors to the test grid: gatherers and curators. Gatherers gather facts about the question, and curators conveniently arrange the information into the most straightforward and easy test possible. The goal of the test is less to test knowledge but to assert the recognition of facts instead. Assuming that this is a good way for tests to be based on verified facts, could there be a case, in specific scenarios, where there would be voter accountability against proven facts? Could this also render elected officials accountable for their decisions when participating in high-level votes? **Deliberative Democracy** On the flip side, shining the light on someone’s disagreement within the consensus could help the individual and the collective. In North American tribes, ”Unanimity requires that everyone involved agrees.” This more thorough approach could be applicable in some instances and could be aided by several rounds of augmented voting. **Staking and Quadratic Voting** \ \ The concept of ”putting your money where your mouth is” has been used successfully by proof of stake. Initially a good idea, whales have successfully tampered with these networks. Whales have a proof-of-stake advantage; the more coin you offer, the higher the chance you have to be selected as a validator. With the existing democracy pallet, proposals are already created with a staked amount. If this could be extended to voting using this same formula: \ cost to the voter = (number of votes)² To even out the voting power. The cost of each vote to a single project from a single contributor will increase, encouraging community contributors to donate to more projects. \ Read more >> **Node Reputation / Performance History** \ \ Leveraging substrate reputation mechanism for feeding Token curated test-grids. WIP \ *All of the above is not a solution in itself but can contribute to strengthening the vote and highlighting the weaknesses of a vote in dispute resolution, elections, reaching consensus, or seeking out the truth.*
# Dynamic NFTs & DeData Marketplace The main difference between a static and dynamic NFT is the ability of the token’s metadata to change. After a favorable vote from the procedure enforced by the democracy pallet, a dynamic NFT can be minted. Its owner, along with the data and its characteristics, can be recorded in its own metadata.\ \ **Metadata** \ \ This is information that will be stored on each API’s database or other persistent storage such as IPFS. It consists of the data or information regarding the data if it is too large to reside on-chain. Initially, at the creation of the NFT, the service level agreement, terms and conditions waiver will be stored in the form of a Ricardian contract. The Kylin Data Oracle constantly updates the metadata from a data feed. **Semi Fungibility/ SFT** \ \ One of the token’s metadata can also serve as a holder of value, often labeled as shares. These shares can be bought to motivate the work this token was created to do by community members who ”believe in the cause.” Dynamic Data-Driven Strategy By assigning our data stream to a dynamic NFT. metadata, the data tied to this NFT can be managed and sold to the most desirable or highest bidder. The price and nature of the data offering should be driven by users' need for this data. The value it generates should also contribute, along with the purchase of subtokens, to its own maintenance costs. For example, if this data needs to be verified and curated by a committee, the NFT value should cover these costs. The data’s ownership should then be constantly revised by its owners for for-profit or to preserve the integrity of the data itself. # DeData Market The concept of a market introduces the notion of ’participation capitalism.’ Participation requires effort and cannot be enforced and hence must be enticed by a marketing approach. NFTs offered on the DeData market can serve for ”bootstrapping.” data feeds, questions, debates, and the search for truth into existence. Also, NFTs offered by the DeData market is such that real financial value will be attributed and dynamically modified according to accurate life results, rendering the appeal for data NFTs greater than speculative and empty (”bored ape”)NFTs, which are more likely to be subject to the more significant fool theory. The cheaper operation costs of transactions in the Polkadot ecosystem make this even more appealing and realizable.\
![](/files/KX8FGjXAbNIYCfqX0PB6) # Token Economics The Kylin Network is powered by the $KYL token, which is used to secure the network, back DAO decisions, and incentivizes participants for their contributions. On Kylin’s canary network, Pichiu, on the Kusama blockchain (Polkadot testnet), the $PCHU token serves all of these purposes of $KYL and even more, including securing crowdloans to win the required parachain auctions. Outlined below are these token specifications;\ \ **Testnet Stage** \ Token Ticker: $PCHU \ Max Supply: 100 Million \ Token Type: Utility | Canary Network \ \ Token Allocation: \ \ Crowdloan(s) - 40% \ Parachain crowdloan stimulus - 10% \ PLO Reserve (Used for future auctions) - 30% \ Ecosystem - 60% \ Community rewards - 9% \ Lock drop rewards - 5% \ Holders rewards - 6% \ Marketing Fund (Promotions & Educational Content) - 20% \ Liquidity Fund (Liquidity for $KSM swaps) - 10% \ Developer fund (Infrastructure costs and validator rewards) - 10% **Mainnet Stage** \ Token Ticker: $KYL \ Max Supply: 1 Billion \ Token Type: Utility \ Token Standard: Polkadot Parachain \ Pichiu Airdrop The Pichiu token ($PCHU) is set to have a generation event on the Kusama Network at block 13,219,200, and this will be followed by an undisclosed amount of snapshots of the ERC20 $KYL holders for the necessary token migration to its test chain on the Pichiu Network and subsequently its native chain on a Polkadot parachain. **Pichiu Airdrop Eligibility** \ $KYL Holders will be eligible for airdrop only by connecting their $KYL custody wallet to a native Polkadot wallet by a dapp to be provided by the team for validation of balances and equivalent $PCHU airdrop. **Holder Rewards** \ Total Rewards Supply - 6% of Max Supply. \ 1% $PCHU will airdrop to $KYL holders immediately, and the remaining tokens will be distributed each month (0.5% per month) \ Based on holder rewards of 6%, 6m / 173m equates to 0.034 $PCHU per KYL \ The values will be different for lock drop rewards as it is 5% instead of 6% **Lock Drop Rewards.** \ Total Lock Drop Supply - 5% of Max Supply. \ 0.5% $PCHU will airdrop to $KYL holders who lock their $KYL per month by staking. \ This will last 10 months. All airdrop rewards are given to Kylin addresses who are holding their $KYL tokens in non-custodial wallets or staking from the time of the snapshots. ## **$KYL & $PCHU Token Utility and Use-cases** The utilities of the $KYL token include the following but are not limited to; **Network Fees**. \ The $KYL & $PCHU tokens find value in settling the network overheads and other on-chain economic activities between agents, including; * Dapp Queries * Polkadot parachains queries * External chains queries * Dispute resolution * Elections * Inquiries. **Staking** \ In order to secure their position in the Kylin ecosystem, the following entities must comply with the SLA requirements and stake an amount that can be slashed in case of bad behavior. * Push based oracles * Pull-based OCW * Pull-based API * Collator node * Parachain node **Data market/NFT/SNFT** \ \ Submitting data feeds to the Kylin Network decentralized data marketplace, as well as the questions necessary to test and validate the submitted data, are powered by the $KYL tokens. If any disputes arise, they serve as an incentivization and disincentivization tool to foster the best behavior accordingly. Other utilities include the crowdsource funding to build and register pertinent data feeds for Semi-Fungible-Tokens. Finally, the bidding and asking of Data feeds sold/auctioned in the marketplace is done in $KYL tokens. **Rewards** \ Network contributions from the following entities are compensated with the $KYL/$PCHU token. * Push-based oracles KYC and the use of random and decentralized fair sequencing will act as a barrier to attacks and allow reporters to earn rewards equitably. Also, the reporters will have to pay a transaction fee for their chance to be included in the aggregation buffer. If they do make it to the buffer, and if this contribution is used in the overall process of answering a paid query, a percentage of the fees will go to this reporter, and reimbursement for all previous transaction fees will occur. * Pull-based OCW Because they are integrated into a collator, OCW benefit from guaranteed access to the Kylin Oracle runtime aggregation Buffer * Pull-based API * Collator node * Parachain node * Attesters * Curators * Gatherers ## Strategic Investors Kylin Network completed its seed round fundraising in Nov, receiving enormous support from nine institutional investors on capital, project advisement, technology development, future parachain slot auction, and more. ![](/files/-MNatIzmnh376c-kXyzu) ##
# Team Members and Advisors The 21-person team and advisor consist of technical, marketing and financial talent coming out of top blockchain projects, schools and employers including **Columbia University, Wharton, John Hopkins, Beam, TomoChain, Harmony, JP Morgan** and **Credit Suisse.** ![](/files/-MNaj8Thb6ZUBBEJqV9U) ## Team Experience [**Dylan Dewdney**](https://wiki.kylin.network/getting-started/www.linkedin.com/in/dylan-dewdney) **- Project Lead** * Longtime (2011/12) crypto enthusiast, miner, investor * Co-founded Harbour DAO 2017 * GTM for Beam.mw + Chief Evangelist * Head of Growth, AdEx * Investor and Advisor to Ramp and other projects [**Agbona Igwemoh**](https://www.linkedin.com/in/agbona/) **- Operations & Marketing Lead.**
* Early Crypto Enthusiast & Convener * Beam Outreach Growth & Development Lead | Africa * Marketing Manager & Business Strategy at Sovereign Wallet Network * Co-founder & Ex-Operations Lead Bictory Finance [**Sylvain Cormier**](https://www.linkedin.com/in/sylvain-c-0592805/) **- Tech Lead** * Fullstack Blockchain Systems Developer at Hypotenuse * Blockchain Systems Developer at Volentix Labs # Development Roadmap ## Recent Work ### **Verify Production of Concepts (POC) and Implement Substrate Modules** In this milestone, we will verify features with limited users and launch the testnet for the production of concepts. The implementation of off-chain workers of Substrate Framework will be built and validated. | Deliverable | **Specification** | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **License** | Apache License 2.0 | | **Documentation** | Documents containing the description of whole architecture design for Kylin Network | | **Testing Guide** | We will provide a full test suite and guide for the POC. | | **Oracle Node Module Repo** | Oracle Node for data feeding built on top of Substrate 2.0 as a customized module written in Rust will store and process the data query request from data consumers, also it will handle the data feeding from miners. The very consensus protocol and the simplest schema of oracle market are implemented inside. | | **Data Feeding Repo** | It handles the query requests from oracle nodes, and feeds the data after processing as requested. It will be implemented with Substrate 2.0, and the major data feeding part will be built with off-chain workers. We will perform configuration and optimization work to make this easier for typical use cases of the Kylin Network. | | **Datasource Sample Repo** | The sample datasource provider provides the data (e.g. the data provider fetches the spot and contract data from derivative exchanges) to be used by miners. It will contain two parts, the Java data retriever to access APIs from exchanges and the NodeJS datasource to handle data feeding. | | **Data Analytics Sample Repo** | The sample of how the data will be analyzed for data analytics. We will provide an interface of the analysis of market data and blockchain data as POC. | | **Docker Image** | The Kylin Network docker image contains the POC version which can be running anywhere to verify the idea of Kylin Network. | ## Roadmap ![](/files/-MWOLbxRIlyVHV3s6nIU) **2020 Q2** Proof of Concept Core Protocol Prototype Establishment **2020 Q3** Draft and Improvement of the Whitepaper **2020 Q3** Development & Marketing Launch **2020 Q3** Official Whitepaper Publish **2020 Q4** Smart Contract Security Audit **2020 Q4** Private Testnet Release Internally **2021 Q2** Announce Bug Bounty Program **2021 Q2** Mainnet Test Version Online **2021 Q2** Implementing Bridges to Multiple Blockchains **2021 Q3** Mainnet Version 1.0 Online **2021 Q3** Integrating Testnet DApps and Partners to Mainnet # Community Engagement Kylin’s current community engagement strategies include: * **Exposure on Leading Media Channels:** We will release additional articles on Forbes, The Block, CoinDesk, CoinTelegraph and many other leading media channels. * **Ecosystem Development Lead Program:** We will launch an Ecosystem Development Lead Program to recruit and get more technology and development contributors involved into our project. * **Promotion of Online and Offline Events:** We will publish an article on medium upon the progress of this project. Meanwhile, we will join Polkadot related off-line events and do online AMA sessions to promote the project to the Polkadot community. Kylin’s future community engagement strategies include: * **Bounty Program for General Community:** We will reward users who contribute positively to community building and content creation through an Ambassador Program. The community management team will be available 24/7 to answer questions and facilitate discussions in community channels. * **Incentive Program for Dapp Developers:** Kylin Network focuses on giving developer support through both offline and online channels. Developers can integrate the data with only a few lines of code. The simplicity of integrating this project makes it easy for any developer to experiment. * **Mining Program for Node Runners:** Kylin Network is targeting a global pool of 100 nodes upon the completed rollout of Kylin Network to achieve the highest degree of decentralization as possible. Gradually, reputable and trusted public nodes will be onboard onto this project to ensure the stability of the network. * **Incentive Program for Data Providers:** After the main functions are completed, we will set up an incentive program to encourage more market data and social data sources as premium data providers for Kylin Network. * **Potential IPO during Parachain Auction for Community Members:** Kylin Network may hold an Initial Parachain Offering (IPO) and reward users for helping our auction with $KYL tokens. # Future Plans ## Milestones The Kylin Network plans to become a parachain for the Polkadot network. We have some preparations for auction and we may design a possible community-wide IPO. ### Phase One Our goal is to achieve all the basic functions of current data feeding and verification solutions, in addition we will begin to build our array of non-traditional data sourcing options for Dapp builders to utilize and the functionality of a one-stop shop for data sourcing needs without manually calling each http. ### Phase Two Our goal is build a cross-chain (such as parachains and parathreads) data querying and data structure tools just like the cross-chain version The Graph on Polkadot. It will be the absolutely necessary data infrastructure as the ecosystem of Polkadot is growing rapidly. ### Phase Three As the maturity, stability and reach of the data marketplace begins to create opportunities for analytics, we will engineer analytics tools to extract meaningful data findings, patterns, interpretations, while implementing low-cost commercialization functionalities for the public. ### Phase Four Finally, our ultimate goal is to provide an essential Open API and SDK from a high-level perspective with the above tools, fully powering the data economy on Polkadot. ## **Technology Integration** The Kylin Network team is already looking toward furthering research in the field of decentralized Oracles. Several solutions have already been identified as potential ways to increase the security and speed of the Kylin Network Oracle. ### **Zero-knowledge Submissions** Zero-knowledge proofs (ZKP) allow for parties to prove that they know a value without revealing the value. For the Oracle, parties could submit a ZKP for the mining solution along with a hidden query value. Once the five parties are chosen as successful miners, they are then required to post the unhidden value (Oracle query) which corresponds to the hidden value submitted with the ZKP. This could help us save gas costs for submissions, prevent mirroring, and further incentivize miners to compete for the median value. ### **TLS Notary Proofs** TLS Notary Proofs give assurances that a website was queried accurately and that no error was returned. The Kylin Network Oracle has plans to utilize different levels of assurances that can be returned (or stored) with the query to ensure that miners are accurately reporting data from the requested query. ### **Optimistic Implementation** The implementation of a complementing non-mining oracle system that allows for data submission by any party for the data requests. This complementary system assumes data submitters have the best intentions. This optimistic approach can allow for disputes by requiring a PoS and/or can be based on submitter reputation. This implementation would be considered less secure and would cater to projects/Dapps/users that may not be time-sensitive and can “shop” around for data. ### **Automatic Reporting and Monitoring** Off-chain analysis for detecting outliers and reporting these to “gain” the “bad” miner’s stake. For example, reporting a value/miner, if the mean differs from the median by a certain amount. The Kylin Network Oracle provides a decentralized option for high-value off-chain data. Kylin Network plans to deploy our current contracts on the Kylin chain in the future and to continue research on creating a secure, scalable, and on-demand Oracle to help smart contracts achieve their true potential. # Media Coverage **Hackernoon -** Making Sense of Price Oracles in DeFi **Yahoo Finance** - Kylin Network Launches Trustless Data Infrastructure For DeFi And Web 3.0 **Entrepreneur** - 3 Lessons From the Summer DeFi Boom **Cointelegraph** - Blockchain-based voting systems have potential despite security concerns **Bitcoinist** - Kylin Launches Oracle to Protect DeFi Against Financial Data Manipulation **Benzinga** - Kylin Network Launches Trustless Data Infrastructure For DeFi And Web 3.0 **Dailyhodl** - The Polkadot Multi-Chain: Building Out the Blockchain Superhighway # Contact Us Website: Medium: Telegram: Twitter: Linkedin: [https://linkedin.com/company/kylin-network](https://www.linkedin.com/company/kylin-network) Github: Email: