Cartesi Rollups are not just another place to deploy Solidity
Cartesi is best understood as an application-specific optimistic rollups framework with a Linux runtime, not as a shared smart-contract chain in the usual sense. The onchain side is still EVM-based, but the application logic runs inside the Cartesi Machine, a deterministic RISC-V virtual machine that can boot a full Linux OS.
That distinction changes what “deploying smart contracts on Cartesi” really means. In practice, you deploy a Solidity-facing control plane on an EVM chain, while the dApp back-end consumes onchain inputs and produces vouchers, notices, and reports offchain inside the Cartesi runtime. Cartesi’s rollups contracts provide the data-availability, consensus, and settlement layer, while the application logic behaves more like a verifiable Linux back-end than a conventional monolithic Solidity contract.
Cartesi appchains can be anchored directly to Ethereum mainnet or deployed on lower-cost EVM rollups such as Optimism, Arbitrum, and Base. The latest deployment docs list pre-deployed rollups contracts for Ethereum Mainnet 1, Sepolia 11155111, Optimism 10, Optimism Sepolia 11155420, Arbitrum 42161, Arbitrum Sepolia 421614, Base 8453, and Base Sepolia 84532.
Cartesi’s technical history is a progression from “Linux on blockchain” thesis to live app-specific rollups
Cartesi’s original whitepaper was published in 2018, and the core idea was already visible there: use a RISC-V machine so a real operating-system stack, including Linux tooling, can be executed in a verifiable environment. The later documentation still treats that 2018 whitepaper as the project’s architectural origin.
On January 5, 2022, Cartesi publicly framed its strategy as solving both computation scalability and what it called “content scalability,” meaning access to mature software stacks rather than forcing every serious application into a niche VM with limited libraries. On October 12, 2022, it sharpened that position into an explicit defense of application-specific rollups with dedicated compute.
The first major execution milestone arrived on September 27, 2023, when Cartesi launched Honeypot as its first rollup dApp on Ethereum mainnet. Cartesi’s own ecosystem recap then described that launch as the project’s move to a “mainnet ready” stage for developers deploying app-specific rollups.
During 2024, the live ecosystem broadened. Cartesi’s year-in-review highlighted RIVES launching on Base mainnet and Bug Buster launching on OP Mainnet, which matters because it showed Cartesi being used for actual product categories rather than only demos: gaming in one case, security tooling in the other.
On June 19, 2025, Cartesi launched the PRT Honeypot as its first rollup application with built-in PRT fraud-proof security on Ethereum mainnet. That strengthened the decentralization story. But on October 21, 2025, Cartesi published a postmortem showing that a liveness bug in the PRT dispute game had permanently frozen that specific deployment while preserving safety. This is the most important recent fact about Cartesi’s security maturity: the architecture advanced, but implementation risk remained real.
What you actually deploy on Cartesi is a hybrid stack, not a single contract artifact
| Layer | What gets deployed | Why it matters |
|---|---|---|
| Onchain contracts | Application contract plus InputBox and asset portals for ETH, ERC-20, ERC-721, and ERC-1155. | Cartesi keeps the settlement and asset boundary on EVM, so you still need smart-contract literacy and ABI-aware tooling. |
| Offchain runtime | A Cartesi Machine running Linux on RISC-V, where the dApp back-end executes as a standard Linux application. | This is the real differentiator. The dApp logic can use mainstream languages, libraries, filesystems, debuggers, and operating-system primitives. |
| Infrastructure | For self-hosted deployment, Cartesi requires a funded wallet, cloud server, PostgreSQL database, and web3 provider. The docs suggest at least 8GB RAM as a starting point, depending on the machine and workload. | You are running real backend infrastructure, not merely publishing bytecode to an RPC endpoint. |
| Developer flow | The normal path is create → build → run → send → deploy. The cartesi build step produces a genesis machine hash, and code changes produce a different hash that requires redeployment. | Cartesi behaves more like shipping a deterministic application image than editing a contract in place. That is powerful, but operationally heavier. |
| Read and write model | Users submit inputs onchain through the InputBox or portal contracts. Back-ends emit vouchers, notices, and reports. GraphQL is the scalable read path, while Inspect requests are serialized and more limited. | The front-end and back-end do not talk directly. That improves verifiability, but it also means web2-style interaction patterns need adaptation. |
Cartesi’s CLI templates cover a fairly wide language surface today, including cpp, go, javascript, lua, python, ruby, rust, and typescript. That is unusually broad in smart-contract land, and it is one of the stack’s clearest advantages for teams that already own non-EVM code or want to use mature libraries without rewriting them for Solidity.
There is, however, an important present-day constraint. The current deployment docs still say third-party service-provider deployment is under development, which means the default serious path is still self-hosting your app node and its supporting infrastructure.
The real advantages are broader programmability, dedicated compute, and a better fit for heavy workloads
- Cartesi gives developers a mainstream software environment. The Cartesi Machine exposes Linux, standard libraries, GCC and Clang toolchains, GDB, filesystems, processes, and familiar languages. If your product actually needs existing Rust, C++, Python, or JavaScript libraries, this is not a cosmetic benefit. It changes what is economically feasible to build without reimplementing everything for the EVM.
- Cartesi’s appchain model avoids shared-VM congestion inside the execution layer. Cartesi’s own architecture and appchain docs explicitly frame application-specific rollups as a way to eliminate resource contention that occurs when thousands of apps share one VM. For compute-heavy apps, that gives more predictable throughput and cost control than competing for scarce execution on a general-purpose chain.
- Cartesi is structurally well-suited to categories that do not fit neatly into pure Solidity. Gaming, richer simulation logic, advanced matching engines, algorithmic workloads, and AI-adjacent back-ends are more plausible in a Linux VM than in a minimal contract VM. Cartesi itself positions the stack for “complex, high-performance decentralized applications,” and the live ecosystem examples support that claim.
- Asset handling is opinionated and already wired into the framework. Portals exist for ETH, ERC-20, ERC-721, and ERC-1155, and the contracts layer supports deposits, withdrawals, voucher execution, and output validation. For teams that want an app-specific rollup but do not want to reinvent the asset bridge boundary, that matters.
- Cartesi lets teams choose a host chain that matches value at risk. The same stack can target Ethereum when security dominates or lower-cost EVM layers when user acquisition and cheaper interactions dominate. That is a practical advantage for product design, not a theoretical one.
- From an incentives perspective, Cartesi can be healthier than “rewards-first” architectures when the workload is real. This is an inference, but it follows from the design. If a product genuinely needs more expressive computation and richer software, the architecture itself produces user value. That is a much sounder base for a token economy than asking perpetual emissions to subsidize an app that never needed an appchain in the first place.
The downsides are operational weight, weaker composability, and security assumptions that vary by deployment
- Cartesi is heavier to operate than ordinary contract deployment. Self-hosted deployment requires a server, PostgreSQL, a web3 provider, a funded wallet, and ongoing node operations. This is not comparable to publishing a few contracts and letting someone else maintain the chain.
- The execution environment is verifiable, but it is not fast in native terms. Cartesi’s performance recommendations explicitly say to expect software inside the Cartesi Machine to be at least 50x slower than bare metal. The docs also recommend compiled languages such as C++ or Rust for performance-critical production dApps. Cartesi expands what is possible in Web3, but it does not turn heavy code into free compute.
- Composability is weaker than on a shared EVM. Cartesi’s appchain docs are explicit that each appchain is logically isolated and that messaging across appchains or between an appchain and another dApp may require custom bridges or relayers. That is a meaningful drawback for DeFi products whose edge depends on synchronous composability.
- Optimistic settlement still means time. Cartesi uses optimistic-rollup logic, so outputs need to be validated before execution. The docs note that withdrawals can take time depending on epoch duration, and optimistic rollups by design rely on a challenge window rather than instant finality.
- The read path has clear scaling asymmetries. Cartesi’s docs say the GraphQL server scales well and can handle thousands of requests per second, but the Inspect server is still basic, serializes requests one at a time, and may reject bursts. The same page also notes that the framework does not support subscription-style status updates. That is manageable, but it is a real application-design constraint.
- Security on Cartesi is deployment-specific. The generic rollups-contracts package currently exposes Authority and Quorum settlement modules, while Cartesi’s broader fraud-proof work is documented separately under PRT and Dave. In other words, “built on Cartesi” does not automatically mean “permissionless fraud proofs everywhere.”
- The public evidence already shows mixed maturity. L2BEAT’s Bug Buster review says invalid state roots are still possible under its Authority setup and that the owner can change consensus. On the other side, the PRT Honeypot reached Stage 2, but Cartesi’s own October 21, 2025 postmortem says a liveness bug froze that deployment permanently while preserving safety. That combination tells you exactly where Cartesi stands today: serious progress, but still not a stack where every production deployment deserves uniform trust.
The practical implication is straightforward. If your application is a relatively standard AMM, lending market, staking contract, or simple NFT system, Cartesi is usually too much machinery for too little incremental value. If your application genuinely needs richer software, long-running logic, complex validation, or a game-like back-end, the trade-off starts to make sense. That is not ideology. It is workload matching.
The best-known deployments show where Cartesi actually fits
| Project | Base chain | What it shows about Cartesi |
|---|---|---|
| Honeypot | Ethereum Mainnet | Honeypot was introduced on September 27, 2023 as the first Cartesi Rollup dApp on mainnet. The later PRT version launched on June 19, 2025 as a Stage-2 security test, then froze after a liveness bug disclosed on October 21, 2025. This makes Honeypot both Cartesi’s strongest proof-of-concept and its clearest maturity caveat. |
| RIVES | Base Mainnet | RIVES is an onchain fantasy console that runs in a Cartesi-powered rollup on Base. Cartesi’s 2024 review highlighted it as the platform that brought DOOM onchain, which is a very direct demonstration of Cartesi’s gaming and creator-tooling fit. |
| Bug Buster | OP Mainnet | Bug Buster is a web3 bug bounty platform powered by Cartesi Rollups. It demonstrates a non-gaming use case, but L2BEAT’s review also shows that the deployed trust model matters: the reviewed system still relies on an Authority contract and centralized operator assumptions. |
The ecosystem is still smaller than that of general-purpose L2s, but the pattern is already visible. Cartesi appears strongest in categories where verifiable computation, gaming logic, richer back-ends, or application-specific workflows matter more than raw shared-state composability. The public examples are far less convincing for plain-vanilla DeFi primitives that already fit comfortably inside Solidity.
The deployment decision is ultimately about whether the application can justify the stack
Cartesi Rollups are a good choice when the application’s core product value comes from more expressive compute, access to mature software, or dedicated execution. They are a weak choice when the application mostly needs shared liquidity, simple contracts, or fast path-of-least-resistance deployment inside the EVM. The technology widens the design space. It does not eliminate trade-offs.
From FinDaS Tokenomics’ perspective, that boundary is where token economy design components start to matter. A Cartesi appchain should eventually justify its own server footprint, database layer, dispute monitoring, and base-layer transaction costs through real usage, fees, or some other productive cash flow. If the only way to keep the system alive is grants, emissions, or recurring subsidy programs, then the problem is not a lack of narrative. It is a weak long-run equilibrium. That is the first question serious tokenomics consulting should ask before anyone reaches for rewards.
At FinDaS Tokenomics, we would frame the decision this way: deploy on Cartesi only if the application’s compute intensity and software requirements are material enough to pay for the extra architecture once incentives fade. Our tokenomics consulting follows that filter. When that answer is yes, Cartesi is one of the more interesting alt-VM designs in Web3. When that answer is no, simpler EVM-native deployment is usually the more sustainable choice.
This article is part of our Choosing The Right Blockchain series.
