In one minute
- On-chain: Data and actions recorded directly on a blockchain. Transparent, permanent, and secured by the network — but limited and costly.
- Off-chain: Data or computation handled elsewhere (servers, content-addressed storage, L2 sequencers before settlement). Cheaper and flexible — but adds trust or availability assumptions.
- Rule of thumb: Put the minimum necessary on-chain (balances, critical state, proofs). Keep big files and heavy compute off-chain, referenced by hashes/links.
Educational only: Not financial advice. Always verify contract addresses and official links.
What usually goes on-chain
Balances & transfers
Native coin transfers and token balances (fungible and NFTs) so anyone can verify ownership.
Critical app state
Escrow amounts, governance votes, loan positions, AMM pool reserves — things contracts must enforce.
Proofs & references
Hashes (fingerprints) of larger off-chain data, or validity/fraud proofs from L2s.
What usually stays off-chain
Big files
Images, videos, large metadata. Often stored on decentralized storage (content-addressed) or traditional servers, then referenced on-chain.
Heavy computation
Analytics, order matching, simulations. Results can be committed on-chain via signatures or proofs.
User interfaces & indexing
Websites, APIs, and search/index services that make on-chain data easier to use.
Tip: Off-chain ≠ “centralized only.” Some storage networks distribute data widely and use content hashes to prevent silent edits.
Trade-offs at a glance
On-chain pros
- Strong integrity & auditability.
- Composability — other contracts can trust the state.
- Censorship resistance (within the chain’s guarantees).
On-chain cons
- Fees & limited capacity.
- Public by default (privacy needs special techniques).
- Hard to change once deployed.
Off-chain pros
- Low cost, high throughput.
- Flexible formats; easy updates.
- Can preserve privacy more easily.
Off-chain cons
- Availability & trust assumptions (who hosts it?).
- Less composable with smart contracts unless anchored by hashes/proofs.
- Link rot risk (URLs change, hosts go down).
Common patterns (plain English)
- Anchoring with hashes: Store a hash of a file on-chain. If the file changes, the hash won’t match, revealing tampering.
- Order books off-chain, settlement on-chain: Some exchanges collect signed orders off-chain, then settle trades on-chain to save gas.
- NFT metadata: Token exists on-chain; the image/metadata is a link (e.g., content-addressed). The contract points to that link.
- Layer 2 rollups: Many transactions are processed “off-chain” by an L2, then posted/verified on L1 with proofs or data batches.
- Oracles: External data (prices, weather) delivered to contracts; consumers should understand the oracle’s trust model.
- Signed attestations: A party signs a message off-chain to attest to something (e.g., KYC check). Contracts can verify signatures later.
NFT storage: centralized URL vs content-addressed
- Centralized URL: Points to https://example.com/image.png. Easy but if the server changes the file, your NFT image can change.
- Content-addressed: The link is the file’s hash (a “CID”). If the content changes, the link changes — prevents silent swaps.
- Permanence: Some networks aim for durable storage; others require “pinning” (keeping copies online). Verify how long data stays available.
As a buyer, check the token’s metadata link type in a block explorer before purchasing.
Privacy & compliance notes
- On-chain is public: Great for audits, not for sensitive data. Use privacy tech or keep sensitive pieces off-chain.
- Right to be forgotten: Public chains are append-only; deletions aren’t practical. Keep personal data off-chain.
- Access control: Off-chain stores can enforce permissions; on-chain data is readable by anyone unless encrypted.
Checklists
For users
- For NFTs, check if the metadata/image link is content-addressed (less risk of silent changes).
- Verify token addresses from official docs; be wary of look-alikes.
- If a dApp stores funds off-chain, understand the custodian and withdrawal path.
For builders
- Put only critical state on-chain; anchor everything else with hashes or proofs.
- Choose storage with a plan for availability (pinning/backups) and link stability.
- Document your oracle, L2, and storage trust assumptions clearly.
- Design for upgrades: versioned metadata, migration paths, and user notices.
Educational content only. Do your own research.
Quick glossary
- Content-addressed storage: Files are retrieved by their hash (CID). Change the file → new CID.
- Hash (fingerprint): Short code uniquely representing data; used to detect changes.
- Merkle root: A single hash summarizing many pieces of data.
- Data availability: Whether the raw data needed to verify state is publicly accessible.
- Attestation: A signed statement someone can verify later.