Why can't most DeFi deliver real innovation? The yellow dot is the L1 EVM block compute limit, forcing developers to compress logic into a single block and ship simplified finance.
The blue grid is the Cartesi VM, offering orders of magnitude more computational capacity. Once you see the gap, you can't unsee the constraint.
If your stack won't let you build with Linux onchain, it ain't the one. 🐧
No more rewriting your code from scratch or compromising on libraries. With Cartesi, we took the entire Linux runtime and brought it straight to Ethereum and Web3. If it runs on Linux, it runs onchain.
Spread the word: https://x.com/cartesiproject/status/2112891152445894867
Want the tl;dr on our Q3 Engineering Report? What actually shipped, and where the stack stands after 130 merged PRs, 673 commits, and 58 releases across 13 repos?
Look no further. Here’s the summary, organized around the 3 technical pillars 🧵↓
Safe infrastructure for real money
Deposit refunds close the last gap in emergency withdrawals. Once an app is foreclosed, anyone can refund unfinalized ETH, ERC-20, ERC-721, and ERC-1155 deposits to the people who made them.
Claims got stricter too. A claim now has to prove the machine finished its epoch normally. A state that halted, threw an exception, or rejected its last input can’t be finalized.
Dave (PRT) added claim staging and harder-to-game bond recovery. The Sling node is now the first operational PRT validator, in testing on the way out of alpha.
Economical computation at scale
Cartesi Machine v0.21.0 makes every input end in a provable outcome, even when the app crashes. Rejected inputs revert to the previous state. Inputs that run out of cycles stop in a fixed state. The emulator and the onchain step apply the same rules.
Apps can now keep state in NVRAM across inputs, which makes carrying state from one input to the next cheaper.
The sequencer shipped a fee oracle that ties user fees to L1 posting costs. It’s priced from a Uniswap V3 TWAP to limit manipulation. Next stop: a live testnet.
Easy stack for shipping onchain in a day
The rollups node moved to emulator v0.21 on its dev branch. It gained JSON-RPC batch requests and now runs every service under one supervisor, with clear health signals for Kubernetes.
The TypeScript libraries now use generated bindings, replacing about 1,800 lines of hand-written wrappers. And cartesi/machine runs a Cartesi Machine from Node.js, or right in a browser tab.
Next up: a coordinated public release of node, SDK, CLI, and explorer release that ships all of this to builders.
For the bigger picture behind these pillars, check out our Technical Plan: https://cartesi.io/technical-plan/
As the SDK matures, there’s a new way to track Cartesi’s progress. Introducing the Quarterly Engineering Reports, covering every tech workstream, achievement, and milestone. 130 merged PRs. 673 commits. 58 releases.
Get the full Q3 2026 breakdown ↓ https://blog.cartesi.io/engineering-report-q3-2026/
For a bird’s-eye view of Cartesi’s tech priorities, explore the Technical Plan and the 3 pillars guiding our roadmap: → Safe infrastructure for real money → Economical computation at scale → An easy stack for shipping onchain in a day 🔗 cartesi.io/technical-evolution-plan
First time breaking down the Cartesi sequencer! Let’s unpack what it is, why it matters, and how it works. 🧵↓
1/ Interactive apps need speed. Ethereum settlement takes time. Nobody wants to wait minutes for L1 finality on every click. That’s where a sequencer comes in.
2/ The sequencer takes signed user operations and confirms them right away (soft confirmation).
In the background, it posts them to L1 in batches. Users get a near-instant response, and Ethereum stays the source of truth.
Full scoop on our sequencer: https://github.com/cartesi/sequencer
3/ What happens technically? Each group of user ops (a frame) points to a safe L1 block. The onchain scheduler takes in deposits up to that block, then runs the same ops in the same order.
The sequencer and the rollup follow the same rule, so both end up with the same state.
4/ There’s a single sequencer, but it can’t steal funds or forge state. The rollup checks everything, and fraud proofs enforce the result.
Deposits skip the sequencer entirely. A censoring sequencer can delay them by a few hours at most. It can never block them.
5/ The Cartesi sequencer is still alpha, but it’s progressing fast.
It plans for L1 outages, crashes, reboots, long downtime, and hostile mempools. On every startup, it checks its database and Ethereum to identify what needs fixing.
A separate watchdog double-checks its state.
6/ The latest release, v0.1.0-alpha.10, ships the sequencer, machine images, and watchdog together.
New: public fee quotes, app history with replay, C app bindings, a rewritten watchdog, and Cartesi Machine v0.21.0. Breaking changes.
Read the notes first: https://github.com/cartesi/sequencer/releases/tag/v0.1.0-alpha.10
Deep dive moment: Felipe Argento, co-founder of Knoss, breaks down why options are still so hard to build in DeFi.
For years, he's given friends the same answer about crypto: "ETH to a million or zero."
Problem is, there's no trustless way to place that bet onchain. 🧵↓
1/ Spot ETH covers the million. Holding nothing covers the zero. Perps add leverage in one direction. None of it covers the "or."
Options do. Buy a call and a put at the same strike and you win if ETH moves hard either way. Sell the same pair and you get paid while it goes nowhere.
2/ In TradFi, options trade about 3x as many contracts as futures. Onchain, they barely register, because the math is hard to run trustlessly: implied volatility, volatility surfaces, and portfolio margin.
So builders either simplify the math and overcollateralize everything, or run it on a server users have to trust.
3/ Now Knoss will run that math on Cartesi, so every step can be reproduced and proven on Ethereum. Users will get the capital efficiency without the black box.
It's an exchange for options and perps, built the Ethereum way. Follow Knoss and catch up on more details here: https://x.com/knoss_xyz/status/2105638543477399621
September was a big one. Dive into the latest ecosystem updates, from our website's refreshed look and feel to Knoss, a derivatives exchange built on Cartesi. Plus tech progress, media highlights, and community moments.
There's a lot to catch up on ↓ https://blog.cartesi.io/ecosystem-updates-september-2026/
Starting today, https://cartesi.io/ has a fresh look, rebuilt around what matters right now: a cleaner layout, simpler navigation, and a direct answer to what Cartesi is and where it's headed in tech and strategy. What you'll find ↓
→ The next stage for Cartesi: why the Foundation is backing Knoss, a derivatives exchange built on Cartesi Rollups by Felipe Argento, Brandon Isaacson, Eduardo Bart, Danilo Tuler & Pedro Argento to prove the stack under real commercial conditions
→ Where the tech stands: the integrated Rollups and fraud-proof stack, with security testing and hardening as top priorities
→ The core idea, in plain words: conventional software in a reproducible Linux environment, settled on Ethereum
Take a look around and let us know what you think.
While you're at it, read the latest blog post, which explains it all about the next stage for Cartesi: https://blog.cartesi.io/the-next-stage-for-cartesi/
Another week of heads down building is in the books and here's your Cartesi Weekly 🐧
Dave v3.0.0-alpha.5 just rolled out. This node-only release fixes stuck bond refunds across epochs: the node now finishes each epoch, waits for final settlement, and recovers its bonds before moving on. If restarted, it picks up right where it left off.
Contracts and the Cartesi Machine remain unchanged. Upgrading from alpha.4 requires a fresh state directory, with one per signer. Kudos to our contributor Gabriel Coutinho for the work on it. See GitHub: → https://github.com/cartesi/dave/releases/tag/v3.0.0-alpha.5
Don’t remember what Dave is? Quick refresher: it’s our fraud-proof system, with the repo tracking advancements to the Permissionless Refereed Tournament (PRT). Check out this short recap: → https://x.com/cartesiproject/status/2097309822626754802
Why does DeFi need Cartesi? Most DeFi runs a simplified version of finance, because builders design around what the chain can run instead of what they actually need. Revisiting an article from contributor João Garcia, our thread highlights what changes when each app gets its own Linux rollup settled on Ethereum: collateral that moves with volatility, prediction markets with a real matching engine, continuous DCA, and credit scores anyone can rerun. Give it a read: → https://x.com/cartesiproject/status/2102774515893953016
Spotted in the wild on Instagram: community-made Cartesi NFC keychains that take you to our website with a single scan. We love seeing this. Give the creator a follow, and make sure you're following us there too: → https://instagram.com/cartesiproject/
Our gm this week kept it simple: every day is a good day to build with Cartesi and that’s what we did throughout the week: → https://x.com/cartesiproject/status/2102019534693814436
That's all for now. Join us on Discord or here on Telegram if you want to keep the conversation going. Have a great weekend.
Most DeFi runs a simplified version of finance. Builders design around what the chain can run, not what the model needs. They cut the math, or run it offchain and ask for trust.
Contributor João Garcia broke it down in an article worth revisiting: → https://x.com/joaopdgarcia/status/2018688089258865078
TradFi quant teams run risk engines across thousands of scenarios with NumPy, SciPy, and QuantLib.
Most smart contract environments lack those libraries for real math operations, and state gets expensive.
On Cartesi, each app gets its own rollup running Linux, settled on Ethereum. Any honest validator can enforce the correct result.
Builders write logic in Python, Rust, or C++ with popular libraries. Now an onchain bonding curve can get much closer to a true quadratic curve.
What this makes practical: - Collateral requirements that move with volatility - Prediction markets with a matching engine and odds updated every epoch - DCA that buys in tiny continuous slices instead of once a day - Credit scores from a model anyone can rerun
Devs still have to design the hard parts: how data gets in, how inputs get validated, how execution is coordinated. More compute moves complexity around. But if your app needs real computation, that's what Cartesi was built for.