Bware Labs is proud to announce that we are releasing our Litepaper! The Litepaper document provides ample details on the INFRA token utility and the different aspects of the Blast Integrity Protocol, to deepen the knowledge of our community and reaffirm our mission to become the one-stop shop for the highest-performing infrastructure services and developer tools that support blockchain builders every step of the way.

Problem

As blockchain technology steadily progresses, more issues are being solved via new, elegant solutions and approaches. Aspects such as the incentivization models for validating transactions, consensus, interoperability, and even the pressing issue of scalability are being tackled and successfully solved by either new protocols or improvements on top of existing ones. However, the issue of decentralized, reliable, and fast access to the blockchain remains largely without an optimal solution.

Finding a way to incentivize blockchain participants or infrastructure companies to run full nodes for a more stable network as well as more reliable and trustworthy means of accessing the blockchain without relying on traditional centralized providers has been a challenge for quite some time in the Web3 space. In this paper, we are trying to present our way of tackling this specific challenge in a way in which no tradeoffs are being made either on the performance or the decentralization side.

Before we dig into the Bware Labs solution for decentralizing blockchain access, another aspect worth mentioning is energy consumption. You will see that by giving current full node owners the option to permissionlessly register their nodes within our protocol they have the opportunity to recycle their resources while earning enough money to sustain their nodes and even make a profit.

Current market

In the current Web3 environment, one thing seems certain: developers don’t want to manage their own infrastructure. And why should they? It requires a tremendous amount of effort and know-how while creating a lot of responsibility. And let’s face it, it’s not the most entertaining effort for developers who, in most cases, are only interested in writing code without having to worry about the infrastructure it runs on.

The traditional API providers were the first to see the opportunity and came up with a solution for this problem. These companies host the blockchain infrastructure (blockchain nodes) needed for dApp development and provide developers with access to the blockchain in exchange for monthly subscriptions based on their level of usage. But even though they solved an urgent need at the time, they also introduced a new issue that stands to threaten the very ambitions of Web3: centralization. A decentralized application that runs on a centralized API provider is sort of nonsense, isn’t it?

This issue was soon spotted in the industry, and in 2020 the first solution to the problem of centralization was brought to the market. Their idea, back then was to create a decentralized network of nodes that receive requests from decentralized applications and route them to other blockchain nodes or available public APIs. Their model is as decentralized as it can get, but it still poses a real problem: performance. It is very hard for such a model to guarantee the high level of performance that a Web3 application or platform might need in order to serve its customers efficiently.

Even though companies and developers that build dApps wish to move to a fully decentralized model, the lack of API performance might push them back to the centralized providers who are able to guarantee SLAs and provide clients with custom subscription plans based on their requirements.

Other projects have recently appeared that propose pseudo-decentralized solutions, which are nothing more than adding a load-balancing mechanism in front of a pool of blockchain nodes. Even though they created staking mechanisms for the incentivization of the nodes serving the user requests, they can hardly be considered to provide real solutions to the existing blockchain access challenge.

Product

How do we solve the problem of having both the level of performance offered by centralized providers and the whole range of benefits that come with decentralization? Well, in our opinion, this is also the main problem that Web3 itself will have to figure out eventually. When it comes strictly to Blockchain API infrastructure, we at Bware Labs believe we have found a way to bring together decentralized infrastructure and fast API performance into a concept we call Proof of Quality.

By Proof of Quality, we mean allowing node owners to join the Blast Protocol as Node Providers. This would be done in a permissionless way, provided the registered nodes are able to match the platform’s performance and data integrity requirements.

All nodes serving user requests are rewarded with our native INFRA token under the condition they can sustain the level of quality required and enforced by our Integrity Protocol.

The process is simple. All Node Providers have to do is register their node endpoints in one of the available slots within the Blast platform for each of the supported networks. If they pass the quality checks, they become active participants and are allowed to create Staking Pools, where they will be required to stake INFRA tokens and start receiving rewards in the form of an APY. They can even accept delegations in order to increase their profitability.

After registration, all nodes are continuously verified against the preset performance indicators. If they fail any of the quality checks, the specific nodes will be jailed. Continuous failure to pass the verifications ultimately leads to node deactivation and the loss of the occupied slot within the platform.

The idea is pretty simple, right? Everyone can register without any interference from the Bware Labs team, their participation being solely conditioned by their own level of performance. This way, all the participants within the platform — clients as well as providers — are able to get the best value for their money or work.

The API consumers are able to get the best quality API services on the market without making any trade-offs in terms of centralization, while Node Providers are able to leverage their technical skills and be rewarded through a fair incentivization mechanism.

Technology

1. The Integrity Protocol

The main technical component, or, if you want, the secret ingredient behind Blast’s Proof of Quality concept, is our Integrity Protocol.

The Blast Integrity Protocol is a distributed piece of software tasked with verifying and monitoring all the nodes within the Blast platform, scoring their performance, jailing, and even deactivating them when there’s a case for that.

Blast quality is measured in 4 dimensions, and the Integrity Protocol verifies that the participant nodes meet the requirements in each of them:

Sync state — Sync checks are done periodically at random time intervals of under one minute. If a node fails verification, it gets flagged and it is verified again at 15 seconds intervals. After 3 failed verifications, it gets jailed.

Data integrity — One of the most important quality functions of the Integrity Protocol is making sure that there are no malicious nodes serving requests inside the platform. Even though the randomized selection of nodes that will answer a particular request would make it really difficult for a malicious node to do any actual harm, our Integrity Protocol is also doing data integrity verifications and jails all non-compliant nodes instantly.

Latency — Response time is a vital characteristic of an API provider platform. It allows decentralized applications and developers to maintain a high level of service for their users and can, at some level, even drive Web3 adoption overall. The way Blast achieves the best-in-industry performance in terms of latency is via a distributed architecture — a custom proxy implementation that efficiently routes requests to the closest and most performant nodes available, as well as by continuously monitoring the participant nodes’ performance against the SLA thresholds established by the platform.

Up-time — Blast’s up-time relies mostly on infrastructure decentralization and a multi-region architecture approach. But even so, all the participating nodes will have to keep a certain up-time in order to earn their rewards efficiently. Our Integrity Protocol is also in charge of this. A node that fails to meet the up-time requirements will also be jailed.

2. The Blast Proxy

The Bware Labs team investigated all the technical solutions available on the market in order to improve the product’s offering and achieve the current state as the fastest and most reliable API platform out there. The decision was made that, for the particular case of blockchain infrastructure, we need to develop our own proxy solution.

The Blast proxy is a piece of software written in C++ that allows us to efficiently handle user requests and decide, in real-time, the most efficient path for a request so that it can get the fastest response possible.

It is able to distinguish between heavy requests such as the ones containing eth_getLogs methods and lightweight requests. It can also route them accordingly, depending on the load on each node, so that the minimum response time is guaranteed.

The proxy is also able to classify and manage the nodes based on their performance and location so that request routing is optimized to the highest possible degree, leading to the current levels of performance in Blast.

3. The Node Scoring Algorithm

Each node participating in Blast will have a score attached based on its overall performance. The score will be taken into consideration in the overall reward distribution.

The algorithm developed by the Bware Labs team takes into account various performance indicators from sync status to latency and uptime. By applying a mathematical model, a performance score is obtained. The score is then passed to the staking smart contract and used when calculating token rewards.

The most difficult challenge when calculating the node score is actually not the algorithm itself but rather the node monitoring process as well as making sure that the performance is measured in a fair and reliable way. For this purpose, we were able to leverage our custom proxy and integrity protocol services by adding functionalities that allow us to monitor performance in real-time and make sure that the participating nodes are treated fairly but, and at the same time, that immediate actions are taken so that a misbehaving node will not impact the overall service in any way.

Token

For the Blast platform and protocol to work, and deliver high-speed, reliable, and decentralized access to the blockchain an incentivization mechanism had to be put in place thus creating the need for the INFRA token. INFRA token will be an ERC-20 utility token, minted on Ethereum and available on both Ethereum and Avalanche chains. You can think of INFRA as the fuel that powers all the infrastructure behind Blast by incentivizing providers to provide high-quality services and allowing all Web3 supporters who believe in mass adoption, decentralization, and performance to participate in the Blast protocol via delegations.

Token utility

Blast was created with the purpose of bringing true reliability and scalability to the Web3 space via the decentralization of the underlying blockchain infrastructure in a clear and straightforward manner.

All participants who are willing to join the platform and support their preferred networks with their knowledge and, of course, their nodes will be able to take part in a fair and well-thought incentivization mechanism based on the INFRA token. On the other hand, in order to ensure the quality of the platform and the best infrastructure services in the industry, Node Providers will also be required to have some skin in the game via staking. This will allow the platform to automatically maintain a high quality of service and self-regulate by rewarding the best-performing nodes while taking immediate actions against underperforming ones so that the end users will never be affected in any way.

Moreover, the Blast staking mechanism offers INFRA token holders and supporters the opportunity to delegate their tokens and receive consistent APYs while participating in the advance of the entire Blast ecosystem.

In the following sections, we will describe how the Blast staking mechanism works and what are the potential earnings for every type of participant.

For the purpose of clarity, here are the definitions of the terms as we see them within Blast:

• Staking — the process of locking up INFRA tokens by a node provider who is running an Active node within Blast and has created a corresponding Staking Pool
• Delegation — the process of locking INFRA tokens by a token holder on a specific Staking Pool that they don’t own with the purpose of obtaining an APY
• Staking Pool — technical term used in Blast to define opening a staking and delegation pool attached to an active node, so that both Node Providers, as well as delegators, have the possibility to earn an APY via staking or delegations respectively.
• Epoch — a time period used as a reference for the calculation of rewards. Also, the amount of time that needs to pass before new rewards become available
• Epoch duration: 24h

Staking protocol

The Blast platform employs a delegated staking protocol in which Node Providers act as validators and accept delegations from Delegators into their associated staking pools. The individual rewards are calculated and distributed to the existing active pools per epoch (e.g. on a fixed time interval).

At the end of an epoch, the protocol computes for each operative pool how much of its stake earned rewards that epoch (the earning stake of the pool) using the formula:

The enclosed variables are defined as follows:

To encourage the onboarding of third-party nodes and the creation of more Staking Pools, the protocol enforces the saturation cap over a pool’s earning stake, roughly defined as:

saturation cap ≔ circulating token supply / desired number of nodes in the protocol (2)

Delegating to a staking pool is permissionless, but harmful to one’s APY if the saturation threshold has already been exceeded. Participants are more incentivized to spin up additional nodes and create new staking pools for them in order to optimize their own stake.

Once the earning stake of a pool has been determined, the protocol proceeds to compute its epoch rewards:

pool earning stake * earningStakeAPY, scaled down to the duration of the epoch (3)

earningStakeAPY is a global protocol configuration applied to all pools, it represents the maximum APY a pool can produce over its entire stake.

From (1) it can be inferred that the maximum earning stake is reached when the pool is filled up to the saturation cap and the entire stake has been deposited by the pool owner.

However, a pool owner is additionally rewarded for maintaining the underlying node by means of a commission fee percentage configured on the attached staking pool. The owner gets this share out of delegators’ rewards which further increases its APY, possibly more than filling the pool itself would.

The minimum stake constraint for creating a new pool along with the earningStakeAPY ensures that the absolute amount of rewards will have a support level and cover the infrastructure costs of the node provider, which in turn leads to a healthy economy for the entire ecosystem.

Yet, a pool’s rewards are subject to its node’s off-chain performance, which is measured by the integrity protocol. Each pool will have a performance coefficient, ranging from 0% to 100%, injected into its epoch rewards calculation:

pool epoch rewards ≔ pool epoch rewards * performance% (4)

Pool Owner base APY

Given that the infrastructure cost varies between different networks, the protocol will reward the pool owners, additionally to their commission rewards, a baseAPY at the granularity of the node attributes: network, chain (testnet or mainnet), node type (full-node or archive) and infrastructure type (cloud or baremetal):

s’ * baseAPY for the particular node specs * performance% (5)

Delegator rewards

A delegator’s rewards are proportional to its stake within the pool:

pool epoch rewards * (100% — commission%) * (d / s) (6)

where d is the stake of the delegator and s is the total uncapped stake of the pool

Limitations and rules:

• Stake required to create a Staking Pool: 5000 INFRA
• Undelegate locking period: 10 days
• Rewards claim frequency: at each epoch (24hrs)

Token distribution

Last but not least the following is an overview of the total token distribution and vesting schedule. The INFRA tokenomics were designed to guarantee the success of the Blast protocol and the fair incentivization of protocol participants as well as to project the same professionalism and trustworthiness that Bware Labs as a whole showed over the last two and a half years of existence towards our customers, partners, and collaborators.

The fully diluted number of $INFRA tokens will be 100 million. This amount is fixed and will be fully unlocked for a total period of 5 years. The total amount will be split into different pools for different utilities:

Protocol incentives: 25% or 25M $INFRA tokens

• reserved for the functioning of the protocol and used to pay the rewards for Staking Pools and Delegators. In addition to the 25M $INFRA, a percentage of the Blast stablecoin revenue (up to 35%) will be used to setup a treasury from which additional $INFRA tokens will be repurchased from the market and put back into the protocol.

Treasury: 20% or 20M $INFRA tokens

• Vesting schedule: 1-year cliff + 3 years linear vesting (daily unlocks — the daily vested amount is calculated by dividing the number of tokens to the number of days in the vesting schedule)
• Usage: The treasury tokens will be employed to further enhance the product adoption, incentivize the building of useful tools by third-party organizations, bug bounty campaigns, team growth.

Core contributions: 20% or 20M $INFRA tokens

• Vesting schedule: 1 year cliff + 3 years linear vesting (daily unlocks)
• Usage: The core contribution tokens are aimed to further grow and incentivize the amazing team behind Bware Labs. It will be used to provide token options to new and existing employees and make sure we attract the most competent engineers and business developers. Part of the tokens will also be used to reward external contributors at the discretion of Bware Labs.

Insurance fund: 1% or 1M $INFRA tokens

• Vesting schedule: Unlocked at TGE.
• Usage: The purpose of the insurance fund is to serve as a guarantee for unexpected events conducted by malicious third parties or which are not in the control of the Bware Labs team (natural disasters, cluster downtimes, protocol hacks)

Marketing: 3.7% or 3.7M $INFRA tokens

• Vesting schedule: 15% unlocked at TGE, 85% 1-year cliff + 1.5 years linear vesting(daily unlocks)
• Usage: All exchange listings require a number of tokens that will be used by those specific exchanges for marketing purposes, hence the unlocked percentage of marketing tokens will be exclusively used for that purpose. The locked percentage will be used to further sustain the awareness around the $INFRA token and Bware Labs as we continue to work for a decentralized, reliable, and high-performance Web3 development space.

Node Providers Incentivized Testnet: 1.2% or 1,2M $INFRA tokens

• Vesting Schedule: 1 year cliff + 1.5 years linear vesting (daily unlocks)
• Usage: Incentives provided to all the Node Providers that supported Houston testnet and promoted their nodes to production

Community airdrop and Incentivized testnet: 0.4% or 400k $INFRA tokens

• Vesting schedule: Unlocked at TGE
• Usage: Community members that hold one of the Galactic Motorcycle Gang NFTs as well as the participants of the Community Phase of the Houston Incentivised Testnet, will be airdropped the corresponding amounts of $INFRA tokens at listing as a reward for their participation and support.

Dex Liquidity: 0.4% or 400K $INFRA tokens

• Vesting schedule: 100% unlocked
• Usage: Add liquidity on Uniswap and Pangolin platforms

CEX Liquidity: 1.3% or 1.3M $INFRA tokens

• Vesting schedule: 100% Unlocked
• Usage: Provide liquidity for listing on the selected exchanges.

Seed round investors: 12.2% or 12.2M $INFRA tokens

• Vesting schedule: 1 year cliff + 1.5 years linear vesting (daily unlocks)

Series A investors: 12% or 12M $INFRA tokens

• Vesting schedule: 1 year cliff + 1.5 years linear vesting (daily unlocks)

Advisors: 2.6% or 2.6M $INFRA tokens

• Vesting schedule: 1 year cliff + 1.5 years linear vesting (daily unlocks)

Listing launch pool: 0.2% or 200K $INFRA tokens

• Vesting schedule: To be disclosed at the official launch pool announcement

Conclusion

The mission of Bware Labs and the Blast protocol is to become the ultimate one-stop-shop for the highest-performing infrastructure services and developer tools that will support blockchain builders every step of the way to production and beyond and do its part in boosting the Web3 mass adoption through permissionless, decentralized infrastructure. As you probably already know by now, our entire protocol is set up in a way that guarantees fairness and transparency for all the parties involved, as well as the necessary characteristics that will allow everyone to benefit from both performance and decentralization across the stack.