How Velas works: Proof of History, an EVM and delegated staking

To understand Velas you need three building blocks: a way to order events quickly, a way for validators to agree, and a way to run smart contracts. Velas takes the first two from Solana and adds an Ethereum-compatible execution layer. Here is how those pieces connect.

Proof of History: a clock for the network

Most blockchains waste time because nodes have to argue about what happened first. Solana's answer is Proof of History, a chain of hashes where each step proves some time has passed since the last. Think of it as a shared stopwatch built from maths. Because every node can verify the ordering rather than negotiate it, blocks can be produced in a fraction of a second. Velas inherited this design from the Solana codebase, which is why block times are short. You can compare the current block height and activity on the native explorer.

Tower BFT and validator voting

Ordering is not the same as agreement. Validators still need to vote on which fork is canonical. Tower BFT is the voting protocol, a variation of practical Byzantine fault tolerance that uses the Proof of History clock to make votes progressively harder to reverse. Each vote locks a validator into a fork for a growing period, so switching sides becomes expensive. A transaction becomes safer as more stake-weighted votes pile on top of its block.

Delegated proof of stake

Validators need stake to participate, but you do not have to run a server to earn a share. VLX holders delegate coins to a validator they trust. The validator votes with that weight and keeps a commission from the rewards; delegators get the rest. Delegation does not transfer ownership: your coins stay in your stake account and you can redelegate later. The official site shows the number of validators and total staked, and a healthy network has many validators with no one operator dominating. Our validators page shows how to evaluate them and our staking guide shows the process.

The embedded EVM

The Ethereum Virtual Machine is the runtime that executes Solidity bytecode. Velas embeds one beside its native runtime. A transaction sent to an EVM address is processed by the EVM side, using the same JSON-RPC methods that Ethereum tools expect, for instance eth_getBalance. That is why wallets like MetaMask can connect with only a network configuration. The Velas RPC for the EVM side is public, and our tracker uses it directly from your browser. See EVM compatibility for setup steps.

Two address worlds

This duality is both the feature and the learning curve. If you only ever use the EVM side, it behaves like another Ethereum-compatible network. Power users and validators interact with the native side.

Where AI is mentioned

Velas materials refer to AI-enhanced delegated proof of stake. In the documentation this is presented as machine-learning assistance on the consensus side, for example scoring validator behaviour, not as a chatbot embedded in the chain. We unpack what is and is not verifiable in the AI integration article.

What speed really means

"Up to 75,000 TPS" appears on the official site. That is a design ceiling under ideal conditions, not average daily load. For users the useful measures are different: how long until a transaction is confirmed, and what it costs. Both are good on Velas in normal conditions. For numbers, see fees and speed, and for side-by-side comparisons, Velas vs Solana.

Following a transaction through the system

It is easier to remember the architecture if you follow one transaction. A user signs a transfer in a wallet. The wallet sends it to an RPC node, which forwards it to the current block producer. The producer places it in a block, with the Proof of History clock stamping its order relative to other events. Other validators replay the block, check it against the rules and cast votes. As votes accumulate with stake behind them, the transaction moves from merely included to effectively final. At each stage the wallet or explorer can show you a status, which is why a transaction can look pending in one tool and confirmed in another that queries a different node.

If the transaction targets an EVM address, the EVM runtime executes it and computes gas costs the way an Ethereum client would, while the surrounding consensus is still the Solana-derived machinery. This is the point of the hybrid: execution is familiar to Ethereum developers, while ordering and agreement come from a different design.

What developers notice first

For a developer, the first practical differences are small and concrete: a different chain identifier, a different RPC URL, different block explorers and different tooling for the native side. Standard Solidity tooling points at the public EVM RPC at evmexplorer.velas.com/rpc and works much as it would elsewhere. Contract verification, gas estimation and event indexing can behave slightly differently from Ethereum mainnet, so it is wise to test on a small deployment first and read the documentation for any caveats rather than assuming parity in every edge case.

Limits to keep in mind

A forked codebase has to keep up with upstream improvements, and Solana has moved quickly since the fork. The Velas team maintains its own version, so features and security patches arrive on its schedule. Network liveness depends on validators staying online. These are not red flags by themselves, but they are reasons to check the project's recent activity on its documentation and the news page before depending on it.