Validators
Provers
Programs
Blocks
Transactions
Docs

© PROVABLE 2025

Validators Provers Programs Blocks Transactions Docs

Explore AleoNetwork

Ctrl + K

Coinbase Target

221.41T

Program Calls Last 7 Days

137.47K

Total Network Stake

1.39BALEO

Percent staked

76.7%

Proof Target

55.35T

Deployed Programs

609

Total Transactions

23.72M

Total Validators

33

Total Provers

168

Total Puzzle Reward

128.54MALEO

Ecosystem News

Announcing snarkOS v4.1.0

Announcing snarkOS v4.1.0

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. Most notably, this release unlocks program upgradability. This feature, proposed in ARC-6, offers a method for program upgrades that seeks to be timely and cost-effective, while preventing fragmentation of application state. The release also introduces various quality of life improvements for node operators, such as exposing HTTP endpoints for creating backups and retrieving version information. If you want to try it out, you can build from source today or download the mainnet release from github August 12th. Find the current release schedule at: https://provablehq.github.io/. Please report any issues you might come across! What's new in v4.1.0 Consensus change: ConsensusVersion V9 A consensus change will occur at the following times: Canary - ~9AM PT July 29th, 2025 Testnet - ~9AM PT August 5th, 2025 Mainnet - ~9AM PT August 12th, 2025 The exact block heights will be encoded in the snarkVM library at release. 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. Maximum validator set increase to 40 The maximum number of validators securing the Aleo network will increase to 40. The gradual increase of validators on the Aleo network assures a continuous increase in decentralization without sacrificing security and stability of the network. Program upgradability With this release, Aleo will facilitate a system for program upgrades with the following highlighted properties: Upgrades preserve the interface of a program. An upgrade can: change logic in a function or finalize define new structs, records, or mappings but cannot modify or remove existing ones add new functions and closures An upgrade cannot: change a function’s input and output interface change a finalize’s input interface change logic in a closure. This is because a change in a closure would invalidate all dependent proving and verifying keys. change existing structs, records, or mappings Program Component Delete Modify Add import ❌ ❌ ✅ struct ❌ ❌ ✅ record ❌ ❌ ✅ mapping ❌ ❌ ✅ closure ❌ ❌ ✅ function ❌ ✅ (logic) ✅ finalize ❌ ✅ (logic) ✅ constructor ❌ ❌ ❌ Upgrades can be rejected by dependent applications. While we require that upgrades are atomic and take effect immediately, dependents may want fine-grained control. There should be a way for an application to detect whether a dependent is changed, after which the dependent application will need to be upgraded to the desired logic to be callable again. Developers must be able to ossify their programs. Immutable application logic gives users sovereignty. This is desirable in many blockchain ecosystems. At a high-level, our proposed design introduces immutable constructors, where you can define your upgrade logic, and new finalize scope operands checksum, edition and program_owner so that users can programmatically define upgrades with the above design goals in mind. Newly deployed programs must contain a constructor, and start at edition 0. As they upgrade, their edition increments by 1. Only the highest edition of the program can be executed. For more information about program upgradability, check out: The ARC specification The Leo examples Improvements for node operators Better peering logging Peering code has been cleaned up significantly, reducing the amount of spurious ProtocolViolation and Unable to resolve false positive messages. Rocksdb checkpoints Native rocksdb checkpoints can now be made with a simple JSON Web Token guarded HTTP call. When you start your node without passing in custom JWT flags, your JWT credentials are printed to stdout at startup. Creating a checkpoint at location /home/aleo_ledger_checkpoints/1 can be done as follows: curl -X POST -H "Authorization: Bearer ${TOKEN}" http://localhost:3030/{network}/db_backup?path=/home/aleo_ledger_checkpoints/1 Rolling back to (or, more precisely, switching to) the aforementioned checkpoint, is as easy as pointing --storage to the particular folder: snarkos --storage=/home/aleo_ledger_checkpoints/1 Alternatively, the original ledger can be removed, and manually substituted with the checkpoint. Retrieving program information Due to program upgradability, programs can now be upgraded, and therefore have higher editions. In order to surface this information, snarkOS now supports the following endpoints: curl http://localhost:3030/{network}/program/{programID} curl http://localhost:3030/{network}/program/{programID}?metadata={true} curl http://localhost:3030/{network}/program/{programID}/edition curl http://localhost:3030/{network}/program/{programID}/edition?metadata={true} The new metadata query parameter returns a JSON object with the following fields: { "program": "", "edition": 0, "transaction_id": "", "program_owner": "", } Build information A node’s build information can be surfaced via: curl http://localhost:3030/mainnet/program/version Which returns a JSON object with the following fields: { "version": "3.8.0", "git_commit": "9359abd0546c39e05b22112c768c90738577e212", "git_branch": "refs/heads/feat-add-version-endpoint" } Library and tooling updates snarkVM v4.1.0 snarkVM is a zkVM library. It powers the Aleo network and most of the software used to interact with it. The following contains some of the most relevant changes which were introduced: snarkVM has been upgraded to Rust 1.88 Process now exposes pub fn add_programs_with_editions, which allows wallets, provers and other applications to initialize a Process with the latest Program editions. Request’s pub fn verify now takes in an optional program_checksum, required for signing execution requests to upgradable programs pub fn deployment_cost now accounts for the finalize cost of constructor logic. Deployments now contain an optional program_checksum and program_owner, populated from ConsensusVersion::V9 onwards Programs now contain an optional constructor, populated from ConsensusVersion::V9 onwards Leo 3.1.0 Async blocks allow you to elide defining separate async functions, and write your on-chain code in the same location as the rest of the transition: async transition main(public a: u32, b: u32) -> Future { let f1: Future = other.aleo/main_inner(0u32, 0u32); let f:Future = async { f1.await(); }; return f; } You can use a .aleo file as a local dependency (previously dependencies were programs already deployed to the network, or local Leo projects): leo add --local this_dependency.aleo SDK 0.9.4 SDK Version 0.9.4 includes the following enhancements and fixes. Fixes: Enables the SDK to build fully offline transactions. To use this functionality, set your SDK dependency to 0.9.4-offline-rc Fixes SDK docstrings and completion of underspecified docstrings. Enhancements: Addition of a buildAuthorizationUnchecked method which allows building authorizations without building a circuit, allowing for build fast requests to trusted external provers. Addition of a ProvingRequest object that can be sent to trusted provers for remote proving Closing notes The full changelogs for the referenced releases can be found here: https://github.com/ProvableHQ/snarkVM/compare/mainnet...canary-v4.1.0 https://github.com/ProvableHQ/snarkOS/compare/mainnet…canary-v4.1.0 If you want to try it out, you can build from source today or download the mainnet release from github August 12th. 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! @d0cd @hritique @kaimast @iamalwaysuncomfortable @ljedrz @meddle0x53 @mohammadfawaz @mikebenfield @niklaslong @raychu86 @vicsn

Introducing ARC-0046: Strengthening Aleo Network Security Through Prover Staking

Introducing ARC-0046: Strengthening Aleo Network Security Through Prover Staking

ARC-0046 is a novel protocol enhancement designed to fundamentally strengthen the Aleo Network’s security and economic model. This proposal introduces a new staking requirement for provers, creating a more robust and sustainable ecosystem for all Aleo participants.

Announcing snarkOS v4.0.0

Announcing snarkOS v4.0.0

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) + randomizer To 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: Records now 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::InputID now includes for record inputs a "record_view_key": record_view_key entry. 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. Querytrait is 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 in None. 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

Updates to Aleo Records & Varuna

Updates to Aleo Records & Varuna

The Provable team has successfully coordinated a network upgrade with validators across all Aleo networks to roll-out important updates to Aleo records and the Varuna proof system. Records are a core primitive for encapsulating private state within programs on Aleo. Records are programmable and expressed in Leo by developers as a unit of storage for programs deployed on-chain. Varuna is an evolution of our peer-reviewed Marlin zkSNARK protocol, optimized to be the core cryptographic system that enables Aleo's private transactions and smart contract execution by allowing users to prove computation validity without revealing sensitive data. This upgrade demonstrates Aleo's commitment to maintaining a fully-upgradeable zero-knowledge proof system that evolves with the latest security & cryptography research, and upholds the privacy principles that developers and users have come to appreciate in Aleo. Key Updates Introducing a Sender Ciphertext to Aleo Records Our cryptography team has implemented a new compliance mechanism that allows record recipients to identify the originating sender. Every new record now includes a sender ciphertext, which is defined as an encrypted message containing the originating sender’s Aleo address. This sender ciphertext is encrypted under the recipient’s address, ensuring only the sender and receiver know who sent the record on the Aleo Network. Going forward, this feature will be enabled as a default, and enforced for correctness by validators during consensus. This feature ensures records offer provenance for the recipient, allowing for the respective parties to demonstrate their adherence to future compliance requirements of the chain. In addition, a feature has been built-in to allow for a future protocol change to make this component optional or disabled, as new compliance standards become defined in jurisdictions worldwide. To ensure this feature reaches all private Aleo credits, the major wallets operating on the Aleo network have agreed to collaborate on migrating user records. These wallets will help transition existing private Aleo credits into the new standard, providing comprehensive coverage for the rollout. As such, token holders will receive this update automatically from their wallet provider, requiring no action on their part. Updates to the Varuna Batching Implementation Our cryptography team implemented upgrades to Varuna's batching protocol, which enables efficient proof generation over multiple circuit statements. Through collaborative research with the security community, including feedback from our HackerOne program, we identified opportunities to strengthen the batching implementation. This update to Varuna addresses a design challenge that was identified in our implementation for zkSNARK batching: ensuring provers cannot adaptively modify their statements based on verifier randomness. Our solution adds one additional round to the Varuna Interactive Oracle Proof while preserving all existing performance characteristics and maintaining full-compatibility with all existing transactions. The upgrade underwent comprehensive validation including unit testing, integration testing, and cryptographic audits to ensure it preserved all intended security properties of the proof system. The latest specification for Varuna can be found here: https://github.com/ProvableHQ/varuna-sage-impl/blob/main/docs/spec.pdf What’s Next Our Commitment to Upgradeable Infrastructure Aleo's proving infrastructure is designed to be fully-upgradeable, allowing the core developers to integrate the latest advances in zero-knowledge cryptography while maintaining backwards compatibility with past transactions on the blockchain. This network upgrade demonstrates our continued ability to deploy improvements in a timely fashion across the ecosystem as new findings and research emerges. Operational Excellence across the Aleo Ecosystem This network upgrade demonstrates the ecosystem’s continued dedication to coordinate and facilitate major improvements to the Aleo Network. This process showcased a strong level of support in communication between validators, exchanges, wallet providers, proving pools, and developer communities. We continue to strengthen our review processes with analysis of how protocol optimizations interact with existing mechanisms. Our coordination capabilities for network-wide upgrades ensure we can efficiently deploy improvements while maintaining the security and reliability our users depend on. Acknowledgements Our appreciation extends to the teams at the Aleo Network Foundation, University of Pennsylvania, and EPFL for their ongoing expertise and contributions to our cryptographic infrastructure. In addition, we thank our HackerOne security researchers for their responsible disclosure and professional collaboration. Additional recognition goes to zkSecurity and Trail of Bits for their thorough validation of the source code that contributed to this network upgrade. This collaborative effort demonstrates the strength of our security & research community, along with our shared commitment to building robust, upgradeable cryptographic infrastructure that can evolve with the cutting edge of zero-knowledge research.

Introducing the Leo native testing framework

Introducing the Leo native testing framework

With the latest update to the Leo programming language, Aleo developers can now write unit tests directly in Leo code. This new feature enables developers to verify the correctness of their program logic before deploying it to the testnet, allowing for greater confidence in the quality and security of their dApps. Unit testing ensures that your program logic behaves as intended by allowing you to test individual transition functions. This granular level inspection checks that each transition function performs correctly in isolation, thereby helping to identify edge cases and potential vulnerabilities before they can be exploited. Unit tests also facilitate auditing, providing a clear and reproducible method for reviewing code behavior and ensuring compliance with project requirements or regulatory standards. Additionally, by catching bugs early in development, unit tests save you from the headache of redeploying a program to the testnet or mainnet after discovering an issue in production. By incorporating native unit testing into your workflow, your Aleo programs become more reliable, secure, and maintainable. Getting Started First, make sure you are using the latest version of the Leo CLI. The command will automatically generate a test directory containing a file with template code containing a script and a compiled test. leo new <project_name> Wondering why there are two types of tests? That’s because the Aleo blockchain contains both public and private state. Public state is modified through on-chain execution. Async transition functions that access mappings can only be tested using scripts. All other logic, such as minting records or hashing data, can be tested using compiled tests. Importing your main program The test file is a Leo program, so in order to be able to test your main program’s functions, you will first need to import it into your test program. Think of your main program as an external dependency for your test program. All of the transitions that you’ll be testing from your main program will be called as external programs inside of your test function code blocks. Just two more things to keep in mind. First thing to note – every test function must be annotated with the `@test` keyword before the function definition. Second point – test functions do NOT take inputs. All inputs must be hardcoded inside of the test function code block. Running compiled tests Compiled tests can be used to test any regular transition or helper function. The test will contain an external transition or external inline function, followed by an assert, as follows: @test transition test_simple_addition() { let result: u32 = example_program.aleo/simple_addition(2u32, 3u32); assert_eq(result, 5u32); } You can also test that invalid results are caught by adding a `@should_fail` annotation. @test @should_fail transition test_simple_addition_fail() { let result: u32 = example_program.aleo/simple_addition(2u32, 3u32); assert_eq(result, 3u32); } You can also use compiled tests to make sure that structs and records contain correct values for their respective fields. @test transition test_record_maker() { let r: example_program.aleo/Example = example_program.aleo/mint_record(0field); assert_eq(r.x, 0field); } Running scripted tests Now for the fun part! Scripts are useful for checking async transitions that interact with mappings. Since mapping data lives on-chain and since the testing framework can’t fetch on-chain data, we need to populate a mapping with some data before we can test it. Let’s say our main program has an async transition and corresponding async function that updates a mapping called "map": async transition set_mapping(x: field) -> Future { let future_1: Future = finalize_set_mapping(x); return future_1; } async function finalize_set_mapping(x: field) { Mapping::set(map, 0field, x); } How would we write a test to check that the mapping is being updated correctly? First, we need to replace the `transition` keyword with `script` to indicate that we’re running a script. Next, within the test code block, we’ll populate the mapping with a hard coded value. Since `set_mapping` is an async transition that returns a Future, we need to await the Future before checking that the value in the mapping matches the correct value: @test script test_async() { const VAL: field = 12field; let fut: Future = example_program.aleo/set_mapping(VAL); fut.await(); assert_eq(Mapping::get(example_program.aleo/map, 0field), VAL); } How do I run the tests? After you are confident that you have written all the tests required to satisfy unit testing gods, it’s time to give it a spin! If you want to run all of the tests together, simply run the following from the root of your project directory. leo test If you only want to run select tests, you can either supply the test function name or a string that is contained within the name of the test function: leo test test_async Or leo test async Conclusion With Leo's native testing framework, developers can now build more robust and secure Aleo applications by catching bugs early and ensuring their transition functions work correctly before deployment. Get started today by exploring the example repository and diving deeper into the comprehensive Leo language documentation to master unit testing for your dApps.

Announcing snarkOS v3.8.x

Announcing snarkOS v3.8.x

The Provable team is happy to announce a new version of the snarkOS Aleo implementation. Aleo is a cryptocurrency enabling developers to build cryptographically secure dApps. You can already use this version on testnet and it is planned to land on mainnet by June 17th, 2025 - at which point you can also download the release from github. Or, if you’re keen to dive in, build from source anytime you want. Please report any issues you might come across! What's new in v3.8.x snarkVM Consensus change A consensus change solidifying consensus logic will occur at the following block height: Canary - Block 6_895_000 (~June 6th, 2025 at the current block times) Testnet - Block 8_365_000 (~June 15th, 2025 at the current block times) Mainnet - Block 8,392,501 (~June 18th, 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. New bootstrap peer IPs This PR introduced new bootstrap peer IPs, which are nodes run by the Aleo Network Foundation! They are an optional gateway into the Aleo network. Improvements for developers When you issue cargo run or even cargo test with no code changes at all, cargo would still re-build the snarkOS binary (and this can take a long time) on every single invocation. With a single clean “cargo:rerun-if-changed=” line removed, you will no longer have a rebuild on every run. A bug was present in the previously added unconfirmed transaction endpoint, causing it to return confirmed transactions. This has now been fixed, the endpoint now returns unconfirmed transactions. There were a few things that made the CLI a little awkward to use, which is now improved. The power of Rust shines through scary idiomatic code such as the following: #[clap(default_value_t=MainnetV0::ID, long = "network", value_parser = clap::value_parser!(u16).range((MainnetV0::ID as i64)..=(CanaryV0::ID as i64)))] Improvements for validators A number of stabilization improvements are coming to consensus and peering. For example, the heartbeat logic has no notion of pending connections, so it might call Router::connect multiple times for the same peer while the handshake is happening. This change prevents frequent warnings being generated when a node attempts to connect to a peer, that it already connected or is currently connecting to, by not considering those cases an error. This PR clears the partially_verified_transactions on all the ConsensusVersion changes. All ConsensusVersions change consensus rules and regardless if it is transaction related or not, we clear the partially_verified_transactions out of abundance of caution. Leo 2.7.0: now with type inference! Alongside the new snarkOS release, there will also be a new Leo release. 🦁Leo is a programming language for formally verified, zero-knowledge applications on the Aleo network. From now on, we’ll be using these release notes to give an overview of new exciting features which landed in the programming language. Unsuffixed Literals and Basic Type Inference In many cases it’s now possible to avoid explicitly writing types, or to avoid the type suffix of numeric literals. let x: u8 = 12; // We no longer have to write `12u8`. let y = 12u8; // Or, instead of `let y: u8 = ...`, we omit the type. for i in 10u8..16u8 { // Can also omit the type here, instead of `for i: u8`. // ... } Clearer Reporting for execute and deploy Now when you use deploy and execute, you’ll get better messaging, including checking the status of your transaction. Closing notes The full changelogs for the referenced releases can be found here: https://github.com/ProvableHQ/snarkVM/compare/v3.7.1...testnet-v3.8.0 https://github.com/ProvableHQ/snarkOS/compare/v3.7.1…testnet-v3.8.0 https://github.com/ProvableHQ/leo/compare/v2.6.0...testnet-v2.7.0 Contributors A big thank you to all the contributors to this snarkVM, snarkOS and Leo release! @cypherpepe @d0cd @ljedrz @kaimast @kpandl @ljedrz @mikebenfield @mohammadfawaz @niklaslong @raychu86 @vicsn @VolodymyrBg

ProvaHack 2.0: Building Privacy dApps on Aleo

ProvaHack 2.0: Building Privacy dApps on Aleo

Earlier this month (May 2–15, 2025), Provable hosted ProvaHack 2.0, a two-week internal codefest where our team built open-source, privacy-preserving dApps on Aleo. Participants used Leo programs and deployed projects to the Aleo mainnet. What We Built on Aleo Each team leaned into Aleo’s strengths—proofs that keep data private, seamless on-chain deployments, and the flexibility of Leo. Here’s a deeper dive: Verifaleo Description: Verifaleo addresses the need for privacy-preserving identity verification (KYC) in dApps. It uses Aleo to link verified identities to soulbound NFTs, allowing users to prove their KYC status to services without repeatedly exposing sensitive personal data. Aleo's ZK proofs ensure that dApps can trust the verification status tied to an NFT without accessing the underlying private information, facilitating compliance while upholding user privacy. Codebase: https://github.com/esren0x/kycNFT PriceProof Description: PriceProof creates decentralized price prediction markets on Aleo, focusing on security and user privacy. The core problem it solves is enabling users to stake on future price movements anonymously, with Aleo's ZK proofs validating that reported outcomes verifiably match on-chain oracle data. This ensures a trustless and transparent market where participants are protected, and their strategies remain private. Codebase: https://github.com/bendyarm/priceproof/tree/main/leo/price_proof_test_1 The Solo Gambit (Pawnstorm) Description: Pawnstorm, from The Solo Gambit, introduces a chess variant with a twist: hidden bombs! The core challenge solved on Aleo is managing this hidden information and validating moves without a trusted third party. Aleo's ZK proofs allow each player's secret bomb placements to be tracked privately on-chain, ensuring fair play and strategic depth as moves are validated against both public game rules and private, hidden states. Codebase: https://github.com/mikebenfield/pawnstorm Proof of Bitcoin Description: Proof of Bitcoin tackles the challenge of privately proving ownership of Bitcoin reserves. Using Aleo, this project allows users to generate ZK proofs demonstrating they hold a certain amount of BTC without revealing their Bitcoin addresses or transaction histories. This is achieved by implementing critical cryptographic components on Aleo, such as ECDSA signature verification for Bitcoin's secp256k1 curve and necessary hash functions, enabling publicly verifiable yet private attestations of off-chain assets. Codebase: https://github.com/vicsn/snarkvm-btc-balance-verification/tree/ecdsa RetroBeatz Description: RetroBeatz offers a nostalgic quiz on classic game soundtracks, aiming to boost Aleo engagement through a fun, community-oriented dApp. The challenge lies in creating an interactive experience on Aleo that can manage quiz mechanics and potentially track high scores in a decentralized manner. It demonstrates Aleo's versatility for building user-friendly applications that can foster community and showcase the platform's accessibility. Codebase: https://github.com/wei-provable/midi-player Daddy’s Orders Description: Daddy’s Orders tackles decision fatigue with a fun, privacy-preserving randomizer on Aleo. The core challenge is generating a verifiably random Taco Bell order (main, side, drink) without a trusted central party. Aleo's ZK proofs ensure the randomness is generated on-chain and the outcome is truly unpredictable, offering a private and amusing way to let fate decide your meal. Codebase: https://github.com/christianwwwwwwww/daddys-orders snorkle Description: Snorkle provides a privacy-preserving oracle, tackling the challenge of securely bringing real-world data on-chain. Using secure enclaves and Aleo's zero-knowledge proofs, this service fetches external data feeds and attests to their authenticity without exposing sensitive API keys or endpoints. This allows dApps to trust and use external information privately and securely. Codebase: https://github.com/d0cd/snorkle lodive Description: Lodive addresses privacy and security in event ticketing by building a platform on Aleo. The core problem it solves is enabling the sale of soulbound tickets where attendee data is encrypted, ensuring buyer anonymity and preventing common issues like scalping and secondhand market scams. Aleo's ZK proofs allow event organizers to verify ticket authenticity and admission without accessing attendees' personal information, enhancing privacy throughout the ticketing lifecycle. Codebase: https://github.com/alexpitsikoulis/lodive Knightfall Description: Knightfall introduces Fog-of-War Chess to the Aleo blockchain, tackling the challenge of hidden information in strategy games. Aleo's zero-knowledge proofs conceal players' pieces from their opponent until they enter attack range, creating tactical suspense. This approach ensures fair play and privacy by managing hidden game states on-chain without revealing them prematurely. Codebase: https://github.com/dgrkotsonis/knightfall-aleo https://github.com/emmaprice082/knightfall Feeling inspired? Explore the Awesome Aleo GitHub repo! This is your go-to hub for Aleo developers and ZK enthusiasts. It gathers tutorials (from beginner to advanced), project ideas, and useful tools to jumpstart your work with Aleo’s privacy-focused platform. Whether you’re building dApps, exploring zero-knowledge proofs, or contributing to the Aleo ecosystem, it’s the perfect launchpad. Take the next step and immerse yourself in the Aleo ecosystem. By joining this ecosystem, you'll connect with like-minded individuals, gain access to exclusive resources, and have the opportunity to contribute to groundbreaking projects. Whether you're a seasoned developer, a curious newcomer, or simply passionate about ZK, the Aleo ecosystem welcomes your participation in building a more secure digital future.

Announcing snarkOS v3.7.x

Announcing snarkOS v3.7.x

The Provable team is happy to announce a new version of the snarkOS Aleo implementation. Aleo is a cryptocurrency enabling developers to build cryptographically secure dApps. You can already use this version on testnet and it is planned to land on mainnet by May 20th, 2025 - at which point you can also download the release from github. Or, if you’re keen to dive in, build from source anytime you want. Please report any issues you might come across! What's new in v3.7.x snarkVM Consensus changes: increase to 35 validators A consensus update is going to take place, allowing the validator count to increase to 35! Extensive load-testing was performed to confirm the robustness of the larger network. In future releases, the validator set will continue to increase in a responsible manner. Excitingly, due to the use of the Bullshark-based AleoBFT consensus algorithm, this increased validator set will increase the throughput of Aleo! The consensus changes will occur at the following block heights: Canary - Block 6_240_000 (~May 2nd, 2025 at the current block times) Testnet - Block 7_600_000 (~May 18th, 2025 at the current block times) Mainnet - Block 7_557_000 (~May 21st, 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. Improvements for developers Many developers and auditors are working hard to add program upgradability to Aleo. While this feature itself is not yet merged yet, several components which lead up to it, such as a cleanup of how imports are managed in snarkVM. This change, combined with program upgradability, will allow for cycles in the import graph, further increasing the expressivity of Aleo programs. We also got help from the wider ecosystem to harden the codebase. When deserializing an Authorization from a string that included multiple transitions, the structural assertion logic would erroneously fail - and this has now been fixed. Moreover, the height metric is now being updated during syncing so you can better see whether your node is almost ready or whether you have time to grab another cup of coffee. Finally, lots of documentation was improved across the snarkVM and snarkOS codebase. Improvements for validators Several improvements were made to harden the security of the consensus algorithm and node implementations. For example, deserialization of nested structs was hardened to reduce the chance of DoS attacks - we thank the anonymous HackerOne submissions for helping to strengthen the Aleo codebase. This PR brought 80%-95% improved RAM usage to load deeply nested programs into memory. Finally, increases in message versions should no longer cause immediate disconnects - they can now be introduced gradually at a future new consensus version. API changes Recall that a Transaction processed by Aleo validators can achieve the following states: accepted: This means that the underlying Deployment or Execution was successful, and that an associated Fee was consumed. The transaction has a confirmed id. rejected: If the Deployment or Execution logic fails, validators will try to process the Fee as an independent Fee transaction. The original transaction is associated with an unconfirmed id, the Fee transaction is associated with a confirmed id. aborted: If the Deployment or Execution logic fails, and the Validators also cannot process the Fee, the transaction is aborted. Tracking accepted and aborted transactions was previously possible, but tracking rejected transactions proved difficult for many ecosystem members. The following endpoint should help resolve this - you can now query an unconfirmed transaction by its confirmed id. GET /{network}/transaction/unconfirmed/:id Closing notes The full changelog for this upcoming release can be found here: https://github.com/ProvableHQ/snarkVM/compare/v3.6.0...canary-v3.7.0 https://github.com/ProvableHQ/snarkOS/compare/v3.6.0...canary-v3.7.0 Contributors A big thank you to all the contributors to this release! @acoglio @d0cd @ljedrz @kaimast @kpandl @lipsyre @ljedrz @lukenewman @mikebenfield @niklaslong @onetrickwolf @raychu86 @vicsn

Deploy Aleo Nodes with One Click on Google Cloud Marketplace

Deploy Aleo Nodes with One Click on Google Cloud Marketplace

Running an Aleo node with snarkOS just got a whole lot faster.

Announcing snarkOS v3.6.x

Announcing snarkOS v3.6.x

The Provable team is happy to announce a new version of the snarkOS Aleo implementation. Aleo is a cryptocurrency enabling developers to build cryptographically secure dApps. You can already use this version on testnet and it is planned to land on mainnet by April 22nd, 2025 - at which point you can also download the release from github. Or, if you’re keen to dive in, build from source anytime you want. Please report any issues you might come across! What's new in v3.6.x snarkVM Consensus changes: increase to 30 validators and spend limits A consensus update is going to take place, allowing the validator count to increase to 30! Extensive load-testing was performed to confirm the robustness of the larger network. In future releases, the validator set will continue to increase in a responsible manner. Excitingly, due to the use of the Bullshark-based AleoBFT consensus algorithm, this increased validator set will increase the throughput of Aleo to around 65 transactions per second! Additionally, spend limits have been introduced, which are discussed in more detail below. The consensus changes will occur at the following block heights: Canary - Block 5_780_000 (~April 11th, 2025 at the current block times) Testnet - Block 6_765_000 (~April 15th, 2025 at the current block times) Mainnet - Block 7_060_000 (~May 4th, 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. Improvements for validators Initialization runtime performance has improved significantly. Program loading on initialization now avoids an exponential slowdown incurred previously from recursive loading of the same program; and fetching from CDN has been sped up through increased parallelization. Overall runtime performance has also been improved. Validator committees are expensive to construct, and they are now cached in more places. Deployment synthesis has been sped up by almost 2x with help from a statically allocated vector and further allocation reductions. Peering and syncing logic has been overhauled to be more robust. Finally, proposal spend limits have been introduced to limit the maximum blocktime. Validator storage changes This PR fixed the storage path configuration for the proposal cache for validators, to ensure it is stored in the location indicated by the --storage flag. Previously, it was always stored in the default Aleo ledger directory. Validators using this flag should review whether they are backing up the entire indicated folder. Improvements for provers Support for CUDA has been merged which will speed up running a snarkOS prover out of the box. API changes This PR is an initial iteration of a validator telemetry implementation used for tracking metrics and performance of other validators. This will allow validators to better monitor the behavior of its peers (and itself) and react accordingly - directly via connections or off-chain via alerts. This new feature is currently guarded with a new telemetry feature flag for optional use by validators. There is a rudimentary concept of participation score that is exposed via logs and a new REST api: // GET /{network}/validators/participation // GET /{network}/validators/participation?metadata={true} Improvements for developers A locktick feature has been added which allows for logging of currently-held locks. This has proven extremely useful for hunting down deadlocks. Cargo doc now compiles again! Moreover, many parts of the codebase have been documented in much more detail - this ongoing documentation effort will improve the developer experience for new contributors. A regression testing suite has been developed to ensure all deployed programs continue to be valid on new versions of snarkVM - ensuring for example that R1CS synthesis does not change. Moreover, a small devnet is now automatically launched in CI on every open PR, catching more issues in a fully automated way. Closing notes This release, there is no update required for Leo, but a new release is on its way bringing several exciting updates, so stay tuned. The full changelog for this upcoming release can be found here: https://github.com/ProvableHQ/snarkVM/compare/v1.4.0...a296d35 https://github.com/ProvableHQ/snarkOS/compare/v3.4.0...a1e4a28 Contributors A big thank you to all the contributors to this release! @acoglio @d0cd @ljedrz @kaimast @kpandl @mikebenfield @niklaslong @onetrickwolf @raychu86 @vicsn

Programs

credits.aleo	35,757,477 CALLS
puzzle_arcade_coin_v002.aleo	8,805,613 CALLS
token_registry.aleo	6,561,353 CALLS
puzzle_arcade_ticket_v002.aleo	1,897,479 CALLS
pondo_protocol.aleo	1,465,400 CALLS

Validators

Coinbase	TVL $42,605,341
Coinbase	TVL $36,558,261
aleo185v9k487zd22gd5fddy05yhwch7ecw0ex6w7gwq95qalwl2trsxqqup5zc	TVL $35,247,471
Chorus One	TVL $23,858,976
Blockdaemon	TVL $20,856,709

DeFi

Pondo	TVL $11,287,577
Beta Staking	TVL $3,298,107
Verulink	TVL $2,823,022
AlphaSwap	TVL $511,166
Arcane Finance	TVL $315,709

Want to build cryptographically secure dApps at scale?

Use the Provable SDK to build secure, private applications on Aleo. Empowering digital privacy.Learn more

Latest Blocks

Latest Transactions

Products

© PROVABLE 2025

Developers

PLAYGROUND SDK WORKSHOP SNARKOS SNARKVM DOCUMENTATION

Company

ABOUT MISSION CAREERS TERMS PRIVACY

Updates

TWITTER/X DISCORD LINKEDIN