The early years of blockchains have been marked by an emotional fixation on the revolutionary potential of web3 and the inherent benefits of decentralization. This emphasis has been crucial to drive innovation and rally early adopters.

However, an overemphasis on these ideals without considering the practical limitations can lead to the formation of erroneous mental models about how and why this technology should be adopted. As more and more mainstream users come in, these mental models can be hard to dislodge.

One such mental model is the belief that all centralized apps should be completely decentralized and migrated to blockchains in their entirety.

Decentralize everything as fast as you can! Or in simpler words - “Onchain good, offchain bad”

Decentralization is not an On-Off Switch

Crypto holds dear the values of decentralisation but it’s often overlooked that decentralisation is a spectrum and not an on-off switch.

Truth be told, not all applications need to fall on the decentralised end of the spectrum.

And in reality, a lot of well-adopted use-cases in crypto currently also function on the back of heavily centralised architectures.

• The current narrative of loyalty programs(read: points) are mostly done with off-chain and opaque infra.

• Perpetual DEXes like Aevo often have their orderbook and matching engine running entirely off-chain.

• Several niche DeFi protocols end up relying on centralised single-signer oracles for price feeds.

• And how can you forget the state of the Layer-2s where everybody is in the process of decentralising 😛

But the lesson is, centralisation vectors are fine if that is the trade-off you need to take for the experience of your app. As mentioned, decentralisation is a spectrum and as long as you’re able to provide your users with certain security guarantees that are appropriate for your app, it is more than enough.

Determining your app's level of decentralization involves carefully weighing the importance of security against the desired user experience.

For example - A DeFi app that holds users’ funds should be as bullet-proof as possible whereas a game that’s augmented with crypto features most probably doesn’t need extremely secure decentralisation guarantees.

Similarly, A social media app, doesn't really need to put frequent and low-value actions such as likes and votes onchain since these actions don't require as much security Instead, they can just put the essential components (say registration, account recovery, etc. for social media apps) onchain while keeping the other components centralized.

Blockchain apps provide transparency, security, censorship-resistance, and immutability. Centralized apps provide speed, efficiency, and scalability but aren’t as secure. Apps that blend both onchain and offchain components can thus be referred to as “hybrid apps” which provides the best of both worlds.

*Obviously, not everyone gets this wrong, so excuse the clickbait title. But that is often the dominating way of thinking about blockchain apps and it’s a mental model that we try to break with this blog post. Vitalik also brought up hybrid apps in his recent article, calling them “halfway-house” level decentralized apps and even other chad builders in the space are talking about it

All of the above leads us to the fact that for a plethora of use-cases, halfway-house security is sufficient while prioritising for the user experience.

Oh Baby, Why dont you just meet me in the middle?

Enabling developers to progressively decentralize their apps allows for some fantastic web3 usecases that so far have been thought of as too difficult to build onchain.

Of course, there can be variations of which part stays onchain based on what each app tries to achieve. “Halfway-house” apps don’t have to be exactly halfway decentralized. They can instead reside anywhere on a spectrum of decentralization based on the desired characteristics (for instance, apps looking for a high level of security can put more components onchain).

(drum roll) Halfway-house security with verifiable compute

Verifiable Compute refers to being able to provably demonstrate that a piece of computation has happened exactly how it was supposed to without any interference or tampering.

Verifiable compute coupled with suitable security guarantees around the trust assumptions of the infrastructure enabling it, is the most ideal outcome that apps should desire rather than decentralisation-maxxing.

Thinking through apps in terms of halfway-house security enables the developers to build apps that can power smooth Web2-like user experience while borrowing the best of crypto and the security guarantees if affords.

Show, don’t tell

Social “Sufficiently Decentralised” Media

Looking at Farcaster, it’s a social protocol that took the stance of being sufficiently decentralised.

For a social protocol, sufficient decentralisation is achieved “if two users can find each other and communicate, even if the rest of the network wants to prevent it.”

Farcaster achieves “sufficient decentralisation” with a clever mix of on-chain & off-chain infrastructure.

• On-Chain: ID registry & critical actions are provably processed and stored on Optimism.

• Off-Chain: Actions like posting a public message, or liking a message are processed and stored on a P2P Network — Hubs.

Farcaster is a prime example of leveraging the on-chain infrastructure for what it’s good at — solid security guarantees. And at the same time, not requiring the users to sign a transaction every single time they want to post “gm” on their feed — good UX.

On top of all that, with the registry being on-chain and Hubs making the data available: developers can build their own clients on top of Farcaster, effectively reaching sufficient decentralisation. If one client decides to censor you, move to another.

These are the kind of trade-offs between security and the envisioned user experience that are highlighted throughout the article.

Micro-Payments

Well if it isn’t the most commonly touted yet not fully realised vision of crypto.

And the vision won’t be fully realised until the UX of micro-payments with crypto isn’t as smooth as Apple Pay. Which is quite possible to build when you think about designing a micro-payments app with halfway-house security.

And to think of it, we’ve had experiments along the similar lines. For example, Lightning Network on top of Bitcoin is a protocol with halfway-house security which tried to offer a better experience for small BTC transfers between the users.

Celo is another case to look at where they’re transitioning from being an independent L1 to a validium on Ethereum with the renewed vision of being THE chain for micro-payments.

(Bonus: Soon, dropping an article on how Celo could be built as a set of micro-rollups using Stackr.)

Two-sided Marketplaces (Matching Engines)

The value of verifiable compute can be applied to any use-case that requires a matching engine to make the market between the supply and demand, and do so efficiently.

Think Uber but they leave an on-chain paper trail that proves your “intent” to go from A to B with your constraints has been matched as efficiently as possible with a driver.

And for a crypto-native use-case, think orderbooks.

In current Perp DEXes, the matching engine that connects buyers and sellers on the orderbook operates off-chain. While the DEX is motivated to make the market efficient, there is limited visibility on whether your orders are being effectively matched or not.

Imagine a rollup that is highly optimised for the matching engine. It reads the state from the orderbook and provably makes the market efficient right in the state transition function of the rollup. 🤯

Games

Building games while leveraging the decentralised stack can look very similar to how Farcaster leverages the decentralised ledger, halfway-house security.

Games usually need to be high throughput and that’s often a constraint when building on-chain both in terms of cost and user experience.

But, when thinking in a combination of on-chain & off-chain architecture, the design space opens up and that is also the trend we’re slowly seeing gaining steam where the games are just normal games with a few crypto-native features.

And in addition to that —

• Simulation/Strategy based games can leverage verifiable compute to build a trust-minimised simulation engine.

• PvP games can leverage the blockchain rails to add native “financialisation” with wagers.

• Games can leverage the decentralised ledger to store a paper-trail of in-game assets.

And many other use-cases…

The road to building hybrid apps & more ➡️

We strongly believe building apps with halfway-house security in mind can lead to both — a more robust crypto-native ecosystem & use-cases that lead to mass adoption.

At Stackr, we’re building the toolkit and the necessary infrastructure to build app-specific micro-rollups to supercharge and unlock the DevEx around building apps with halfway-house apps and much more with the languages you already know.

It’s not just a new tool, it’s a new paradigm on how to think about building blockchain-powered applications that are also secure.

If that piques your interest, come say hi and keep an eye out for the wish list of experiments dropping soon ✨

Thanks JD for review and Shivanshu Madan and Benjamin Funk for inputs