State Channel Documentation v0.1 State Channel Documentation Powered By: State Channel Documentation v0.1 Contents 1. Revision History .......................................................................................................................... 3 2. Abstract ...................................................................................................................................... 4 3. Introduction to Constellation’s HyperGraph Network ............................................................... 4 4. State Channels ............................................................................................................................ 5 5. Nodes and their role in State Channels ...................................................................................... 7 1. State channel node .................................................................................................................. 7 2. Validation node (full node) ...................................................................................................... 8 3. Hybrid node ............................................................................................................................. 8 4. Lite node .................................................................................................................................. 9 6. Consensus ................................................................................................................................... 9 1. Layer-1 consensus ................................................................................................................... 9 2. Layer-0 consensus ................................................................................................................. 10 7. Steps involved in building a state channel on the HyperGraph ............................................... 11 8. Coming Soon ............................................................................................................................. 13 9. Use Case – Alkimi Exchange ..................................................................................................... 14 1. Introduction to Alkimi Exchange and the digital advertising ecosystem .............................. 14 2. Problems in the digital advertising ecosystem ...................................................................... 15 3. Design goals of Alkimi Exchange ........................................................................................... 16 4. How Constellation’s HyperGraph enables Alkimi Exchange to resolve the problems of the Advertising ecosystem and to achieve the design goals ............................................................... 16 State Channel Documentation v0.1 1. Revision History Version Number 0.1 Changes Initial draft explaining features of HyperGraph, state channels and consensus mechanism. State Channel Documentation v0.1 2. Abstract This document is intended to provide all the information needed to build a state channel on top of Constellation’s HyperGraph Network. This document is intended to act as a guide to project teams and developers. 3. Introduction to Constellation’s HyperGraph Network Constellation’s HyperGraph Network is the world’s first Layer-0 blockchain, which aims to resolve the problems faced by blockchain solutions that are currently in the market. HyperGraph Network is based on the concept of ‘Generative Economics’, which is defined as “a living economy that is designed to generate the conditions for life to thrive, an economy with a built-in tendency to be socially fair and ecologically sustainable”. This definition provides not only the objectives on which the HyperGraph Network is built but also defines the problems with the current blockchain solutions. Some of the features of Constellation’s HyperGraph Network which enables it to resolve the problems of current blockchain solutions are as below. 1. HyperGraph provides for feeless transactions. This ensures that applications and users of these applications do not have to pay any fees when creating transactions. This resolves the problem of exorbitant fees that are charged by blockchain solutions such as Ethereum. This also enables project teams to build real world applications on top of HyperGraph and users to transact freely without the need to pay expensive fees. While HyperGraph allows for feeless transactions, these transactions tend to be rate limited. In order to achieve higher throughput and faster transaction times, it is possible to specify a fee for the transactions. 2. HyperGraph provides a highly decentralised network of nodes that are operated by any user who can provide the collateral for running a node. This will also be followed by a concept of ‘lite nodes’, which will require lower levels of collateral. This resolves the problem of decentralisation that is seen on blockchain solutions such as Bitcoin and Ethereum, where a few large players dominate the mining and therefore the consensus mechanism. 3. While some blockchain solutions use ‘proof of work’ consensus, others use ‘proof of stake’. ‘Proof of work’ requires miners to resolve complex mathematical problems which are environmentally unfriendly as they require large amounts of energy. This also ensures that only those operators who own computationally superior machines can function as node operators. ‘Proof of stake’ requires users to provide huge amounts of capital in order to function as node operators. Both these consensus mechanisms restrict users from functioning as node operators and hence affect the decentralised nature of blockchains. However, Constellation’s HyperGraph Network uses a unique consensus mechanism called ‘Proof of Reputable Observation’ (PRO) which rewards node operators based on their actions on the network. This feature, combined with the ability to run full or lite nodes by providing collateral ensures that the network of nodes is truly decentralised. 4. HyperGraph supports infinite horizontal scalability of its nodes. Based on the network bandwidth, the collateral required to run the node can be modified in order to enable more nodes to enter the network and hence be able to process the increased number State Channel Documentation v0.1 of transactions. This ensures that the network can meet the bandwidth requirements of any application that is built on top of it. 5. HyperGraph supports very fast transaction times, much faster than any existing blockchain solution in the market today. This is primarily achieved by introducing the concept of ‘State Channels’ (discussed in the next sections). State channels (Layer 1) can be viewed as a subnet of nodes that is specific to each project. These nodes enable HyperGraph to provide two levels of consensus, one achieved within the state channel and the second achieved on a global level (Layer 0). The two levels of consensus enable the processing to be shared between the layers and contribute to transactions being validated in real time. This enables application developers to develop real world applications that need fast, reliable and secure processing. 6. HyperGraph works on Layer-0 which provides a global cross-chain liquidity pool using its $DAG token. Current blockchain solutions in the market, such as Bitcoin, Ethereum, etc are all Layer-1 protocols. Layer-0 enables any Layer-1 blockchain solution or Layer1 state channel to work with each other. HyperGraph makes this possible by supporting ‘bridge connectors’ which interconnect data from one blockchain to another. For example, a state channel built on HyperGraph can accept transactions (data) from the Ethereum and Bitcoin blockchains, process and create business logic using this data. This feature removes any restriction that an application may have on the types of transactions it can process, thereby creating an internet of blockchains. 7. Hypergraph supports validation and processing of a wide variety of data from various real-world sources. For example, applications built on HyperGraph Network can accept data from real-world sources such as cars, mobile phones, consumer devices, data stores, etc and are able to validate the data and build business logic using this data. 8. HyperGraph also supports processing of huge amounts of data due to the infinitely scalable nature of its network. 9. Big Data is defined by 3Vs – volume, variety and velocity. Constellation’s HyperGraph is designed to allow it to handle all these properties. a. It can process huge volumes of data owing to its infinitely scalability. b. It can process a wide variety of data owing to lite nodes built on edge devices which can operate based on custom consensus mechanism. It can also accept data from real-world data sources. c. It can process these data feeds at very fast speeds due to the infinite scalability feature of its network which is truly decentralised. 10. HyperGraph also allows applications built on it to cryptographically secure the data that it validates. 4. State Channels Constellation’s HyperGraph Network identifies the problems posed by Smart Contracts that are supported by current Blockchain solutions. In order to resolve these problems and provide applications with the flexibility of building on a feeless, infinitely scalable blockchain solution, HyperGraph introduced the concept of State Channels. State Channel Documentation v0.1 State Channels can be viewed as a subnet of nodes that are specific to a Layer-1 project that is built on top of Constellation’s HyperGraph Network (which itself is a Layer-0 protocol). State Channels enable applications to process and validate different types of data from real world data sources. This feature enables any Layer-1 application to receive, process and act on triggers and data from various sources, thereby resolving the ‘data oracalisation’ problem that is seen on smart contracts built on blockchains, such as Ethereum. A data oracle is a bridge between the blockchain and the real world. They provide on-chain APIs that help to send real world data to and from a smart contract. These oracles depend on off-chain data sources which feed in the data to the blockchain. These data sources are centralised components and are susceptible to problems with the integrity, validity and security of associated data. They are also susceptible to attacks by hackers who can change the behaviour of the smart contract by controlling the data that drives these contracts. Centralising the data source that drives the smart contracts also undermines the decentralised nature of the blockchain. This is referred to as the ‘Data Oracalisation’ problem. While HyperGraph Network provides Layer-0 functionality, all other blockchain solutions, such as Bitcoin, Ethereum, Solana, Matic, etc can be viewed as Layer-1 protocols. Other Layer-1 projects, such as Alkimi Exchange can also be built on top of the HyperGraph Network. This can be visualised as shown in the diagram below where each project can use its own state channel and state channel nodes (SC nodes) to use its own custom consensus to validate data. This validated data can then be exchanged between projects using the underlying Constellation Hypergraph as the Layer 0 protocol which uses its own Layer-0 consensus mechanism and Validator Nodes to confirm the transaction. Figure 1 - Constellation HyperGraph – Layers Constellation’s HyperGraph is able to operate at Layer-0 as it operates on raw data while other Layer-1 protocols are bound by specific transaction formats. Further, the data sets that HyperGraph operates on, can be customised as per the needs of the project. This allows each project that is built on top of HyperGraph to post its custom data/transaction to Layer-0 for consensus. Some of the features of state channels are as given below. a. Ability to accept, process and validate third party data from real world data sources. For example, state channels can accept data from sources such as cars, consumer electronics devices, temperature sensors, advertising exchanges, financial exchanges, etc and act upon triggers from these sources. State Channel Documentation v0.1 b. Ability to accept, process and validate data from other blockchains. For example, state channels can accept data from other blockchains such as Ethereum. c. One of the most powerful features that HyperGraph provides state channels is the ability to define custom consensus mechanisms. This enables them to validate real world data and implement complex logic in order to arrive at decisions. This is impossible on any other blockchain solution currently available on the market. d. State channel logic runs on its own subnet of nodes, which are provided by a distributed network of node operators. This ensures that the operations of state channels are highly decentralised. e. State channels can define their own L0 tokens which can be used to assign value to data. These tokens also enable state channels to create their own Tokenomics which can be used to transact within the specific ecosystem, define specific business logic and reward node operators and users. State channels are not bound by restrictive fees, such as the gas fees to be paid f. on Ethereum networks. While each state channel may monetise their applications using different payment models, there are no fees for users to transact on the HyperGraph Network. For example, a user bidding on a product that is being auctioned on a blockchain powered solution will need to pay gas fees, if the auction were to be conducted on the Ethereum network. However, the user will not have to pay any such fees in order to place a bid on the product, if the auction were to be conducted on the HyperGraph Network. HyperGraph enables infinite horizontal scalability of the network, which enables g. state channels to use the bandwidth to run complex operations of huge sets of data in order to implement business logic. This also enables state channels to provide very fast and cost-efficient transactions ensuring that users do not have to wait for long periods of time or pay high gas fees, in order to complete their transactions. HyperGraph also allows the concept of ‘Lite Nodes’, which enables state channel logic to run on edge devices, such as, cars, mobile phones, consumer devices, h. smart watches, etc which can validate data at the source, before it can be processed further. 5. Nodes and their role in State Channels Constellation’s HyperGraph Network is powered by its decentralised network of nodes. These nodes provide the processing power that enables HyperGraph to process huge volumes of data of different varieties at very high velocities (the 3Vs of Big Data). Based on their role in the network and their functions, HyperGraph defines 3 types of nodes. 1. State channel node Such a node is specific to a state channel and enables the state channel to run its business logic. These nodes typically allow the state channel to handle the following functions. State Channel Documentation v0.1 a. Accept huge volumes of varied data sets from various real-world data sources. These are referred to as Layer-1 transactions. b. Validate data (Layer-1 transactions) received from real world data sources by passing them through the first level of consensus (Layer-1 consensus). c. Fold the validated Layer-1 transactions into the state channel snapshots (Layer-1 snapshot). Each state channel snapshot can contain data that is specific to the state channel. d. Sign the state channel snapshot using the state channel’s signature key. This allows Layer 0 to validate the authenticity of the data posted to it. e. Send these state channel snapshots (Layer-1 snapshot) to Layer-0 for the second level of consensus (Layer-0 consensus). f. Subscribe to Layer-0 events so that any state channel snapshot that has been invalidated by Layer-0 consensus can be suitably corrected. Node operators running such a node are usually rewarded in the corresponding Layer-0 token. 2. Validation node (full node) Such a node operates on Layer-0 of the HyperGraph Network i.e., it is the glue that brings all Layer-1 protocols together by providing a global cross-chain liquidity pool. These nodes provide the following functionalities. a. Accept state channel snapshots from Layer-1 (state channel nodes operating on Layer-1). b. Validate the signature associated with the state channel snapshot to ensure authenticity of the snapshot. c. Group state channel snapshots from various state channels into a global snapshot. d. Run a consensus mechanism on the global snapshot to validate the data associated with the state channel snapshots. As part of the global snapshot processing, balances may be updated to reflect validated Layer-1 snapshots. These balances may be either in $DAG or the corresponding Layer-0 tokens. e. Store the validated global snapshot on the ledger. f. Provide cross-chain liquidity pool, which enables various Layer-1 protocols to be interoperable. This is achieved using $DAG tokens as the medium of exchange. Node operators running such a node are usually rewarded in $DAG. 3. Hybrid node A hybrid node is one that can operate both as a state channel node and a validation node. Node operators running such a node can be rewarded either in the corresponding Layer-0 token or in $DAG. State Channel Documentation v0.1 4. Lite node This is a special type of node that is specific to a state channel. These nodes require lower amounts of collateral and processing power and hence can be run on a variety of devices by users who do not possess the required collateral to run a full node. These nodes usually run on devices such as mobile phones, cars, consumer devices, smart watches, etc and provide validation of data at the source. 6. Consensus One of the salient features of HyperGraph is the freedom that it provides application developers to define their own consensus mechanism. This allows Layer-1 applications (state channels) to accept data from various sources and formats, run validation checks, implement business logic and transact using Layer-0 tokens. There are two levels of consensus that are supported by HyperGraph. 1. Layer-1 consensus This is the consensus mechanism that is run as part of the state channel operations. State channel nodes receive Layer-1 transactions from external sources (data sources, centralised components of the application, etc.). These Layer-1 transactions are passed through the initial round of validation i.e., the Layer1 consensus mechanism. Once this initial round of validation has been completed and signed by the required number of validating nodes, the transactions are collated into either Layer-1 blocks (containing Layer-1 transactions) or Layer-1 snapshots. Layer-1 snapshots are customisable to the state channel and can contain any custom data that is intended to be passed to Layer-0 for the second round of consensus and to be captured on the ledger. This is as shown on the diagram below. State Channel Documentation v0.1 Figure 2 - Constellation HyperGraph - Layer-1 Consensus 2. Layer-0 consensus This is the second stage of the consensus mechanism, and it follows the Layer-1 consensus step described in the section above. Once the state channel nodes have validated the Layer-1 transactions, they are folded into Layer-1 snapshots. These blocks are the input to Layer-0 consensus. The Layer-1 snapshots from various state channels are grouped together into a ‘global snapshot’. This global snapshot is passed through the Layer-0 consensus mechanism. Each Layer-1 snapshot which forms the global snapshot undergoes a custom consensus mechanism that is defined for that state channel. If the snapshot passes Layer-0 consensus, it is captured on the ledger as part of the global snapshot. If the validation fails, the Layer-1 snapshot is discarded. Layer-1 should subscribe to events from Layer-0 to identify if a Layer-1 snapshot has failed the consensus. This will allow Layer-1 to take any corrective actions. This is as depicted in the diagram below. State Channel Documentation v0.1 Figure 3 - Constellation HyperGraph - Layer-0 Consensus The below diagram shows all the steps involved in the custom consensus mechanism (both Layer-1 and Layer-0). Figure 4 - Constellation HyperGraph - Complete Consensus Mechanism 7. Steps involved in building a state channel on the HyperGraph Before we look at the steps involved in building the state channel, let us look at a few definitions. parties. a. Layer-0 (L0) token - A L0 token is a token that is created specific to the state channel. A L0 token brings utility into the project and can be used as a medium of exchange i.e., it is used in the project’s ecosystem in order to transact between State Channel Documentation v0.1 For example, consider a state channel built on top of the HyperGraph Network. Let us suppose that the project enables two parties – a service provider and a consumer to interact transparently using the dApp built by the project. The service provider provides a service that is consumed by the consumer, who in turn pays for the service. The payment for the service, which is provided via the state channel, shall be paid for using the L0 token. b. Layer-1 (L1) transaction – Usually, there are multiple transactions that occur between the service provider and the consumer (in the above example) before the service can be paid for. For example, the consumer specifies the services that they are looking for. The service provider provides all details of the service, terms and conditions. These are agreed by the consumer and both parties are now bound by the agreed terms. Each of these transactions that occur between the two parties and that are specific to the project are referred to as ‘L1 transaction’. These are transactions that are posted to Layer-1 for validation. c. Layer-1 (L1) blocks – State channel nodes may group L1 transactions into ‘L1 blocks’. These blocks may contain L1 transactions which may be related to each other. For example, a block may contain transactions specific to an exchange of value between two parties. In the above example, all transactions between the pair of service provider and consumer may be grouped together into a L1 block. d. Layer-1 (L1) consensus – State channel nodes validate L1 blocks using a consensus mechanism called the ‘L1 consensus’. This consensus mechanism can be customised to suit the needs of the state channel. This process can be used to ingest data from external sources, validate the data, process it and use it to drive business logic. Since transactions of one state channel are different from those of other state channels, the consensus mechanism that validates these transactions are also specific to the state channel (and the transaction type). This custom consensus mechanism is one of the salient features of the HyperGraph Network that sets it apart from other blockchain solutions in the market. e. Layer-1 (L1) snapshots – All Layer-1 blocks/transactions/data are folded into L1 snapshots. These transactions are created by state channel nodes and are specific to the state channel. These snapshots are passed to Layer-0 for the second level of consensus. f. Layer-0 (L0) consensus – The validation nodes receive L1 snapshots from different state channels, group them together into a ‘global snapshot’ and pass these global snapshots through a consensus mechanism, referred to as the ‘Layer-0 consensus’. This is the second round of consensus, the first being the Layer-1 consensus. The diagram below describes the process involved in building a state channel. State Channel Documentation v0.1 Figure 5 - Constellation HyperGraph – Process of building a state channel As outlined above, there are multiple steps involved in building a state channel on Constellation’s HyperGraph Network. These are as given below. 1. Create L0 token 2. Define L1 transactions 3. Define the triggers for sending these transactions to L1 4. Define L1 consensus mechanism for each transaction 5. Define how these transactions are folded into L1 snapshots 6. Define the format of L1 snapshots 7. Define L0 consensus mechanism for each L1 snapshot 8. Coming Soon 1. Creating your L0 token – implementation details 2. Defining L1 transactions and triggers 3. Creating your state channel and L0 consensus – implementation details 4. Defining L1 snapshots, folding L1 transactions into L1 snapshots – implementation details 5. Defining L1 consensus – implementation details 6. SDK features, APIs and usage 7. Build process and testing 8. Deploying your state channel on TestNet 9. Deploying your state channel on MainNet 10. Best practices State Channel Documentation v0.1 9. Use Case – Alkimi Exchange 1. Introduction to Alkimi Exchange and the digital advertising ecosystem Alkimi Exchange is a decentralised advertising exchange that is built on Constellation’s HyperGraph Network. Alkimi Exchange is built to solve the problems that currently plague the digital advertising ecosystem. In order to better understand the problems that Alkimi is designed to solve, let us look at the current landscape of digital advertising. Digital Advertising is a rapidly growing market which has surpassed $340 Billion and accounts for over 50% of all media spend globally. This market is currently dominated by Google and Facebook, who facilitate the trading of advertisements in the digital space. Figure 6 - Alkimi Exchange - Current Digital Advertising Ecosystem There are 4 main actors in the digital advertising ecosystem. This is as shown in the diagram above. a. User b. Publisher / Supply side c. Ad Exchange d. Advertiser / Demand side The user is any individual who visits a website that is hosted by the publisher. This website not only provides the user with content but also presents the user with ads from advertisers. The publisher is part of a supply side platform, which is comprised of multiple parties. The advertiser is part of a demand side platform, which is also comprised of multiple parties. The Ad Exchange is an intermediary that brings the supply side and the demand side together. This matching is based on various criteria such as the content type hosted by the website, the ad size and format that is expected to be shown to the user, the minimum price expected by the publisher to display the ad, the relevance of the ad to the content hosted on the website, etc. These criteria may also include matching an ad to a user based on their details (such as location, age, gender, interests, etc.), which are made possible by the use of cookies. State Channel Documentation v0.1 The ad exchange ensures that the publishers (supply side) get the best possible price for displaying the selected ad to the user by conducting an auction between multiple demand side platforms (DSP). The DSP with the highest bid gets to display their ad to the user on the publisher’s website. The auction process is conducted programmatically and is completed within a second, so that the ad is displayed to the user almost instantaneously. This sub-second response time is crucial to ensure that the ad is viewed by the user. Once the publisher confirms that the ad was displayed to the user, the advertiser pays the amount that was bid as part of the auction. Since there are multiple parties involved both on the demand and the supply side, this price is distributed among these parties. Typically, for $1 spent by the advertiser, the publisher only receives 51c after deductions by each link in this advertising chain. This is typically referred to as ‘Ad Tech Tax’. 2. Problems in the digital advertising ecosystem Digital advertising ecosystem is currently plagued with the following problems. a. Lack of transparency and auditability b. Ad frauds c. Very high transaction fees d. Limited transaction bandwidth e. Lack of instant reconciliation f. Users are not part of the value exchange As described in the above section, only 51% of the amount spent by the advertiser actually reaches the publisher. To make matters worse, there is no transparency or auditability either in the auction process or the price that the advertiser paid in order to show their ad on the publisher’s website. This leads to a serious lack of trust in the system, especially with giants like Google and Facebook running not only the advertising exchanges but also the demand side platforms, leading to a conflict of interest. The problem is further complicated by ad frauds such as domain spoofing, ad injection, ad stacking, etc, which accounts for 20% of the total ad spend. The technical solutions currently available on the market are also subject to very high transaction fees, limited transaction bandwidth and cannot instantly reconcile transactions. This lack of instant reconciliation prevents the ads from being displayed to the user before they scroll away from the webpage. The problem that is least spoken about is that the user bears the brunt of bad advertising, irrelevant ads, poor browsing experience but is not a part of the value exchange. Every link in the digital advertising supply chain gets their share of the ad spend but for the user. This leads to more and more users installing ad blockers, further accentuating the problem for publishers as a reduction in users willing to view ads forces them to increase the number of ads shown to ensure revenue, leading to more users getting frustrated and installing ad blockers and so on. It is high time to break that vicious cycle and ensure that every user who is the target of an ad is made part of the value exchange and is rewarded for viewing the ad while browsing the internet. State Channel Documentation v0.1 3. Design goals of Alkimi Exchange Alkimi Exchange has been built with the following design goals. a. Provide end-to-end transparency and auditability b. Prevent ad frauds c. Reduce transaction fees d. Remove bandwidth constraints e. Provide instant reconciliation f. Make users part of the value exchange Alkimi Exchange is built with the aim of resolving all the problems described in the section above. This is largely made possible by building the exchange on Constellation’s HyperGraph network and by leveraging the unique features that it offers. 4. How Constellation’s HyperGraph enables Alkimi Exchange to resolve the problems of the Advertising ecosystem and to achieve the design goals The below table describes how Constellation’s HyperGraph enables Alkimi Exchange to achieve its design goals. # Design Goal HyperGraph feature that enables achieving this design goal How this is made possible Constellation’s HyperGraph allows projects to build state channels on top of it. These state channels can operate on custom data types and define custom consensus mechanisms to validate these data types. 1 Provide end-to-end transparency and auditability Custom data types and custom consensus mechanism This allows Alkimi to define multiple data types (bid requests, responses, auction results, confirmation whether the ad was displayed to the user, etc.) as part of the state channel and validate these based on the data type. As this validation happens in a decentralised manner, there is no scope for malpractice. The result of such validation (the custom data type) is captured on the ledger, thereby allowing any publisher/advertiser/user to view and audit data related to their transactions. This will allow publishers to access and audit data that was previously unavailable to them. This includes information, such as, which advertisers bid to show ads to the user, details of each bid response, the winning bid response, authenticity of the auction result, fees deducted by the ad exchange, etc. The HyperGraph’s custom consensus mechanism allows Alkimi Exchange to build into its own custom consensus mechanism the ability to determine if any fraudulent actions have occurred in the process of displaying the ad to the user. 2 Prevent ad frauds Custom consensus mechanism This includes the following checks that are built into the custom consensus mechanism. 1. Verify the authenticity of the publisher and the advertiser. 2. Verify whether the ad was shown on the website that it claimed to show it on. State Channel Documentation v0.1 # Design Goal HyperGraph feature that enables achieving this design goal How this is made possible 3. Verify that the ad was in an area of the website that was viewable by the user. 4. Verify that the ad was indeed viewed by the user. Up until now, detection of ad fraud used to happen based on historical data. However, by building ad fraud detection into the custom consensus mechanism, this can be performed on a real-time basis. Further, this validation is performed in a decentralised manner and the result of the validation is captured on the ledger. 3 Reduce transaction fees Feeless transaction validation HyperGraph allows for feeless transactions. This enables Alkimi Exchange to provide highly reduced transaction fees to publishers and advertisers. HyperGraph allows state channels the ability to scale horizontally by using network resources as they are needed. 4 Remove bandwidth constraints Infinite horizontal scalability This is made possible by incentivising node operators to provide the bandwidth required for the state channel. In exchange for the processing power, node operators can be rewarded either in $DAG or the L0 token ($ADS in the case of Alkimi Exchange). The HyperGraph provides very fast transaction times by using two levels of custom consensus. This allows Alkimi Exchange to complete the auction process within a second and provide information to the publisher on which ad to display to the user. 5 Provide instant reconciliation High speed transaction processing This is further aided by the ability to scale horizontally based on the transaction bandwidth requirements. The finality window that is usually set by publishers is approximately 1 second and the ad should be shown to the user before this time, in order for the ad to be registered as ‘viewed by the user’. This is ample time for the Alkimi Exchange state channel to conduct an auction and provide the results of the auction to the publisher. As stated before, Alkimi Exchange uses HyperGraph custom consensus mechanism to validate whether a user viewed an ad or not. 6 Make users part of value exchange Ability to mint L0 tokens and reward users and node operators in L0 tokens The result of this custom validation is captured on the ledger. Additionally, this information is used to reward the user for viewing the ad. A part of the fees paid by the advertiser to Alkimi Exchange is used to pay a reward to the user for viewing the ad. This reward is paid in the L0 token ($ADS), thereby making the user a part of the value exchange. Table 1 - How HyperGraph Enables Alkimi Exchange To Achieve Its Design Goals