Special thanks to My Team, Rahul Sethuram, Patrick McCorry, Sjors, Linda Xie and Anurag Arjun for related discussions and review.
One of my tweets caught fire recently, gaining some great traction among the Web3 community online! It was a pretty condensed, four-part “twitter” thread but what does it even mean, I hear you ask? Let me break it down.
Original tweet: https://twitter.com/Kautukkundan/status/1693413447508365352
Fuck rollups, bypassing the cliché
Opening a rollup article with talking points such as “what are rollups” or “why do we need rollups” is much like killing Uncle Ben or shooting mama and papa Wayne in every iteration of a Spider-man and Batman movie. If you’re reading this article, you’re likely familiar with these well-documented arguments. Also, if you’re reading this, I’m assuming that we can move beyond the app-chain vs app-rollup debate. So let’s cut to the chase.
Rise of App-specific rollups
General-Purpose Rollups are depressing
General purpose rollups are like the Indian school system (I’m sure they also share similar traits with other schooling systems but this is the one which I have first hand experience with).
An athlete, a singer, a mathematician, a thinker, an economist and a storyteller all need to go through the same process for securing a passing grade. Technically the system isn’t “biased” towards a particular group but it isn’t “fair” towards anyone either. But hey we make friends! (this will be important later).
Similarly for applications on general-purpose rollups, the bottleneck is the environment itself since it cannot individually cater to the needs of every application. Each application may require different kind of optimization but its just unreasonable for them to expect anything tailor-made. However, it’s the most convenient option if you’re just experimenting and want a general taste of things. Also for some applications just like some average students, it might just be the right solution!
What about friends? it’s the ecosystem of applications that are built alongside your application. You turn out to be a entrepreneur, you can simply call your accountant friend to help you with hiding tax money from the government :)
App-specific rollups are confusing
OK, My kid is too athletic to be in a public school, she needs special training. Do I need to send her to a sports school or should I hire a personal trainer…..
Spe-ci-fi-ci-ty com-ple-xity
Let’s play a game
Below there are 8 app-specific rollups. However in each group there’s 1 project which does not really belong to the group. Can you spot which one?
Application-specificity is becoming a convoluted term. There are app-specific rollups that allows deployment of contracts on top of themselves, there are also app-specific rollups that CAN allow contract deployment since their VM support it but their owners restrict it. There are also app-specific rollups that have a closed VM or no VM at all and does not support other kind of development.
Is it fair to categorize them together?
Answer to the previous exercise -
Group1 : Celo is the odd one out because it allows other developers to build apps while others are direct-use applications. Other projects which could be considered in group 1 - Fuel-v1, Aevo, RhinoFi etc
Group-2 : Loopring is the odd one out because it is the only purpose built rollup for direct-use, while the rest are networks optimized for specific functionalities like privacy, NFT and TPS so that the apps deployed on them can inherit these features. Other projects which could be considered in group 2 - Kinto, Kroma, public goods network etc
The Issue with deploying contracts in a modified general purpose VM
These VMs on which you deploy your smart contracts are nothing but turing complete state machines. The contract that you deploy on them is just additional modifications to the state itself. It does not really affect the core state transition rules of the VM. The rollup essentially is the VM and your business logic is sitting on top of it.
Your business logic is separate from the rollup’s state transition function
I also refer to this as the “smart contracts paradigm of building applications” since you are deploying some additional logic on top of a VM. The rollup doesn’t “directly” care about proving your application’s logic. The VM is the rollup and not your application.
Ofcourse - you are the sole owner of the VM and your application is the sole citizen, you can keep enhancing the base itself to make it suitable for the application. You can keep beefing up the state transition function (STF), adding / removing opcodes that boosts your application’s performance but the application is still independent and limited by the VM itself.
Its like a lamborghini Urus pulling a Lamborghini Huracan
Solo Apps on an app-specific rollup could do better! MUCH BETTER!
What if you keep enhancing the STF such that the scope of the STF keeps getting smaller and smaller to suit your application’s business logic. Eventually, as you keep enhancing, the STF will converge to a point where the business logic and the STF will overlap and at this point you’ll realize…oh SHIT WAIT A MINUTE!
Birth of Micro-Rollups!
Hence a micro-rollup is nothing but a rollup where the application’s state transition function IS the business logic itself.
The app becomes the rollup, the states can be managed in any way possible in any execution environment and the state transition rules can be applied directly in the application’s runtime. The application could be customized without any bounds. The proofs are tied to your business logic and not the machine. It makes your application light weight.
These special State transition functions require another article, stay tuned ;)
Micro-rollups are unrestricted in terms of developer experience. you could build them using whatever tool you like as they are unbounded by the VM limitation. They look like web2 backend applications with an exception that they periodically post transaction proofs to a parent L1. This is something I feel is going to be a major factor for influencing the shift of web2 developers into the web3 space

The only downside to this approach is the custom proving mechanism for each different application. If the app logic can compile into a common intermediary then proving that common intermediary takes away the pain of proving each app separately but I personally believe that’s just a tradeoff between efficiency and faster development (read laziness). We want to squeeze every drop of efficiency as possible.
💡 There are ways around it without using an approach where a VM is involved at the execution layer. What if there was a tool which allowed developers to do exactly that?
And that’s the mission statement of Stackr Labs - We are building a micro-rollup framework and SDK so that anyone and everyone could build their applications unrestricted and in whatever language they want just as you build web3 backend applications. Making Micro-rollup development as easy as writing and deploying smart contracts and not to mention the modularity adds to the ability of plugging into whatever ecosystem the dev chooses.
So Micro-rollups are real?
Always have been. (but as real as Rollups themselves, sorry don’t wanna upset Jon)
Applications like Loopring, dYdX and Fuel-v1 etc came up or have been around for a very long time. These are ultra optimized rollups with custom logic running specifically to serve their use cases. The first ever non-VM based app-specific rollup that I know of and personally worked on is Hubble Optimistic Rollup, this 3 year old project served as the core infrastructure for Worldcoin’s token for a while. (Also the major inspiration for Stackr)
It’s just now that the need to differentiate these terms has become important
The things that you can build as Micro-Rollups are unlimited -
Consumer products like games, exchanges, NFT marketplaces etc
App-chains can be converted to App-rollups
you can even build Novel VMs that support unique usecases opening doors to open VM innovation
I will be writing another post on pros and cons of micro-rollups and what applications make sense to be built using the micro-rollup framework.
Conclusion
The missing element of the tree I showed earlier are custom state machines
Moreover, it’s not efficient for solo applications to use a VM or EVM based rollup to deploy a single protocol. It works for applications that already have a bunch of smart contracts and running their protocol on an EVM like chain but not for “applications that want more” and want to be free from the VM restrictions.
So if we prune the tree, the final tree would look something like this. This is also the reason why I think soon in the future App-Rollups, Micro-Rollups or RollApps will just be called Apps.