Group 1.png

I’m sure you’ve heard of a bunch of these technical terms: MEV, ePBS, SUAVE, Sequencers, Intents, Smart Accounts, User Operations, Bundlers, Relayers, MPC Wallets, Zero Knowledge Proofs, Restaking, Proto-danksharding (EIP-4844), Data Availability Sampling, Rollups, etc.

These are all part of the “ Modular Stack ”. If you’ve avoiding them because you think they’re overcomplicated or only pertinent to rollup security/scalability then hey - I get it. I was in the same boat until a couple months ago, when I started to understand the application design unlocks they provide.

I want to dumb the stack down into an easier-to-manage mental framework for two reasons:

  1. For an easier time remembering the narrative connecting these technologies for those who don’t read every new article or thread - because the discourse is truly tiring to follow.
  2. To take an application-focused view on all this new tech, rather than an infrastructure-focused view. 99% of the content I see on these topics is purely written for an infrastructure audience and targets those building the chains, not those building on the chains.

Designing a Transaction

Users and developers at the app layer primarily care about getting the most out of their transactions - customizability, speed, and data transferability.

I break these transactions down into three main stages:

Until now, as a developer, you had to code all your application logic into the smart contract. You had to stick to 12-word seed phrase wallets, you had to force users to sign multiple transactions to go through your app, you had to stick to very simple math (or learn assembly), you had to work with only onchain data and no APIs, and you had to fit into a chain that tried to scale for every use case. Developers were stuck in the isolated and monolithic space of the Ethereum Virtual Machine (EVM).

The “Modular Stack” is a collection of technologies designed to change all that, so application developers can tailor their development environment to the desired user experience, while remaining permissionless, composable, and minimizing trust assumptions.

This diagram provides an overview of the various parts of this ecosystem that I will touch on:


This framework revolves around the question:

“What is the design space of a transaction, really?”

I’ll spend this article defining the design space for a transaction, explaining what is being abstracted and added at each stage with each technology. I’m going to be as succinct and non-technical as I can and will provide links to more technical articles in case you want to read into them.

Transaction Plans: Smart Accounts and Intents