Expressive and Secure DeFi Appchains with Cartesi

Use Cases/Sep 25, 2025/Shaheen Ahmed

Disclaimer: This article is intended for app developers who want to explore and experiment in the DeFi space with optimistic rollups. It also shares author’s personal take on why the finality delay shouldn’t stop you from building cool and creative ideas.

Appchains are not a new concept in the blockchain space. Bitcoin is arguably the most popular app-specific blockchain, with a single application, i.e. serving as a public ledger. In contrast, Ethereum introduced a general-purpose blockchain where a wide range of applications could run in the form of smart contracts. Over time, however, we saw applications began moving out of this shared ecosystem. For example, Uniswap started as a smart contract DEX and evolved into a full-fledged Unichain. Similarly, Ronin was built for gaming, Zora for Web3 social, and many others across the Web3 ecosystem. But what drives teams to launch app-specific chains?

One of the primary reasons has been bad UX due to the high transaction fees when interacting with smart contract-based apps on Ethereum. Since usage fees for a shared resource increase with demand, costs naturally rise over time. This runs counter to the ethos of Ethereum as a public good. Decentralization shouldn’t burn a hole in your pocket, hence the motivation to detach resources. Additionally, interacting with Ethereum has been slower when compared to its L2 counterparts. The real superpower of appchains lies in customizability, meaning you can design an economic and governance model tailored to your specific needs. Check out this article on the introduction of Unichain, where you’d find a few reasons for switching over to an L2 appchain.

Key achievements for Unichain: Low cost, while furthering decentralization. Fast, with near-instant transactions and Seamless multi-chain swapping.

In this article, we’ll focus on appchains built on the optimistic rollups stack, with a particular emphasis on Cartesi as our go-to rollups framework. Today, spinning up an appchain is nearly as simple as deploying a smart contract. With the Cartesi Rollups SDK, you can build and deploy your own app-specific rollup quickly. Such a chain offers great performance, low operating costs, and customizable governance, all while being anchored to Ethereum for security. Sounds perfect, except for one major pain point: the week-long withdrawal period. The challenge period remains a limitation, but should it really stop you from realizing your next appchain big idea? Let’s find out.

Is finality delay a real challenge for optimistic DeFi?

Finality refers to the time it takes for a rollup’s state to be considered settled on the base layer(here, Ethereum). In other words, once finality is reached, the state transition can no longer be challenged. This process typically involves a challenge window and a dispute resolution process. The window must be long enough to allow challenges to be raised, but not so long that it ruins the withdrawal experience.

Too short of a challenge period, and you compromise security; too long, and you hurt usability.

The security aspect runs deeper than it first appears. Let’s consider the infamous censorship attack scenario: if the challenge period were too short, attackers could spam L1 with high-value transactions, inflating gas fees so much that honest challengers are locked out. Combine this with collusion among L1 nodes, and censorship becomes feasible. While such an attack sounds extreme, it’s possible when the value at stake outweighs the cost of the attack. To prevent this, optimistic rollups must allow enough time for a social response to withstand censorship attacks on L1.

With billions in TVL secured by Optimistic Rollup protocols, additional security at the cost of user experience is non-negotiable. That’s why most protocols standardize on a 7-day challenge window — not only to allow fraud-proof challenges, but also to defend against censorship.

That said, disputes can extend finality beyond 7 days, which is far from ideal for scalability. It sounds like a deal breaker while designing appchains, but it shouldn’t be generalised as such. Certain types of applications naturally align with given withdrawal times. Let’s look at two key determinants that shape user tolerance levels.

When time and security make the wait worthwhile

Keeping the protocol-level details aside, let’s see how a user would perceive this delay in withdrawal. We’ll look into two important scenarios.

My Money Will Make More Money Over Time

Traditional finance already uses time as a parameter in designing financial instruments. Withdrawing from a savings account may be instant, but maturing assets like fixed deposits require patience. Users are often willing to wait longer if their funds are compounding in value.

Compare Uniswap-like DEXs with staking apps. On a DEX, trades are instant, i.e. you can swap, take profits (or losses), and exit right away. In contrast, staking apps encourage long-term participation. When users are locked in for weeks or months, an extra 7 days for withdrawal feels little less like a deal breaker. It is fair to say that the longer the time horizon, the greater the willingness to tolerate an extra week for withdrawals. This doesn’t mean users can’t spend months swapping on Uniswap; rather, the point is that if an application keeps you engaged in its core function for much longer than the challenge period, a 7-day wait doesn’t seem so bad. We’ll look into concrete examples later.

My Money Is Secure with a Fraud-Proof System

The second determinant is security. It falls into the domain of why we even have a long challenge period. A challenge window allows fraud-proof systems to work as intended, i.e. making it decentralized to challenge invalid claims. It means that the rollup is plugged with a fraud-proof system that is easy to validate — only requires a modest laptop and some funds. In theory, it improves the participation of validators watching over the state of the appchain. Cartesi’s core researchers have introduced sybil-resistant Permissionless Refereed Tournaments and Dave fraud-proof systems that are designed to work on three critical parameters:

Decentralisation: A participant can take part in securing the appchain with a minimal set of resources
Security: One honest participant can defeat N number of attackers
Liveness: A dispute resolution is promptly settled within a defined time

Users may prefer a more secure system over depending on a fast withdrawal provided by a centralised setup. If the validator node(a participant in validating the appchain) misbehaves, users have little recourse. By contrast, a permissionless fraud-proof protocol empowers anyone to challenge invalid claims, distributing security guarantees across a broader set of actors.

Many DeFi apps are already designed for long-term engagement, months or even years. When app logic requires users to stay longer than the withdrawal window anyway, a secure fraud-proof system becomes a huge benefit.

Next, we’ll look at how these two determinants operate in reality with a few examples.

Exploring DeFi ideas to execute with Cartesi

We’ll focus on some of the ideas that align well with our framework of optimistic rollups.

One of the ideas is Dollar-Cost Averaging on-chain. It is an investment strategy where you invest a fixed amount of money at regular intervals (e.g., weekly, monthly), regardless of the asset’s price. At the heart of a successful DCA is time. You have to stay put with the app in order to get the averaging effect. As they say, time in the market beats timing the market.

The above tweet shows an example of how a regular investment in Bitcoin turned out to be a wealth-generating strategy over time. The core logic goes well with our first factor.

An interesting DCA prototype built with Cartesi is called DCA Monster. It is a decentralised exchange app with a stream swaps function at its core. It enables users to get the “DCAing” effect over time. The core app logic — an Automated Market Maker — is written in Python and runs inside the Cartesi Machine, giving the developer much-needed flexibility to use a traditional software stack on Linux.

A Lending and Borrowing app that uses a Reputation system is another good example. Unlike quick trading tools or flash loans, which depend on instant liquidity and split-second decisions, reputation-based lending is about patience and fairness. Lending apps typically work on longer timelines — borrowers commit to paying back loans over weeks, months, or even years. In that setting, waiting one more week to take funds out is hardly noticeable. What really matters is trust: how fairly someone’s reputation is judged and how repayments or defaults are handled.

With Cartesi Rollups, developers can build richer reputation features, such as looking at past behaviour. They can even leverage lightweight AI models, a logistic regression model could classify borrowers as “low risk” or “high risk” based on repayment history. A decision tree could rank users by trustworthiness using features like loan size, repayment punctuality, and collateral history. Even a tiny neural net could be used for pattern recognition if you’re aggregating multiple signals.

These models add nuance to reputation without being too heavy to run on-chain, and Cartesi’s fraud-proof system makes sure every computation can be verified with minimal resources at hand.

Staking and Yield farming is another category that naturally fits for optimistic rollups, where a 7-day withdrawal period doesn’t feel like a burden. These applications already require users to lock their funds for weeks or months to earn rewards, so patience is built into the core experience. Adding an extra week on top of long-term participation rarely changes user behaviour.

On the other hand, builders aren’t boxed into Solidity’s limited math. With the Cartesi Machine, you can add complex reward logic instead of simple fixed APYs, rewards can depend on multiple factors, for instance, pool performance, length of stake, or user behaviour. A developer could implement tiered yields, loyalty bonuses, or dynamic rates that adjust automatically with market conditions. One could implement advanced penalty conditions where developers can model nuanced conditions for slashing or penalties, such as partial penalties instead of all-or-nothing, or conditions tied to network behaviour.

Simulation and analytics are also feasible, allowing developers to run statistical models or lightweight simulations to optimize pool performance, something that’s difficult to achieve in Solidity.

The design space extends beyond these basic examples. Developers could integrate other verticals in DeFi, such as complex DAO governance models, SocialFi experiences, real-world assets, solutions for promoting green technologies, and much more.

From both the user’s perspective and the experimentation opportunities for developers, the advantages of building on an optimistic rollups solution outweigh the drawbacks. That said, it benefits everyone to see the technology evolve and provide the best possible user experience. We’ll continue to watch ZK rollups as they become more feasible in the future, but until then, let’s appreciate the diverse and expressive nature of Appchains with L1 security guarantees.

Hope you enjoyed reading the article. If you’re a builder looking to create an Appchain with the best execution environment(🐝 iykyk) and state-of-the-art fraud-proof systems out there, reach out to me. I’ll be happy to get you started. 🚀

Expressive and Secure DeFi Appchains with Cartesi

Is finality delay a real challenge for optimistic DeFi?

When time and security make the wait worthwhile

My Money Will Make More Money Over Time

My Money Is Secure with a Fraud-Proof System

Exploring DeFi ideas to execute with Cartesi

Subscribe to The Cartesi Newsletter

More from Use Cases

Expressive and Secure DeFi Appchains with Cartesi