Aleo Explorer by Provable

Announcing Aleo Stack v4.6.0

The Aleo maintainers are excited to announce a new version of the Aleo Stack. This update includes changes to the node implementation snarkOS and the high-level programming language Leo - as well as their supporting libraries. This release is one of the largest and most significant upgrades to Aleo since the launch of Mainnet. It introduces three major capabilities: Leo v4.0.0: a complete overhaul of the Leo language, unifying five function-like constructs into a single fn keyword with explicit execution context modifiers. Interfaces and Dynamic Dispatch: compile-time program contracts and runtime function resolution, enabling standardized interfaces, pluggable architectures, and open composability. Leo Libraries: Reusable packages of types, constants, and functions that are shared across programs and fully inlined at compile time Onchain SNARK Verification: new snark.verify and snark.verify.batch opcodes that allow programs to verify Varuna proofs directly onchain. If you want to try it out, you can build from source today or download the mainnet release from Github March 30th. Find the current release schedule at:https://aleo.org/roadmap. Consensus Upgrade: V14 The release schedule and upgrade block heights for v4.6.0 can be found here: https://roadmap.aleo.org/ ATTENTION: Validators and clients that do not upgrade in time will be at risk of forking and require manual intervention to recover. Leo v4.0.0 Leo v4.0.0 is a ground-up rethinking of how Leo programs are written. The previous version of Leo required developers to choose between five distinct function-like constructs — transition, function, inline, async transition, and async function — each with different semantics, calling restrictions, and execution contexts. This release replaces all of them with a single fn keyword. Unified fn Syntax All functions now use fn. Where a function executes depends on two things: whether it is inside a program block (making it an entry point), and whether it uses the final modifier (marking it for onchain execution during finalization). Previous Syntax New Syntax Location transition fn Inside program block function fn Outside program block inline fn (compiler decides) Outside program block async transition fn returning Final Inside program block async function final fn or final { } block Outside program block Future Final Type name .await() .run() Execution operator Before (Leo v3.x): program token.aleo { mapping balances: address => u64; async transition transfer(to: address, amount: u64) -> Future { return finalize_transfer(to, amount); } async function finalize_transfer(to: address, amount: u64) { let current: u64 = balances.get_or_use(to, 0u64); balances.set(to, current + amount); } } After (Leo v4.0.0): final fn update_balance(to: address, amount: u64) { let current: u64 = balances.get_or_use(to, 0u64); balances.set(to, current + amount); } program token.aleo { mapping balances: address => u64; fn transfer(to: address, amount: u64) -> Final { return final { update_balance(to, amount); }; } } The program block now clearly defines the program's public interface — only entry points, record declarations, and storage live inside it. Helper functions and type declarations are placed outside. The final keyword explicitly marks functions and blocks that execute on-chain during finalization, replacing the overloaded async terminology. The result is that the distinction between private ZK proof execution and public onchain finalization is visible at a glance. Automatic Optimization The compiler now makes inlining decisions automatically. Functions called only once are auto-inlined, and functions never called are eliminated. Developers no longer need to choose between function and inline — the compiler handles it. A @no_inline annotation is available for cases where you want to prevent inlining of a specific function. Migration Only the new syntax will be supported going forward from this release. Programs written with transition, function, inline, and async will continue to compile identically. We recommend migrating to the new syntax for all new code. Deprecation warnings for the old syntax will be introduced in a future release. For detailed migration guidance, refer to the Leo documentation. Interfaces Interfaces introduce compile-time contracts for Leo programs. An interface declares what a program must provide — entry point function signatures, record types, and mappings — and the compiler verifies that any program claiming to implement the interface actually does. interface ARC20 { record Token { owner: address, balance: u64, .. } fn transfer(input: Token, to: address, amount: u64) -> Token; } program my_token.aleo : ARC20 { record Token { owner: address, balance: u64, memo: field, } fn transfer(input: Token, to: address, amount: u64) -> Token { // ... } } The Token annotation here is a compile-time obligation. If any required member is missing or has the wrong signature, the compiler rejects the program. Composition and Inheritance Interfaces compose using the + operator and support inheritance: interface Transfer { record Token; fn transfer(input: Token, to: address, amount: u64) -> Token; } interface Balances { mapping balances: address => u64; } interface ARC20 : Transfer + Balances {} program my_token.aleo : ARC20 { // Must implement everything from Transfer and Balances } Record Constraints Interfaces can require that a record has certain fields without fully specifying its structure. The .. syntax means "these fields are required; the implementor may add more": interface ARC20 { record Token { owner: address, balance: u64, .. } } This allows programs to extend the record with additional fields (like a memo or created_at timestamp) while still satisfying the interface contract. Dynamic Dispatch Until now, every cross-program call in Leo was static — the target program was hardcoded in source and baked into the circuit. To support a second token, you wrote a second function. To support an arbitrary token, you redeployed or upgraded your program. fn route_transfer_static(to: address, amount: u64) { return token_a.aleo::transfer(to, amount); // Static } Dynamic dispatch changes this. A single function can now route to any program that implements a known interface, with the target resolved at runtime. // Dynamic: any program that implements TokenStandard can be called fn transfer_dynamic(token_program:identifier, to:address, amount:u64) { return TokenStandard@(token_program)::transfer_public(to, amount); } Dynamic Records Dynamic dispatch solves the problem for program logic. Data has the same rigidity problem — if your function accepts a Token record, it must know the record's exact layout at compile time. The new dyn record type removes this limitation. Programs can accept, inspect, and forward records whose structure is determined at runtime: fn route_private_transfer( token_program: field, input: dyn record, to: address, amount: u64 ) -> dyn record { } Field access on dynamic records is verified by Merkle proof inside the circuit. If a field doesn't exist or has the wrong type, the proof fails. Security Model Dynamic dispatch is opt-in and interface-constrained. Static dispatch remains the default. When a program makes a dynamic call, translation proofs automatically verify that records passed across call boundaries are consistent between their static and dynamic representations. The target program, network, and function name are publicly witnessed — private variables influencing the call target are implicitly revealed. Leo Libraries Leo now supports libraries — reusable packages of types, constants, and functions that are shared across programs and fully inlined at compile time. Libraries have no transitions, no mappings, and no onchain footprint. Every struct, constant, and function call is resolved and inlined by the compiler before bytecode is emitted. Creating a Library A library lives in its own package with a lib.leo entry point (created with leo new --lib). It can define constants, structs (including generic ones), and plain fn functions: // lib.leo (package: math) const PRECISION: u32 = 1000u32; struct Vec2 { x: u32, y: u32, } fn dot(a: Vec2, b: Vec2) -> u32 { return a.x * b.x + a.y * b.y; } fn scale::[N: u32](v: Vec2) -> Vec2 { return Vec2 { x: v.x * N, y: v.y * N }; } Declaring the Dependency Add the library to your program's program.json manifest under "dependencies": { "program": "myapp.aleo", "version": "0.1.0", "description": "", "license": "MIT", "dependencies": [ { "name": "math", "location": "local", "path": "../math" } ] } Using the Library All library items are accessed under the library name as a namespace: program physics.aleo { fn kinetic_energy(vx: u32, vy: u32, mass: u32) -> u32 { let v: math::Vec2 = math::Vec2 { x: vx, y: vy }; let v3: math::Vec2 = math::scale::[3u32](v); // const arg resolved at compile time return math::dot(v3, v3) * mass / math::PRECISION; } @noupgrade constructor() {} } The compiler monomorphizes scale::[3u32] into a concrete function, folds PRECISION to 1000u32, and inlines everything. The resulting bytecode contains no trace of math. Key Properties Because libraries are inlined rather than deployed, there are no cross-program call overhead, no ABI boundaries to cross, and generic parameters (array sizes, loop bounds, etc.) are all resolved at compile time — making them the natural home for shared utilities, data structures, and constants. Libraries Programs Compiled to bytecode No — fully inlined Yes Structs (incl. const generic) ✓ ✓ Constants ✓ ✓ Functions (incl. Const generic) fn only All variants Mappings / storage — ✓ Deployed onchain No Yes Onchain SNARK Verification Aleo Stack v4.6.0 introduces snark.verify and snark.verify.batch; new opcodes that verify Varuna proofs directly onchain within the finalize scope of a program. This implements ARC-0008. In Leo, these are available as: program verifier.aleo { fn verify_proof( vk: [u8; 1024], varuna_version: u8, inputs: [field; 16], proof: [u8; 512] ) -> Final { return final { let valid: bool = Snark::verify(vk, varuna_version, inputs, proof); assert(valid); }; } } snark.verify.batch supports batch verification of multiple proofs, with compile-time enforcement of snarkVM limits (max 32 circuits, max 128 total instances). To accommodate the larger data sizes required for verifying keys and proofs, the maximum array size has been increased from 512 to 2,048 elements. This feature enables proof composition, cross-chain verification, and trustless bridging — any external computation that produces a Varuna proof can now be verified natively by an on-chain Aleo program. Improvements for Developers Leo leo fmt — Code Formatter: Leo now ships with a built-in code formatter. Run leo fmt to format all .leo files in a project, or leo fmt --check for CI integration. The formatter wraps lines at 100 characters and is built on a new lossless Rowan-based parser that preserves comments and whitespace. leo abi — ABI Generation: A new leo abi command generates a JSON ABI from compiled .aleo files. The ABI includes struct and record definitions, mapping declarations, and transition signatures with input/output types and modes. leo build now automatically writes an abi.json alongside main.aleo. Faster Testing: leo test now skips proof generation by default, dramatically speeding up test cycles. Opt in to full proof generation with leo test --prove. Group Generator Access: Two new built-ins — Aleo::generator() and Aleo::generator_powers() — expose the network's group generator point to programs. Aleo::generator() returns the generator as a group, and Aleo::generator_powers() returns a [group; 251] array of precomputed powers, enabling in-program address derivation and other elliptic curve operations. External Structs: Programs can now reference structs defined in imported programs. Two structs with the same name and identical member structure are considered equivalent, resolving a common pain point when working with multi-program deployments. Increased Program Limits: Maximum program size has been increased from 100 KB to 512 KB. Maximum transaction size is now 540 KB. Maximum writes per finalize scope increased from 16 to 32. VK Migration (Amendment Deployments): A new deployment type allows updating a program's verifying keys without changing the program edition, owner, or re-running the constructor. This is essential for adding dynamic dispatch support to existing deployed programs. New REST endpoints support querying amendment counts and transaction history. Structured Error Messages: When an instruction fails, error messages now include the failing instruction index and a formatted instruction string, producing stack-trace-like output for nested calls. SDK Dynamic Dispatch: The DynamicRecord and DynamicFuture types have been added to support dynamic dispatch , Utilities: A stringToField()method has been added for converting program names to field elements Privacy and Security: Proving requests for the Delegated Proving Service can now be encrypted. A KeyStore abstraction has been added for persistent key storage across environments. Zeroizing destructors have been added that scrub private key material from WASM memory. MPC (multi-party computation) support has been added for constructing execution requests. WASM Memory: Maximum WASM memory has been raised to ~4 GB. API Endpoints: The API endpoint has migrated from api.explorer.provable.com/v1 to api.provable.com/v2. Improvements for Node Operators Automated Ledger Checkpoints: A new --auto_db_checkpoints=<path> flag enables rolling RocksDB checkpoint-based ledger backups every 1,000 blocks, maintaining up to 5 rolling snapshots. Filesystem Reorganization: Node-specific data (peer lists, proposal cache) now lives in a dedicated node-data directory, separate from the ledger. Use --node-data for custom paths and --auto-migrate-node-data for automatic migration. Dynamic Validator Whitelist: Nodes now maintain a file listing all currently connected validators, updated with every heartbeat. The format is IP-port pairs for easy scripting and firewall integration. New Metrics: Build info (version, git commit, branch) is now exposed as Prometheus gauge metrics. New gauges track total connected validator stake and the combined stake of validators running the same snarkOS SHA, useful during rolling upgrades. Network Stability: TCP socket configuration has been hardened, connection timeouts relaxed (handshake increased from 1s to 3s, high-level from 3s to 5s), and the BFT communication layer refactored from channel-based to direct callbacks, reducing async overhead and improving error propagation. CDN sync performance is improved through unchecked deserialization and threadpool reuse. New REST Endpoints: New routes for historical staking rewards, connected validator queries (/{network}/connections/bft/…), and amendment deployment metadata (/program/{programID}/amendment_count). Looking Ahead Interfaces, dynamic dispatch, and dynamic records provide the language-level machinery for standardized program contracts, runtime polymorphism, and open composability on Aleo — with privacy guarantees the EVM cannot provide and interface enforcement that extends beyond function signatures to records and mappings. The first major consumer of these features is already in progress: ARC-20, Aleo's interoperable token standard. More on that soon. Closing Notes The full changelogs for the referenced releases can be found here: https://github.com/ProvableHQ/snarkVM/compare/v4.5.0...v4.6.0 https://github.com/ProvableHQ/snarkOS/compare/v4.5.0…v4.6.0 https://github.com/ProvableHQ/leo/compare/v3.5.0…v4.0.0 https://github.com/ProvableHQ/sdk/compare/v0.9.16...v0.10.0 If you want to try it out, you can build from source today or download the mainnet release from Github March 30th. Find the current release schedule at:https://aleo.org/roadmap. Please report any issues you might come across! Contributors A big thank you to all the contributors on Github to this snarkOS, snarkVM, Leo, and SDK release! @AleoAlexander @Antonio95 @aripiprazole @awatts73 @d0cd @damons @dgrkotsonis @eranrund @iamalwaysuncomfortable @IGI-111 @JoshuaBatty @kaimast @ljedrz @marshacb @meddle0x53 @mitchmindtree @mohammadfawaz @raychu86 @Roee-87 @shaaibu7 @tcrypt25519 @tenequm @vicsn

Announcements

Transaction ID	Status	In Block	Type
at1kd5zexygsy3wlhum7azz8ngx293r49lsu4dnf3pkjm2xmpxgl5ys3wwxjm	accepted	17,473,886	Execute
at144p3d868jd3puz46lzdwpawdmlhff6qdmjzdh4rwgeysc32w6uyqy74y63	accepted	17,473,884	Execute
at16k9pd9gtzvp6jsa7tj0sq2dltygkl9ka5gmjx57adyxnp3rq6qgs8r4wke	accepted	17,473,884	Execute
at15al9nra87dxzhjanr9sdg56dempaeche6t35lrerja6qcych8srq57wfzz	accepted	17,473,883	Execute
at10fy8y0eue7gv5x646nre8vr9aw4694kyaeqqfkt22rfggw4s9cps4yx383	accepted	17,473,859	Execute
at1u35lcl485kw3rwnmh3nuakkankdc53l7wn6t9zhvl63cypjdwqzqvepe5e	accepted	17,473,841	Execute
at1ghxte2ggdgpw7qedukq4j4chcnw8xxtshl63k9tdghgddcxs8sxqut0t90	accepted	17,473,817	Execute
at1jakfdtrugq8tfjm0apsnqj8adjgpc8qeqqdw5qk6g4h8pmcrhvyqrr80z9	accepted	17,473,796	Execute
at1lkkszxv0tjpmxctcgjntxk9gsjq87dpth3p0l699lyvhwxq9cvrqdx2vpq	accepted	17,473,775	Execute
at1qx4k96jm0l7uu5ty803xcxz37fgvs68mwqkfqusq3jpmgpkqauzsakv2qp	accepted	17,473,775	Execute

Transaction ID

Status

Program ID

Function

In Block

Type

Age

at1kd5zexygsy3wlhum7azz8ngx293r49lsu4dnf3pkjm2xmpxgl5ys3wwxjm

accepted

17,473,886

Execute

at144p3d868jd3puz46lzdwpawdmlhff6qdmjzdh4rwgeysc32w6uyqy74y63

accepted

17,473,884

Execute

at16k9pd9gtzvp6jsa7tj0sq2dltygkl9ka5gmjx57adyxnp3rq6qgs8r4wke

accepted

17,473,884

Execute

at15al9nra87dxzhjanr9sdg56dempaeche6t35lrerja6qcych8srq57wfzz

accepted

17,473,883

Execute

at10fy8y0eue7gv5x646nre8vr9aw4694kyaeqqfkt22rfggw4s9cps4yx383

accepted

17,473,859

Execute

at1u35lcl485kw3rwnmh3nuakkankdc53l7wn6t9zhvl63cypjdwqzqvepe5e

accepted

17,473,841

Execute

at1ghxte2ggdgpw7qedukq4j4chcnw8xxtshl63k9tdghgddcxs8sxqut0t90

accepted

17,473,817

Execute

at1jakfdtrugq8tfjm0apsnqj8adjgpc8qeqqdw5qk6g4h8pmcrhvyqrr80z9

accepted

17,473,796

Execute

at1lkkszxv0tjpmxctcgjntxk9gsjq87dpth3p0l699lyvhwxq9cvrqdx2vpq

accepted

17,473,775

Execute

at1qx4k96jm0l7uu5ty803xcxz37fgvs68mwqkfqusq3jpmgpkqauzsakv2qp

accepted

17,473,775

Execute

Announcing Aleo Stack v4.6.0

Announcements

Explorethe AleoNetwork

Ecosystem News

Announcing Aleo Stack v4.6.0

Changelog

Introducing Shield: The Privacy-First Wallet for Aleo

Announcing Aleo Stack v4.5.0

Fuzzing the Aleo VM: Two Approaches to Bulletproof Security

Announcing Aleo Stack v4.4.0

Provable Acquires Leo Wallet with Commitment to Support & Expand Product Offering

Introducing the New and Improved Provable Explorer

Announcing Aleo Stack v4.3.0

Announcing Aleo Stack v4.2.0

Ecosystem News

Want to build cryptographically secure dApps at scale?

Latest Blocks

Latest Transactions

Products

Announcing Aleo Stack v4.6.0

Changelog

Introducing Shield: The Privacy-First Wallet for Aleo

Announcing Aleo Stack v4.5.0

Fuzzing the Aleo VM: Two Approaches to Bulletproof Security

Announcing Aleo Stack v4.4.0

Provable Acquires Leo Wallet with Commitment to Support & Expand Product Offering

Introducing the New and Improved Provable Explorer

Announcing Aleo Stack v4.3.0

Announcing Aleo Stack v4.2.0