Privacy-Preserving Smart Contracts on Aleo

Aleo is the only Layer 1 blockchain where smart contracts execute entirely off-chain. Zero-knowledge proofs go on-chain to verify correctness. Function inputs, outputs, and intermediate private state stay hidden. Program ID and function name are visible.

This guide explains how that works, from the execution model through the proof system. If you understand blockchain basics and want to evaluate whether Aleo's privacy model holds up under scrutiny, this is the right starting point.

On Ethereum, Solana, and nearly every other programmable blockchain, smart contract execution is fully transparent. Every input, every state mutation, every output is recorded on-chain in plaintext. That transparency is what lets any node re-execute transactions and verify the resulting state.

The tradeoff is that nothing is hidden. When you call a DeFi contract, the amount, the asset, the sender, the recipient, and your strategy are visible to every participant in the network. Even Solidity variables declared as private offer zero confidentiality. The private keyword in Solidity controls code-level visibility only (whether other contracts can call a function or read a variable). The underlying data still sits in the EVM's state trie and anyone who queries the correct storage slot can read it.

Privacy in smart contracts means something specific. There are three distinct properties:

Input privacy. The arguments passed to a function are not revealed to the network. If you transfer tokens, the amount and recipient are hidden. If you place a bid in an auction, the bid value is concealed.

Output privacy. The results of a computation (new balances, updated records, return values) are encrypted or hidden from anyone other than the intended recipient.

Function privacy. In the strongest model, external observers cannot determine which function was called or even which program was invoked. Aleo does not fully achieve this. The program ID and function name are visible on-chain because validators need them to verify the proof. The inputs and outputs of the function remain private.

Aleo achieves strong input and output privacy. A transaction reveals which program and function were called, but the data that flowed through the computation stays hidden. Validators confirm that the zero-knowledge proof is valid and that no double-spending occurred. They do not learn private input/output values.

This is not an incremental improvement over public blockchains. It is a different execution model.

On Ethereum, a user submits a transaction containing a function call and its arguments. Every validator re-executes that function against the current global state. The results are deterministic, so all validators arrive at the same output. The transaction, its inputs, and its effects are permanently recorded on-chain.

Aleo inverts this. Execution happens on the user's machine (or on a proving service acting on the user's behalf):

1. The user runs the program locally. The Aleo Virtual Machine (AVM) executes the program's function on the user's device. This computation consumes input records and produces output records, exactly as it would on-chain, but it happens entirely in the user's environment.

2. The user generates a zero-knowledge proof. During execution, the AVM produces a SNARK (Succinct Non-Interactive Argument of Knowledge) that attests to the correctness of the computation. This proof guarantees that the function was executed faithfully, that the inputs were valid, and that the outputs are correct, all without revealing what any of those values are.

3. The proof is submitted to the network. The user broadcasts the proof along with any encrypted output records. No plaintext data appears in the transaction.

4. Validators verify the proof. Network validators check the SNARK, which takes milliseconds regardless of how complex the original computation was. If the proof is valid and no records have been double-spent, the transaction is accepted and the encrypted outputs are recorded on-chain.

The point worth emphasizing: validators never execute the program. They never see the inputs. They never see the outputs. They verify a mathematical proof that the computation was performed correctly. That is enough to guarantee the integrity of the state transition.

This has several implications worth spelling out:

• Privacy is the default for records. Function inputs and outputs remain private when modeled as records. Any values written to mappings in final { } are public by design. The developer makes the choice.
• Computation scales differently. Validators only verify proofs, not re-execute programs. The on-chain cost depends on proof size and verification time, not computational complexity. A program that performs a million operations produces a proof the same size as one that performs ten.
• The user pays the proving cost. Proof generation is computationally expensive. This is the primary tradeoff: privacy and scalability come at the cost of client-side computation.

Here is a minimal example of an Aleo program written in Leo, the high-level language that compiles to AVM instructions:

program token.aleo {
    // Constructor (required for all programs)
    @noupgrade
    constructor() {}

    record Token {
        owner: address,
        amount: u64,
    }

    fn mint(owner: address, amount: u64) -> Token {
        return Token {
            owner: owner,
            amount: amount,
        };
    }

    fn transfer(input: Token, recipient: address, amount: u64) -> (Token, Token) {
        let remaining: u64 = input.amount - amount;

        let sender_token: Token = Token {
            owner: input.owner,
            amount: remaining,
        };

        let recipient_token: Token = Token {
            owner: recipient,
            amount: amount,
        };

        return (sender_token, recipient_token);
    }
}

When a user calls transfer, the entire function executes on the user's machine. The network receives a proof that the transfer was valid (no tokens created from nothing, no overflow, the input record was legitimately owned) and two encrypted output records. Nobody except the sender and recipient can read those records.

Aleo uses a record-based state model. It is a variation of the UTXO (Unspent Transaction Output) model used by Bitcoin and Zcash. The choice is deliberate: it enables privacy at the protocol level.

In Ethereum's account model, the state of the world is a single global mapping. Every address has a balance. Every contract has a storage trie. When a transfer occurs, balances are mutated in place. This is intuitive but hostile to privacy. The current balance of every account is globally visible, and every state change is a public mutation of shared data.

In Aleo's record model, state is represented as records: discrete, self-contained data objects that are created and consumed but never mutated. A record has an owner (an Aleo address) and arbitrary data fields defined by the program. Records are encrypted on-chain using the owner's address. Only the owner possesses the view key necessary to decrypt and read the record's contents.

The lifecycle of a record:

1. Creation. A function outputs one or more new records. These records are encrypted and stored on-chain. Only the designated owner can decrypt them.

2. Consumption. When a record is used as input to a transition, it is consumed (spent). The network tracks serial numbers (nullifiers) to prevent double-spending, but the link between a serial number and the original record is hidden by the zero-knowledge proof.

3. No mutation. Records are never updated in place. If your balance changes, the old record is consumed and a new record with the updated balance is created. Think of spending a $20 bill and receiving change. The original bill is gone; new bills take its place.

Why this matters for privacy:

Ownership is private. Records are encrypted on-chain. An observer sees that encrypted data exists but cannot determine who owns it or what it contains.

Transfer graphs are hidden. Serial numbers (nullifiers) cannot be linked to the records they consume without the owner's view key. The flow of value through the system is opaque. Compare this to Bitcoin, where UTXOs are plaintext and transaction graphs are fully traceable.

Any program state can be private. Records are not limited to tokens. A vote, a bid, an inventory item in a game, a credential: any of these can be a record. Arbitrary application state can be private by default.

Here is a private voting program as an example:

program private_vote.aleo {
    @noupgrade
    constructor() {}

    record Ballot {
        owner: address,
        proposal_id: u64,
        choice: u8,
    }

    record VoteReceipt {
        owner: address,
        proposal_id: u64,
    }

    fn cast_vote(ballot: Ballot, choice: u8) -> VoteReceipt {
        return VoteReceipt {
            owner: ballot.owner,
            proposal_id: ballot.proposal_id,
        };
    }
}

When a voter casts their vote, the Ballot record is consumed and a VoteReceipt is produced. The vote choice is never revealed on-chain. The voter can prove they voted (they hold a receipt) without revealing how they voted.

Not all state should be private. Some applications need globally visible, shared state: a token's total supply, the current highest bid in an auction, a governance vote tally, a price oracle. Aleo handles this through the finalize mechanism.

A Leo program can include a final { } block within a function. The function's main body executes off-chain (privately). The final { } block executes on-chain (publicly). Both are part of the same atomic operation. If either fails, the entire transaction reverts.

final fn finalize_mint_public(receiver: address, amount: u64) {
    let current: u64 = Mapping::get_or_use(total_supply, 0u8, 0u64);
    Mapping::set(total_supply, 0u8, current + amount);
}

program token_with_supply.aleo {
    @noupgrade
    constructor() {}

    mapping total_supply: u8 => u64;

    record Token {
        owner: address,
        amount: u64,
    }

    fn mint_public(public receiver: address, public amount: u64) -> (Token, Final) {
        let token: Token = Token {
            owner: receiver,
            amount: amount,
        };

        return (token, final { finalize_mint_public(receiver, amount); });
    }
}

In this example, mint_public creates a private token record (only the receiver can see it), but the final { } block updates a public total_supply mapping that anyone can read. The individual mint amounts per recipient stay private. The aggregate supply is public.

This hybrid model is one of Aleo's most important design decisions. Private state lives in records, managed through function bodies. Public state lives in mappings, managed through final { } blocks. You choose, per-field and per-function, what is private and what is public.

The properties of final { } blocks:

• On-chain execution. final { } blocks run on validators, not on the user's machine. They have access to public mappings and can read/write shared state.
• Atomic composition. The function and its final { } block succeed or fail together. No partial execution.
• Limited computation. final { } blocks have constrained computational budgets because they execute on-chain. Complex logic belongs in the function body (off-chain). Only state commitments and aggregations belong in final { } blocks.
• Public data. Anything written to a mapping in a final { } block is publicly visible. This is intentional.

This design lets Aleo programs participate in DeFi (which requires some public state for price discovery, liquidity pools, and order books) while keeping individual user positions, strategies, and balances private.

AI agents operating on blockchains face an ugly problem: strategic transparency. An agent managing a portfolio, executing arbitrage, or participating in auctions on a public blockchain exposes its entire strategy to the world in real time.

On Ethereum or Solana, every transaction an agent submits is visible in the mempool before confirmation. Competing agents (or humans) can observe the pending transaction, infer the strategy, and front-run it. After confirmation, the agent's full transaction history is a permanent public record that competitors can analyze to reverse-engineer its decision-making.

The consequences are predictable:

• Front-running. An agent's pending trades are visible and can be exploited by MEV (Maximal Extractable Value) bots that insert their own transactions ahead.
• Strategy leakage. Over time, an agent's on-chain behavior reveals its strategy. Competitors copy it, counter-trade against it, or manipulate the inputs it relies on.
• Portfolio exposure. An agent's holdings are publicly visible. Adversaries know its risk exposure, liquidation thresholds, and available capital.

Aleo eliminates these attack vectors. When an agent executes a function on Aleo:

• The transaction contents are hidden during propagation and after confirmation. There is no mempool sniping because there is nothing to snipe.
• The agent's holdings are encrypted records. No external party can determine the agent's portfolio composition or size.
• The agent's strategy is invisible. The network can verify that every action was valid but cannot determine what the action was.

This makes Aleo a natural execution environment for autonomous agents that manage real value. The agent's correctness is publicly verifiable (every action is backed by a zero-knowledge proof), but its competitive edge is protected.

An agent on Aleo can prove it followed its declared policy: that it did not exceed risk limits, that it executed within authorized parameters, that it did not misappropriate funds. It does this without revealing the specifics of what it did. That combination of verifiable compliance and strategic privacy is what agent-based systems actually need.

Aleo is not the only project working on blockchain privacy. Its approach is architecturally distinct, and a fair comparison requires understanding the different design philosophies.

Aztec is a ZK-rollup built on Ethereum. It provides a hybrid public/private execution environment where developers choose which function calls and state variables are private. Aztec settles to Ethereum, inheriting its security guarantees and ecosystem. The privacy model is strong. Aztec uses client-side proving similar to Aleo. But it is constrained by Ethereum's throughput and gas costs at the settlement layer. Aztec is not a standalone Layer 1; it is an Ethereum scaling solution with privacy features.

Namada is a Cosmos-based blockchain focused on multi-asset shielded transfers. It implements a shielded pool (based on the MASP, Multi-Asset Shielded Pool) that lets users hold and transfer any asset privately. Namada's strength is interoperability with the Cosmos ecosystem via IBC. However, Namada does not support general-purpose private smart contract execution the way Aleo does. Its privacy is focused on asset transfers rather than arbitrary programmable logic.

Secret Network uses Trusted Execution Environments (TEEs), specifically Intel SGX enclaves, to provide private computation. Smart contracts execute inside the enclave, and encrypted state is stored on-chain. This approach does not rely on zero-knowledge proofs. The privacy guarantee depends on the hardware's security. If the TEE is compromised (and Intel SGX has had multiple documented vulnerability classes), the privacy model breaks. This is a different trust assumption than ZK-based privacy, where the guarantee is mathematical rather than hardware-dependent.

Polygon Miden is a STARK-based rollup that supports client-side proving and a note-based (UTXO-like) state model. It shares several architectural similarities with Aleo, including off-chain execution and local proof generation. Miden uses STARKs rather than SNARKs, which avoids the need for a trusted setup and provides potential quantum resistance, but produces larger proofs and has higher verification costs.

Aleo's distinguishing characteristic is that it is a standalone Layer 1 purpose-built for private execution. It does not inherit the constraints of an underlying chain. Its entire stack, from the programming language (Leo and Aleo instructions) through the virtual machine (AVM) to the proof system (Varuna), was designed for private smart contracts.

For a detailed feature-by-feature comparison, see Aleo vs. Alternatives.

Aleo's privacy model depends on its zero-knowledge proof system. You need to understand the basics to evaluate the platform's security and performance characteristics.

What is a zero-knowledge proof?

A zero-knowledge proof is a cryptographic protocol that lets one party (the prover) convince another party (the verifier) that a statement is true, without revealing any information beyond the truth of the statement itself.

A classic analogy: imagine you have a color-blind friend, and you want to prove that two balls are different colors without telling your friend which color each ball is. You ask your friend to hold one ball in each hand behind their back, optionally swap them, and show them to you. You can always tell whether a swap occurred (because you can see the colors), but your friend gains no information about which color is which. After enough rounds, your friend is convinced the balls are different colors but has learned nothing about the specific colors.

On Aleo, the "statement" being proved is: "I executed this program correctly, consuming these specific inputs and producing these specific outputs, and I am authorized to spend these inputs." The proof convinces the network that this is true without revealing the inputs, outputs, or any intermediate computation.

SNARKs and Varuna

Aleo uses SNARKs (Succinct Non-Interactive Arguments of Knowledge). The key properties:

• Succinct. The proof is small (a few hundred bytes) regardless of how complex the computation is. Verification is fast (a few milliseconds).
• Non-interactive. The prover generates the proof in one shot. No back-and-forth between prover and verifier.
• Argument of Knowledge. The proof guarantees not only that the statement is true, but that the prover actually "knows" the underlying data (the witness). This prevents someone from generating a valid proof without possessing the private inputs.

Aleo's specific SNARK construction is called Varuna, a successor to the Marlin proof system. Varuna is an algebraic holographic proof system, meaning the prover can generate proofs for any program without a per-program trusted setup. There is a universal setup (a one-time ceremony that produces structured reference parameters), but adding new programs does not require new ceremonies.

The proof generation pipeline works roughly as follows:

1. Compilation. A Leo program is compiled to Aleo instructions (an intermediate representation), then compiled to a constraint system: a set of polynomial equations encoding the program's logic.

2. Witness generation. When a user executes the program with specific inputs, the AVM evaluates the constraint system and produces a witness, the set of all intermediate values that satisfy the constraints.

3. Proving. The prover takes the constraint system, the witness, and the universal setup parameters, and runs the Varuna proving algorithm to produce a SNARK. This is the expensive step. It involves polynomial arithmetic, multi-scalar multiplications, and Fast Fourier Transforms over elliptic curve groups.

4. Verification. The verifier takes the proof, the public inputs (if any; in the case of a finalize block, the mapping updates are public), and the verification key, and checks the proof in constant time relative to the computation's complexity.

Tradeoffs

No proof system is free of tradeoffs. The relevant ones for Aleo:

Trusted setup. Varuna requires a universal structured reference string (SRS) generated through a multi-party computation ceremony. The security assumption is that at least one participant was honest and discarded their secret share. If all participants colluded (or were compromised), it would be theoretically possible to generate false proofs. In practice, Aleo's setup ceremony involved many independent participants, and the cryptographic community considers the risk negligible.

Proof generation cost. Generating a SNARK is computationally intensive. Expect 10 to 30 seconds for a moderately complex program on consumer hardware, and under a few seconds with GPU acceleration or dedicated proving hardware. This is the most significant usability bottleneck. For AI agents, the cost can be mitigated with dedicated proving services or hardware accelerators, and proving time is expected to decrease as the technology matures.

Not quantum-resistant. SNARKs based on elliptic curve pairings (which includes Varuna) are not resistant to attacks from large-scale quantum computers. A sufficiently powerful quantum computer could break the discrete logarithm assumption underlying the proof system. This is a long-term concern shared by most deployed cryptographic systems. The transition to post-quantum proof systems (STARKs, lattice-based schemes) is an active area of research.

Proof size vs. verification time. SNARKs produce very small proofs with fast verification, which is why Aleo chose them over STARKs (which have larger proofs but avoid trusted setups). Smaller proofs mean lower on-chain storage costs and faster block validation.

These tradeoffs are real, but SNARKs remain the most practical technology available for general-purpose private smart contract execution. The combination of proof succinctness, verification speed, and expressiveness makes them well-suited to a blockchain environment where on-chain resources are scarce and verification must be fast.

Aleo's privacy-preserving smart contracts are not a feature bolted onto an existing blockchain. They come from a ground-up design that puts private execution at the center of the protocol. Off-chain execution with on-chain proof verification. The record-based state model. The hybrid function/final { } architecture. Together, these create a platform where privacy is the default and transparency is the explicit exception.

For developers building applications that handle sensitive data (financial positions, medical records, identity credentials, agent strategies), Aleo provides privacy guarantees that are mathematical rather than policy-based. The network does not see your data and cannot leak it. Not because it promises not to, but because it never had access to it in the first place.