The Opinionated Application
The App-Infra Thesis, an ode to customisation.
If you’re interested in spreading the word about this article, feel free to interact with this tweet
Much of my time in Bangkok was spent talking to and discussing the idea of infrastructure and middleware being tailored specifically to an application’s need - providing a catered and better user experience.
As they grow in traction, most applications quickly realise that their customisation and internalisation choices are limited as simple smart contracts. Applications are inherently opinionated about many things, especially ordering in the DeFi case.
The idea is relatively simple: the fat application and protocol are the same, and both benefit each other. There are perfect examples of this already, such as taking advantage of ordering and customisation for a better application.
The idea comes from the fact that we at Maven11 generally believe that applications are opinionated by default. They all have some idea of how they want specific things to function within their application (often without the power to do so); this could be related to ordering, fairness, distribution, customisation & and the list goes on. To better understand why we believe that applications are opinionated, it may be easier to look at blockchain applications as actual companies (which they often are). Companies in the real world are opinionated about many things and can often be expressive (meaning they aren’t limited/restricted too much). You could compare the current situation for most blockchain applications to that of “companies” in a central planning economy run by a socialist dictatorship. Most real-world companies in modern economies, while they have to adhere to some degree of governmental laws and legislation, their landlord isn’t watching over their every step. This, in turn, allows companies to compete across more axes as they can define and fine-tune a more significant part of the user experience.
Let’s take an example of a real-life company, in this case, a burger joint. In this joint, the local landlord controls how the seats should be placed, where the windows are allowed, and the burgers' pricing. What business would appreciate this type of overreach? Not many. The fundamental issue with most businesses functioning as smart contracts on generalisable blockchains is that they run into these issues - a complete lack of control and, therefore, a degrading user experience. While some aspects of newer monolithic systems have provided models like local fee markets, even there, much of the customisation is still lacking. In the rest of this article, we aim to present our thesis on why applications are opinionated and how they can become opinionated (and those who are already expressing these opinions).
All the applications we've spoken to had one thing in common: they were all opinionated about how to service their users best. Can they do so in current conditions in a generalisable environment - in most cases, no. Although application-specific sequencing aims to solve some of the ordering concerns some applications have, we'll cover them in more depth later.
Conceptually there are simple reasons why an application would want to control aspects of its design that isn’t possible on a baselayer w/o significant changes (either ASS, off-chain or rollup-esque setups):
Static VMs
No ordering control
Inelastic scaling
MEV leakage
Global state (good & bad)
Contention, the beauty and the beast of composability
We have specifically covered the ordering part in depth in a complete article on the concept of transaction ordering, which can be found here. As such, we’ll just summarise shortly why this matters:
Allows for internalising MEV (end the proposer monopoly!! Or become your own proposing monopolist?)
Ordering constraints for specific apps: fair ordering, welfare maximisation, priority lane, LVR auctions, frequent batch auctions and swap splits (and the list goes on)
While many projects (most successfully CoWSwap) are utilising batch auctions for their intent batches, something we specifically would like to see on an application-specific level is noted below;
In terms of live implementations of ordering rules, there are quite a few - some highly successful already, and several significant players are moving towards using ordering rules to their advantage in the coming year. Underneath are just a few examples.
Hyperliquid; prioritises cancels and makers over takers by running cancels and post-only orders first.
Unichain; TEE builder(s) to ensure no malicious actors in the supply chain with a “highway” for arbitragers.
Penumbra; ordered batch auction with an accrued time arbitrage value
Slinky (Skip); oracle data at block level (protocol-level) to ensure the application(s) on the chain can utilise fresh (and cryptoeconomic secure) oracle data
Oval (UMA) and Warlock; Oracle-Extractable Value auction for the right to act on updated information - specifically relevant for liquidations, but could also work for arbitrage.
Generally, many of these ordering rules can (and are going to be) implemented on generalisable chains via applications-specific sequencing (ASS); however, some considerable constraints need to be kept in mind, specifically around composability, resource locks and exogenous vs endogenous MEV capture. And certainly also a spectrum of security, we'll cover some of the security considerations and composability settings both for ASS and other setups below;
While ASS has been pushed primarily (at least as a concept) via bundles, fat TXs and off-chain (guardian) node systems, there are several different ways of achieving control over sequencing:
App-chain
App-rollup (deriving security)
App-based-rollup (if lanes/flags)
Fat TXs/Bundles
Off-chain node systems
Key things to keep in mind between all the various solutions is that there are generally four key security parameters that must be taken into account:
Decentralisation
Transparency or Privacy (either can play a big part in censorship; TEE could be used to “trustlessly” enforce rules in the supply chain). The caveat here is that a lot of power is still in the app/wallet pre-ordering
Censorship
Stakes/bonds (rules backed by economic security)
Looking at the five ways of achieving sequencing control above, generally, we'd flag the issues/powers as
App-chain
Orchestration push, but complete control - need to write everything yourself. Lend itself well to eg. Perps
App-Rollup
Less push, inherit security, complete control - flurry of SDKs. Composability is still hard.
Based-Rollup
Less built out, higher degree of composability depending on outsourcing/delegation, less specific control but gain network effects
Fat TXs/Bundles
Less lift, exogenous MEV is hard to capture, endogenous MEV easier. Might have to change call data of txs, dependent on global ordering rules. Susceptible to exogenous MEV if composable.
Off-chain node(s)
Less secure, solid complete control, composability essentially impossible
In most of the cases above, your likely dependencies will be; the underlying chain, your own protocol or not, are you inheriting some security (ie DA/Dispute Resolution) and is there a need for a consensus algorithm or economic bonds. How much of this is outsourced (and is incentivisation needed?). Also, but not least, are you on contested global state.
Do consider that most of the app-specific chain or rollups can enforce rules on a “consensus” protocol level, meaning the protocol is built respecting rules rather than forced in. This is also why economic security or verifiability (validity proving) is so vital in most setups. You could argue there's quite some likelihood that based rollup setups with execution flags or lanes could provide the best of both worlds (still unclear aspects though, specifically around execution preconfs with sync composability and ordering lanes). When we say both worlds, we're specifically referring to also dealing with the issue of composability (while retaining control), let's look at the composability spectrum.
This is heavily based on the great work by Thogard but simplified to provide a simpler explanation of the tradeoffs, if you want the nitty gritty aspects - I heavily recommend checking out his work. Keep in mind that app-chain could also mean app-rollup. The general idea is that while some control is possible in terms of ordering and MEV internalisation on the baselayer with existing contracts, not all MEV is capturable (especially exogenous MEV, which is highly prevalent in intent based protocols). Furthermore, on the baselayer, you're still constrained in customising the infrastructure backing the applications. Let's take a look at what we mean when we say customisation (and specilisation), since there are several aspects that are important to keep in mind for a business (application) founder.
The customisation part of a chain, often overlooked by many (but a big issue for specifically EVM-chains), is how that affects UX. A great example is the constant approval needed of tokens to trade, and of course the hated EoA. EIPs like 7702 can be implemented (and adjusted) to fit your application needs. However, that's just the beginning of what you could implement; how about changing your VM to one better fitting your developer's needs (and, as such, providing a better user experience). Maybe your chain needs a high degree of security with ZK verification, and the native BNS-128 isn't good enough on Ethereum, so change that. The reasoning here for your own infrastructure (and so many providers offer this now) is that you should be allowed to be opinionated about how you build your business and not be constrained.
Other things that might be interesting to add for an application could be new precompiles (which can take a long time to implement on a baselayer).
Another reason, and one generally utilised as the most prominent reason in the past (but has subsided since then), is scalability. Now, we don't just wanna trout the “modular scalability horn” yet again. However, we will note that the elasticity (i.e., increasing gas limits) you're afforded regarding scaling and latency can be a considerable gain depending on the application.
However, we see this move towards infrastructure control as an evolution that the application takes on as it increases in complexity and popularity (although newly built applications with complete control have seen to do well because they're able to provide a much better UX). The general evolution is likely a 4 step process (or 5 if you consider smart contract into smart contract w/ ASS)
This is not the time to get into the complexity, orchestration and cost of a fully decentralised app-chain, but if you're interested in our thoughts on this, feel free to watch our presentation from Denver last year (link to slides)
The clearest and most famous example of the many mentions of specialisation above is the one needing composability the least (one of the downsides often associated with app-specific infrastructure) - the “decentralised” exchange Hyperliquid. It does two specific things that benefit its users immensely- controlling ordering and customising its infra to the user.
On the ordering front, they prioritise cancel and maker orders to provide a better trading experience. On the customisation front, the general trading experience we usually associate with on-chain venues is abstracted away via infinite approvals and one-click trades (ie EIP7702-esque), as well as elastic scaling and a tailored consensus algorithm to penalise inefficient nodes for “CEX-esque” experience (even w/ a larger/decentralised set, I expect this to feel much the same)
It's just the beginning innings of the game. With other larger players like Uniswap moving in a similar direction (but as a rollup), we expect to see many more similar announcements as time passes.
One aspect to also keep in mind as we see more applications move aspects off-chain is that we keep the censorship resistance of the protocol (especially with the advent of auctions). There are various ways to achieve this, such as:
Based sequencing (w/ some nuances depending on the degree of outsourcing, fair-exchange and proposer monopoly)
TEE (obfuscate the ability for dishonesty in the supply chain)
Bonds/Stakes
Application-specific rollups w/ decentralised rotating sequencers
Mixture (ie Unichain)
Fair exchange solving via consensusless decentralised protocols against censorship
Other issues to keep in mind as we specialise further are:
With faster chains, how do we deal with reverts, how fast can simulations get (ie can the top of block invalidate bottom, and how does this look w/ new streaming txs across block times)
If the decentralised sequencing mentioned above is not single leader but competitive, how much of this is latency games
Consensus is slow, might make sense to just stream txs (but then latency game as said above)
TEE's might push towards spamming (already a massive issue) because of private OF
Generally there are some downsides to taking control:
Lack of composability depending on setup, with ASS a lot (just like chain abstraction) comes down to resource locks.
If ASS, lack of own fee market? Lack of VM/EIP control
To give a broader view of the vertical in terms of taking control (beyond the simplistic - go build app rollup/chain), there are other examples of app-specific infrastructure for specific needs:
Spire (building based-rollups, app-specific ones will have much control)
Astria/Espresso/Radius, allowing for app-specific builders (+ shared seq for composability)
Spicenet (sovereign rollup on Celestia)
Sorella (LVR auctions in Univ4 hooks)
Initia (Apps can ASS their sequencer using the mempool lanes on each minitia / Skip's Protocol-owned-Builer)
Magicblock (ephemeral/based rollups on Solana)
Delta (each app is its own sequencer but with a global state layer underneath)
Offering Application-specific sequencing on a baselayer there are specifically:
RaaS - in theory, all RaaS providers could/are providing some degree of ordering/customisation control
The fat protocol and applications thesis are one and the same, they merge ever closer together as applications become businesses, and businesses become infrastructure.
Whether that is sequencing rules, using a different virtual machine or making custom changes to existing ones (such as adding new opcodes or changing gas limits) is really up to the end developer, depending on their product.
Something we'll start to see happen (and already is) this year is the move of many smart contract applications to their own application-specific rollups. This is primarily to control ordering (either for priority fee extraction or to provide specialised setups that gets closer to fair ordering). But also the ability to customise/specialise your VM, OPCodes, precomplies, new curve support for ZKPs or even gas limits (e.g. keep all active world state on disk).
One thing that we do need to mention as well is that there's undoubtedly also a ton of validity in the idea of a “fat wallet thesis” considering their power as the transaction originator, curated interface with revenue share from various protocols - however, gaining ground here is much more complicated because of the network effects we generally see. There are also multiple things to remember, such as wallets are unlikely to change calldata of txs, which can limit aspects of monetisation and things like NBBO.
The gist of the thesis on app-infra and opinionated applications is that opinions matter;
They enable applications to become better and more akin to real-world businesses.
Creates better user experience
When applications can conform to user’s wants, users are more sticky
If you're building opinionated applications, we'd love to talk to you - please reach out!
We'll leave you with a great quote to ponder (and chart) from the Syncracy Capital guys.
