White Paper


Today, centralized solutions are used everywhere across all areas of our lives. But recently society has started to realize the shortcomings of centralized systems, and how the largest corporations conduct their business. Therefore, we are seeing tremendous growth in decentralized solutions that have emerged thanks to blockchain technologies. Unfortunately, decentralized solutions can hardly be called convenient and user-friendly, which is crucial to reaching mass distribution. Velas want to change that.

This paper contains a description of the Velas Network Ecosystem. Our team has developed a set of technologies that are designed to form the basis for the decentralized Internet - Web 3.0. We took the most useful and applicable technological innovations and built decentralized products based on top of them. We designed our products to be user-friendly, accessible, and as understandable as centralized products, but without exploiting users' data or creating a single centralized point of authority or failure.

With such a mixture, we hope to show the general public all the benefits of using decentralized solutions with Velas.



The world has changed fundamentally in the past few challenging years. Unprecedented global events have prompted countless questions to what we should expect next, and how we should move forward. COVID-19 contributed to the increase in speed, growth, and complexity of our society's evolution. Businesses, governments, and private households were forced to adopt digital technologies to reduce human contact. Trends like home workspaces, social media, e-commerce, and online meetings have significantly increased the demand for digital solutions – and that trend won’t end once the pandemic is over.

The world has moved into the digital age with the emergence of services and applications that leverage the way we communicate, and transfer information to the next level. The accelerated and forced digital transformation has triggered the need for a constant search for innovation.

The darker side of rapid digitalization has seen the emergence of giants and monopolies, who spread centralization, censorship, and control in and across the digital space and social networks. If you are using popular social media platforms, then your confidential information no longer belongs to you. A large span of companies manage all your personal data for their own purposes. And these problems are the lasting legacy of Web 2.0.

Web 3.0

People's desire to regain freedom, privacy, and control over their data has led to the emergence of the concept of Web 3.0 – the decentralization of the Internet. It can become true with the advancement of blockchain technology, which has transformed entire industries in recent years.

Web 3.0 will completely erase the boundaries between online and offline, it will be completely authentic and saturated with decentralized applications distributed across domain-specific clusters. The ordered chaos created by the small activities of billions of people is likely to make individuals, companies, and technologies work differently. Work better.


Blockchain has the potential to revolutionize economic and social interactions, and ultimately become the backbone of a digital society.

Blockchain is a distributed ledger technology that is designed to protect against unauthorized access and ensures that records are immutable (nothing can be erased once it's added) and traceable without the need for centralized management.

Such architecture allows different organizations to utilize one common database, which does not require human efforts to verify the integrity of the data, and is protected from unauthorized interference.

Blockchain technology has proven its capabilities in handling data in a decentralized and secure way, collecting separate fragments into one common whole. Where the internet transmits information, blockchain is capable of efficiently transmitting value, whether it is rights of ownership, goods, or services. Efficiency implies both the speed of information exchange on the blockchain and ensuring its reliability, immutability, as well as building a secure and transparent mode of access to this data by only those who have the right to access it.

This is especially important when the costs of adding data sources and the associated liabilities outweigh the benefits. With the explosive growth in the use of customer data in emerging technologies, such as AI and IoT, visibility is becoming extremely relevant to customers. If the blockchain itself has reached a certain threshold of maturity, then the UX / UI technologies that support it are in their infancy. Soon, they will start a conflict very similar to the conflicts of standards that have led to today's Internet standards. According to Gartner, by 2024, 30% of the sensitive personal data of customers will be protected by licenses based on blockchain technology.


Inspired by the values of Web 3.0 and Blockchain technology, we created Velas, a project that combines Blockchain and innovative AI technologies to create a transparent, community-driven, and decentralized ecosystem of products and services.

Realizing social needs and aiming to become the industry standard, Velas is designed to be a blockchain platform suitable for thousands of applications and services to be built upon. Therefore, we architect it to be one of the most secure and fastest platforms in the industry.

Our mission is to create and integrate world-changing technology products and services to improve people's lives all over the world and make the internet free again - like it was before. We believe that disruptive technologies and innovations will help us to build a self-governed, decentralized future driven by the collective intelligence of the community.

Each of Velas' services is primarily focused on our users. We are trying to combine the best qualities of both centralized and decentralized solutions. It involves researching state-of-the-art cryptography, developing consensus protocols, and designing intuitive user interfaces providing developers, enterprises, and people worldwide to create and join easily accessible, transparent, and community-governed ecosystems for Web 3.0.

To address the main blockchain trilemma, our technologies are being developed with an emphasis on scalability, security, and decentralization.

Currently, Velas Blockchain’s performance is much higher than what can be seen across most of the existing blockchain platforms.

Comparison with others


To resolve the scalability issue, we’ve built our solution based on Solana complementing it with additional features and innovations.

Moreover, Velas is a community-driven project. At any time our community members can vote for the next product our team will place a priority on. This feature and the fact that anyone can join our network as a validator or delegator - makes both Velas and Velas Blockchain decentralized by nature.


Velas Blockchain

Before creating the project idea, the Velas team researched a huge variety of different technologies. We came to the conclusion that the project should solve fundamental problems of both users and blockchain technology in general, and with the maximum achievement of the theoretical performance limit, without compromising on safety and decentralization. That's why we are applying all possible optimizations and innovations at this stage.

We have chosen Solana as a foundation for the Velas Blockchain and complemented it with several innovations to ensure a more secure and user-friendly interaction with our Platform.

Furthermore, we would like to describe the set of technologies that unite together to make Velas Blockchain one of the most scalable, secure, decentralized, and user-friendly blockchain platforms on the market.


Velas Account

Velas provides its own passwordless authentication system, allowing users to securely access a variety of services without a password using just their Velas Account, while introducing unique authorization quotas to minimize risks.


Currently, there is a dilemma in the industry - how to make blockchain both secure and scalable. Therefore, we are working to add an AI module as an additional layer to prevent known attacks by slowing down the blockchain when an attack on the system is in progress, and accelerating the system when there is no malicious behavior in the network.

To achieve the optimal balance of speed, throughput, and security, Velas will implement a novel consensus system known as AIDPoS, which will use machine learning to automatically adapt the Velas blockchain to changing circumstances, ensuring maximum performance and resilience at all times.

Velas Vault

This is a new technology that allows us to accelerate and cheapen transactions from other cryptocurrency systems by leveraging the speed and security of our blockchain. In this way, we can achieve true security for a decentralized custodian. As an additional perk, we can utilize different authentication solutions, such as Google or Apple Authentication and our own Velas Account, to make the experience of using cryptocurrencies as user-friendly as with all the digital products we use every day. And to add to the number of use cases, our technology can be used to store any data you want in a distributed manner, which completely secures its privacy. And the list of possible applications goes on...

Based on Solana

It is highly important to have almost instant confirmation for e-payments. Solana has that.

As all know, blockchain technology is greatly suitable for making e-payments, without the need for a centralized third party to confirm the transfer of funds. When a transaction is confirmed, the nodes (network participants) add information about it to the blockchain.

To reach consensus and legitimize a transaction, blockchain nodes must exchange information about the state of the network or correct to say - synchronize. Synchronizing nodes in the network is one of the fundamental problems of blockchain technology because nodes are located all over the world and have different data throughput capabilities. Synchronization duration proportionally affects the ability of the blockchain to pass more accepted transactions per second (TPS). For example, the bandwidth of the Bitcoin network is 7 TPS, EOS has about 4000 TPS, but the most popular centralized payment system Visa processes around 1700 TPS and dwarfs (with such capability) most decentralized networks.

During our testing of Solana for a full network load, bandwidth reached ~60,000 TPS, and this is not the limit - in theory, it can reach 710,000 TPS on the standard gigabyte network.

Currently achievable performance metrics:

  • 59,490 Transactions per Second
  • 400ms Block times
  • $0.00001 fee per transaction

How is this possible?

Velas' team understands all outlooks of Solana's approach, and now it's your turn to view these perspectives.

We noticed Solana as the best one-shard chain with vast optimizations within it. The traditional blockchain sharding concept is technically bulky and has additional difficulties.

Solana blockchain can reach a speed of 60,000 transactions per second through GPU utilization, transaction processing parallelization, and other innovations such as PoH and Gulf Stream. The presence of such technologies in the framework significantly raises the bar for competitors and we consider this framework to be the best solution on the market. Therefore, we chose to use these developments instead of developing competing solutions. Which, in turn, allowed us to fully concentrate on developing the rest of our ecosystem.

The Solana Team composes pioneering technologists from Qualcomm, Intel, Netscape, and Google — and has focused on building the tech required for Solana to function with groundbreaking performance standards.

The main technologies that make Solana so productive and efficient compared to other blockchains are:

But, the way Solana optimizes the blockchain affects how developers build decentralized applications on it. They need to think about how the blockchain is structured and develop directly for the Solana blockchain, given all the imposed limitations associated with parallel processing.

Ethereum Virtual Machine (EVM) Compatibility

The predecessor of Solana, Ethereum, developed the concept of developer-friendly smart contracts that allows for the realization of all the possible uses with more thought about the process of decentralizing the subject domain and less focus on the limitations of the blockchain.

This enabled many developers around the world to develop a huge number of decentralized Ethereum applications in a short time, some of which even formed ERC standards that became widespread. However, there is no exact reason available why we need to replace this standard with another.

Despite this, developers faced the high cost of transactions, and limited performance of the Ethereum network, which motivated the creation of a more productive Ethereum 2.0.

Ethereum is by far the most widely used DeFi platform on the market, with the majority of dApps built on the network, so this EVM bridge will allow for those applications to run faster and smoother with Velas’ increased transaction per second (TPS) capabilities.

Our idea involves a different approach, which is being realized by the Velas team. We take the most efficient blockchain and implement the ability to write Ethereum smart contracts in it, namely the Ethereum VM.

This will open doors for the DeFi market and developers of decentralized Ethereum applications, allowing them to expand their capabilities with the Velas ecosystem, fast Velas blockchain, and low fees.

Velas Account

According to research by NordPass, the average user holds 70-80 passwords. That is a lot of passwords to remember. It is no surprise, then, that digital users' security is a bottleneck and the main goal of hackers. The FBI Internet Crime Complaint Center estimated that the sheer mass of password-related complaints they received in 2019 alone costs organizations $2.1 billion.

On the other hand, Internet commerce is growing quickly and experts predict that it could reach 27 trillion USD by the end of 2027, where payment method convenience plays a major role to outperform the competition.

This is why next-gen authentication and payment solutions become more and more popular as a measure to improve user experience and security.

Having to create multiple accounts across multiple applications and platforms negatively impacts a product’s attractiveness and convenience to their user base. Having one Facebook account, for example, enables users to seamlessly sign into other services with it, reducing friction. Paid services, however, request additional information such as credit card binding which is unavailable during a typical user session facilitated by Facebook or alternative social login solutions.

While a combination of centralized solutions, for example, Facebook for login and PayPal for payments might address the problem. Nevertheless, such a setup has its user experience and security drawbacks. Just to name a few: single points of failure, data collection, lack of ability to adjust to custom use-cases, reliance on email with password and etc.

While Facebook, Google, PayPal, and WeChat are the undisputed leaders in today’s markets, the blockchain industry is developing alternatives that focus on greater security, privacy, and durability. These alternatives start to form decentralized ecosystems that contribute to the transformation of the way people would manage their digital identities and perform transactions in the future. However, when it comes to authentication and one-click payments, today’s user experience of decentralized apps has a large room for improvement due to the complexities of blockchain technologies.

Let’s look at Metamask, one of the top wallet apps in the blockchain industry. It supports integration with any website and allows you to authenticate and execute payments through Metamask Browser Extension and recently a mobile app. However, to make payment in ERC20 tokens, you need to sign and broadcast multiple transactions (Approve, TransferFrom) that contain lots of technical information that average users can barely verify if it matches their intent. It’s complicated.

Besides confusing the transaction signing process, the other non-trivial task is to properly manage wallet seed phrases.

These two aspects alone significantly worsen user experience that sometimes results in the loss of funds and it’s not surprising that users would prefer services that make authentication and the payment process more convenient, even at the expense of their own privacy. If blockchain payments want to expand their audiences, it has to approach the level of Google and Apple in terms of user experience. This is where Velas Account is meant to perform its mission.

With Velas Account authentication, interaction with cryptocurrencies are facilitated to the level of centralized technology convenience without sacrificing user privacy and security.

  • No passwords, no break-ins. Velas Account uses biometric authentication on the user’s device to confirm login requests and transactions.
  • Seed phrases are available for advanced users, but newcomers can begin their decentralized journey with their Account backed by a social login without the need to manage private keys directly.
  • 360° overview of all connected apps and active sessions across all devices with the ability to terminate sessions and revoke permissions of any app at any time.
  • With Velas Account, the transaction confirmation screen is free from technical details, providing only the necessary and verifiable information to the user.
  • Sending an ERC-20 token to a dApp doesn’t require multiple transactions.
  • Stay in control of every transaction performed by Velas Account or whitelist well-known apps to execute app-specific transactions in the background.

As a result of these improvements, the user will not feel any discomfort because of the difficulties of using blockchain technologies. The interface will facilitate easy migration from centralized to decentralized solutions, leaving all technical details under the hood and convenient UX.


The Velas team conducted fundamental research to better understand how AI could be implemented into the blockchain architecture to optimize the performance of the whole network. Based on the conducted research we are designing and developing the AIDPoS consensus algorithm.


The main principle is to use AI to adapt the blockchain to current circumstances in the network, preserving the level of Transaction Per Seconds (processed and confirmed transactions) and resilience in the optimal ranges.

In our opinion blockchain should always be working in instant transaction confirmation mode, just like centralized payment solutions like Visa and Mastercard do. Instant transaction confirmation mode means that any transaction will be processed and validated within a second.

Maintenance of both performance and security at a high level is achieved by embedding trained models in every full node, which is producing the optimal values of the key parameters for the blockchain, based on the data collected from the last epoch.

The Velas Blockchain is a complex system that is deliberately configured for high performance. However, high performance means very limited time for nodes to synchronize, which can result in a large portion of nodes falling out due to network problems or targeted attacks on the consensus mechanism. As a result, performance can degrade greatly or even forks can occur. In order to prevent this, we are designing the AIDPOS algorithm which is proactively adjusting blockchain configuration to balance performance and security, also incentivizing decentralization and user engagement.


Overall approach

One of the promising areas of integrating AI and blockchain technologies is the development and training of a recommender algorithm based on machine learning technologies, which should provide a dynamic change in the parameters of the network and the consensus smart-contracts from epoch to epoch. Such an algorithm should ensure that the Velas blockchain network stays secure, resilient, and productive for all of its participants.

Velas proposes using the global network state data and local nodes state data of the previous epoch for predictions.

The recommender algorithm will act as the objective “guardian” of the network.

There are two main conceptions that are important for proper network functionality - performance and resilience. Performance can be measured by two straightforward metrics - throughput, which is measured by transactions per second, and transaction confirmation time. Resilience is the ability of the blockchain to withstand any type of attack and properly function during these events. Two main characteristics that ensure resilience maintains are security (the number of resources that an attacker needs to spend to break the blockchain) and decentralization, which can be described as the absence of a single point of failure.

Recommender model. How it works


The recommender module will be based on machine learning algorithms and will execute the following tasks: anomaly detection (nodes anomaly behavior) and recommendation of the optimal Velas blockchain parameter values.

Prediction/prognostic algorithms will be based on a Convolutional neural network. For anomaly detection, we consider the following approach is most suitable: distance-based, density-based, recurrent neural networks. Plenty of attention will be paid to the stability of trained models and their adaptation to the data in the process.

A Detailed Description of the Model

The AI module is a trained multilayer neural network that accepts two sets of parameters as input - the static parameters “α” of the blockchain, which change, but which we cannot influence on, and the dynamic “x” which the AI module can recommend based on the current state of blockchain and targeted parameters (y) that were identified in the N-1 epoch. For the network to accept the new parameters of the blockchain, it is necessary to conduct a vote in which the consensus participants will approve the new parameters determined by the AI module.


x - blockchain parameters
α - the current situation in blockchain
y - optimized function (throughput, security, etc.)

But here we face some challenges, x - never changed before at mainnet, α - small variations in mainnet (low load, etc.). To complete this tasks we develop Velas blockchain simulation model with the following features:

  • Launch simulation for a big range of α;
  • Investigate how the blockchain reacts for α with different x;
  • Build recommender model which proposes best x with respect to α

A module should have the possibility to adjust blockchain configuration to appropriate x.


Velas Vault


As all decentralization enthusiasts, we admire the cryptocurrencies that are bringing the world of decentralization closer to a level of full-blown normalization. Especially Bitcoin and Ethereum for their monumental contribution to the ideas and the concept of decentralized money and smart contracts. But as ordinary users, we see that these systems suffer from slow and expensive transactions, compared with other cryptocurrency solutions. Yet we still use these systems for their security, proven both by time and cryptography.

But, naturally, we want to make those transactions cheaper and faster, without losing the security provided by these systems. There are a lot of solutions on the market that offer to make your transactions almost instantaneous and free if you transfer your coins into their custody. They do it just by maintaining a centralized ledger of balances of all their users, so a transfer to another user is just a small change in a “spreadsheet”, which is very fast and cheap by definition. But there are significant problems with these services.

Let’s analyze the most common drawbacks of resorting to such solutions:

  1. Transferred control of your assets — service keeps the private keys, which means that if there are some problems with accessing the service, such as employee breach or external security breach, then your private keys are at significant risk of being compromised.
  2. Hacking and hacker attacks — there exist almost no exchanges that haven’t been subject to attacks or thefts of users’ funds in one form or another. If you don’t hold your keys personally, you are at risk of someone else gaining access to your assets through a wide variety of means.
  3. Changes in service conditions — at any moment, the service can impose restrictions or limits on services, including the deposit/withdrawal of funds from your accounts. Again, if you don’t personally hold your keys, you are at increased risk of losing access to them.
  4. Account blocking and freezing — upon request of regulatory bodies or police/ security services, the custody service may be required to limit user access to the platform and therefore their stored crypto.
  5. No anonymity — according to FATF rules, the service must collect user data and provide information to regulators upon request. KYC has its perks, but to many, it is a key factor to avoid.

Most of these drawbacks are fundamentally inherited from the centralized nature of such services. To be more precise, the problem lies in the way they guarantee their security. They build it on their reputation and the licensing from government regulatory bodies. So in other words, their security follows from their compliance to the regulations of centralized authorities. But this is in full contradiction with the core ideas of decentralization. True security can only be proven by time and mathematics.


As we described before, our primal goal was to make the fastest and the most secure blockchain one-layer system in the world. At the same time, the basic idea of custody service is that a fast and cheap ledger solution can accelerate and cheapen any other cryptocurrency system. As we’ve discussed, the main question is about security. So what if we can use our blockchain (decentralized ledger technology) as a ledger for custody?

If we do this, then it should only be done in a decentralized manner. But from the dawn of the cryptocurrency era until a year ago there were no suitable cryptographic solutions for the problem of decentralized custody. Yet the strong desire of the crypto-community for a solution to be found gave sufficient motivation for mathematical teams all around the world to search for new approaches to solve the problem at hand. So now let us find out what was the actual problem.

First, we need to understand that any type of custody cannot exist, if the user still holds the secret keys, that allow transferring the coins in custody. Actually, if any one entity knows the secret key, then it is not true decentralized custody. So we have two implications:

1) At least one transaction from a user to the custody should be made in the native Bitcoin system by the ways of a slow and expensive transaction.

2) No small group of validators, participating in securing the custody, should be able to restore the secret key.

What other requirements are necessary for a decentralized custodian to work? From properties 1) and 2) follows that we need a special protocol to exist that will allow the validators in the custody system to create a secret key in a distributed manner, where no small group can restore this key. And yet the protocol should allow for the corresponding public key to be made known for the users for the purpose of sending transactions to an address in the system.

This task was not the problem, as described protocols existed in the cryptography world for some time. So now we know that it is possible for the validators to create a secret key and corresponding private key in a truly decentralized way. And users can send their coins to the address that is owned by our custody. After that fast and secure transfers are possible in our blockchain. But instead of changing balances in a “spreadsheet”, as we described for the case of centralized custody, it will be done via a smart contract deployed on the Velas chain.

So does it mean that we’ve achieved our goal? The fastest and cheapest transactions of all cryptocurrencies on the fastest chain! But you’ve probably spotted that there is yet one unresolved question. While we can make fast transactions inside our chain, and Bitcoins (or others) are in custody, the question of exiting the custody remains. And here we enter the problem that for a decade prevented us all from creating a truly decentralized custodian.

To exit custody, we need to make a transaction from the custodian to the user. But we cannot achieve this just by invoking the protocol for restoring the secret key of the custodian. Because in this scenario every validator will be able to sign a transaction that demands the coins to be transferred to his own address. And one of these transactions can get into the block that will be mined first in the Bitcoin network, instead of the one that should have been signed in the first place. So we can see clearly that we need a way to sign transactions in a distributed manner, without restoring the secret key itself. And to understand why it is a huge problem we need to dive deeper into mathematical details of the underlying protocols.

We will start with basic definitions and slowly will go deeper into the details of the needed protocols. Later we will briefly describe existing solutions, their problems, and motivation for the solution we’ve picked.

Mathematical descriptions

Basic Definitions and Schemes

p denotes the set of all integers from 0 to p − 1 with operations of addition and multiplication performed modulo p. ℤp will be the set of scalars that will be multiplied by G — the base point of the elliptic curve that is used in the digital signature scheme from the considered cryptocurrency network. For example, p = 2256 − 232 − 29 − 28 − 27 − 26 − 24 − 1 for the case of secp256k1 that is used in ECDSA for Bitcoin and Ethereum systems. But in Solana, a different number p is used for the curve Ed25519 in EdDSA, and there are other examples too.

So why do we need these scalars (multipliers)? The answer is very simple: in every public-key elliptic curve cryptography scheme, the secret key sk is just an element of ℤp. The corresponding public key is always sk ∗ G, where, again, G is the base point of the curve. Now we can move to the signature scheme itself.

For simplicity of arguments, we will only consider the ECDSA used in Bitcoin, Ethereum and others. In this signature scheme, when a user has a secret key sk, the corresponding public key pk, a message m to be signed, coded as an element of ℤp, the two protocols for signing and verification are:

Protocol 1. Sign (m, sk, pk)

  1. Sample a random element k ∈ ℤp.
  2. Compute the curve point R = k ∗ G, and its x-coordinate rx (mod p).
  3. Compute the signature sig = (m + sk ∗ rx) ∗ k−1 (mod p).
  4. Publish the pair (rx, sig).

Protocol 2. Verify (rx, sig, pk, m)

  1. Compute the curve point V = (m ∗ G + rx ∗ pk) ∗ sig−1
  2. Accept the signature if and only if the x-coordinate of V matches rx modulo p.

Now we move to the decentralized setting. It will involve n parties (validators, servers, nodes) that can communicate with each other by the ways of secure channels, meaning that only intended recipients will understand the messages sent. As we’ve seen, the first task is to create a secret in a decentralized way.

Our goal is to allow any subset of t of them to sign a message, and at the same time to prevent subsets of t − 1 or less parties from gaining any information about the secret key. This problem is called t-of-n threshold digital signature. It should be clear that in such a setting t should represent the supermajority of custodians, and that neither sk nor k can be stored in one place (be in the possession of one entity).

Underlying MPC Protocols

Therefore, important questions of multiparty computations arise, when several parties sign the message (evaluate the expression above) without knowing neither sk nor k. The standard technique to resolve this issue is called secret sharing. We will explicitly derive the details on the following pages for readers to obtain a deeper understanding of the main principles and common pitfalls in this fascinating but complicated topic.

However, let’s first suppose for a second, that we already distributed the additive secret shares sk1, sk2, … , skt and k1, k2, … , kt of an sk and k respectively such that sk1 + sk2 + … + skt = sk and k1 + k2 + … + kt = k. Would it help us sign the document via the aforementioned protocol? We can easily compute R = R1 + R2 + ⋯ + Rt, where Ri = ki ∗ G for the signing phase, and pk = pk1 + pk2 + ⋯ + pkn, where pki = ski ∗ G for the verification phase, but how do we proceed with the computation of sig itself?

If you take one more look at the main formula

sig = (m + sk ∗ rx) ∗ k−1 (mod p),

you may notice that it takes more to sign a message because the signature formula involves multiplication by modular inverse of k, and there is no way to get shares of an inverse from additive shares of k without revealing k itself.

We would therefore like to generate the shares of k in some specific way that will allow us to obtain the secret shares of k−1 as well. This subproblem is solved by a t-party inverse-sampling protocol described in greater detail in Doerner et al.

Once we do have such shares sk1, sk2, … , skt, k1, k2, … , kt and v1, v2, … , vt that sk1 + sk2 + … + skt = sk, k1 + k2 + … + kt = k and v1 + v2 + … + vt = v, we can compute the shares sig1, sig2, … , sigt of a signature as sig = vi ∗ m + wi ∗ rx, where w1, w2, … , wt, are the shares of sk ∗ k−1, computed by yet another supplementary protocol for multiparty multiplication. The signature is then restored as sig= sig1 + sig2 + … + sigt.

Now that the main concept is clear, we’ll delve into the details.

The first important question is how to distribute shares of the secret key between nodes in a decentralized custodian system. One of the best ways to do this is to use polynomial secret sharing, or as it is better known, Shamir Secret Sharing Scheme.

In this scheme, nodes have assigned addresses i1, i2, … , in, which are some elements of ℤp. To make a t-of-n threshold secret sharing of secret element sk from ℤp, we randomly pick t− 1 field elements c1, c2, … , ct-1 from ℤp and use them as coefficients of a polynomial Psk(x) = sk + c1 ∗ x + c2 ∗ x2 + … + ct-1 ∗ xt-1 of degree t − 1 with the free term equal to sk. After that we create n shares for our scheme: (i1, Psk(i1)), (i2, Psk(i2)), …, (in, Psk(in)). Later another polynomial Pk is constructed in the same way to distribute the secret shares of k.

Knowing t of such shares allows us to restore the secret with a little help from the classical Lagrange interpolation theorem, which states that


where I is any subset of t parties from {i1, i2, … ,in}.

The current version of the sharing scheme involves a so-called dealer, who knows sk and distributes the shares. It is therefore not suitable for our needs, because we assume that no party (including the user) knows sk. However, a minor adjustment of the scheme easily addresses this problem.Instead of selecting a polynomial by ourselves, we allow parties to generate their own polynomials Psk, i, and then define Psk to be their sum.

The shares are then defined in the same way as before. To compute them, each party i broadcasts the values Psk, i(j) for all j = i1, i2, … , in and learns the values of Psk, j(i) from all other parties with j = i1, i2, … , in. Finally, it reconstructs Psk(i) as the sum of the learned values.

This version is sometimes typically referred to as Shamir secret sharing with no dealer.

It is also a basis for widely used subprotocols, such as Biased Random Number Generation (BRNG), Random Zero Generation (RZG), and (unbiased) Random Number Generation (RNG), which allow multiple parties to generate a common random number in a decentralized fashion.

Note that we never compute Psk explicitly not to reveal sk. It is also worth noting that this version is not subject to bias, as the sum of any number of random variables from ℤp is uniformly distributed as long as at least one of the variables is uniformly distributed. Note that this statement is the same as the assumption of the absence of t adversarial parties.

Finally, note that each share is a pair of field elements from ℤp and it is only useful in the secret sharing they were created for and gives no information without other shares from its initial creation.

Now that we defined how shares are created, let us describe the details of the above-mentioned multiparty multiplication protocol. For this part, we encourage you to think about sk and k in terms of their respective polynomials Psk and Pk. To state the problem clearly, we want to multiply sk and k without revealing them, using only operations with Psk and Pk.

The straightforward way to do this is to multiply the polynomials themselves. The constant terms will then multiply as well. The polynomial multiplication can be easily performed if every party i multiplies its secret shares of sk and k, as (Psk ∗ Pk)(i) = Psk(i) ∗ Pk (i). To put it simply, the secret shares of the product are the products of secret shares of the multipliers.

The Fundamental Problem of Naive MPC Multiplication

However, notice that after we multiply two polynomials of degree t - 1, the degree of their product is not t - 1 but 2t − 2 instead. One simple example of this is x ∗ x = x2, where we get a polynomial of degree 2 from two polynomials of degree 1. In particular, this implies that in order to interpolate the product polynomial we now need 2t − 1 honest parties.

Not only does this impose a condition 2t − 1 ≤ n or tn/2, which is clearly not the supermajority we are aiming for, but it also creates the gap requirement m ≤ (n - (2t - 1))/2 on the number m of adversarial parties, due to the Reed-Solomon error correction code. These inequalities combined give us a bound of tn/6 for the practical scenario of m = n/3.

It is possible to avoid the latter bound with Pedersen commitments, but it will not remove the former problem, which has its roots in the naive polynomial multiplication.

This problem is fundamental and prone to the following logical error: one may think that if we need 2t - 1honest nodes to sign the message, then the adversary would also need to corrupt 2t - 1parties in order to forge a signature. This is, however, completely wrong, as the adversary needs not follow the protocol and can simply restore sk and k from only t shares.

This asymmetrical situation feels odd and is not appealing to the public. As a real-life example, imagine having two locks at your door. You need both keys to open it, but everyone else can enter your house with one key only. Sounds weird, right?

The same issue was encountered in RenVM whitepaper, but was not resolved at the time.

However, more recent protocols allow any t parties to sign while being resistant against an adversary controlling t − 1 parties. We’ll summarize some of these here. Canetti et al. proposed a solution that allows for strong identifiable aborts and fast one-round online signing, removing all the hard computations to the offline stage. Gennaro et al. also offers identifiable aborts and more efficient computations achieved by limiting the use of zero-knowledge proofs. This protocol also provides a possibility of proactive key refresh (which is especially useful in the presence of cold wallets).

Gągol et al. proposed what was at the time the first dishonest majority threshold protocol, robust in the signing phase. In Doerner et al., very few security assumptions are made. However, the number of rounds in the protocol presented in this paper increases logarithmically with t which might make it slower for larger systems.

After thoughtful consideration of all these protocols, we arrived at the solution that combines their best practical parts. Soon we will publish a follow-up paper describing our approach in greater detail.

Concensus Mechanism & Tokenomics

Concensus Mechanism

Before starting the implementation of the Velas Blockchain our team was researching all the possible solutions to find the one that is the most suitable for a decentralized, scalable and secure network with the potential of onboarding billions of users.

To find the solution we have analyzed a total of 48 consensus mechanisms including 34 proof-based, 7 vote-based, and 8 alternatives (DAG-based) solutions.

Having reviewed most of the existing consensus mechanisms, we can summarize that the compute-intensive-based consensus protocols suffer from the issues of high energy consumption, environmental pollution, low transaction throughput, and low scalability.

On the other hand, the capability-based protocols solve the issue of high energy consumption but tend to be biased towards the rich (wealth dominance) and more prone to malicious attacks.

The voting-based protocols solve the issues of high computational energy consumption, low transaction throughput, and scalability in the compute-intensive-based protocols but they make the network less decentralized. Moreover, the number of data transfers is high in voting-based protocols, leading to higher energy consumption.

It should be stated that a need exists for an energy-efficient, decentralized, high transaction throughput, and highly scalable blockchain consensus protocol to address the misalignment between the existing protocols and the customer services where applications are evolving rapidly to meet the requirements of a collaborative large-scale ecosystem.

Therefore, the DPoS consensus mechanism has been chosen as the most appropriate solution that with wise settings could meet all requirements on the network and network participants level:

  • It is much more scalable and PoW and traditional PoS consensus
  • It is democratic and encourages a decentralized manner of network governance due to the role of delegates in the network
  • The entrance threshold in DPoS consensus is extremely low which makes it one of the most decentralized of existing consensus mechanisms
  • DPoS mechanisms have strong protection from double-spend attacks.

However, there are a lot of variables in such complex technologies as consensus mechanisms. Thus, the proper setting and correctly established rules of interaction within the network is required.


General Overview

Tokenomics are the economic rules of behavior and interaction of participants in the blockchain network. Velas AIDPoS consensus is based on DPoS economics, and AI does not affect tokenomics at all. A set of rules has been established to provide participants with the most favorable conditions for interaction with each other and motivate them to act for the benefit of the network.

Basic VLX metrics:

  • Total supply - 2,124,380,663 VLX;
  • Circulating Supply - 1,419,198,849 VLX;
  • Inflation rate - 8% annually

Velas has inherited most of the settings designed by Solana. Below you will find documentation related to the parts of Velas’ Tokenomics that come from Solana:


We have implemented some changes comparing to Solana’s tokenomics regarding the amount of tokens participants should have to apply to the particular role:

  1. To become a Validator user should have at least 1 mln of VLX Tokens
  2. To become a Delegator user should have at least 10.000 VLX Tokens

There are two options for staking in the Velas system — creating your own pool and becoming a validator or Join an existing pool as a delegator.

DPOS (Delegated Proof of Stake) provides the opportunity for delegators to “vote” on potential validators by staking tokens on them and increasing their chances of becoming validators.