12 min read

Overview

Most blockchains are transparent by default. Every transaction, balance, and contract interaction is visible to anyone. That works for trust and auditability, but it becomes a problem when applications handle sensitive data: financial records, medical credentials, identity documents, or trading strategies.

Aleo is a Layer 1 blockchain that flips this default. It's built around zero-knowledge cryptography from the ground up, so developers decide exactly which parts of a transaction are public and which stay hidden, enforced by math rather than trust assumptions. The private computation runs on the user's device, and the network receives a cryptographic proof and any encrypted outputs, not the raw inputs.

TL;DR

• Aleo is a privacy-first Layer 1 blockchain where private computation runs on the user's device, and the network receives zk-SNARK proofs (compact cryptographic proofs that something is true without revealing why) and encrypted outputs instead of raw inputs
• snarkVM (AleoVM) executes Leo programs locally and generates zero knowledge proofs. Validators only verify these proofs rather than re-executing every transaction
• AleoBFT is a DAG-based BFT (Byzantine Fault Tolerant, meaning the network works even if some participants are malicious) consensus protocol with up to 200 validators (minimum 10M ALEO stake) and an unlimited set of provers who earn rewards through Proof of Succinct Work
• Leo is a statically typed, Rust-inspired language that compiles to zk-SNARK circuits. Functions (fn) run offchain to generate proofs, and final {} blocks run onchain to update public state
• Aleo programs store private state in encrypted records (similar to UTXOs, the unspent output model Bitcoin uses, except encrypted so only the owner can decrypt) and public state in mappings (key-value stores readable by anyone, modified by onchain logic)

What You Will Learn

• How Aleo's architecture separates computation from verification with an offchain/onchain split
• What snarkVM and snarkOS do in the execution and consensus layers
• How AleoBFT consensus coordinates validators and provers to produce blocks with instant finality
• The Leo programming language: how it compares to Solidity, its visibility modifiers, and the offchain/onchain execution model for bridging private computation with public state
• Transaction types, fee mechanics, and the privacy model (records, mappings, and visibility modifiers)

What You Will Need

• Familiarity with general blockchain concepts (transactions, blocks, consensus)
• Basic programming knowledge (the Leo examples use Rust-like syntax)
• No zero-knowledge cryptography experience needed. The guide explains relevant concepts as they come up
• A Quicknode account (if you plan to deploy and interact with Aleo programs via RPC)

What Problem Does Aleo Solve?

To understand why Aleo exists, consider three scenarios that existing public blockchains handle poorly:

1. A payroll contract that pays employees onchain. On traditional blockchains like Ethereum, every salary amount and recipient address is permanently visible to anyone scanning the chain.
2. A credential verification system where a user proves they are over 18 without revealing their date of birth, passport number, or any other personal detail.
3. A trading strategy that executes a DeFi swap. On a transparent chain, the pending transaction sits in a public mempool, exposing it to front-running bots that extract value before the trade settles.

All three require selective disclosure: the network needs to verify that the computation is correct, but it shouldn't need to see the inputs or outputs that make it sensitive.

Aleo addresses this by combining a zero-knowledge virtual machine (snarkVM/AleoVM) with a privacy-aware programming model (Leo), connected through a consensus layer (AleoBFT) that verifies proofs rather than re-executing computations.

Architecture Overview

Aleo's architecture has three main layers, each built for zero-knowledge workloads rather than being retrofitted onto an existing chain.

The Three Layers

Layer	Component	Role
Execution	snarkVM	A zero-knowledge virtual machine that runs programs locally and generates proofs of correct execution
Networking	snarkOS	Node software handling peer-to-peer communication, proof verification, and state storage
Consensus	AleoBFT	A DAG-based BFT protocol combining proof-of-stake (validators) with proof-of-succinct-work (provers)

snarkVM: The Execution Engine

snarkVM is Aleo's equivalent of Ethereum's EVM, but with a major difference: instead of every node re-executing every transaction, only the user's machine runs the private computation. The network receives a proof that the computation was performed correctly, verifies it, runs any public finalize logic, and updates the ledger.

What this means in practice:

• Sensitive inputs never leave the user's device. A token transfer can hide the sender, receiver, and amount from the network while still proving the transfer is valid (no double spending, sufficient balance, etc.).
• Verification is cheaper than execution. A proof that took seconds to generate can be verified in milliseconds. Validators do less work per transaction than in re-execution models, which is where the scalability comes from.
• Programs compile to arithmetic circuits. Leo code compiles down to Aleo Instructions, which snarkVM converts into R1CS (Rank-1 Constraint Systems), the mathematical structure that zk-SNARK provers and verifiers operate on.

snarkOS: The Network Layer

snarkOS is the node software that ties everything together. It handles:

• Peer-to-peer networking between validators, provers, and client nodes
• Proof verification: when a transaction arrives, snarkOS verifies the zk-SNARK proof before it enters the candidate block
• Ledger management: storing encrypted records (private state) and public mappings (public state) in a verifiable format
• Transaction propagation: broadcasting transactions and proofs across the network

Client nodes are the entry point for users. They accept locally generated proofs and submit them to validator nodes for inclusion in consensus.

How a Transaction Flows Through the Stack

Here's the lifecycle of a single program execution, from the user's device through to finality:

Steps 1-4 happen entirely on the user's machine. The network never sees the raw inputs. Steps 7-9 happen on validators, but they only verify the proof and execute any onchain logic (the final block). They don't re-run the private computation.

AleoBFT Consensus

AleoBFT is a hybrid consensus mechanism that separates two concerns: who decides block ordering (validators) and who generates cryptographic proofs (provers). This lets the network scale proof generation independently from consensus.

How AleoBFT Works

AleoBFT is a DAG-based Byzantine Fault Tolerance protocol inspired by two research primitives:

• Narwhal: a mempool protocol for data availability. Validators batch transactions, exchange them with peers, and collect signatures to certify that data is available before consensus begins.
• Bullshark: a consensus protocol that orders the DAG. One validator is elected as the leader each round, and their batch becomes the anchor (the reference point that determines which transactions get committed and in what order).

The flow works in rounds:

Consensus alternates between even and odd rounds. In an even round, one validator is elected leader. Say that's Validator A: it bundles pending transactions into a batch and broadcasts it to Validators B, C, and D. This batch is the anchor for that round.

In the next (odd) round, the other validators broadcast their own batches, and each batch references at least n - f batches from the prior round, where n is the total validator count and f is the maximum number of faulty validators. If Validator B's batch references Validator A's anchor, that counts as an implicit vote for it. No separate voting message is needed; the DAG references are the votes.

Once at least f + 1 validators have referenced the anchor, it commits. Every transaction reachable from the anchor gets ordered by a deterministic rule and added to the ledger. The result is instant finality: once committed, a block cannot be reverted.

Validators vs. Provers

	Validators	Provers
Role	Produce blocks, verify proofs, maintain consensus	Generate zk-SNARK proofs, solve coinbase puzzles
Staking	Minimum 10,000,000 ALEO at the time of writing (current requirements)	No staking required
Hardware	Standard server infrastructure	GPU/CPU intensive (proof generation)
Reward	Block reward (base ~23.8 ALEO per block at the time of writing, adjusted dynamically via ARC-42)	Coinbase puzzle rewards (Proof of Succinct Work)

ARCs (Aleo Request for Comments) are the governance proposals for the Aleo network, similar to Ethereum's ERCs. They define protocol changes like reward schedules, consensus parameters, and token standards. | Set size | Maximum 200 validators | Unlimited |

Stakers can delegate a minimum of 10,000 ALEO to validators, which lets them earn consensus rewards without running validator infrastructure.

Proof of Succinct Work (PoSW)

Provers compete to solve coinbase puzzles, which are cryptographic challenges that require generating valid zk-SNARK proofs. This does two things:

1. It incentivizes building out proof generation infrastructure (GPUs, ASICs) that the broader ecosystem can use
2. It distributes newly minted tokens to participants who contribute computational resources

Unlike Bitcoin's proof of work, where the computation itself is thrown away, the work done by provers in PoSW produces useful cryptographic proofs.

The Privacy Model: Records and Mappings

Aleo programs can store state in two different ways. Which one you pick depends on whether the data should be public or private.

Records (Private State)

Records are Aleo's private data structure, conceptually similar to Bitcoin's UTXO model but with programmable fields:

• Encrypted onchain: stored as ciphertext in the ledger. Only the record owner can decrypt them.
• Owner-controlled: each record has an owner field (an Aleo address). Only the owner can consume or modify the record.
• Consumed, not updated: when a record is used in a function call, it's consumed (spent) and new records are created as outputs, similar to Bitcoin UTXOs.
• Nonce-protected: each record carries a nonce that prevents replay attacks and provides unlinkability.

Mappings (Public State)

Mappings are key-value stores that live transparently onchain, similar to Solidity's mapping type:

• Publicly readable: anyone can query a mapping's state through a block explorer or API.
• Modified onchain: only the final block of a function (the onchain portion) can read or write mappings.
• Good for shared state: token balances that should be publicly auditable, governance vote tallies, or protocol configuration parameters.

Choosing Between Records and Mappings

If the data needs to be visible to everyone, use a mapping. If it should stay private, use a record. A token program might store public balances in a mapping (so anyone can verify total supply) while also supporting private transfers using records (so individual transaction details stay hidden). Both can exist in the same program, and you can build functions that convert between public and private state.

View Keys

Every Aleo account has three key types:

• Private key: signs transactions and spends records.
• View key: decrypts all records and transaction details for the account, without the ability to spend anything.
• Address (Public key): the public identifier derived from the private key.

The view key is useful for compliance. An entity can share its view key with an auditor, giving them read access to all transaction history without giving up control of funds.

The Leo Programming Language

Leo is a statically typed, Rust-inspired language designed for writing zero-knowledge programs on Aleo. It hides the underlying cryptography from you: you write logic in a familiar imperative style, and the compiler handles circuit generation, proof construction, and the onchain/offchain split. As of Leo 4.0, the language uses fn as the universal function keyword and final {} blocks for onchain logic, replacing the older transition/async function syntax.

Leo vs Solidity at a Glance

If you're coming from Solidity, here are the main differences:

Aspect	Solidity	Leo
Execution	Fully onchain, all nodes re-execute	offchain (fn) + onchain (final {} block)
Privacy default	Everything public	Everything private unless marked public
State model	Account-based storage (all public)	Records (private, UTXO-like) + Mappings (public)
Visibility	private controls code access, not data	private means cryptographic data privacy via ZK proofs
Type system	uint256, bytes, string	u128 max, plus field, group, scalar for ZK circuits
Loops	Unbounded	Bounded only (compiled to fixed circuits at compile time)
Strings	Native support	No native strings
Cost model	Gas per opcode	Storage cost + finalize computation cost

Here's a minimal Leo program showing the basic structure:

program hello.aleo {

    // Private record that only the owner can decrypt
    record Message {
        owner: address,
        data: u128,
    }

    // Entry point: runs offchain, generates a ZK proof
    fn create_message(
        private receiver: address,
        private data: u128,
    ) -> Message {
        return Message {
            owner: receiver,
            data: data,
        };
    }

    @noupgrade
    constructor() {}
}

A few things to notice: fn defines entry points inside a program block. Every parameter defaults to private, meaning the values are hidden from the network. The record type creates encrypted, owner-controlled state similar to Bitcoin UTXOs. This program runs entirely offchain: the caller gets a ZK proof and an encrypted Message record, and the network only verifies the proof.

note

This example only uses private state (records). Programs that need public state would also include a mapping and use final {} blocks to update it onchain. We cover those concepts later in the Offchain/Onchain Execution Model section and in the Build and Deploy guide.

note

This guide covers Leo's core concepts at an introductory level. For in-depth coverage of program structure, data types, built-in cryptographic operations, and complete program examples, see the Leo documentation.

Visibility Modifiers

Every input and output of a function can be marked as public, private, or constant. The default is private:

// `sender` is hidden; `amount` is visible onchain
fn transfer(
    private sender: address,
    public amount: u64,
) -> bool {
    // ...
}

This gives you fine grained control. You could build a function where the transferred amount is public (for regulatory compliance) but the sender and receiver stay private.

The Offchain/Onchain Execution Model

This is probably the most interesting part of Leo's design. The language splits every operation into two phases that map directly to Aleo's offchain/onchain architecture:

Phase 1: fn (offchain)

• Runs on the user's device
• Has access to private inputs (records, private parameters)
• Generates a zero-knowledge proof of correct execution
• Can create and consume records
• If the function has onchain work, it returns the Final type (or a tuple like (Token, Final))

Phase 2: final {} block (onchain)

• Runs on validators after the proof is verified
• Has access only to public parameters and captured variables (like self.caller)
• Can read and write mappings and storage variables
• Cannot access private state or generate proofs
• All inputs are visible to validators and the network

This two-phase model is what makes Aleo's hybrid privacy work: the private computation proves its correctness offchain, and the public state updates happen onchain with full transparency.

Transaction Types and Fees

Aleo has three transaction types:

Type	Purpose	What Happens
Deploy	Publish a new program to the network	The Leo-compiled bytecode is stored in the onchain program registry. Fees scale with program size (storage cost) plus a synthesis cost based on circuit complexity. Program names shorter than 10 characters incur a namespace fee that increases as the name gets shorter, similar to how short domain names cost more since they're scarcer and more desirable.
Execute	Call a function on a deployed program	The user generates a proof locally and submits it with encrypted outputs. Validators verify the proof and run any final block logic. Fees scale linearly for transactions under 5KB, and quadratically above that threshold.
Fee	Pay for transaction processing	Attached to every deploy or execute transaction. Can be paid publicly (from a mapping balance) or privately (from an Aleo Credits record).

Fee Mechanics

Fees are calculated based on two factors:

1. Transaction size: the raw byte count of the serialized transaction.
2. Validator computation: how much onchain finalize logic the validators need to execute.

For deployments, there's also a synthesis cost proportional to the number of variables and constraints in the compiled circuit (num_variables + num_constraints), plus a storage cost of 1 millicredit per byte of program data.

Next Steps

To go deeper from here:

Start building

• Install Leo and scaffold your first program with the official Leo documentation
• The Aleo Developer Documentation has API references, deployment guides, and SDK options
• The Leo by Example section has complete working programs (tokens, auctions, voting)

Explore privacy patterns

• Dig into the record model: how records are consumed and created, how nonces prevent replay attacks, and how view keys enable selective disclosure
• The offchain/onchain execution model documentation covers advanced patterns like cross-program calls and composed Futures

Conclusion

Aleo takes a different approach to blockchain design. Privacy isn't a feature bolted onto a transparent system; it's the architectural foundation. offchain execution (snarkVM), a privacy-aware language (Leo), and a consensus mechanism built to scale proof generation (AleoBFT) together give developers a platform where applications can handle sensitive data without forcing users to choose between privacy and verifiability.

The core idea is separating computation from verification. Users prove their transactions are valid without revealing what those transactions contain. That's also a scalability win, since verification is orders of magnitude cheaper than re-execution.

If you're building private DeFi, credential verification, confidential governance, or anything where users should control what they reveal, Aleo gives you the tools to do it at the protocol level rather than retrofitting it after the fact.

Frequently Asked Questions

What is the Aleo blockchain?

Aleo is a privacy-first Layer 1 blockchain that launched its mainnet in September 2024. Programs execute on the user's device using snarkVM, and only a compact zk-SNARK proof is submitted to the network for verification. This means validators confirm that a transaction is valid without ever seeing the underlying inputs or outputs. Aleo uses the Varuna proof system (an evolution of Marlin) for its zk-SNARKs.

What is the Leo programming language?

Leo is a statically typed, Rust-inspired language for writing zero-knowledge programs on Aleo. As of Leo 4.0, you write functions using the fn keyword, and the compiler handles circuit generation, proof construction, and the split between offchain execution and onchain verification. Leo supports integers, cryptographic field types, structs, records, and built-in hash functions like BHP, Pedersen, Poseidon, and SHA3.

How does Aleo achieve privacy onchain?

All computation happens offchain on the user's device. When you call a program function, snarkVM runs it locally and generates a zk-SNARK proof of correct execution. The proof and any encrypted outputs go to the network, but the raw inputs never do. Validators verify the proof mathematically without seeing the original data. Leo's visibility modifiers let developers mark each function parameter as public or private, so you control exactly what the network can see.

What is the difference between records and mappings in Aleo?

Records are private, encrypted data structures similar to Bitcoin UTXOs. They are stored as ciphertext on the ledger, and only the record owner can decrypt them. When used in a transaction, records are consumed and new ones are created. Mappings are public key-value stores, similar to Solidity mappings, that anyone can read. Only the onchain final block of a function can modify mappings. A single program can use both, for example tracking public total supply in a mapping while handling private transfers with records.

What is AleoBFT consensus and how does it work?

AleoBFT is a DAG-based Byzantine Fault Tolerance protocol that separates block ordering from proof generation. Up to 200 validators (each staking a minimum of 10,000,000 ALEO) produce blocks and verify proofs, while an unlimited set of provers generates zk-SNARK proofs and earns rewards through Proof of Succinct Work. The protocol is inspired by Narwhal (for data availability) and Bullshark (for consensus ordering), and it provides instant finality once a block is committed.

How does Aleo compare to other privacy blockchains like Zcash?

The biggest difference is programmability. Aleo is a general-purpose L1 with full smart contract support through Leo, while Zcash only handles private transactions with limited scripting. Aleo also runs computation offchain and sends proofs to validators, while Zcash processes transactions onchain. They use different proof systems too: Varuna for Aleo, Halo 2 for Zcash. On the privacy model side, Aleo gives you per-variable visibility control, while Zcash splits funds into fixed shielded and transparent pools.

What is snarkVM and how does it differ from the EVM?

snarkVM is Aleo's zero-knowledge virtual machine. The main difference from the EVM: instead of every node re-executing every transaction, snarkVM runs computations only on the user's device and produces a zk-SNARK proof of correctness. Validators verify the proof instead of replaying the execution. Sensitive inputs never leave the user's machine, and proof verification is orders of magnitude cheaper than re-execution.

We ❤️ Feedback!

Let us know if you have any feedback or requests for new topics. We'd love to hear from you.