Velas vs Solana: a fork compared with its parent

Velas used Solana's open-source code as a starting point. Since then, the projects have diverged.

What Velas adds

The main addition is the EVM, plus products such as Vault and an AI-enhanced consensus description. For Solidity developers this is a real convenience. See EVM compatibility.

What Solana has that Velas does not

A vastly bigger developer base, deeper liquidity and much more usage. Solana's improvements may not automatically flow into a fork.

Who should pick which?

If you need the largest ecosystem, Solana is the obvious choice. If you want Solidity on a fast chain and accept a smaller ecosystem, Velas is an option. Compare with Ethereum and BNB Chain in this page; the technical background is in how Velas works.

What it means to be a fork

When a project forks another, it copies the code at a certain point and then evolves it independently. Velas started from Solana, which means that its native runtime shares concepts with it: accounts holding data, programs written for a specific runtime, a fee unit called lamports, stake accounts, and validators voting on blocks. Many tools and ideas from the Solana world are therefore familiar to someone who works on the Velas native side. At the same time, a fork is not a mirror. It is a separate chain with separate validators, a separate token and a separate state, so activity, security and liquidity on Solana say nothing about the same on Velas.

The design Velas inherited

Solana is known for aiming at high throughput through a combination of techniques, among them a cryptographic clock called Proof of History that helps validators agree on ordering, a consensus protocol on top of it, and parallel execution of transactions that do not touch the same accounts. The 75,000 transactions per second claim on the Velas site refers to design capacity. How much of this design is active on the Velas network, and how it has been adapted, is described in the documentation at docs.velas.com. We cannot confirm details beyond that.

Different programming worlds

On Solana, programs are typically written in Rust and run in a runtime designed for parallelism, with an account model very different from Ethereum's. Developers who come from the Ethereum world often find this a steep change. Velas offers a bridge: its embedded EVM lets them deploy Solidity contracts and use familiar wallets while the native layer sits underneath. That is the main practical argument for choosing Velas over Solana for a team that already has Solidity code. The cost is a smaller audience, because the audience that uses Solana's native apps is not automatically present on Velas.

Maturity and network effects

Network effects matter more than architecture for most users. Solana has a large developer community, a wide range of wallets, many exchanges that support it, and substantial trading activity. It has also had well-known periods of outages and congestion, a reminder that high throughput designs carry their own operational risks. Velas has a much smaller footprint. That reduces some kinds of congestion risk but also means fewer applications, fewer audits by independent researchers, and less liquidity if you need to exit a position.

Practical differences for a holder

• SOL and VLX are different assets; you cannot send one to the other network.
• Wallets are not interchangeable by default, even if some use similar address formats.
• Staking happens with Velas validators and Velas rules, not Solana's.
• Exchange support differs widely; always check that a deposit address matches the network.

Bottom line

Treat the comparison as parent and derivative, not as rivals of equal size. If you want the biggest ecosystem in this design family, that is Solana. If you want EVM compatibility on a Solana-derived chain and can live with less liquidity, look at Velas. See fees and speed for what can be measured and validators for the security side.

How to think about the comparison

A comparison between a fork and its parent can easily become a contest, but it is more useful as a question about fit. Velas began from Solana code and added its own layers, including EVM support. Solana has its own large ecosystem and tooling. Which one suits you depends on what you want to do, not on which has the bigger headline number.

Throughput figures deserve extra care here. The claim of up to 75,000 TPS for Velas is a theoretical figure, and peak numbers on any network describe ideal conditions rather than what users experience day to day. Comparing a theoretical maximum on one chain with measured activity on another is not a fair test. If speed matters to you, measure confirmation time and fees yourself, using the explorers, over several days.

Developer experience is another factor that rarely appears in comparisons. A team that already writes Solidity may value the EVM route, while a team with Rust experience may prefer working closer to the native design. Community size, documentation and available audits all affect how quickly you can build and how easily you can find help. We do not rank the two; we suggest you test the specific features you need before committing time or funds.