What If DeFi Was Built For Finance First?

We talk with Joao Garcia from Cartesi about why DeFi keeps paying a hidden tax when smart contracts are forced to act like calculators instead of computers. We break down how Linux-style execution environments, better runtimes, and research-backed proofs can unlock cheaper, safer, more flexible on-chain finance.

• The “three levels deep” approach for explaining complex Web3 concepts without losing accuracy
• Why Linux on-chain matters for real-world developer tooling and existing software libraries
• The human cost and rigor cost of rebuilding finance primitives inside EVM constraints
• Designing the machine around finance to reduce gas costs and expand what DeFi can do
• Why execution environments are overlooked compared with UX narratives and hype cycles
• Gas-optimised finance versus computation-driven finance using bonding curves as a concrete example
• Application-specific rollups and why shared congestion can become a financial risk
• Building trust through research, fraud proofs, and settling on Ethereum rather than reinventing an L1
• How AI-assisted development and spec-driven workflows change how Web3 apps get built
• Organising community learning with layered docs, Discord channels, and deeper GitHub trails

DeFi Needs A Better Runtime

DeFi has proven product market fit, but the way we build many protocols still looks like engineering finance inside a cramped execution box. In this conversation with Joao Garcia from Cartesi, we keep coming back to a simple Web3 question: are we designing financial applications around the limits of the EVM, or designing the machine around the needs of finance? When the runtime is constrained, developers pay a hidden tax in gas costs, development time, and verification effort. Users pay too, through higher fees, brittle UX, and the constant risk that congestion elsewhere on the chain makes their own actions expensive or impossible at the worst moment.

A core idea is why “Linux on-chain” matters for blockchain scalability and developer experience. Most modern software runs on Linux servers, and the most trusted building blocks in computing and finance were designed for that environment. When developers can use familiar tools like Python, databases, file systems, and established mathematical and financial libraries, they stop reinventing years of infrastructure just to make an on-chain version work. That shift is not only about comfort. It changes security posture because battle-tested libraries bring mature assumptions, known failure modes, and long-running scrutiny that custom Solidity re-implementations often lack.

The episode also digs into the difference between gas-optimised finance and computation-driven finance. A simple example is a bonding curve for token launches: without a full math library, teams end up using approximations that fit within smart contract limits, then spend weeks proving correctness under edge cases. With richer computation, precision can improve without ballooning per-operation cost, and the developer’s job becomes more like normal financial engineering. The conversation extends this to application-specific rollups and runtime isolation: if one app saturates a shared chain, everyone else suffers, but a specialised execution environment can reduce cross-application interference and keep critical actions like withdrawals, liquidations, and rebalancing predictable.

Finally, we connect execution environments to trust and to the future of AI-assisted development. Joao argues that infrastructure teams earn trust by proving, not selling: research-backed design, robust fraud-proof mechanisms, and settling on Ethereum as a trusted settlement layer rather than launching a new L1 from scratch. On the builder side, AI coding tools thrive when systems are well documented and aligned with mainstream software patterns, which strengthens the case for bringing the broader Linux ecosystem on-chain. Pair that with spec-driven development, and teams can move fast while maintaining a safety layer that keeps complex Web3 applications auditable, explainable, and easier to ship.