Decide What Actually Belongs on a Blockchain

We still see a lot of decks with a slide that basically says, “we’ll put everything on-chain.” It sounds bold and “web3-native,” but it’s usually a tell: the founder hasn’t decided what actually needs credible neutrality, composability, or shared state – and what’s just CRUD in a hoodie.

Blockchains are slow, expensive, and public. Databases are fast, cheap, and private. Treating them like drop-in substitutes is how you end up with unusable products and puzzled investors.

This piece walks through a concrete way to decide which parts of your product truly belong on a blockchain, which should live in web2, and how to explain that split so investors see an intentional architecture – not a buzzword tax.

Before you get into L1 vs L2 debates, be precise about what you actually need that a well-run Postgres cluster cannot give you. In real systems, three properties matter:

1. Credible neutrality. No single operator can change the rules or censor users. This is why Uniswap’s core pools, Maker’s vault accounting, and Lido’s staking logic live on-chain. If any one company can flip a bit and redirect flows, the system’s guarantees disappear.

1. Shared state. Multiple independent parties need to read and write the same ledger without trusting each other. NFT marketplaces indexing the same token ownership, or multiple frontends plugging into the same DeFi protocol, all rely on a common state layer.

1. Permissionless composability. You want unknown third parties to integrate, extend, and build on top of your logic without asking you first. This is why Aave, Compound, and similar protocols expose their contracts as money legos.

If your feature doesn’t lean heavily on at least one of these, you’re not getting real leverage from a blockchain. You’re probably pushing it on-chain for aesthetics, not necessity.

A practical way to design crypto products: assume everything is off-chain by default, and only “promote” something on-chain when it has a clear, defensible advantage there.

A simple mental model:

• Is this about balances, rights, or rules that must be credibly neutral?

Then it wants to live as a smart contract.

• Do multiple untrusted parties need to coordinate on the same state?

Then you’re in “shared source of truth” territory: consider an on-chain registry or protocol surface.

• Do we want third parties to plug in permissionlessly?

Then that interface should be on-chain; the rest can sit in conventional services.

• Is this just UX, recommendations, analytics, or internal ops?

That belongs in web2 infrastructure.

From there, map your system into three buckets:

• Core protocol – on-chain, where balances, rights, and core rules live.
• Coordination surfaces – may be on-chain, where untrusted parties meet and interact.
• Everything else – off-chain, where you can move fast, iterate, and scale cheaply.

You’re not optimizing for “maximum on-chain.” You’re optimizing for a design where the on-chain surface is exactly where your moat, composability, and network effects compound.

We keep seeing the same pattern across NFT platforms, creator tools, and “web3 social” pitches: teams try to force feeds, messaging, and even real-time interactions fully on-chain. Gas and latency bury them.

You’ve seen the variants:

• Early NFT marketplaces that dutifully wrote every bid, view, and like to the chain, then quietly shifted 90% of that data into their own databases.
• Social dapps that tried to store full posts and comments on-chain instead of just hashes or external references.
• Games that insisted every in‑game action must be a transaction, then learned players won’t wait 15 seconds and pay $0.50 just to open a door.

In every case, the real win was the shared asset layer: ownership, balances, rights. Everything else — feeds, ranking, chat, matchmaking — performs better as conventional web2 services built on top of that shared state.

There are, however, clear patterns where pushing more on-chain is a real advantage.

• Markets where trust is the product. AMMs, lending pools, prediction markets, and on-chain treasuries win because anyone can independently verify rules, state, and balances.
• Multi-sided platforms with adversarial participants. Creator royalty splits, revenue-sharing DAOs, and tokenized IP catalogs work better when payouts are enforced by code, not by a startup’s goodwill or balance sheet.
• Ecosystems designed for third‑party builders. If you want wallets, aggregators, and other apps to integrate you by default, your core logic has to be on-chain, composable, and easy to reason about.

The working model: put the money, rights, and rules on-chain; keep UX, iteration, and personalization off-chain. That’s how Uniswap, OpenSea, and similar protocols ended up with durable moats instead of expensive science experiments.

Most investors have seen enough “put it all on-chain” decks to start from a place of suspicion. What they’re actually looking for is proof that you understand the tradeoffs and are using blockchains only where they create a real advantage.

When you walk them through your architecture, make the split explicit:

• “Here’s the core protocol surface we’re putting on-chain, and why it needs credible neutrality and shared state.”
• “Here’s what we’re intentionally keeping off-chain so we can ship fast, iterate, and avoid lighting users’ money on fire in gas fees.”
• “Here’s how third parties can plug in: what’s composable on-chain vs. what’s exposed as a conventional API.”

That framing does two things: it makes clear you’re not cargo-culting web3, and it reframes your on-chain footprint as a defensible moat, not a side quest. The “right” split is almost never obvious from the buzzwords; it becomes obvious once you map where trust, coordination, and composability are structural to your product—and where they’re not.

If you start from “everything on-chain,” you’ll burn months wrestling the chain instead of benefiting from it. Flip the default: assume everything is off-chain, then selectively pull on-chain only what truly demands credible neutrality, shared state, or permissionless composability. That’s where blockchains stop being a constraint and start being a force multiplier.

Do that mapping early, while it’s still cheap to change your mind. Sketch the system: what’s protocol, what’s coordination layer, what’s just product logic. If you can’t defend that separation on two slides to a skeptical investor, you won’t be able to make it intuitive for users either. The real design question isn’t “how do we put more on-chain?” It’s “what is the minimal on-chain surface that, if we get it right, amplifies the value of everything built around it?”