v4.2.1

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

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:

1. Priority fees for transactions already in the mempool cannot be updated.
2. 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.
3. 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:

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.

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:

• /// 200 Success
  

• /// 203 Non-Authoritative Information 
  

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

For example, the /transaction_broadcast endpoint will now return detailed information with regards to whether or not a transaction could be checked and whether the node is synced:

We encourage explorer APIs to support the new version and new These new return codes as wellmay 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)
• 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)