Our team is happy to announce a new version of the Aleo node implementation, snarkOS, alongside developer tooling updates to snarkVM, Leo and the Aleo SDK. Aleo is a cryptocurrency through which developers can deploy cryptographically secure dApps.
This is the most significant release yet since Aleo’s mainnet launched in September 2024. Most notably, it contains an upgrade to Aleo’s record model, allowing the recipient to decrypt the sender address using their account view key, which we expect will lead to an increased interest from financial institutions to accept private transactions. The release also introduces staking requirements for miners (ARC-46), transaction confirmation time improvements, and many more performance improvements.
If you want to try it out, you can build from source today or download the mainnet release from github July 22nd. Find the current release schedule at: https://provablehq.github.io/.
Please report any issues you might come across!
What's new in v4.0.0
snarkVM Consensus change
A consensus change solidifying consensus logic will occur at the following block height:
Canary - Block 7,565,000 (~July 8th, 2025 at the current block times)
Testnet - Block 9,173,000 (~July 15th, 2025 at the current block times)
Mainnet - Block 9,425,000 (~July 22th, 2025 at the current block times)
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.
An upgrade to Aleo’s record model
At the heart of Aleo lies a revolutionary cryptographic protocol known as ZEXE, or Zero-Knowledge EXecution, which was first introduced in 2018. ZEXE was designed to enhance privacy and security in decentralized systems and was the first to introduce the record model. This model extends the UTXO model from Zcash and enables storing and encrypting arbitrary data such as user assets and application states, rather than just values of specific assets or tokens.
In the record model, the application state, along with its owner are encrypted and stored on the blockchain. Records are a fundamental data structure that can contain any arbitrary payload and are used for encoding user assets or application states. Records represent a fragment of the global state kept on chain. For example, the balance of your credits in a given account is composed by the multiple credit records that have your address as the owner.
We are introducing a couple changes. Most notably, records will now by default include a sender_ciphertext which allows the recipient to decrypt the sender address using their account view key. This opens up the avenue for financial institutions to accept private transfers, significantly improving user privacy and helping to increase the adoption of privacy-preserving technologies - in crypto and beyond.
The encryption scheme is as follows (where vk is the recipient's account view key, and G^r is the record nonce):
record_view_key := (G^vk) * r == (G^r) * vk
randomizer := Hash_PSD4( ENCRYPTION_DOMAIN || record_view_key || 1field )
sender_ciphertext := ToXCoordinate(signer_address) + randomizerTo perform decryption of the sender ciphertext, call Output::decrypt_sender_ciphertext with your account_view_key. If the given account view key does not belong to the given output record's owner, the function will return an error.
To support potential future upgrades, we also added versioning to the Record object. From ConsensusVersion::V8 onwards, old V0 credits.aleo records cannot be spent anymore - they can only be upgraded to V1 by calling a new upgrade function in credits.aleo. In other words, all records will need to be upgraded. In the process of upgrading, additional integrity checks will automatically take place with regards to correctness of the record contents. Aleo’s 4 major wallets (Puzzle, Leo, Fox and Soter) all support the new record upgrade process in their wallet applications. Moreover, a CLI tool will be made available for anyone who wishes to upgrade their records without the use of a wallet.
For more background about Aleo’s record model, check out: https://aleo.org/post/aleo-record-model-secure-efficient-blockchain/
ARC-46: Staking for Puzzle Solution Submissions
This PR implements the new features highlighted in the ARC-0046 Proposal. This ARC proposes a mechanism requiring provers on the Aleo Network to stake a specific amount of Aleo credits to be eligible to submit a specific number of solutions per epoch. This feature is programmatic, with a stepwise increase in the required amount of stake over a two-year period following the activation of this ARC.
For more information about how to stake, see: https://developer.aleo.org/concepts/network/staking
For an overview of stake required per solution per epoch in the future, see the following table:
Effective Date | Stake Required Per Solution Per Epoch |
|---|---|
2025-07-31 23:59:59 UTC | 100,000 |
2025-10-31 23:59:59 UTC | 250,000 |
2026-01-31 23:59:59 UTC | 500,000 |
2026-04-30 23:59:59 UTC | 750,000 |
2026-07-31 23:59:59 UTC | 1,000,000 |
2026-10-31 23:59:59 UTC | 1,250,000 |
2027-01-31 23:59:59 UTC | 1,500,000 |
2027-04-30 23:59:59 UTC | 2,000,000 |
2027-07-31 23:59:59 UTC | 2,500,000 |
Faster transaction confirmation times
#3678 enables faster transaction confirmation times. Currently, it can take half a minute for a well-connected client to detect that its transaction was confirmed, because block propagation is sometimes slow. This PR ensures that when a new block is received or created, nodes send new ping messages. This should reduce block propagation time, as the old approach introduces up to 20 seconds of delay for each network hop.
Further improvements and speedups to both syncing speed and transaction confirmation times are in the works!
Doubled constraint limit
PR #2797 has doubled the constraint limit one can use in deploying programs, a long-time awaited feature. This is made possible due to various recent improvements in deployment verification performance. Note that the upgraded record handling does require more constraints in the proof system. Transactions involving private state will therefore require more fees. Deployments involving private state will require more fees and constraints than before. Still, the increased limit will ensure developers can write more expressive programs than before. We will continue to push deployment verification performance in order to increase this limit more in the future.
Further improvements for developers
Parallelized proving workloads can experience up to 90% proving time speedups due to a glorious one-line change in #2753. Wallets and end-users can experience up to 400% authorization speedups due to #2760.
#2777 introduces the `dev-print` feature. This is to give user developers more control of snarkvm's output - currently some print statements are compiled in when debug-assertions is on, but we want to elide those print statements even with debug-assertions.
#3692 fixes the `snarkos developer scan` endpoint, which was previously broken.
Improvements for node operators
Cases of massive duplicated logs about staking_rewards has been fixed in #2689.
JWT-guarded RPC endpoints are now functioning for clients due to #3672.
#3707 adds a --log-filter flag, that can be set instead of --verbosity. The log filter flag, essentially, works like setting RUST_LOG. If you, for example, only want to all show logs related to the BFT crate but nothing else, you can start a node like this snarkos start --log-filter=off,snarkos_node_bft=trace.
#3682 adds a /sync_status endpoint to the REST API. A call to it will return something like the following:
~> curl http://localhost:3030/mainnet/sync_status
{
"is_synced": false,
"ledger_height": 2443,
"sync_mode": "p2p",
"cdn_height": 8167950,
}sync_mode will switch to p2p once the initial sync is done.
If the node is not connected to a CDN, the cdn_height field is omitted.
~> curl http://localhost:3030/mainnet/sync_status
{
"is_synced": false,
"ledger_height": 2795,
"sync_mode": "p2p",
"p2p_height": 8638987
}P2p height is only added to the response once a peer is connected
Library and tooling updates
snarkVM v4.0.0
snarkVM is a zkVM library. It powers the Aleo network and most of the software used to interact with it. There are a number of breaking changes introduced:
Recordsnow contain a new"_version"field. New records generated after ConsensusVersion::V8 will have a version of 1, while those before have version 0.Programs verifying keys for all programs deployed on-chain have been updated to a new version to support the new record version, and as such all programs now require the use of edition 1. (Introduced in #2793R).
As described above, transactions with output records will now have an encrypted sender field that encodes the signer of the transaction that produced the record. This will allow users to determine what address sent them a record. Serialization for the following objects has changed:
Request::InputIDnow includes for record inputs a"record_view_key":record_view_keyentry. Blocks do not contain requests, so this should not impact all indexers.Transition::Output now includes for record outputs an optional "sender_ciphertext": sender_ciphertext entry, which will be populated from ConsensusVersion::V8 onwards.
You can retrieve the latest program edition using
block_store().get_latest_program(In contrast to e.g.block_store().get_program). Once program upgradability is introduced in a future release, you’ll be able to review all.Querytraitis now used as a trait object. This significantly improves the ergonomics of using these functions. If you don’t want to pass in a Query, just pass inNone. Note that if you do use a Query object, you may need to instantiate it e.g. as follows:Some(&Query::<N, BlockMemory<N>>::from(endpoint)).
Leo 3.0.0
Leo is a programming language for formally verified, zero-knowledge applications on the Aleo network. The latest release includes the following features:
Const generics for inline:
inline sum_first_n_ints::[N: u32]() -> u32 {
let sum = 0u32;
for i in 0u32..N {
sum += i + other::[i]();
}
return sum;
}
transition main() -> u32 {
return sum_first_n_ints::[5u32]();
}More informative deployment stats printing;
No more input files - specify inputs on the command line.
SDK 0.9.3
SDK version 0.9.3 releases the following new features to developers desiring to build NodeJS apps and browser-based extensions for Aleo:
Developers can now build authorizations using the SDK. This is helpful when developers desire to execute authorizations in their own accelerated environments.
Records can now be decrypted with record view keys. This provides the option for applications to decrypt individual records without using the view key directly. This enables developers to achieve compliance surrounding individual records without sharing an account’s view key.
Transition view keys can be computed allowing transitions to be decrypted without direct usage of an account’s view key.
Minimum fees are now automatically calculated for executions.
BHP, Pedersen, and Poseidon hash functions are now available directly in the SDK. This enables developers to:
Compute hashes outside Leo allowing developers to hash data prior to providing it to a function input.
Compute mapping keys which were derived via a hash function.
Verify any data within mappings, function outputs, or records that was computed via a hash function enabling actions such as commitment opening directly within Dapps and custodial applications.
Closing notes
The full changelogs for the referenced releases can be found here:
https://github.com/ProvableHQ/snarkVM/compare/v3.8.0...canary-v4.0.0
https://github.com/ProvableHQ/snarkOS/compare/v3.8.0…canary-v4.0.0
If you want to try it out, you can build from source today or download the mainnet release from github July 22nd. Find the current release schedule at: https://provablehq.github.io/.
Contributors
A big thank you to all the contributors on Github to this snarkVM, snarkOS, Leo and SDK release!
@acoglio
@kaimast
@d0cd
@dizer-ti
@joske
@kaimast
@kpandl
@ljedrz
@meddle0x53
@mikebenfield
@niklaslong
@raychu86
@vicsn