Cowrie Research

cartesi

3 min read

Cartesi

  • Name: Cartesi
  • URL: https://docs.cartesi.io/
  • Category: optimistic rollup framework / Linux VM execution environment / application-specific rollup runtime / fraud-proof verifiable-compute infrastructure
  • Summary: Cartesi is best understood not as a generic L2, but as a split between base-layer rollup contracts, an off-chain deterministic RISC-V Linux machine, and node middleware that turns on-chain inputs into off-chain execution plus proof-carrying outputs. That makes it a useful comparison point for systems that want full Linux and traditional software stacks without giving up blockchain verifiability. The strongest analytical wrinkle is that Cartesi’s architecture exposes both the long-run permissionless fraud-proof path (PRT / Dave) and the nearer-term authority / quorum settlement modules and node-side epoch control, instead of hiding those layers behind generic scaling rhetoric.
  • What it does:
    • Lets each dApp run backend logic inside the Cartesi Machine, a deterministic RISC-V virtual machine that boots Linux and processes ordered inputs off-chain
    • Uses InputBox, CartesiDApp, factory, and portal contracts to accept inputs, custody assets, and connect base-layer assets and outputs
    • Uses the Rollups Node to relay advance-state and inspect-state requests, store vouchers / notices / reports, and expose GraphQL / REST interfaces for frontends and validators
    • Supports application-specific optimistic-rollup-style flows where outputs can be validated or executed on-chain after the relevant verification period
    • Maintains separate fraud-proof documentation around Permissionless Refereed Tournament (PRT) / Dave as the permissionless dispute-resolution path
  • Key claims:
    • Full Linux support is the core differentiation: Cartesi moves verifiable application logic into a deterministic off-chain Linux VM instead of asking developers to live entirely inside the EVM.
    • The real control surface is split across contracts, machine, and node middleware. Input ordering, epoch closure, output proof access, portal design, and settlement-module choice matter as much as the VM itself.
    • Current first-party materials show an important transitional reality: the contracts support authority- and quorum-based settlement modules, while the current Rollups Node says it only supports Authority consensus for epoch closure and claim submission. That makes Cartesi more analytically useful as a modular off-chain-compute stack with a staged path toward permissionless fraud proofs than as a flat trustless rollup label.
    • PRT matters because it tries to repair classic multi-party fraud-proof Sybil fragility by moving from player-bound final-state claims to computation-hash commitments and bracket-style tournament disputes.
    • Cartesi cleared the bar for the active corpus because it exposes a distinct design branch: full Linux execution, application-specific rollup runtimes, asset portals, proof-carrying vouchers / notices, and explicit dispute / settlement modularity.
  • Whitepaper: Cartesi publishes an official whitepaper and separate docs for Cartesi Rollups, the Cartesi Machine, rollups contracts, the Rollups Node, and fraud proofs / PRT. See ../whitepapers/cartesi-primary-sources-2026-05-12.md and official PDF ../whitepapers/cartesi-whitepaper.pdf.
  • Sources:

Internal linkages

  • Modular-rollup and appchain-toolkit contrasts that choose different boundaries between execution environment, DA coupling, full-node responsibility, and sequencer policy: sovereign-sdk and rollkit

  • Lower-layer primitive stack cousin where many of those choices are left intentionally unbundled instead of shipped as a Linux rollup runtime: commonware

  • Last reviewed: 2026-05-12 UTC

Graph View

Backlinks