Starknet v0.13.1: EIP4844 Support, More Fee Reductions, Stability, Quality of Life

(Coming to integration on February 12; testnet dates TBD in the upcoming days.)

What’s better than your favorite pizza? A cheeseburger. Your favorite pizza, but cheaper!

Starknet v0.13.1 has rich toppings! First, it adds support for Ethereum’s long-awaited EIP4844 upgrade, expected to massively slash Starknet’s data availability (henceforth DA) costs. Second, it continues the reduction of transaction fees initiated in v0.13.0: not only will DA fees be reduced in accordance with Ethereum’s blob market, but compute fees will also be reduced due to shiny new optimizations! Third, it contains many behind-the-scenes improvements to the code. Finally, it will make transaction receipts more informative, including full resource consumption and fee accounting.

Let’s get our hands in the dough!

Update: v0.13.1 also includes fee reductions. For more information, see here!

EIP4844 Support

EIP4844 is one of the most highly anticipated Ethereum upgrades in a long time. Intended to reduce the data availability costs of rollups, it introduces “blobs” as an alternative to calldata for sending data to Ethereum. Moreover, the upgrade introduces “blob gas” – a new resource, separate from gas, that is consumed only by “blob transactions”. Consequently, the blob market is expected to mostly consist of rollups, without competition by standard Ethereum users. Thus the demand of rollups (as opposed to all Ethereum users) will determine blob prices and by extension rollup DA costs.

Starknet v0.13.1 will include support for this Ethereum upgrade. In a nutshell, state-diffs which are currently sent as calldata will be sent as blobs. To give some more details:

  1. The SNOS will output an evaluation of an interpolation of the state-diffs as opposed to its current output of the state-diffs themselves. It will also forward a KZG commitment to the state-diffs that was computed in the backend.
  2. A separate service will send state-diff blobs.
  3. Integrity of the state-diff blobs will be verified as part of the state update process by comparing a random sample from the blob’s KZG commitment with a random sample from the commitment output by the OS.

Note that v0.13.1 does not add blob gas as an additional protocol-level resource: for now we remain only with “gas”. We will review whether or not it should be added (e.g included in the fields submitted in v3 transactions) in the future.

For a lot more detailed, see this great post by @FeedTheFed!

Transaction Fee Reductions

Roughly speaking, Starknet transactions consume two resources: data (for Starknet’s DA), and compute (Cairo steps and various builtins). Transaction fees for both resources will be reduced in v0.13.1. (We purposely disregard L1/L2 message fees for simplicity; details about the fee mechanism can be found in the documentation.)

An obvious source for DA fee reductions is EIP4844 support: reduced DA costs justify a reduction in DA fees charged from users. And indeed, each transaction’s L1DA fee will be computed from its expected blob gas consumption when posted to L1. Going by the prevalent sentiment, this should massively slash DA related fees, which comprise over 80% of the average transaction’s fee!

A less obvious reduction in compute fees comes from some more optimizations of L1 gas consumption both by Starknet and by SHARP that are just around the corner, namely larger blocks, larger SHARP trains and smaller proofs submitted to L1. Resisting the temptation to expand more here, I’ll defer the fascinating topic of fee and cost reduction roadmaps in Starknet to its own post, coming soon!


Over the past few months, Starknet downtimes prompted the community to call out for stability improvements. We listened and dedicated a lot of engineering resources to improve, clean, and iron out many flows and parts of the code. While this blessed work will be invisible to users it will greatly enhance testing, alerts, metrics, logs, bugs, configs, and more. After all, it’s the quiet ones you have to watch out for…

Quality of Life

Starting from v0.13.1, transaction receipts will display full execution resources, taking syscalls into account. They will also separately report DA resource consumption, making it easy to see how transaction fees are divided between DA and compute.


The ecosystem guides us on! Fee reductions continue in v0.13.1 with support for the epic EIP4844 to reduce DA fees and SHARP-related optimizations to reduce compute fees. Stability is greatly improved in many senses. Transaction receipts are rounded out.

We want you :index_pointing_at_the_viewer: to share feedback, ask questions, make suggestions, and share criticism!

GM GM, ilia!

Does it mean that usual users will have opportunity to test/use it after Feb 12?
I’m waiting to spend all my $ETH for ecosystem products, but with the “cheap” gas😁

Happy Lets Go GIF by Togethxr

GM GM GM @lover!

It’ll be difficult for users to use integration, since generally speaking they interact with Starknet through wallets, which in turn rely on SDKs which in turn require RPC providers which in turn require a new version of full nodes.

You’re welcome to try out the new version when it’s deployed on testnet in a few weeks!

can you explain how the introduction of blob gas (lol) in 4844 is expected to influence the market dynamics for rollups versus standard eth tx… like how it would alter the way state-diffs are handled :pinching_hand:

Hey @ilia,

First of all, nice post!

Can you give more details on what will change regarding the transaction receipts and its execution resources?

Does it mean that as soon as 4844 hits L1 mainnet, Starknet will take full advantage of it pretty much immediately?

Hey @gaetbout, thanks! Two key receipt changes:

  1. Receipts will reflect the execution resources consumed by system calls. Until now, if your tx used a syscall that consumed 1K steps, these steps were not reflected in the receipt, but the fees charged for them were. Consequently, there was a gap between execution resources and fees.
  2. Receipts will separately report the DA fees charged from the user. Until now, it was not straightforward to look into the DA fees paid by users.

Hey @milan! That is our goal!