Many layer-1 platforms exist out there. A layer-1 platform, in the blockchain world, is a blockchain able to perform smart contracts and dApps, without any dependency on any other blockchains. Actually, Waves is and is not one of these.

This may sound confusing to you. How can a blockchain be both a layer-1 platform and not? Well, the answer is complex, and to get to the answer, it is best first to know what layer-0 is.

Blockchains Layer-0 blockchain is a concept that Cosmos Network introduced to the world. Before this concept, all the blockchains could execute an app or a smart contract. These types of blockchains were named layer-1s. As the demand for dApps increases and more capital flows into the space to support development, we are beginning to see the growing pains of layer-1 networks as they struggle to meet the needs of developers and end users who have opposing views on whether dapps should prioritize scalability, security or decentralization.

Layer-1 networks are built with a monolithic architecture. This means that the execution, consensus, and data availability layers function within a single blockchain network. This stacked design strains the system and results in the need for blockchains to comprise decentralization for security or scalability for decentralization.

In addition, the lack of control over the underlying infrastructure that dApp developers build on top of has also been a cause of much frustration. Rising gas fees on the Ethereum network make all Ethereum dapps too expensive to use, while unexpected downtime on the Solana network similarly makes all dapps on Solana also go offline.

Dapp developers must also make compromises in how they design their dapps in order to remain compatible with these L1 networks, and they lack the ability to explore different consensus mechanisms or to experiment freely with token incentive models because consensus is a primary function of the L1 infrastructure layer. The over-dependence on L1s and difficult tradeoffs imposed by the scalability trilemma can only be remedied by creating a new base infrastructure that empowers developers to launch their own independent blockchains that can be optimized for different aspects of the scalability trilemma.

This base infrastructure is called layer-0, the single most important component for helping blockchains and decentralized applications achieve limitless scalability while maintaining the highest possible levels of decentralization and censorship resistance.

As Vitalik Buterin, co-founder of the Ethereum blockchain, stated: “there are three properties that a blockchain tries to have, and that if you stick to “simple” techniques, you can only get two of those three.” These three properties are:

• Scalability: The blockchain needs to process more transactions per second as the number of users soars. This must be so that the transaction fee does not increase dramatically.

• Decentralization: The blockchain must run without the need for trust. Meaning that no centralized authority is in charge of creating and submitting transactions, and a decentralized network is in charge of such work. This way, the need for trust in one centralized authority is diminished.

• Security: The blockchain must be resistant to the attack of a large number of peers, ideally 50%. Because this attack can risk the security of people’s funds since a double-spending attack would be enabled.

Now, let us take a look at three classes of “easy solutions,” as Vitalik proposed:

• Traditional blockchains: including Bitcoin, pre-PoS/sharding Ethereum, Litecoin, and other similar chains. These rely on every participant running a full node that verifies every transaction; hence they have decentralization and security but not scalability.

• High-TPS chains: including the DPoS family, but also many others. These rely on a small number of nodes (often 10-100) maintaining consensus among themselves, with users having to trust a majority of these nodes. This is scalable and secure (using the definitions above), but it is not decentralized.

• Multi-chain ecosystems: this refers to the general concept of “scaling out” by having different applications live on different chains and using cross-chain-communication protocols to talk between them. This is decentralized and scalable, but it is not secure because an attacker needs only to get a consensus node majority in one of the many chains (so often <1% of the whole ecosystem) to break that chain and possibly cause ripple effects that cause great damage to applications in other chains.

A layer-0 protocol enables developers to launch multiple layer-1 (L1) blockchains that can be designed to each serve a specific purpose and cater to 1 or 2 dimensions of the scalability trilemma as opposed to all 3.

These L1 networks can also be made to communicate with each other such that the end user can have the experience of using one blockchain while they are, in fact, using multiple.

Layer-0 (L0) networks are equipped with Software Development tool Kits or SDKs that allow developers to launch their own blockchains, known as L1s or sidechains, connected to the L0 mainchain but operating independently.

Layer-0 networks solve three critical problems for web3 development and adoption: Scalability, flexibility, and interoperability.

• Scalability: We have already introduced the scalability trilemma. As we mentioned before, to achieve full decentralization, one must sacrifice scalability. And to achieve a good level of scalability, one must sacrifice decentralization or security. But, this is especially true on a monolithic blockchain, like layer-1 blockchains, where all the critical functions like transaction execution, consensus, and data availability (the ability to verify that all the data from new blocks has been published) are managed by a single network, increasing the likelihood of congestion and making it much more difficult to scale.

  A workaround to the scalability trilemma is to delegate the primary responsibility for these three functions to different independent blockchains. This design ensures that the execution chain can be optimized for handling high TPS dapps like a DEX or play-to-earn game without worrying about decentralization. A second chain can then be optimized for decentralization and serve as a final consensus layer for the execution chain to enable withdrawals and anchor its data.

  When it comes to scalability, layer-0 networks can help blockchain scale by increasing transaction throughput. While transaction speed is typically measured in terms of TPS (transactions per second), transaction throughput looks at the total number of transactions a network can handle simultaneously.

• Flexibility: What makes an independent blockchain truly independent is having its own set of validator nodes to confirm transactions and produce blocks based on its own consensus mechanism.

  As a developer, the ability to develop your own blockchain from scratch means that you can:

  • Design your token issuance model—inflationary or deflationary

  • Optimize your chain for speed, decentralization, or security

  • Make your network private and permissioned or public and permissionless

  • Curate the type of dapps you want to be built on your network and foster your own developer ecosystem.

  What’s more, thanks to the SDKs of L0 protocols, the time and complexity of launching a blockchain on an L0 network can be compared to launching a Dapp on an L1, which means you can build and manage multiple L1s with relatively little effort.

• Interoperability: Interoperability is the ability of computer systems with different programs to interpret and exchange information with each other with minimal friction. The perfect analogy for understanding the importance of interoperability in the blockchain space is to think about blockchains as large cities that need to be connected via bridges in order for economic activity to flow in and out.

The three main components of a layer-0 protocol are:

• The Main Chain: This typically serves as the primary blockchain where transaction data from the various L1 chains are backed up.

• Sidechains: Independent layer-1 blockchains that have their own set of validator nodes and can run their own consensus mechanism. These chains do not rely on the mainchain for security but will often share the security of the mainchain since it is typically the largest and most decentralized.

  • Sharing security can occur in different ways. For example, a user may be required to stake the L0’s token in order to become a validator on an L1, which means they can lose both their L0 stake and their L1 stake if they attempt to submit fraudulent transactions.

  • In other cases, L1s will periodically share their network state, the latest record of account balances and transaction history, with the L0 in order to keep a backup in a more secure network in case the L1’s records are ever compromised.

• Cross-chain transfer protocol: The mechanism that enables tokens and other forms of data to be transferred between chains in a trustless and secure manner.

Different types of L0 architecture exist. Horizen explains its architecture in a more linear way than others. The main blockchain (L0 one) is a linear blockchain with no over-complex structure that sidechains (L1 ones) have a connection to it. The sidechains are linear and non-complex blockchains. These chains together build the Horizen network, since they are connected through the mainchain and can interpret and exchange data.

Cosmos has a main blockchain, and using a Hub with the help of the Inter-Blockchain Communication protocol (IBC) creates the communication of its Zones (L1 blockchains). Cosmos believes its structure is not linear and is a bit more complex than the Horizen network.

On the other hand, Polkadot has the most complex structure among the three. They have a Relaychain, which plays the role of the main blockchain. This Relaychain gives some spaces to other L1 blockchains, named Parachain. The Parachains can communicate with the Relaychain and each other through the Relaychain.

You can see the structure of each L0 blockchain above in the images below.

Now that we know what a layer-0 blockchain is, we can continue to understand the two biggest products of Waves Labs:

• Waves Protocol

• Waves Enterprise

Waves Protocol is a community-based stack of decentralized open-source technologies to build scalable, user-friendly apps. What does it even mean?

Launched in 2016, Waves Protocol is a global open-source platform for decentralized applications. Based on proof-of-stake consensus, Waves aspires to make the most of blockchain with a minimal carbon footprint.

Waves technology stack can benefit any use cases that demand security and decentralization—open finance, personal identification, gaming, sensitive data, and many others.

In other words, Waves Protocol is a layer-1 blockchain that can execute smart contracts and dApps, easily and fast, with almost no fee. This helps it be one of the fastest and cheapest layer-1 blockchains.

According to them, Waves Protocol is:

• Simple: Waves enables a world of NFTs, DAOs, and other new business models;

• Scalable: Waves delivers extremely fast experiences with extremely low costs; Eco-

• Friendly: Waves aspires to make the most of blockchain with a minimal carbon footprint;

• Open: Waves bridges to other ecosystems for easy interoperability.

So, let’s see what Waves Protocol brings to the table for the world and how it does it.

A token is a digital asset on the blockchain. A token can be used:

• as a cryptocurrency to pay for goods and services within a project, as well as for crowdfunding;

• as an object or resource in games, etc.

A token can represent a physical or an intangible object. The words “token” and “asset” are used interchangeably in the Waves ecosystem.

Other than WAVES (Waves blockchain native token), all tokens are custom tokens issued on behalf of some account. Any account with enough WAVES to pay a fee can issue its own token. The new token is immediately available:

• for transfers between accounts,

• for trading on the WX.Network exchange developed by the third-party team from the community (except for NFTs; smart assets trading is temporarily unavailable),

• for payments attached to the dApp script invocation.

You can use your tokens:

• as a digital currency – to pay for goods and services in your project or for crowdfunding,

• as in-game objects or arbitrary resources, and so on.

One of the key benefits of the Waves blockchain is the simplicity of issuing tokens. To launch your own token, you don’t have to write a smart contract – just create an Issue transaction and send it to the blockchain. The only threshold for the issuer is to pay a fee: 1 WAVES for a regular token (asset) or 0.001 for a non-fungible token (NFT).

To issue a token, one has to create an Issue transaction within the token parameters:

• name

• description

• decimals

• quantity

• reissuable

• script (for issuing a smart asset).

Also, a token issued on another blockchain cannot be used directly on the Waves blockchain. A new token representing the original one can be issued on the Waves blockchain, and a gateway that pegs the two tokens 1:1 can be deployed. For example, a gateway for an ERC20 token can be created using the Waves-ERC20-Gateway framework. By default, tokens on the Waves blockchain are not smart contracts, and any transactions with them are allowed. The script endows a token with functionality that sets the rules for its circulation. Each transaction involving a smart asset is automatically checked against the conditions specified in the script. If the asset’s script allows the transaction, it will be executed; if the script denies the transaction, it is either not put onto the blockchain at all or saved as failed.

Using smart assets, you can implement various financial instruments on the blockchain (options, interval trading, taxation) and game mechanics (allowing transactions only between characters with certain properties).

Asset script checks transactions involving the asset against the specified conditions. The script contains a logical expression. Possible results of the expression calculation are:

• true: the transaction is allowed,

• false: the transaction is denied,

• error: the transaction is denied.

If the asset script denies the transaction, it can either be discarded or saved on the blockchain as failed. If the transaction is saved as failed, the sender is charged a fee, and no further changes are made on the blockchain.

An asset script can use blockchain data:

• The current height

• Account balances

• Entries in account data storage

• Parameters of the asset itself

• Other tokens

The script also has access to the fields of the current transaction, except proofs.

Issue Asset (Normal Token)

To issue an asset (token), you don’t need to write any smart contracts. You may just send an issue transaction with the fields specified above, and the token is created by the blockchain. You have several ways to create your non-smart asset:

• Using WX.Network: This option is great for those who don’t know any programming languages, don’t have time or want to learn one.

• Using JavaScript: Waves has created a library for JavaScript language for those familiar with this programming language. Developers can easily use two pre-made functions, issue and broadcast, to create and send their transactions to the blockchain.

• Using Python: Again, Waves created a library to import to your Python script, and with just three lines of code, your asset is ready.

• Using dApp: This way is for more experienced developers since you directly contact the blockchain. There are some callable functions that I’m not going to explain, but you can find the full explanation in Waves docs.

Issue Non-Fungible Token (NFT)

A non-fungible token or NFT is a special type of token that represents some unique object. Each NFT has its own unique identifier.

To issue an NFT, you can use any of the methods described above. Specify the following parameters of the token:

• "quantity": 1

• "decimals": 0

• "reissuable": false

Waves Protocol offers a unique approach to decentralized application development: avoiding gas and non-Turing-complete language keeps the system secure and predictable. For smart contract creation, Waves provides its native language called Ride. Its straightforward and developer-friendly syntax makes blockchain development easy and intuitive.

Ride

Ride is a purpose-designed programming language for smart contracts on the Waves blockchain. It was created to address many of the most serious shortcomings of other popular smart contract languages. The overall idea was to offer a straightforward, functional language for dApp development on the Waves blockchain. Ride is easy to learn, especially for beginning developers.

Ride is a statically-typed, lazy, functional, expression-based compiled programming language. It is designed for building developer-friendly decentralized applications (dApps).

Ride is not Turing Complete, and its execution engine (virtual machine) doesn’t have any concept of loops. Also, there are several limitations by design, helping to ensure execution is secure and straightforward. However, Waves recognize that iterations are necessary and have implemented them as FOLD macros. One of the key features is that the execution cost is always predictable and known in advance.

Despite being simple to use, Ride is powerful and offers wide-ranging functionality to developers. It’s broadly based on Scala and is also influenced by F# and the functional paradigm.

Ride was created specifically for execution within a blockchain environment and is optimized for this purpose. Because the blockchain is a shared ledger on many computers worldwide, it works slightly differently from conventional programming languages.

Since Ride is designed to be used inside the blockchain, there is no way to access the filesystem or display anything in the console. Instead, Ride functions can read data from the blockchain and return actions as a result, which can then be applied to the blockchain.

Generating Nodes

A generating node is a node that generates blocks. Each generating node is a validating node. A generating account is an account that a node uses for signing generated blocks.

For a node to be able to generate blocks, its generating balance must be at least 1000 WAVES. This means that the account balance in WAVES, taking into account leasing, was at least 1000 WAVES in each of the last 1000 blocks. The greater the generating balance of the node, the higher its chance of being eligible to generate the next block.

By adding a new block to the blockchain, block generators receive the block reward (at the time of writing this article, the reward is 6 WAVES) and transaction fees.

Validating Nodes

A validating node is a node that validates transactions. A Validating node validates each transaction in the following cases:

• The node receives the transaction via the broadcast endpoint of Node REST API or gRPC Server.

• The node receives the transaction from another node of the blockchain network using the binary protocol.

• The block generator adds the transaction to a block.

• The node receives a block (or microblock) from another node in the network.

Full transaction validation includes the following checks:

1. Transaction fields check, including:

   1. Timestamp check: the transaction timestamp should be at most 2 hours ago or 1.5 hours ahead of the current block timestamp.

   2. Transaction version check: all the features required to support this version should be activated.

   3. Transaction type check: all the features required to support this type should be activated.

   4. Check of token amounts: the values must be non-negative.

   5. Check of fields depending on the transaction type.

2. Sender’s balance check. The sender should have enough funds to pay the fee. The sponsor’s balance is also checked to see if a sponsored asset is used for the fee. Depending on the type of transaction, the sender should have enough assets for transfer or for payments attached to the Invoke Script transaction. Order senders in the Exchange transaction should have enough funds to exchange.

3. The sender’s signature verification for an ordinary account (without script), account script execution if the sender is a smart account, or the verifier function execution if the sender is dApp. A similar check is performed for orders in an Exchange transaction.

4. For the Invoke Script transaction and the Ethereum transaction that invokes a dApp script:

   1. Calculation of the result of the dApp callable function.

   2. dApp balance check: dApp account should have enough funds for dApp script actions.

   3. Check that the transaction fee is not less than the minimum fee based on script actions.

5. Execution of asset scripts if the transaction uses smart assets, including scripts of assets used in dApp script actions.

Leased Proof-of-Stake (LPoS)

Waves Protocol is based on a Proof-of-Stake consensus algorithm. Each participant’s chance to generate the next block is proportional to their economic stake in the network. Unlike Proof-of-Work, Proof-of-Stake is hardware-savvy and power-savvy, making attacks profitless for miners.

Users can lease their WAVES to a Waves node and get a part of the node payout as a reward, preserving full control over their WAVES under their accounts.

Leased Proof-of-Stake (LPoS) is an enhanced type of proof-of-stake consensus algorithm by which the Waves blockchain network aims to achieve the distributed consensus to secure the network.

Nodes can use the leased tokens to generate blocks and get the mining reward. For that purpose, the generating balance of a node must be at least 1000 WAVES.

LPoS allows the token holders to lease their tokens to the Waves nodes and earn a percentage of the payout as a reward.

By using LPoS, leasers will be able to participate in generating new blocks because the larger the amount leased to a Waves node, the higher the chances for that node to be selected to generate the next block. If that node is selected, then the leaser will receive a reward.

When the user starts leasing the tokens, those leased tokens are locked and remain in the same address with the full control of their owner (They are not transferred to the node, they just remain unspendable until the leaser cancels the lease).

The only thing to consider when leasing is to choose the right node operator, as the operator’s node may work with different efficiency and send back different percentages as rewards.

Fair Proof-of-Stake is used to select a miner to generate the next block (I’ll explain this algorithm a bit, later).

Rewards are distributed to the leasers as below:

• The node owner may send the leaser a part of the rewards according to his conditions.

• The more transactions made on the network, the more rewards leasers get.

• These rewards are in WAVES.

Speaking in a nutshell, if you are familiar with Delegated Proof-of-Stake (DPoS), you are more or less familiar with LPoS, too.

Fair Proof-of-Stake (FPoS)

The idea of Proof-of-Stake is as follows: the choice of account that has the right to generate the next block is based on the number of coins in the account. Proof-of-Stake has some disadvantages that allow very large miners to forge a not proportionally greater number of blocks, which is not fair. Therefore, Begicheva and Kofman, in their article “Fair Block Delay Distribution In Proof-of-Stake,” proposed a new mathematical function that is way beyond the scope of this article.

This little change to the formula allows the algorithm works better and fairer. It improves fairness and security. Just to show how much improvement it makes, I’m going to show a table from the so-called article and describe it.

During the experiment, scientists took two miners as attackers, who wanted to create a fork for various reasons. They ran the simulation dozens of times for each setup of the consensus algorithm. The results show that with the old PoS, attackers gained 70% more commission, while this rate is 30% for the new one (FPoS). The table above shows the number of forks that attackers could create for each setup for lengths 2 to 14. As it can be derived immediately, the FPoS setup won’t let attackers create forks of their own to gain more commission. This setup makes it difficult and infeasible for attackers to misbehave and gain more than they should.

Blockchain protocols have some scalability limits and challenges that tradeoff between throughput and latency. The current blockchain technology is not fast enough and does not scale to include more transactions, so we have a performance challenge to consider.

There is a united agreement between miners, consumers, and developers with several perspectives that we need to deploy scalability measures. There has been an ongoing argument on how to improve Bitcoin’s scalability. Current proposals have focused on how big to make the blocks and how to handle the block size increases in the future.

All proposals suffer from a major scalability bottleneck: no matter what block size is chosen, the blockchain system can, at best, reach a proper transaction throughput, increasing from ~3 transactions per second to ~7 transactions per second. This is too far from the 30,000 transactions per second necessary to compete with the existing systems such as VISA transactions. The same major limitations apply to Litecoin, Ethereum, and all other currencies that share Bitcoin’s blockchain protocol.

Waves-NG will address the scalability bottleneck by making the network reach the highest throughput, depending on the network conditions. It will not only enhance the transaction throughput but will also reduce transaction latencies. So it will be possible to get an initial transaction confirmation in seconds rather than minutes.

Waves NG

Waves-NG is based on the bitcoin next generation protocol that serializes transactions and offers important improvements in the transaction latency (lower latency) and bandwidth (higher throughput) compared to Bitcoin without sacrificing other properties.

Waves approach this scalability matter by allowing the miner to farm a block during the time of mining in a continuous approach. This block continues in increments called a liquid block. This liquid block is unchangeable over time once the next block referencing is created and appended.

This approach increases effective bandwidth and speed of block creation, which is described as being “especially significant for businesses” using the Waves Protocol since it allows for conducting microtransactions—without any delays that are typical with traditional blockchain systems.

Furthermore, it allows the blockchain to withstand high loads, such as the distribution of tokens following crowdsales and airdrops of bonus tokens. The speed of processing trading transactions on exchange is increased as well.

Bitcoin Next Generation (Bitcoin NG)

It is a next-generation blockchain protocol, which is an alternative bitcoin scaling solution that does not involve increasing the size of blocks or decreasing the block time interval. This reduces the risk of forks, amongst other advantages. Bitcoin-NG describes that the basic tradeoffs in Bitcoin can be reduced with an alternative blockchain protocol, offering a consensus delay and bandwidth limited only by the Network Plane. The protocol splits time into time periods (epochs). In each time period, a particular leader is responsible for serializing transactions.

The leaders take the rule of generating blocks:

• Key blocks for the election of a leader.

• Micro blocks for ledger records.

Waves NG Operations

Waves-NG’s main and core idea is to split the liquid block into two types, Key blocks and Micro blocks. The process of creating a liquid block works as follows:

• The miner node gets permission to create a block.

• The miner node creates and sends the key block (which does not contain transactions).

• The miner node creates and sends the micro blocks (which contain transactions just as in a normal block with a reference to the previous micro block or key block) with a mining time interval of three seconds.

• Miners will mine those micro blocks and propagate them directly to the network until the next new key block appears regarding the liquid block.

All the transactions are part of the same block and are contributed altogether. In between blocks, the traditional Bitcoin system appears idle to an onlooker, as miners are working to discover the next block, but without apparent progress on the consensus front.

In contradiction, in Waves NG, the key blocks can be small because they need to contain only the coinbase transaction, which defines the public key that the miner will use to sign macroblocks.

Because a key block requires Proof of Stake, miners can not just produce one and usurp the leadership at will. Following the key block, the lead miner can quickly issue microblocks simply by signing them with the private key corresponding to the public key named in the key block’s coinbase.

Leader Blocks

It’s also called “Key Blocks.” these blocks are generated with proof of stake but do not contain transactions.

They serve as a leader election mechanism and contain a public key that identifies the chosen leader.

Each block has a header that contains, among other fields, the unique reference of its predecessor, which is a cryptographic hash of the predecessor header (either a key block or a microblock).

Micro Blocks

Once a node generates a key block, it becomes the leader. As a leader, the node is allowed to generate microblocks at a set rate lower than a predefined maximum.

These micro blocks will contain the ledger entries with no requirement for any Proof of Stake, and they’re generated by the elected leader in every block-generation cycle.

This block-generation cycle is initiated by a leader block. The only requirement is to sign the micro blocks with the elected leader’s private key.

The micro blocks can be generated at a very high speed by the elected leader (miner), thus resulting in increased performance and transaction speed.

For a microblock to be valid, all its entries must be valid according to the specification of the state machine, and the signature has to be valid.

Note that microblocks do not affect the weight of the chain, as they do not contain Proof of Stake.

When all micro blocks have been validated, they will be merged with their key block into one block.

The Reward Mechanism

Remuneration consists of two parts. First, each key block entitles its generator to a set amount. Second, each ledger entry carries a fee.

This fee is split by the leader that places this entry in a microblock and the subsequent leader that generates the next key block.

In order to motivate participants to follow the protocol, Waves-NG uses the following mechanisms:

• Each transaction pays a fee to the system, but unlike Bitcoin, this fee is distributed, with 40% to the leader and 60% to the subsequent leader.

• Finally, if a leader forks the chain by generating two microblocks with the same parent, it is punished by revoking the subsidy revenue; whoever detects the fraud wins a nominal fee.

Beyond the blockchain functionality and its underlying protocols, the Waves ecosystem offers a diverse collection of tools, products, and components to streamline the process of building and running dApps. The tools are developed both by the Waves team and the developer community.

As we mentioned, Waves Protocol is a layer-1 platform that executes smart contracts and dApps. This is the exact functionality of the Ethereum blockchain, the biggest layer-1 platform. Ethereum is the oldest platform that went online in 2015. Not long after that, in 2016, Waves Labs began to work on the Waves Protocol. But it is obvious that Waves Protocol could not get much attention, and its market cap is so less than Ethereum’s that they are incommensurable.

After all, Waves is trying to become the next Ethereum. Whether it is able to do such a thing or not, the wish to become the next Ethereum necessitates us to compare these two.

I have been talking about Waves Protocol for a long time. But, as it is obvious, none of what we saw was associated with “Layer-0 Platforms.” Then why did I introduce L0 and insist on Waves being both L0 and L1? Well, the answer is in the next section.

Waves Enterprise is a combination of private and public networks that ensures high throughput, scalability, and reliability of solutions, as well as data immutability and confidentiality. Waves Enterprise provides consulting, deployment, and support services.

Waves Enterprise consists of 4 layers:

• Business application layer: The platform’s client is located on this level, facilitating access rights management, executing transactions of all kinds, and tracking network activity. This layer also hosts client applications that use the blockchain for business process automation, sending and receiving distributed ledger data.

• Middleware layer: This layer features integration adapters for accessing data, as well as tools for integrating the platform into a company’s existing IT landscape. The authorization service restricts access to integration services’ data and facilitates the use of existing login data management services for interaction with the blockchain. The data service provides processed data from the blockchain in a relational form that is more familiar to most developers.

• Blockchain layer: The main tools ensuring consistency and immutability of distributed ledger data operate on this layer. Data transferred between nodes undergo preliminary validation. Then, based on a node’s current role (whether it generates blocks), it either creates a block from received data, signs it with a cryptographic module and its keys, or adds validated data to the state. A node’s current role is determined by the consensus algorithm. Two interfaces are available under the push/pull model for external access to the blockchain: GRPC and Rest API.

• Network layer: On the network layer, nodes exchange data under the TCP protocol after establishing a signed handshake that validates a node’s right to join the network. Data is transferred as a byte sequence. Nodes exchange data on transactions, blocks, microblocks, other network participants’ known addresses, and other service information. On this layer, nodes also exchange private data over encrypted TLS-like p2p connections.

These layers give the opportunity to have many blockchains, private or public, connected. These blockchains can have different consensus mechanisms, sets of nodes, maintaining algorithms, and even functionalities.

Let’s take a look at the platform and its architecture.

The Waves Enterprise platform is based on distributed ledger technology and built as a fractal network that consists of two elements:

• Master blockchain (Waves Enterprise Mainnet), which provides functioning of the overall network and acts as a global moderator for the basic network, as well as for many user networks;

• individual sidechains created for definite business tasks.

Interaction between the master blockchain and sidechains is provided by the anchoring mechanism, which broadcasts cryptographic proofs of the transaction into the basic blockchain network. The anchoring mechanism allows one to freely configure sidechains and use any consensus algorithm without losing connection with the master blockchain. For instance, the Waves Enterprise master blockchain is based on the Proof-of-Stake consensus algorithm because it is supported by independent participants. At the same time, corporate sidechains that do not have to stimulate miners with transaction fees can use the Proof-of-Authority or Crash-Fault-Tolerance algorithms.

This two-part arrangement allows optimizing the network for high processing loads, increases information transmission rate, as well as to enhance concurrence and availability of data. Usage of the anchoring mechanism increases trust in data in sidechains because they are validated in the master blockchain.

Each blockchain node is an independent network participant who has the software required to work with the network. Every node consists of the following components:

• Consensus services and cryptolibraries: components responsible for achieving consensus between nodes and cryptographic algorithms.

• Node API: gRPC and REST API interfaces of the node that allow to receive data from the blockchain, sign and broadcast transactions, send confidential data, create and call smart contracts, etc.

• Unconfirmed transaction pool (UTX pool): the component providing storage of unconfirmed transactions before their validation and broadcasting into the blockchain.

• Miner: the component responsible for creating transaction blocks for adding to the blockchain, as well as for interaction with smart contracts.

• Key store: storage for key pairs of a node and users. All the keys are protected with a password.

• Network layer: the logic layer that provides interaction of nodes at the applied level via the network protocol over the TCP.

• Node storage: the system component based on RocksDB that provides storage of ‘key-value’ pairs for the entire set of confirmed transactions and blocks, as well as for the current blockchain state.

• Validation logic: the logic layer containing transaction validation rules, for instance, basic signature check and advanced check according to the script.

• Configuration: node configuration parameters that are set in the node-name.conf file.

Installation of auxiliary services is not required, but they alleviate the interaction of users with the blockchain network. Apart from ready-made services and depending on tasks, integration adapters can be developed for the transit of transactions from client applications into the blockchain network, as well as for data exchange between a node and the applied services of a customer.

Scheme of node and auxiliary services arrangement:

In a private blockchain, transactions are processed by a definite list of participants, and each participant is familiar with the network in advance. Compared with the public network, private blockchains contain fewer participants, blocks, and transactions, which can cause a threat of information replacement. This situation, in turn, creates a risk of blockchain override, especially in case the PoS consensus algorithm is used–because this algorithm is not protected from such occurrences.

In order to increase the trust of private blockchain participants in the data broadcasted in it, the anchoring mechanism has been developed. Anchoring allows checking the consistency of data. Consistency of data is guaranteed through broadcasting data from a private blockchain into a larger network, where data replacement is less possible because of a larger number of participants and blocks. Block signatures and blockchain height are published from the private network. The mutual connectivity of two or more networks increases their resilience since all connected networks must be attacked to forge or change data due to a long-range attack.

Anchoring steps are:

1. Anchoring configuration is performed in the private blockchain configuration file (set the corresponding parameters in accordance with the recommendations listed in the article in order to exclude complexities while working with anchoring);

2. After each configured number of block’s height-range, the node saves information about the block at the (current-height, threshold) in the form of a transaction into the Targetnet. To do this, Data Transaction 12 containing the ‘key-value’ pairs is used;

3. After the transaction broadcast, the node receives its height in the Targetnet;

4. The node checks the Targetnet blockchain every 30 seconds until the height achieves the value height of a created transaction + height-above.

5. Upon achieving this Targetnet blockchain height and acknowledgement of the presence of the first transaction in the blockchain, the node in the Targetnet creates a second transaction with data for anchoring in the private blockchain.

Snapshooting is an auxiliary mechanism of the blockchain platform that allows saving the data of the working blockchain for a subsequent change of network configuration and starting the network with the saved data.

The snapshooting mechanism allows changing the blockchain configuration parameters without any loss of its data. The process of changing the network configuration parameters with the use of a snapshot is called migration.

• A snapshot includes the following data:

• states of network addresses: balances, permissions, keys;

• states of smart contracts created in the network: data received as a result of smart contract calls and attached to them with the use of 105 transactions (this is a technique of writing the result of a smart contract execution to its state);

• data of miners of the previous rounds;

• information of confidential data access groups.

A snapshot does not include the history of transactions, bans, and network blocks.

In the migration process, a snapshot becomes an initial state of the blockchain network with new parameters. The network itself is restarted with the generation of the new genesis block.

A smart contract is a separate application that saves its entry data in the blockchain, as well as the output results of its algorithm. The Waves Enterprise blockchain platform supports the development and usage of Turing complete smart contracts to create high-level business applications.

Smart contracts can be developed in any programming language and do not have any restrictions for their internal logic. In order to split the startup and performance of a smart contract and the blockchain platform itself, smart contracts start and work in Docker containers.

When a smart contract starts in a blockchain network, nobody can change, spoof, or restrict its operation without interfering with the entire network. This aspect allows for providing security for business applications.

Blockchain is a distributed system that does not have a unified process regulator. Decentralization prevents corruption inside the system but complicates decision-making and organization of an overall workflow.

These problems are resolved by the consensus–an algorithm that coordinates the work of the blockchain participants utilizing a certain voting method. Voting in the blockchain is always performed in support of the majority: minority interests are not taken into account, and decisions that have been made become mandatory for all network participants. Anyway, voting guarantees the achievement of a consensus that will be profitable for the entire network.

The Waves Enterprise blockchain platform supports three consensus algorithms:

• LPoS consensus algorithm

• PoA consensus algorithm

• CFT consensus algorithm

The Waves Enterprise Mainnet uses the Leased Proof of Stake (LPoS) consensus algorithm for internal decision-making. To support this, the WEST technical token has been developed, which serves as a proof of the right to mining, as well as a financial motivation for the participants.

Sidechains and private networks based on the Waves Enterprise blockchain platform can use any of three supported consensus algorithms, depending on the needs of a certain project. A private network consensus algorithm is configured in the node configuration file.

I already talked about the LPoS consensus algorithm. I will explain PoA and CFT consensus algorithms in the next two parts.

Proof-of-Authority (PoA) Consensus Algorithm

In a private blockchain, tokens are not always needed. For example, a blockchain can store hashes of documents exchanged by organizations. In this case, a solution based on the PoS consensus algorithm is redundant in the absence of tokens and fees from transactions. The Waves Enterprise Blockchain Platform offers the option of a Proof of Authority (PoA) consensus algorithm. Mining permission is issued centrally in the PoA algorithm, which simplifies the decision-making compared to the PoS algorithm. The PoA model is based on a limited number of block validators, which makes it scalable. Blocks and transactions are verified by pre-approved participants, who act as system moderators.

In PoA, rights to generate new blocks are awarded to nodes that have proven their authority. These nodes are called “Validators,” and they run software allowing them to put transactions in blocks. The process is automated and does not require validators to monitor their computers constantly, but it does require uncompromising the computer. PoA is suited for both private and public networks, like POA Networks, where trust is distributed.

PoA consensus algorithm leverages the value of identities, meaning that block validators are not always staking coins but their own reputation instead. PoA is secured by the trust in the identities selected.

Crash Fault Tolerance (CFT) Consensus Algorithm

Coherence among the network elements that form a single blockchain is important when exchanging information extensively in a corporate blockchain. And the more participants are engaged in the exchange, the more likely an error will occur: a hardware failure by one of the participants, network problems, and so on. This can lead to forks of the main blockchain and, consequently, the rollback of a block that seems to be already formed and included in the blockchain. In this case, the blocks subject to the rollback begin to be mined again and become unavailable in the blockchain for some time. This, in turn, can affect the business processes that use the blockchain. The Crash Fault Tolerance (CFT) consensus algorithm is designed to prevent such situations.

The CFT consensus algorithm is based on the PoA with an added phase for voting of mining round validators: network participants that are automatically appointed by the consensus algorithm. This approach guarantees the following:

• more than half of the participants (validators) are familiar with a definite block and have validated it;

• the block will not be rollbacked and will be published in the blockchain;

• there will be no parallel chain in the network.

This is achieved by the finalization of a produced block. The finalization itself is based on the consensus of a majority of round validators (50% + 1 vote). In accordance with this consensus, the decision to block broadcasting is taken. If this majority is not achieved, mining will be stopped until the network cohesion is restored.

Like the PoA, the CFT algorithm depends on the current time; starting and ending time of each mining round is calculated based on a genesis block timestamp. Basic parameters that form an algorithm that is used for the appointment of a current block miner are also identical to the PoA parameters.

Waves’ new blockchain-agnostic solution is a major step towards interoperability between different blockchains.

Gravity Hub, presented at Waves Community Meetup in Berlin on 11 December 2019, aims to unite all existing blockchains and dApps, resolving the interoperability issue. It will also operate as a data oracle, feeding data from the outside world to the blockchain.

Gravity Hub is essentially a blockchain that doesn’t have any tokens but can communicate with other blockchains, such as Waves Platform, Waves Enterprise, or Ethereum.

The use of the word “gravity” is by no means random, as the solution will have properties similar to those of gravity: it will attract and connect various blockchains.

So far, the inability to transfer data from one blockchain to another has been a major hindrance to the development of the blockchain space. This solution has the potential to take blockchain technology to a new level by facilitating free and unfettered communication between any existing blockchains.

Gravity Hub will assume interoperability at the protocol level, as well as at the decentralized applications level, allowing a dApp to send a request to another dApp on a different blockchain.

Gravity Hub’s nodes will be able, for instance, to obtain block headers from the Ethereum network and send them to the Waves Platform. If Ethereum block header data is available on the Waves Platform, it will be possible to prove that a specific transaction has occurred on Ethereum. To obtain that data, users will pay reasonable fees.

For sending tokens between blockchains, token ports will be used, which will also use data from Gravity Hub.

Gravity Hub will also be connected to custom chains, which represent a new approach to blockchain customization. Waves Matter, our blockchain engine, can be assembled in any configuration for different purposes.

As nodes will be split into the main core and several mandatory and optional plug-ins, users will be able to choose smart contract languages, consensus algorithm modules, cryptography types, and other functionality for their custom chains.

In addition to providing an interoperability protocol, Gravity Hub will help resolve the issue of obtaining information from the outside world, as it will facilitate access of all connected chains to data from outside the blockchain.

A member of any network connected to Gravity Hub will be able to request oracle data from any information systems that have APIs—from Google to enterprise ERP systems.

All Gravity Hub nodes will have “data watchers”—modules for collecting various types of data, such as block headers and block height from other blockchains, exchange rates, etc.

For each data watcher, a data profile will be set. For instance, if a data watcher collects Ethereum block header data, this will need to be done with a certain frequency and reliability.

How can we make sure that the data provided by Gravity Hub is accurate? That can be achieved by consensus between several nodes.

To that end, at least several nodes collect data of the same type, which is written to the Gravity Hub blockchain as “raw data.” Once consensus has been reached, “consensus data” is also written to the blockchain and can be sent to a user who has requested it. There are various options for sending consensus data to the user.

One option is a multi-signature solution, whereby a transaction containing the consensus data must be signed by all nodes.

Alternatively, any node could be allowed to send consensus data to the user, but in that case, the node’s stake will act as collateral. If, for instance, a node sends data to the target blockchain that is different from the ultimate consensus data, proof of that can be sent to a smart contract, which will automatically deduct part of the node’s stake as a fine.

A user will be able to request a certain type of data over a specific time period for a fee consisting of execution costs and the node’s fee. Also, the user will be able to set up preferences. For example, when requesting exchange rate data, the user can set the maximum variability required.

The Waves protocol uses state-of-the-art cryptographic algorithms to ensure assets’ secure transfer and storage. The platform supports the Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signatures and SHA-256 for hashing. These algorithms have been thoroughly tested and are widely considered to be secure.

In addition, the Waves team also conducts regular security audits and implements best practices to ensure the platform’s security. This includes regular software updates and patches to address any vulnerabilities or security flaws that may arise.

Waves protocol has been audited by multiple third-party security firms. However, the specific results of those audits are not publicly disclosed by Waves or the auditing firms. It is common for security audit results to be considered confidential and not publicly shared in order to protect the security of the platform and its users. Nevertheless, it is known that the Waves protocol regularly undergoes security audits and that the results have been positive, indicating the platform’s commitment to security and protecting its users’ assets.

The Waves platform underwent a security audit performed by Kudelski Security, a well-established company with a solid track record. The purpose of the audit was to uncover security shortcomings in the Waves platform and improve its security. The audit, which took 50 hours of work, was led by Dr. Jean-Philippe Aumasson, a Principal Research Engineer at Kudelski Security. The audit results showed no critical security issues in the Waves platform, and the auditors praised the platform’s good security engineering, choice of cryptographic components, and clear design and code that facilitated auditing. As they mentioned in their published audit:

“We did not find any critical security issues but reported four medium-severity issues and six low-severity issues, which can all be easily fixed. The Waves platform otherwise shows good security engineering, good choice of cryptographic components with reliable implementations thereof, and has a clear design and code that facilitate auditing.”

Waves CEO Alexander Ivanov was pleased with the audit’s outcome and said that a clean bill of health from Kudelski was a testament to the hard work of the developers. The Waves platform will continue to undergo additional security audits as more functionality is added.

Waves Enterprise’s voting service provider underwent security testing by an external company, Deteact, back in 2020. The main goal of the testing was to ensure the service’s protection from vulnerabilities that could compromise confidential user data or interfere with the voting process. Deteact, a relatively new company specializing in security audits (back in those days), was chosen as the testing partner due to a previous successful collaboration with Waves Enterprise.

The security tests covered various aspects of the voting service, including the client app, smart contract logic, voting process, and infrastructure. The testing process took around three weeks and discovered several vulnerabilities in the classic web interface, specifically in the user registration and data storage parts. The two most critical vulnerabilities found were the risk of personal user data leakage and cross-site scripting, which could allow an attacker to perform actions in the app under a user’s name.

Other vulnerabilities discovered were:

• An attacker’s ability to make changes to a voting invitation.

• The potential to add the same voter multiple times.

• A vulnerability that could leave the service open to a DDOS attack.

Once the vulnerabilities were uncovered, they were addressed by the service’s developers and re-checked by the testing team.

Waves Enterprise’s interaction with Deteact was productive, with Deteact’s CEO, Omar Ganiev, commenting on the smoothness of the collaboration. Waves Enterprise values the security of its solutions, and the tests run by Deteact have helped make the voting service even more reliable and protected from outside interference. The company is satisfied with its collaboration with Deteact and plans to use its services in the future.

In conclusion, the security testing of Waves Enterprise’s voting service successfully ensured the protection of confidential user data and the integrity of the voting process. The testing process uncovered and addressed several vulnerabilities, and the collaboration with Deteact was productive and successful.

Founder and CEO

Sasha Ivanov is a physicist and mathematician who is best known as the founder of Waves Protocol. This blockchain platform enables users to create custom digital assets, launch ICOs, and trade tokens. Before founding Waves, Ivanov worked as a software engineer and IT consultant. He has a background in physics and mathematics, having studied at St. Petersburg State University in Russia.

Ivanov founded Waves in 2016, intending to make blockchain technology accessible to a wider audience. Under his leadership, Waves has become one of the largest blockchain platforms, with a growing ecosystem of developers, users, and businesses. Sasha Ivanov has been recognized for his contributions to the blockchain industry and is known for his innovative approach to solving complex problems.

Head at Waves Camp

Ekin Tuna is the Head of Waves Camp, a blockchain incubator and accelerator program that provides support and resources to early-stage blockchain projects. Tuna is a seasoned entrepreneur with a background in finance and business development. He has extensive experience in the blockchain and cryptocurrency industry and has worked with several startups in the space.

Under Tuna’s leadership, Waves Camp has become one of the leading programs for supporting and scaling early-stage blockchain projects. The program provides mentorship, resources, and funding to help startups grow and succeed in the competitive blockchain market. Tuna is known for his deep understanding of the industry and ability to identify and support promising projects.

Waves Protocol and Allbridge, a token bridge protocol, partnered to integrate Waves with all of Allbridge’s 15 supported blockchains, including Solana, BNB Smart Chain, and Ethereum. The integration launched on 22 September with an incentivized multi-asset pools campaign on the Waves-based AMM platform, Swop.Fi. The partnership aims to increase access to Waves-based projects for investors seeking larger returns on their stable assets. Allbridge is a bridging protocol with over $6 billion in asset transfers and over $74 million in Total Value Locked. Waves, launched in 2016, is a global open-source platform for decentralized applications based on proof-of-stake consensus and aims to maximize blockchain benefits with a minimal carbon footprint. Allbridge is a tool to transfer assets freely between different blockchains.

As we mentioned earlier, Waves Protocol is a competitor to Ethereum, BNB Smart Chain, Solana, and other layer-1 platforms. At the time of writing this article, Waves Protocol is behind many of the other layer-1 platforms in the market cap.

It seems that Waves Protocol is not very better than these other platforms in terms of technical or economic aspects. This can cause Waves Protocol never reaches the market cap of the other great layer-1 platforms. If they decide to change some technical and economic means, they might become bigger in the future.

Waves Enterprise is a competitor to big L0 platforms. These layer-0 platforms consist of Polkadot, Cosmos, and Horizen. The most important difference between Waves Enterprise and the other L0 platforms is that Waves Enterprise is mostly for enterprises and can handle public and private blockchains with different levels of permission. But, the other layer-0 platforms can only handle public blockchains.

The other difference is in their technology. Polkadot is much better designed in terms of the economy of the token. Cosmos is much more popular among projects to use.

In conclusion, if Waves Enterprise doesn’t redesign the technology and economy of its native token, there is a high probability that it won’t be big enough to compete with these big layer-0 platforms.

The Waves blockchain started 2022 with more than 2 million user wallets and a vibrant community across successful projects such as Waves.Exchange, Vires.Finance, and WavesDucks.com. With 100k+ transactions in the mainnet daily and more than 250 validators, Waves boasts a throughput of thousands of transactions per second. The current Total Value Locked (TVL) in the network is $2B, and about 80% of tokens are locked in staking. These have been achieved without VC funding in the last five years.

Waves Protocol is going from version 1.0 to version 2.0. Some key points regarding this transformation are:

1. Waves 2.0: New Consensus with Ethereum Virtual Machine Support

2. Open Collective. New governance models

   1. DAO Framework

3. Cross-chain finance: Bridge to all chains

   1. Gravity Bridges

   2. Universal Bridge Integration

4. Meta: A bridge between digital worlds

   1. Level 0 Inter-Metaverse Protocol

5. US Company and Accelerator Program

   1. US Company

   2. Accelerator Program

6. Projected Timeline

7. (1 ➝ 2) – Join The Movement

For Waves Enterprise, 2022 brought several fundamental changes, which will bear fruit next year. Here are the most important ones:

• Waves Enterprise has moved to the enterprise DAO governance model, including the community and the Governing Council.

• They designed a new tokenomics based on WEST/LWEST/GWEST triad to be launched in the first half of 2023. It will bring new opportunities to all Waves Enterprise users.

• The community already approved several third-party projects to enter the Waves Enterprise ecosystem—SwapWave decentralized AMM and Syndex tokenizing protocol. With the launch of the new tokenomics, the votings in 2023 will be based on new tokens.

• This year, the Waves Enterprise team became as global as never before. It moved beyond the UAE and Singapore. The new legal entity was established in the USA and aimed to bring more enterprise customers to Waves Enterprise’s tech stack. We expect to get public cases in North America next year and make the Waves Enterprise case folio truly global.

• EAST protocol launched staking with tasty APRs!

• They plan to continue onboarding new projects within the ecosystem; the current SwapWave and Syndex start a long journey here.

All these global changes are forming the next phase of the Waves Enterprise ecosystem, which is expected to be thrilling. And here are just a few things from the list that we plan to do in Q1, 2023:

• LWEST/GWEST will finally set off, or at least they will share the exact launch date in H1, 2023.

• More important and regularly, all the DAO initiatives will be brought to life via community voting.

• Deeper integration into the Waves ecosystem: WEST became part of WINDX, participating in the recently launched Waves ambassador program and other co-op things.

• The first of the new mainnet projects will be launched in February—a protocol for tokenizing real-world assets.

• The USA integrator will be officially introduced to the market.

Also, there is a roadmap in the WEST 2.0 whitepaper, which you can see in the image below.

WAVES is the native token of the Waves blockchain. Block generators receive transaction fees and block rewards in WAVES, which encourages generators to maintain and develop the blockchain network infrastructure. The more WAVES the generator holds (by ownership or lease), the greater its chance to add the next block is.

WAVES has been present on the blockchain since inception; there is no issue transaction for it. Therefore the WAVES token does not have an ID. The REST API uses null for WAVES.

The owner of WAVES can lease them via a Lease transaction. WAVES received on lease are included in the generating balance. Block generators send back different percentages as rewards to lessors. A lessor can cancel the lease anytime via a Lease Cancel transaction.

The number of decimal places (decimals) for WAVES is 8. The atomic unit called WAVELET is 1/100,000,000 WAVES.

During its initial coin offering in April 2016, 100 million tokens were launched, raising over $16 million. The fund was brought Waves Protocol, nearly 30,000 BTC, at the time of ICO.

15 million tokens are reserved for bounties and the development team in the following proportions:

• 1 million tokens are distributed to early supporters.

• 1 million tokens are reserved for post-ICO bounties.

• 4 million tokens are reserved for strategic partners and backers

• 9 million tokens are withheld by the development team.

The remaining 85 million tokens have been distributed in the lCO procedure to participating users based on their contribution to the total amount of the raised funds.

Block Rewards

Block Reward is a blockchain feature under which generating nodes receive a fixed fee in WAVES for each generated block. Block rewards are paid due to the additional issue of the WAVES token. The community of generating nodes can change the reward size through voting.

Every 100,000 blocks, i.e., approximately every 70 days, a new voting for the current reward size change begins among the generators. The voting duration is 10,000 blocks. During this time, generating nodes vote to increase, decrease, or leave the current reward size unchanged. The elected reward size remains unchanged for 100,000 blocks following the end of voting.

A generating node specifies the new desired reward size using the waves.rewards.desired setting in the node configuration file; the setting value is specified in WAVELETs.

If the value is greater than the current reward size, then the generator votes for the current reward size increase; if the value is smaller—for the decrease. If the setting value is not specified in the configuration file, then the generator votes for keeping the current reward size.

When a node generates a block, it writes the value of the waves.rewards into that block.desired setting from its own configuration file. If the setting value is not specified in the configuration file, then -1 is written to the block.

During the voting time in 10,000 blocks, a single node can generate several blocks; therefore, one node can vote several times. How often a node generates blocks is determined by the LPoS consensus.

Waves Enterprise uses WEST (Waves Enterprise System Token) as a basic asset, a utility token for all operations in the mainnet, as well as in hybrid sidechains.

As of June 2022, a total sum of 400 million WEST is emitted within the mainnet. 175 million WEST remains locked on a smart contract till 2023 under Tokenomika control. Then 100 million of the whole sum will be transferred to the DAO treasury. The other part of the Tokenomika treasury, 75 million WEST, is allocated to company investors; it will remain locked on a smart contract till 2024 and potentially afterward. 160 million WEST, along with another 25 million WEST in possession of the team, will also go directly to the DAO treasury, making it the biggest WEST holder on the market.

They are planning for a large share of the total WEST used by the Governing Council towards ecosystem development, including grants and marketing. The table below shows the perfect distribution of the total 400 million WEST supply from the WE DAO perspective.

LWEST token serves as a reward for WEST leasing within the Waves Enterprise ecosystem–this opportunity is provided by the mainnet consensus, LPoS. Leasing WEST boosts the overall liquidity of the tokenomics.

GWEST tokens fuel the Waves Enterprise DAO. GWEST works as a proof of interest in the long-term development of the platform. One can get GWEST due to staking LWEST for six months or more at the staking service.

Until June 2027, Waves Enterprise plans to distribute 60 million WEST as an airdrop to GWEST holders. This distribution will decrease over time; early birds will catch the biggest worms, as shown in the image below.

The Waves Protocol is a secure blockchain platform for transferring and storing assets, designed to provide high-quality security and scalability. The Waves team is led by founder and CEO Sasha Ivanov, who has a physics, mathematics, and software engineering background. The team has implemented several security measures, including regular security audits, best practices, and positive results from past security audits. The platform utilizes state-of-the-art cryptographic algorithms, such as ECDSA and SHA-256, to provide a secure environment for the transfer and storage of assets.

Waves Enterprise is a platform that consists of a master blockchain (Waves Enterprise Mainnet) and individual sidechains. The master blockchain serves as a global moderator and provides a proof-of-stake consensus algorithm, while the sidechains can use other consensus algorithms. The anchoring mechanism allows the sidechains to interact with the master blockchain, maintain trust in data, and prevent the risk of information replacement in private blockchains. The platform includes nodes and auxiliary services arranged in a scheme to help interact with the blockchain network.

Gravity Hub is a blockchain-agnostic solution to resolve the blockchain space’s interoperability issue by unifying all existing blockchains and dApps. It operates as a data oracle, feeding data from the outside world to the blockchain, and has the potential to take blockchain technology to a new level by enabling free and seamless communication between different blockchains. The solution will assume interoperability at the protocol and decentralized application levels, allowing dApps to send requests to other dApps on different blockchains. The accuracy of the data provided by Gravity Hub will be achieved through consensus among several nodes.

Overall, the Waves Protocol can become a promising player in the blockchain space, offering scalability, security, and interoperability solutions to businesses and individuals alike. It’s worth noticing that this is a matter of time and progress in technology and the economy.

• Begicheva, Antonina, and Alexy Kofman. “Fair Block Delay Distribution In Proof-of-Stake.” Waves Community Forum, https://forum.waves.tech/uploads/default/original/2X/7/7397a4cb5fa77d659a7b7ecc9188dd0a4fe0decc.pdf. Accessed 28 January 2023.

• Buterin, Vitalik. “Ethereum Whitepaper | ethereum.org.” Ethereum.org, https://ethereum.org/en/whitepaper/. Accessed 27 January 2023. Coin Bureau. “What's Up With WAVES?? My Deep Dive!!” YouTube, 16 September 2020, https://www.youtube.com/watch?v=-AtXH2j4eF8. Accessed 24 January 2023.

• Cosmos. “What is IBC? | Developer Portal.” Cosmos Developer Portal, https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html. Accessed 27 January 2023.

• Crunchbase. “Sasha Ivanov - Founder @ Waves Platform.” Crunchbase, https://www.crunchbase.com/person/sasha-ivanov. Accessed 30 January 2023. Crypto Square. “☕️.” YouTube, 10 August 2022, https://www.youtube.com/watch?v=nrAyYTHHlVE. Accessed 24 January 2023.

Many layer-1 platforms exist out there. A layer-1 platform, in the blockchain world, is a blockchain able to perform smart contracts and dApps, without any dependency on any other blockchains. Actually, Waves is and is not one of these.

This may sound confusing to you. How can a blockchain be both a layer-1 platform and not? Well, the answer is complex, and to get to the answer, it is best first to know what layer-0 is.

Blockchains Layer-0 blockchain is a concept that Cosmos Network introduced to the world. Before this concept, all the blockchains could execute an app or a smart contract. These types of blockchains were named layer-1s. As the demand for dApps increases and more capital flows into the space to support development, we are beginning to see the growing pains of layer-1 networks as they struggle to meet the needs of developers and end users who have opposing views on whether dapps should prioritize scalability, security or decentralization.

Layer-1 networks are built with a monolithic architecture. This means that the execution, consensus, and data availability layers function within a single blockchain network. This stacked design strains the system and results in the need for blockchains to comprise decentralization for security or scalability for decentralization.

In addition, the lack of control over the underlying infrastructure that dApp developers build on top of has also been a cause of much frustration. Rising gas fees on the Ethereum network make all Ethereum dapps too expensive to use, while unexpected downtime on the Solana network similarly makes all dapps on Solana also go offline.

Dapp developers must also make compromises in how they design their dapps in order to remain compatible with these L1 networks, and they lack the ability to explore different consensus mechanisms or to experiment freely with token incentive models because consensus is a primary function of the L1 infrastructure layer. The over-dependence on L1s and difficult tradeoffs imposed by the scalability trilemma can only be remedied by creating a new base infrastructure that empowers developers to launch their own independent blockchains that can be optimized for different aspects of the scalability trilemma.

This base infrastructure is called layer-0, the single most important component for helping blockchains and decentralized applications achieve limitless scalability while maintaining the highest possible levels of decentralization and censorship resistance.

As Vitalik Buterin, co-founder of the Ethereum blockchain, stated: “there are three properties that a blockchain tries to have, and that if you stick to “simple” techniques, you can only get two of those three.” These three properties are:

• Scalability: The blockchain needs to process more transactions per second as the number of users soars. This must be so that the transaction fee does not increase dramatically.

• Decentralization: The blockchain must run without the need for trust. Meaning that no centralized authority is in charge of creating and submitting transactions, and a decentralized network is in charge of such work. This way, the need for trust in one centralized authority is diminished.

• Security: The blockchain must be resistant to the attack of a large number of peers, ideally 50%. Because this attack can risk the security of people’s funds since a double-spending attack would be enabled.

Now, let us take a look at three classes of “easy solutions,” as Vitalik proposed:

• Traditional blockchains: including Bitcoin, pre-PoS/sharding Ethereum, Litecoin, and other similar chains. These rely on every participant running a full node that verifies every transaction; hence they have decentralization and security but not scalability.

• High-TPS chains: including the DPoS family, but also many others. These rely on a small number of nodes (often 10-100) maintaining consensus among themselves, with users having to trust a majority of these nodes. This is scalable and secure (using the definitions above), but it is not decentralized.

• Multi-chain ecosystems: this refers to the general concept of “scaling out” by having different applications live on different chains and using cross-chain-communication protocols to talk between them. This is decentralized and scalable, but it is not secure because an attacker needs only to get a consensus node majority in one of the many chains (so often <1% of the whole ecosystem) to break that chain and possibly cause ripple effects that cause great damage to applications in other chains.

A layer-0 protocol enables developers to launch multiple layer-1 (L1) blockchains that can be designed to each serve a specific purpose and cater to 1 or 2 dimensions of the scalability trilemma as opposed to all 3.

These L1 networks can also be made to communicate with each other such that the end user can have the experience of using one blockchain while they are, in fact, using multiple.

Layer-0 (L0) networks are equipped with Software Development tool Kits or SDKs that allow developers to launch their own blockchains, known as L1s or sidechains, connected to the L0 mainchain but operating independently.

Layer-0 networks solve three critical problems for web3 development and adoption: Scalability, flexibility, and interoperability.

• Scalability: We have already introduced the scalability trilemma. As we mentioned before, to achieve full decentralization, one must sacrifice scalability. And to achieve a good level of scalability, one must sacrifice decentralization or security. But, this is especially true on a monolithic blockchain, like layer-1 blockchains, where all the critical functions like transaction execution, consensus, and data availability (the ability to verify that all the data from new blocks has been published) are managed by a single network, increasing the likelihood of congestion and making it much more difficult to scale.

  A workaround to the scalability trilemma is to delegate the primary responsibility for these three functions to different independent blockchains. This design ensures that the execution chain can be optimized for handling high TPS dapps like a DEX or play-to-earn game without worrying about decentralization. A second chain can then be optimized for decentralization and serve as a final consensus layer for the execution chain to enable withdrawals and anchor its data.

  When it comes to scalability, layer-0 networks can help blockchain scale by increasing transaction throughput. While transaction speed is typically measured in terms of TPS (transactions per second), transaction throughput looks at the total number of transactions a network can handle simultaneously.

• Flexibility: What makes an independent blockchain truly independent is having its own set of validator nodes to confirm transactions and produce blocks based on its own consensus mechanism.

  As a developer, the ability to develop your own blockchain from scratch means that you can:

  • Design your token issuance model—inflationary or deflationary

  • Optimize your chain for speed, decentralization, or security

  • Make your network private and permissioned or public and permissionless

  • Curate the type of dapps you want to be built on your network and foster your own developer ecosystem.

  What’s more, thanks to the SDKs of L0 protocols, the time and complexity of launching a blockchain on an L0 network can be compared to launching a Dapp on an L1, which means you can build and manage multiple L1s with relatively little effort.

• Interoperability: Interoperability is the ability of computer systems with different programs to interpret and exchange information with each other with minimal friction. The perfect analogy for understanding the importance of interoperability in the blockchain space is to think about blockchains as large cities that need to be connected via bridges in order for economic activity to flow in and out.

The three main components of a layer-0 protocol are:

• The Main Chain: This typically serves as the primary blockchain where transaction data from the various L1 chains are backed up.

• Sidechains: Independent layer-1 blockchains that have their own set of validator nodes and can run their own consensus mechanism. These chains do not rely on the mainchain for security but will often share the security of the mainchain since it is typically the largest and most decentralized.

  • Sharing security can occur in different ways. For example, a user may be required to stake the L0’s token in order to become a validator on an L1, which means they can lose both their L0 stake and their L1 stake if they attempt to submit fraudulent transactions.

  • In other cases, L1s will periodically share their network state, the latest record of account balances and transaction history, with the L0 in order to keep a backup in a more secure network in case the L1’s records are ever compromised.

• Cross-chain transfer protocol: The mechanism that enables tokens and other forms of data to be transferred between chains in a trustless and secure manner.

Different types of L0 architecture exist. Horizen explains its architecture in a more linear way than others. The main blockchain (L0 one) is a linear blockchain with no over-complex structure that sidechains (L1 ones) have a connection to it. The sidechains are linear and non-complex blockchains. These chains together build the Horizen network, since they are connected through the mainchain and can interpret and exchange data.

Cosmos has a main blockchain, and using a Hub with the help of the Inter-Blockchain Communication protocol (IBC) creates the communication of its Zones (L1 blockchains). Cosmos believes its structure is not linear and is a bit more complex than the Horizen network.

On the other hand, Polkadot has the most complex structure among the three. They have a Relaychain, which plays the role of the main blockchain. This Relaychain gives some spaces to other L1 blockchains, named Parachain. The Parachains can communicate with the Relaychain and each other through the Relaychain.

You can see the structure of each L0 blockchain above in the images below.

Now that we know what a layer-0 blockchain is, we can continue to understand the two biggest products of Waves Labs:

• Waves Protocol

• Waves Enterprise

Waves Protocol is a community-based stack of decentralized open-source technologies to build scalable, user-friendly apps. What does it even mean?

Launched in 2016, Waves Protocol is a global open-source platform for decentralized applications. Based on proof-of-stake consensus, Waves aspires to make the most of blockchain with a minimal carbon footprint.

Waves technology stack can benefit any use cases that demand security and decentralization—open finance, personal identification, gaming, sensitive data, and many others.

In other words, Waves Protocol is a layer-1 blockchain that can execute smart contracts and dApps, easily and fast, with almost no fee. This helps it be one of the fastest and cheapest layer-1 blockchains.

According to them, Waves Protocol is:

• Simple: Waves enables a world of NFTs, DAOs, and other new business models;

• Scalable: Waves delivers extremely fast experiences with extremely low costs; Eco-

• Friendly: Waves aspires to make the most of blockchain with a minimal carbon footprint;

• Open: Waves bridges to other ecosystems for easy interoperability.

So, let’s see what Waves Protocol brings to the table for the world and how it does it.

A token is a digital asset on the blockchain. A token can be used:

• as a cryptocurrency to pay for goods and services within a project, as well as for crowdfunding;

• as an object or resource in games, etc.

A token can represent a physical or an intangible object. The words “token” and “asset” are used interchangeably in the Waves ecosystem.

Other than WAVES (Waves blockchain native token), all tokens are custom tokens issued on behalf of some account. Any account with enough WAVES to pay a fee can issue its own token. The new token is immediately available:

• for transfers between accounts,

• for trading on the WX.Network exchange developed by the third-party team from the community (except for NFTs; smart assets trading is temporarily unavailable),

• for payments attached to the dApp script invocation.

You can use your tokens:

• as a digital currency – to pay for goods and services in your project or for crowdfunding,

• as in-game objects or arbitrary resources, and so on.

One of the key benefits of the Waves blockchain is the simplicity of issuing tokens. To launch your own token, you don’t have to write a smart contract – just create an Issue transaction and send it to the blockchain. The only threshold for the issuer is to pay a fee: 1 WAVES for a regular token (asset) or 0.001 for a non-fungible token (NFT).

To issue a token, one has to create an Issue transaction within the token parameters:

• name

• description

• decimals

• quantity

• reissuable

• script (for issuing a smart asset).

Also, a token issued on another blockchain cannot be used directly on the Waves blockchain. A new token representing the original one can be issued on the Waves blockchain, and a gateway that pegs the two tokens 1:1 can be deployed. For example, a gateway for an ERC20 token can be created using the Waves-ERC20-Gateway framework. By default, tokens on the Waves blockchain are not smart contracts, and any transactions with them are allowed. The script endows a token with functionality that sets the rules for its circulation. Each transaction involving a smart asset is automatically checked against the conditions specified in the script. If the asset’s script allows the transaction, it will be executed; if the script denies the transaction, it is either not put onto the blockchain at all or saved as failed.

Using smart assets, you can implement various financial instruments on the blockchain (options, interval trading, taxation) and game mechanics (allowing transactions only between characters with certain properties).

Asset script checks transactions involving the asset against the specified conditions. The script contains a logical expression. Possible results of the expression calculation are:

• true: the transaction is allowed,

• false: the transaction is denied,

• error: the transaction is denied.

If the asset script denies the transaction, it can either be discarded or saved on the blockchain as failed. If the transaction is saved as failed, the sender is charged a fee, and no further changes are made on the blockchain.

An asset script can use blockchain data:

• The current height

• Account balances

• Entries in account data storage

• Parameters of the asset itself

• Other tokens

The script also has access to the fields of the current transaction, except proofs.

Issue Asset (Normal Token)

To issue an asset (token), you don’t need to write any smart contracts. You may just send an issue transaction with the fields specified above, and the token is created by the blockchain. You have several ways to create your non-smart asset:

• Using WX.Network: This option is great for those who don’t know any programming languages, don’t have time or want to learn one.

• Using JavaScript: Waves has created a library for JavaScript language for those familiar with this programming language. Developers can easily use two pre-made functions, issue and broadcast, to create and send their transactions to the blockchain.

• Using Python: Again, Waves created a library to import to your Python script, and with just three lines of code, your asset is ready.

• Using dApp: This way is for more experienced developers since you directly contact the blockchain. There are some callable functions that I’m not going to explain, but you can find the full explanation in Waves docs.

Issue Non-Fungible Token (NFT)

A non-fungible token or NFT is a special type of token that represents some unique object. Each NFT has its own unique identifier.

To issue an NFT, you can use any of the methods described above. Specify the following parameters of the token:

• "quantity": 1

• "decimals": 0

• "reissuable": false

Waves Protocol offers a unique approach to decentralized application development: avoiding gas and non-Turing-complete language keeps the system secure and predictable. For smart contract creation, Waves provides its native language called Ride. Its straightforward and developer-friendly syntax makes blockchain development easy and intuitive.

Ride

Ride is a purpose-designed programming language for smart contracts on the Waves blockchain. It was created to address many of the most serious shortcomings of other popular smart contract languages. The overall idea was to offer a straightforward, functional language for dApp development on the Waves blockchain. Ride is easy to learn, especially for beginning developers.

Ride is a statically-typed, lazy, functional, expression-based compiled programming language. It is designed for building developer-friendly decentralized applications (dApps).

Ride is not Turing Complete, and its execution engine (virtual machine) doesn’t have any concept of loops. Also, there are several limitations by design, helping to ensure execution is secure and straightforward. However, Waves recognize that iterations are necessary and have implemented them as FOLD macros. One of the key features is that the execution cost is always predictable and known in advance.

Despite being simple to use, Ride is powerful and offers wide-ranging functionality to developers. It’s broadly based on Scala and is also influenced by F# and the functional paradigm.

Ride was created specifically for execution within a blockchain environment and is optimized for this purpose. Because the blockchain is a shared ledger on many computers worldwide, it works slightly differently from conventional programming languages.

Since Ride is designed to be used inside the blockchain, there is no way to access the filesystem or display anything in the console. Instead, Ride functions can read data from the blockchain and return actions as a result, which can then be applied to the blockchain.

Generating Nodes

A generating node is a node that generates blocks. Each generating node is a validating node. A generating account is an account that a node uses for signing generated blocks.

For a node to be able to generate blocks, its generating balance must be at least 1000 WAVES. This means that the account balance in WAVES, taking into account leasing, was at least 1000 WAVES in each of the last 1000 blocks. The greater the generating balance of the node, the higher its chance of being eligible to generate the next block.

By adding a new block to the blockchain, block generators receive the block reward (at the time of writing this article, the reward is 6 WAVES) and transaction fees.

Validating Nodes

A validating node is a node that validates transactions. A Validating node validates each transaction in the following cases:

• The node receives the transaction via the broadcast endpoint of Node REST API or gRPC Server.

• The node receives the transaction from another node of the blockchain network using the binary protocol.

• The block generator adds the transaction to a block.

• The node receives a block (or microblock) from another node in the network.

Full transaction validation includes the following checks:

1. Transaction fields check, including:

   1. Timestamp check: the transaction timestamp should be at most 2 hours ago or 1.5 hours ahead of the current block timestamp.

   2. Transaction version check: all the features required to support this version should be activated.

   3. Transaction type check: all the features required to support this type should be activated.

   4. Check of token amounts: the values must be non-negative.

   5. Check of fields depending on the transaction type.

2. Sender’s balance check. The sender should have enough funds to pay the fee. The sponsor’s balance is also checked to see if a sponsored asset is used for the fee. Depending on the type of transaction, the sender should have enough assets for transfer or for payments attached to the Invoke Script transaction. Order senders in the Exchange transaction should have enough funds to exchange.

3. The sender’s signature verification for an ordinary account (without script), account script execution if the sender is a smart account, or the verifier function execution if the sender is dApp. A similar check is performed for orders in an Exchange transaction.

4. For the Invoke Script transaction and the Ethereum transaction that invokes a dApp script:

   1. Calculation of the result of the dApp callable function.

   2. dApp balance check: dApp account should have enough funds for dApp script actions.

   3. Check that the transaction fee is not less than the minimum fee based on script actions.

5. Execution of asset scripts if the transaction uses smart assets, including scripts of assets used in dApp script actions.

Leased Proof-of-Stake (LPoS)

Waves Protocol is based on a Proof-of-Stake consensus algorithm. Each participant’s chance to generate the next block is proportional to their economic stake in the network. Unlike Proof-of-Work, Proof-of-Stake is hardware-savvy and power-savvy, making attacks profitless for miners.

Users can lease their WAVES to a Waves node and get a part of the node payout as a reward, preserving full control over their WAVES under their accounts.

Leased Proof-of-Stake (LPoS) is an enhanced type of proof-of-stake consensus algorithm by which the Waves blockchain network aims to achieve the distributed consensus to secure the network.

Nodes can use the leased tokens to generate blocks and get the mining reward. For that purpose, the generating balance of a node must be at least 1000 WAVES.

LPoS allows the token holders to lease their tokens to the Waves nodes and earn a percentage of the payout as a reward.

By using LPoS, leasers will be able to participate in generating new blocks because the larger the amount leased to a Waves node, the higher the chances for that node to be selected to generate the next block. If that node is selected, then the leaser will receive a reward.

When the user starts leasing the tokens, those leased tokens are locked and remain in the same address with the full control of their owner (They are not transferred to the node, they just remain unspendable until the leaser cancels the lease).

The only thing to consider when leasing is to choose the right node operator, as the operator’s node may work with different efficiency and send back different percentages as rewards.

Fair Proof-of-Stake is used to select a miner to generate the next block (I’ll explain this algorithm a bit, later).

Rewards are distributed to the leasers as below:

• The node owner may send the leaser a part of the rewards according to his conditions.

• The more transactions made on the network, the more rewards leasers get.

• These rewards are in WAVES.

Speaking in a nutshell, if you are familiar with Delegated Proof-of-Stake (DPoS), you are more or less familiar with LPoS, too.

Fair Proof-of-Stake (FPoS)

The idea of Proof-of-Stake is as follows: the choice of account that has the right to generate the next block is based on the number of coins in the account. Proof-of-Stake has some disadvantages that allow very large miners to forge a not proportionally greater number of blocks, which is not fair. Therefore, Begicheva and Kofman, in their article “Fair Block Delay Distribution In Proof-of-Stake,” proposed a new mathematical function that is way beyond the scope of this article.

This little change to the formula allows the algorithm works better and fairer. It improves fairness and security. Just to show how much improvement it makes, I’m going to show a table from the so-called article and describe it.

During the experiment, scientists took two miners as attackers, who wanted to create a fork for various reasons. They ran the simulation dozens of times for each setup of the consensus algorithm. The results show that with the old PoS, attackers gained 70% more commission, while this rate is 30% for the new one (FPoS). The table above shows the number of forks that attackers could create for each setup for lengths 2 to 14. As it can be derived immediately, the FPoS setup won’t let attackers create forks of their own to gain more commission. This setup makes it difficult and infeasible for attackers to misbehave and gain more than they should.

Blockchain protocols have some scalability limits and challenges that tradeoff between throughput and latency. The current blockchain technology is not fast enough and does not scale to include more transactions, so we have a performance challenge to consider.

There is a united agreement between miners, consumers, and developers with several perspectives that we need to deploy scalability measures. There has been an ongoing argument on how to improve Bitcoin’s scalability. Current proposals have focused on how big to make the blocks and how to handle the block size increases in the future.

All proposals suffer from a major scalability bottleneck: no matter what block size is chosen, the blockchain system can, at best, reach a proper transaction throughput, increasing from ~3 transactions per second to ~7 transactions per second. This is too far from the 30,000 transactions per second necessary to compete with the existing systems such as VISA transactions. The same major limitations apply to Litecoin, Ethereum, and all other currencies that share Bitcoin’s blockchain protocol.

Waves-NG will address the scalability bottleneck by making the network reach the highest throughput, depending on the network conditions. It will not only enhance the transaction throughput but will also reduce transaction latencies. So it will be possible to get an initial transaction confirmation in seconds rather than minutes.

Waves NG

Waves-NG is based on the bitcoin next generation protocol that serializes transactions and offers important improvements in the transaction latency (lower latency) and bandwidth (higher throughput) compared to Bitcoin without sacrificing other properties.

Waves approach this scalability matter by allowing the miner to farm a block during the time of mining in a continuous approach. This block continues in increments called a liquid block. This liquid block is unchangeable over time once the next block referencing is created and appended.

This approach increases effective bandwidth and speed of block creation, which is described as being “especially significant for businesses” using the Waves Protocol since it allows for conducting microtransactions—without any delays that are typical with traditional blockchain systems.

Furthermore, it allows the blockchain to withstand high loads, such as the distribution of tokens following crowdsales and airdrops of bonus tokens. The speed of processing trading transactions on exchange is increased as well.

Bitcoin Next Generation (Bitcoin NG)

It is a next-generation blockchain protocol, which is an alternative bitcoin scaling solution that does not involve increasing the size of blocks or decreasing the block time interval. This reduces the risk of forks, amongst other advantages. Bitcoin-NG describes that the basic tradeoffs in Bitcoin can be reduced with an alternative blockchain protocol, offering a consensus delay and bandwidth limited only by the Network Plane. The protocol splits time into time periods (epochs). In each time period, a particular leader is responsible for serializing transactions.

The leaders take the rule of generating blocks:

• Key blocks for the election of a leader.

• Micro blocks for ledger records.

Waves NG Operations

Waves-NG’s main and core idea is to split the liquid block into two types, Key blocks and Micro blocks. The process of creating a liquid block works as follows:

• The miner node gets permission to create a block.

• The miner node creates and sends the key block (which does not contain transactions).

• The miner node creates and sends the micro blocks (which contain transactions just as in a normal block with a reference to the previous micro block or key block) with a mining time interval of three seconds.

• Miners will mine those micro blocks and propagate them directly to the network until the next new key block appears regarding the liquid block.

All the transactions are part of the same block and are contributed altogether. In between blocks, the traditional Bitcoin system appears idle to an onlooker, as miners are working to discover the next block, but without apparent progress on the consensus front.

In contradiction, in Waves NG, the key blocks can be small because they need to contain only the coinbase transaction, which defines the public key that the miner will use to sign macroblocks.

Because a key block requires Proof of Stake, miners can not just produce one and usurp the leadership at will. Following the key block, the lead miner can quickly issue microblocks simply by signing them with the private key corresponding to the public key named in the key block’s coinbase.

Leader Blocks

It’s also called “Key Blocks.” these blocks are generated with proof of stake but do not contain transactions.

They serve as a leader election mechanism and contain a public key that identifies the chosen leader.

Each block has a header that contains, among other fields, the unique reference of its predecessor, which is a cryptographic hash of the predecessor header (either a key block or a microblock).

Micro Blocks

Once a node generates a key block, it becomes the leader. As a leader, the node is allowed to generate microblocks at a set rate lower than a predefined maximum.

These micro blocks will contain the ledger entries with no requirement for any Proof of Stake, and they’re generated by the elected leader in every block-generation cycle.

This block-generation cycle is initiated by a leader block. The only requirement is to sign the micro blocks with the elected leader’s private key.

The micro blocks can be generated at a very high speed by the elected leader (miner), thus resulting in increased performance and transaction speed.

For a microblock to be valid, all its entries must be valid according to the specification of the state machine, and the signature has to be valid.

Note that microblocks do not affect the weight of the chain, as they do not contain Proof of Stake.

When all micro blocks have been validated, they will be merged with their key block into one block.

The Reward Mechanism

Remuneration consists of two parts. First, each key block entitles its generator to a set amount. Second, each ledger entry carries a fee.

This fee is split by the leader that places this entry in a microblock and the subsequent leader that generates the next key block.

In order to motivate participants to follow the protocol, Waves-NG uses the following mechanisms:

• Each transaction pays a fee to the system, but unlike Bitcoin, this fee is distributed, with 40% to the leader and 60% to the subsequent leader.

• Finally, if a leader forks the chain by generating two microblocks with the same parent, it is punished by revoking the subsidy revenue; whoever detects the fraud wins a nominal fee.

Beyond the blockchain functionality and its underlying protocols, the Waves ecosystem offers a diverse collection of tools, products, and components to streamline the process of building and running dApps. The tools are developed both by the Waves team and the developer community.

As we mentioned, Waves Protocol is a layer-1 platform that executes smart contracts and dApps. This is the exact functionality of the Ethereum blockchain, the biggest layer-1 platform. Ethereum is the oldest platform that went online in 2015. Not long after that, in 2016, Waves Labs began to work on the Waves Protocol. But it is obvious that Waves Protocol could not get much attention, and its market cap is so less than Ethereum’s that they are incommensurable.

After all, Waves is trying to become the next Ethereum. Whether it is able to do such a thing or not, the wish to become the next Ethereum necessitates us to compare these two.

I have been talking about Waves Protocol for a long time. But, as it is obvious, none of what we saw was associated with “Layer-0 Platforms.” Then why did I introduce L0 and insist on Waves being both L0 and L1? Well, the answer is in the next section.

Waves Enterprise is a combination of private and public networks that ensures high throughput, scalability, and reliability of solutions, as well as data immutability and confidentiality. Waves Enterprise provides consulting, deployment, and support services.

Waves Enterprise consists of 4 layers:

• Business application layer: The platform’s client is located on this level, facilitating access rights management, executing transactions of all kinds, and tracking network activity. This layer also hosts client applications that use the blockchain for business process automation, sending and receiving distributed ledger data.

• Middleware layer: This layer features integration adapters for accessing data, as well as tools for integrating the platform into a company’s existing IT landscape. The authorization service restricts access to integration services’ data and facilitates the use of existing login data management services for interaction with the blockchain. The data service provides processed data from the blockchain in a relational form that is more familiar to most developers.

• Blockchain layer: The main tools ensuring consistency and immutability of distributed ledger data operate on this layer. Data transferred between nodes undergo preliminary validation. Then, based on a node’s current role (whether it generates blocks), it either creates a block from received data, signs it with a cryptographic module and its keys, or adds validated data to the state. A node’s current role is determined by the consensus algorithm. Two interfaces are available under the push/pull model for external access to the blockchain: GRPC and Rest API.

• Network layer: On the network layer, nodes exchange data under the TCP protocol after establishing a signed handshake that validates a node’s right to join the network. Data is transferred as a byte sequence. Nodes exchange data on transactions, blocks, microblocks, other network participants’ known addresses, and other service information. On this layer, nodes also exchange private data over encrypted TLS-like p2p connections.

These layers give the opportunity to have many blockchains, private or public, connected. These blockchains can have different consensus mechanisms, sets of nodes, maintaining algorithms, and even functionalities.

Let’s take a look at the platform and its architecture.

The Waves Enterprise platform is based on distributed ledger technology and built as a fractal network that consists of two elements:

• Master blockchain (Waves Enterprise Mainnet), which provides functioning of the overall network and acts as a global moderator for the basic network, as well as for many user networks;

• individual sidechains created for definite business tasks.

Interaction between the master blockchain and sidechains is provided by the anchoring mechanism, which broadcasts cryptographic proofs of the transaction into the basic blockchain network. The anchoring mechanism allows one to freely configure sidechains and use any consensus algorithm without losing connection with the master blockchain. For instance, the Waves Enterprise master blockchain is based on the Proof-of-Stake consensus algorithm because it is supported by independent participants. At the same time, corporate sidechains that do not have to stimulate miners with transaction fees can use the Proof-of-Authority or Crash-Fault-Tolerance algorithms.

This two-part arrangement allows optimizing the network for high processing loads, increases information transmission rate, as well as to enhance concurrence and availability of data. Usage of the anchoring mechanism increases trust in data in sidechains because they are validated in the master blockchain.

Each blockchain node is an independent network participant who has the software required to work with the network. Every node consists of the following components:

• Consensus services and cryptolibraries: components responsible for achieving consensus between nodes and cryptographic algorithms.

• Node API: gRPC and REST API interfaces of the node that allow to receive data from the blockchain, sign and broadcast transactions, send confidential data, create and call smart contracts, etc.

• Unconfirmed transaction pool (UTX pool): the component providing storage of unconfirmed transactions before their validation and broadcasting into the blockchain.

• Miner: the component responsible for creating transaction blocks for adding to the blockchain, as well as for interaction with smart contracts.

• Key store: storage for key pairs of a node and users. All the keys are protected with a password.

• Network layer: the logic layer that provides interaction of nodes at the applied level via the network protocol over the TCP.

• Node storage: the system component based on RocksDB that provides storage of ‘key-value’ pairs for the entire set of confirmed transactions and blocks, as well as for the current blockchain state.

• Validation logic: the logic layer containing transaction validation rules, for instance, basic signature check and advanced check according to the script.

• Configuration: node configuration parameters that are set in the node-name.conf file.

Installation of auxiliary services is not required, but they alleviate the interaction of users with the blockchain network. Apart from ready-made services and depending on tasks, integration adapters can be developed for the transit of transactions from client applications into the blockchain network, as well as for data exchange between a node and the applied services of a customer.

Scheme of node and auxiliary services arrangement:

In a private blockchain, transactions are processed by a definite list of participants, and each participant is familiar with the network in advance. Compared with the public network, private blockchains contain fewer participants, blocks, and transactions, which can cause a threat of information replacement. This situation, in turn, creates a risk of blockchain override, especially in case the PoS consensus algorithm is used–because this algorithm is not protected from such occurrences.

In order to increase the trust of private blockchain participants in the data broadcasted in it, the anchoring mechanism has been developed. Anchoring allows checking the consistency of data. Consistency of data is guaranteed through broadcasting data from a private blockchain into a larger network, where data replacement is less possible because of a larger number of participants and blocks. Block signatures and blockchain height are published from the private network. The mutual connectivity of two or more networks increases their resilience since all connected networks must be attacked to forge or change data due to a long-range attack.

Anchoring steps are:

1. Anchoring configuration is performed in the private blockchain configuration file (set the corresponding parameters in accordance with the recommendations listed in the article in order to exclude complexities while working with anchoring);

2. After each configured number of block’s height-range, the node saves information about the block at the (current-height, threshold) in the form of a transaction into the Targetnet. To do this, Data Transaction 12 containing the ‘key-value’ pairs is used;

3. After the transaction broadcast, the node receives its height in the Targetnet;

4. The node checks the Targetnet blockchain every 30 seconds until the height achieves the value height of a created transaction + height-above.

5. Upon achieving this Targetnet blockchain height and acknowledgement of the presence of the first transaction in the blockchain, the node in the Targetnet creates a second transaction with data for anchoring in the private blockchain.

Snapshooting is an auxiliary mechanism of the blockchain platform that allows saving the data of the working blockchain for a subsequent change of network configuration and starting the network with the saved data.

The snapshooting mechanism allows changing the blockchain configuration parameters without any loss of its data. The process of changing the network configuration parameters with the use of a snapshot is called migration.

• A snapshot includes the following data:

• states of network addresses: balances, permissions, keys;

• states of smart contracts created in the network: data received as a result of smart contract calls and attached to them with the use of 105 transactions (this is a technique of writing the result of a smart contract execution to its state);

• data of miners of the previous rounds;

• information of confidential data access groups.

A snapshot does not include the history of transactions, bans, and network blocks.

In the migration process, a snapshot becomes an initial state of the blockchain network with new parameters. The network itself is restarted with the generation of the new genesis block.

A smart contract is a separate application that saves its entry data in the blockchain, as well as the output results of its algorithm. The Waves Enterprise blockchain platform supports the development and usage of Turing complete smart contracts to create high-level business applications.

Smart contracts can be developed in any programming language and do not have any restrictions for their internal logic. In order to split the startup and performance of a smart contract and the blockchain platform itself, smart contracts start and work in Docker containers.

When a smart contract starts in a blockchain network, nobody can change, spoof, or restrict its operation without interfering with the entire network. This aspect allows for providing security for business applications.

Blockchain is a distributed system that does not have a unified process regulator. Decentralization prevents corruption inside the system but complicates decision-making and organization of an overall workflow.

These problems are resolved by the consensus–an algorithm that coordinates the work of the blockchain participants utilizing a certain voting method. Voting in the blockchain is always performed in support of the majority: minority interests are not taken into account, and decisions that have been made become mandatory for all network participants. Anyway, voting guarantees the achievement of a consensus that will be profitable for the entire network.

The Waves Enterprise blockchain platform supports three consensus algorithms:

• LPoS consensus algorithm

• PoA consensus algorithm

• CFT consensus algorithm

The Waves Enterprise Mainnet uses the Leased Proof of Stake (LPoS) consensus algorithm for internal decision-making. To support this, the WEST technical token has been developed, which serves as a proof of the right to mining, as well as a financial motivation for the participants.

Sidechains and private networks based on the Waves Enterprise blockchain platform can use any of three supported consensus algorithms, depending on the needs of a certain project. A private network consensus algorithm is configured in the node configuration file.

I already talked about the LPoS consensus algorithm. I will explain PoA and CFT consensus algorithms in the next two parts.

Proof-of-Authority (PoA) Consensus Algorithm

In a private blockchain, tokens are not always needed. For example, a blockchain can store hashes of documents exchanged by organizations. In this case, a solution based on the PoS consensus algorithm is redundant in the absence of tokens and fees from transactions. The Waves Enterprise Blockchain Platform offers the option of a Proof of Authority (PoA) consensus algorithm. Mining permission is issued centrally in the PoA algorithm, which simplifies the decision-making compared to the PoS algorithm. The PoA model is based on a limited number of block validators, which makes it scalable. Blocks and transactions are verified by pre-approved participants, who act as system moderators.

In PoA, rights to generate new blocks are awarded to nodes that have proven their authority. These nodes are called “Validators,” and they run software allowing them to put transactions in blocks. The process is automated and does not require validators to monitor their computers constantly, but it does require uncompromising the computer. PoA is suited for both private and public networks, like POA Networks, where trust is distributed.

PoA consensus algorithm leverages the value of identities, meaning that block validators are not always staking coins but their own reputation instead. PoA is secured by the trust in the identities selected.

Crash Fault Tolerance (CFT) Consensus Algorithm

Coherence among the network elements that form a single blockchain is important when exchanging information extensively in a corporate blockchain. And the more participants are engaged in the exchange, the more likely an error will occur: a hardware failure by one of the participants, network problems, and so on. This can lead to forks of the main blockchain and, consequently, the rollback of a block that seems to be already formed and included in the blockchain. In this case, the blocks subject to the rollback begin to be mined again and become unavailable in the blockchain for some time. This, in turn, can affect the business processes that use the blockchain. The Crash Fault Tolerance (CFT) consensus algorithm is designed to prevent such situations.

The CFT consensus algorithm is based on the PoA with an added phase for voting of mining round validators: network participants that are automatically appointed by the consensus algorithm. This approach guarantees the following:

• more than half of the participants (validators) are familiar with a definite block and have validated it;

• the block will not be rollbacked and will be published in the blockchain;

• there will be no parallel chain in the network.

This is achieved by the finalization of a produced block. The finalization itself is based on the consensus of a majority of round validators (50% + 1 vote). In accordance with this consensus, the decision to block broadcasting is taken. If this majority is not achieved, mining will be stopped until the network cohesion is restored.

Like the PoA, the CFT algorithm depends on the current time; starting and ending time of each mining round is calculated based on a genesis block timestamp. Basic parameters that form an algorithm that is used for the appointment of a current block miner are also identical to the PoA parameters.

Waves’ new blockchain-agnostic solution is a major step towards interoperability between different blockchains.

Gravity Hub, presented at Waves Community Meetup in Berlin on 11 December 2019, aims to unite all existing blockchains and dApps, resolving the interoperability issue. It will also operate as a data oracle, feeding data from the outside world to the blockchain.

Gravity Hub is essentially a blockchain that doesn’t have any tokens but can communicate with other blockchains, such as Waves Platform, Waves Enterprise, or Ethereum.

The use of the word “gravity” is by no means random, as the solution will have properties similar to those of gravity: it will attract and connect various blockchains.

So far, the inability to transfer data from one blockchain to another has been a major hindrance to the development of the blockchain space. This solution has the potential to take blockchain technology to a new level by facilitating free and unfettered communication between any existing blockchains.

Gravity Hub will assume interoperability at the protocol level, as well as at the decentralized applications level, allowing a dApp to send a request to another dApp on a different blockchain.

Gravity Hub’s nodes will be able, for instance, to obtain block headers from the Ethereum network and send them to the Waves Platform. If Ethereum block header data is available on the Waves Platform, it will be possible to prove that a specific transaction has occurred on Ethereum. To obtain that data, users will pay reasonable fees.

For sending tokens between blockchains, token ports will be used, which will also use data from Gravity Hub.

Gravity Hub will also be connected to custom chains, which represent a new approach to blockchain customization. Waves Matter, our blockchain engine, can be assembled in any configuration for different purposes.

As nodes will be split into the main core and several mandatory and optional plug-ins, users will be able to choose smart contract languages, consensus algorithm modules, cryptography types, and other functionality for their custom chains.

In addition to providing an interoperability protocol, Gravity Hub will help resolve the issue of obtaining information from the outside world, as it will facilitate access of all connected chains to data from outside the blockchain.

A member of any network connected to Gravity Hub will be able to request oracle data from any information systems that have APIs—from Google to enterprise ERP systems.

All Gravity Hub nodes will have “data watchers”—modules for collecting various types of data, such as block headers and block height from other blockchains, exchange rates, etc.

For each data watcher, a data profile will be set. For instance, if a data watcher collects Ethereum block header data, this will need to be done with a certain frequency and reliability.

How can we make sure that the data provided by Gravity Hub is accurate? That can be achieved by consensus between several nodes.

To that end, at least several nodes collect data of the same type, which is written to the Gravity Hub blockchain as “raw data.” Once consensus has been reached, “consensus data” is also written to the blockchain and can be sent to a user who has requested it. There are various options for sending consensus data to the user.

One option is a multi-signature solution, whereby a transaction containing the consensus data must be signed by all nodes.

Alternatively, any node could be allowed to send consensus data to the user, but in that case, the node’s stake will act as collateral. If, for instance, a node sends data to the target blockchain that is different from the ultimate consensus data, proof of that can be sent to a smart contract, which will automatically deduct part of the node’s stake as a fine.

A user will be able to request a certain type of data over a specific time period for a fee consisting of execution costs and the node’s fee. Also, the user will be able to set up preferences. For example, when requesting exchange rate data, the user can set the maximum variability required.

The Waves protocol uses state-of-the-art cryptographic algorithms to ensure assets’ secure transfer and storage. The platform supports the Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signatures and SHA-256 for hashing. These algorithms have been thoroughly tested and are widely considered to be secure.

In addition, the Waves team also conducts regular security audits and implements best practices to ensure the platform’s security. This includes regular software updates and patches to address any vulnerabilities or security flaws that may arise.

Waves protocol has been audited by multiple third-party security firms. However, the specific results of those audits are not publicly disclosed by Waves or the auditing firms. It is common for security audit results to be considered confidential and not publicly shared in order to protect the security of the platform and its users. Nevertheless, it is known that the Waves protocol regularly undergoes security audits and that the results have been positive, indicating the platform’s commitment to security and protecting its users’ assets.

The Waves platform underwent a security audit performed by Kudelski Security, a well-established company with a solid track record. The purpose of the audit was to uncover security shortcomings in the Waves platform and improve its security. The audit, which took 50 hours of work, was led by Dr. Jean-Philippe Aumasson, a Principal Research Engineer at Kudelski Security. The audit results showed no critical security issues in the Waves platform, and the auditors praised the platform’s good security engineering, choice of cryptographic components, and clear design and code that facilitated auditing. As they mentioned in their published audit:

“We did not find any critical security issues but reported four medium-severity issues and six low-severity issues, which can all be easily fixed. The Waves platform otherwise shows good security engineering, good choice of cryptographic components with reliable implementations thereof, and has a clear design and code that facilitate auditing.”

Waves CEO Alexander Ivanov was pleased with the audit’s outcome and said that a clean bill of health from Kudelski was a testament to the hard work of the developers. The Waves platform will continue to undergo additional security audits as more functionality is added.

Waves Enterprise’s voting service provider underwent security testing by an external company, Deteact, back in 2020. The main goal of the testing was to ensure the service’s protection from vulnerabilities that could compromise confidential user data or interfere with the voting process. Deteact, a relatively new company specializing in security audits (back in those days), was chosen as the testing partner due to a previous successful collaboration with Waves Enterprise.

The security tests covered various aspects of the voting service, including the client app, smart contract logic, voting process, and infrastructure. The testing process took around three weeks and discovered several vulnerabilities in the classic web interface, specifically in the user registration and data storage parts. The two most critical vulnerabilities found were the risk of personal user data leakage and cross-site scripting, which could allow an attacker to perform actions in the app under a user’s name.

Other vulnerabilities discovered were:

• An attacker’s ability to make changes to a voting invitation.

• The potential to add the same voter multiple times.

• A vulnerability that could leave the service open to a DDOS attack.

Once the vulnerabilities were uncovered, they were addressed by the service’s developers and re-checked by the testing team.

Waves Enterprise’s interaction with Deteact was productive, with Deteact’s CEO, Omar Ganiev, commenting on the smoothness of the collaboration. Waves Enterprise values the security of its solutions, and the tests run by Deteact have helped make the voting service even more reliable and protected from outside interference. The company is satisfied with its collaboration with Deteact and plans to use its services in the future.

In conclusion, the security testing of Waves Enterprise’s voting service successfully ensured the protection of confidential user data and the integrity of the voting process. The testing process uncovered and addressed several vulnerabilities, and the collaboration with Deteact was productive and successful.

Founder and CEO

Sasha Ivanov is a physicist and mathematician who is best known as the founder of Waves Protocol. This blockchain platform enables users to create custom digital assets, launch ICOs, and trade tokens. Before founding Waves, Ivanov worked as a software engineer and IT consultant. He has a background in physics and mathematics, having studied at St. Petersburg State University in Russia.

Ivanov founded Waves in 2016, intending to make blockchain technology accessible to a wider audience. Under his leadership, Waves has become one of the largest blockchain platforms, with a growing ecosystem of developers, users, and businesses. Sasha Ivanov has been recognized for his contributions to the blockchain industry and is known for his innovative approach to solving complex problems.

Head at Waves Camp

Ekin Tuna is the Head of Waves Camp, a blockchain incubator and accelerator program that provides support and resources to early-stage blockchain projects. Tuna is a seasoned entrepreneur with a background in finance and business development. He has extensive experience in the blockchain and cryptocurrency industry and has worked with several startups in the space.

Under Tuna’s leadership, Waves Camp has become one of the leading programs for supporting and scaling early-stage blockchain projects. The program provides mentorship, resources, and funding to help startups grow and succeed in the competitive blockchain market. Tuna is known for his deep understanding of the industry and ability to identify and support promising projects.

Waves Protocol and Allbridge, a token bridge protocol, partnered to integrate Waves with all of Allbridge’s 15 supported blockchains, including Solana, BNB Smart Chain, and Ethereum. The integration launched on 22 September with an incentivized multi-asset pools campaign on the Waves-based AMM platform, Swop.Fi. The partnership aims to increase access to Waves-based projects for investors seeking larger returns on their stable assets. Allbridge is a bridging protocol with over $6 billion in asset transfers and over $74 million in Total Value Locked. Waves, launched in 2016, is a global open-source platform for decentralized applications based on proof-of-stake consensus and aims to maximize blockchain benefits with a minimal carbon footprint. Allbridge is a tool to transfer assets freely between different blockchains.

As we mentioned earlier, Waves Protocol is a competitor to Ethereum, BNB Smart Chain, Solana, and other layer-1 platforms. At the time of writing this article, Waves Protocol is behind many of the other layer-1 platforms in the market cap.

It seems that Waves Protocol is not very better than these other platforms in terms of technical or economic aspects. This can cause Waves Protocol never reaches the market cap of the other great layer-1 platforms. If they decide to change some technical and economic means, they might become bigger in the future.

Waves Enterprise is a competitor to big L0 platforms. These layer-0 platforms consist of Polkadot, Cosmos, and Horizen. The most important difference between Waves Enterprise and the other L0 platforms is that Waves Enterprise is mostly for enterprises and can handle public and private blockchains with different levels of permission. But, the other layer-0 platforms can only handle public blockchains.

The other difference is in their technology. Polkadot is much better designed in terms of the economy of the token. Cosmos is much more popular among projects to use.

In conclusion, if Waves Enterprise doesn’t redesign the technology and economy of its native token, there is a high probability that it won’t be big enough to compete with these big layer-0 platforms.

The Waves blockchain started 2022 with more than 2 million user wallets and a vibrant community across successful projects such as Waves.Exchange, Vires.Finance, and WavesDucks.com. With 100k+ transactions in the mainnet daily and more than 250 validators, Waves boasts a throughput of thousands of transactions per second. The current Total Value Locked (TVL) in the network is $2B, and about 80% of tokens are locked in staking. These have been achieved without VC funding in the last five years.

Waves Protocol is going from version 1.0 to version 2.0. Some key points regarding this transformation are:

1. Waves 2.0: New Consensus with Ethereum Virtual Machine Support

2. Open Collective. New governance models

   1. DAO Framework

3. Cross-chain finance: Bridge to all chains

   1. Gravity Bridges

   2. Universal Bridge Integration

4. Meta: A bridge between digital worlds

   1. Level 0 Inter-Metaverse Protocol

5. US Company and Accelerator Program

   1. US Company

   2. Accelerator Program

6. Projected Timeline

7. (1 ➝ 2) – Join The Movement

For Waves Enterprise, 2022 brought several fundamental changes, which will bear fruit next year. Here are the most important ones:

• Waves Enterprise has moved to the enterprise DAO governance model, including the community and the Governing Council.

• They designed a new tokenomics based on WEST/LWEST/GWEST triad to be launched in the first half of 2023. It will bring new opportunities to all Waves Enterprise users.

• The community already approved several third-party projects to enter the Waves Enterprise ecosystem—SwapWave decentralized AMM and Syndex tokenizing protocol. With the launch of the new tokenomics, the votings in 2023 will be based on new tokens.

• This year, the Waves Enterprise team became as global as never before. It moved beyond the UAE and Singapore. The new legal entity was established in the USA and aimed to bring more enterprise customers to Waves Enterprise’s tech stack. We expect to get public cases in North America next year and make the Waves Enterprise case folio truly global.

• EAST protocol launched staking with tasty APRs!

• They plan to continue onboarding new projects within the ecosystem; the current SwapWave and Syndex start a long journey here.

All these global changes are forming the next phase of the Waves Enterprise ecosystem, which is expected to be thrilling. And here are just a few things from the list that we plan to do in Q1, 2023:

• LWEST/GWEST will finally set off, or at least they will share the exact launch date in H1, 2023.

• More important and regularly, all the DAO initiatives will be brought to life via community voting.

• Deeper integration into the Waves ecosystem: WEST became part of WINDX, participating in the recently launched Waves ambassador program and other co-op things.

• The first of the new mainnet projects will be launched in February—a protocol for tokenizing real-world assets.

• The USA integrator will be officially introduced to the market.

Also, there is a roadmap in the WEST 2.0 whitepaper, which you can see in the image below.

WAVES is the native token of the Waves blockchain. Block generators receive transaction fees and block rewards in WAVES, which encourages generators to maintain and develop the blockchain network infrastructure. The more WAVES the generator holds (by ownership or lease), the greater its chance to add the next block is.

WAVES has been present on the blockchain since inception; there is no issue transaction for it. Therefore the WAVES token does not have an ID. The REST API uses null for WAVES.

The owner of WAVES can lease them via a Lease transaction. WAVES received on lease are included in the generating balance. Block generators send back different percentages as rewards to lessors. A lessor can cancel the lease anytime via a Lease Cancel transaction.

The number of decimal places (decimals) for WAVES is 8. The atomic unit called WAVELET is 1/100,000,000 WAVES.

During its initial coin offering in April 2016, 100 million tokens were launched, raising over $16 million. The fund was brought Waves Protocol, nearly 30,000 BTC, at the time of ICO.

15 million tokens are reserved for bounties and the development team in the following proportions:

• 1 million tokens are distributed to early supporters.

• 1 million tokens are reserved for post-ICO bounties.

• 4 million tokens are reserved for strategic partners and backers

• 9 million tokens are withheld by the development team.

The remaining 85 million tokens have been distributed in the lCO procedure to participating users based on their contribution to the total amount of the raised funds.

Block Rewards

Block Reward is a blockchain feature under which generating nodes receive a fixed fee in WAVES for each generated block. Block rewards are paid due to the additional issue of the WAVES token. The community of generating nodes can change the reward size through voting.

Every 100,000 blocks, i.e., approximately every 70 days, a new voting for the current reward size change begins among the generators. The voting duration is 10,000 blocks. During this time, generating nodes vote to increase, decrease, or leave the current reward size unchanged. The elected reward size remains unchanged for 100,000 blocks following the end of voting.

A generating node specifies the new desired reward size using the waves.rewards.desired setting in the node configuration file; the setting value is specified in WAVELETs.

If the value is greater than the current reward size, then the generator votes for the current reward size increase; if the value is smaller—for the decrease. If the setting value is not specified in the configuration file, then the generator votes for keeping the current reward size.

When a node generates a block, it writes the value of the waves.rewards into that block.desired setting from its own configuration file. If the setting value is not specified in the configuration file, then -1 is written to the block.

During the voting time in 10,000 blocks, a single node can generate several blocks; therefore, one node can vote several times. How often a node generates blocks is determined by the LPoS consensus.

Waves Enterprise uses WEST (Waves Enterprise System Token) as a basic asset, a utility token for all operations in the mainnet, as well as in hybrid sidechains.

As of June 2022, a total sum of 400 million WEST is emitted within the mainnet. 175 million WEST remains locked on a smart contract till 2023 under Tokenomika control. Then 100 million of the whole sum will be transferred to the DAO treasury. The other part of the Tokenomika treasury, 75 million WEST, is allocated to company investors; it will remain locked on a smart contract till 2024 and potentially afterward. 160 million WEST, along with another 25 million WEST in possession of the team, will also go directly to the DAO treasury, making it the biggest WEST holder on the market.

They are planning for a large share of the total WEST used by the Governing Council towards ecosystem development, including grants and marketing. The table below shows the perfect distribution of the total 400 million WEST supply from the WE DAO perspective.

LWEST token serves as a reward for WEST leasing within the Waves Enterprise ecosystem–this opportunity is provided by the mainnet consensus, LPoS. Leasing WEST boosts the overall liquidity of the tokenomics.

GWEST tokens fuel the Waves Enterprise DAO. GWEST works as a proof of interest in the long-term development of the platform. One can get GWEST due to staking LWEST for six months or more at the staking service.

Until June 2027, Waves Enterprise plans to distribute 60 million WEST as an airdrop to GWEST holders. This distribution will decrease over time; early birds will catch the biggest worms, as shown in the image below.

The Waves Protocol is a secure blockchain platform for transferring and storing assets, designed to provide high-quality security and scalability. The Waves team is led by founder and CEO Sasha Ivanov, who has a physics, mathematics, and software engineering background. The team has implemented several security measures, including regular security audits, best practices, and positive results from past security audits. The platform utilizes state-of-the-art cryptographic algorithms, such as ECDSA and SHA-256, to provide a secure environment for the transfer and storage of assets.

Waves Enterprise is a platform that consists of a master blockchain (Waves Enterprise Mainnet) and individual sidechains. The master blockchain serves as a global moderator and provides a proof-of-stake consensus algorithm, while the sidechains can use other consensus algorithms. The anchoring mechanism allows the sidechains to interact with the master blockchain, maintain trust in data, and prevent the risk of information replacement in private blockchains. The platform includes nodes and auxiliary services arranged in a scheme to help interact with the blockchain network.

Gravity Hub is a blockchain-agnostic solution to resolve the blockchain space’s interoperability issue by unifying all existing blockchains and dApps. It operates as a data oracle, feeding data from the outside world to the blockchain, and has the potential to take blockchain technology to a new level by enabling free and seamless communication between different blockchains. The solution will assume interoperability at the protocol and decentralized application levels, allowing dApps to send requests to other dApps on different blockchains. The accuracy of the data provided by Gravity Hub will be achieved through consensus among several nodes.

Overall, the Waves Protocol can become a promising player in the blockchain space, offering scalability, security, and interoperability solutions to businesses and individuals alike. It’s worth noticing that this is a matter of time and progress in technology and the economy.

• Begicheva, Antonina, and Alexy Kofman. “Fair Block Delay Distribution In Proof-of-Stake.” Waves Community Forum, https://forum.waves.tech/uploads/default/original/2X/7/7397a4cb5fa77d659a7b7ecc9188dd0a4fe0decc.pdf. Accessed 28 January 2023.

• Buterin, Vitalik. “Ethereum Whitepaper | ethereum.org.” Ethereum.org, https://ethereum.org/en/whitepaper/. Accessed 27 January 2023. Coin Bureau. “What's Up With WAVES?? My Deep Dive!!” YouTube, 16 September 2020, https://www.youtube.com/watch?v=-AtXH2j4eF8. Accessed 24 January 2023.

• Cosmos. “What is IBC? | Developer Portal.” Cosmos Developer Portal, https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html. Accessed 27 January 2023.

• Crunchbase. “Sasha Ivanov - Founder @ Waves Platform.” Crunchbase, https://www.crunchbase.com/person/sasha-ivanov. Accessed 30 January 2023. Crypto Square. “☕️.” YouTube, 10 August 2022, https://www.youtube.com/watch?v=nrAyYTHHlVE. Accessed 24 January 2023.