On-Chain vs Off-Chain: What Actually Belongs on the Blockchain

The on-chain vs off-chain decision is the most important architecture choice in a blockchain product, and it’s often made by default rather than by design. Put too much on-chain and you get a product that’s slow, expensive, impossible to change and leaks data it shouldn’t. Put too little on-chain and you’ve built a database with extra steps, and lost the guarantees that made a blockchain worth using in the first place.

This guide gives you a way to decide, feature by feature.

What “on-chain” actually costs you

On a public blockchain, state and logic live in a shared ledger replicated across many independent nodes. Nobody can change it except through valid transactions, and anyone can read it. Those properties are the point, and they come with costs:

• Every write costs a fee, paid by someone: your user or you.
• Storage is expensive compared with a database, so on-chain data has to be compact.
• Everything is public by default. Assume anything you write can be read, forever.
• Changes are hard to undo. Mistakes in data or logic can be permanent.
• Throughput and latency are limited compared with a conventional backend, and they vary by network.

So every piece of data or logic you put on-chain should earn its place.

On-chain vs off-chain: the three reasons to go on-chain

1. Decentralised control

Use the chain when no single party, including you, should be able to change the rules or the state unilaterally. Settlement between parties who don’t trust each other, custody conditions, governance votes and token supply are classic examples. If it would be fine for your company to have an admin button that edits the record, it probably doesn’t need to be on-chain.

2. Transparent verification

Use the chain when people need to check the state or its history without trusting your servers: how many tokens exist, whether reserves cover liabilities, who owned an asset and when, how a random draw was produced. Public verifiability is something a private database simply can’t offer.

3. Programmable assets

Use the chain when users should own something they can hold, transfer and use elsewhere without your permission: tokens, NFTs, positions in a protocol. On-chain assets are also composable: other applications can build on them, which is one of the most powerful properties Web3 has.

What belongs off-chain

In most products, the majority of the system should live in conventional infrastructure:

• Personal data. Data protection laws such as the GDPR give people rights like correction and erasure, which are hard to reconcile with an immutable public ledger. Keep personal data off-chain.
• Large files: images, documents, media. Store a reference or hash on-chain, never the file itself.
• High-frequency, low-value updates such as presence, likes, drafts and UI state.
• Search, filtering and analytics, which blockchains are not designed to answer efficiently.
• Confidential business logic and anything that must stay private.
• Things you expect to change often: copy, configuration, content, pricing presentation.

Hybrid patterns that connect the two

Anchor, don’t store

Keep the data off-chain and write a cryptographic commitment on-chain: a hash or a Merkle root. Anyone holding the data can prove it matches what was committed, without the chain storing it. This pattern underpins allowlists, airdrops and document notarisation.

Content-addressed storage for files

Systems like IPFS address files by the hash of their content, so a reference stored on-chain always points to exactly that content. One caveat that catches teams out: content addressing proves integrity, not availability. Files stay reachable only while someone keeps them pinned, so plan for persistence explicitly.

Indexers for reading

Contracts are good at enforcing rules and bad at answering questions like “show me this user’s last 20 trades, sorted by value”. Emit clear events from your contracts and use an indexer, such as The Graph or your own service, to build a queryable view off-chain. Your interface reads from the index; the chain stays the source of truth.

Oracles for outside facts

Contracts can’t see the outside world. Oracles bring in prices, randomness or real-world events, and networks like Chainlink are widely used for this (Chainlink VRF, for example, provides verifiable randomness). Every oracle is a trust assumption, so design for stale or manipulated data: check freshness, bound values and avoid relying on prices that can be moved within a single transaction.

Sign off-chain, settle on-chain

Many interactions don’t need a transaction until the moment of settlement. Users can sign structured messages off-chain (EIP-712), such as orders, approvals or votes, and a contract verifies the signature when it matters. This keeps the experience fast and cheap while preserving the guarantee.

Layer 2 networks for cost and speed

If the logic truly needs to be on-chain but mainnet fees or latency don’t fit your use case, rollups and other layer 2 networks can reduce costs while inheriting security from the underlying chain. Each makes its own trade-offs, so pick deliberately.

A worked example

Consider a hypothetical event-ticketing product:

• On-chain: ticket ownership and transfers (users own and can resell tickets), plus resale rules such as a royalty or price cap that the organiser shouldn’t be able to change after sale.
• Content-addressed or CDN storage: ticket artwork and event metadata, referenced from the token.
• Off-chain database: user accounts, email addresses, support history and analytics.
• Indexer: “my tickets” views and secondary-market listings, built from contract events.
• Off-chain with signatures: venue check-in, where a ticket holder signs a challenge to prove ownership without paying a fee.

The chain handles the few things that need its guarantees. Everything else uses the right tool for the job.

Common mistakes in the split

Treating the indexer as the source of truth

Indexers make data easy to query, but they can lag, miss events during reorganisations or simply have bugs. For anything that moves value, such as balances, permissions and settlement, read from the chain or verify against it. Use the index for display and discovery.

Storing references that can change

A token that points to a regular web URL for its metadata can have that metadata changed or taken offline at any time. If the content matters to what the user owns, use content addressing and make sure it stays pinned, or anchor a hash on-chain so changes are detectable.

Forgetting that “off-chain” still needs trust design

Moving something off-chain doesn’t remove the need to think about who controls it. Be explicit with users about which parts of the system you operate, what you can and can’t change, and what happens to their assets if your servers go down. Well-designed products keep core assets usable directly from the chain even when the operator’s interface is unavailable.

Optimising gas before the design is right

Gas optimisation matters, but a contract that stores the wrong things efficiently is still the wrong contract. Settle the on-chain vs off-chain split first; micro-optimise the code that remains afterwards, with tests guarding behaviour.

How to decide, feature by feature

Getting this split right is a big part of what makes a Web3 product fast, affordable and safe. If you’re planning a build, see our approach to dApp development and smart contract development, read the three things to get right before you build, or get in touch.