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