How the Overledger Network Community Treasury powers the Network of Networks Seq Follow Apr 3 · 15 min read

Quant Network recently released the Overledger Network Community Treasury Design paper which compliments the Overledger Network Whitepaper. In this article I will discuss the community treasury design and how it will add additional utility to the QNT token and facilitate the launch of Overledger Network, a horizontally scalable decentralised trusted Network of Networks connecting all DLTs (permissioned, permissionless, current and future) as well as existing networks. Where anyone will be able to run a node and contribute and be rewarded with transaction fees in QNT.

Summary:

The community treasury is a Multi Chain Application (MAPP) operating in a trustless manner with the use of Layer 2 unidirectional payment channels. This enables scalability for payments for transaction fees in QNT with the vast majority of transactions being performed off chain instantly, with only minimal transactions being done on chain such as the opening and closing of channels and random reconciliations). This means despite QNT being a ERC20 token it doesn’t matter about Ethereum’s low tps or high ETH fees.

In addition to the already extensive list of utility the QNT token benefits from as detailed in the Quant Network Utility paper and David’s article here, this utility will be increased further with the community treasury where more QNT will be used / locked in payment channels, further reducing circulating supply:

• There are deposits for Users (to pay fees) as well as small deposits to cover against raising incorrect disputes.

• Gateways operators must have a minimum deposit to join the network which is a license fee (and will be much lower than the original 500 QNT that was planned). They also have a variable deposit where the operators choose how much to stake (which unlike the license fee is returned providing the gateway doesn’t act maliciously / faulty behaviour). The more that is staked the more requests the gateway is authorised to handle. If the gateway returns faulty data / malevolent behaviour, then the deposit gets slashed as punishment to incentivise correct behaviour.

The community treasury design has the benefits of staking where more QNT is being used / locked up in funding payment channels and used for fees paid to gateways increasing demand and reducing circulating supply of QNT, but importantly without the usual major disadvantages associated with staking with proof of stake blockchains, where the rewards and just created by minting new tokens via high inflation increasing supply and diluting existing token holders, which I discussed further in a previous article here.

With QNT there is no inflation, no new tokens are minted, the increase in demand for QNT will need to be purchased from the existing supply of tokens (circulating supply will also reduce as more QNT is locked in payment channels / staked in addition to Enterprise/Community licence fees to access and use the Overledger software). Those that don’t want to run a gateway aren’t punished through dilution of the tokens (in fact everyone benefits from the increased utility demand in QNT) and those that do choose to run a gateway can benefit from additional revenue in QNT from processing functions which they could then use those rewards to further increase the amount of QNT they stake to process even more transactions.

An extremely exciting functionality has been added and will be a breakthrough for the distributed ledger domain with Overledger Network providing a method to establish trust between users not running a node and parties running nodes providing a crucial missing piece in full end to end trust. This is achieved through a game theoretic approach to establish trust where the community treasury allows a user to ask multiple gateways to compute the same function or a corresponding function Check. This approach means that economically rationale gateways will act truthfully, whereas malicious gateways will be slashed and removed from the Overledger Network quickly, enabling users to trust the results provided without running a node themselves, or having to trust a single provider such as Infura who potentially may return faulty information.

The ability for a user to query multiple gateways for functions could also be used for decentralised oracle functionality but also the platform offers huge potential for the likes of Chainlink to be built as a MAPP on Overledger enabling decentralised Oracle functionality to all connected blockchains through Overledger Network whilst benefiting from the layer 2 payment channels for fees (which this benefit could potentially extend to payments to other MAPPs with their own ERC20 token for use with their specific MAPP as well as QNT being used for the underlying Overledger Network fees.)

The Overledger design opens up for so many possibilities, with a few potential examples only scratching the surface below:

Micropayments from IOT devices to interact with MAPPs utilising payment channels for scalable, low fees as well as integration with Point of Sale systems for instant payments etc.

Many more projects to be built as MAPPs benefiting from interoperating with multiple blockchains as well as offchain networks and utilising payment channels for fast, cheap payments.

Along with treaty contracts using Quant’s atomic swap capability this also provides additional functionality for DEXs to be built on Overledger Network

Offering Treasury-as-a-Service to projects

Potentially enabling gas fees to be paid by users in QNT to the treasury which is then converted to other tokens as required

A more detailed look at the Community Treasury Design:

Overledger Data Standards

The Overledger Network relies on data standards so that all stakeholders in the network “speak a common language” and inconsistencies in responses can be detected. This data standard is known as the Overledger Data Standard. By having a data standard, data object instances can be compared of the same object type to determine if they are equivalent and confirm the output enabling these to be compared against other gateways enabling a game theoretic model which disincentivises malevolent behaviour and provides trust.

Functions

Users can request functions to be computed by Overledger Gateways. Each function takes as input a data object instance of a speciﬁc data object type and returns as output another data object instance of another speciﬁc data object type. Functions are organised into four main sets:

1. Private — contains all the functions that use private gateway data, e.g. GET Licence.

2. Compare — contains all the functions that do not use private data and the results from diﬀerent gateways can be compared for veriﬁcation purposes, e.g. GET Transaction.

3. Check — contains all the functions that do not use private data but a diﬀerent function is more appropriate to use for veriﬁcation purposes, e.g. POST Transaction should be veriﬁed not by calling the same function on another gateway but instead by calling GET Transaction.

4. Multi — contains functions that do not utilise private data of an Overledger gateway and do not utilise the current state of a distributed ledger with probabilistic ﬁnality. This is the set of functions that we can create multi-gateway payment contracts over.

Creating end to end trust

Distributed ledger networks provide a method to establish trust between different parties where they each run blockchain nodes and can verify transactions providing trust. Despite this, many developers do not run their own blockchain nodes and instead rely on a small number of providers such as Infura and Etherscan in the case of Ethereum for interaction with the Blockchain through their API. Without the end user running a node themselves how do they know if Infura / Etherscan start returning faulty data? Or with permissioned DLT’s where the end user isn’t able to run a node and verify transactions how can they really know that the data the stakeholder returns actually comes from the DLT?

With multi-gateway payment contracts, users not running a DLT node can ask multiple gateways to perform a request where the responses will be compared for veriﬁcation purposes. Therefore, not only do distributed ledger networks provide a method to establish trust between diﬀerent parties running diﬀerent nodes, but the Overledger Network will provide a method to establish trust between users not running a node and parties running nodes providing a crucial missing piece in full end-to-end trust.

This is achieved through a game-theoretic approach to establish trust where the community treasury allows a user to ask multiple gateways to compute the same function or a corresponding function Check. The diﬀerent gateways are then essentially placed in competition, each correctly responding gateway will be rewarded with a fee, each non-responding gateway will not be paid and each gateway incorrectly responding will be penalised. Gateways are further incentivised to be truthful as the penalty fee from gateways returning incorrect results will be moved to the gateways returning truthful results. This approach means that economically rational gateways will act truthfully, whereas malicious gateways will be slashed and promptly removed from the Overledger Network. This game-theoretic approach is enforced by the treasury and implemented through multi-gateway payment contracts.

Users

Users will each need to deposit an amount of QNT that will be used to pay fees to gateways for processing functions. This deposit will be used to fund a payment channel between the user and the community treasury. Any fees that haven’t been spent when the channel times out / is closed will be returned to the user.

The user also has to deposit a small amount of QNT to cover the cost of any penalties for raising incorrect disputes. This dispute deposit is not expected to be large but is used to disincentivise a user from raising many unnecessary disputes and is returned if no unnecessary disputes are raised.

When a user interacts with the Overledger Network it needs to have decided:

• What function to request be performed from gateways

• What data object instance to pass to the function

• What is the maximum response time for the gateway to return the value from performing the function

• The desired and minimum number of gateways to perform checks / verifications.

• Which metric to use to select which gateways are preferred to process the function request — This can be random, lowest transaction fee, speed, distance, reputation etc. (Regardless of the metric chosen an element of randomness will be introduced into the process so that gateways cannot deﬁnitively understand which other gateways may get asked to perform the same function.)

• Which specific gateways to choose for a function in the form of a list of lists.