Window: 1 July – 30 September 2026 Scope: Cartesi Rollups stack and related components
In this report
- Summary
- Q3 in Numbers
- Pillar 1: Safe Infrastructure for Real Money
- Pillar 2: Economical Computation at Scale
- Pillar 3: Easy Stack for Shipping Onchain in a Day
- How the stack interlocks
- Appendix A: GitHub activity
- Appendix B: Delivery ledger
- Appendix C: Releases by product
- Scope limitations
Summary
Q3 2026 is reported against the three current technical priorities in the Technical Plan. The quarter released Cartesi Machine v0.21.0 and moved settlement and fraud proofs onto it.
Safe Infrastructure for Real Money. Deposit refunds complete emergency withdrawal at the contract layer, and a claim must now prove that the machine has finished its epoch normally before it can be finalized. The Fraud-Proof System v3 gained claim staging, hardened bond recovery and its first operational validator, the Sling node, and continues on its alpha track.
Economical Computation at Scale. In Cartesi Machine v0.21.0, every input ends in a provable outcome, even in the event of exceptions or app malfunction, and applications can keep state in persistent memory (NVRAM) across inputs. The sequencer released a fee oracle and merged fail-stop handling, and is progressing through testing toward a live testnet.
Easy Stack for Shipping Onchain in a Day. The rollups node moved to emulator v0.21 on its development branch and laid the groundwork for a second fraud-proof validator. The TypeScript libraries were restructured and published as alpha packages, including Node.js and browser bindings for the Cartesi Machine.
The next milestones span all three priorities. The Fraud-Proof System works toward leaving alpha, with the rollups node joining as a second validator. The sequencer moves to a live testnet that pairs fast soft confirmations with fraud-proof settlement. A coordinated node, SDK, CLI and explorer release brings deposit refunds and the v0.21 machine to developers and operators.
Q3 in Numbers
The following GitHub activity highlights the evidence of the work across the official repositories reviewed this quarter.
Pillar 1: Safe Infrastructure for Real Money
Objective
Financial applications need recovery paths and dispute resolution that hold under adversarial conditions.
In Q3, the objective was to extend recovery to deposits that were not yet processed when an application stops, and to harden the Fraud-Proof System and integrate it across the stack.
Key Q3 Deliveries
Emergency Withdrawals: Deposit Refunds. Foreclosure stops an application so that users can exit. Until Q3, a deposit that reached a foreclosed application without being covered by a finalized claim had no recovery path. Deposit refunds, released in contracts v3.0.0-alpha.7, close that gap: finalized deposits are recovered through the account-proof withdrawal path delivered in Q2, and unfinalized Ether, ERC-20, ERC-721 and ERC-1155 deposits can be refunded to their depositors by anyone once the application is foreclosed. Node support, which makes refunds available end to end, is in progress in rollups-node #798, and the explorer added a foreclose action for the application's guardian and a withdrawals view for its next release.
Rollups Contracts: Distribution. From alpha.7, the @cartesi/rollups npm package is retired: each release ships artifacts and deterministic deployment addresses on GitHub, source on Soldeer and Rust bindings on crates.io. The v3 pre-releases are deployed on the Ethereum, Arbitrum, Base and OP Sepolia testnets.
Claim Validity. A claim used to prove only that an outputs root belonged to the claimed machine state, not that the machine had finished the epoch normally. The machine yield check closes that gap: a claim now also proves that the machine yielded with its last input accepted, and takes the outputs root from that proven state. A state that halted, raised an exception or rejected its input therefore cannot be claimed under Authority or Quorum, and Dave #282 applies the same check to tournament results. If a malformed state is the only result, the application can be foreclosed and users exit through withdrawal and refunds.
Fraud-Proof System v3. Dave released the pre-releases v3.0.0-alpha.4 and v3.0.0-alpha.5, both built on contracts alpha.10. Dave settles disputes with PRT (Permissionless Refereed Tournaments).
Claim staging gives PRT applications the observation window that Authority and Quorum gained in Q2. Settlement becomes two-phase, replacing the single settle call: a tournament result is staged first and accepted after a staging period, or immediately if every designated sentry confirms the same final state. Sentries can speed up acceptance but cannot block or change a result.
An internal review of the PRT dispute game hardened bond recovery (#273, #274): anyone can trigger it, the winner receives its bond plus 10% of the surplus, and the rest is burned so losing Sybil bonds cannot be recycled.
Validator Diversity. PRT is being built toward two independent validator implementations. The Sling node is the first operational PRT validator, now in testing and hardening on its way to production status. It rewrites Dave's Rust validator around one engine for both input execution and dispute recomputation, which were previously separate implementations that could diverge, and runs on emulator v0.21.0. The Go rollups node is being prepared as the second validator: deterministic input outcomes and the state proofs the new claim format requires are merged on its development branch, and dispute participation is in progress in #798.
Auditing and Battle Testing. Q3 security assurance combined internal reviews, agentic (AI-assisted) validation, and hands-on QA. The AI-assisted work used frontier models from OpenAI (GPT-5.6 Sol and GPT-6 Astra) and Anthropic (Claude Opus 4.8 and 5.5, Sonnet 5, and Fable 5.1), on Codex Pro and Claude Max. The team validated the dave sling node (the PRT fraud-proof validator) and extended the test catalog of the v3 rollups contracts and v2 reference node, covering the foreclosure lifecycle, deposit refunds, and the machine validity proof. Most of the surfaced findings have already been fixed and re-verified; the remaining items have been forwarded to the protocol team and are being worked through ahead of the fraud-proof system leaving alpha.
Why it Matters
With refunds, a foreclosed application no longer strands deposits that arrived after its last finalized state. With the validity check, no consensus type can finalize a post-epoch state in which the machine halted, raised an exception or rejected its last input. Staging gives PRT applications a window to detect a bad result before it is final, and the bond-recovery changes keep tournaments live and Sybil attacks costly before PRT secures real funds. Deterministic node records are a precondition for a second validator, because two honest nodes must never durably disagree about an input.
Next Milestone
The next milestone for Emergency Withdrawals is end-to-end availability of deposit refunds: the node update in #798, followed by CLI and explorer support and refund documentation.
The next step for the Fraud-Proof System v3 is leaving alpha, which includes resolving the internal QA findings on the Sling node. Its integration with the rollups node is in #798, and support in the TypeScript clients, CLI and explorer is in open pull requests. PRT targets Ethereum today, with other chains experimental. A delay-only safety gate for L2BEAT Stage 1 deployments is proposed in dave #271. For validator diversity, the next step is for the Go node to respond to disputes as well as observe them.
Battle testing continues through a local PRT lab that runs honest Sling nodes against scripted fraudulent players.
Pillar 2: Economical Computation at Scale
Objective
Real financial logic has to be cheap enough to run every block, and interactive applications cannot wait minutes for L1 finality on every user action.
In Q3, the objective was to establish the next machine version for the stack to integrate against, and to prepare the sequencer for application testing on a live testnet.
Key Q3 Deliveries
Machine Emulator. machine-emulator v0.21.0 shipped with matching releases of the Solidity step v0.15.0, guest tools v0.18.0 and the Linux image, delivering the Q2 milestone of the next machine version. Its documentation now explains how the emulator is used in the fraud-proof verification game, with runnable examples.
The release makes every input end in a provable outcome, even in the event of exceptions or app malfunction:
- Revert on reject. When the guest rejects an input, the valid state is the state before that input. The emulator (#389) and the on-chain step (#98) now both apply this rule.
- Cycle limits. An input that exhausts its cycle budget stops in a fixed, provable state, with the same rule off chain (#394) and on chain (#100).
- Computation hashes. The
cartesi-machinecommand line computes the epoch commitments that PRT disputes compare, and releases ship reference cases that other implementations can test against.
Q3 also made NVRAM usable by applications: with guest tools and kernel support, an application can keep its state in a machine memory range across inputs without synchronising it through the kernel page cache.
Confirmation Latency: Sequencer for Low-Latency Soft Confirmations. The sequencer accepts signed user operations, confirms them immediately (a soft confirmation, given before L1 inclusion), and posts them to L1 in batches. A fee oracle, released in v0.1.0-alpha.9, ties the user fee to the L1 cost of posting batches, priced from a Uniswap V3 time-weighted average to limit manipulation. Staged for the next release, a fail-stop runtime stops issuing soft confirmations once a terminal fault is diagnosed, and replica support lets replicas and indexers follow the soft-confirmed history and detect when recovery replaces it. The sequencer is in its testing phase.
Why it Matters
The machine is the execution and proof base of the stack. With v0.21, rejected inputs and cycle limits have one provable behaviour in the emulator, the on-chain step and the fraud-proof node, and the reference cases let independent implementations check that they agree. NVRAM reduces the cost of keeping application state between inputs.
Linking fees to L1 cost lets user fees cover the cost of posting batches, and stopping on a diagnosed fault keeps soft confirmations from outliving the state they rest on.
Next Milestone
The next milestone for confirmation latency is a live testnet deployment where applications can test fast soft confirmations alongside fraud-proof settlement. The steps toward it are a release of the work merged after alpha.9 and a move to emulator v0.21.0 and the current contracts.
The ZK verification path, which proves a machine state transition inside a zkVM and checks it on chain in one call, continues in open machine-emulator #390, which proposes one step-log format shared by the emulator, the RISC Zero guest and a generated Solidity verifier.
Machine Emulator work continues on interpreter performance, currently on experimental branches.
Pillar 3: Easy Stack for Shipping Onchain in a Day
Objective
Developers and coding agents should be able to build rollup applications quickly, using the languages, libraries, and tools they already know.
In Q3, the objective was to integrate the next machine version into the rollups node, SDK, explorer and CLI, to improve node operation, and to simplify the TypeScript client libraries.
Key Q3 Deliveries
Rollups Node v2. All Q3 node work, including the move to emulator v0.21.0 (#791), is merged on the next/2.0 development branch and staged for the next release after v2.0.0-alpha.12. The next CLI and explorer releases build on that node release.
The JSON-RPC API gained batch requests of up to 100 calls, with shared limits so that a batch cannot multiply database work, and new query methods.
A single-process supervisor now runs all node services under one lifecycle. The readiness endpoint reports which services are failing, so orchestrators such as Kubernetes get accurate health signals, and a failed component no longer leaves a half-running node. With the replay verification described in Pillar 1, these changes meet the Q2 diagnostics goal on the development branch and advance restart resilience.
TypeScript Client Libraries. rollups-ts delivered the Q2 milestone of a clearer TypeScript interface. The alpha packages @cartesi/client and @cartesi/react replace about 1,800 lines of hand-written wrappers with viem contract calls on bindings generated from each contracts release, and @cartesi/codec encodes and decodes inputs, outputs and portal deposits. Two new packages bring Node.js to both sides of the machine: @cartesi/rollup lets an application inside the machine handle inputs and emit outputs directly through the rollup device, and @cartesi/machine runs machines from Node.js or, through a WebAssembly build, in a browser tab.
Agentic Development and Documentation. Emergency-withdrawal documentation was published (docs #343), with a six-step recovery guide, guest requirements and deployment steps, indexed in llms.txt for coding agents. Updates for current contracts and refunds are in open documentation pull requests.
Why it Matters
A developer should be able to depend on one compatible set of node, contracts, clients and tools. Generated bindings let each contracts release reach TypeScript developers without hand-written wrappers. The native and browser packages let developers run and test applications without the rollup HTTP server or a local emulator install. The node changes make it easier to operate and to query. These gains reach developers with the next node and CLI releases.
Next Milestone
The next milestone is the coordinated release of the rollups node, SDK, CLI and explorer on emulator v0.21, contracts alpha.10 and Dave alpha.5. The node release comes first, followed by the SDK, CLI, explorer and TypeScript client updates that build on it, which are in open pull requests; further updates will follow in Q4. The JS/TS templates are being moved to @cartesi/rollup.
How the stack interlocks
The diagram shows how Q3 releases depended on one another.
Appendix A: GitHub activity
Breakdown by repository. Headline figures are in Q3 in Numbers; counting rules are in Scope limitations.
Appendix B: Q3 2026 delivery ledger
Complete list of pull requests merged between 1 July and 30 September 2026 in the 13 repositories reviewed. This is the evidence backing the report above. Titles are shortened from the GitHub titles, and bold titles mark the headline deliveries described in the pillars. The Pillar column uses the TEP headings: Safe (Safe Infrastructure for Real Money), Econ (Economical Computation at Scale), Easy (Easy Stack for Shipping Onchain in a Day).
Automated release-versioning pull requests (Version Packages (alpha)) in rollups-ts are omitted from the table; the nine of them are counted in the totals. † cli #504 and #510 were merged into the branches of pull requests that were later closed without merging, so their changes did not reach the CLI mainline; they are counted as merged. Six rollups-ts pull requests, one rollups-explorer pull request, dave #283 and sequencer #35 were merged into stacked branches and reached the primary branch with their parent pull requests.
Appendix C: Q3 2026 releases
Cartesi Machine (emulator, solidity step, guest tools)
Settlement and fraud proofs (contracts, Dave)
Node and sequencer
Developer SDK and tooling (CLI, TypeScript, templates)
Explorer
Outside the 13 repositories, machine-linux-image v0.21.0, cartesi/linux v6.5.13-ctsi-2 and setup-action v1.0.0 to v1.2.0 were also released in the window; they are not counted.
Scope limitations
Documentation work in cartesi/docs and the QA and battle-testing work of the Developer Advocacy Unit in Mugen-Builders are described in the pillars and are not counted in the appendices. The internal QA of the Sling node is summarised at a high level and not itemised.
Merged PRs count every pull request merged in the window on any base branch, including merges into feature branches and the nine automated Version Packages (alpha) pull requests in rollups-ts. Commits are counted on each primary branch by committer date, so commits authored earlier but merged in Q3 are included; main is counted for rollups-contracts and dave, whose primary branch moved there from next/3.0 during the quarter.
Some Q3 releases include work merged in a previous quarter, such as NVRAM support in emulator v0.21.0; those pull requests are not counted, but the tags are. Of the 58 release tags, 33 are per-package tags of the TypeScript libraries and 12 are test tags of the machine components. All contracts and Dave v3 releases are GitHub pre-releases, and merged work awaiting release is identified as such in the pillars.
Execution of deployments to live networks is not recorded in these repositories and may live in operational systems outside GitHub. The sequencer is in its testing phase.