Cartesi Co-Founder on ‘Stage 2’ Decentralisation and the Power of Honeypots

We caught up face-to-face with Felipe Argento, Co-Founder of Cartesi, during DevConnect in Buenos Aires, Argentina. We discussed the project’s evolution from an AI marketplace to a modular execution layer and the importance of reaching their “Stage 2” decentralisation milestone.

Cartesi is an app-specific rollup protocol with a virtual machine that runs Linux distributions, creating a richer design space for DApps. Their “Honeypot” challenge recently tested the security of their fraud-proof system in a live, permissionless environment.

Read more about Cartesi’s security strategy and their renewed focus on Ethereum in the interview below.

You have been with Cartesi since 2018, helping design its architecture and leading the on-chain implementation of Cartesi Rollups. What problem were you trying to solve at the start, and how has that vision changed as Ethereum’s scaling ecosystem evolved?

Augusto, our principal founder, originally proposed the idea. He aimed to create a marketplace for AI, which soon expanded into the broader challenge of performing arbitrary computation in a scalable manner.

Initially, the aim was to expand the capabilities of smart contracts. You had a Solidity smart contract and integrated Cartesi into it so the contract could perform complex computations, like a coprocessor for Ethereum. As the industry’s understanding of rollups and L2 structures grew, we realised that our development could do more than just extend smart contracts.

It could potentially replace the smart contract execution environment. Instead of computing directly on Ethereum, you perform calculations on another layer and then bridge the results back to Ethereum while maintaining security, fraud proofs, and censorship resistance. We have shifted from simply “extending smart contracts” to “being the execution layer itself.”

Before Cartesi, you worked on blockchain applications for clean energy and carbon markets. What lessons from those early projects shaped the way you think about verifiability and scalability today?

That was around 2016 and 2017. The same study group I mentioned became a company that conducted research and development for large Brazilian companies interested in blockchain. One major company wanted to explore carbon credits and energy certificates, so we began researching and building prototypes for a marketplace.

It was very early. The main lessons were twofold. First, the interaction between blockchains and the real world is complex. Connecting on-chain systems with off-chain data introduces trust assumptions, shifting from a trustless environment to a trusted one. This must be managed with care. Second, large enterprises understand the value, but they tend to proceed slowly. They favour small research projects and pilots over full-scale commitment. They are very deliberate and systematic.

Determinism and reproducibility are at the heart of Cartesi’s design. What were the most complex engineering challenges in making a Linux-level environment both verifiable and trustless?

That is an excellent question. The simpler an architecture is, the easier it is to verify. That is why the EVM design is quite straightforward and well considered, even if there are aspects we would do differently today.

We were not experts in computer architecture, but many specialists exist worldwide. We selected an established ISA, RISC-V, which balances simplicity and power and has gained widespread adoption. Our goal was to develop a deterministic RISC-V emulator, which was a significant engineering challenge. The person leading this effort is one of our founders, Diego, an experienced engineer and former professor. Achieving accurate floating point operations, supervisor privileges, and performance bottlenecks under strict determinism proved difficult. Running Linux deterministically on this machine was particularly challenging.

How does the microarchitecture layer, or “uarch”, strengthen Cartesi’s fraud-proof system while keeping on-chain verification costs low?

Our emulator is built on RISC-V, a standard instruction set. During a fraud-proof game, we need to verify the correctness of a single instruction on-chain in Solidity. Every time we added a new feature to the emulator, we had to ensure the Solidity implementation remained correct and compatible. This created complexity. Therefore, we introduced a simpler micro-architecture in Solidity. It allowed us to continue improving the emulator while keeping the on-chain verification logic minimal and easier to understand.

Now we are moving away from this because we can use ZK proofs for sets of instructions. Instead of proving each instruction optimistically in Solidity, we can prove segments of computation with ZK. That improves performance and keeps security at least as strong as before.

The Honeypot challenge turned the PRT system into an open contest, allowing anyone to try to break it. What did that experiment reveal about security and developer behaviour in a permissionless environment?

I really like the honeypot idea. Most rollups launch in what people call stage 1. They have fraud proofs or ZK proofs, but they also have a security council that can intervene. In stage 2, the system is fully permissionless and decentralised, and the team has no control.

In stage 1, if someone attempts to steal funds, the security council can block the attack. Attackers are aware of this, so they might choose not to exploit a bug. Instead, they may discover a bug, keep it secret, and wait until the rollup advances to stage 2, then strike when there is no safety net. Our argument is that you can never truly be sure of your safety while a security council exists.

In Cartesi’s honeypot, we built a completely permissionless system without an emergency brake. If someone discovers a bug and steals the funds, we cannot halt them. We also explicitly inform people that there are no legal consequences for draining the honeypot.

That transforms it into a pure incentive game. It establishes a financial benchmark for security. If there is one hundred thousand dollars in the honeypot and nobody has stolen it, a new app chain can deduce that attackers are more likely to target the honeypot up to that amount than the new app, because the honeypot is risk-free from a legal standpoint.

You recently introduced a bond mechanism for PRT participants. How do these incentives create a fair balance between openness and security, and how might they evolve as Cartesi prepares for production rollups?

Fraud prevention follows a simple rule: anyone should be able to defend the system. You only need one honest participant to protect it. That is powerful. However, blockchains are permissionless and anonymous, so you face Sybil attacks. Someone can create many fake identities and repeatedly join the protocol, forcing honest participants to spend gas and computational effort to counter them.

Bonds limit that. Everyone who joins the dispute game must post a stake. This reduces the number of Sybils they can create. There is a delicate balance. If the bond is set at fifty million dollars, then only someone like Elon Musk can afford multiple identities, and normal people cannot join at all. If the bond is too small, Sybil attacks become cheap. So we aim for a bond size that discourages Sybils but still allows real people to participate.

In a recent blog post, Cartesi is said to have renewed focus on serving Ethereum first. What drove that decision, and how do you define Cartesi’s role within Ethereum’s broader execution stack?

I have some fresh insights after DevConnect. As an industry, we went through a period where we were desperate for adoption. During that time, we started to compromise on core values such as decentralisation and censorship resistance. We added centralised components for a better user experience, and it became easy to question why we were not simply using AWS.

Cartesi was explicitly designed to uphold those values while offering powerful computation. Ethereum is the ecosystem that most earnestly embraces those values. It possesses high integrity, talented researchers, and a culture that values transparency and safety. Cartesi aims to extend Ethereum while maintaining its guarantees. If we abandon that, there are many simpler ways to run Linux.

How do you balance prioritising Ethereum while having Cartesi remain ‘general purpose ’?

Cartesi is fully open source. Anyone can use it to spin up an app chain. All our code and research are accessible, and we respond to questions from all ecosystems, not just Ethereum.

Many other ecosystems are EVM-based or EVM-compatible. By building on Ethereum and maintaining strong decentralisation and trustlessness, we develop a system that can also integrate with those ecosystems. We are not excluding them; we are simply refusing to compromise on the core guarantees.

For a builder deciding between an EVM-native rollup and Cartesi, what is the most apparent reason to choose Cartesi today, and what remains the most significant friction point to overcome?

The most evident reason is the power of the Cartesi Machine. It enables you to do much more than a traditional EVM environment. You can utilise other programming languages and reuse open-source code created for the Web2 world. The EVM is a very specific virtual machine. It has excellent tooling in Web3, but you often have to reinvent the wheel when you require new capabilities.

On Cartesi, you can utilise existing libraries and frameworks. For example, although on-chain AI remains mostly a concept, you can already import something like TensorFlow into a Cartesi application and experiment.

The tradeoff is that we had to spend considerable time developing Web3 tools that other EVM chains freely inherited from Ethereum. Meanwhile, EVM rollups now face a new obstacle. Many of them simply replicated Ethereum and made it more affordable. It is difficult to stand out. Cartesi was different from the very beginning.

As the team works toward the v3.0 contracts and the Stage 2 rollup milestone, what technical or operational benchmarks must be met before Cartesi can be considered fully production-ready?

Cartesi is a platform for building app chains. Our end goal is for you to press a button and have an app chain rollup running your application on the Cartesi Machine. We are very close. Currently, we have a stage 2 app chain that serves as the honeypot, but we are still finishing the final pieces needed to generalise it to any application. I expect it to be ready soon.

Finally, if someone leaves DevConnect remembering only one thing about Cartesi, what should it be?

Stay tuned for stage 2. Do not compromise on safety or decentralisation. Let us build systems we cannot control.