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.
• 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.

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).

testnet-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.
• 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.

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).

v4.5.5

Merge pull request #4177 from ProvableHQ/prevent_block_response_race_…

v4.5.4

Merge pull request #4171 from ProvableHQ/release-mainnet-4.5.4

[Release] Mainnet v4.5.4

v4.5.2

Merge pull request #4159 from ProvableHQ/fix/4.5.1-hotfixes

[Fix] 4.5.1 mainnet backports

v4.5.1

Our team is happy 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 unlocks fast and reliable end-to-end (E2E) testing of Leo programs, streamlines operations for validators, and introduces a limit on the total supply of Aleo credits.

If you want to try it out, you can build from source today or download the mainnet release from Github February 6th. Find the current release schedule at: https://aleo.org/roadmap .

Please report any issues you might come across!

Consensus Upgrade: V13

The release schedule is as follows:

• Canary (validator test network)
  • Release: January 12th
  • Hard fork: ~January 15th (exact block heights)
• Testnet (developer test network)
  • Release: February 6th
  • Hard fork: February 13th (exact block heights)
• Mainnet
  • Release: February 13th
  • Hard fork: February 20th (exact block heights)

ATTENTION: Validators that do not upgrade in time will be at risk of forking and require manual intervention. Clients that do not upgrade will be at risk of halting until an upgrade occurs.

Cap on Total Supply of Aleo Credits

With the approval of ARC-0047, the Aleo network has now established a hard cap on the total supply of Aleo Credits at 5,000,000,000 ALEO. The cap will be enforced by halting block rewards and proving rewards at a predetermined block height (based on theoretical maximum issuance). Note that the emission rates of these rewards are not being modified. Instead, both reward streams will terminate at a predetermined block height in the far future. With the current average block rate, we expect this to occur at the conclusion of Q4 2049.

Improvements for Developers

## leo devnode

One of the most important points of software engineering is testing. While Leo recently added support for unit tests, a good E2E test suite was missing. Existing solutions require running a small development network with multiple validators and clients - slow, expensive, and clunky. leo devnode is a new tool that creates a local lightweight development client to enable developers to rapidly test and iterate through Aleo program design.

leo devnode has two commands:

• leo devnode start will initiate the development client at localhost:3030
• leo devnode advance creates a single block and adds it to the ledger. Optionally, this command takes a value n, which advances the ledger by n blocks.

By default, broadcasting a transaction to the devnode will automatically produce a block and advance the ledger. However, passing the --manual-block-create flag at startup will allow users to broadcast multiple transactions to a queue without creating a block. In order to advance the ledger in this scenario, users will need to use the leo devnode advance command.

Additionally, a --skip-execution-proof flag has been added for the for leo execute command. This flag will create transactions without generating the corresponding ZK proof, further accelerating the testing process.

We have provided some examples of how to use the devnode feature alongside the Javascript/Typescript SDK.

Program Edition Handling in Leo

Leo now handles editions for local and remote programs in a more robust way. As local programs haven't been deployed yet, they do not possess a real onchain edition. We default to edition 1 for certain commands that don’t interact onchain to avoid the check in snarkVM that rejects edition 0 programs without constructors. This keeps local development frictionless.

Command	Local Programs	Network Dependencies
leo run	Default to edition 1	Fetch edition from network
leo execute	Default to edition 1	Fetch edition from network
leo synthesize	Default to edition 1	Fetch edition from network
leo deploy	N/A	Fetch edition from network + V8 constructor check
leo upgrade	N/A	Fetch edition from network + V8 constructor check

Additionally if a network dependency is at edition 0 without a constructor, a more verbose error will now be produced with a clear message explaining the program needs to be upgraded onchain.

External Structs in Leo

This release also introduces an important change to how external structs are handled in Leo.

In previous versions of Leo, external structs did not need to be qualified with the program they came from. All imported structs effectively lived in a global namespace.

Now, external structs must now be explicitly qualified with the program that defines them. Struct names are no longer globally scoped across imports.

For example, given the following program foo.aleo:

Another program (bar.aleo) must qualify struct Foo with foo.aleo in order to use it:

New --json-output flag in the Leo CLI

The Leo CLI now supports a new --json-output flag that writes structured, machine-readable JSON output to disk. This makes it easier to integrate Leo commands into scripts, tooling, and automated workflows.

The --json-output flag is available for the following commands:

• deploy
• upgrade
• run
• execute
• test
• query
• synthesize

Save JSON output to the default location:

Save JSON output to a custom file path:

By default, JSON output files are written to the build/json-outputs/ directory, with one file per command. For example:

Changes to snarkos developer execute

• By default, snarkos developer execute commands will now use the V2 endpoints for api.explorer.provable.com. However, backwards compatibility is still supported for the V1 endpoints.
• Attempting to use an account with an insufficient balance of credits now produces clearer error messaging.
• A bug was fixed which prohibited fetching and utilizing the right editions of imported programs.

Miscellaneous Updates

• Initial support for external structs has been added to snarkVM. This will be supported in Leo program syntax in a future release.
• The size of the compiled program (in kB) will be output by the CLI when calling leo build, leo deploy, and leo upgrade.
• A --disable-update-check flag has been added to the Leo CLI. This allows for disabling the Leo’s automatic update check, allowing for more consistently reproducible output from the CLI.
• Various performance improvements have made their way into AleoVM, such as better block caching and better database deserialization.

SDK

Upgrades to Proving Speed & Proving Key Management

• 10-20% speedup local wasm-based proving via wasm optimizations made through applying wasm-opt
• Adds a new KeyStore interface for storing proving and verifying keys on disk for node JS and storing them in IndexedDB for web and wallet applications. This helps developers cache proving keys for later re-use improving wasm proving times a further 30%

Miscellaneous Upgrades:

• Adds support for getting the address of a program from the Program object

Improvements for Node Operators

Improved Database Organization

A new node-data directory has been introduced that contains all node-specific data (essentially everything but the ledger). This is located at ~/.aleo/storage/node-data-{network_id} for production or ./node-data-{network_id}-{dev} for development nodes. Alternatively, users can also pass a value to --node-data and store the data at a custom path.

Previously, these files lived in the similarly-named ledger-* folder. At startup, a node will check for any files that indicate that the old storage format is used. In that case, a message is printed on how to migrate, and the node will not start.

Alternatively, nodes can also be started with --auto-migrate-node-data to move the appropriate files automatically from the ledger-* folder to the node-data-* folder.

Automated Peer IP Handling

A dynamic validator IP whitelist has been introduced, which is written to a file called dynamic_validator_whitelist every ~15 seconds. A validator node constructs the IP list based on its own peers as well as the known peers gossiped by the bootstrap peers.

Validators will now be recommended to allow incoming connections from (1) the bootstrap peer IPs (2) the dynamic_validator_whitelist file in...

v4.5.0

Merge pull request #4144 from ProvableHQ/release-mainnet-4.5.0

Release mainnet 4.5.0

testnet-v4.5.4

Merge remote-tracking branch 'origin/canary' into testnet

testnet-v4.5.1

https://provable.com/blog/announcing-aleo-stack-v4-5-0

testnet-v4.5.0

https://provable.com/blog/announcing-aleo-stack-v4-5-0