Why we build on Hyperledger Besu and QBFT
The choice of blockchain engine is a one-way door. Here is why we picked a sovereign, permissioned EVM chain with states as validators.
Choosing a blockchain engine is one of those decisions you only get to make once. After comparing frameworks, we accepted a clear architecture decision: the engine is Hyperledger Besu and the consensus is QBFT. Besu is an Apache-2.0 licensed Ethereum client that can run as a fully independent, permissioned private network — its own genesis, its own chain ID, connected to no public chain.
Three reasons
- A local EVM. A programmable execution layer means the future value scenarios (authorization, escrow triggers, tokenized deposits) are already possible — a capability, not a rebuild.
- Single-chain simplicity + full sovereignty. No bridges, no dependency on an external mainnet, and — thanks to the open licence — no vendor lock-in.
States as validators
The design is deliberate: validators are states (equal vote) and full nodes are trusted institutions. QBFT comfortably handles the ~20-validator range a states-only consensus needs. A phased model lets a foundation run the validators at first and hand them to states over time — progressive decentralization with a committed, transparent path. We deliberately rejected writing our own chain from scratch: years of work and risk with no gain in sovereignty that Besu does not already give us.