Kakarot zkEVM: Deep Dive Analysis

Everything you need to know about Kakarot


The emergence of Ethereum revolutionized the crypto world, introducing a multitude of possibilities for decentralized applications (dApps). However, this advancement has also brought forth a crucial dilemma: how to strike a balance between security, decentralization, and scalability without compromising any of these vital components?

In this complex context, Layer 2 (L2) solutions have emerged as a proposal to address the scalability issue while leveraging the security and decentralization of Ethereum. Among these solutions, zk-Rollups shine as the most promising, according to Vitalik Buterin himself. However, since Ethereum was not originally designed to support ZK proofs, building a zkEVM as a L2 requires finding a compromise between compatibility with the Ethereum Virtual Machine (EVM) and optimal performance. While most L2 solutions prioritize compatibility, Starknet stands out by focusing on performance, aiming to maximize it at the expense of compatibility.

Amidst this ever-evolving landscape, Kakarot presents itself as an innovative solution, acting as a bridge between the ultra-optimized zkVM of Starknet and the EVM compatibility. This article explores the limitations of monolithic blockchains, the transition towards a modular architecture, and thoroughly analyzes how Kakarot positions itself as a catalyst for achieving a balance between compatibility and performance, bringing the network effect of the EVM into the ZK ultra-optimized world of Starknet.

To achieve this, this article will be organized as follows:

I. Problem:

  1. Limitations of Monolithic Blockchains

  2. Rollups and ZK

II. Solution:

  1. Introduction to Kakarot

  2. Advantages offered by Kakarot

  3. History of Kakarot

III. Functioning:

  1. How Kakarot currently works

  2. Technical characteristics

IV. Team and Funding:

  1. Composition of the team

  2. Funding and investors

V. Roadmap:

  1. Kakarot's development stages

  2. Strengthening the Starknet ecosystem

  3. Proving the Ethereum layer and other EVM chains

I. Problem:

1.1. Limitations of monolithic Blockchains

Ethereum was launched on July 30, 2015, through an ICO that raised over $8 million. While other projects focused on specific functionalities like payments and transfers, Ethereum was designed as a general-purpose blockchain capable of handling a wide range of applications. Its primary goal was to empower developers to create all kind of dApps that cater to users' needs while operating in a secure and decentralized environment. This approach has proven to be highly successful.

Initially, the goal of Ethereum was to cover all aspects of a blockchain, including settlement, consensus, execution, and data availability. However, it soon became clear that this monolithic approach did not effectively address the challenges of security, decentralization, and scalability simultaneously. This was evident with the emergence of CryptoKitties in 2017 and the DeFi boom in 2021, where the cost of a simple transaction could reach several hundred dollars. While this demonstrates the growing demand for web3, it is not sustainable in the long run, especially for small users.

This issue, referred to as the blockchain trilemma, highlights the inherent trade-off between decentralization, scalability, and security. It is not possible to achieve all three simultaneously; sacrificing one element is necessary to fully satisfy the other two.

To solve this problem, Ethereum has embraced a modular approach, with Ethereum serving as the settlement layer that ensures security and decentralization, while Layer 2 (built on top of Ethereum) brings scalability to users. Altough the level of modularity can vary, especially with new data availability solutions like Celestia, Avail, or Eigen Layer, the following level of modularity offers the highest security and is currently the most widely used:

  • Ethereum: handles data availability, consensus, and settlement

  • Layer 2: focuses on execution

As a reminder, here is a breakdown of each component:

  • Execution: processes and executes transactions

  • Settlement: achieves consensus on the agreed state

  • Consensus: agrees on the order of messages and transactions

  • Data validity: ensures the publication, visibility, and accessibility of data for all

Among the different Layer 2 solutions available (Sidechain, State Channel, Plasma, and Rollups), Rollups are the most prevalent and promising option. Simply put, Rollups involve executing multiple transactions on L2, batching them, and then sending only the necessary information from these transactions in a single transaction on Ethereum. Within this category, ZK Rollups offer several advantages over Optimistic Rollups. In fact, to remain sustainable in the long term, Optimistic Rollups will likely need to transition to Validity Proofs or ZK Rollups.

1.2. Rollups and ZK

If you want more details about why ZK is superior to Optimistic Rollups, I recommend reading my article "Starknet part 1: L2 landscape", section II/ part B and C.

In summary, even Vitalik himself considers ZK as a better long-term solution compared to Optimistic Rollups.

My opinion is that in the long run, ZK-Rollup will eventually beat Optimistic Rollup because they have basic advantages like users don't need to wait 7 days for a withdrawal.

In general, my own view is that in the short term, optimistic rollups are likely to win out for general-purpose EVM computation and ZK rollups are likely to win out for simple payments, exchange, and other application-specific use cases, but in the medium to long term ZK rollups will win out in all use cases as ZK-SNARK technology improves.

Currently, implementing the architecture of Optimistic Rollups is easier than that of ZK Rollups, and they do not have any compatibility issues with the EVM. As a result, building ZK Rollups is more time-consuming and challenging. However, there are several advantages that ZK Rollups offer over Optimistic Rollups:

  • ZK Rollups are more secure because they are based on mathematics, while Optimistic Rollups rely on the honesty of at least one network participant.

  • ZK Rollups do not have a Dispute Period, resulting in a very fast withdrawal period. On the other hand, an Optimistic Rollup requires around 7 days for the withdrawal period (and the shorter the period, the less secure the network).

Furthermore, the advantages of Optimistic Rollups are only short-term:

  • Ease of building: Over time, as research and discoveries intensify in the field of ZK, the construction of ZK Rollups becomes less difficult. Furthermore, there are already solutions being developed for ZK-Rollups-as-a-service, enabling the effortless deployment of a ZK-Rollup with just a few clicks.

  • Easy compatibility with the EVM: zkEVM is currently working on achieving EVM compatibility.

  • The Ethereum roadmap: aims to enhance the efficiency of zk-Rollups.

The main current challenge for these solutions lies in the fact that the EVM was not designed to support ZK proofs. As a result, ZK proofs in an EVM environment is not optimal, and there are compatibility difficulties that ZK projects' teams must address:

  • They can either optimize compatibility at the expense of performance.

  • Or optimize performance at the expense of compatibility.

zkEVM (especially those aiming to be type 1 and 2) has chosen compatibility, while Starknet has prioritized performance.

The compromise is that developers on Starknet must learn an entirely new programming language called Cairo, which is optimized for ZK proofs. This poses a significant barrier for developers accustomed to the EVM:

  • They may lack the time or motivation to learn a new language.

  • Projects may not have the financial or human resources required to rewrite and maintain code in two different languages.

Some teams really need to be able to use Solidity. For example, if someone wrote a DEX or an AMM for the Ethereum ecosystem and now has 60,000 lines of code already audited, ready to go, but it’s only on EVM chains. If these developers wanted to start using Starknet, they would have to hire a whole new dev team, write in, audit the code again and maintain two code bases — which Tazartes describes as “prohibitively expensive.

In summary:

  • The EVM allows to benefit from the Ethereum network effect (users, tools, software, dApps...), but it is not optimized for ZK.

  • Cairo is optimized for ZK but lacks the network effect of the EVM.

Is it possible to combine the best of both worlds?

Possibly, and that is exactly what Kakarot is currently building 🥕

II. Solution:

2.1. Introduction to Kakarot

Kakarot zkEVM is an implementation of the EVM written in Cairo. Cairo is a programming language that generates execution traces, which can be used to generate Stark Proofs. Therefore, Kakarot allows the development of provable EVM applications.

By combining EVM compatibility with the Starknet ecosystem, it offers the best of both worlds: Users and developers can benefit from the growth and innovations of Starknet while operating within the EVM universe.

The core thesis of the Kakarot team is that Cairo is the optimal tool for ZK technologies and will remain the top choice in this sector in the future. At the same time, the EVM will continue to be dominant. Kakarot serves as a bridge between the two, enabling developers to create EVM smart contracts on Starknet and other chains based on the CairoVM.

This vision is supported by the following main reasons:

  • Cairo simplifies the construction of ZK applications within these environments.

  • Cairo has been in production for several years and has demonstrated high performance. Since its launch in 2018, there have been no security issues, and StarkEx has successfully executed over 1 trillion dollars worth of transactions.

  • Cairo enables the creation of provable dApps through STARK proofs, which offer numerous advantages over SNARK proofs.

Kakarot aims to bring all these benefits to the EVM ecosystem while leveraging the network effect of EVM to strengthen all CairoVM-based ecosystems.

2.2. Advantages offered by Kakarot

Kakarot is a type 2.5 zkEVM (when the 9th precompile is implemented) that aims to eventually become a type 1. This allows users to enjoy the benefits of Validity Rollups while maintaining compatibility with the Ethereum ecosystem.

By writing its zkEVM in the intermediate language optimized for ZK, Cairo, Kakarot becomes the first zkEVM built on top of an intermediate zkVM. This unique architecture provides some exclusive advantages.

The first advantage is enhanced security. Thanks to the power of the Cairo programming language, Kakarot was able to build its zkEVM using just 10,000 lines of code. This is important because smaller code makes it easier to audit the contract and reduces the likelihood of errors. Additionally, Kakarot has been open-source from day one, allowing anyone to verify the code.

The one I worry about most is if we have $10B in a ZK-rollup 2y from now and it gets hacked because of a bug in the circuit constraint code or the EVM wrapper around it. For the latter, keep it simple and formal-verify.

In programming, simplicity is king.

Additionally, unlike other zkEVMs where the security of the ZK component relies solely on them, Kakarot relies on the expertise of StarkWare. By utilizing the CairoVM, Kakarot benefits from the audits and security work conducted by StarkWare's cryptographers.

This virtual machine has already demonstrated its efficiency as the most efficient language for STARK proofs. It powers:

  • StarkEx and its flagship dApps such as dYdX (since the beginning, but they are now migrating to their own sovereign chain Cosmos), and Sorare.

  • Starknet, the permissionless version of StarkEx, which already has over $140m TVL.

The second point, which is related to the previous one, is that thanks to Cairo (which is provable by default), Kakarot does not need to build the circuits or polynomials.

Unlike other zkEVM (Scroll, Polygon, zkSync, Linea), Kakarot is an EVM built from a pure software engineering perspective, delegating to Cairo (and the hundreds of Starkware's cryptographers) the responsibility of the "zk", thanks to the unique usage of Cairo.”

This means that while other zkEVM have to build both the EVM and the provable part, Kakarot focuses solely on the EVM and delegates the provable part to Cairo. How does it possible? Because programs written in Cairo are provable, developers looking to leverage the scalability property of ZK cryptography no longer need to write circuits. Kakarot is solely a zkEVM that functions as an implementation of the EVM on top of a provable VM.

Thanks to this unique modular approach, Kakarot has been able to implement the EVM opcodes in just two and a half months.

Thus, contributions and development are greatly simplified compared to other ZK. Additionally, unlike other teams, Kakarot does not currently have any cryptographers on its team.

“While others are building their own languages, Cairo simplifies our development. Our codebase is more readable and accessible to those without deep math cryptography knowledge. This ease of entry has attracted over 50 open-source contributors, enabling us to achieve full upgrade compatibility in just three months,” explained Danilo.

Finally, Kakarot stands out as the most flexible ZK solution available in the market. Its smaller code size enables it to adapt quickly to updates. Moreover, Kakarot has the unique ability to leverage optimizations and updates from both the EVM and CairoVM communities.

This means that Kakarot can benefit from the continuous research and development efforts of StarkWare, its community, and the EVM community, and rapidly implement these innovations!

2.3. History of Kakarot

The story of Kakarot is fascinating and inspiring.

On July 21, 2022, Shahar, the co-inventor of Cairo, proposed the strange idea of coding a zkEVM in Cairo. The goal was to create a verifiable EVM by default.

Abdel, the Exploration Lead at StarkWare, was immediately captivated by the idea. He gathered a team of open-source developers to work on the project and played a crucial role as a catalyst. He created the project's GitHub repository and initiated several calls to the Starknet open-source developer community. He also chose the project's name, Kakarot, as a reference to the hero of the famous manga Dragon Ball Z.

The project gained momentum in October 2022. During the Starknet hacker house in Lisbon, approximately 70 developers from the Starknet community came together. Among the proposed projects was Kakarot, and a small group of developers joined forces to pursue its initial vision: coding the EVM opcodes in Cairo. Among these developers were the three people who now lead Kakarot: Elias (CEO), Clément (CTO), and Danilo (Ecosystem Lead).

From that point forward, this dedicated team of open-source developers focused on implementing the EVM opcodes in Cairo. In just three months, they achieved full compatibility with EVM opcodes.

This remarkable progress has been achieved without a fixed core team, relying solely on open-source contributors and funding from grants provided by StarkWare and Only Dust.

  • Shahar's tweet: July 2022

  • Hackathon kick-off: October 2022

  • Opcode equivalence: December 2022

  • Organization as a real project: Q1 2023

  • Pre-seed with participation from StarkWare and Vitalik Buterin himself: June 2023

  • Seed round: November 2023

Thus, Kakarot was initiated following a simple tweet and has grown through a community of open-source contributors. Today, Kakarot is being developed within a structured framework, with a clear vision, a core team, and financial support of several million dollars.

If you are a developer and are hesitant to participate in hacker houses, Kakarot serves as a perfect example of the unique opportunities that such events represent, as well as the power of open-source contributions. Moreover, the rapid and collaborative development of Kakarot testifies to both the commitment of the Starknet community and its strength. So don’t sleep on Starknet anon!

III. Functioning:

3.1. How Kakarot currently works

The unique implementation of the EVM proposed by Kakarot will initially be launched on a standalone testnet. Then, in its first phase, Kakarot will act as a smart contract deployed on Starknet, which functions similarly to a blockchain but is not one. This smart contract will interpret Solidity bytecode and execute EVM opcodes on Starknet. To understand Kakarot, think of it as follows: on the front-end, we have Kakarot and the EVM, but on the backend, it's Starknet.

Kakarot supports all EVM opcodes, which are instructions specifying operations to be performed. Each opcode corresponds to a specific operation such as addition, subtraction, data movement, and more. Opcodes are used by the EVM to execute contracts or transactions. Therefore, Kakarot serves as an EVM bytecode interpreter, enabling Solidity smart contracts to function on Starknet.

Unlike the discontinued WARP project, which only allowed developers to convert their Solidity code into Cairo, Kakarot allows developers to directly deploy their dApps in Solidity. Additionally, users can interact with the deployed dApps using their preferred tools, such as MetaMask.

Here is a simplified explanation of the functioning:

  1. A user sends an EVM TX/call.

  2. Kakarot's RPC node translates/wraps the request into a Starknet-compatible environment.

  3. The RPC node sends the request to Starknet's JSON-RPC.

  4. The transaction is executed and processed by the Starknet OS.

  5. STARK proofs are generated to verify and record the state difference caused by the activity on Starknet onto Ethereum L1.

3.2. Technical characteristics of Kakarot

✅ Kakarot is a set of Cairo programs, deployable on any chain that runs the CairoVM as runtime.

✅ Kakarot can: (a) execute arbitrary EVM bytecode, (b) deploy an EVM smart contract as is, (c) call a Kakarot-deployed EVM smart contract's functions (views and write methods).

✅ Kakarot is an EVM implementation.

✅ 100% equivalence with EVM opcodes.

✅ 8/9 precompile (when 9/9, type 2.5 zkEVM)

✅ Open source since day one.

❌ Kakarot is not a blockchain by itself. It still needs a chain that runs the CairoVM to be deployed.

❌ Kakarot is not a compiler.

As a type 2.5 zkEVM, Kakarot will be compatible with Ethereum, allowing developers to build on Kakarot and users to interact with it as if they were on Ethereum or Arbitrum. This seamless integration means there will be no differences for users and developers. Developers can easily copy-paste their Solidity code, and it will work without any changes (to be precise, only the gas fees will change). Users can also continue using their preferred tools like MetaMask.

Currently, Kakarot has already integrated MetaMask, Remix, Foundry, and Ethers tools, and is currently testing other tools such as Hardhat, Viem, Truffle-Box, and Wagmi.

In addition to the EVM compatibility, Kakarot utilizes STARK proofs from Starknet, which offer several advantages over SNARK proofs. Simply put, STARK proofs are faster and more efficient in proving significant elements, and they do not require a trusted setup ceremony, thereby enhancing security. This is why an increasing number of Layer 2 solutions are transitioning to STARK proofs.

Reminder: STARK stands for Scalable, Transparent, Argument of Knowledge; while SNARK stands for Succinct, Non-Interactive, Argument of Knowledge.

IV. Team and Funding:

4.1. Composition of the Kakarot team

The Kakarot team consists of a core team of 6 people, two advisors, and over 50 contributors.

Elias is leading the project from the Lisbon hacker house and has naturally become the CEO. On the other hand, Clément has been leading the technical efforts and has become the CTO of Kakarot. Finally, Danilo, who has also been present from the very beginning, is now the Ecosystem Lead.

As for the advisors, we have Abdel, the spiritual father of Kakarot, champion of the EIP-1559, and current Exploration lead at StarkWare, as well as Mentor, the CEO of AVNU, the current DEX leader on Starknet.

Finally, there are 3 core developers involved in the project.

4.2. Funding and investors

In terms of fundraising, the exact amount raised by Kakarot is unknown. However, we do know that they received $150,000 before their first fundraising round. This funding came in the form of grants from StarkWare and Only Dust.

During a donation round on Gitcoin, they also raised approximately $12,500.

Moreover, they have successfully concluded two rounds of investment so far.

The first round is a pre-seed round that includes support from many highly recognized players in the ecosystem, the most notable being:

  • Vitalik Buterin himself, the creator of Ethereum

  • StarkWare, the company behind STARK proofs, Cairo, StarkEx, and Starknet

  • Nicolas Bacca, the co-founder of Ledger, the company behind the most widely used hardware wallet in the market

  • Sam, the organizer of Starknet CC and the founder of Node Guardians

The second one is a seed that brings together numerous top-tiers investors such as:

V. Roadmap:

5.1. Kakarot's development stages

Currently, Kakarot is primarily focused on conducting the official tests of the Ethereum Foundation: Hive and Execution Tests. Once these tests are completed, Kakarot will release its unique implementation of the EVM as a standalone testnet. This will allow the team to thoroughly test the robustness of their solution and make optimizations before the Mainnet launch.

The testnet is scheduled to be released by the end of this year and will initially function as a private testnet. The community will have the opportunity to participate in this private testnet before it becomes public, which is expected to happen in early 2024.

5.2. Strengthening the Starknet ecosystem

Then, Kakarot plans to strengthen the Starknet ecosystem through several initiatives.

The first initiative involves implementing Kakarot's zkEVM as a smart contract on Starknet. This will enable developers to build EVM dApps secured by Starknet's technology. The implementation is scheduled to be completed no later than the second quarter of 2024.

Next, Kakarot will likely explore the possibility of deploying its solution as an L3 on Starknet. This would make it the first general-purpose L3 zkEVM on top of Starknet. By doing so, it will provide an ultra-scalable solution with higher transaction capacity per second at a lower cost compared to L2 solutions. Moreover, it will still benefit from the security of Ethereum, as Kakarot settles on Starknet, which in turn settles on Ethereum.

This mechanism, known as fractal scaling, creates a more favorable environment for various applications, such as gaming or social networks, in comparison to current L2 solutions.

Additionally, Kakarot aims to develop an L3 zkEVM as-a-service solution in collaboration with Madara and Karnotxyz. This will allow anyone to deploy a compatible EVM appchain that settles on Starknet using STARK proofs.

One-click: a zkEVM deployed as L3 on top of Starknet for a specific app. EVM environment, low gas, and fast execution. Cryptographic security.

Once again, L3 offer several advantages:

  • Exponentially lower gas fees compared to L2.

  • Much higher transactions per second capacity.

  • Customization of the stack based on the needs of the appchain.

After the era of L1 and then L2, the next step is L3, and the majority of current L2 are working towards that direction.

However, the proliferation of L2 and L3 poses a major issue: user and liquidity fragmentation, as well as a lack of interoperability. That's why Kakarot also plans to explore ways to partially solve this problem. Their first objective will be to facilitate interoperability and composability between Kakarot dApps and Starknet, aiming for interoperability by design with Starknet. In other words, facilitating communication from Solidity to Cairo and from Cairo to Solidity.

5.3. Proving the Ethereum layer and other EVM chains

Finally, Kakarot aims to adopt the type 1 to prove Ethereum chains and contribute to the diversity of provers within the Ethereum ecosystem. Proving Ethereum is crucial as it enhances network decentralization, making it theoretically possible for anyone to run a node using just a mobile phone. Furthermore, having multiple prover implementations is beneficial for decentralization as it ensures resilience in case one of them has a bug.

You get it: in addition to aiming to improve scaling on Ethereum, Kakarot also aims to contribute to its decentralization and the diversification of its core stack.


In the rapidly evolving world of Ethereum scaling, Kakarot presents an elegant and innovative solution to improve this dynamic. While ZK solutions position themselves as either zkEVM, prioritizing compatibility at all costs, or zkVM, focusing on building an optimized virtual machine for ZK at the expense of compatibility, Kakarot emerges as a unique solution that cleverly bridges these two paradigms. It acts as a bridge between compatibility and performance, bringing the EVM into the ultra-optimized ZK environment of Starknet.

Being the first zkEVM built on an intermediate zkVM, Kakarot enjoys increased security and enhanced flexibility compared to other solutions. Its ambitious roadmap goes beyond a simple L2, which is not only exciting but also essential for strengthening the Starknet ecosystem and, consequently, Ethereum itself. Kakarot is definitely establishing itself as a project to closely monitor.

To conclude this article, I would say that Kakarot is a cool project, and I'm not the only one who thinks so…

I hope you enjoyed this article and learned something new! If so, please feel free to share it and follow me on Twitter. Following me on Twitter is the best way to support and encourage me to continue creating content like this. You can also subscribe to this newsletter for free!

Join the conversation

or to participate.