From Milestones to Masterstrokes: StarkWare’s Year in Review

STARK-tech as the secret sauce that helps dApps scale and thrive on Ethereum — today and tomorrow.


  • Starknet set the foundations to be the home for complex, computational-hungry, and innovative DeFi platforms, onchain games, dynamic NFTs, and more.
  • Starknet continues to have the fastest-growing dev ecosystem among all L2s (and a few L1s).
  • StarkWare open-sourced key elements such as Stone Prover, Starknet sequencer, and Papyrus full node in 2023.

Read on to learn about our highlights and the overall progress of the Starknet ecosystem in 2023.

Decentralization & Community Expansion

L1 limitation of scale, UX, and high costs have made creating successful onchain games nearly impossible. But with the maturity of Validity Rollup technology, the promise of onchain games is finally being delivered.

As a result, the number of projects building fully onchain games on Starknet boomed over the past year. Some examples include Influence, a grand-strategy MMO set in a distant asteroid belt with a player-owned open economy, Shoshin, a user-programmable fighting game, Realms, a fantasy-strategy game, and Loot Survivor, a survival-strategy game.

This year, we also saw the launch of Dojo, a decentralized gaming engine built by the Starknet community, which simplifies key elements required for game building. Other components like ECS, Sozu, Torii, and Katana aid game development and deployment.

  • The Starknet Decentralization Roadmap

The Starknet ecosystem took several strides in 2023 toward fulfilling the Starknet decentralization roadmap. Published in October 2023, this canonical paper outlines the values on which the ecosystem was created, how the transition process to a decentralized Starknet will look like, the decentralized network architecture, and the plan towards a fully open-sourced software stack.

  • The Devonomics Pilot Program

Starknet’s founding vision recognized that developers are central to the network’s
mission of scaling Ethereum while retaining Ethereum’s core principles of decentralization, transparency, inclusivity, and security.

That’s why, in December 2023, and in accordance with this vision of decentralized governance, the Starknet Foundation, in collaboration with StarkWare, launched the Devonomics Pilot Program. A first-of-its-kind program among L2s, Devonomics distributes over 1,600 ETH to Starknet dApp and Core Developers who have contributed to Starknet’s expansion and adoption. The distribution is done via a novel mechanism that aims for fairness, inclusivity, and transparency.

The end goal of Devonomics is to bolster developer participation in decision-making and the future operation of Starknet.

STARK-Tech: Reaching New Heights

  • Leading the Pack

STARK-Tech continues to scale Ethereum and provide apps with the ability to grow their audience and activity at low costs. StarkEx passed $1 trillion (yes, you read that right) in cumulative trading, and Starknet, during several weeks in 2023, scaled more activity on Ethereum than all the other L2s combined.

Moreover, in 2023, Starknet’s developer ecosystem grew by 14% to become the 8th largest crypto developer community, the largest developer ecosystem among all L2s.

The release of Starknet Alpha v0.12.0 marked the beginning of a quantum leap forward in providing enhanced performance and scalability, featuring a 10x increase in throughput. Three key ingredients contributed to this improvement: Cairo VM in Rust (part of a year-long collaboration between LambdaClass and StarkWare), Blockifier, and Papyrus, all benefiting from the power of Rust.

Innovating on Ethereum

In ground-breaking research that used cryptographic proofs and block hashes, Herodotus collaborated with StarkWare to prove Ethereum blocks all the way back to the Genesis block. Until this point, the only records developers could access in a trustless manner was the history of the past hour. However, by leveraging Herodotus’s storage proofs solution and StarkWare’s powerful SHARP (SHARed Prover) system, developers can now retrieve — in a chain-native and provable way — all Ethereum block hashes back to the Genesis block.

By doing so, this accomplishment achieves the goals of EIP-2935 — a way to access historical block hashes older than 256 blocks in a chain-native way, and unlocks new use cases for Defi and more.

Open-Sourcing Time — Setting New Bars for Protocols

In keeping with its vision to facilitate decentralization on Starknet, StarkWare open-sourced various key components of its tech stack to empower developers. Here are some of the key elements that were open-sourced:

The upgrade from Cairo Zero to (the new) Cairo in January brought 2023 in with a bang. A major milestone in the evolution of Cairo, the Turing-complete programming language for efficiently writing provable programs, this new release made Cairo dev-friendly, allowing for writing safer code while also being more expressive.

Cairo also introduced Sierra, a new intermediate representation that ensures every program that Cairo runs can be proven. This makes Cairo particularly well-suited for use in a permissionless network like Starknet, where it can provide robust DoS protection and censorship resistance. To learn more about Cairo, read here.

A Rust implementation of a Starknet full node, Papyrus was launched to provide the foundations for the new Starknet Sequencer, which dramatically enhances Starknet’s throughput. In line with StarkWare’s ongoing move to open-source the Starknet stack, Papyrus was provided open source under the Apache 2.0 license and joined other Starknet full nodes — Pathfinder, Juno, and Deoxys — which were built by external teams in the ecosystem.

Built on the foundations of Papyrus, the new open-sourced Starknet sequencer became available under the Apache 2.0 license and was designed and developed to boost throughput and level up Starknet’s performance. The vital first stop in a user transaction’s journey to STARK scaling, sequencers order the transaction and produce blocks to be converted into a proof for Ethereum.

StarkWare open-sourced its battle-tested and powerful Stone (STARK one) Prover under the Apache 2.0 license. In doing so, StarkWare allows builders to use this robust battle-tested prover and build their proving systems around it for whatever cause they choose. It also allows more eyes to review the code and offer optimizations, improve its quality, help detect bugs, and provide transparency.

Appchains on Starknet: The Home of Innovative dApps

Public networks offer composability and ecosystem benefits, but for some apps, a dedicated scaling solution can offer specific benefits that cannot be implemented on the public network. Starknet appchains are making notable strides forward, with the first Starknet appchain already in production. Here are a few milestones we saw in 2023:

In July 2023, Paradigm, the largest institutional liquidity network in crypto, launched Paradex, a crypto-derivatives exchange and the first appchain on Starknet. The launch demonstrated Starknet’s ability to cater to the needs of apps that require heavy computation, low costs, and custom specs, all while retaining self-custody.

The smart contract behind this new, beta-stage perpetual trading platform was written in Cairo by the Paradex team within only six months.

The launch of Madara, a sequencer built by Starknet’s exploration team and community members, was a game-changer for projects and developers interested in creating customizable and efficient appchains.

By using the Substrate framework, Madara amplifies the capabilities of the Cairo VM, leading to provable, secure, and flexible programs. Madara offers developers special features, including support for potential onchain privacy, streamlined interoperability across various chains, and robust execution.

Madara is paving the way in dApp development by delivering cost-effective, scalable, and customizable solutions in the blockchain domain and already has many projects using it to enhance their apps with scalable infrastructure, high throughput, and unprecedented control.

One of the Starknet ecosystem’s main goals is to provide developers with decentralized, open-sourced tools that empower them to create scalable and secure projects. Starknet has the most decentralized rollup stack, including lots of key infrastructure built by multiple independent teams.

Community Engagement & Events

While creating programs to benefit our existing community members, StarkWare continued expanding the Starknet community by holding countless meetups, workshops, hacker houses, and events. Two of the events that stand out most are StarkWare Sessions and StarkWare Summit.

  • StarkWare Sessions — Over the course of two days, StarkWare hosted more than 1,000 attendees from all over the world, crypto ecosystem, and walks of life. Designed to bring the ever-expanding StarkWare community together to meet, collaborate, and learn, the event exceeded our wildest expectations and served as a promising beacon for the future of the Ethereum and Starknet developer community. Relive the magic of all the discussions and workshops on our YouTube channel.
  • Starknet Summit — In August, hundreds of participants flew into San Francisco to meet the faces behind the Twitter handles and Discord IDs of the vast STARK ecosystem.

Vision for the Future

StarkWare aims to lead the way in developing the most innovative solutions for scaling Ethereum.

STARK-tech has proved itself to be the secret sauce that allows amazing use cases to scale and thrive and turning Starknet into a hub of creative apps with complex logic such as fully onchain gaming, perpetuals, dynamic NFTs, and more.

Throughout 2023, StarkWare supported the Starknet ecosystem with tools for building blockchain applications by providing unlimited scaling needs at low costs. In parallel to those accomplishments, StarkWare made significant strides toward supporting developers and other members of the ecosystem, under its goal of expanding decentralization on Starknet.

By introducing innovative technology and processes, and open-sourcing key elements of its tech stack, Starknet became the fastest-growing L2 (by number of devs) in the industry and continues to expand. Going into 2024, expect StarkWare to build on these amazing achievements and bring more ideas to Starknet’s thriving ecosystem.

Make sure to join the discussion on Discord and follow StarkWare and Starknet on X.

From Milestones to Masterstrokes: StarkWare’s Year in Review was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Starknet Launches the ‘Devonomics’ Pilot Program

Moving towards decentralization by supporting and empowering Starknet developers


  • The Starknet Foundation, in collaboration with StarkWare, is launching Devonomics, an experimental pilot program that puts Starknet developers first by rewarding and empowering them.
  • Devonomics is initially allocating over 1600 ETH ($3.5M+ at time of publication), constituting 10% of all transaction fees accumulated until November 30, 2023.
  • The program runs through a transparent and inclusive distribution process, unique to Ethereum’s L2 landscape.
  • The end goal of Devonomics is to bolster developer participation in decision-making and the future operation of Starknet.


In accordance with its vision of decentralized governance, the Starknet Foundation, in collaboration with StarkWare, is launching the Devonomics Pilot Program which will distribute over 1,600 ETH (over $3,500,000 at current prices) to Starknet developers. This constitutes approximately 10% of all Starknet fees accrued from November 2021 until November 30, 2023. The distribution will be done via a novel mechanism, unique to the Ethereum L2 landscape, that aims for fairness, inclusivity, and transparency.

This post provides background on Starknet, describes the details of Devonomics, and explains how it relates to Starknet’s decentralization vision. Finally, it discusses Devonomics in the broader context of other initiatives for Starknet users and developers.

Background on Starknet

Since Nov ’21, developers worldwide have worked around the clock to build and develop Starknet’s Mainnet, the first Turing-complete Validity Rollup on Ethereum. As a result, Starknet is now the largest developer ecosystem among all L2s, having grown 14% over the past year to become the 8th largest blockchain developer community, and the leader in the L2 landscape.

This growth is partially explained by the mature technology stack Starknet offers. This stack is built on STARKs — the safest and most scalable proof system; Cairo — an ergonomic and dev-friendly smart contract language; and includes novel blockchain features like native account abstraction.

Another explanation for the rapid growth of Starknet’s developer ecosystem is its vision, in which Devonomics plays a key role.

Starknet’s Vision Reflected in Devonomics

Starknet’s founding vision recognized that developers are central to the network’s mission of scaling Ethereum, while retaining Ethereum’s core principles of decentralization, transparency, inclusivity, and security.

By distributing fees via the Devonomics Program, Starknet is progressing according to this vision in the following ways:

  1. Rewarding developers for operating and developing the network

Devonomics will give devs additional rewards for operating core network infrastructure or building new dApps and incentivize them to continue doing so in the future. In this sense, the program is a realization of the network’s governance vision. “A fair, open, and censorship-resistant service is only possible if several parties show up to compete to perform work that powers the decentralized service, and that can only be guaranteed if those workers are compensated for their role as operators of the network.” (A Decentralization and Governance Proposal for Starknet)

2. Empowering developers to govern the network in a decentralized manner

Devonomics helps those who build the network and its dApps play a prominent role in governing the network. It ensures that no single centralized entity holds sway over Starknet. It uses a reliable method for judging the level of contribution of dApps to the ecosystem, assessed by fees generated, and likewise will use reliable methods to judge the contribution of core developers. These judgments are then reflected in the strength each developer has in the governance of the ecosystem.

3. Maintaining and securing the network by staking

In the future, all fees on Starknet will be denominated in STRK and the operation of the network will be decentralized via a Proof-of-Stake based protocol. At that time, Devonomics will enable devs to stake their STRK to participate in ensuring the liveness and security of the network, via sequencing, STARK-proving services and data availability provisioning, to name a few examples.

Overview of the Devonomics Pilot Program

As mentioned above, Devonomics will initially allocate 10% of Starknet transaction fees accrued from the launch of Mainnet in November 2021 until the end of November 2023. This is over 1,600 ETH (over $3,500,000 at the time of writing).

This sum will be distributed by the Starknet Foundation to two cohorts of developers, (a) dApp Developers and (b) Core Developers, as follows:

Fee allocation for dApp Developers

The program will distribute 8% of collected fees (over 1,200 ETH) to dApp Developers.

The value offered to users by a smart contract is reflected in the amount of fees collected by that smart contract. By allocating a fixed portion of fees to each smart contract, Starknet rewards dApp Developers objectively, transparently and fairly, in correlation with the value they offer to Starknet users. In other words, smart contracts that contribute to users’ engagement with Starknet will receive more funds.

The computation of the exact allocation to each dApp is done by measuring the L1 and L2 fees paid by users of these contracts (the fee estimation algorithm has been built to ensure the inclusion of a variety of dApps and will likely be modified over time). In the future, the allocation of fees and ongoing newly minted Stark Tokens to dApp Developers will be automatically done by the Starknet protocol itself in a manner that is fair, transparent and objective.

A description of the fee allocation algorithm and the list of recipient Starknet accounts can be found here.

Fee allocation for Core Developers

The program will distribute 2% of collected fees (over 300 ETH) to Core Developers.

While the relative value offered by dApp Developers can be assessed by the fees users pay, there is no known objective metric to compare the contribution of Core Developers, such as those who write code for provers, sequencers, full nodes, long-term storage providers, etc. Therefore some human discretion is needed. However, having a single central entity assigning a fixed portion of fees to Core Developers would be arbitrary and open to favoritism. With this in mind, we are conducting research on the best practices to evaluate contributions in a fair, transparent, and efficient manner, and we are learning from existing mechanisms in the blockchain space.

For the current Pilot Program, we decided to put the responsibility for recommending the assignment of funds to Core Developers in the hands of the very dApp Developers who receive fees from the program. We made this decision in order to have a simple yet reliable mechanism for the Pilot Program, as dApp Developers are familiar with core projects and their contribution to Starknet.

In other words, during the Pilot Program, each dApp Developer will be asked to recommend how to allocate an additional 25% of fee revenue on top of what they have received. Thereby, an additional 2% of fees collected by Starknet (over 300 ETH) will be apportioned by dApp Developers to Core Developers whose work they value.

Example: Suppose Alice, a dApp Developer, is set to receive 8 ETH. As part of the claiming process, Alice will be asked to recommend how to allocate a separate amount of 2 ETH (i.e., 25% of her allocated amount), to Core Developers, at arm’s length. To clarify, this amount of 2 ETH is separate from, and additional to, the 8 ETH that Alice receives as a dApp Developer, and is paid directly from the Starknet Foundation to the Core Developers.

Further restrictions appear in the “Fine Print” section below.

Other Starknet Initiatives for Users and Developers

Devonomics is one of several complementary initiatives that reflect Starknet’s commitment to decentralization. These initiatives seek to empower important network stakeholders who have contributed in the past to Starknet’s success, and ensure that present and future stakeholders continue to maintain Starknet as a public good. Previous Starknet Foundation initiatives include:

Regarding user-facing initiatives, the upcoming first round of Provisions, the first of several rounds, will initiate Starknet’s user-focused decentralization efforts. Future user-oriented initiatives include rebates denominated in STRK on transactions performed, and other mechanisms that recognize and reward the contribution of users to the network.

Finally, in the near future there is expected to be a significant reduction in fees, a benefit to all ecosystem users.


The Devonomics Pilot Program is an important step in Starknet’s progress towards a fully decentralized ecosystem in both its tech stack and the processes that govern it. Put simply, it is a bold experiment in building and sustaining a decentralized community.

By allocating 10% of transaction fees to developers, the program seeks to encourage the growth of the Starknet community and bolster the role developers play in the network’s decision making processes. As the program is expected to change over time, developers are encouraged to actively participate and explore this exciting space together by providing feedback to shape the pilot program’s evolution into something more robust and permanent.

Want to join the discussion about the Devonomics Pilot? Join our community forum and follow Starknet on X.

To become a member of Starknet’s community, get started with the Starknet Book and Cairo Book.

— — — — — —

Fine Print

  • At the moment, there is no need to reach out to the Starknet Foundation or any other party in the Starknet ecosystem regarding participation in the program. The Starknet Foundation will initially reach out to projects directly and later on share details on how to receive fee allocations through the program.
  • Fees in the first phase of the program will be paid in ETH, and, when relevant after the launch of Starknet v0.13.0, in both ETH and STRK. Generally speaking, Devonomics will be denominated in the token(s) used to pay transaction fees on Starknet.
  • It should be noted that the Devonomics mechanism is not supposed to replace sustainable business models for projects. In particular, it may be modified over time and may be terminated at any point in time based on an evaluation of its benefit to the Starknet ecosystem.
  • The mechanisms for allocating fees to both dApp and Core Developers will be modified over time, to improve transparency, fairness and efficiency.
  • The fraction distributed is very likely to change over time, e.g., following events such as future fee reductions on Starknet due to greater efficiency and scale, the introduction of EIP-4844, introduction of a fee market to Starknet and modification of the Starknet gas computation model. The percentage may also evolve based on community feedback and other factors.
  • The Starknet Foundation will strive to allocate fees in accordance with the outlined pilot program. However, final discretion on all payments will be left to the Starknet Foundation, to accommodate regulatory and financial obligations.
  • The Devonomics Pilot Program has a total budget of 8% for dApps and 2% for Core Developers, but this does not create a current or future commitment, legal or otherwise, to allocate to any dApp 8% of the fees collected through such dApp. The exact computation method for the Pilot Program is merely an attempt to approximate a fair allocation.
  • The claiming threshold for receiving fees in this round is set at 0.1ETH. In case this threshold is not reached, fees will accumulate and roll over to the next distribution date until the threshold is met.


What do I need to do to receive Devnomics?

Nothing, at the moment. The Starknet Foundation will release further details at a later point in time and will contact the relevant projects.

Starknet Launches the ‘Devonomics’ Pilot Program was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Session Keys: Unlocking Better UX

Towards a Smoother Blockchain User Experience

Ethereum has revolutionized the world of decentralized applications (dApps), offering a secure and transparent way to interact online. However, early blockchain networks like Ethereum, provide a basic account model which is unintuitive for most users, called Externally Owned Accounts (EOAs).

In a recent blog post about native account abstraction, we dived into the key challenges posed by EOAs:

  • A subpar blockchain user experience.
  • Security risks associated with complete control by the private key holder.
  • The lack of flexibility due to EOA’s rigid ties with the Ethereum protocol.

To deal with these problems, account abstraction was introduced. Account abstraction redefines how accounts function, offering developers flexibility through customizable “account contracts.” These contracts, acting as smart contracts, employ the three pillars of account abstraction: signature abstraction for custom permissions, fee abstraction for versatile payments, and nonce abstraction for enhanced convenience.

For a deeper understanding of the challenges associated with EOAs and how Starknet overcomes them, visit Native Account Abstraction: Opening Blockchain to New Possibilities.

Session Keys

A particularly promising application of account abstraction lies in the concept of “session keys.” Traditionally, decentralized applications (dApps) require users to individually sign each transaction through their wallet, introducing friction, especially during multiple transactions in a session. Account abstraction introduces the innovation of generating “session keys,” enabling a dApp to autonomously sign transactions on behalf of the user for a specified period and transaction parameters, such as limits on duration and value.

The implementation of session keys presents a significant opportunity for dApps to streamline user interactions. Users can tailor session keys to their specific needs, whether they engage in frequent trading or occasional purchases. This adaptability fosters a more inclusive user base for blockchain technology and markedly enhances user experience in two pivotal areas: decentralized finance (DeFi) and onchain gaming.


In the DeFi realm, the current inconvenience of decentralized exchanges (DEXs) lies in the necessity to approve each transaction individually at various stages. However, with session keys, we can replicate the seamless experience of centralized exchanges (CEXs) without succumbing to their drawbacks. For instance, a user could create a session key valid for an hour, allowing trades of up to $7000 on a decentralized exchange without the need for individual confirmation of each transaction through their wallet. This not only simplifies the process but also contributes to a more user-friendly and efficient DeFi ecosystem.

Session Keys: Unlocking Better UX


The current state of onchain gaming can be described as clunky at best. Rather than imposing the intricacies of managing gas fees or signing multiple transactions on users, session keys facilitate seamless UX, resembling the smooth experience of traditional games. This shift results in a more user-friendly onchain gaming environment, liberating gamers from the hassle of configurations and errors. Gamers can focus on gaming, instead of having to focus more on the blockchain itself.


Ethereum has transformed decentralized applications (dApps) but faces challenges with rigid account structures like Externally Owned Accounts (EOAs). The introduction of account abstraction addresses these issues, offering developers flexibility and enhancing user experience through customizable “account contracts.”

Perhaps one of the most important applications of account abstraction is “session keys,” which streamlines user interactions in DeFi and onchain gaming. In DeFi, session keys eliminate the need for individual transaction approvals on decentralized exchanges (DEXs), providing a user-friendly experience similar to centralized exchanges (CEXs). In onchain gaming, session keys simplify the user experience, freeing gamers from the complexities of gas fees and transaction signatures. Explore more special features enabled by using Starknet’s Native Account Abstraction, and learn Cairo to try it out yourself.

Session Keys: Unlocking Better UX was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Herodotus: Proving Ethereum’s State Using Storage Proofs on Starknet

Herodotus: Proving Ethereum’s State Using Storage Proofs on Starknet


  • StarkWare and Herodotus have created a way to prove Ethereum blocks all the way back to genesis
  • This is accomplished using the power of cryptographic proofs and block hashes
  • It achieves the goals of EIP-2935 — a way to access historical block hashes older than 256 blocks in a chain-native way, and unlocks new use cases for Defi and more
  • This technology is being brought to Ethereum as a public good by Herodotus and StarkWare


Being able to access historical state on Ethereum in a provable way is important — but until now all you could access in a trustless manner was the history of the past hour.

But Starknet is a vibrant, innovative ecosystem that pushes the edge of what’s possible. And now, thanks to Herodotus and StarkWare, you can retrieve — in a chain-native and provable way — all Ethereum block hashes all the way back to the genesis block.

Let’s look in detail at how Herodotus and StarkWare achieved this and what it all means. We’ll start with a background on storage proofs.

What are Storage Proofs?

Storage proofs allow us to prove that a certain state existed at some point in the past, and without having to trust any third party. With storage proofs, trust is built into the mathematics. Storage proofs can also be used to access this state across different chains.

In a recent article on storage proofs, we introduced Herodotus, the team leading the research and innovation of storage proofs. The Herodotus team has now created a way to make storage proofs even better by providing trustless proving of Ethereum all the way back to the genesis block.

Let’s look at how Herodotus achieved this and why it’s important.

Proving Ethereum’s Genesis Block On-Chain

First, we need to understand how Ethereum block headers and block hashes work.

So, What is a Block Header and a Block Hash?

A block header is the section of a block that summarizes all the information kept in that block. It includes the hash of the parent block, the block timestamp, the state root, and more.

Ethereum block header and state merkle tree (source)

There is a lot of information kept inside the block header. For this article, we’re particularly interested in the state root. Let’s look at why.

In the diagram above you can see, just below the block header, the Ethereum Account State. Every Ethereum account has an associated storage space where that account’s variables are stored (essentially, the smart contract’s state). A cryptographic commitment of the account’s storage is hashed and stored as a storage root along with the account balance, nonce, and code hash. Together, this all acts as a basic summary of this account’s state.

A Merkle Patricia Trie of all the Ethereum account states is constructed, and its hash is stored in the block header as the state root (labeled stateRoot in the diagram above). This state root contains all the information you need to prove the state of the entire Ethereum network at any particular point in time.

Finally, since every block on Ethereum (and EVM chains) contains this state root, and since every block also has an associated string called the block hash (which is the result of hashing everything inside the block header including the state root), the block hash acts as a cryptographic commitment of the entire Ethereum state at a particular time.

Historical Block Hashes on EVM

Since so much key information is kept in the block hashes, we often need to access them historically.

In Solidity, if we want to retrieve the block hash of the block that was mined two blocks ago (the backward count starts from the block in which a transaction is included), we use the following syntax:

bytes32 lastBlockHash = blockhash(block.number - 2);

Pretty simple. But there’s a catch — this block-hash method can only retrieve the block hash for the last 256 blocks. With an average of 12-second blocks on Ethereum, that’s 51.2 minutes of history on-chain.

For someone who wishes to use historical block hashes as a source of entropy (randomness), the 256 limit is generally good enough. However, if you want to use block hashes for fetching the historical state of the chain at a specific block, a 51-minute history is not nearly enough (compared to an eight-year history of the Ethereum blockchain).

This 256 limit of on-chain block hash retrieval was primarily a design choice made for state storage efficiency and to mitigate potential state growth problems.

Herodotus Gives Access to the Complete History of Block Hashes

So, how does Herodotus solve this limitation and allow us to:

  • access the complete history of block hashes on Ethereum
  • prove Ethereum’s state all the way back to the genesis block
  • and all in a trustless manner?

The key is the power of cryptographic proofs.

Let’s delve deeper by dividing the Herodotus Historical Block Hash Accumulator procedure into steps:

Step 1. Registering a recent block hash

On the Ethereum mainnet, a recent block hash is registered in a smart contract named the SharpFactsAggregator smart contract. The block hash can be retrieved using the block hash opcode (opcode value 0x40) and saved in the aforementioned smart contract as a simple string variable. The corresponding block number can also be registered for access later on.

Let’s assume that the registered block number is block 18,000,000. From Etherscan, we can see that the block hash of this block is 0x95b1…4baf3.

Step 2. Proving the block hash of the latest block

The next step is to retrieve the block header (from an archival node) for block 18,000,000, compute its block hash in an off-chain computation, and compare it to the registered block hash 0x95b1…4baf3. This calculation is also run through a prover to create a proof of this computation.

The block hash for this block is added to a Merkle Mountain Range (MMR). This is a variation of a Merkle tree such that appending new elements to the tree does not require significant computation.

Step 3. Proving the block hash of block X-1

Once we have proven that the block header retrieved from the archival node is valid, we retrieve the block header for block X-1, compute its block hash, and compare it with the parentHash value for block X. (It is available in the X’s block header that we retrieved earlier).

If the hashes match, we know that the block header for X-1 is also valid. Since this whole computation can be modeled as a function, a STARK proof of this computation can be created simultaneously. Hence, a proof of validity for the block header of block X-1 is created (see diagram below).

Step 4. Recursively proving the block hashes for previous blocks

The block hashes are computed similarly for all the previous blocks until we reach all the way back to the Genesis block — the first block on the Ethereum mainnet. These are all appended to the MMR tree, thus creating a final MMR root.

It should be noted that all of these computations are done off-chain with a simultaneous generation of proof of computation by Herodotus.

Step 5. Publishing of proof on-chain and subsequent use

Once the final MMR root is generated, this root can be published on-chain (on a Proofs Aggregation smart contract) along with the proof of computation for the millions of blocks. Since the generated STARK proofs are exponentially cheaper to verify, the cost of verifying these proofs on-chain is reasonable.

And there we have it! We’ve created a way to access Ethereum’s state all the way back to the genesis block.

These MMRs (called “historical block hash accumulators” by the Herodotus team) achieve the goals of EIP-2935 proposed by Vitalik Buterin and Tomasz Stanczak in 2020 — a way to access historical block hashes older than 256 blocks. This was a problem that had remained unsolved for over three years! And yet, Herodotus and Starknet achieved it without having to make any protocol-level changes.

Some key points to note on the process above:

  • Herodotus processes the blocks in batches of ~1350 blocks, and the proof is published on-chain for every single batch. Once the whole process is completed for the first 18,000,000 blocks on Ethereum, the MMR root for the history of the block can be updated periodically as new blocks are added to the chain’s history.
  • Once the MMR root is available on-chain, it becomes possible to prove the inclusion of every single block hash in the MMR (that’s a basic property of Merkle trees).
  • Before sending the proof onto the Ethereum mainnet, the Herodotus team’s prover uses SHARP, created by the StarkWare team. The primary benefit of the SHARP system is its ability to decrease costs and enhance the efficiency of the generated proofs.
  • The workflow described above is being duplicated for two independent MMRs — one that uses the Keccak256 hashing function and one that uses the Poseidon. On Ethereum, the Keccak256 variant will be used, while Starknet will use the Poseidon variant.
  • The MMR root for the Ethereum mainnet is also sent to Starknet using the native Starknet L1-to-L2 messaging protocol for use on Starknet. The Herodotus Block Hash Accumulator also enables Ethereum historical data access on Starknet. The Starknet L1-to-L2 messaging system can be used to relay an L1 block hash and the verified MMR root to Starknet in a secure manner. Once on Starknet, storage proofs of historical Ethereum data can be verified against these commitments.

New Opportunities with the Herodotus Block Hash Accumulators

These block hash accumulators are being brought to Ethereum by Herodotus and StarkWare as a public good. Once the final MMR roots are published on Ethereum mainnet, along with proofs of computation, any developer can utilize them for accessing a provable state of the chain for any time since inception.

Since the MMR roots for Ethereum are also going to be sent to Starknet via the native messaging protocol cross-chain, cross-chain state information can be accessed in a simple yet trustless manner. DeFi protocols could benefit from historical state proofs by utilizing the information about a specific account balance or leveraged positions of an account at any point in time. More robust random number generation using a larger history of block hashes becomes possible. Cross-chain voting becomes simplified without users having to bridge assets before they cast their votes on an L2. And much more.


In the evolving world of blockchain scalability, decentralization, and verifiability, teams on Starknet are emerging as beacons of innovation. Projects created in Starknet are becoming key elements in scaling Ethereum. As we delve into this new future, familiarizing yourself with the ecosystem will position you for what lies ahead.

Read more about projects in the Starknet ecosystem here.

Herodotus: Proving Ethereum’s State Using Storage Proofs on Starknet was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

7 Super Cool Dev Tools for Starknet Devs

The building blocks for Starknet developers

While Starknet is a Layer 2 network built over Ethereum, it is different from other Layer 2s built on the model of the Ethereum virtual machine (EVM), and so it has many of its own developer tools to support the community of developers that are building on Starknet.

While originally the stack of Starknet development tools was based mostly on Python, there is an overall trend to move from tools built on Python to tools built in Rust.

Here are 7 Dev Tools for Starknet devs:

  1. Starkli
  2. Starknet-devnet
  3. Katana
  4. Scarb
  5. Starknet Foundry
  6. Hardhat
  7. Starknet Remix Plugin


This diagram illustrates the development process, with the tools that are useful for each stage of development.


What is it?

Starkli, pronounced Stark-lie, is a fast command-line interface that replaces the legacy starknet-CLI. Starkli is a standalone interface, that is, you can use it on its own, rather than as a component of another tool. If you’re not actually developing on Starknet and just want to interact, such as by sending transactions, then a standalone CLI might be more appropriate than an interface such as Cast, which is an integrated component of the Foundry development environment.

Who maintains it?

Starknet community contributor Jonathan Lei, the co-founder and CTO of zkLend.

Why should you care?

Starkli is a Starknet CLI similar to cairo-lang but written in Rust. It’s easier to install and to navigate, and has no dependencies. The tool supports Braavos and Argent X smart wallets, and has embedded support for RPC endpoints.

Starkli includes standard CLI functionality, such as the following:

  • deploying accounts
  • interacting with contracts
  • getting Starknet data, such as information about blocks, transactions and more

Starkli also includes the following features:

  • compute class hashes from the Cairo file that defines the class
  • compute a function’s selector
  • encode messages
  • auto-completion
  • useful help commands
  • the ability to make multi-calls

Where do you get it?

For information on getting started, including installation instructions, see Starkli: The New Starknet CLI.

See also:

SDKs: A window into Starknet

A Software Development Kit (SDK) is a library that abstracts the complexities of Starknet when building transactions and interacting with the blockchain, including the following:

  • read and write API calls, using both the JSON-RPC and the Feeder gateway API
  • account creation
  • cryptography: Signature verification and signing, computing hashes used by Starknet
  • contract interactions: ABI import, constructing transactions

There are several SDKs for various languages, so you can choose the SDK according to your preferred language.

LanguageUsed byWho maintains it?Where do you get it?Starknet.jsJavaScript/


Dapps/WalletsShardlabsThe starknet.js Github repositoryStarknet.pyPythonUseful scriptsSoftware Mansion (SWM)The Github repositoryStarknet-rsRustStarkli, FoundryJonathan LeiThe starknet-rs Github repositoryStarknet-goGoChainlinkNethermindThe starknet-go Github repository

starknet-devnet, starknet-devnet-rs

What is it?

A devnet is a Starknet instance that you run as a local node, which enables much quicker development than is possible using testnet, as well as providing privacy prior to launching on testnet.

Shardlabs, originally wrote starknet-devnet in Python, but they are now actively developing a version in Rust, starknet-devnet-rs. For now, the Python-based version is more feature-rich, with the most notable feature being the ability to fork the network at a given block, so if that’s important to you, then you need to use the Python-based version. However, starknet-devnet-rs runs more quickly, and the developers are working to bring it to feature parity with the Python-based starknet-devnet.

starknet-devnet-rs is the only version that is receiving new features.

Who maintains it?


Why should you care?

starknet-devnet and starknet-devnet-rs include some accounts that are already funded with an ERC-20 token that can be used to pay fees. The ERC-20 contract that defines this token is also included.

With starknet-devnet and starknet-devnet-rs You can do the following:

  • Create mock accounts.
  • Send transactions using pre-deployed, pre-funded accounts, which are included.
  • Test tools.
  • Test RPC requests.
  • Deploy new contracts using an included Universal Deployer Contract (UDC).

What’s next?

starknet-devnet-rs is the devnet to pay attention to, as it is developed in cooperation with StarkWare, and it is the version that is being actively developed.

Where do you get it?


What is it?

Katana, developed by the Dojo team, is an extremely fast devnet designed to support local development with Dojo, which is a gaming engine for Starknet. You can use Katana as a general purpose devnet as well. Katana lets developers test applications locally using the Katana network to test the transactions being sent during the game.

  • Katana provides convenient RPC methods that you can use to change the network’s configuration as needed. For example, you can change the block time or allow zero-fee transactions.
  • Katana supports version v0.3.0 of the Starknet JSON-RPC specifications, the latest version as of June 2023. Katana lets you use native Starknet JSON calls, such as starknet_getTransactionReceipt, starknet_getStorageAt

Where do you get it?

For information on installing and using Katana, see Katana in the Dojo documentation.

Scarb: The Cairo package manager

What is it?

The official package manager for Starknet.

Who maintains it?

Software Mansion

Why should you care?

It makes life easier in the following ways:

  • When installing Cairo packages, it handles adding, updating, and removing dependencies.
  • You can use it to compile smart contracts.
  • When creating your own Cairo package, it takes care of patching any libraries you need from Github, and lets you know if there’s a version mismatch. You can then use it to build and test your project, using the Cairo test runner. Building is quite fast.
  • It includes the Cairo compiler, built-in, so unless you’re actually a compiler developer, you don’t need to set up any extra tooling.
  • It includes a bundled binary of the Cairo language server, which you can use
  • It works well with other tools in the Cairo ecosystem, such as Foundry and Dojo.

What’s next?

Developers are currently working on improving the way Scarb handles the management of versions, projects, and workspaces.

Where do you get it?

The Scarb site

Starknet Foundry

What is it?

Starknet Foundry is a toolchain for developing Starknet smart contracts. It helps with writing, deploying, and testing your smart contracts.

Who maintains it?

Software Mansion

Why should you care?

Starknet Foundry includes the following features:

  • Forge, a fast testing framework. Forge achieves performance comparable to the Cairo Test Runner with a better user experience. You can test standalone functions in your smart contracts and embed complex deployment flows.
  • Support for prints in contracts. According to the documentation, the debugging features will follow the addition of support in the Starknet compiler.
  • The online Foundry Book, with lots of helpful information and guidance in writing and running tests and interacting with Starknet.
  • Integrated compiling and dependency management, using Scarb.
  • Cast, which the documentation refers to by its command name, `sncast`. Cast is an integrated CLI specifically designed for performing Starknet RPC calls, sending transactions and getting Starknet chain data. You can use Cast to declare, deploy, and interact with contracts using the Starknet JSON-RPC.

What’s next?

Many new features are coming soon, including fuzz testing, L1L2 messaging, and code coverage.

The Starknet Foundry Github repo has a roadmap showing new and in-development features, although it’s not clear if the checkmarks indicate features that are already implemented, or in active development.

Where do you get it?

The Starknet Foundry Github repo

Hardhat (with a plugin)

What is it?

A tool primarily for testing Cairo code. You can also deploy contracts using scripts in JavaScript.

Who maintains it?


Why should you care?

Hardhat is a popular JavaScript development environment for Ethereum, and if you are already familiar with it and want to use it on Starknet, then this plugin can come in handy. You can run Starknet commands as tasks in Hardhat, such as compiling a Cairo contract.

Hardhat is integrated with a local devnet, so you only need to worry about writing your tests, in JavaScript, of course.

What’s next?

Upcoming features include:

  • improved integration with Starknet.js, for a better developer experience
  • improved support for the latest Cairo features

Where do you get it?

Get Hardhat at the Hardhat site.

Get the Starknet plugin at the Starknet Hardhat plugin Github repo.

See examples of how to use the plugin at the Starknet Hardhat example scripts Github repo.

The Starknet Remix plugin

What is it?

Remix is a browser-based integrated development environment (IDE) for Ethereum that you can use for learning, experimenting and finding vulnerabilities in smart contracts, without installing anything. The Starknet Remix plugin lets you use Remix for testing Starknet smart contracts, so you can focus on learning Cairo and Starknet without the distraction of setting up a toolchain.

Who maintains it?


Why should you care?

Remix and the Starknet Remix plugin include the following features:

  • Integrated compiling.
  • You can deploy contracts on any devnet, including the plugin’s own integrated devnet.
  • You can also deploy on testnet or Mainnet.
  • You can call functions of contracts that you have already deployed, to facilitate testing and interaction.
  • Seamless integration with Scarb.
  • Integration with block explorers such as Voyager, so you can easily check the execution of your transactions, in real time.
  • The Starknet Remix Plugin is integrated with Starknet By Example, a rich repository of practical learning content.

For more information on the Starknet Remix plugin, see Unlocking Onboarding to Starknet: An Overview of the Starknet Remix Plugin.

What’s next?

  • Support for testing Starknet contracts directly within the browser.
  • An integrated code editor is planned for a future release.

Where do you get it?

To get started with Remix, see the Remix Project site.

To get started with the Starknet Remix plugin, see the Starknet Remix plugin’s Github repo.

Looking for more dev tools, libraries and tutorials? Go to Starknet’s Developers Hub

7 Super Cool Dev Tools for Starknet Devs was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Starknet Decentralization: A Roadmap in Broad Strokes


  • StarkWare is progressing towards decentralization in two threads: planning and implementation.
  • A clear roadmap lies ahead for the steps required to ensure the transition of the Starknet protocol to a decentralized proof-of-stake protocol.


Starknet enjoys the security and decentralization provided by Ethereum by sending STARK proofs of its state transitions for verification on the Ethereum blockchain. This flow places substantial limits on the power of otherwise centralized entities building and maintaining Starknet, such as StarkWare and the Starknet Foundation: no centralized entity on the network can forge transaction messages that would misstate or otherwise fraudulently manipulate user data or assets.

This is the first and most critical step in ensuring that Starknet is trust-minimized, and that users of Starknet are not reliant on the honesty of any centralized party when they use the network. However, more must be done to ensure full trust-minimization and decentralization, so that even if entities like the Foundation or StarkWare were to disappear, the network would continue to function as designed and without interruption. This post outlines a tentative roadmap for those next steps.

How We Got Here

Just under a year ago, we began documenting our decentralization research process in a long series of blog posts which culminated in a simple concrete proposal.

In short, our goal is to transition operation of the Sequencer+Prover to a decentralized proof-of-stake protocol, whereby anyone can participate in sequencing and such that no party is essential to the continued liveliness of the network. To this end, two necessary threads open:

  1. Implementation of the various components required to run the decentralized protocol,
  2. A transitional process to gradually decentralize operations to Starknet stakers.

In this post we will focus on the latter.

The Transition Process

In a nutshell, the transition process itself has four main threads:

  1. Transitioning to a decentralized network architecture while Sequencer operation remains under centralized operation
  2. Ensuring the availability of a fully open-sourced software stack
  3. Developing increasingly broad testing and integration networks
  4. Fostering Staker onboarding in advance of the final transition of Sequencer operation to proof-of-stake participants.

The numbering represents some obvious sequential dependencies, but a lot of concurrent work is possible. Below we slightly expand with a paragraph for each thread.

Decentralized Network Architecture

The Starknet network will move to a more decentralized model:

  • At present, full nodes do not communicate with each other, instead each node relies on periodic queries to the Sequencer through a centralized feeder gateway.
  • In a less centralized model, full nodes will be part of a peer-to-peer network that does not require a connection between each of them and the Sequencer.

This change goes beyond the connectivity of the network. Let us illustrate this with two examples.

First, the Sequencer will sign its blocks to alleviate some trust assumptions and prepare for a vote-based BFT protocol with many voters. Second, data propagation will take on a more distributed flavor, with nodes helping each other to sync on the state and complete their local view.

Working towards a Fully Open-Sourced Software Stack

Open-Source Software Stack: Ensuring availability of an open-source software stack is critical to enable everyone to participate in the various aspects of the protocol and the network. As more components are implemented, both by StarkWare and by other contributors, they will be released for everyone to test, criticize, and get comfortable with. Some notable examples (of already open sourced parts of the stack) are full nodes (Pathfinder, Juno, Deoxys), Provers (Stone, Sandstorm), Sequencers (Blockifier, Madara), and Block Explorers (Starkscan, Voyager, ViewBlock, Stark Compass)

Testing & Integration Networks: Increasingly broad testing and integration networks are necessary for a maximally smooth transition process. For each new component there will likely be a progression from an internal testnet, to a slightly broader permissioned testnet with external participants, and eventually to a public testnet, integration, and mainnet. There are some choices to be made later, e.g between sequential and concurrent approaches for introducing testing new components, but that’s for another day.

Staker onboarding: We must give time for the L1 staking contract to accumulate sufficient staked tokens to secure the decentralized protocol with real economic weight. This is to avoid a scenario where a small number of participants with little actual skin in the game maliciously attempt to take control of Starknet.


In summary, we have given here a rough overview of the tentative roadmap to decentralizing Starknet. As with any engineering plan, certainly one of this complexity, it is likely to evolve and change over time as our community of contributing builders develops better insights and understanding.

As always, feedback, suggestions, and criticism are welcome. Feel free to reach out on the Starknet community forum!

Trailblazing the Way to Building New Worlds

Starknet is taking the emerging Autonomous Worlds space by storm


  • Starknet is a frontier in the evolving space of onchain gaming and autonomous worlds, channeling the power of Dojo engine and Madara to enable onchain gaming.
  • Using Starknet’s high throughput and Cairo, a world of possibilities is emerging for devs and users who want to utilize asset ownership and limitless interoperability.
  • Multiple teams are utilizing Starknet’s capabilities to bypass EVM limitations and explore new horizons in gaming.


Autonomous worlds are the convergence of tech, gaming, decentralization, creativity, and innovation. These worlds operate independently and without a central authority, which allows users to engage and explore, create content, and interact, all without permission from anyone and without any concern of censorship.

Starknet has positioned itself as the natural choice for those who spearhead the creation of these worlds. Worlds that need an L1 to ensure they can exist forever, but they also need a robust L2 to cater for their complexity. The combination of Ethereum, as the basis layer, and Starknet, as the scaling and creativity enabling layer, allows these worlds to emerge.

Let’s look at this new frontier of autonomous worlds and onchain gaming and the features that Starknet offers, which makes it so suited for this vision.

What Exactly are Autonomous Worlds?

As mentioned above, autonomous worlds are worlds that operate independently and without a central authority. Some of the key features of an autonomous world include:

  • Constant Accessibility: They are always available.
  • Multiplayer Interactivity: Allowing multiple players to concurrently explore and have interactive experiences.
  • Immunity to Shutdown: Autonomous worlds are censorship-proof, which means there is no central authority that can be told to shut the game down.
  • Unrestricted User Engagement: They allow users to independently explore, create, and interact (independently, or as a group) with no central authority.

Players, individually and as a whole, create, control, and play in this world, all on their own. It’s a new frontier in gaming with untapped capabilities and new use cases. It challenges the current conventions in gaming and redefines what is possible. The potential is huge.

But to exist, autonomous worlds must be onchain, on a network that can handle the requirements outlined above. At the same time, they must be highly performant and highly cost-efficient. That’s where Starknet comes in.

The Origins of Onchain Gaming on Starknet

In November 2021, StarkWare released Starknet Alpha, and prior to that, Cairo. The combination of a Validity Rollup that provides Ethereum-grade security, and a new non-EVM compatible language, was a challenge and a puzzle that opened a new world of opportunities. The earliest adopters of Cairo (developers like Perama and Guiltygyoza) started delving deeper into the language, creating guides and experimenting with physics and neural networks. This level of innovation in the Ethereum ecosystem was impressive.

Eventually, the first game on Starknet emerged: a proposal to recreate the classic game “Drug Wars” was submitted, a grant was given, and a fully onchain game engine began to take shape.

Teams such as Realms, Influence, and Briq were among the earliest projects to build on Starknet. They came from the Solidity world, where complex games were nearly impossible to build. Others, such as Topology, came directly as they had heard of the limitations of Solidity. For all of them, though, their visions were finally possible with Starknet. Cairo, as a general computation programming language, lifted barriers that were created by the EVM. Teams got a taste of the flexibility it offered builders.

Escaping the EVM Limit: Online and Autonomous Games on Starknet

Currently, after years of research and iteration, Starknet is one of the first L2s that can sustainably host onchain, high-TPS games. It is the platform where game developers can finally build their complex visions of worlds that operate on a permissionless basis and in a decentralized manner. Among active L2s, Starknet has attracted the largest number of game developers and teams.

Let’s look at two key technologies that make Starknet the premier platform for building and playing onchain games and autonomous worlds — Dojo gaming engine and the Madara sequencer.

Dojo Gaming Engine

In a recent article, we covered in detail the Dojo Gaming Engine — the world’s first provable onchain game engine. Dojo enables Starknet’s gaming builders to provide transparency, provability, and scalability for their games.

The Dojo gaming engine is a software framework for Starknet game developers that helps them create fast, provable games onchain. It provides developers with everything they need to get started creating games and autonomous worlds (such as physics, graphics, and game mechanics).

Dojo is the brainchild of two early innovators in Starknet-based game development — the Cartridge and the Realms teams. Their collaboration was inspired by the insights they gained over a one-year journey starting in early 2021, during which they explored the most efficient ways to build games on Starknet.

Dojo consists of the Entity Component System (ECS) framework, which is a system for blockchain-based game development that promotes modularity, efficiency, and flexibility, and three additional useful tools for game developers: Sozo, Torii, and Katana.

Sozo — Sozo is a migration planner that handles the complex task of deploying autonomous worlds onchain. With a simple `sozo migrate` command, deploying an instance of the game world onchain is possible.

Sozo also has the ability for any participant in the ecosystem to propose new components to the onchain gaming universe by using the simple CLI tool. This is a key philosophy of autonomous games: worlds can outlive the game’s creators, and additional contributors can extend the ecosystem with their own assets, levels, characters, and more.

Katana — Katana is a sequencer built for local game development. Running this sequencer on Starknet enables immense jumps in productivity. Katana enables RPC methods offered by Starknet on mainnet and allows the developer to test with various parameters such as the block time, base fee per transaction, etc.

Running the node (once configured) is as easy as running the `katana` command on the CLI

Torii — Torii is an indexing layer built on top of the Dojo engine that connects the onchain infrastructure with game development clients such as Unity or Unreal Engine. Based on the developed game’s source, Torii can be used to easily start indexing game-specific events and expose a GraphQL API for queries. Simply running `torii` creates a GraphQL API running on http://localhost:8080, ready to be queried.

Madara Sequencer

The Madara sequencer is a high-performance Starknet sequencer that can create highly customizable and efficient appchains, especially suited for gaming. Madara is built using the proven Substrate framework used by the Polkadot ecosystem.

Appchains are a private instance of Starknet that allows developers to control virtually all parameters configured in a network: sequencing, data availability, settlement layer, governance, and more.

Why is this useful? For example, if a game wants to prioritize the speed of player transactions, they could choose to implement a form of First-Come-First-Served sequencing. But if instead, they want to incentivize users to bid higher for quicker block inclusion, Priority Gas Auction (PGA) sequencing could be implemented with a more profit-driven perspective.

With many other possible parameters (such as block times, frequency of settlement on L2, or utilization of non-native data availability solutions), the possibility to launch their games on a Starknet appchain provides devs with choices and power.

Future Features: Offchain Provable Games

Not every action that the player takes must be onchain. For some games, where the user’s actions should not be public before the state of the game changes, an offchain proof of the user’s action could be generated on the client, with only the proof stating the action took place being submitted onchain. Beyond multiplayer games, this infrastructure holds promise for auctions and voting-system applications where you might want to obscure the user’s input data.

Client-side proving also unlocks the possibility for models where gamers try out a hybrid approach: proofs are published, but only whenever something significant happens in-game (e.g., a level is passed or the character finds a rare asset).

Autonomous Worlds in Action — Shoshin

In a previous article, we looked at some of the largest gaming projects built on Starknet — from space colonization strategy games to ‘immutable arcade machines’ enabled by ZK circuits. We reviewed games that can be shaped and continue to evolve with the guidance of their player, even if their creators will not operate them.

One additional example is Shoshin — which has implemented a novel way of onchain gaming where the user programs their character and the actions they take. Once this programmed logic is in place, players can battle with other players’ characters.

All in-game mechanics are executed within the Cairo virtual machine. Shoshin even had a recent in-person tournament in Palo Alto for pioneer gamers. To try out the game, log in to, and show off your fighting skills by programming a character no one can beat!

episode from Shoshin of programming character action logic


With onchain gaming and autonomous worlds, Starknet is not just refining the present state of gaming; It is shaping the future of how games are played, assets are owned, and communities are built.

The likes of eth_worm, Guiltygyoza, and others, are trailblazing the field of onchain gaming and technical innovation. Teams such as Realms, Topology, Influence, Briq, Cartridge, and Madara are building on Starknet, escaping EVM limits.

With these collaborators and many others pushing boundaries, Starknet is poised to lead the way into this new landscape of autonomous worlds.

Want to play a Starknet-based onchain game? Check out Shoshin, an asynchronous 2-dimensional fighting game from Topology.

Trailblazing the Way to Building New Worlds was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Safe and Sound — A Deep Dive into STARK Security

Safe and Sound — A Deep Dive into STARK Security

Explore the Full Security Analysis of STARKs


  • Non-interactive STARKs start as Interactive Oracle Proofs (IOPs) which are compiled to non-interactive ones in the random oracle model.
  • This post explains the recent update to the ethSTARK documentation, which gives a full and concrete analysis of the security of the ethSTARK protocol in the random oracle model.

STARK Security Explained

A STARK proof system (Scalable Transparent Argument of Knowledge) is a powerful tool for computational integrity: it allows verifying the correctness of computations performed on public data in a trustless manner. In this blog post, we delve into the security that is provided by STARK proofs, defining it and exploring techniques to prove scheme security.

(Read Section 6 in the ethSTARK documentation (version 1.2) for full details, and the important and comprehensive independent work of Block et al. on the topic.)

What are we trying to achieve with our security analysis? We would like to prevent a “successful attack” on the STARK system, which is given by a false statement and a STARK proof accepted by the STARK verifier for this (false) statement. Since false statements are dangerous and they can come in all sizes and shapes, we want to be secure against all false statements. Any false statement, even as trivial as 1+1=3, combined with a STARK proof accepted by a STARK verifier for this statement, is considered a successful attack on the system. (Those with a cryptographic background may be interested to know that STARKs also satisfy stronger security notions such as knowledge soundness but for simplicity this post focuses on the simpler case of soundness.)

How do we formally define the security of a STARK system? We do so by analyzing the “soundness error” which roughly measures the expected “cost” that an attacker would need to spend in order to construct a successful attack (i.e., find a STARK proof for a false statement that nevertheless is accepted by the STARK verifier). Mathematically speaking, the soundness error is a function (t) that gets as input a time parameter “t“, representing the amount of computation time an attacker is willing to spend to mount the attack, and outputs the success probability of the attacker in succeeding with the attack (finding a convincing proof of a false statement). As the “cost” t that the attacker is willing to spend grows larger, his success probability increases.

Thus far we have defined the security of STARKs as a function (t) which is not the way you naturally discuss security, say, on crypto Twitter. There, you probably heard statements of the form “The scheme has 96 bits of security”. How does such a statement translate to our security definition? There is no one answer to this, as people have slightly different interpretations of “x-bits of security”:

  • A very strict translation would mean that for any t between 1 and 296, the soundness error is (t) 2–96 . This means that any attacker running time at most 296 has a tiny probability of success, smaller than 2–96, which is smaller than one in a billion times a billion times a billion.
  • A more relaxed, and perhaps more common, translation is that 96-bits of security means that for any t, it holds that t/(t) 296. This means that the success probability is (inverse) linear to the running time. For example, if an attacker has running time 286, its success probability is at most 210.

In this blog post we will relate to the second option.

From IOPs to STARKs with 96-Bit Security

So how do we prove that a scheme has 96 bits of security? To answer that, we need to understand the high-level structure of how STARKs are constructed. A STARK consists of three main ingredients: an IOP (interactive oracle proof), a Merkle tree, and a Fiat-Shamir hash; the main component we will focus on is the IOP. Once these components are specified, one can compile them to yield a STARK. We will elaborate on these, what they are, and how to assemble them together.

The first component we’ll review is the IOP: An IOP is similar to a standard interactive proof, where a prover and verifier interact for multiple rounds (we limit ourselves to public-coin protocols, where the verifier only sends random challenges to the prover). In an IOP, the verifier does not read the prover messages entirely but instead samples a small number of bits from each prover message. This is what allows the succinctness of the later compiled STARK.

So we have an IOP, how do you build a STARK from it? The prover messages might be long (actually, they are longer than the computation itself). To compress the messages, we use Merkle trees. A Merkle tree is a binary hash tree where each leaf node represents a query or an answer in the IOP. The root of the tree is a commitment to the entire message. When the verifier wants to read a specific location in a message, the prover provides the value at the location and an authentication path. The verifier can then use the path to verify that the value is correct. The IOP verifier reads only a small number of locations from the prover messages. Thus, the use of a Merkle tree results in a succinct protocol (one with small communication).

Compressing Rounds

One may opt for interactive STARKs, meaning but often it is convenient to make them non-interactive to simplify the process of generating them, so that the prover need not wait for external messages when constructing one. Indeed, this is the way currently all STARK systems are deployed, and this is the way the ethSTARK protocol is constructed. Non-interactive STARKs are also a special case of transparent SNARKs (transparency means that no trusted setup is needed to instantiate them; this is also known as an “Arthur Merlin protocol” or a “public coin IOP”). To this end, a final step is to apply Fiat-Shamir to compress the rounds to a single message, which we’ll call the STARK Proof. The Fiat-Shamir transformation converts an interactive protocol into a non-interactive one. The prover simulates the interactive protocol while “talking to a hash function”. To derive the random challenge for round i, the prover hashes the partial transcript up to round i, and interprets the output as the next challenge.

This ensures that the prover cannot change their responses after the challenge has been generated. However, the cheating prover has some new strategy avenues that it did not have with the interactive IOP. The prover can regenerate the verifier challenge by modifying the last prover message, which would give a new transcript, and thus a new challenge as well. As it turns out, the standard soundness notion of IOPs does not suffice to prove the security of the Fiat-Shamir transformation.

For example, consider an IOP with 96 rounds with the following “hack” to the verifier: if the first bit of the randomness of the verifier is 0 in each of the 96 rounds then the verifier accepts (without looking at the proof whatsoever). One can see that adding this hack to the verifier only adds a term of 2–96 to the soundness error of the IOP. However, after the Fiat-Shamir transformation, an attacker can easily modify the prover messages to ensure that each hash begins with a zero, essentially breaking the system within a very short time. Rest assured, this scary scenario is merely a theoretical example, not one that applies to deployed STARKs. So, let’s see why our STARKs are secure after all? In a nutshell, we’ll show that an attacker running at most t steps will succeed in attacking with probability at most (t) t 2–96. Details follow.

IOPs and Round-by-Round Soundness

A STARK can only be as secure as its underlying IOP. But what does it mean for an IOP to have 96-bits of security? The standard definition would say that the IOP has soundness error 2–96: meaning that the probability of any attacker (regardless of running time) fooling the verifier is at most 2–96. However, as we discussed, IOP soundness is only one component out of three, and this does not suffice to get 96-bits of security for the STARK compiled from all three steps. Instead, security of the compiled STARK is proven assuming the STARK has 96-bits of round-by-round soundness error (sometimes a similar definition called state-restoration soundness is used).

Intuitively, the round-by-round soundness says that every round has 96-bits of security and not just the overall protocol. In more detail, round-by-round says that there exists a predicate that gets a partial transcript of the protocol and tells us if this transcript is “fooling”: The empty transcript is not “fooling”, a full transcript is “fooling” if and only if the verifier accepts it. Finally, for any partial transcript that is not one that “fools” the verifier, the probability that in the next round the transcript will become “fooling” is at most 2–96. If such a predicate exists with these properties, we say that the protocol has 96-bits of round-by-round soundness (the predicate is not required to be efficiently computable).

In many cases, only the soundness of an IOP is analyzed and not its round-by-round soundness. Admittedly, it is hard to think of examples where an IOP has standard soundness but not round-by-round soundness (except for contrived examples). However, the differences between the two might come up when deriving concrete security bounds where each bit matters. Thus, to derive tight and concrete bounds, one must give a tight analysis of the round-by-round soundness of the IOP. This is precisely what we do to the FRI protocol and then ethSTARK IOP that underlies the IOP of our STARKs. The analysis itself is far from trivial and beyond the scope of this post. Using the new analysis, we can set precise parameters for our proofs.

The round-by-round soundness does give us the desired guarantee. The prover can regenerate the challenge many times, but we know that for any round, the probability of generating a “fooling” transcript is 2–96. Thus, if the prover has time t, which is measured as the number of hash invocations, then it can try at most t times to get a fooling transcript, which limits its success probability to (t) t 2–96.

Adding All the Error Terms

Finally, for all of this to hold, we need to ensure that the prover cannot tamper with the Merkle tree. One can show that as long as the prover finds no collision in the hash function, he cannot cheat in the Merkle tree. The probability of an attacker finding a collision using t invocations (to a random hash function) is at most t2/2, where is the output length of the hash function (this is due to the “birthday paradox”). This is why we need to set the hash function to have a length that is double the desired security. Thus, if we have a hash function with output length 192 and an IOP with round-by-round soundness of 96-bits, we get a compiled STARK with soundness error (t)=t2–96 + t2 2–192. In particular, such a scheme has 95 bits of security since t/(t) = t/(t 2–96+t2 2–192) 1/(2–96+1/2–96) = 295.


In conclusion, STARKs provide a powerful method for verifying the correctness of computations performed on public data in a trustless manner. The security of STARKs is typically measured in terms of the “soundness error”, which represents the probability of an attacker successfully providing a false statement and convincing the verifier with a proof. To achieve a desired level of security, such as 96 bits, the underlying IOP must satisfy round-by-round soundness, ensuring that every round maintains a high level of security. We analyzed the round-by-round soundness of the IOP underlying our SATRKs which allowed us to derive concrete security bounds.

Safe and Sound — A Deep Dive into STARK Security was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

​​The What’s What of the Cairo World

Deciphering Cairo VM, CASM, Cairo Zero, Cairo, and Sierra.


In order to unlock secure and decentralized scaling for Ethereum, Validity Rollups make the verification of batches of transactions vastly more efficient than their naive re-execution. Specialized nodes (called Sequencers) on Layer 2 (L2) bundle transactions into new L2 blocks, while Ethereum mainnet nodes confirm these transactions with minimal effort.

Starknet is a Validity Rollup that leverages the Cairo VM, purposefully designed to optimize the efficiency of Validity proofs. Starknet utilizes STARKs (Scalable, Transparent ARgument of Knowledge) as its proof system, enabling the generation of succinct proofs for complex computations, thus greatly reducing the complexity of on-chain verification processes.

In this blog post, we’ll dive into the different components that make Starknet the most performant L2 by TPS — Cairo VM, CASM, Cairo Zero, Cairo, and Sierra.

Cairo VM

Creating Validity Proofs for general computational programs requires a deep grasp of the complex mathematical principles that underlie STARKs. For every computation, it’s crucial to construct an Algebraic Intermediate Representation (AIR), which comprises a set of polynomial constraints that accurately represent the given computation. Initially coined as “CPU AIR,” Cairo is a virtual CPU and a singular AIR, capable of describing any computation with the same “generic” AIR. The Cairo VM is intentionally tailored for Validity Proof systems and is not constrained by the limitations imposed by the EVM (Ethereum virtual machine).


CASM (Cairo Assembly) is the machine code that the Cairo VM runs. CASM is translated to polynomial constraints that enforce the correct execution of a program. CASM is a key component in the ecosystem because regardless of what the user sends to the Starknet sequencer, what’s proven is the correct CASM execution.

Cairo Zero, A Breakthrough

Cairo Zero, released in 2020, introduced the world’s first Turing-complete language for creating STARK-provable programs, revolutionizing verifiable computation. Cairo Zero programs were compiled locally into CASM and then sent to the Starknet sequencer. Although groundbreaking, Cairo Zero had a steep learning curve owing to its low-level nature and did not entirely abstract away the underlying cryptographic primitives required to prove the program execution.

Cairo: Cairo Zero, but Better

Cairo (now v2.1.1) overcomes the limitations of Cairo Zero, promising safer, more efficient contract writing. Cairo greatly improves the developer experience with a Rust-like syntax and by abstracting away the limitations that were present in Cairo Zero (e.g. write once memory).
Cairo brings modern programming concepts from the rust world, such as trait/impls, generics, enum matching, without compromising the efficiency of proof generation that is brought about by the underlying CairoVM.


With Cairo, came Sierra. Sierra serves as an intermediate representation between Cairo and CASM. This additional layer ensures that user code remains provable in all cases. Sierra compiles down to “safe CASM,” a subset of CASM that is guaranteed to be provable for all inputs. This intermediate layer between user code and proven code is crucial in protecting the Starknet sequencer from DOS in the form of unprovable transactions.

A perhaps surprising benefit of Sierra is, that thanks to this simple intermediate representation, Starknet sequencers may eventually run on native hardware directly instead of going through the CairoVM. To illustrate the power of sequencers executing Sierra, consider the following example: one can use type information from Sierra to work with native types (e.g. u32) instead of working in the prime field of the CairoVM.


Cairo builds upon the foundation laid by CairoVM to revolutionize verifiable computation. With a Rust-like syntax and modern programming languages features, Cairo greatly enhances the developer experience, simplifying contract writing and reducing the chance for bugs. Cairo emerges as a powerful tool driving decentralized innovation.

​​The What’s What of the Cairo World was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Open-Sourcing the Battle-Tested Stone Prover

StarkWare is Open-Sourcing the STARK Prover, now named Stone, under Apache 2.0.

A code review session will be done on August 31st during Starknet Summit. On this date, the code of the Stone prover will be available for the community


  • As announced in February 2023, we are about to open-source StarkWare’s STARK Prover, now named Stone (STARK one), under Apache 2.0 license.
  • Open-sourcing the prover is a major step forward in decentralizing Starknet. It will boost collaboration and innovation, and enable devs to observe, optimize and use the prover’s code, preferably for the good of public Starknet.
  • This step is consistent with previous steps to open-source license for the Starknet Stack. With the fastest-growing developer community, Starknet has the most decentralized Rollup Stack, including multiple key infrastructure components, such as Cairo, several Full Node implementations, Starknet’s new Sequencer, and other open-sourced features built by independent teams.
  • The Stone Prover is a powerful engine, and teams are encouraged to add customizations and wrappings around it in order to build the proving system they need and require.

Big News

We are excited! As announced earlier this year, and as planned from the early stages of Starknet, we are open-sourcing the STARK Prover code, now named Stone. The Prover’s code base will be available under the Apache 2.0 license. An intro session to the code will take place during the Starknet Summit on August 31st, which will be the date on which the code will be available.

This is a major step forward in the decentralization of StarkWare’s technology that enables the community to build upon and contribute to the Prover’s development independently.

For devs, this means that the battle-tested engine at the center of StarkWare’s scaling achievements is available for all to use to prove Cairo programs. We provide you with a powerful STARK-prover, and you can use it to help build upon and contribute to the development of Starknet’s ecosystem.

Open-Sourcing the Stone STARK Prover

The STARK Prover is a vital component within Starknet’s tech stack. It’s responsible for compressing transactions and generating cryptographic proofs, and plays a key role in helping to scale Ethereum.

This Prover has been in production since June 2020, playing a critical role in proving transactions from decentralized applications powered by StarkEx (such as Immutable X, Sorare, dYdX, and more) and Starknet. The code has been continuously optimized, and we are sharing its latest updated version (which was released in March 2023).

Since launch, STARK-tech scaling solutions built with this Prover at their basis (including StarkEx and Starknet) have compressed and proved $1T in cumulative transaction volume, 500M transactions, and more than 100M NFTs mintings. Of course, further innovations and optimizations can be made, whether by StarkWare, or by devs who will choose to take the code and use it for their own initiatives.

An open-source Prover allows more eyes to review the code and offer optimizations, improve its quality, help detect bugs, and provide transparency.

Currently, StarkWare already has open-sourced Cairo, Papyrus Full Node, and all Starknet versions. The new Starknet Sequencer that is being built, will also be open-sourced. These projects are joined by several open-sourced projects in the Starknet ecosystem.

What is Open-Sourced, and How Can Devs Use it?

The open-sourced code includes the Stone STARK Prover in C++ (under Apache 2.0 license). In addition, a C++ STARK Verifier will also be available.

The open-source Stone Prover will allow innovative initiatives that will be able to utilize it as the underlying proving engine of their proving systems. Devs will be able to use it as follows:

  1. Write a Cairo0 program
  2. Use the Cairo tools to take the Cairo0 program and compile it to CASM
  3. Run the CASM code with cairo_run and receive a Cairo trace for that run
  4. Use the Stone STARK Prover to prove the Cairo trace
  5. Receive a STARK Proof
  6. Use the C++ Verifier in order to ensure that the proof is valid

The Stone Prover is suitable for proving Cairo programs. Additional wrappings and customizations can be built on top of it in order to utilize it for several and various proving systems and needs. Devs can take this trailblazing, battle-tested engine and build their own custom-made proving service. For example, StarkWare built the SHARP system with this Prover as its basis.


With the release of the Stone Prover codebase under the Apache 2.0 license, StarkWare marks a pivotal moment in developing and releasing open tools for securely scaling Ethereum. StarkWare believes open-sourcing the Starknet tech stack means more collaboration, better quality, improved security, innovation, and independence. All of these values can help Starknet and Ethereum reach their full potential.

In the future, everything devs need to operate and run the Starknet Stack is planned to be open-sourced, as is appropriate for a decentralized, permissionless Layer 2 network.

Open-Sourcing the Battle-Tested Stone Prover was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Getting Started Using Starknet: Setting Up a Starknet Wallet

A gentle hand-holding guide for your first steps using Starknet


When I tried to get started using Starknet, I found it difficult to know exactly what to do. While I’ve heard a lot about the wonders of Starknet and how it can save me money in fees while providing security and trustlessness, I’m a blockchain newbie. In my quest to onboard to Starknet and try out some of the applications in the ecosystem, I found a lot of helpful information, but I also didn’t find a lot of information.

So this post provides the information that I couldn’t find and provides links to information that someone else made the effort to provide elsewhere.

What can you do on Starknet? You can swap tokens, invest using financial dApps, play games and build your NFT collection. For more information, visit the dApps page on


Although this is a guide for newbies, you will gain more out of using Starknet and this tutorial, if you understand Ethereum basics. You should understand the terms Layer 1 (L1) and Layer 2 (L2), and on-chain and off-chain, and what they mean in the context of Ethereum.

You should also understand what wallets are, the difference between hot and cold wallets, EOAs and contract accounts. You can find this information on the Ethereum website.

High-Level Steps

Each of these steps is detailed either in other sections of this blog post, or in external documentation on another site.

  1. Set up an Ethereum wallet.
    There are many. For a list, see Ethereum wallets, and for a helpful guide, see How to “create” an Ethereum account. Both are on the Ethereum site. You can use a search engine like Google to help you decide on the right one for you. I found that Best Ethereum Wallets of 2023 helped me, and to get started, I decided to use MetaMask. For information on setting up a wallet, see the documentation for the wallet you choose.
  2. Deposit some ETH to your Ethereum wallet. You can use your credit card or your bank account with an exchange such as Binance or Coinbase.
  3. Set up a Starknet wallet, which includes funding the wallet and deploying your account on Starknet. For more information, see Setting up a Starknet wallet below.

NOTE: You can also add funds directly to your Starknet wallet from a credit card or bank by using an on-ramp service, such as Banxa or Ramp.

After you complete these procedures, you’ll be ready to start actually doing something.

For example, this tutorial walks you through swapping ETH for another cryptocurrency using Jediswap. There are lots of other things you can do, such as providing liquidity to a pool, buying NFTs, minting your own NFTs, and playing games.

Let’s Get Started — Setting Up a Starknet Wallet

Once you have an Ethereum wallet with some ETH, you can install and set up a Starknet wallet.

See the up-to-date list of available Starknet wallets on the Starknet site. For more information on a specific wallet, including installation instructions, see that wallet’s site. Whichever one you choose, make sure that you install it as a browser extension.

In this blog post I used wallets by Braavos and Argent.

After you finish installing, you need to set up the wallet by adding funds to it. You can use StarkGate, a bridge that transfers funds between your Etherum wallet on L1 and your Starknet wallet on L2. You can go to StarkGate from a link in the wallet, or go to


  1. Click Connect Wallets, and then Get started.
    StarkGate prompts you to select an Ethereum wallet.

2. Click the wallet that you want to use. In this example, click MetaMask, as it is already installed.

3. When your wallet prompts you to connect, approve the connection.
StarkGate completes the connection. Your Ethereum wallet is now connected.

4. When StarkGate prompts you to connect a Starknet wallet, click Connect Starknet Wallet.

5. When the wallets that you have connected to your browser appear, click the wallet that you want to use.

6. When the wallet prompts you to, approve the connection. For example, this is what appeared when I clicked ArgentX:

and this what appeared when I clicked Braavos:

StarkGate completes the connection.
Your Starknet wallet is now connected, and it prompts you to add funds. In order to deploy your account on Starknet, you need to add funds.
NOTE: Deploying an account incurs a small gas fee on Ethereum. But don’t worry, you only have to deploy the account once.

7. Confirm that you’re on the Deposit tab.

8. StarkGate lets you select from several different types of tokens. This example uses the default token, ETH. Check that the available balance in your Ethereum wallet is enough to transfer funds and pay for the gas required to transfer the funds.

9. Enter the amount of ETH you want to transfer.
Your Ethereum wallet prompts you to confirm the transfer. Your wallet might also show you the estimated transaction cost. For example, MetaMask shows approximately how much gas is required to execute the transfer, as well as the cost of the required gas in ETH and USD.

10. Confirm the transfer in your Ethereum wallet.

11. StarkGate confirms the transaction and displays its status, including links to Etherscan and StarkScan, so you can view the transaction on both Ethereum and Starknet:

After a short time, typically a few minutes, StarkGate should show updated balances in your Ethereum and Starknet wallets:

Swapping ETH for Another Token Using JediSwap

JediSwap is a community-driven Automated Market Maker (AMM) on Starknet that enables you to swap one type of token for another. The JediSwap documentation provides information on swapping and on adding liquidity. This procedure demonstrates swapping ETH for WBTC.


  1. Go to JediSwap at

2. Connect your wallet by clicking Connect Wallet and then selecting your Starknet wallet.

3. When your wallet prompts you to approve the connection, click Approve.
Once JediSwap connects to your wallet, it shows your balance in each token that it supports. For example, my wallet has about 0.05 ETH.

4. Select the tokens that you want to swap in Swap From and Swap To (est.), and click Swap. I swapped 0.025 ETH for WBTC.

5. Your wallet prompts you to sign the transaction by clicking Sign. Clicking Sign submits the transaction

6. JediSwap shows Transaction Submitted. Click Open in browser to view the transaction on StarkScan.

7. Open your wallet to see your balance and the assets that you own. For example, this is my Braavos wallet after the swap:

What now?

Now that you’ve taken those first steps into Starknet, it’s time to plunge deeper into the ever-expanding Starknet ecosystem. As a permissionless network, Starknet sees new developers constantly creating novel dApps and features like stars bursting into being.

To safely navigate the uncharted waters of Starknet, make sure to:

  • Research new releases. Regularly scan Starknet’s news sites and follow the core community to stay abreast of new dApps. This universe evolves fast.
  • Research before interacting with any dApp on Starknet. As with all permissionless platforms, perform due diligence on the legitimacy and security of any dApp before connecting your wallet.
  • Seek fellow travelers. The Starknet forum at is ideal for learning from the journeys of pioneers. Ask questions, think critically.
  • Be wary of scams. Verify URLs, transactions, and addresses — don’t be lured into ambushes.
  • And most importantly, enable wallet protections like 2FA, Hardware Signers, or Wallet Shields. This novel protection level is possible on Starknet because of native account abstraction.

By staying alert and doing thorough research, you can enjoy the full benefits of Starknet’s ever-growing array of dApps and integrations. As with any new technology, educated caution is very important. If something sounds too good to be true, it probably is. With some common sense, you can explore Starknet safely.


This guide was written by Steve Goodman, Principal Technical Writer at StarkWare Industries. You can send questions to @CityOfNewOrleans on Twitter.

Getting Started Using Starknet: Setting Up a Starknet Wallet was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Volition on Starknet: Your Data, Your Choice


  • Starknet presents: Volition!
  • Volition will allow developers to regulate data availability on Ethereum (L1) or on Starknet (L2). Reducing L1 onchain data can radically reduce costs.
  • Flexibility in data availability modes will allow, once again, greater freedom for Starknet developers and users, letting them choose the most suitable security level for their specific needs in a cost-effective manner.
  • Volition will be implemented on testnet during Q4 2023.

Validity Rollups: Increasing Throughput, Reducing Costs

As Ethereum continues to grow, the need for scalability and cost reduction becomes increasingly urgent. For that purpose, Validity Rollups emerged as a scalable and efficient solution that operates on top of Ethereum.

Starknet, a Validity Rollup from the inventors of STARK proofs, operates as Layer 2 that allows massive computations and reduce computation fees by submitting to Ethereum (L1) only the must-have data of each transaction and using a Shared Prover (SHARP) to split the proof’s onchain validation fees across all transactions within a given batch.

In Q4 of 2023, Starknet will unlock another meaningful cost reduction, addressing a major challenge that developers face when it comes to transaction fees: the high cost of L1 onchain data.

Among the various factors that determine the cost of a transaction, onchain data availability alone can account for up to 95% of the average transaction cost. Finding a way to reduce L1 onchain data can have a major impact on the overall cost reduction that users and developers can gain. Starknet’s solution to this challenge: Volition.

Introducing: Volition

Currently, Starknet operates in a Validity Rollup mode, meaning Starknet’s data and the commitment to the state is sent to be submitted on Ethereum. With Volition, data could be stored on Starknet L2, allowing developers to optimize their contracts by choosing its data availability mode at the individual storage variable level.

Volition — as its name suggests — will provide the ability to choose the data availability of an app or a transaction. Starknet developers will be able to flex throughout the data availability spectrum, dynamically choosing their data availability solution, and determine if the data of their app will be available on Ethereum L1, or on Starknet L2 — Free to pass this choice along to the users of their app.

Volition is made possible by implementing Starknet’s state as two distinct storage commitment trees: one for L1 data availability mode, and one for L2 data availability mode. While the data of the L1 data availability mode tree will be posted on Ethereum Mainnet, L2 data availability means that the data of the transactions will be updated on L2 and communicated to the Starknet network. Only the commitment for the data (meaning the ‘root’ of the commitment tree) will be sent to L1.

Make it Your Choice

The security of the layer where data is posted determines the level of certainty for the data’s availability. Data posted on L1 will benefit from the security level provided by Ethereum and will be as available as any other data on Ethereum. On the other hand, data posted on L2 will benefit from lower costs and will be communicated to all Starknet L2 nodes. This ensures minimized risks of failures or malicious actions that could prevent withdrawals or deny access to the stored data on L2.

While these necessary measures are taken to ensure a high level of security for L2 data availability, we acknowledge that for maximum security, L1 data availability (DA) should be your choice, granting Ethereum-grade security. L2 data availability should be used for cases in which developers and users consider the trade-offs between L2 costs and L1 security. We also recommend developers to write contracts that use L2DA, in a way that enable the contract to function (while losing the L2DA assets, for example) in case of an L2 data availability crisis. Moreover, as we introduce Volition, we recognize that refining innovations takes time. Therefore, Volition will be available on the testnet for an extended period. During this phase, we will actively use feedback from our community to tailor it to our builders’ needs.

Introducing Volition on Starknet will improve efficiency and DevEx. The ability to choose independently how to optimize the balance between security and costs will allow Layer 2 apps to adjust their design to user´s needs, and reach wider audiences.

Volition Use Cases and Applications

To best illustrate the effectiveness of Volition, let’s look at a few real-world examples.

Imagine you participate in a high-profile Web 3 game on an app that is built on Starknet. You successfully bid on and purchase a prime NFT of a crossbow. Given the importance of this transaction, you may choose onchain data availability mode. This will ensure the ownership of the crossbow is securely recorded on the Ethereum blockchain, benefiting its wide decentralization. Subsequently, you decide to buy 150 arrow NFTs. Since this purchase is of lower value, you may opt for L2 Data availability to complete the transaction, allowing you to save on costs.

The same concept applies to high-value decentralized trading, where DEX’s top priorities are securing funds and minimizing transaction fees. Users may keep some funds in their L2 data availability account to optimize trading operations. Using the funds stored in the L2 data storage allows traders to execute a high volume of trades with reduced fees. When the funds in the L2 data availability account reach a high amount, the DEX will prioritize security over costs and will move funds back to an L1 data availability account. This transfer ensures that the lion’s share of the funds is securely available on L1.

As seen in both examples, Volition, by enabling developers and users to choose the data availability mode for each contract, allows more control and enhances the user trading experience.

Wen Volition?

Volition will be introduced in Starknet Testnet in Q4 2023. It will remain in testnet for an extended period, enabling us to understand and enhance various security aspects based on the community’s feedback and experience Volition is expected to allow cost reduction for many users and dApp builders. In the future, Starknet will define additional data availability modes, such as Adamantium (a data availability mode that utilizes a committee for users who prefer a trusted party for their data availability).


Starknet’s Volition tackles both security concerns and steep onchain data costs. By allowing data storage on Starknet L2, developers have a shot at cutting costs and boosting scalability, all while maintaining Ethereum’s trusted security. The upside of employing Volition on Starknet is vast, potentially opening doors for innovative app development. Curious about Volition? Dive into a comprehensive lecture by our head of product, Avihu Levy, and explore an in-depth discussion on our community forum.

Volition on Starknet: Your Data, Your Choice was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let the Games Begin: Redefining On-Chain Gaming with Starknet


  • Starknet is redefining the crypto gaming industry by providing fast, cheap, and secure transactions on Ethereum.
  • On-chain games such as Realms and Influence, built on Starknet, showcase the potential of crypto gaming.
  • Starknet leverages Cairo — an ergonomic, developer-friendly Rust-like language — for game development.


For years crypto gaming has touted the potential to transform the gaming industry, thanks to its ability to own and transfer in-game assets. Ownership is just the start for blockchain gaming, with the greater potential being a DeFi style revolution of decentralisation and interoperability in onchain gaming. Unfortunately, the realities of slow and expensive blockchain transactions have kept that potential from being fully realized.

Starknet is changing this by enabling fast and cheap transactions while providing Ethereum’s security. With Starknet’s latest throughput improvements, there are already multiple on-chain games that are being built and are about to realize the potential of on-chain gaming. Two of these games are Realms and Influence. We’ll explore what the games are all about, which features of Starknet allow them to build next-gen systems, and how you can get involved!

First, let’s quickly examine Starknet and how it drives on-chain gaming.

Starknet and Cairo

Starknet is a powerful validity rollup layer (an L2) built on Ethereum. This means that not only are transactions fast and cheap (since they are “rolled” up and processed on L2) but also secure. With the recent Starknet upgrade that massively increased the number of processable transactions per second (TPS). This is extremely important for transaction-heavy industries, like on-chain gaming.

Cairo is a Rust-like smart contract language that allows developers to easily build provable applications, making the most out of the scaling potential of STARKs. Multiple gaming projects (Influence, Realms, Topology, Briq, Cartridge, Dojo gaming engine, etc.) are building on Starknet using Cairo. Cairo 1.0 version has made it more user-friendly than ever, so if you last wrote code in Cairo Zero, it is time to check it out again. (Here is a guide for developers moving from Solidity to Cairo)

Now let’s explore the journey of two of the largest games close to releasing their first public versions on Starknet — Realms and Influence — and discuss both challenges and novel possibilities that stand before them.


Realms.World — one of the pioneers of the on-chain gaming space — has multiple games and a ‘creator studio’ in development.

Realms was inspired by ideas from ‘Loot’, a project launched on Ethereum In 2021 with the aim to bootstrap the development of a fantasy world, and to be owned and built by the community on the blockchain.

The idea of using smart contracts as building blocks to collectively build a fantasy world together on Ethereum appealed to many developers and gamers, who realized the potential that decentralization, open-sourcing, and self-custody can have on gaming.

In creator-focused ‘web 2’ games, like Minecraft and Roblox, the users of the world are still visitors in the publisher’s world. With game worlds built on-chain, once deployed, they are autonomous of their original deployer and anyone can build on top of them. For gamers, the promise of on-chain games goes beyond ‘modding’ and ownership of assets to an entirely novel way of building and playing games together.

The Realms community was inspired by these possibilities and so formed Bibliotheca DAO to drive forward the development of a game world on-chain that encompassed Loot lore as well as its own lore. The DAO and project have been early adopters of Cairo, Starknet, and the new possibilities they offer on-chain games.

Realms Eternum and Loot Survivor

Eternum is a game from the strategy genre, that blends together the gameplay of popular browser games like Travian and Tribal War, with play patterns reminiscent of board games like Catan and Risk, with economic consideration. The 8,000 Realms of Eternum are individual territories, managed and developed by the Lord of each territory. Eternum is an eternal game: it will run as long as Ethereum is producing blocks, and the events in this world will shape its direction.

Loot Survivor is a session-based game, one the first complex fully on-chain games running on any layer 2. In this game, players encounter beasts, traps and opportunities to improve their weaponry and armor with every move. The complexity of the game is made possible by the speed, cost and verifiable computation power of Starknet. Loot Survivor is the first example of an ‘immutable arcade machine’ enabled by ZK circuits.


Influence is a highly strategic and massively social space colonization game, where players vie for dominance and control in the newly formed colony within the Adalian asteroid belt.”

-Chris Lexmond, CEO of Unstoppable Games, Inc. and creator of Influence

After fleeing a dying Earth, humanity’s new frontier is the asteroid belt of the Adalia system. The 250,000 asteroids, each with its own unique mineral composition, all orbit the Adalian star in real-time. Players compete through multiple avenues: mining, building, trading, traveling, researching, and fighting.

In the game’s first release, Exploitation, Players focused on creating colonies in Adalia and the foundation of a player-driven in-game economy.

TIn the next stages of the game — Discovery and Conflict — gamers will focus on technology advancements and inter-asteroid conflicts. At this point, the game will evolve into a full-fledged player-versus-player warfare experience.

Influence offers players the freedom to choose whether to claim their very own asteroid or to start their journey on Adalia Prime, the largest asteroid in the system which serves as open land from which all players can mine valuable resources to begin to expand their influence. Interestingly enough, the structure of the asteroid belt adheres to the principles of real-world orbital physics.

Unstoppable Games will release the inaugural fully-playable version of the game on testnet soon, dubbed the “Pre-Release”.

Currently, 15+ independent applications are already being built with Influence contracts at the center — something that is only possible when you have an open and permissionless framework like blockchain.

The Revolution of On-Chain Gaming

  1. Everlasting: Both Realms and Influence are intended to be everlasting games. As long as the game’s logic stays on-chain and the blockchain supporting the games is active, the games will continue to exist and should be able to function independently of the developers that built them. Moreover, since the entire game logic exists on-chain, others can build on top of the game code.
  2. Empowering players and third-party contributors: players are allowed to have a role in shaping, contribute to the development and engage with the games in ways that transcend traditional gaming boundaries. This might involve creating analytical tools, resource managers, or DPS meters. This player-driven evolution contributes to ever-evolving the game, and creating a vibrant ecosystem.
  3. Enhanced control of game assets: players can buy, sell, and trade assets freely without restrictions from a central authority.
  4. Dojo Power: For Realms creators building the game with Dojo, the world’s first provable game engine, has made the work of the game’s developers much easier( Read more about Dojo here.)
  5. Cairo as a bridge: As apparent on Realms codebase, the game was written in Cairo. As the gaming industry moves from Web2 to web3, the fact that Cairo is a Rust-like language can play a crucial role in the gaming landscape on Starknet: Game developers familiar with Rust-like languages can transition into blockchain game development. In this context, Cairo can serve as a bridge.

“Starknet is taking the long game, and in software, the long game is the game you want to play. Because there is so much optimization that can happen on the CairoVM in the near future.”

Realms Developers


Onchain games empower players and are leading to a new era in gaming. This approach, grounded in decentralization, cultivates a player-driven economy and fosters vibrant in-game communities. Moreover, it encourages innovative gameplay, leading to a dynamic, evolving ecosystem.

Utilizing Cairo, the native language of Starknet only enhances onchain game’s ability to succeed as they can process massive computational data, have ultra-efficient verification, and create seamless UX thanks to account abstraction. Additionally, as enhancements such as Volition and Native Account Abstraction are integrated into Starknet, the cost of transactions is set to decrease much further. With continuous improvements in the Starknet sequencer, the transaction speed will only increase. Amidst this progressive scenario, the outlook for the gaming industry, and Starknet, has never been more promising.

Let the Games Begin: Redefining On-Chain Gaming with Starknet was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Joining Forces: SHARP

Save Costs and Enhance Ethereum’s Scalability: If it’s Written in Cairo, SHARP Can Prove it


  • SHARP (SHARed Prover) generates STARK proofs of aggregated Cairo programs, allowing any app to submit transactions to the same proof. Think UberPool but for STARK Proofs. This ‘ride-sharing’ dynamic means even small apps can access the massive power of STARK scaling.
  • If it’s written in Cairo, SHARP can prove it, however diverse the dApps are. Processing SHARP bundles approximately 220K transactions into a single proof on Ethereum Mainnet.
  • Recursive proving with SHARP enables parallel processing and verification of multiple STARK proofs, enhancing scalability and efficiency.
  • A further reduction in gas fees of up to 30% will be delivered by the upcoming Dynamic Layouts customization for SHARP.

The Scaling Journey

Scaling Ethereum is a journey. It requires ongoing innovation in order to find the next solution that will further raise scaling capabilities. In June 2020, StarkWare launched StarkEx, the first STARK-based L2 scaling solution. In September 2020 it announced Cairo, the first programming language designed to gain maximum efficiency with STARK proofs. Cairo, and the general computation it allows, paved the way for swift and secure coding of proofs for any business logic and arbitrary computational statements. With this innovation came a new wave of developers into the StarkWare ecosystem.

But while these developers wanted the scalability, security, and efficiency of StarkEx, many of their projects didn’t have enough transaction activity to fill up a STARK proof. Similarly, users were still hampered by the unpredictability of rising gas fees triggered by Ethereum network congestion.

And then came SHARP.

What is SHARP?

SHARP (a SHARed Prover) is a powerful system designed to generate STARK proofs for aggregated Cairo programs. Cairo, being a general computation programming language, allows for the accommodation of various code logics in one single proof. SHARP processes batches of transactions off-chain, and validates the proof for their computation on-chain, amortizing the cost of all transactions across a single proof. The generated unified STARK proof is validated through an on-chain Solidity verifier contract, enabling SHARP to enhance throughput, reduce gas fees, and minimize latency.

For example, SHARP can process any Cairo code from entirely different programs and logic, all the way to NFT minting and even Starknet network OS. If it’s in Cairo, SHARP can prove it, and it can aggregate a variety of programs under one proof. The efficiency that SHARP brings results in the capability of bundling thousands of transactions into a single proof on Mainnet. The costs of processing the proof on-chain are split between all transactions in the batch, so the more transactions bundled, the lower the gas fees each transaction will cost.

Let’s use an example to illustrate this idea:

Imagine that you and your sister are purchasing gifts for your parents — a new phone, a mug, and a tee shirt. Each gift is ordered from a different online retailer and will be delivered to your respective homes on different dates, varying in size and packaging. Your plan is to gift wrap each item and ship them to your parents via mail.

However, there’s a predicament at the post office. Small and medium-sized boxes are unavailable, leaving only large, one-size-fits-all boxes. This presents two options:

Option 1: Pack and ship each item separately in its own large box as soon as it arrives. While this may expedite the shipment of individual gifts, it requires the additional effort of packing three separate boxes and making three trips to the post office to send three separate packages. As a result, this method proves to be neither time-efficient nor cost-effective.

Option 2: Pack and ship all items together in a single large box. This means you only handle one box, instead of three.

In this example, SHARP is Option 2, allowing for the efficient use of resources and more streamlined time management.


While SHARP was birthed for the StarkWare Ecosystem, it is capable of proving any Cairo program with a valid execution. Its efficiency in saving time and costs makes SHARP a solution for whatever requires an innovative proving method.

Recursive SHARP

Since its inception, SHARP has undergone a handful of efficiency upgrades. One of the most powerful has been the shift from a linear to a recursive model.

With recursive proving, SHARP proves each statement upon its arrival, instead of first collecting a bundle of statements to fill up a proof, and only then starting the process for the whole bundle of statements. This is a time-efficient way to verify computational statements, much quicker than the calculation itself.

This is achieved by the parallel processing of incoming statements, allowing to bypass previous scalability barriers which required the combined statement to be proved only once all individual statements have been received. Now, not only can SHARP prove the correctness of thousands of transactions but also verify multiple STARK proofs using the corresponding STARK verifiers. This allows the generation of a single proof that attests to the validity of multiple upstream proofs.

With recursion implemented, SHARP proves incoming statements immediately. From there, these proofs themselves can be repeatedly proved and merged into recursive proofs. This recursive proving process is implemented until, eventually, the final proof is submitted to an on-chain Solidity verifier contract. It’s like a nesting pattern: A Cairo program verifies the upstream proofs, which in turn produces a new proof, with a STARK verifier confirming their validity.

Whereas the post office in our analogy initially offered only one standard box size, recursive SHARP has introduced a breakthrough with smaller boxes of different sizes, each specifically designated for an individual item. Although these boxes are not precisely tailored to the size of each specific item, this innovative approach enables the packing of gifts in smaller boxes as they arrive, eliminating unnecessary expenses of unused space and reducing delays. Instead of waiting for all three gifts to be received before packing them into one large box, the smaller boxes allow for immediate packing and preparation for shipping once all gifts are ready.

What’s Next: Dynamic Layouts

Our team is currently developing Dynamic Layouts as the next customization of SHARP services. With Dynamic Layouts, the prover will calculate the required resources for each specific logic and generate a tailored proof accordingly.

Drawing a parallel to our post office analogy once more, Dynamic Layouts can be likened to the idea of custom shipping boxes. These custom boxes perfectly accommodate the shape of each present, ensuring you only pay for the exact size required, avoiding unnecessary fees. Similarly, with Dynamic Layouts, we will create a tailored proof for each logic and the unique computation resources it requires, ensuring you only pay for the computation you use. If it’s in Cairo, SHARP can prove it accurately.

Our team hopes to introduce this improvement in both adaptability and efficiency, by the next SHARP version. Dynamic Layouts will aim to massively reduce gas fees.

By leveraging the power of STARK-based recursive proof generation, this technology is greatly improving the scalability and efficiency of the Ethereum network.

You can read more about StarkEx and Starknet in the following links: StarkExStarknet

Joining Forces: SHARP was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Native Account Abstraction: Opening Blockchain to New Possibilities

Smooth UX, innovative technology, increased adoption


  • Blockchain’s journey to the heart of the mainstream hit a wall: security and UX limits created a barrier to introducing blockchain to a wider audience of Web 2 users.
  • The solution? Account Abstraction (AA). It is the software layer that’s revolutionizing the blockchain landscape by allowing accounts to have flexible design and adjustable deterministic behavior.
  • AA is available on Ethereum and Starknet but implemented differently. Starknet has native AA, which means all accounts are smart accounts. Ethereum has ERC-4337, which adds AA without omitting the legacy of EOAs. The benefits of AA will be considerably diminished in any environment in which EOAs continue to prosper, if only because apps will have to continue to cater to EOAs.

The Wall of EOAs

The Externally Owned Account (EOA) is Ethereum’s simple solution for creating an on-chain user representation that allows users to interact with the blockchain and own assets by linking it to the account’s assets.

While simpler, EOAs’ behavior is pre-determined by the protocol on which they are deployed and therefore lack flexibility in adjusting them to the different needs of users. This often leads to poor UX and creates a barrier to mass adoption. The biggest issue is determined in the protocol: EOAs are controlled by a pair of private and public keys. The main Three problems of having to use pair of keys to initiate transactions are:

  1. Poor UX — the requirement to keep the private key in a secure, discreet place is not intuitive for the key holder who is used to using smarter, more modern methods like a 6-digit password or face ID; making initiating transactions more challenging.
  2. Nothing but a key — Knowledge of the private key’s details is not just the only way to initiate transactions, but also the only way in which the protocol identifies the account’s owner. By that, a security hazard is created — in which if your key is compromised, you are indistinguishable from the entity who stole it.
  3. The protocol is the master — It is clear from the examples above that in the realm of EOAs the Ethereum protocol, and not the developer, is the one to determine which transaction is considered valid.

The complications caused by determining the account’s behavior as part of the chain’s protocol are found in most chains.

Breaking the Wall: Introducing Account Abstraction

The issue caused by the protocol, as opposed to the user determining accounts’ behavior, exists in most chains. As early as 2015 Ethereum co-founder Vitalik Buterin discussed these challenges. He describes Account Abstraction (AA) as the solution that represents a simpler way to handle accounts — reducing, or even ending reliance on private keys. What is more, AA creates a host of other benefits that will make Web3 user experience indistinguishable from Web2 and, as such ease the way to mass adoption.
Over the years, two significant approaches to AA emerged, and both carry the same goal of empowering app developers to design their apps and creating a simpler way to handle accounts.


As mentioned before, EOAs are an inseparable part of Ethereum, and their behavior is defined by the Ethereum protocol. In addition to EOAs, Ethereum also has contracts, which can contain user-defined code. In 2023, Ethereum introduced a protocol upgrade — ERC-4337 — in order to bridge the structural gap between EOAs and contracts, without introducing major protocol changes. ERC-4337’s main idea is to introduce a new role: The Bundler. The Bundler’s role is to collect user operations (think of them as meta-transactions that are collected in a specialized mempool), and send them to Ethereum from their own (Bundler-controlled) EOAs. In this way, the Bundler allows developers and users to deploy and interact with account contracts and gain the advantages of AA.

Introducing AA to Ethereum with ERC-4337 allows developers to create a more flexible behavior for contracts. However, Ethereum continues to maintain EOAs. For developers, the consequence is having to serve both EOAs and ERC-4337. In an ecosystem where EOAs are cheaper it is likely to assume that EOAs will remain dominant, and applications won’t be able to harvest the real value of AA across their entire user base.
EVM chains that track or emulate Ethereum, including zkEVMs, will experience a similar evolution: EOAs will remain the dominant form of accounts, negating the benefits of AA and losing the advantage of not having to work around EOAs legacy.

Starknet’s Native Account Abstraction

By contrast, Starknet has AA at its core: All accounts are smart accounts — there are no EOAs. It’s a jump to a world where every account is smart. All infrastructure, including wallets and block explorers, are designed and built for AA. This is unique across L1 and L2 chains, making Starknet the first smart ecosystem: Builders can build their apps and tools knowing that AA applies to all accounts, and save the need to work and service non-AA accounts. Builders can design their app to benefit from the full breadth of opportunities presented by AA, knowing that smart accounts are the only means users have of interacting with the application.

Native AA on Starknet eliminates the additional complexities associated with introducing a Bundler, as done with ERC-4337. There is no need to adapt infrastructure and tools to interact with it. This simplification is achieved by designating the Sequencer to fulfill the Bundler’s role.

The Three Pillars of Account Abstraction

There are three main components of AA. Each component serves a unique purpose to enhance the overall user experience: Signature Abstraction, Fee Abstraction, and Nonce Abstraction.

Signature Abstraction

Signature Abstraction designs the flow of transactions. The power to define a valid transaction is in the hands of the architect — the account designer, be it the developer or the user. The main benefit here is the freedom to customize account permissions, as well as the potential usage of Smartphones to control accounts.

Fee Abstraction

Fee Abstraction allows different tokens to be used as payment for transaction fees, without being restricted to the network’s native token. For instance, a user could use USDC to pay the transaction fee, bypassing the need to first convert USDC to the native token, thereby saving on exchange fees and time.

Nonce Abstraction

Nonce Abstraction ensures comfort and convenience for the user. Traditional sequential nonce solutions have several UX drawbacks. For example, it restricts users from sending multiple independent transactions simultaneously due to its enforcement of complete ordering. Nonce Abstraction provides the required flexibility by allowing customization of the account’s replay-protection mechanism.

Rollups, such as Starknet, can be thought of as blockchain operating systems. When designing a new operating system things work best without inheriting the challenges of previous operating systems. It’s the equivalent of building a new house as opposed to renovating an old one. When designing a new house, critical infrastructures such as electrical wiring, plumbing, and a heating system, should be incorporated during the blueprint stage. There is little sense in building a new house with mere adjustments and workarounds for what is already known to be the required standard in the future. The same principle applies to AA. Designing Starknet was done looking forward, towards the future and what we believe will become the standard way to build apps. With AA as the default, and in fact, the only option, Starknet provides the seamless, efficient, and user-friendly experience we’d desire to have in the future.

Looking at the features enabled by the implementation of AA, it is clear that the benefit is twofold — the first for users as they benefit from better UX, and another one for developers, as they don’t need to be burdened with EOAs legacy.

Under Construction — Account Abstraction Implementations on Starknet

Starknet’s smart ecosystem is already providing a fertile ground for growth, much like how the introduction of software revolutionized the cash economy. Initially, software digitized records and streamlined processes, and it has since evolved into a wider set of systems that manage transactions, track finances, and automate financial processes. Similarly, Starknet’s smart ecosystem empowers developers with the ability to interact seamlessly with various apps and providers. This not only enhances user experiences, making them richer and more dynamic but also promotes a collaborative and innovative environment, fostering an ever-growing, fertile ground for development.

It is evident from the following exciting app advancements made using signature abstraction on Starknet’s native smart accounts:


Using Starknet native smart account, the Braavos team created a smart wallet that enables a Web-2-like experience, allowing you to use your mobile phone’s biometric identity feature to access your wallet. This is exciting as the differences between the cryptography used in most blockchains versus that of mobiles, usually result in extremely costly signature verification, and might in the future enable signing off transactions using mobile phones, while maintaining a high level of security.


Another innovation brought up by using signature abstraction, is ArgentX’s guardian service, Argent-Shield. This service allows users to add another layer of protection for their account by having Argent function as a guardian, who will only approve your transactions if it was confirmed via mail. This is another 2-factor authentication mechanism that most of us are familiar with from many non-blockchain apps.


STARK proofs were invented to tackle Ethereum’s scalability challenge, aiming to achieve the same TPS capacity as Visa. For that reason, Visa’s decision to conduct its much-discussed exploration of ‘auto payments for self-custodial wallets’ on Starknet is a significant milestone. It demonstrates their recognition of our cutting-edge technology and innovative smart ecosystem.


Starknet’s ecosystem is growing by the day, with more and more builders who utilize Starknet’s native AA to design their apps in the most flexible way possible. The opportunities for integration with other providers and the ability to offer users more sophisticated and personalized experiences mirror the boundless potential of a digital economy.

Developers are not required to work out solutions for past practices. Instead, they can build their app in an environment designed for their future needs, built from the ground up.

Native Account Abstraction: Opening Blockchain to New Possibilities was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Paradex: Starknet’s first Appchain

Paradex x Starknet

Quantum leap in Starknet throughput is bringing a new cutting-edge financial use case to the Starknet ecosystem

Can We Skip to the Good Part?

Paradex, a new crypto-derivatives exchange, is launching on Starknet’s first Appchain. Paradex will offer perpetual futures trading with deep liquidity, capital efficiency and performance while remaining transparent and self-custodial. Paradex was incubated by the team at Paradigm, the largest institutional liquidity network in crypto.

This collaboration between StarkWare, inventors of STARK technology, and Paradex is a demonstration of the power of Starknet to cater for the needs of apps that require high scale, low costs, and custom specs, all while attaining decentralization and self-custody.

How We Got Here

Blockchain technology was invented with decentralization and security at its core, in order to tackle the disadvantages of traditional finance and its reliance on a third-party entity when handling assets. Notable events, such as the FTX crash in November 2022, underscored the essential need to provide users with self-custody, security and transparency.

STARK-Based Solutions

STARK technology aims to provide massive scaling on the one hand, while simultaneously retaining Ethereum’s security and decentralization on the other. It has been used to process more than $1T, including StarkEx-powered apps such as Sorare and dYdX. Starknet, a STARK-based layer 2 Validity Rollup, has established one of the most creative and robust ecosystems in Web3. With the expanding variety of use cases on Starknet, it is only natural that some app developers would want to use Starknet for scaling, but they would like to customize it to their needs.

Leap of Chain: Introducing Paradex, Starknet’s First Appchain

“Paradex played a key role in being the first to adopt the new sequencer, a clear demonstration of our deep belief in the StarkNet team and its emerging ecosystem”

“As we began evaluating blockchain scaling technologies that would enable Paradex’s ambitious vision, it became clear that we needed a solution that would not only deliver performance and scalability, but also control and customization. A private instance of Starknet, or Appchain, provides this in abundance.”

Nafaa Hendaoui,

Head of product at Paradex

As a derivative exchange, Paradex requires heavy computational capabilities to run complex business logic. It is determined to do so while establishing decentralization in order to ensure its users experience fair, transparent, and secure trading.

STARK-based validity proofs provide integrity through math, with their power boosted by recent technological advances on Starknet, including the major throughput improvement presented in Starknet Quantum Leap (V0.12.0), which made the creation of Starknet’s first Appchain possible.

Starknet Appchains let applications that need significant scale to create their own highway, where they are the only user, free to adjust specs without being dependent on others’ protocols, and still benefit from Ethereum-grade security and decentralization.

Building with Cairo. Fast.

The business logic of the application was written in Cairo by the Paradex team. The speed with which the team mastered Cairo, and the ergonomic nature of the language, ensured its quick progress. Within just six months, the Paradex team was able to build a Starknet Appchain to fit its needs, and to take part in reaching Starknet’s V.0.12.0 impressive scale improvements before deploying it on Mainnet.

The business logic, feature development, and addition of the Appchain were determined solely by the team who will operate it, which allows maximum optimization using new customized features as well as Starknet signature features, such as multi calls, that will allow optimization of perpetual trading on Paradex.

Join the Ride

Welcoming Paradex Appchain to Starknet’s ecosystem is a sign of its innovation and strength in winning recognition from major actors in the crypto world. As new features, initiatives and possibilities unlock the ecosystem’s use on public Starknet, such as the recently introduced Starknet Stack, it’s getting clearer by the day that Starknet is in the midst of a remarkable growth spurt.

While Paradex was the first to use Starknet Appchain, it opens a world of new opportunities for companies of varying sizes seeking scalability, security, and decentralization packed into one tailor-made product that suits each company’s special needs. Harnessing STARK technology to reach new heights and provide clients with improved performance is within your reach. Join us now.

Paradex: Starknet’s first Appchain was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Harnessing the Beast — Madara and the Revolution of Starknet Appchains

Harnessing the Beast — Madara and the Revolution of Starknet Appchains

Harnessing the Beast — Madara and the Revolution of Starknet Appchains

From Massive Cost Reductions to Personalized Control, Discover the Future of Blockchain Infrastructure


  • Madara is a high-performance Starknet sequencer, providing the power to create customizable and efficient appchains.
  • By using the Substrate framework, Madara amplifies the capabilities of the Cairo VM, leading to provable, secure, and flexible programs.
  • Its implementation offers numerous benefits such as scalable infrastructure, high throughput, and unprecedented control over applications.
  • Unique features of Madara include support for potential on-chain privacy, streamlined interoperability across various chains, and robust execution.
  • Madara is paving the way in dApp development by delivering cost-effective, scalable, and customizable solutions in the blockchain domain.


Imagine having the power to tailor-make a blockchain specifically for your application’s unique requirements — that’s exactly what appchains offer. Appchains are application-specific blockchains that offer developers the flexibility to fine-tune aspects of the chains to suit their applications’ needs, like choosing a different hash function or customizing the consensus algorithm. The best part? Appchains inherit the security of the robust L1 or L2 blockchains on which they are built, providing developers with the best of both worlds.

Introducing Madara, a game-changing sequencer that combines flexibility and lightning-fast performance. Sequencers are entities responsible for executing transactions and grouping them into batches. Acting as a gateway to launching your very own Starknet appchain, Madara opens up a realm of possibilities for experimentation in the Starknet ecosystem like never before.

Before we delve into the fascinating capabilities of Madara in enabling Starknet appchains, it’s important to address the question of why developers would opt to build appchains on top of Starknet rather than utilizing the Starknet Validity Rollup directly. One might wonder if Starknet is already sufficient for most scenarios.

Let’s first learn why appchains are a compelling extension to the Starknet ecosystem.

Why Appchains

Madara, developed by the StarkWare Exploration Team, also known as Keep Starknet Strange, is specifically designed to realize StarkWare ‘s fractal scaling vision. There are numerous compelling reasons why developers might choose to establish a Starknet appchain or L3 instead of directly relying on Starknet.


App developers face significant challenges in terms of scalability within the existing blockchain infrastructure. Scalability encompasses two crucial aspects: high speed and low fees. By implementing a 1,000x cost reduction at each layer, developers can achieve a remarkable overall cost reduction from L1 to L3, potentially reaching up to 1,000,000x. The throughput remains unaffected by the activity of third-party applications as the app has a dedicated blockchain and is not competing for resources. This ensures a consistently smooth experience.


General-purpose chains like Starknet and Ethereum have multiple measures in place to ensure the network is usable by everyone, leading to a constrained environment. With appchains, developers can fine-tune various aspects of their applications and infrastructure, creating tailored solutions. Don’t like a feature of the Cairo VM? Eliminate it in your appchain.


The customizability of appchains also allows developers to work with features that are currently unavailable or risky in environments like Starknet. Appchains will offer each team the autonomy to write and authorize any desired code hints. This allows appchains to unlock many use cases, like being able to enforce on-chain KYC without leaking private information.

Madara’s Effect on the Appchain Stack

Let’s take a look at the interplay of different layers powering appchains, and where Madara comes in.

  • Execution: The execution layer defines the execution of blocks and generation of state difference. Madara offers the flexibility to switch between two execution crates, blockifier by StarkWare and starknet_in_rust by LambdaClass. Regardless of the crate chosen, the underlying framework utilizes the Cairo VM. The Cairo language facilitates the creation of provable programs, enabling the demonstration of correct computation execution.
  • Settlement: As a Validity Rollup, a Madara appchain’s state can be reconstructed solely by examining its settlement layer. By settling more frequently on Starknet L2, an L3 appchain can achieve faster hard finality, while decentralizing the sequencing layer enables more robust soft finality. Hence, settlement is enhanced on both fronts (hard and soft finality).
  • Sequencing: Madara takes charge of the sequencing process, which can be altered to suit the application’s needs — be it simple FCFS, PGA or more complex schemes like Narwhall & Bullshark. Certain appchains can choose to deploy encrypted mempools to ensure fair ordering and mitigate the impact of MEV.
  • Data Availability: Data availability guarantees that the complete state tree remains accessible, providing users with the confidence that they can prove ownership of their funds even if Madara experiences a disruption. Madara will offer developers a range of data availability (DA) schemes to choose from.
  • Governance: Each Madara appchain can choose its governance model. Snapshot X offers a fully on-chain governance system that relies on storage proofs. Alternative governance mechanisms are also under exploration, such as the native substrate governance pallet. On-chain governance stands as a core value for Madara.

Enter: Madara

In Madara, the Cairo VM is being enhanced by utilizing the Substrate framework and integrating the Cairo VM for executing Cairo programs and Starknet smart contracts. Substrate is an open-source Rust framework to build customizable blockchains, that is known for its flexibility. Meanwhile, the Cairo VM is specifically designed to efficiently generate Validity Proofs for program execution. By employing state tracking and a smart contract to verify these proofs on L2, appchain ensures secure integration with Starknet. This way, Madara leverages Cairo’s power to enable the provability of program execution.

The Substrate framework’s inherent modular nature lets developers customize the appchain with ease. No assumptions are imposed, allowing you to incorporate your own consensus protocol, hash function, signature scheme, storage layout — whatever your app requires, all while utilizing Cairo to generate proofs. No limits on what developers can do while still being provable, inheriting the security of the underlying chain — be it Starknet or Ethereum.

Initially, Madara will bear a strong resemblance to Starknet, enabling the composability of smart contracts within the Starknet ecosystem. There are bigger plans in store for the future as Starknet integrates with Herodotus to leverage storage proofs to achieve interoperability. The integration of storage proofs will also let Madara appchains consider state and liquidity from other chains.

Prepare to witness a new era of possibilities in the realm of Starknet, enabled by Madara.

The Starknet Stack’s Growth Spurt


  • The Starknet Stack is developing at dizzying speed, and will allow you to launch your own custom Starknet instance, to suit your needs
  • Starknet is already the most performant L2 in terms of throughput
  • With the fastest-growing developer community, Starknet has the most decentralized Rollup Stack, including lots of key infrastructure, built by multiple independent teams
  • The first Starknet Appchain is coming to Mainnet very soon


There is a veritable renaissance of public L2 chains over Ethereum. Starknet, in particular, has been flourishing, with a bustling community of developers tackling exciting use cases in gaming, DeFi, NFTs, AI, and more.

The need for Appchains, application-specific blockchains that are designed to service the needs of one specific application, has been apparent for several years and is now getting renewed attention. StarkWare’s SaaS offering StarkEx, has been powering the most successful L2 Appchains running on Ethereum today like dYdX and Sorare. To date (July 2023), StarkEx has settled some $1T in cumulative trading and processed over 500M txs. Starknet Appchains are the bespoke environment where applications can tailor an instance of Starknet to achieve better control over the specs, lower cost, greater scale, and opt-in privacy. The Starknet Stack is intended to allow any application to deploy its own Starknet Appchain in a permissionless fashion.

The Starknet Stack

Starknet’s building blocks attract a wide range of applications and use-cases. They are: STARK proofs, the Cairo programming language, and native Account Abstraction. With Starknet’s upgrade to v0.12.0 on Mainnet, Starknet became the most performant L2 by TPS. We expect Starknet’s performance advantage over other L2s, and in particular over the EVM-compatible L2s, to grow over time, as Starknet is unshackled by legacy constraints put in place by the EVM’s design and implementation.

Still, it is only natural that some applications require further fine-tuning to their platform. The Starknet Stack will allow them to do so.

In the spirit of the Starknet ecosystem, we aim to show first, and tell later. But given the electrifying development efforts within our ecosystem, and the pace with which the Stack is evolving, we decided to offer our current perspective on the Starknet Stack. The development efforts are driven by the Starknet ecosystem, and are orchestrated by the Starknet Foundation via its development partnerships.


The Starknet Stack allows applications to spin up bespoke Starknet Appchains. These will yield the generic benefits of Appchains, namely:

  • Protection from congestion on the public Starknet, can provide its users with better throughput and UX.
  • Appchains are potentially free to implement features not supported on the public chain, such as their own fee market logic. From the public network’s perspective, these new features implemented in Appchains are invaluable experiments. Implementing these on an Appchain would yield valuable conclusions that may carry over to other Appchains, or to the public network.

Beyond these benefits, Starknet Appchains will have additional benefits. Starknet is the most scalable rollup, with the option to configure various parameters, including consensus, block chain parameters, and data availability.


The Starknet Stack is quickly becoming the most decentralized L2 stack. Permissionless blockchains focus on decentralization as a means of achieving network security and resilience. The Starknet Foundation is focused on achieving this property for Starknet.

“A decentralized stack makes the network more secure, resilient, transparent, scalable and innovative. No single point of failure, no dependency on a single entity, no black boxes and many more builders!”

Diego Oliva
CEO, Starknet Foundation

“Starknet is achieving organic decentralization of the stack — different teams are producing optimized versions of the core components, that then find their way back way to official releases (LambdaClass Rust VM) or sparkle entirely new components”

Nicolas Bacca
Co-Founder & CTO, Ledger


One recent example for the decentralization of the Starknet Stack is the Madara Sequencer. It is based on Substrate, and as such relies on decentralized consensus mechanisms right out of the box. The community development effort started in Feb 2023. The engineering effort includes 45 community developers, who have produced to date (July 2023) over 740 commits and over 400 merged PRs. This effort has produced a Sequencer which is compatible with public Starknet, with a configurable mempool and more.


Another notable effort in building the stack that will allow launching Starknet Appchains is the work done by LambdaClass (who also played a pivotal role in the improvements manifest in V0.12.0). LambdaClass is building a Starknet Stack that will eventually include a prover, a sequencer, an execution engine, and a network explorer. In the near future, these different components could be integrated with other components of the Starknet stack, and made into a working Starknet instance.

By the Community, for the Community

The Starknet ecosystem aims to have multiple implementations of every single component in the Stack. Here is a taste of the different teams and the infrastructure they’re developing:

CategoryProjectEntityStatusFull NodePathfinderEquilibriumIn productionJunoNethermindIn productionPapyrusStarkWareSoon in productionDeoxysKasarLabsIn developmentExecution EngineBlockifierStarkWareIn productionstarknet_in_rustLambdaClassSoon in productionSequencerSW SequencerStarkWareIn productionMadaraCommunityIn developmentLC SequencerLambdaClassIn developmentProverSW Prover StarkWareIn productionLC ProverLambdaClassIn developmentSandstormAndrew MilsonIn development

In addition to the core components of the stack, there are important complementary components and services that are needed in order to run an Appchain (all in production, unless otherwise noted):


The Starknet Stack is powered by Cairo. Its latest version, Rust-like and ergonomic, has been met with tremendous excitement by the developer community.

“As someone who has never written any Rust, I picked it up a few weeks ago and I’m as efficient in writing Cairo contracts as Solidity. Throw in the ability to share logic across contracts (coming soon!), and built-in fuzz-testing, and it will be my preferred environment for writing smart contracts!“

Moody Salem

Lead Solidity Dev, Uniswap

Cairo, as a general purpose smart contract language, with the added benefit of producing provable computations, is consumed by one of the fastest growing blockchain developer ecosystems in history. Applications can find Starknet developers to partner with, hire, or outsource to.

“Starknet’s ecosystem feels like early Ethereum. It attracts the best talent in the space, with its decentralized approach to development and innovation“

Itamar Lesuisse

Cofounder & CEO, Argent

The Road Ahead

The Starknet Stack is WIP and will continue to evolve and improve over the years. Yet already today, Starknet Appchains can be run as a hosted service, operated by StarkWare. In fact, the first Starknet Appchain will launch a closed beta on Mainnet real soon (!).

We expect Starknet ecosystem development teams like LambdaClass, Nethermind, and StarkWare, as well as Rollup-as-a-Service providers to offer Appchain hosting services. Appchains will choose which components of the Stack they run themselves, and which they run through a hosting service (e.g., StarkWare’s SHARP). They may choose to rely on strictly open-source components, or on proprietary technology. This is the beauty of Appchains — one size does not fit all. Instead, each application will make its own optimal choices.

Appchains started out as an L2 over Ethereum, but will not remain there for long. Back in 2021, StarkWare introduced the concept of L3. We believe that in order to achieve better scale and lower gas/tx, Starknet Appchains will migrate to L3, and as such will run over the L2 public Starknet.


The Starknet Stack is in the midst of a remarkable growth spurt. We expect it to dominate the Appchain space due to its performance, security, and expressiveness. The thriving Starknet developer ecosystem, which has been driving the rapid evolution of this stack, will continue to develop it, and meet the various needs of more and more applications.

The Starknet Stack’s Growth Spurt was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dojo on Starknet: Game On!

The First Provable Game Engine for Starknet


  • Dojo is a provable on-chain game engine, enabling games with ownership, interoperability, and extensibility.
  • It operates on Starknet, providing a software framework for game creators, to help them create a high-quality seamless, and fast game.
  • Dojo enhances game development by enabling fast and cheap transactions, necessary for production-grade crypto gaming.
  • Components like ECS, Sozu, Torii, and Katana aid game development and deployment.
  • Future Dojo enhancements include Layer-3 game research, optimistic updates, client-side proving, and cross-chain transfers.
  • Dojo-powered games on Starknet, like Dope Wars, Influence, Realms, and CafeCosmos, are increasing, marking a rising trend in on-chain gaming.

Blockchain games have failed to live up to their promise. The limitations in scale and high costs have limited most on-chain games to the tokenization of in-game assets. But with the cheap and fast transactions enabled by Starknet and the new Dojo crypto gaming engine, the promise of not only owning your in-game assets, but also proving the game logic on-chain, is coming true.

The global gaming market, valued at $245 billion as of 2023, is one of the largest segments of the worldwide entertainment industry. And blockchain gaming, with its promise of allowing boundless interoperability, offers an opening to a world of gaming that is much more exciting than the current scenario. Similar to how multiplayer games added a whole new dimension of possibilities to the gaming ecosystem, on-chain games can become even more entertaining and relevant.

But that promise has run up against the reality of blockchain — transactions are expensive and slow. These are two problems that games simply can’t have. Because of this, creating successful on-chain games has been nearly impossible.

But with the maturity of validity rollup technology, the promise of on-chain games is finally being delivered.

In this article, we’ll look at how the high TPS enabled by Starknet brings the promise of on-chain games to fruition. And we’ll look at how Dojo — the first community-built provable gaming engine — uses Starknet to empower creators. Finally, we’ll look at the future of Dojo and what it unlocks for blockchain gaming.

Crypto Gaming

When we talk about blockchain gaming, the two most popular ideologies that blockchain enables are ownership of in-game assets and interoperability.

Ownership of in-game assets means that game assets belong to a wallet owned by the user. In other words, they do not belong to the game builder or to a simple email account stored on a centralized server that the game devs can remotely delete. In blockchain gaming, assets that you create or earn truly belong to you.

And once these assets belong to you — games can enable interoperability. With interoperability, characters and assets from one game can be transferred to a different game or world. If you invest hundreds of hours in a game but decide to no longer play, you can take those hard-earned assets with you to your new game of choice.

In order to implement these two concepts, games must be built on-chain. This means that all in-game assets, all the actions taken by the player, and any other state changes must take place as a transaction on the blockchain (either separately for each action or an aggregate transaction pushed periodically). On a fairly decentralized blockchain, it can cost a few cents to a few hundred dollars (during congestion) and take several minutes or more for a single transaction. Obviously, this makes operating large-scale gaming infrastructure on such platforms prohibitively expensive, slow, and impractical.

Starknet and Cheap Computation

But all that is changing with the advent of validity rollups such as Starknet.

Starknet is a Layer 2 validity rollup (commonly known as a zero-knowledge rollup) developed by StarkWare that uses cryptographic systems called STARKs to massively decrease computation and storage costs. (To learn more about cryptographic proofs on Starknet, refer to an introductory article here.)

Starknet (and Cairo, the smart contract language for Starknet) allow dApps to process high TPS at minimal cost and yet still take advantage of the security of Ethereum. These cheap and fast transactions are exactly what’s needed to unlock the promise of blockchain gaming. Games can now be fully on-chain, fast, and affordable.

But even with the ability to be on-chain, for blockchain games to flourish they need a second key building block: a provable game engine.

What are Game Engines

A game engine is the software framework that enables the beautiful settings, swift player movements, and realistic character behaviors in the games you love. A game engine usually includes libraries and support programs that provide developers with a framework so they don’t have to recreate fundamental systems (such as physics, graphics, and game mechanics) from scratch for every game. Game engines can also include audio and video processing, rendering 3D effects, and AI features.

A game engine is the stage upon which a game is built.

Most of the games that we love to play owe their existence to two of the most popular game engines in the world: Unity and Unreal Engine. The Unreal Engine, developed by Epic Games, has been used in popular titles like “Fortnite,” “Street Fighter V,” and the “Gears of War” series. Unity, another major player in the game engine industry, has brought games like “Hearthstone,” “Ori and the Blind Forest,” and “Pokémon Go” to life.

Because Starknet unlocks the promise of crypto gaming, a rush of projects have started building games on Starknet. But what is still missing is a crypto game engine that allows developers to build games without having to write custom code for basic physics, logic, and game mechanics — and all while staying on-chain.

Dojo — the First Provable Game Engine

Dojo is that crypto game engine. It is a community-built, provable game engine and toolchain for building on-chain games and autonomous worlds. It brings the promise of crypto gaming to reality.

The number of games on Starknet using Dojo is growing quickly. Some of the most popular include:

  • Influence — A grand strategy MMO set in a distant asteroid belt with a player-owned open economy. The users can buy NFTs that permit them to explore and develop asteroids. All the asteroids live in the same world, and players can interact with one another.
  • Realms — A strategy game with 8,000 land maps with specific names, forms, sizes, and geographical traits that give users (owners of these lands) on-chain utility, such as resource generation and fungible housing primitives allowing for economic games.
  • CafeCosmos — A land-based on-chain game where users must manage resources efficiently. This includes gathering resources, farming, and rearing animals, crafting appliances and furniture, trading assets, and so much more.

Dojo Components

The Dojo ecosystem has the following components:

  • ECS (Entity Component System) written in Cairo
  • Sozu migration planner
  • Torii networking & indexing stack
  • Katana RPC development network

Let’s walk through each of these in detail.

An ECS system is a design pattern used in game development to promote more maintainable code. An ECS system allows the game developer to give unique features (components) to the game’s objects (entities), allowing the whole scene to work as an integrated system.

Dojo’s ECS framework, specially designed for blockchain-based game development, promotes modularity, efficiency, and flexibility, which are vital to managing blockchain environments’ unique challenges. This enables the creation of complex, dynamic games on the blockchain, supporting diverse game mechanics and interactions while harnessing blockchain technology’s transparent, decentralized benefits.

And, since Dojo is written in Cairo, it maximizes the efficiency of code that needs to be proven. (To learn more about the intricacies of Cairo and what we mean by provable, we recommend this article.)

Sozo is a toolchain adapted specifically for building and migration planning. In other words, Sozo can be used for deploying the developed games on Starknet. With a simple `sozo migrate` command, deploying an instance of the game “world” on-chain is possible. Sozo is only available as a command-line interface (CLI) tool. However, a GUI interface is currently in development.

Torii is a comprehensive indexing and networking layer for Dojo worlds. Since the Torii system is built on top of Dojo, it is designed to index any events happening in the game worlds deployed on-chain. It systematically organizes the state of Dojo’s worlds, making querying data for clients convenient and efficient. Considering many state changes in games — imagine each click is a state change — efficient querying systems are a useful feature on top of the Dojo stack. Queries on Torii are made in GraphQL.

Katana is an extremely fast local Starknet node designed to support local development with Dojo. Katana allows developers to test their applications on this “devnet” for rapid local development. Developers can use the Katana network to test the transactions being sent during the game. Katana provides convenient RPC methods that can be used to change the network’s configuration as needed (for example, changing the block time or allowing zero-fee transactions, etc.). On top of that, Katana supports version v0.3.0 of the Starknet JSON-RPC specifications (the latest version as of June 2023). Native Starknet JSON calls, such as starknet_getTransactionReceipt, starknet_getStorageAt, can be used on Katana.

The Future of Dojo and Crypto Gaming

The Dojo community continually researches and builds in order to push crypto gaming forward. In addition to improving the current components, the lead developers are working on:

  • L3s for games
  • Optimistic updates
  • Client-side proving
  • Cross-chain asset transfers

Let’s look at each one and what it means for gaming.

L3s for games — Dojo is researching the viability of developing games as L3s on Starknet. This means that a separate chain is deployed on top of Starknet which periodically proves the execution of its transactions and submits the proof on Starknet (the L2). Starknet aggregates this proof with other transactions on the network and submits the proof to Ethereum L1, where the proof is verified. This solution could increase the scalability of games even several times more. (As an extra step, think about if every time a player attempts a level in the game, a new layer is built for a one-time use on top of the game layer.)

Optimistic updates — How often have we sat silently waiting for the “transaction in progress…” text in our wallets to turn green and show the transaction as “verified”? A lot. If every move a player takes in the game is sent as a separate transaction, the player would waste a lot of time waiting for the transaction to be accepted.

Optimistic updates — which Dojo is working on adding as an extra feature to its stack — get rid of this problem by optimistically running the transaction on the client side (in the browser itself) and allowing the player to continue the game. If, for some reason, the transaction’s outcome is different from what was run in the browser, the game would reconcile the changes.

Client-side proving — Along with optimistic updates running on the client side, Dojo is exploring the possibility of client-side proving parts of transactions sent on-chain. This would allow the games built on top of Dojo to effectively blind some of the inputs passed by the user since a ZK proof of receiving those inputs on the client side can be created. This ZK proof, in turn, could be sent on-chain to the sequencer, which executes the rest of the transaction.

Utilizing storage proofs — Storage proofs are a cryptographic way to store blockchain information so that it can be shared across chains. Similar to oracles, they provide proof that information is true. But unlike oracles, they do not require trust in a third party for this proof — with storage proofs, the trust is built into the storage. Storage proofs also allow proving the validity of the state for another chain or layer built on top of Ethereum.

Dojo is working with the Herodotus team to implement storage proofs in Dojo so that cross-chain asset transfer is unnecessary. Ownership of an asset from a different chain could be proven with storage proof, and the user would be able to use their assets in different games on different chains or layers. (See the part about games being built as separate L3s on top of Starknet discussed above.)


Dojo is the world’s first provable game engine and is made possible due to the availability of Starknet and Cairo. With provable gaming engines such as Dojo, truly on-chain crypto games are starting to see the light of day. The “interoperability and ownership” promise is being fulfilled one step at a time.

If you want to help the Dojo community to build the future, visit them at or reach out on their Discord.

Dojo on Starknet: Game On! was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Starknet Quantum Leap: Major Throughput Improvements are Here!

Starknet is about to break through the TPS barrier


  • Starknet alpha V0.12.0 is deployed on testnet
  • Starknet achieved a remarkable 10x increase in throughput by implementing the Sequencer in Rust. This was driven by a close collaboration between StarkWare and LambdaClass
  • A smoother user experience will be provided as the `PENDING` status for transactions has been removed
  • A new syscall has been introduced, allowing easy retrieval of past block hashes
  • Starknet alpha V0.12.0 will support a new Cairo syntax that focuses on safety
  • The network upgrade to this version will undergo a community vote, ensuring widespread participation and input


We are excited to announce the release of Starknet Alpha V0.12.0. This version is a significant milestone which will mark the beginning of a major leap forward in providing enhanced performance and scalability. This version is another step in Starknet’s journey to scale Ethereum, with a focus on addressing throughput and latency. To tackle these challenges, we targeted Starknet’s Sequencer, as much of the limit to throughput is determined by its performance.
The development of Starknet Alpha V0.12.0 is largely the result of a productive and enjoyable year-long collaboration between LambdaClass and StarkWare. We are proud to build Starknet with the LambdaClass team.

This version, being a major one, will be up for a community vote. We invite the community to participate in shaping the future of Starknet.

Performance — Throughput is Here!

This version focuses on performance, and specifically on improved throughput, resulting in a significant 10X increase. The throughput has surged from an average of 30K Cairo steps per second (CSPS) on v0.11.0, to an impressive 220K CSPS in this latest version. This remarkable achievement results from targeted optimizations that underpin the efficiency of the Starknet Sequencer, as previously shared in our performance roadmap. Three key ingredients have contributed to this improvement in Starknet’s performance: Cairo-rs, Blockifier, and Papyrus, and they all benefit from the power of Rust.

The first improvement to the Sequencer is the integration of Cairo-rs, a highly efficient Cairo runner written in Rust and developed by LambdaClass. By leveraging the power of Rust, Cairo-rs has enhanced the execution of Cairo contracts, resulting in a more streamlined experience for users.

Additionally, the introduction of the Blockifier, a Rust-based block execution logic, has played a crucial role in improving throughput. By optimizing transaction execution time this implementation has effectively reduced wait times and alleviated network congestion, The inclusion of Papyrus, a local storage solution, has contributed to the efficient management of the Sequencer’s local state. This enhancement has further optimized the overall system performance and responsiveness.

This is Merely the First Step

The Sequencer optimizations in this version are far from the end of the road to performance improvements.


Starknet will integrate LambdaClass’s cairo_native compiler, which will enable the execution of Cairo contracts in a more efficient manner. By allowing contracts to run in “native code” such as Rust, rather than executing within the Cairo environment, we anticipate even greater efficiency and performance gains for Starknet.


Starknet’s previous Pythonic Sequencer introduced the parallelization of transactions, which significantly improved its performance. However, it’s important to note that the Sequencer initial implementation in Rust, included in the V0.12.0 release, does not yet include parallelization. The ongoing development efforts are focused on parallelizing transaction execution within the block, in the spirit of block-STM. Drawing from the successful demonstrations in the Pythonic implementation, this optimization will further enhance the throughput of Starknet, enabling it to efficiently handle increased transaction volumes.

No More Pending Transactions

In previous versions, the `PENDING` status denoted valid blocks that were executed by the Sequencer but were not yet full, indicating additional transactions could still be added. However, in this latest release, the `PENDING` status has been replaced with ACCEPTED_ON_L2, reflecting the finality status of transactions. This change simplifies the transaction confirmation process and provides users with a smoother experience.

get_block_hash Syscall

Another addition in Starknet Alpha V0.12.0 is the introduction of the `get_block_hash` syscall. This new system call allows developers to retrieve the hash of a specific Starknet block within the range of `[first_v0_12_0_block, current_block-10]`. The signature of this syscall is `fn get_block_hash(u64 block_number) -> felt252`.

The error message associated with this scenario is: `Block number out of range`.

To implement this change, the operating system will write, at the beginning of every block, a mapping under `address = 0x1` with `current_block — 10` as the key and its corresponding hash as the value.

With the `get_block_hash` syscall, developers can conveniently retrieve block hashes, which are essential components for constructing and validating storage proofs. These proofs enable efficient cross-chain data access and enhance the trustworthiness of blockchain data even without the need for reliance on third-party oracles. By obtaining the block hash through this syscall, developers can accurately reference a specific block’s state, transactions or any other information committed in the block header

Cairo — Improved Contract Syntax

In this version we’re introducing significant improvements to the smart contract syntax. The new syntax focuses on safety and lays the foundations for extensibility. Safety in this context means being more explicit on the external-facing components of the contract (interface/storage/events), which gives developers a better idea of what to expect when interacting with the contract. Extensibility, which will be finalized in a later version, allows contracts to use components from external libraries. This is a key feature of any smart contract language and will address a significant issue in the Starknet dev community. For an exhaustive treatment of the motivation and changes, see the Cairo Roadmap blog post and the community forum post.

While the new compiler version includes breaking changes, you can keep using the older compiler version (v1.1.0) and deploy the resulting contracts on Starknet for the next six months. This reflects our new compiler upgrade protocol for breaking changes: following new compiler versions, contracts compiled by the old compiler version will continue to be accepted for at least six months, in order to allow the community to adjust. Of course, Once a Cairo contract (not Cairo 0) is declared on Starknet, it will remain available for deployment and interaction indefinitely.

What’s next?

Short-Term Goals: Version 0.12.1

In the short term, Starknet is focused on enhancing user experience and transaction reliability. The next version, 0.12.1, will introduce another significant improvement: the inclusion of failed transactions in the block. Up until now, failed transactions were not included in the block, and thus the Sequencer could not charge a fee and advance the nonce for them. This created UX problems for developers. They could not rely on the nonce advancing, forcing them to continuously monitor transaction status before sending a new one. This change also protects the Sequencer from users spamming the system with failed transactions without paying for them. This update aims to provide users with a smoother and more seamless experience when interacting with Starknet.

Long-Term Vision: Throughput, Latency, and Costs

Looking ahead, Starknet’s overarching vision is to achieve substantial scalability both in scale and cost. The next priority on the agenda is to reduce transaction costs dramatically.

By driving down costs, Starknet aims to make transactions more affordable and inclusive, thereby enabling a broader range of use cases and empowering developers and users. The commitment to cost reduction aligns with Starknet’s mission to provide a scalable, flexible, and cost-effective infrastructure for decentralized applications.

Starknet Alpha V0.12.0 Vote

Starknet Governance Phase 1 focuses on major Starknet protocol upgrades.
Every major Starknet version upgrade is first deployed on Testnet, giving the Starknet community a few days to examine and test the upgraded version. During this examination period, a Snapshot proposal is opened, allowing the community to vote on whether to approve the upgraded version for Mainnet deployment.

If the proposal gains a majority of ‘YES’ votes during the voting period, it passes, and Starknet Mainnet will be upgraded accordingly.

The Starknet Alpha V0.12.0 vote is just around the corner!
Everyone is invited to sign up for the notification service on Starknet’s Snapshot space. Check out the Delegate Profile Thread & the Delegation discovery to either become a delegate or select one, and disscuss Starknet alpha v0.12.0 proposal on the Community forum.


Starknet Alpha V0.12.0 focuses on enhancing performance and user experience. The new version introduces a Rust-based implementation of the Sequencer, improving throughput by 10X and reducing transaction latency. Other features include a new compiler version, removal of the pending transaction status, and the addition of a block hash syscall.

Starknet developers are empowered to code solutions that make a difference. Start your Cairo development journey, read the Cairo docs, register for Cairo Basecamp, or go through the tutorials. Want to stay up to date with all version updates? Sign up for our Staknet Developers Newsletter.

About LambdaClass

LambdaClass is an engineering-centered company with 10 years in the industry working in distributed systems, compilers, ML and cybersecurity. Throughout their history, they’ve supported projects that offer technical challenges and that make a difference in the world, choosing projects and partners mainly on the basis of shared goals and approaches with their creators or founders

Starknet Quantum Leap: Major Throughput Improvements are Here! was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cairo Roadmap: Join the Ride

Time to migrate from Cairo 0!


  • Cairo continues to evolve. For the community’s convenience, we’ve created a public board describing the cool features ahead
  • A new contract syntax will be launched soon along with Starknet alpha v0.12.0, requiring minimal code changes and significantly enriching the smart contract language
  • With Cairo 1.1.0 on Starknet Mainnet, and v2 arriving to Starknet soon, we have reached an important milestone in the maturity of the language. Between the docs, book, and the Starknet discord, you should have enough resources to get going and migrate from Cairo 0


Cairo v1 has evolved significantly since its early alpha days, reaching feature parity with Cairo 0, and accumulating new features on top (basic loops are now available, and many more capabilities are underway). Our goal in this post is to shed more light on Cairo’s short-term roadmap: what is currently being worked on and what developers can expect in the coming weeks and months. In the future, you can stay up to date with the latest developments or plans for the language by tracking the cairo-roadmap board on Github.

Why Cairo?

Alongside the major advances in the high-level language, we think it’s important to emphasize the fundamental benefit of Cairo, and why we think it’s the foundation of future of blockchain scaling.

From its inception, Cairo was designed with the sole purpose of being the most efficient language for writing provable programs. The architecture of the Cairo VM, as described in the original paper, was designed for efficiently generating STARK proofs for Cairo programs execution, making it the ideal foundation for Validity Rollups. Cairo v2, the new rust-like language we have today, is built on these foundations, but designed to serve a wide community of developers, in terms of ergonomics, safety, and ease of learning and writing. The evolution that Cairo went through in the past two years, turned it from a niche low-level language into a high-level developer-friendly language, that provides an edge when it comes to proofs and scaling efficiency.

Just Say Cairo

Say “Cairo 1 — compiler version vX.Y.Z” no more. From now on, just say Cairo. Yai!

With the new Cairo compiler, we’re following the semantic versioning standard; that is, compiler versions consist of three digits, and a change in the most significant digit denotes breaking changes. With the next Cairo version, we have breaking changes in the smart contract syntax (described later in the post), so the correct thing to do is to bump the version to Cairo v2. To avoid cumbersome notation, we’ll stop saying Cairo 1, and from now on, identify the language’s version with the (only) compiler version. The original language, which could still be used in the future in different contexts outside Starknet, will be referred to as “Cairo 0”.

What’s Next for Cairo?

In the following sections, we go over the upcoming major developments in the language, and explain how they affect the developer experience in Cairo.

Upcoming Features

While feature parity with Cairo 0 was an important milestone, it is definitely not the final destination. The high-level language can always be improved, and many more features are on the way. You can check out the roadmap to see features that are being worked on and track the backlog. A few notable mentions are:

  • Components: the next phase in the new contract syntax, allowing contracts to import components defined in external libraries.
  • Keccak and Secp-k1: Already included in Cairo v2, these will allow verifying Ethereum signatures on the upcoming version of Starknet.
  • Signed integers support.
  • Secp-r1 curve operations: This will allow using native hardware to sign transactions, which will result in a much simpler UX for interacting with Starknet.
  • Strings: A native type for (long) strings, allowing standard string manipulation. This is a basic feature, which is also in high demand from NFT and gaming projects.
  • Iterators: these will allow us to enrich the loop syntax, and iterate over arrays/spans much more conveniently.

Cairo v2 — New Contract Syntax

The current syntax of Starknet’s smart contract mostly inherits from the previous Cairo 0 design. This design suffers from a few issues that we would like to address. Our goal in moving to a new syntax is to increase safety by making the contract’s behavior more explicit. By introducing more structure to the contract’s external functions, storage, and events, we can significantly decrease the probability of bugs. This will help protect protocols against potential hacks and loss of funds. In addition, the new syntax allows us to introduce extensibility, a feature highly requested by the community, that allows developers to easily use components written in external libraries.

The new syntax requires breaking changes. While we opt to avoid breaking changes as much as possible at this stage, after internal and community discussions we concluded that this is the right path that will pay dividends in the future.

These changes are discussed at length in a more technical post that was published in the community forum (refer to it for a comprehensive overview of the upcoming changes). Here we’d only like to emphasize that only the “outermost layer” of your contract (definition of external functions and events) needs to be modified. Your existing Cairo v1 code only requires minor adjustments (see the docs for a quick migration guide). The benefit of the new syntax, on the other hand, is highly significant: Using components from external libraries (a critical feature when working on large projects) will become mundane, and will no longer require ad-hoc workarounds.

Backward Compatibility Guarantee

Some of the upcoming changes described in the post (in particular, the new contract syntax) will mean breaking changes in the language. While, following Cairo v2, the bulk of breaking changes is behind us, committing to backward compatibility from this point onwards is still early. That said, projects developing smart contracts on top of Starknet require stability and careful auditing, and this presents an important consideration for us. To address these concerns, we provide the following guarantees for stability:

  1. Any class declared on Starknet will continue to work as before, and will be unaffected by changes in the language
  2. Any contract deployed on Starknet will continue to work as before, and will be unaffected by changes in the language
  3. For every breaking language upgrade, contracts written in the previous version will continue to be declarable on Starknet for a period of at least six months.

For example, if you’re developing your project (or are near deployment / during the audit phase) with Cairo version X, and Cairo Y is released with breaking changes, contracts written with version X will still be accepted on Starknet for at least six months. That is, you have a period of at least six months to get your contracts deployed on Starknet, at which point they’re forever protected by points 1 & 2.

When Should I Migrate?

With the new contract syntax released (and made available on Starknet in the upcoming v0.12.0), and the bulk of breaking changes behind us, Cairo is now stable and rich enough to support complex applications, and to port existing Cairo 0 logic. Additionally, the backward compatibility guarantees on Starknet ensure that even if there are breaking changes in the language, you will have enough time (at least six months) to finish developing or auditing and deploying your contracts.


Cairo continues to evolve and has reached a point where it greatly bypasses the original language. If you haven’t already, now is the time to get involved. We welcome the developer community to actively participate in the discussions, either directly on the compiler repo by raising issues, or posting in the cairo discord channel or the Starknet community forum. Hopefully, this post (alongside its more technical counterpart) helped shed some light on expected changes and remove much of the doubt about the future of Cairo.

Cairo Roadmap: Join the Ride was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Moving from Solidity to Cairo

Guiding Devs through the Expansion into Cairo Programming


  • Developers are expanding their skills to include Cairo, driven by Starknet’s increasing prominence.
  • Solidity enabled globally interoperable smart contracts but required extensive computation repetition.
  • Cairo’s efficiency stems from its ability to create verifiable transaction execution proofs using a single machine.
  • Both Cairo and Solidity are smart contract languages, but their functionalities and principles are distinct.


With the growth of Starknet (and continued excitement around rollups), Cairo has become one of the most in-demand skills in web3.

Cairo — which is used for writing smart contracts on Starknet and StarkEx as well as scaling applications such as dYdX and ImmutableX — has seen its number of full-time developers increase by a staggering 875% over the past two years and by 83% year-on-year. And since Cairo can be used outside blockchains whenever any proof of computation is required, adoption of Cairo by developers is expected to only rise.

Many of these new Cairo developers are moving over from Solidity — the smart contract language on Ethereum. If you’re one of the developers making this move, we’re here to help!

In this article, we’ll give you a developer’s guide to moving from Solidity to Cairo. We’ll talk about what makes Cairo different, how Cairo works from a technical perspective, and then look at some code examples to show the key differences between the languages.

Let’s get started!

What Is Cairo?

Cairo is the Rust-inspired, native smart contract language for Starknet.

According to the Cairo docs, “Cairo is the first Turing-complete language for creating STARK-provable programs for general computation.” Let’s break that definition down.

Turing-complete means this programming language can simulate a Turing-complete machine. A Turing-complete (named after Alan Turing) machine is a computer that can perform any computation and execute any algorithm if given enough time and resources.

STARK-provable means that programs written in Cairo can be executed so that a STARK proof of the execution can be efficiently created. When a program written in Cairo is executed on any machine, a newly generated STARK (Scalable Transparent ARguments of Knowledge) proof is created that allows any independent verifier to succinctly verify the honest execution of the program — without having to trust the machine on which the program’s computations were performed.

Cairo 1.0 was just released this spring (replacing Cairo 0) and is already available on Starknet Mainnet.

Which Is Better — Cairo or Solidity?

Neither! In some ways, it is an “apples to oranges” comparison.

Solidity is the language first used for widely adopting composable computation — a programming paradigm in which different system components can be used in sync and composed into complicated software by using different components as Lego blocks.

Solidity made it possible for smart contracts to be intricately intertwined due to the following:

  • Byte code that was made public and transparent to the world
  • Standard ABI structures (that allowed others to interact with external smart contracts)
  • Use of the Ethereum network to have an almost 100% liveness (or uptime)
  • Use of the Ethereum network as a means of executing financial transactions
  • Global interoperability of smart contracts due to a single common EVM (a copy of which is held by all the validators in the network)

Even though Solidity achieved a myriad of firsts by being the most widely adopted smart contract language, Cairo has a single overpowering property: its ability to create provable programs for general computation.

This single differentiating property allows us to move from a system where every computation has to be repeated hundreds of thousands of times (that’s the number of validators in the Ethereum network) to a newer system where only a single machine (called the prover) creates a proof of correct execution of a transaction that others on the network can verify.

Differences Between the Cairo Virtual Machine and Ethereum Virtual Machine

For Cairo programs’ execution to be efficiently converted into a STARK proof, there are a few key differences between the Cairo virtual machine and the EVM (Ethereum Virtual Machine):

  1. Memory Model. The Cairo VM uses a single-write-only memory model. A memory slot cannot be overwritten (unlike the EVM). Even though this may seem like a highly complex overhead, the Cairo compiler solves this problem, and the abstracted version allows mutable variables to be used in code (more on this later). The single-write memory model makes Cairo a more predictable and verifiable system. Each memory address is written only once, and it retains its value until the execution of the program is complete. This means there’s a clear, unchanging record of the computation, which is vital when generating STARK proofs, as they rely on verifying the correctness of computations.
  2. Fields. When we talk of cryptographic proofs, we almost always speak of these proofs being created for operations on elements of a certain field. As discussed in our article on arithmetization, in mathematics, a field is a set of elements with two binary operations, addition, and multiplication. It satisfies certain axioms, such as closure, associativity, commutativity, and the existence of inverses and identity elements. Examples of fields include real numbers, rational numbers, and complex numbers. The elements of such a field are the subjects of operations that are part of any provable general computation. When discussing fields, it is important to note that some fields are finite (the one used in Cairo is also finite). In a finite field, the number of elements is finite, and all the elements are less than the highest “order” of the field. The “order” of a field equals the highest number that the elements of a field can attain plus one. Also, all addition and multiplication operations result in a number, the module of the highest order. So, for example, in a field of order 6, the addition 3+4 would result in (3+4) mod 6 = 7 mod 6 = 1. Cairo uses a finite field of order 2²⁵¹ + 17 * 2¹⁹² + 1. Since, while generating proofs, all the elements need to be field elements, the Cairo VM uses field elements as the base for all the operations. It does not follow the conventional system of uint256 or uint32 as the EVM does. However, abstraction techniques can be created to use the more convenient uint256 type (or similar). However, these structures require more resources (increasing the number of operations proving the same in order of tens) for execution.
  3. Inheritance and Polymorphism. Cairo does not have the concepts of inheritance and polymorphism. Though contracts can be extended by importing specific functions and storage variables, the much-used concepts of object-oriented programming require a bit of “out-of-the-box” thinking.

Cairo Compiles to Sierra

One step to be aware of is that when you write a Cairo smart contract, it is first converted into Sierra code, which must be published on the network. Sierra code is an abstraction over the raw Cairo assembly (CASM) code interpreted by the Cairo VM. The compilation of Cairo code to Sierra surrounds the Cairo code with some security measures, the most important of which is a mechanism to avoid DoS attacks.

According to Starknet documentation, “A crucial property of every decentralized L2 is that the sequencers are guaranteed to be compensated for work they do. The notion of reverted transactions is a good example: even if the user’s transaction failed mid-execution, the sequencer should be able to include it in a block and charge execution fees up to the point of failure.”

However, sometimes a user may write a line of code or include a transaction, proving the execution is impossible. For example, the statement `assert 1 == 0` is a valid Cairo statement; however, including this execution in a cryptographic proof is not possible since this statement is false, and it translates to polynomial constraints that are not satisfiable. Hence Sierra adds a security layer that ensures even unprovable reverted transactions are charged for. This both mitigates the potential of a DoS attack on the sequencer and satisfies the economic incentives of the sequencer.

Comparing Cairo to Solidity

Now we have an idea of Cairo’s basic types, functions, and structures. Let’s compare those with their Solidity counterparts to draw a few parallels between the two smart contract languages. (Keep in mind that Cairo can also be used to write non-smart contract code that can be used for creating provable programs. However, that is out of our current scope of discussion.)

Note: From this point onward, all discussion regarding Cairo concerns Cairo 1. Cairo 0 is no longer recommended as the go-to language for writing smart contracts on Starknet.

Cairo Types

Here is the list of some fundamental types in Cairo:

As you can see in the list above (we just added signed integers and we also have Dict.), starting from Cairo 1, unsigned integers have been added to Cairo, similar to their counterparts in Solidity. Even though using integers may be less cost-effective for the sequencer than directly using felts, integrating integers into Cairo promises to simplify developers’ lives.

Other than that, using Arrays is very similar to the syntax in Rust, and they are similar in logic to those in Solidity.

Functions in Cairo

Functions in Cairo can be of the following types:

  • internal
  • external
  • view
  • constructor

By default, all contract functions are considered internal (such functions can only be called from inside the contract — somewhat similar to private functions in other languages).

External functions are open to the world and can be called by other smart contracts as well — including accounts. (Hooray, account abstraction!)

View functions are a type of external function that can only read the state on-chain. View functions cannot modify the state of the chain.

Constructor is another attribute of functions in Cairo given to … constructors of a smart contract!

Now, let’s compare the syntax of function declaration between Cairo and Solidity:

Let’s look in more detail at a few key differences:

  1. The keyword to declare a function is `fn` in Cairo, while it is `function` in Solidity.
  2. The function types are declared before the function keyword in Cairo (#[view]), but in Solidity, the format is different (see above).
  3. In the Cairo programming language, the syntax for declaring return values involves using the `→` symbol. On the other hand, in Solidity, the keyword `returns` is used to denote return values.

Modules in Cairo

Modules in Cairo serve the purpose of grouping related functionality within a namespace. The keyword `mod` is used to define a module, followed by the module name and a code block that includes functions and other declarations. Modules can import other modules and make use of their functionality.

These are similar to libraries in other languages, and in Solidity, modules can be compared to the inheritance of contracts.

For example, in the above code, `starknet` and `array` modules are imported. The syntax differs from `import` statements in Solidity or inheritance which uses the `is` keyword (see this). Note that the `use` keyword makes all functions from the imported module accessible within the importing module in Cairo.

Arrays in Cairo

Using arrays in Cairo 1.0 has become easier since manipulations of the dynamic array are made possible with the array module’s exported functions such as `append,` `array_at,` and `array_len.`

Sample Cairo Smart Contract

Now that we understand the set of types and functions in Cairo, let’s go over a sample Cairo ERC20 contract code. An ERC20 contract is a standard template smart contract for the tokens that people own on-chain. It allows the users to transfer tokens to one another, check balances for users, and approve transfers to another entity. Here’s our contract:

Note: The Cairo 1 syntax is changing slightly and will be updated later this year (2023). Please see this post for more details.

Above code is based on

Let’s look in detail at some of the most important pieces.

Lines 1 and 2 initialize and give the name to the smart contract


mod ERC20 {

Line 4 imports `get_caller_address` function from `starknet` module. The get_caller_address() function returns the address of the contract that called the function.

use starknet::get_caller_address;

Lines 7 to 14 define a structure (similar to `struct` in Solidity) that is used later in the code.

Lines 20 and 21 define an event Transfer that is emitted whenever the ERC20 token is transferred. Events provide an efficient way to track contract activities/state changes, thus allowing external listeners to react accordingly.


fn Transfer(from_: felt, to: felt, value: u256) {}

Lines 36 to 54 contain a constructor function (the function that is called when contract is deployed) and a view function that reads the `name` storage variable and returns its value to the user.

Lines 97 to 101 define an external (discussed earlier) function that is used to transfer ERC20 tokens from one account to another. This function calls the `transfer_helper()` function underneath that also emits the Transfer() event defined above.


If you are comfortable with Solidity, you should now have a great start to understanding how Starknet works, the differences between Cairo and Solidity, and how to read basic Cairo smart contracts.

For the next step in your Cairo development journey, refer to the Cairo docs, register for Cairo Basecamp, or go through the tutorials.

Cambrian Explosion of Cryptographic Proofs

Cryptographic proofs validate computations and improve transaction integrity in blockchain networks.

The transformative potential for scalability, transparency, and privacy


  • Cryptographic proofs validate computations and improve transaction integrity in blockchain networks.
  • Layer-two (L2) blockchains use cryptographic proofs for scalability by generating verifiable proofs of aggregated transactions.
  • Zero-Knowledge Proofs (ZKPs) verify truth without revealing extra information, but their use for privacy varies.
  • Cryptographic proofs involve technical aspects like arithmetization and low-degreeness enforcement.
  • With blockchain technology’s maturation, one type of cryptographic proof is likely to become dominant, promoting scalability, transparency, and privacy.

Note: This article is based on a talk by Professor Eli Ben-Sasson, co-founder and president of StarkWare, at the 13th Bar Ilan (BIU) Winter School on Cryptography. The BIU Winter School focused on recent advances in cryptography and blockchain technology. The lecture given by Professor Eli Ben-Sasson can be found here.

Integrity was defined by C.S. Lewis as the act of “doing the right things even when no one is watching.” In the context of blockchains, cryptographic proofs are used to ensure the exact same thing — making sure that some computational processes were done right even when no one was watching.

In this article, we’ll look at cryptographic proofs — what they are, how they are used in blockchain, and some of the significant differences between implementations. Let’s start with a definition.

What are cryptographic proofs?

Cryptographic proofs are a set of mathematical and cryptographic protocols that can be used to assert the integrity of computations.

A beautiful example of the kind of things that cryptographic proofs can do is described in the fundamental 1991 paper titled “Checking Computations in Polylogarithmic Time” by L. Babai, L. Fortnow, L.A. Lewin, and M. Szegedy, the authors presented a protocol in which “a single PC can monitor the operation of a herd of supercomputers with powerful but unreliable software and untested hardware.” This means that a machine with limited computational capacity can assert the integrity of computations made by a set of computers with far greater computational power, even if the party controlling those computers is malicious, or incentivized to misreport the output of those computations.

How are cryptographic proofs used in blockchains?

The past decade has witnessed a Cambrian explosion of semi-practical and practical proof systems, with various applications that ensure privacy, security, and integrity of computation. And, although integrity is needed in web2 as much as its needed in web3, for various reasons all products that use general purpose cryptographic proof systems can be found within web3, on blockchains, due to the open and transparent nature of blockchains and their preference for mathematical integrity over human-based integrity. To understand how proofs help scale blockchains we need to first recall how blockchains work.

Today, when we send a transaction on a blockchain like Solana, Ethereum, or Cosmos, each and every validator in the network receives the transaction and executes it. This quickly becomes inefficient. As decentralization grows, the compute resources used for including every transaction in the network’s history increases linearly with the number of active validators.

Several projects (such as Aztec, Starknet) aim to solve this scalability problem using cryptographic proofs. They are known as Layer 2 Validity Rollups because they sit on top of the Layer 1 blockchain (e.g Ethereum). The idea behind these L2 rollups is that they rely on cryptographic proofs to confirm the integrity of computations done off-chain, and the validity of updates to state and transaction sets. The ability for a long computation to be verified to have been executed with integrity represents a fundamental paradigm shift in throughput for distributed networks. Instead of naively re-executing each computational step, a network of many machines can simply verify them. There is no need for supercomputers — these can be regular weak computers.

This verification of the integrity of vast computations is performed by the reliable nodes of the Layer 1 network (such as Ethereum). In this case, and using the prophetic words of the 1991 paper mentioned above, the validators in the L1 network take the role of the “single reliable PC,” and the L2 prover is a supercomputer of sorts that, remarkably, achieves utter integrity and reliability despite being executed on untested hardware and possibly unreliable software.

The Cambrian explosion of cryptographic proofs is about the ever-increasing usage of these systems in blockchains, and the proliferation of different cryptographic protocols that implement these proofs. Below we can see a visualization of many projects currently being used in web3.

Chart showing what cryptographic proofs are used by currently live L2 blockchains

The above projects use only a tiny fraction of cryptographic proof systems that are known to us (at least in theoretical implementations).

Chart showing which of the most commonly known cryptographic proof systems are used by blockchain-based projects. The ones in use are colored in a light yellow shade. The cryptographic proof systems not used prominently in the blockchain space are in the white boxes.

Comparing Systems

Because there are so many options, it’s important to understand the pros and cons of each implementation. Many of the details are highly technical, but understanding them is important to understanding which ones may lead to the next generation of blockchains and L2s.

Zero-Knowledge Proofs: Scalability versus Privacy

You’ve probably heard (quite often) projects throwing around the term “Zero-Knowledge” proofs (or ZKPs). For all the catchiness of the phrase, and the potential of zero-knowledge proofs for privacy preserving blockchains, most web3 L2 validity rollups do not use proofs that have the cryptographic property known as “zero knowledge”, but rather rely on the scalability attributes of cryptographic proofs. Let’s talk briefly about privacy and scalability in cryptographic proofs.

ZKPs are proofs that allow a party to verify that a particular computation was executed correctly, without revealing the inputs that were consumed by that computation (e.g., passwords, financial details of transactions, medical data, etc.) As a result, on top of a significantly reduced cost of verification (inherited from the properties of cryptographic proofs), we gain privacy.

It’s important to understand exactly what a project means when they say they use ZKPs. While most blockchain-based projects built on cryptographic proofs claim their technology is “based on ZKPs,” in reality, their solution has no privacy considerations in play.

In a modified visualization of the above image, we can see that most of the projects are more focused on scalability than privacy.

A chart displaying that only four of the 16 most advanced projects built with cryptographic proofs on blockchains are concerned only about privacy.

Let’s next explore three more technical concepts all of the proofs use: arithmetization, enforcement of low-degreeness, and cryptographic assumptions.

What is arithmetization?

When looking at a set of computations that a system needs to prove, it makes sense to convert these computational problems into algebraic problems. Arithmetization in cryptographic proofs refers to the process of representing mathematical concepts and operations using arithmetic operations on finite fields.

At a high level, this means representing any statement as an algebraic equation, i.e., a polynomial. The process of converting computational problems into such algebraic problems is known as a “reduction” in the lingo of computer science, and an illustration is given in the following figure.

The reason arithmetization helps with scalability is that we can boost the likelihood of catching a breach of integrity once things are phrased with algebra and polynomials. To understand the magic of polynomials and their usefulness in proofs, best to work out the STARK 101 course or read this post.

Surveying the different proof systems out there, one differentiating factor is the way they perform arithmetization. Some may use modular arithmetic over integer rings (RSA rings), others may use elliptic curves and/or more complex methodologies (lattice-based cryptography, code-based cryptography, and multivariate polynomials).


All cryptographic proof systems have some form of low-degreeness enforcement, which is a crucial differentiating factor among them.

Low-degreeness enforcement refers to the process of ensuring that the polynomials (algebraic equations that are generated as part of the arithmetization process) are of a degree less than a certain threshold. (Just a reminder that the degree in a polynomial is equal to the largest power of a term appearing in it.)

Low-degreeness enforcement is necessary for integrity and security. As described above, the probability of erroneously accepting a false proof is related to the degree of polynomials chosen. Moreover, low-degree polynomials are used in these systems because they have some nice mathematical properties that make them more efficient.

A polynomial commitment scheme (PCS) is a cryptographic protocol that allows for efficient and verifiable computation on polynomials. It enables one party, called the committer, to commit to a polynomial without revealing its full details, while another party, called the verifier, can later verify the properties of the polynomial commitment.

Different proof systems use different PCSs to create and verify proof. STARKs and Risc0 use the Fast Reed-Solomon Interactive Oracle Proof (“FRI”) commitment scheme, while Groth16 and PLONK use the KZG commitment scheme. Generally, the differentiating factors between these commitment schemes are the cost of creating the proof, verifying the proof, and the size of the proof.

See the above image for the pros and cons of the different systems. The STARK proof system uses the FRI protocol to enforce low-degree polynomials. Under this system, the prover iteratively interacts with the verifier and commits to new polynomials such that the degree of each new polynomial is half the previous one. The PLONK system uses polynomial commitments based on elliptic curve mathematics (for example, KZG).

Moreover, some systems may require a trusted setup. A trusted setup is an arrangement under which specific secret parameters are to be generated. The challenge in these cases is that the pre-image of these parameters must remain private. If not, then the whole proof system is vulnerable, and the generation of a false proof becomes possible.

Generally, special trusted setup “ceremonies” are organized in which multiple parties privately create random elements combined to get the final parameters. If even a single party from these successfully destroys the random elements it submitted, then the setup can be considered secure.

Cryptographic Assumptions

Finally, any other cryptographic assumptions these systems use are also essential to track.

For instance, some of these uses rely on elliptic curve mathematics (such as BulletProofs and Halos) or “knowledge of exponent” (such as Groth16, PLONK, etc.), which are quantum-computer breakable.

On the other hand, others use collision-resistant hashes which are quantum-computer resistant (such as STARKs, ZKBoo, etc.).


As we can see from the above discussion, a vast array of cryptographic proofs can be used to achieve scalability and transparency (or privacy). While some proofs might be very convenient in use for short proofs (such as Groth16), some other systems are better off in large computations (such as STARKs, in the opinion of Prof. Ben-Sasson). However, as the ecosystem matures, we will see one type of cryptographic proof used extensively.

May the best system win!

Scaling Ethereum Efficiently

Validity Rollups, a breakthrough in scaling Ethereum.

Validity Rollups and the Role of the Cairo VM


  • Validity Rollups are the most promising way to increase Ethereum’s throughput in a secure and decentralized way; zkEVM and Cairo VM (CVM) are two types of VMs used in Validity Rollups.
  • zkEVM focuses on Ethereum compatibility, but sacrifices performance and scalability.
  • Cairo VM, used in Starknet, prioritizes performance and scalability over compatibility.

Rollups are the hot topic of the year when talking about scaling Ethereum. Out of the various types of rollups, we believe Validity Rollups (VRs), also known as zk-rollups, are the most promising way to increase Ethereum’s throughput in a secure and decentralized way. At the heart of this scaling solution, is the use of Validity Proofs for verifiable computation. Here’s how they work:

  • Instead of processing every transaction on Ethereum’s mainnet, operators offload transaction execution to an off-chain environment. This off-chain environment serves as a Layer 2, meaning a layer operating on top of Ethereum.
  • After processing massive batches of transactions, the Layer 2 operator returns the results to be applied to Ethereum’s state, along with a Validity Proof to verify the integrity of the off-chain execution. The proof guarantees that all transactions in a batch are valid, and is verified autonomously by the on-chain verifier contract. This allows Ethereum to apply the result to its state.
Validity Rollups

Note: Validity Rollups are often mistakenly referred to as Zero-Knowledge Rollups, but this is not accurate. Most Validity Rollups do not use ZKPs and are not utilized for the purpose of ensuring privacy. Hence the term “Validity Rollup” is more accurate.

The Off-Chain VM

Before proceeding, the first question we need to answer is: What is a virtual machine (VM)? Put simply, it is an environment in which programs can run, like a Mac running a Windows OS. It transitions between states after performing computations on some inputs. The Ethereum Virtual Machine (EVM) is the VM that runs Ethereum smart contracts.

A Zero Knowledge Virtual Machine (zkVM) is a program execution environment that, along with the program outputs, allows for the generation of a Validity Proof that can be easily verified. This Validity Proof proves that the program was executed correctly. When the term “zkEVM” is used, it generally refers to a rollup that utilizes the Ethereum Virtual Machine (EVM) and is capable of proving EVM executions. This terminology can be misleading because the EVM itself does not generate these proofs; instead, the proofs are generated by a separate prover mechanism that takes the results of EVM execution as its starting point. Also, these proofs are about validity, not privacy, hence they are not exactly Zero-Knowledge Proofs. Nevertheless, for consistency, we’ll stick with the conventional term “zkEVM” in this writeup.

While all Validity Rollups aim to harness Validity Proofs to scale Ethereum, they differ in their choice of VM to execute transactions off-chain. Many Validity Rollups chose to replicate the design of the EVM (and are thus called “zkEVM rollups”), attempting to replicate Ethereum on the L2 rollup. Starknet uses a new VM — the Cairo VM (CVM) — which was designed specifically to optimize Validity proof efficiency.

Both these approaches have their own advantages and tradeoffs, but zkEVMs trade performance for Ethereum compatibility, and the Cairo VM prioritizes performance over compatibility, prioritizing scaling capabilities.

The zkEVM Approach

A zkEVM is a Validity Rollup with the goal of bringing the Ethereum experience fully to Layer-2 blockchains. It aims to replicate the Ethereum developer environment as a rollup. With zkEVMs, developers would not need to change their code or abandon their EVM tools (and smart contracts) when writing or porting smart contracts to more scalable solutions.

One major drawback of this approach is that it reduces the scaling potential of Validity Proofs. zkEVMs are slower and more resource-intensive due to their commitment to compatibility with Ethereum. The EVM was not designed with proving efficiency in mind, unlike the CVM. This restricts the use of optimizations that could improve efficiency and scalability, ultimately affecting the system’s overall performance.

Provability of the EVM

The central challenge with the zkEVM approach is rooted in the EVM’s original blueprint — it wasn’t designed to function within a Validity Proof context. Consequently, efforts to mirror its functionality fail to unlock the full potential of validity proofs, resulting in less-than-optimal efficiency. Such inefficiency ultimately weighs down the system’s overall performance. The EVM’s compatibility with Validity Proofs is hindered by the following factors:

  • The EVM employs a stack-based model, whereas Validity Proofs are more effectively employed with a register-based model. The stack-based nature of the EVM makes it inherently more difficult to demonstrate the correctness of its execution and provide direct support for its native toolchain.
  • The Ethereum storage layout relies heavily on Keccak and a large Merkle Patricia Tree, both of which are not Validity Proof-friendly and impose a substantial proving burden. For example, Keccak is very fast for the x86 architectures (over which we usually run the EVM), but takes 90k steps to prove (with a special build built-in). While Pedersen (a zk-friendly hash function) takes 32 steps. Even with recursive compression, the use of Keccak in a zkEVM means high prover resources which end up being paid by the user.

As a result, various zkEVMs aim for different levels of support for Ethereum tooling– the more Ethereum compatible a zkEVM is, the less performant. (For more info on zkEVM types, skip to the end of the post.)

The Cairo-VM Approach

zkEVM solutions invest substantial development time in “making the EVM work for Validity Rollups”, prioritizing compatibility over long-term performance and scalability. There is another option: use an entirely new, dedicated VM, and add support for Ethereum tooling as an additional layer on top. This is the approach taken with Starknet, a permissionless Validity Rollup launched in November 2021. Starknet is the first Validity Rollup to offer a general-purpose smart contract platform on a fully composable network.

Starknet uses the Cairo-VM (CVM), with a high level language of the same name. The Cairo-VM is a VM designed for efficient generation of Validity Proofs for programs’ execution.

With Cairo (the VM and language), we have:

1. Optimized validity proofs — every instruction has an efficient algebraic representation

2. A modern rust-like language for writing provable programs

3. An intermediate representation (Sierra) between high level Cairo and Cairo assembly (VM instructions) which allows efficient execution of Cairo code

Developing a new language allows one to tailor it to the specific needs it is intended to meet, as well as equip it with features that answer previously unmet needs.

Cairo and Coding Pluralism

In order to create a Validity Proof about some computation, first this computation must be expressed as a sequence of mathematical constraints describing the computation. This process can be very tricky due to the challenge of optimizing computations for efficiency, and the need for specialized tooling.

The Cairo language was initially designed to simplify this task and make it easier to add features and complex business logic to StarkEx. Cairo programs are compiled into algebraic machine code — a sequence of numbers — that a single, fixed VM executes. With Cairo, the whole complexity of generating mathematical constraints describing the computation — a thorny issue for Validity Proofs — is abstracted away and captured by the fixed set of constraints (less than 50 constraints in total). As a result, developers can leverage Validity Proofs to scale their apps without needing to understand the underlying math and infrastructure, by writing code in a syntax they are familiar with.

Starknet is all about innovation and this is reflected in its pluralistic approach to code. Cairo’s power to get the best scaling using STARKs is not limited to those who write their contracts natively in Cairo. Developers can opt for an approach that suits them best:

  • Code natively in Cairo: With the release of Cairo 1.0, developers now have access to an ergonomic and safe Rust-inspired language which makes writing program logic much easier and less error-prone.
  • Solidity-compatibility: Solidity developers can write code that can be used by the Cairo VM. This method offers a similar developer experience to Ethereum and makes Solidity smart contracts portable to Starknet. There are two ways of achieving this:
  • Transpiling: Transpiling refers to the process of converting source code written in a programming language to another language. The Nethermind team has created the Warp transpiler, for transpiling Solidity code into Cairo. Warp makes Solidity smart contracts portable to Starknet, effectively making it a Type 4 zkEVM. It has already been used to transpile and deploy Uniswap contracts with only minimal changes.
  • zkEVM on Starknet: The Cairo VM can be used to prove the execution of another VM. Kakarot is a zkEVM written in Cairo, that can be used to run Ethereum smart contracts on Starknet. The Cairo VM and zkEVM aren’t competing approaches and instead of choosing between Cairo VM and zkEVM, we can have both!

Despite being around for a short time, Cairo is the 4th most popular smart contract language by TVL and already secures over $350M.


A zkEVM aims to replicate the Ethereum environment as a rollup and allows developers to use familiar Ethereum tooling. However, this approach inhibits the full potential of Validity Proofs and can be resource-intensive.

The Cairo VM is designed specifically for Validity Proof systems, without being constrained by the EVM’s limitations. It is supported by a new, safe and ergonomic Rust-inspired programming language, called Cairo 1.0, forming a powerful tool, designed to gain maximum efficiency from using STARK Proofs for scaling Ethereum.

It’s exciting to see the track record that Cairo achieves week by week, as well as the growth of different options for developers, such as the Kakarot zkEVM and Warp. As Starknet dApps enter production, demonstrating Cairo’s power, we’re confident it will be used for ever-more ambitious projects in the future.

As a result of the three routes to STARK scaling outlined above, and doubtless others that will be offered in the months to come, developers now have previously unimaginable control over scaling blockchains.

Types of zkEVM

Vitalik categorizes zkEVMs primarily into four types:

Type 1 or fully Ethereum-equivalent: Do not change any part of the Ethereum ecosystem.

Type 2 or fully EVM-equivalent: Compatible with existing dApps, but make some changes to Ethereum’s design for faster proof generation.

Type 3 or almost EVM-equivalent: Support most EVM opcodes, but remove some features that are hard to implement in a zkEVM implementation (eg: precompiles, hash fucntions).

Type 4 or high-level language-equivalent: Take smart contract code written in Solidity / Vyper and compile that to a Validity Proof-friendly language.

Dynamic NFTs and Their Potential

From Static to Dynamic — How NFTs are Changing the Face of Digital Ownership


  • Dynamic NFTs are interactive tokens that change on-chain data based on events.
  • Current NFTs face challenges with static data or centralization risks.
  • Starknet enables dynamic, decentralized NFTs with reduced computation and storage costs.
  • Dynamic NFTs allow for innovative applications in gaming, music, and art.
  • The emergence of dynamic NFTs signifies an evolution in the NFT space, providing increased flexibility and adaptability.

If you’ve been following web3 for the past couple of years, you’ve probably heard of the Bored Ape Yacht Club — NFTs that have sold for hundreds of ETH. (The largest Bored Ape Yacht Club sale was made for a whopping $3.4 million.)

Bored Ape Yacht Club #8817

These JPEG images of pixelated characters are probably what comes to mind when you hear the word “NFT.” However, the concept of a non-fungible token is much more diverse than just JPEGs, and potentially much more powerful.

In this article, we’ll look at the concept of dynamic NFTs — NFTs that can change their on-chain data in response to an on-chain (or even real-world) event. We’ll look at a few current examples, some potential future uses, and then at how Starknet enables this new kind of NFT with its cheap computation and storage costs.

What Are Dynamic NFTs?

NFT stands for “non-fungible token,” a digital asset that represents ownership of some unique item/information. Creators can tokenize their works by representing them with NFTs. For example, tickets to events can be represented as NFTs, real-world assets such as real estate property can be bound to such tokens and become tradeable, and even music and movies can be captured as NFTs.

But these NFTs can still be considered “first generation” — the more interesting use cases have yet to be explored, and evolutions of the standard are being created.

One example of the future of NFTs is Dynamic NFTs — NFTs that can change the value they represent. For example, NFTs that represent an image can have the image change colors and shape or even attain a completely new appearance. Audio NFTs can evolve their audio in reaction to on-chain events.

Since all the data related to such NFTs is stored on-chain, these changes are transparent and can be tied to certain permissions or events. We’ll get into the details of how such a project might work later in this article, but first, let’s look at NFTs from a technical perspective and consider why most NFTs today can’t be dynamic.

The Current State of NFTs

Usually, when we talk about NFTs, we refer to the ERC-721 standard, which was formally created in 2018. The ERC-721 standard is a base interface for non-fungible tokens that declares a few of the functions that every smart contract implementing ERC-721 must support. (For those with no Solidity background, it is a kind of blueprint that defines how to interact with a contract/class, specifying functions but not their implementations).

Set of functions implemented by ERC-721

Whenever an NFT changes hands, the `transferFrom` function is called, which changes the owner of the NFT in the ledger. Similarly, when we check who owns a particular token, we call the `ownerOf` function.

Marketplaces like OpenSea rely on NFTs to support this standard in order to display tokens on their websites and transfer NFTs between buyers and sellers.

However, let’s look deeper at one of the BAYC NFTs: Ape #8817. If you visit the page on OpenSea, you’ll see the image associated with the 8817 Ape. However, where is this image stored? It’s not on-chain! Storing the whole image on the Ethereum mainnet would cost a small fortune in storage space, and considering that there are millions of NFTs on Ethereum, it’s not possible to store all those images on-chain.

Instead, what these smart contracts do is store all of their NFT-related data (i.e., “metadata”) on some URL that is accessible from the internet. The two main options for NFTs are keeping the metadata off-chain but on a decentralized storage solution such as IPFS (here is an example of the metadata related to Ape #8817), or storing the data on a centralized source like traditional cloud storage.

You may check the metadata for any BAYC token from its smart contract on mainnet

The first choice — IPFS — creates a fundamental constraint: the data becomes static. Since data, once stored on IPFS, cannot be modified, making any amendments to IPFS is impossible.

The second solution allows modification of NFT-related metadata but introduces the serious problem of centralization, which goes against the ethos of blockchain.

Hence, in this constant conflict of increased accessibility vs increased centralization, we end up with NFTs that stay “the same” even for use cases that need dynamic changes, such as gaming, SBTs, creator tokens, etc.

NFTs that get the benefits of both of these options — dynamic and decentralized — are needed. This is where dynamic NFTs come into play.

Dynamic NFTs Made Possible by Cheap Computation and Storage on StarkWare

Starknet is a validity rollup (commonly known as a zero-knowledge rollup) developed by StarkWare that uses cryptographic systems called STARKs to massively decrease computation and storage costs. Because of these savings, Starknet finally makes the concept of dynamic NFTs — dynamic and decentralized — a possibility.

Let’s look at how it works with an example.

The Carbon Protocol is a project that is a hub for carbon neutrality, from funding regeneration projects to managing companies’ net zero programs and reporting. Their strong commitment to decentralization and transparency led them to develop one of the first proofs of concept for “dynamic” NFTs, such that the metadata for the NFT is stored completely on-chain. Below is an example token of the NFT contract that Carbonable deployed.

As an experiment, I transferred a major chunk of this “value” to another address — and automatically, the metadata related to the token was updated. The image describing my token also changed, and as we can see below, the color of the text changed from golden to bronze. Note that this change has happened completely on-chain. This is the power of dynamic NFTs!

Unlike ERC-721’s, where the balance and ID of a specific token are used to understand the ownership of an NFT, for dynamic NFTs, the main information is the value stored in a token.

What this means is that whenever a user requests the value stored in the token, the value can change. This is implemented by declaring a simple contract (let’s call it the “metadata” contract) that handles both the dynamic and the static part of the NFT metadata. For a more superficial understanding, we can think of the “static” part as a short string that stores some property of the NFT.

On the other hand, the “dynamic” part is different because to return some information (for simplicity, let’s assume it also returns a string), it can run some code on the metadata contract. The code can be dynamic in the sense that the values it returns can change with different chain-specific parameters or the state of the contract itself. It would be possible to change the state of the contract upon external interaction.

Note that the metadata contract only has to be declared on Starknet; there is no need even to deploy it as such. Unlike Ethereum, Starknet distinguishes between a contract class and a contract instance. A contract class represents a contract’s code (but with no state), while a contract instance represents a specific class instance with its own state. When you declare a contract class, the code is stored on-chain, but there is no state to upkeep. Since the metadata contract does not necessarily have to have a state, simply declaring it is enough to run the code inside the functions which are called by the NFT contract.

The proof of concept deployed by the Carbonable team is completely decentralized since the SVG stored by the image has all the code deployed on the contract (see code here). This allows anyone to keep track of the changes made to the SVG. As soon as the token is transferred from one user to another, the token’s value can change, showing its ability to adapt.

Use Cases for Dynamic NFTs

This example deployed for testing purposes only opens the door to a vast array of possibilities, such as:

Images and animations. As the example above shows, amendable images can be stored on-chain. However, similar to that, animations can also be stored on-chain and can be modified with user interaction. Several teams are working on this right now with massive possibilities in the crypto-gaming space. For example, in the proof of concept project by Carbonable (that we mentioned earlier), the color of the text changes with the value stored in the token. So, if a user has a token with value > 1000, the color of the text can be golden, where it would be silver if the value is in the range of 100–1000.

Music and audio. When we listen to music or audio files, these files are often in a .mp3 or .wav format. This format of an audio file is “finite” in that there is no quick way to change a beat or a small part of the clip. Audio formats (like WAV or MP3) store actual sound data, while MIDI (Musical Instrument Digital Interface) files contain instructions for synthesizers or other devices to generate sounds.

Raphael Doukhan, the co-founder of Rosis Lab, worked on a proof of concept for generative music by storing a MIDI file as a JSON object on Starknet and allowed the file to be modified by external interaction. Some parts of the music file were constant (e.g., music structure, melody theme, etc.), and others were amendable (e.g., BPM, tension profile, keys, etc.). This proof of concept was a prime example of generative music where an artist’s work “is not a finite object anymore but just lives beyond the creator and beyond the creation.” For example, the beat frequency of the audio file can be changed as users interact with the file, and hence, the music would attain a unique characteristic upon new interactions.

Gaming, fantasy sports, and collectibles. On-chain games could harness the power of dynamic NFTs to make in-game changes to the environment, objects, and characters based on different gameplay.

For example, Realms, a multiplayer on-chain game on Starknet, is exploring the use case of dynamic NFTs to have on-chain character skins (and even music) that changes with the game.

In fantasy sports, character features could be upgraded/downgraded based on the player’s real-life performance (which could be retrieved from oracles). An example of this is LaMelo Ball’s ChainLink-powered NFT. After each game, the NBA player’s stats are brought on-chain using an oracle, and the fans can collect the player’s “talent” as tokens. There are 4 different categories of LaMelo’s NFTs: Red Mars, Blue Neptune, Silver Moon, and Gold Sun. They are all tied to different statistics of the NBA player. For instance, Red Mars is tied to the points scored, and Silver Moon is tied to assists made. Hence, each time LaMelo scores points or makes an assist, the value inside the respective NFT increases.

LaMelo Ball’s NFT

This idea can be incorporated in games so that skins of the characters become “cooler” as the player’s level increases, or the player’s achievements are shown on the NFT as medals and trophies.

Generative art. Art comes in many forms, some of which have been discussed above. However, the notion of art is wide open. OG:CR (Organic Growth: Crystal Reef) is a dynamic NFT project that bridges digital and physical art. Users can collect NFTs of crystals on-chain, and the NFTs evolve with every transfer between the users. The user’s wallet history (with a hint of randomness) decides the changes made to the crystals. The end idea is to convert the digital crystals into a physical art piece that can be displayed in museums worldwide.

Dynamic NFTs Are an Evolution

NFTs, though still early in their development, offer a myriad of applications. The emergence of Dynamic NFTs represents a further evolution in the uptake of this technology. Storing a considerable amount of information efficiently and modifying it consistently is made possible by chains with low-cost computation like Starknet. Starknet is witnessing significant ongoing development, and now is an opportune moment to join the developers of the future and consider building projects with exciting new use cases on Starknet.


Dynamic Non-Fungible Tokens (NFTs) are at the vanguard of a digital asset metamorphosis, responding and evolving in concert with on-chain or real-world events. These enhanced versions of traditional NFTs shatter the mold of static data, introducing transformative changes in value and form. The power of Starknet’s cost-effective computation and storage brings the dream of dynamic NFTs into reality, unveiling an abundance of possibilities such as adaptable images, evolving music, interactive gaming, and generative art. As our exploration of the blockchain and digital asset universe continues, dynamic NFTs embody an exciting evolution, marking a new era in the spheres of technology and creativity.

Builtins and Dynamic Layouts

A Pathway to More Efficient Proving Jobs

Summary: Builtins optimize the proving process. However, each proof is computed with respect to a layout, and layouts which are inefficient for a particular proving job diminish the benefit of builtins. Currently, there is a small static list of layouts, and each proof is computed with respect to the most suitable layout from that list. The static approach has two main drawbacks. First, the limited variety of layouts is inefficient for most proving jobs, incurring unnecessary costs on users through a convoluted fee mechanism. Second, manual maintenance of the list to accommodate new builtins becomes wildly more difficult for a large set of builtins, practically impeding the proving process from supporting many builtins with any semblance of efficiency. To resolve these issues, we are working on a Dynamic Layout system in which a layout is tailored to each proving job.

The Cairo stack facilitates provable general computation by compiling Cairo code into instructions for a STARK-friendly CPU architecture: the Cairo VM (henceforth CVM). The many advantages of a general purpose CPU come at an inherent cost: the CVM is not optimized for many frequently used operations. Prominent examples of such operations are hash functions e.g Keccak, Pedersen, and Poseidon, with other examples including elliptic curve operations and range checks (i.e checking if a particular number lies in a particular range of values).

To resolve the relative inefficiency of the CVM, the Cairo stack introduced the concept of builtins for key operations: plugins that optimize those operations’ proving complexity. Builtins are analogous to ASICs: ASICs are application-specific integrated circuits while builtins are application-specific algebraic constraints (AIRs). If you don’t know or remember what AIRs are, we’ll briefly touch on them later on; more details appear in this introductory medium post.

In a nutshell, proof complexity is correlated (roughly linearly) to a resource called trace cells, and builtins streamline proofs of particular operations by using far fewer trace cells than the Cairo VM.

Having explained the benefit from builtins, it seems natural to develop them for many frequently used operations. This is easier said than done. The current process of introducing new builtins into Starknet involves several steps:

  1. Write the AIR
  2. Integrate into the prover by creating new layouts (explained below)
  3. Integrate into Starknet, i.e modify its codebase and developer tooling to use the new builtin

Beyond the challenge of writing an AIR there is much room for improvement in the remaining two stages. This high-level post will go into more detail about builtins as application-specific AIRs, the above issues, and our plans for the upcoming future.

Builtins: application-specific AIRs

AIR is an acronym for Algebraic Intermediate Representation. In our context, it is a system of polynomials which represents a virtual machine. For instance, Cairo derives its name from CPU AIR: a system of polynomials which represents a particular CPU architecture. A solution of this polynomial system represents a valid state transition, and is called a valid algebraic execution trace (AET).

STARKs prove the correct operation of a virtual machine by proving that the associated execution trace is valid with respect to the given AIR. Roughly speaking, execution traces are organized as tables of numbers, and the STARK protocol proves these numbers jointly solve a polynomial system.

There are many ways to compute the same thing, with some computations more efficient than others. In our context, proof complexity is essentially determined by the trace size, i.e the number of trace cells in the table. Since traces are generated with respect to an AIR, an application-specific AIR can greatly reduce the execution trace of a particular computation. Builtins are application-specific AIRs aiming for precisely this optimization.

Here’s a table that conveys the efficiency improvements of particular builtins (all in production).

Trace layouts: present and future

Recall an algebraic execution trace (AET) is (roughly speaking) a table of numbers that encodes a sequence of VM steps (i.e an execution of a program). To compute a proof, the prover executes the STARK protocol on an execution trace with respect to an AIR.

Above, we introduced builtins as application-specific AIRs that aim to minimize proof complexity by reducing the number of trace cells required to encode a computation. However, careless integration of builtins into Starknet can waste many trace cells, diminishing the intended benefits. Let’s elaborate.

In a nutshell, a trace layout is an allocation of trace cells to different “components”. In our context, these components are the CVM and the builtins. More specifically, a layout specifies the relative amount of trace cells allocated to each component. (Layouts are always structured to streamline proof verification. For more information, see the “succinctness” section in this medium article.)

Here’s the crucial point: proof complexity depends on the total number of trace cells allocated by the layout, which may be larger than necessary. For example, to prove a sequence of CVM steps, it is roughly doubly efficient to use a layout that only allocates trace cells to the CVM component compared to a layout that allocates half the trace cells to e.g the Poseidon builtin. In summary, the complexity of proving a particular computation can be greatly reduced with a suitable layout.

Currently, there is a manually maintained list of layouts, which gradually grows for two main reasons:

  1. Builtins can only be used in layouts which allocate them trace cells. Hence the addition of a builtin requires at least one new layout.
  2. Tailoring a layout to an execution of Cairo code can improve cell allocation. Hence optimizations of cell utilization often require new layouts.

The code for both prover and verifier (the Solidity and Cairo verifiers) is configured according to the list of layouts.

With the addition of the Keccak and Poseidon builtins, we found it increasingly difficult to generate a small list of layouts which include many builtins while remaining efficient for the execution of most Starknet blocks. Furthermore, this efficiency is expected to drop wildly with the introduction of additional builtins, since layouts would have to account for the many possible combinations and ratios amongst them.

We are currently working to improve our system and forgo a prespecified list of layouts in favor of “Dynamic Layouts”: tailored on-the-fly to every execution of Cairo code. Dynamic Layouts will always be optimally proportioned for the proving job at hand. From an engineering perspective, this requires a considerable change in the codebase to support dynamic inputs. However, we expect Dynamic Layouts to streamline Starknet’s proving layer by improving trace cell utilization and consequently making better use of the prover machine.

Dynamic Layouts will dismiss the challenges of manually maintaining efficient layouts for many builtins, consequently streamlining the process of integrating more builtins into Starknet.

Dynamic Layouts and fees

One of the goals of transaction fees is to charge users for the marginal costs incurred on the protocol from their transactions. Since the units of transaction fees are currency, the fee mechanism involves conversion from resources (e.g VM steps, builtins, calldata, Ethereum gas) to tokens (e.g STRK, ETH).

Currently, the wasteful resource utilization of the prover comes at the expense of the users since they are charged fees according to the total trace, and not its utilized portion. Dynamic Layouts will improve cell utilization and consequently reduce the “unnecessary” part of the transaction fee (the part covering resource consumption not directly incurred by the user’s transaction).

Starknet builtin integration

Currently, the final step in builtin integration involves modifying the Starknet codebase to actually employ them. These modifications are orthogonal to layouts: they are required to ensure the Starknet operating system invokes builtins when possible. For instance, we want the Starknet operating system to invoke the Poseidon builtin during execution of Cairo code that invokes the Poseidon hash function.

Starknet builtin support is supported manually now, similarly to layouts. However, unlike the case of layouts, this manual support will remain tame and straightforward even for many builtins. In other words, Starknet builtin support is not a blocker to integration, and Dynamic Layouts will truly pave the way for creation and integration of additional builtins.


In this post we explained what builtins are, their benefits, the challenges involved in reaping these benefits, and our plans. Our current focus is on Dynamic Layouts, which will improve not only the efficiency of the proving process, but also the ease of integrating new builtins.

Charting the Stateless Future

A Deep Dive into Beerus, Starknet’s New Client


  • Beerus, a stateless client for Starknet, is built on Ethereum’s Helios light client, requiring no state information.
  • Starknet’s cryptographic proofs enable trustless state verification, a feature absent in Ethereum.
  • Beerus verifies Starknet storage proofs against Ethereum STARK proofs, converting untrusted data into trusted data.
  • Developers can contribute to Beerus, contributing to a secure, decentralized Starknet ecosystem.

Ethereum’s state is a comprehensive record of all Ethereum accounts, their respective balances, deployed smart contracts, and associated storage. As new accounts are continuously created, and new smart contracts are deployed, the Ethereum state keeps expanding indefinitely.

While various solutions aim to mitigate the impact of this state growth, the overall trend remains upward. This design feature results in the unbounded growth of Ethereum’s state size, which has several implications. It’s crucial for network participants to be able to verify that everything on Ethereum is happening correctly, and as operators and users, we must ensure we’re interacting with valid information.

This issue was first recognized in 2017 and the concept of stateless Ethereum was introduced. Unlike its literal meaning, the term “stateless” in the context of Ethereum doesn’t imply the absence of state. As Ben Edginton puts it, it means that you have delegated the responsibility of provisioning and storing Ethereum’s state to another participant within the network. Put simply, a stateless Ethereum client chooses the state it wants to maintain.

Light Clients and Stateless Clients

While light clients and stateless clients both aim to tackle the problem of Ethereum’s growing state size, there is a subtle difference between the two: light clients need some information about Ethereum’s state, whereas stateless clients like Beerus don’t.

Beerus is a stateless client for Starknet built using the Helios light client for Ethereum.

Starknet’s integration of cryptographic proofs within its protocol is what enables light clients and stateless clients to shine, a feature not found in Ethereum. They enable network participants to trustlessly verify the validity of the state, not only the consensus.

Light Future

Light clients and stateless clients have the potential to be a game-changer in the world of blockchains.

  • A new infrastructure paradigm: With low resource requirements, light clients could help to decentralize web3 infrastructure, making it more democratic and open to a broader range of participants.
  • Trustless bridges: Currently, most cross-chain transactions require multi-sig wallets to facilitate the transfer of assets. By using light clients, it could be possible to create trustless bridges that do not rely on centralized intermediaries.
  • Wallets with greater security: Currently, most cryptocurrency wallets require communication with centralized servers to function correctly. By using light clients, it will be possible to create wallets that operate entirely in a decentralized manner, providing users with more control and security over their assets.
  • Better or no oracles: By combining light clients with cryptographic proofs, there could be a secure way to verify external data.
  • IoT: Light clients are lightweight, which makes them a perfect fit for devices with restricted processing power and memory, consequently opening up new possibilities with IoT.
  • Light clients as smart contracts: By implementing the light client protocol of another chain as a smart contract, you can make decisions based on the state of the other chain with stronger security guarantees.

The Way A Light Client Works

A simplification of the way light clients work:

  1. The light client downloads Ethereum block headers, which contain the Merkle tree root for each block.
  2. The light client uses these block headers to verify the validity of consensus in Ethereum, without having to download the full contents of each block. (In Starknet, where cryptographic proofs are built into the protocol, light clients can verify the validity of state and consensus.)
  3. When a user wants to transact or interact with a smart contract, the light client sends a request to a full node. The full node then responds with the information needed to complete the transaction.
  4. The light client uses the block headers it had downloaded to ensure that the information returned by the full node is valid.
  5. Once the transaction is done, the light client updates its own copy of the blockchain by downloading any new block headers that have been added to the network.

Getting the Root Hash

In Ethereum, each block contains a Merkle tree of all the transactions included in the block. The Merkle tree is a data structure that allows for efficient verification of individual transactions without having to verify the entire block. The Merkle tree root hash is the cryptographic hash of the entire Merkle tree, and it is included in the block header of each block. This root hash represents the entire state of the blockchain up to the latest block.

An Ethereum light client needs this root hash to verify the authenticity and state of the latest block on the blockchain. By verifying the Merkle tree root hash, the light client can ensure that the latest block has not been tampered with or modified by a malicious actor.

There are two ways by which a light client can obtain the root hash: relying on a full node or a sync committee.

Full node verification

In this method, the light client relies on a full node to obtain the latest block with the root hash. The full node follows all signatures and verifies them up to the latest block. However, this method is resource-intensive and requires the light client to rely on a centralized authority to obtain the latest block, defeating the purpose of running a light client.

Sync committee

In Ethereum’s Consensus Layer, a sync committee is a randomly selected group of 512 validators. A new committee is chosen every 256 epochs (roughly 27 hours). This committee is responsible for signing block headers for each new slot. If more than 2/3rds of a sync committee agrees on the same state, the light client can trust it to be correct.

Sync committees work in conjunction with light clients to simplify the validation process. The light client only needs to know a previously validated block header, and have information about the previous, current and next sync committee members to authenticate Ethereum’s state. This way, the light client can verify the accuracy of validated blocks without needing to access the entire validator set or state history. This approach significantly reduces the computational power needed to validate a header.

Weak Subjectivity Checkpoint

To find the current sync committee, a light client needs to acquire the weak subjectivity checkpoint. A weak subjectivity checkpoint is akin to a genesis block, but it is located at a non-genesis position in the blockchain. It simply denotes a block that the entire network acknowledges as a permanent part of the canonical chain.

A weak subjectivity checkpoint is different from the concept of a “finalized” block. When a node encounters two conflicting finalized blocks, a consensus failure has occurred, and the node cannot determine a canonical fork. However, if a node encounters a block that conflicts with a weak subjectivity checkpoint, it will instantly reject it. In terms of nodes’ fork choice, the most recent weak subjectivity checkpoint serves as the network’s new genesis block.


Helios is a Rust-based Ethereum light client developed by a16z. It syncs in around two seconds, requires very little storage, and provides fully trustless access to Ethereum. Helios works with centralized RPC providers to verify their authenticity without running a full node. It is also easily embeddable and allows users to access secure chain data from any device.

Unlike most other Ethereum clients, Helios tightly couples the Execution Layer and the Consensus Layer. This way, Helios users only need to install and run a single piece of software.


A Starknet Stateless Client inspired by and using Helios. The goal is to provide a simple and easy-to-use client to query Starknet state and interact with contracts using the aforementioned merkle proofs.

The Beerus Core is a crucial component that does all the heavy lifting. By running Beerus Core, you gain access to all Ethereum endpoints by communicating with two untrusted RPC sources — the Helios light client’s execution layer and the Starknet full node. This is where the magical part comes in: Beerus transforms this untrusted data into trusted data.

How Beerus Works

Let’s get an overview of how Beerus works by taking the example of querying a storage value of a Starknet contract:

  1. Beerus synchronizes with Helios, which in turn synchronizes with the sync committee using a weak subjectivity checkpoint. This checkpoint ensures the reliability of the root hash that Helios receives.
  2. Next, we query Starknet to check whether the storage key for the given contract is present.
  3. A storage proof is then received from a Starknet full node at the last proven block. This storage proof verifies the existence of the storage contract at the last proven block.
  4. Beerus Core proceeds to request the Starknet state root from Helios, which fetches and verifies the STARK proof posted on Ethereum.
  5. The proof received from Ethereum is compared with the storage proof received from the Starknet full node. If the proofs match, we can confirm that the data has been validated on Ethereum and is therefore accurate.
  6. Finally, the verified data is returned to the user in a trustless manner.


Beerus is a stateless client for Starknet, built using the Helio light client for Ethereum, that enables trustless state verification. Light clients and stateless clients have the potential to decentralize web3 infrastructure and unlock various use cases that weren’t possible earlier.

By eliminating the need for extensive state information, Beerus only needs to verify Starknet storage proofs against the STARK proofs posted on Ethereum. This way, Beerus converts untrusted data into trusted data, allowing even resource-constrained devices to operate securely without relying on a full node.

Getting Involved

Interested in contributing to the development of a secure and decentralized Starknet ecosystem? Beerus is a great place to start. Developers can get involved by contributing to the project on Github and joining the discussion on Telegram.

Exploring the Use Cases of Cheap Computation

What new use cases does Starknet enable, and how can devs take advantage?

  • High compute costs have held back blockchain adoption and use cases
  • Starknet, a layer 2 Ethereum rollup, enables cheap computation
  • New use cases: day-to-day transactions, improved oracles, on-chain gaming, and more
  • Starknet already live on mainnet, with millions of transactions processed
  • Further improvements and cost reductions expected with EIP-4844 integration
  • Projects like Realms, Influence, and Dojo working to develop blockchain gaming on Starknet
  • Possibilities for AI/ML integration with verifiable inference, on-chain model ensembles, and verifiable training
  • Starknet’s future focused on performance, UX, increased throughput, reduced latency, and lower fees
  • Developers can use the Starknet book to learn about Cairo and build on Starknet

In the bull markets of 2021, when everyone was talking about crypto and sending out millions of transactions on Ethereum, gas prices could reach as high as 200 or more Gwei. That meant if you wanted to send 10 USDC to someone on Ethereum, it would cost you $50 or more. Not a very good deal.

With many new users of the blockchains, the demand for block space skyrocketed. This surge in gas prices on Ethereum (and other chains) exposed the limitations of monolithic blockchains. The public was ready — but the technology was not.

To address this issue, a shift to modular design emerged with “layer 2” solutions, a set of technologies built on top of a base blockchain that increases scalability and cost-effectiveness. As per Polynya’s article, “all blockchains worth their salt will pivot away from purely monolithic, in some way or another, over the coming years (unless the scale is not required, like Bitcoin).”

Starknet — a validity (or zero-knowledge) rollup — is a leader among these layer 2 solutions and has massively decreased the cost of computation. In this article, we’ll explore how high compute costs have held back blockchain, and then look in detail at several new use cases now possible through the cheap computation costs of Starknet.

Ethereum L2s

On Ethereum, a wide variety of these L2s have been developed, mainly within three solution categories: optimistic rollups, zero-knowledge rollups, and state channels.

The great thing about rollups is that they derive their security from Ethereum L1 (thus utilizing a decentralized network of over 600k validators). However, they also offer much faster and cheaper execution than a transaction on the mainnet. They achieve this by performing the computations outside of layer one (where computation is cheaper), but periodically posting the state of the L2 on the mainnet (to keep the security of the mainnet) as a bundle (hence “rolling up” the transactions).

What Is Starknet?

Starknet is a validity rollup (commonly known as a zero-knowledge rollup) developed by StarkWare that uses cryptographic systems called STARKs to achieve decreased computation cost.

Today, the mainnet version of Starknet already has transaction fees much lower than Ethereum.In version 0.13.0 (expected to release in Q3 2023), Starknet’s transaction costs are expected to go down even more with the introduction of Volition (or off-chain data availability). Currently, 95% of the transaction fees on Starknet are due to the transaction costs on Ethereum Mainnet (the rest 5% is compute). Furthermore, once EIP 4844 is implemented on Layer 1, the team will push upgrades to adapt to it as soon as possible. As a result of these 2 upgrades, the transaction costs are expected to go down drastically.

Limitations of High Compute Costs

Aside from the outrageously high fees just to send tokens, there are other issues with high compute costs. Even today, many applications are limited in their use cases due to this high computation cost. And as blockchain technology continues to evolve, the demand for complex computations will increase. The high compute costs are creating limitations on the growth and adoption of decentralized applications. For example:

  1. Day-to-day transactions. The promise of “crypto as cash” has yet to come true (except for some exceptions where you can “survive on crypto”). Along with regulatory uncertainty, one of the primary reasons for lack of mainstream day-to-day adoption has been expensive transactions. No one wants to pay $1 in transaction fees for a $2 coffee.
  2. Oracles. Due to their inherent design and principles, blockchains cannot retrieve off-chain real-life data. In order to get data such as stock prices, weather data, sports match results, etc., special applications called oracles are used. These oracles periodically publish data on-chain, which smart contracts can then retrieve. However, due to the high cost of transactions, the oracles cannot publish data on-chain regularly, often publishing only at long intervals. As a result, the data on-chain becomes outdated and could potentially cause poor decisions to be made by smart contracts. This is particularly important to be able to deliver trading experiences on par with Web 2. On top of this, due to expensive execution, any kind of data aggregation or additional computation becomes unfeasible.
  3. Governance. On-chain governance, or on-chain voting, is an effective way of making decision-making processes transparent and decentralized. Until now, for on-chain voting to occur, voters were required to cast their vote (based on the amount of token X they hold or any other mechanism to achieve voting power) by sending a transaction. However, for governance to be decentralized, effective decisions must be made often and quickly. As a result of high compute costs, on-chain voting has become an inefficient voting system. It’s too expensive to vote — so people simply don’t. Consequently, many projects have opted for off-chain governance, which undermines the purpose of blockchains.
  4. Gaming. When we hear of on-chain gaming, the once-viral game Axie Infinity comes to mind. In the game developed by Sky Mavis, the game characters, Axies, were represented by NFTs. However, the game logic was running in a fashion similar to all the other traditional games — on a centralized server. Games require players to make numerous decisions in a short period, each representing a transaction of sorts. And based on the player’s decision, the game plot can change, which requires large amounts of computation. This limitation of expensive computation caused games like CryptoKitties and Axie Infinity to feature only limited on-chain components. However, by marketing themselves as “web3” games, they achieved a market cap of several billion dollars at their peak, despite not being genuinely representative of blockchain gaming.

Opening the Door to New Use Cases with Cheap Computation

However, if we can achieve cheap computation, we open a new set of blockchain use cases. Starknet is already live on mainnet and processes tens of thousands of transactions daily (with more than 7 million transactions done to date). As mentioned, once EIP-4844 is integrated, the cost of transactions will go down by orders of magnitude.

Let’s look at some of the use cases this cheap computation on Starknet enables.

Affordable transactions and Account Abstraction

The simplest of all is that with cheap transactions comes day-to-day usage. Paying for your coffee now only costs you a couple of cents (or even a fraction of a cent). Additionally, due to account abstraction, your crypto wallet functions similarly to a traditional wallet. Much like keeping the bulk of your finances in a secure savings account, you store most of your assets in a wallet with multiple security layers (e.g., requiring a trusted individual to co-sign large transfers or using a unique private key).

Transforming data feeds with affordable on-chain computation

With the introduction of cheap on-chain computation, oracles will look much different than today.

First, frequent updates of oracle feeds become possible since individual transactions cost much less. This will result in more accurate data feeds and will enable more use cases for the users to build markets based on this data (complicated options protocols, prediction markets, etc.).

Since Starknet is a rollup, it needs to periodically send a commitment on Ethereum mainnet to update the state of the rollup (generally the gap between commitments can be from a couple minutes to hours). This commitment is one of the significant costs that a user pays when paying transaction fees on an L2. However, rollups must only commit the latest state to the L1. Overwriting the same storage slot multiple times in a single block does not incur high storage costs. In case of oracles, if some variable (e.g. the price of some asset) is updated frequently within the same commitment, the L1 cost would still be equivalent to a single write, as only the final state is published to mainnet as calldata.

Computational feeds — or feeds of aggregated and computed data — become possible due to the cheaper cost of execution. In traditional finance, financial applications utilize sophisticated data feeds, including risk, yield, and volatility. Teams like Pragma are working on bringing these feeds to web3. Pragma already has two computational feeds live on Starknet testnet — a volatility index and a yield curve.

The utilization of storage proofs will also change the landscape of oracles. Storage proofs are a cryptographic way to keep track of storage. Using these cryptographic commitments makes it possible to trustlessly prove that a particular state existed at a certain time (or at a specific block, in the case of blockchains). In order to verify these proofs, computations are needed (though they are very light), and cheap computation will enhance the UX. With storage proofs, it becomes possible to transfer information between different chains in a decentralized manner, offer historical data from the blockchain, and much more. If you want to dive deeper into storage proofs, check out our Medium article.

The shift to on-chain game logic

The world of gaming is immense. The largest gaming market, the USA, generates a whopping 54 billion USD per annum in revenue from gaming. Blockchain games have been in the spotlight recently, but as previously discussed, those games mainly belong to “web2.5” rather than being actual “web3” games.

In order for games to be actually considered a blockchain game, they must:

For the game logic to be completely on-chain, cheap execution is essential.

For the game to be considered a web3 game, an elementary “litmus test” could be whether the game could survive if the developers behind the game suddenly disappeared. This is very similar to how a smart contract lives on-chain; no matter if the developer of the smart contract is still active or not, the game should continue. Different interfaces could be built on the game logic if the basic game mechanics and rules are on-chain. The developers, on the other hand, would be incentivized to build with game-specific tokens. Even though no major game is currently wholly built on-chain, multiple projects on Starknet are working in the right direction, including Realms, and Influence.

Ecosystem developers like Dojo are working on providing an open-source ECS (Entity-Component-System) framework for the Starknet ecosystem. An ECS framework is a basic design pattern used to build games in a modular way. For example, for the case of Mario Kart, Mario and his car would be entities, the position and velocity of the cars would be components and the logic for car collisions would be implemented as a System. The game developer would then use these components to build the game. Projects like this are needed as the ecosystem grows, and more game developers are joining to build games on Starknet.

Transparent AI applications

With the recent buzz of artificial intelligence, it seems that AI may soon be integrated into our digital being. While it’s not a sure thing that AI models will be put on-chain, there are several reasons why this could be beneficial. And cheap computation is a must for these use cases.

  1. Verifiable inference means that models are pre-trained in centralized servers. However, once training is done, the model weights could be published on-chain. Once this is done, inputs could be passed to the model on-chain, and the outputs would maintain transparency with the user having proof of the model generating a certain output.
  2. On-chain model ensembles could be made possible if computation is cheap enough for models to be run to generate outputs on-chain. Outputs from multiple models could then be aggregated to form an “ensemble” model commonly used in ML applications.
  3. Verifiable training would mean that models could be trained on-chain, maintaining verifiable proof of benign training without introducing external biases. This may be the most compute-intensive application of the above and also the least likely to be brought live soon. These days, large AI/ML models take days (or years) to train on GPUs with enormous resources. On top of this, generating S[N/T]ARK proofs for the computation done while training would be an overhead right now. Moreover, Cairo specifically runs on CPUs (which are much slower than GPUs).


Giza and Modulus Labs (which also abbreviates to ML) are some of the prime research teams working to bring AI on-chain using ZK proofs.

What is the future for Starknet?

In the near future, Starknet’s roadmap focuses on performance and a better UX. Increased throughput, reduced latency and lower transaction fees are expected by Q3 of 2023. For more details on the plans for development, you may refer to the roadmap given here.

Cairo is designed specifically for STARK proving, making it optimal for harnessing the benefits of algebraic proof systems and ensuring efficient computation and verification processes.

Starknet is engineered for scalability, ensuring that it can accommodate exponential growth without sacrificing security, or decentralization.


With the intensive research around the “modular blockchain” space, the “bringing one billion users” goal is getting closer and closer. And with Starknet, cheap computation is here, and it’s only getting cheaper.

The growing Starknet book offers an excellent starting point for developers embarking on their Cairo journey for Starknet, with chapters 0 to 2 providing an introduction to various topics.

Starknet Goals and Roadmap for 2023

Focuse on performance and UX

This post will address Starknet’s roadmap for 2023 and provide color on the considerations driving it. The roadmap focuses on performance and UX.
We are aiming to provide the community with the transparency it needs, and so are sharing the roadmap at the earliest time possible. Naturally, sharing the roadmap early on also means things may change.

We would like to express our gratitude to Starknet’s developer community, and the Builders Council in particular, for providing invaluable insight and feedback in defining this roadmap. Special thanks to Sylve from briq, Federico from LambdaClass, and Jorik from Nethermind for their valuable feedback. We invite the community to continue being part of this important process.

The Starknet Journey

Starknet was designed to allow developers to harness the power of STARKs and Cairo in order to build their app. Up till now, Starknet’s development focused on providing developers with future-proof functionality. Starknet’s functionality, powered by Cairo 1.0, is by now mostly complete, aside from Regenesis.


Starknet will go through Regenesis this year. This will be a seamless event for the network, as it will result in no down time and with no resetting of the network’s state.

Fresh Cairo 1.0 contracts will require no action whatsoever — for them, Regenesis is a non-event.
Cairo 0 contracts will need to complete the transition to Cairo 1.0. Regenesis, where Cairo 0 will be shut down, will occur only after we’ve made sure the lion’s share of the community was able to complete this transition.
The Regenesis will be the last planned breaking change on Starknet’s roadmap, and we expect any future breaking changes to be vetted by governance decisions, as is done in Ethereum.

Or to explain Regenesis using Cairo 1.0 itself:

Roadmap for 2023

Starknet’s current development focus is on performance and UX. Here is an estimated timeline:


Our main goal for the coming months is to improve network performance in order to support the expected increase in the number of users and developers. As we see it, performance is defined by throughput and latency, obviously, but also by transaction cost.
We list here the areas of focus by their priority, and (when possible) state the planned version for their release.

Throughput & Latency

The upcoming Starknet v0.12.0, will incorporate significant throughput and latency improvements. This is the result of work conducted over the past six months to Rust-ify the Starknet stack. This version will include the transition to a Rust-based Sequencer (developed by StarkWare), and the new Rust-Cairo VM (cairo-rs, developed by LambdaClass) — two open-source projects. We expect to have performance benchmarks soon.

This transition will dramatically reduce block execution time, and therefore will increase throughput. In the absence of congestion, we also expect improvements to the transaction latency, as the main cause of latency is block execution time.

Higher throughput and lower latency will remain a top priority, even after v0.12.0, and the work to improve them will become a mainstay of Starknet development.

Transaction Cost

In v0.13.0, Starknet’s transaction costs will be reduced dramatically. This will be done by targeting the main component of transaction cost: L1 (Ethereum) data cost, which accounts for 95% of tx cost today. Volition will allow developers to build Starknet applications with a hybrid Data Availability (DA) mode: both on-chain and off-chain data. A post dedicated to Volition is forthcoming, with full details on its design and developer interfaces.

Ethereum’s EIP-4844 (Shard Blob Transaction) is expected in Q4 of 2023. Starknet will adapt to benefit from it as soon as possible, in addition to the introduction of Volition.

We expect dramatic reduction in the cost of data thanks to Ethereum’s EIP-4844 and to Starknet’s Volition (off-chain data availability).

Faster Finality

As we approach the release of Starknet v0.14.0 and v0.15.0, we remain committed to providing Starknet’s users with a seamless and predictable experience on the network, regardless of congestion levels. To achieve this, we are prioritizing two key areas of development: fee market and block intervals.

Fee Market

The planned performance improvements will be evident to developers and users, as long as the network remains uncongested. However, when network congestion occurs, it will lead to increased waiting times for everyone. To solve this issue, a fee market will be introduced to Starknet in v0.14.0, to allow an efficient allocation of Starknet’s limited resources, based on users’ willingness to pay for a transaction, and not merely on its place in line.

Shorter & Fixed Block Intervals

In v0.15.0, Starknet will switch to constant and shorter block intervals. Currently, each block is proven by its own proof, and block intervals are variable — the conserved quantity is the block cost. In order to reach that fixed block cost, the network awaits for the accumulation of enough transactions, and that results in variable block intervals. To solve this we plan to decouple the 1:1 relationship between a Starknet block and its proof. Starting v0.15.0, a proof will attest to the integrity of one or more Starknet blocks. This will fix the block interval, and improve Starknet’s UX.

Tradeoffs & Considerations

What were the tradeoffs we considered in determining this roadmap?

Performance is the highest priority — this is also the loud and clear feedback we got from our ecosystem. This will be improved mostly by increasing the Sequencer’s throughput, starting in v0.12.0.

In v0.13.0, we had to pick between lower transaction cost, and better UX (shorter/fixed block intervals, and more predictable network response during congestion).We decided to focus on lower transaction costs, and not on UX, because we expect v0.12.0 to result in much better latency (on the order of seconds). As mentioned above, the main lever for reducing transaction costs will be the introduction of Volition, and — as more details emerge — EIP-4844.
We would consider deviating from this plan if latency will not improve sufficiently following v0.12.0.

Improving network behavior during congestion (by introducing a fee market) will likely wait for v0.14.0. Although congestion may well occur post v0.12.0, we expect the significant throughput improvements to reduce its likelihood. Consequently, we decided to give lower transaction costs a higher priority.


The release of Cairo 1.0 marks the stabilization of Starknet’s functionality development. The remainder of 2023 will be devoted to improving Starknet’s performance & UX. By the end of this year, we expect the network’s base layer to have reached a healthy and stable state in terms of functionality, performance and UX. We expect the pace of major changes to decline sharply, and naturally be governed by all network participants. In 2024, decentralization will become the network’s focus, both in its operation and decision-making.

We are confident that the combination of future-proof functionality and enhanced best-in-class performance & UX will continue to drive an influx of developers and applications to Starknet.

updated: April 2023

What are Storage Proofs and how can they improve Oracles?

Trustless Cross-Chain Information Access on Starknet


Storage proofs are a cryptographic way to track blockchain information so that it can be shared across chains. Similar to oracles, storage proofs provide proof that the information is true. However, unlike oracles, they do not require trust in a third party for this proof; rather, with storage proofs, the trust is built into the storage.

In some cases, storage proofs can replace oracles. In other cases, storage proofs can enhance them and open up new blockchain use cases that weren’t possible before.

So let’s look in detail at storage proofs — what they are, how they work, their use cases, and how they can enhance (and sometimes replace) oracles.

What are storage proofs?

Storage proofs allow you to open cryptographic commitments of state, They can be optimized by marrying them with S[N/T]ARKS. . These validity proofs prove that a particular state existed and was valid at a particular block in the past.

Fundamentally, blockchains are databases that contain data cryptographically committed using Merkle trees, Merkle Patricia trees, Verkle trees, etc.). Since all the data is committed, we can prove that some information is encapsulated in a given state. However, with simple commitment schemes, the size of this proof becomes more prominent as the size of the data it includes becomes larger. Verifying such proofs on-chain becomes too expensive to be practical.

Storage proofs, on the other hand, when used in conjunction with STARKs or SNARKs, can be relatively small, and allow you to verify a specific piece of state, at a specific point in time, and on any domain — without trusting a third party. Instead of third parties, they rely on the security of the underlying chain itself.

Why is this important? Ethereum today is not the simple monolithic chain (L1) it was several years ago. With the advent of L2 solutions, the data is now spread across multiple chains.

Synchronous assumptions about the state of the chain can no longer be made. Many solutions for sharing data are now live such as L1->L2 messaging systems, cross-chain bridges, and oracles. But the issue with these current solutions is that they include trust in a third party such as relayers, multisig signers, and committees. Storage proofs allow us to validate the state of a blockchain at any point in time using cryptographic commitments assuming no trust in a third party.

The use cases for storage proofs

Since storage proofs allow us to efficiently “compress” a blockchain and transmit the data elsewhere, they have quite a few applications. The affordable verification cost, an integral property of storage proofs, allows the proof to be validated on the destination chain, minimizing the need to develop cross-chain messaging systems.

Potential use cases include:

  • General information access of one chain from another about state and transactions on the blockchain.
  • Simplified cross-chain voting systems. Frequently users hold their assets on a slow but more secure chain A, but some token-based voting occurs on a chain B with cheaper transactions. This forces the user to either skip their vote or pay huge transaction fees to bridge their assets from A to B, cast their vote, then bridge them back to A. In such cases, storage proofs enable users to prove their token balance on chain A at a given block and seamlessly cast their vote on chain B.
  • Alternative to cross-chain bridges. Currently, cross-chain bridges assume a level of trust in a third party because they typically involve an intermediary, such as a custodian or a decentralized autonomous organization (DAO). This intermediary is responsible for ensuring that a certain amount of tokens are received on the source chain by the intermediary and for holding the assets on the source chain. Afterward, the corresponding tokens are minted on the destination chain. Storage proofs can enable trustless cross-chain bridges since a smart contract application on the destination chain could validate a transaction where assets were transferred to the bridge smart contract on the source chain and mint the bridged assets. However, in many cases the need of transferring assets between chains may be eliminated since ownership of assets on another chain could be simply proven with storage proofs.
  • Enhanced UX for Account Abstraction (AA) use cases. AA has been implemented in different chains and is considered a crucial innovation in onboarding the first billion users to the blockchain space. With storage proofs, wallets could include the additional functionality of restoring access only if the wallet did not send any transactions over a long duration. Additional checks that require some data to be used from other chains could also be enforced.

An example of a storage proof

Generating storage proofs on EVM-compatible chains is straightforward. For example, Web3.js library has the `getProof` function that can generate proof of a contract’s state on Ethereum (and other EVM-compatible chains such as Polygon or BSC). A contract address and the storage slot for the contract must be passed to the function.

In Ethereum, smart contracts use a key-value store to store data in their storage. Each piece of data is stored in a specific location known as a “storage slot.” Storage slots are memory locations within the contract’s storage and are identified by a unique index. Let’s look at a sample smart contract with the following code deployed on Ethereum mainnet at 0xcc…da8b.

The `owner` variable would be stored at slot 0. Now, to generate the proof that the `owner` of this contract was an address A, we can use the `getProof` function as follows:

The output of the code above looks something like this:

The “storageProof” returned contains the storage proof for the “owner” variable. Since Ethereum uses Merkle Patricia Trees to commit to its state the state of accounts and their storage, the storage generated can be used to prove a storage slot (or account state). However, as previously stated, these proofs are not scalable enough to discuss cross-chain message transfers. Using complex ZK mathematics on top of this can decrease the computation required to verify the proof.

So how do storage proofs compare and contrast with oracles?

By design, blockchains cannot retrieve off-chain data. This keeps a blockchain trustless but also introduces limits on a smart contract’s ability to make decisions based on real-world events. Oracles are also commonly employed for obtaining historical blockchain information, as acquiring this data directly is highly challenging and consequently susceptible to mistakes.

To solve this problem, special entities named oracles were created to retrieve this off-chain data (or retrieve results from some heavy off-chain computation). Currently, these oracles require a third party, such as an institution or a decentralized network of node operators to submit data on-chain that becomes public to users and smart contracts. This assumption of trust is currently inevitable, yet not ideal (though several teams are working on minimizing this trust requirement such as Pragma)

Chainlink is an example of a blockchain oracle that provides a wide variety of real-world data (stock prices, weather data, etc.), off-chain computation services to minimize the cost of heavy computations on-chain, and cross-chain services that read and write information between different blockchains.

Since smart contracts have no other way of knowing what is happening in the real world except for using oracles, oracles have become an indispensable part of the blockchain ecosystem.

The state of oracles on Starknet

On Starknet testnet, the previously mentioned Chainlink currently provides price data feeds for seven pairs of cryptocurrencies and has partnered with the Starkware team to “further accelerate app development and general growth for the StarkNet ecosystem.” Chainlink minimizes the assumption of trust with a decentralized network of nodes that provide data from off-chain sources, but the data aggregation occurs off-chain.

Pragma and Stork Network are two of the largest oracle providers on Starknet, operating on both mainnet and testnet. Along with the price tickers for multiple cryptocurrency pairs, Pragma is working on implementing a verifiable randomness feed on mainnet that would allow protocols to request secure randomness on-chain. Price feeds on Pragma are based on price submissions by large institutions and market makers, and price aggregation occurs on-chain leveraging efficient ZK technology.

Can oracles be replaced or improved by storage proofs?

In some cases, yes, a storage proof can replace an oracle.

Not all data provided by oracles actually needs to be supplied by a third party. In some cases, the data provided by an oracle was already available on chain (in the form of on-chain storage, or a transaction) and can be retrieved by taking a peek at a previous state of the blockchain. In these cases, a storage proof can replace the need for trust in a third party and the oracle, and allow smart contracts to rely completely on the security of cryptographic commitments.

In other cases, where storage proofs can’t completely replace an oracle, they can often still enhance them with additional functionality, such as the following:

  • Oracles transmit information from data providers to data consumers. However, not all data consumers are on the same chain. With the help of storage proofs, it is possible to complete some computation on the data from different sources and export the result to other chains.
  • The preferred source chain for such data is the one with cheap computation, and validation of the proof can be done cost-effectively on other destination chains.
  • Herodotus is one of the research leaders in this domain, and they offer cross-domain data access across different Ethereum chains using storage proofs and ZK mathematics. Pragma also partners with Herodotus to enable cross-chain oracle support in the near future.
  • Storage proofs can unify the state of multiple rollups, and even allow synchronous reads between Ethereum layers.
  • Another enhancement is a trustless retrieval of historical data published on-chain. Stateful blockchains such as Ethereum and Starknet record and cryptographically preserve their state through specialized data structures, such as Merkle/Verkle trees and MPTs. This makes it possible to prove the inclusion of any data stored in these structures. Hence, any past data published on-chain can also be trusted, retrieved, and used in other applications (not even necessarily on the same chain). These storage proofs allow smart contracts to access information dating back even to the genesis block.
  • Pragma is researching the viability of developing an oracle as an L3 on Starknet from where data can be “pulled” on other chains and verified using storage proofs. The benefits of having the oracle in a different domain on top of a computationally cheap network like Starknet include the following:
  • Since the L3 could be a highly customizable chain, various parameters can be tweaked to achieve consensus faster on the blocks, greatly reducing data latency for the oracle.
  • In combination with storage proofs, the low-latency data can be asynchronously transferred to other chains, upon reaching consensus in the source chain.
  • The possibility to enhance trust in data by developing an inbuilt system in the L3 to slash dishonest data providers. If given appropriate incentives, the data providers on the L3 could stake their assets as a guarantee of publishing correct data. Since the consensus of the whole network on L3 is needed before other chains can utilize the data, the data provided by the oracle can be considered to be secured by the validator’s stake on the L3.


Over the last several months, the growing use of L2s on Ethereum has given us a clearer view of the industry’s future. The L2 narrative has been gaining traction with networks like Starknet, Optimism, and Arbitrum. However, one of the primary backstops for its growth has been implementing a decentralized cross-chain messaging system. Although they are still at a nascent stage, storage proofs promise incredible improvements to this problem.

Big thanks to Marcello Bardus & Kacper Koziol for reviewing this article.