Vela Network Whitepaper

A Custom Layer-1 Blockchain Built From Scratch in Rust

Author: Gaurav Sharma·Version 0.1·April 2025

Table of Contents

  1. Abstract
  2. Introduction
  3. Consensus: HotStuff BFT
  4. Network Layer
  5. Cryptography
  6. Tokenomics
  7. Roadmap
  8. Conclusion

1. Abstract

Vela is a Layer-1 blockchain I wrote from scratch in Rust. It's not a fork. The consensus, networking, transaction processing, and state management are all my own code. It runs on a live testnet right now with an explorer, wallet, and faucet.

2. Introduction

I wanted to understand how blockchains actually work, not just at the API level but all the way down. Most projects fork Geth or build on Cosmos SDK, which is fine for shipping a product, but you don't really learn what's happening under the hood that way.

So I built Vela from an empty cargo new. Every struct, every message type, every state transition is written by hand. The goal was simple: if I can build a working blockchain from nothing, I actually understand the technology.

I picked Rust because it's fast, memory-safe without a garbage collector, and has great async support through Tokio. The type system also catches a lot of bugs at compile time, which matters when you're dealing with consensus logic.

The project only depends on a few well-known libraries: ed25519-dalek for signatures, blake3 for hashing, libp2p for networking, axum for the HTTP API, and sled for storage. Everything else is written from scratch.

3. Consensus: HotStuff BFT

Vela uses HotStuff BFT for consensus. It's the same protocol family that Aptos uses (originally designed for Facebook's Diem). I chose it over simpler options like PoA or Raft because I wanted to implement real Byzantine fault tolerance, and HotStuff has a clean design that's easier to get right than PBFT.

3.1 Why HotStuff?

The main advantage is message complexity. In PBFT, every validator talks to every other validator in each phase, so you get O(n²) messages. HotStuff funnels everything through the leader, so it's O(n) per phase. That means it can scale to more validators without the network getting overwhelmed.

It also gives you deterministic finality. Once a block is committed, it's done. No waiting for 6 confirmations like in Bitcoin.

3.2 Three-Phase Commit

How it works
Prepare → The leader proposes a block and sends it to all validators. They check it and vote.
Pre-Commit → The leader collects votes into a Quorum Certificate (QC), which proves enough validators agreed.
Commit → With 2f+1 matching votes, the block is final.

3.3 Fault Tolerance

The rule is n = 3f + 1, where f is the number of bad nodes you can tolerate. The testnet runs 3 validators, which is the minimum to demonstrate the protocol structure. The code supports any validator set size.

4. Network Layer

Networking uses libp2p, the same stack that Ethereum 2.0 and Polkadot use. I didn't want to write my own TCP framing and peer management from scratch when a battle-tested library exists.

4.1 Transport

Connections run over TCP with Noise encryption and Yamux multiplexing. Every connection is encrypted and authenticated automatically.

4.2 Gossipsub

Messages are broadcast using Gossipsub, a pubsub protocol designed for blockchains. There are three topic channels:

4.3 Peer Discovery

On a local network, nodes find each other automatically through mDNS. For remote nodes, you pass bootstrap addresses via the CLI or they're hardcoded in the binary. When a node starts up, it waits 2 seconds for connections and then sends a sync request to fetch any blocks it missed.

5. Cryptography

5.1 Ed25519

Every transaction and consensus vote is signed with Ed25519. I picked it over secp256k1 (what Bitcoin and Ethereum use) because it's faster to verify, the keys are smaller (32 bytes each), and signatures are deterministic so there's no risk of nonce-reuse bugs.

A Vela address is just the raw 32-byte public key with a vela: prefix. No hashing or encoding on top.

5.2 Blake3

All hashing (block hashes, tx hashes, Merkle roots, signing payloads) uses Blake3. It's significantly faster than SHA-256, supports parallel hashing, and has a large security margin. It's based on the same family as BLAKE2 and ChaCha.

6. Tokenomics

Token Parameters
Name: VELA
Total Supply: 1,000,000,000 (1 billion)
Smallest Unit: nVELA (1 VELA = 1,000,000,000 nVELA)
Transaction Fee: Minimum 1 nVELA per transaction

6.1 Genesis Distribution

On testnet, the entire supply starts in a faucet wallet. This is the simplest approach for a test network. On a real mainnet you'd want a proper allocation plan.

6.2 Faucet

The faucet gives out 10,000 VELA per request with a 24-hour cooldown per address. It works just like a normal transaction: the faucet has its own Ed25519 key, signs the tx, and it goes through the same mempool and validation pipeline as everything else.

6.3 Validator Rewards (planned)

The plan is to add staking and block rewards later. When a leader successfully proposes a block, they'll collect the transaction fees from the included transactions.

7. Roadmap

Phase 1: Core Protocol
Block/tx types, HotStuff BFT, libp2p, Ed25519, sled storage
Phase 2: Testnet
Deployed on Railway with explorer, wallet, and faucet
Phase 3: Validation
Nonce checks, balance checks, mempool dedup, chain sync
Phase 4: Network
Bootstrap peers, sync protocol, better peer management
Phase 5: Smart Contracts
Programmable transactions, on-chain logic
Phase 6: Mainnet
More validators, staking, governance

8. Conclusion

Vela is a working blockchain written from scratch. The whole point was to prove that you can build one without forking someone else's code, and to actually learn how every piece fits together in the process.

All the code is open source. If you want to understand how blockchains work at the implementation level, reading through this codebase is a good place to start.

Source: github.com/OrDex78/vela-network