ARC-0005: Reduce Execution Fees by 90% and Introduce Priority Fees

[kpandl]

---

arc: 5
title: Reduce Execution Fees by 90% and Introduce Priority Fees
authors: @kpandl, @vicsn
discussion: ARC-0005: Reduce Execution Fees by 90% and Introduce Priority Fees
topic: Protocol
status: Draft
created: 2025-03-12

Abstract

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

We suggest to land this feature for release v3.6.0, which means testnet wallets will have to upgrade by May 13th and mainnet wallets by May 20th.

Background

The current fee model is very simple. Transactions which are submitted to the Aleo ledger consume resources on the network, and should therefore be priced accordingly. Transactions can either be deployments or executions.

Deployment base fees

• There is a size cost, determined by the amount of raw bytes of your program.
• There is a namespace cost, the smaller your program name the more you pay. There is no namespace cost if your program name is 10 characters or longer.
• There is a synthesize cost to process your program. The more complicated operations which your program has, the more time it takes for the network to convert this to a circuit to create zero knowledge proofs for. This cost is compute related.

Execution base fees

This is what you pay for executing program functions on the Aleo network.

• There is a storage cost, determined by the amount of raw bytes of your execution.
• This is a finalize cost, determined by the amount of operations in your function's finalize scope. This cost is compute related.
• There is no execution cost, because verifying the associated zero knowledge proof is very fast.

Specification

Initially, the compute costs can be reduced in snarkVM by introducing a const COST_FACTOR set to 25 as part of the network trait. snarkVM then uses the cost factor to compute fees of deployments and executions:

• A new function deployment_cost_v2 will divide the synthesis_cost by the COST_FACTOR. Note that storage_cost and namespace_cost remain the same.
• A new function execution_cost_v3 will divide the finalize_cost by the COST_FACTOR. Note that the storage_cost remains the same.

Both new functions deployment_cost_v2 and execution_cost_v3 can become effective at a certain block height in the near future.

Because fees are now much lower, we can also re-introduce priority fees in snarkOS. This will require another migration rule.

Clarifying by repository:

• snarkVM: We introduce a const COST_FACTOR which reduces compute-related fees by 25x
• snarkOS: Because fees are now so low, we re-introduce priority fees in snarkOS. Related PR 2977

Test cases

In snarkVM, we add a unit test to ensure the transaction fees are reduced as expected.

In snarkOS, we add a unit test to ensure a transaction with a high priority fee is moved ahead of the mempool queue.

In addition, we do extensive stress testing.

Experimental evaluation

We experimentally implemented the snarkVM PR and analyzed fees of commonly used functions.

Deployments

Tx type	Price before [microcredits]	Price after [microcredits]	Reduction [%]
credits1.aleo	134,619,400	115,123,243	14.4
grant_disbursement_arcane.aleo	13,805,525	8,953,181	35.1

Executions

Tx type	Price before [microcredits]	Price after [microcredits]	Reduction [%]
credits.aleo transfer_public	34,060	2,725	91.9
credits.aleo transfer_private	2,242	2,242	0

As seen in the data, especially execution costs can be reduced massively. This is of large benefit for the users of the Aleo blockchain, since the vast majority of transactions are execution transactions (~12 Million executions vs. ~200 deployments). It is expected that transfer_private transactions remain at the same price, as their only costs are the storage costs determined by the transaction size.

For most functions where the execution fee is reduced, we expect the reduction to be in the range of 91 to 98.4%.

Dependencies

This PR relies on snarkOS PR #3471 (spend limits) to be merged.

Backwards Compatibility

Although old fees may technically still be sufficient, transaction generators / wallets / transaction cannons should ensure from the network upgrade onwards that they:

• Use the new lower base fee computed from deployment_cost_v2 and execution_cost_v3.
• Offer a pathway for users to submit priority fees to increase the speed of inclusion, potentially even offering an interface to observe the average recent priority fee on the network to facilitate efficient bidding.

Security & Compliance

Testing of the PR, in conjunction with the batch proposal spend limits, shall ensure that new compute loads can be handled by validators and clients.

Out of scope

There is an abundance of literature on fee markets and mechanism design. The proposal in this ARC is simple to audit and adopt, and is an essential step on the road towards more complex out of scope upgrades, such as EIP1559 or blockspace tokenization.

References

• snarkOS PR #2977 on processing unconfirmed transactions by priority fee and age
• snarkOS PR #3471 on batch proposal spend limits

[lukenewman]

@kpandl thanks for the writeup!

• i think the size cost bullet under Execution base fees was copypasta'd from Deployment base fees and should instead describe the storage cost
• how did the COST_FACTOR come out to be 25?

[kpandl]

Thanks for your comment!

i think the size cost bullet under Execution base fees was copypasta'd from Deployment base fees and should instead describe the storage cost

Correct, thanks for pointing that out, I've fixed it.

how did the COST_FACTOR come out to be 25?

We wanted a significant reduction in compute-related fees, so we evaluated different factors. With 25, we maintain the design principle that transfer_private transactions remain cheaper than transfer_public transactions. As Aleo continues to evolve, we’re open to revisiting compute and non-compute fee structures in the future.

[d0cd]

@kpandl Is this ARC up to date? Does it need to be voted on?

[vicsn]

@kpandl Is this ARC up to date? Does it need to be voted on?

With the fallen token price, seems low priority at the moment, but can be revisited in the future

[mwyatt896]

@vicsn -- just replying for reference here for anyone passing by on why priority on this got bumped up in July

Puzzle Arcade ran into arcade store stock operations issues once we ran the massive Coinbase Quest campaign in Q2.
The best/fastest solution we found to resolve store stock operations based on user demand was to introduce daily giveaways that store stock could be converted into.

This was developed in April/May and released in late May with it becoming stable in June. The feature was a hit -- we watched user reviews improve/bad user feedback slowed, user feedback over discord was great, retention numbers greatly improved, and conversion numbers improved.

However after 1 month of usage (ie July) -- we saw that this feature actually increased the average $ALEO consumed by Puzzle Pro subscribers by >5x (0.9--1 ALEO per month to 4.4 ALEO -- 5 ALEO per month)

Demand is a great problem to have, but Puzzle cannot generate $ALEO fast enough to cover the $ALEO consumed by this increase from the new feature/product offering as is today even with Puzzle's validator staking commission on the 22M $ALEO staked. Puzzle floated to its community whether charging more on their monthly subscription ($4/month) was viable and it was not deemed so without expected high user churning because users found the product too expensive.

In mid-July, Puzzle was growing too fast and had to turn off/limit growth efforts until this ARC is passed and implemented or an alternative is found.

Hence the increase in prioritization today in July as opposed to Victor's comment above from April

[GlimoZK]

We’re not just service providers. We’re stakeholders.

I’m writing to express serious concern about the governance process surrounding ARC 5 — specifically, the exclusion of miners (provers) from voting, despite recent structural changes that directly affect us.

When ARC 46 was passed, it was promoted as a way to give provers greater stake and voice in the future of Aleo. Many of us accepted significant new staking requirements — scaling up to 2.5 million Aleo per solution over two years — on the premise that our economic commitment would come with governance participation. This was clearly framed as a tradeoff: deeper alignment with the network in exchange for influence over its direction.

Now, with ARC 5 being voted on, miners are blocked from voting entirely. This is a clear contradiction of the intent and messaging behind ARC 46. It gives the impression of a bait-and-switch — securing economic buy-in from miners, only to sideline us from governance once that buy-in is locked in.

The timing is especially troubling. ARC 5 is a critical protocol-level change. Blocking miner participation at this moment suggests that governance is not truly community-driven, but selectively applied to preserve control within a smaller group of stakeholders — namely, the Foundation and validators.

This pattern undermines trust in the governance process and in the Aleo Foundation’s commitment to decentralization. If miner participation is good enough to secure the network’s compute layer and economic security, it should be good enough to help decide the network’s future.

I urge the Foundation and core contributors to pause this vote, re-evaluate governance inclusion criteria, and clarify when and how miners will be given the governance power that was promised.

We’re not just service providers. We’re stakeholders.

[mwyatt896]

@GlimoZK -- hey Glimo!

Totally hear your perspective and think it's extremely understandable given the quick timing here. However, I think you may have missed the community call last Monday where this was discussed or the comment above that explains why this was reprioritized all of a sudden.

I am on the same page with you that the outreach and governance process can be improved to make sure everyone saw it. I was on the all core dev call last Monday when this ARC05 was discussed and decided to bring to a vote this week and it was clear that most miners were not in attendance (<30 total attendees total).

This ARC05 needs to pass or Puzzle (currently 99.9% of Aleo activity) cannot continue growing and pushing the limits of Aleo to the benefit of the entire community. I don't think pausing this vote solves the root of the problem -- it will only compound the problem even worse as Puzzle would be forced to evaluate alternative options to continue running our business and hurt all Aleo stakeholders.

Rather than pausing this vote, I believe the root of the problem is actually just getting the new larger mining stakeholders more involved in the all core dev process and that there should be some Aleo Foundation community lead focused on making sure all the larger mining stakeholders attend all core dev calls to stay aware of the community's pressing needs.