Validators
Provers
Programs
Blocks
Transactions
Docs

© PROVABLE 2025

Validators Provers Programs Blocks Transactions Docs

Explore AleoNetwork

Ctrl + K

Coinbase Target

211.85T

Program Calls Last 7 Days

167.22K

Total Network Stake

1.4BALEO

Percent staked

76.9%

Proof Target

52.96T

Deployed Programs

618

Total Transactions

23.97M

Total Validators

33

Total Provers

169

Total Puzzle Reward

132.98MALEO

Ecosystem News

Announcing Aleo Stack v4.2.0

Announcing Aleo Stack v4.2.0

Our team is happy to announce a new version of the Aleo Stack, which includes the node implementation snarkOS and the programming language Leo. These applications are built on top of the developer-friendly snarkVM and Aleo SDK libraries. Aleo is an open source cryptocurrency through which developers can deploy cryptographically secure dApps. Most notably, this release unlocks a reduction of base fees by 90%, as well as the introduction of priority fees. This effectively creates a fee market, allowing users to bid in order to get a higher priority in the mempool. The release also introduces various quality of life improvements such as new /v2/ snarkOS endpoints with more informative responses, performance improvements, as well as a `Leo update` command. If you want to try it out, you can build from source today or download the mainnet release from github September 9th. Find the current release schedule at: https://provablehq.github.io/. Please report any issues you might come across! What's new in snarkOS v4.2.0 Consensus change: ConsensusVersion V10 A consensus change will occur at the following times: Canary - ~9AM PT August 29th, 2025 Testnet - ~9AM PT September 5th, 2025 Mainnet - ~9AM PT September 16th, 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. Reduced Fees + Priority Fees The use of zero knowledge cryptography in Aleo enables a highly scalable blockchain network. However, those scalability benefits have not translated into low fees on the Aleo network - yet. Because of a large focus on security, high fees have served as an additional layer of defense against Denial of Service attacks. The time has come to deliver on the promise of zero-knowledge proofs, and to make transactions cheap. Technically, this will soon be possible because of the spend limits which are introduced, acting as another layer of defense against high compute. As such, this ARC proposes to reduce compute-related costs by a factor of 25x, which will significantly bring down average transaction costs by up to 92%. Note that private transfers are not impacted, because they did not incur any compute costs, which was the aspect which has been discounted. Example deployment cost reduction Program Price before [microcredits] Price after [microcredits] Reduction [%] credits.aleo 134,619,400 115,123,243 14.4 grant_disbursement_arcane.aleo 13,805,525 8,953,181 35.1 Example execution cost reduction Function Price before [microcredits] Price after [microcredits] Reduction [%] credits.aleo transfer_public execution 34,060 2,725 91.9 credits.aleo transfer_private execution 2,242 2,242 0 Priority fees This release also introduces priority fees which effectively create a fee market, allowing users to bid in order to get a higher priority in the mempool. In more technical detail, this PR introduces a priority queue for transactions containing a nonzero priority fee. This is drained before the pre-existing transactions queue when sending transactions to the BFT. A few notes on the current design: Priority fees for transactions already in the mempool cannot be updated. There is no protection against starvation: if the priority pool stays full enough, transmissions from the standard queue will not be sent to the BFT. Batch building is not atomic w.r.t. the memory pool. New endpoints Check transaction on broadcast Submitting transactions to blockchains and developing on them can be difficult. In order to verify transactions, you need the latest state, and it is ultimately up to consensus to include a transaction into a block, which is a multi-stage opaque process. To improve the quality of life for users and developers, this PR introduces a new feature for nodes allowing them to perform an early optional check on the transaction, and to return the result synchronously to the user: // POST /<network>/transaction/broadcast?check_transaction={true} The reason this is optional, is that for many applications, performance is critical, so the default behaviour is the same as before: the user gets a response just confirming receival, not approval. Fetching a batch of statePaths This PR adds a new REST endpoint that allows users to fetch multiple state paths at once. This will help mitigate the global state root to be the same across iterations issues seen when users/provers are querying for state. GET /<network>/statePaths?commitments=cm1,cm2,... The commitments in the query string are comma separated. At most 16 commitments can be fetched at a time. Informative snarkOS JSON-RPC responses snarkOS now supports versioned API endpoints. This change is backwards compatible, meaning by not indicating any version, or by using the /v1/ prefix, the original responses will be used. New /v2/ snarkOS endpoints have been introduced which return more informative error messages. Instead of only returning a 500 or 429, the REST API now returns the error chain as JSON It will (try to) set the HTTP status code correctly: /// 400 Bad Request - Invalid input, malformed parameters, validation errors /// 404 Not Found - Resource not found /// 422 Unprocessable Entity - Business logic validation errors /// 429 Too Many Requests - Rate limiting /// 503 Service Unavailable - Temporary service issues (node syncing, feature unavailable) /// 500 Internal Server Error - Actual server errors, unexpected failures These new return codes may become available via updated explorer APIs as well. Improvements for node operators Some further improvements worth mentioning include: Networking code has been significantly cleaned up, leading to fewer spurious connection issues. (#3754) Syncing has been further sped up and stabilized (#2745) Running a network with the `test_network` feature now prints more low level debugging information. Peers can now be specified both by IPs and hostnames. (#3768) ./snarkos start --peers "validator0:4130,client0:4130" The "Overview" page in the terminal UI (display) is usable again. It now shows the currently connected peers and information about the latest block. (#3767) What’s new in Leo 3.2.0 Leo Modules Leo 3.2.0 comes with a module system. Given a file other_module.leo containing struct, const, and inline definitions like this: const X: u32 = 2u32; struct S { a: field } inline increment(x: field) -> field { return 1field; { You may refer to contents of the module as other_module::X, other_module::S, and other_module::increment. 📁 Example Directory Structure src ├── common.leo ├── main.leo ├── outer.leo ├── outer │ ├── inner.leo 📦 Module Access Paths Given the structure above, the following modules are defined: common.leo defines module common, accessible from main.leo via: common::<item> outer.leo defines module outer, accessible from main.leo via: outer::<item> outer/inner.leo defines submodule outer::inner, accessible from: main.leo: outer::inner::<item> outer.leo: inner::<item> 📏 Module Layout Rules This PR also enforces new rules to prevent ambiguity and ensure consistency: Leaf modules (i.e. modules without submodules) must be defined in a single file: foo.leo Modules with submodules must be defined by an optional top-level foo.leo file and a foo/ directory containing the submodules: foo.leo # defines module `foo` - this is optional foo/ ├── bar.leo # defines submodule `foo::bar` Only relative paths are implemented so far. That means that items in outer.leo cannot be accessed from items in inner.leo, for example. This is limiting for now but will no longer be an issue when we add absolute paths. Leo Update leo update now allows you to select a particular version to install: leo update --name v3.0.0 Remaining stability improvements leo now allows you to decrypt records via the CLI. You may also pass in record ciphertexts as inputs to leo execute directly. Bug fix in outputting code regarding parenthesizing operands of the ternary conditional. Bug fix: eliminate redundant type errors in async function calls. Bug fix: correctly handle shorthand struct initializers which are consts. Bug fix: leo clean doesn’t produce errors when outputs or build directory isn’t present. Bug fix: correctly type check return statement in a constructor. Bug fix: check snarkos installation location. Bug fix: const evaluate const args before monomorphizing. Improved error messages for unresolved generics. Library and tooling updates What’s new in SDK v0.10.0 Updates to the KeyProvider interface with methods that enable local storage + implementations of the KeyProvider interface that store Proving and Verifying keys in local storage in Node.js and browser storage in browser contexts. This allows function executions to use locally stored keys to speed up execution. Update to the RecordProvider interface to enable metadata to be included with found records + implementations of the RecordProvider interface that allow users of the SDK to efficiently search for their own records. ProgramManager methods now accept object parameters instead of individual parameters. This enables developers to supply only required parameters to ProgramManager functions. Developers upgrading to v1.0.0 will need to make slight changes to their invocations of ProgramManager methods. Fixes that allow private transactions involving records to succeed consistently via a custom implementation of the QueryTrait. snarkVM v4.2.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: fn deployment_cost was renamed to fn deployment_cost_v1 fn deployment_cost and fn execution_cost were introduced to allow for switching on the cost function based on ConsensusVersion fn find_records now filters records by ownership before decryption in #2691 This PR implements get_state_paths_for_commitments to retrieve a batch of state paths rather than one at a time in the query. This will help mitigate the global state root to be the same across iterations issues seen when users/provers are querying for state. A floating‑point sqrt and type conversion was replaced by isqrt to support WASM-based platforms which don’t support floating point operations, in #2835 Support building snarkVM on SGX in #2791, enabled by the introduction of a filesystem feature, without which, the parameters crate won’t require a filesystem anymore to store parameters. fn authorize_request was introduced, which allows offline hardware wallets to sign a Request without importing the entire VM object. This is possible only for individual functions with public inputs and outputs, such as credits.aleo::transfer_public. The total amount of TestRNG call counts are now printed at the end of test runs to help facilitate debugging. This PR changes the Query type to use http::Uri internally for enhanced debugging. Closing notes The full changelogs for the referenced releases can be found here: https://github.com/ProvableHQ/snarkVM/compare/v4.1.0...testnet-v4.2.0 https://github.com/ProvableHQ/snarkOS/compare/v4.1.0...testnet-v4.2.0 If you want to try it out, you can build from source today or download the mainnet release from github September 9th. Find the current release schedule at: https://provablehq.github.io/. Contributors A big thank you to all the contributors on Github to this snarkOS, Leo, SDK and snarkVM release! @acoglio @anstylian @antonio95 @christianwwwwwwww @damons @d0cd @kaimast @iamalwaysuncomfortable @ljedrz @meddle0x53 @mohammadfawaz @mikebenfield @niklaslong @raychu86 @rejected-l @Roee-87 @trevor-crypto @vicsn

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.

Programs

credits.aleo	36,069,732 CALLS
puzzle_arcade_coin_v002.aleo	8,913,308 CALLS
token_registry.aleo	6,562,789 CALLS
puzzle_arcade_ticket_v002.aleo	2,013,781 CALLS
pondo_protocol.aleo	1,466,048 CALLS

Validators

Coinbase	TVL $39,743,105
Coinbase	TVL $36,543,881
aleo185v9k487zd22gd5fddy05yhwch7ecw0ex6w7gwq95qalwl2trsxqqup5zc	TVL $33,708,123
Chorus One	TVL $22,777,503
Blockdaemon	TVL $20,188,524

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