Data stored directly on the blockchain ledger, such as token balances, smart contract state, and transaction history. This data is immutable, transparent, and cryptographically verifiable by all network participants. Every node in the network stores a full copy, ensuring censorship resistance.

Key characteristics:

• Permanence: Data cannot be altered or deleted.
• Cost: High gas fees, especially on networks like Ethereum.
• Examples: ERC-20 token balances, NFT ownership records on Ethereum, DeFi pool reserves.

Data stored outside the blockchain's consensus layer, referenced on-chain via hashes or pointers. This includes large files, complex application data, and private information.

Common solutions:

• Decentralized Storage Networks: IPFS, Arweave, Filecoin.
• Centralized Cloud Services: AWS S3, Google Cloud Storage.
• Layer-2 Scaling: Data availability layers like Celestia or EigenDA.

Trade-offs:

• Lower Cost: Avoids expensive on-chain gas.
• Reduced Guarantees: May rely on external availability and integrity assumptions.
• Use Case: Storing NFT metadata, application front-ends, large datasets.

The guarantee that transaction data is published and accessible for network participants to download. This is distinct from data storage and is a core security requirement for Layer 2 rollups and validiums.

Why it matters: Without available data, nodes cannot reconstruct state or verify transaction validity, breaking trust assumptions.

Solutions:

• On-Chain: Full data posted to L1 (e.g., Optimistic Rollups).
• Off-Chain with Proofs: Data availability committees or networks like Celestia provide cryptographic proofs that data is available.

Blockchains manage two primary data types with different storage implications.

State Data: The current snapshot of all accounts and smart contracts (e.g., ETH balance, Uniswap pool liquidity). This is mutable and expensive to store on-chain, leading to state bloat.

Transaction Data: The immutable history of all actions (inputs, outputs, logs). This is append-only and can be pruned by some clients.

Design Impact: Applications must decide what belongs in state (costly, live) versus what is logged in transaction history (cheaper, historical).

On-chain storage is the most expensive blockchain operation. A single 32-byte word costs ~20,000 gas on Ethereum. Developers use several techniques to minimize costs:

Optimization Strategies:

• Packing: Store multiple small variables in a single storage slot.
• Events: Use log events instead of storage for non-essential data.
• Off-Chain Reference: Store data hashes on-chain, full data off-chain.
• State Channels: Conduct transactions off-chain, settle final state on-chain.

Example: Storing a user's profile picture directly on-chain is prohibitively expensive; storing an IPFS hash is standard practice.

The location of data determines how it is verified and what trust assumptions are required.

On-Chain Trust Model: Data validity is enforced by blockchain consensus. Verification is cryptographic and permissionless.

Off-Chain Trust Model: Validity depends on the security and honesty of the external storage provider or proof system.

Hybrid Approaches:

• Commit-Reveal Schemes: Submit a hash on-chain, reveal data later.
• Zero-Knowledge Proofs: Prove knowledge of off-chain data without revealing it.
• Data Availability Proofs: Cryptographic guarantees that off-chain data is retrievable.

Choosing a model balances cost, security, and application requirements.

The execution state and business logic of smart contracts must be stored on-chain. This includes token balances for ERC-20 contracts, ownership records for NFTs (ERC-721/1155), and the rules governing DeFi protocols like Uniswap or Aave. On-chain storage ensures deterministic execution and global consensus on the contract's current state, which is non-negotiable for decentralized applications.

All transactions that modify financial state must be settled on-chain. This includes:

• Token transfers and swaps on DEXs
• Loan origination and repayment in lending protocols
• Yield farming stakes and rewards distribution Storing this data on a public ledger like Ethereum or Solana provides a transparent, auditable, and censorship-resistant record of all value movements, which is critical for user trust and protocol security.

On-chain storage is the definitive source of truth for digital asset ownership. NFT metadata pointing to media can be off-chain, but the token ID and owner address are stored on-chain (e.g., on Ethereum Mainnet). This creates a globally verifiable proof of ownership and provenance that cannot be forged, which is fundamental to digital collectibles, in-game assets, and tokenized real-world assets (RWAs).

Governance actions for DAOs and protocols require on-chain finality. This includes:

• Proposal metadata and voting power snapshots
• Executed transaction payloads (e.g., parameter changes, treasury spends)
• Delegation records for voting tokens Storing these actions on-chain, as seen with Compound's Governor Bravo or Aave's governance, ensures the process is transparent, tamper-proof, and enforceable by the underlying smart contracts.

Critical state for cross-chain operations must be secured on-chain. Bridge validators or light client states for networks like Cosmos IBC are stored on-chain to verify the validity of messages from another chain. The lock/unlock or mint/burn records for bridged assets (e.g., Wrapped BTC) are also stored on-chain to maintain a 1:1 collateralization ratio and prevent double-spending across chains.

A peer-to-peer hypermedia protocol for storing and sharing data in a distributed file system. Content is addressed by its cryptographic hash (CID), ensuring immutability.

• Content-addressed storage: Data is retrieved by its hash, not location.
• Decentralized network: Files are stored across a global network of nodes.
• Common use cases: Storing NFT metadata, website frontends, and large datasets.

Projects like Filecoin add economic incentives for persistent storage on IPFS.

A blockchain-like protocol designed for permanent, low-cost data storage. It uses a blockweave structure and a Proof of Access consensus mechanism.

• One-time, upfront payment for perpetual storage.
• Data persistence is incentivized; miners store random old data to produce new blocks.
• Primary use: Archiving critical data, hosting decentralized applications (dApps), and storing historical records permanently.

A modular blockchain network that specializes in data availability (DA). It allows other blockchains (rollups) to post their transaction data securely and verifiably off-chain.

• Data Availability Sampling (DAS): Light nodes can cryptographically verify data is published without downloading it all.
• Enables scalable rollups: Separates execution from consensus and data availability.
• Core function: Provides a secure base layer for L2s to ensure their data is published and accessible.

A high-throughput data availability (DA) layer built on Ethereum by EigenLayer. It leverages Ethereum's economic security through restaking.

• Actively Validated Services (AVS): Operators restake ETH to secure services like EigenDA.
• High bandwidth: Designed to support high-volume rollups at lower cost than calldata.
• Security model: Inherits cryptoeconomic security from Ethereum's validator set.

A decentralized storage network that turns cloud storage into an algorithmic market. It provides verifiable, long-term storage with economic guarantees.

• Storage proofs: Miners prove they are storing client data over time using Proof-of-Replication and Proof-of-Spacetime.
• Market-based pricing: Users pay FIL tokens to storage providers.
• Often used with IPFS: Filecoin provides persistent storage for content addressed by IPFS CIDs.

A decentralized cloud storage platform that uses client-side encryption and sharding to store data across a global network of storage nodes.

• End-to-end encryption: Data is encrypted before leaving the user's device.
• Data resilience: Files are erasure-coded and distributed across dozens of nodes.
• S3-compatible: Offers an API compatible with Amazon S3, easing integration for developers.

Ethereum treats on-chain data as part of the global state or transaction calldata, replicated across every full node. This guarantees immutability and verifiability, but introduces hard constraints on cost and throughput.

Key references explain:

• State vs calldata: Storage slots (~20,000 gas per SSTORE) versus calldata (~16 gas per non-zero byte).
• Merkle Patricia Tries: How account state and storage are cryptographically committed.
• Execution vs data availability: Why even "inactive" storage increases long-term node requirements.

Practical implications:

• Token balances, ownership, and permissions belong on-chain.
• Large datasets (images, logs, ML outputs) are economically infeasible to store directly.
• Gas pricing enforces scarcity and prevents state bloat.

This documentation is foundational when deciding what data must remain on-chain for trust minimization.

IPFS provides off-chain data storage using content addressing, where files are identified by cryptographic hashes instead of locations. Blockchains typically store the CID on-chain, while the content itself is distributed externally.

Core properties covered in the docs:

• Content-addressed integrity: Any data change produces a new CID.
• No built-in permanence: Availability depends on pinning or incentive layers.
• Deterministic verification: Hash comparison ensures data authenticity.

Common usage patterns:

• NFTs storing media and metadata off-chain.
• DAO governance proposals referencing large documents.
• dApps logging events or analytics data externally.

Understanding IPFS limitations is critical: IPFS alone does not guarantee uptime, ordering, or economic incentives without complementary protocols.

Ethereum’s scalability roadmap separates execution, settlement, and data availability. EIPs like EIP-4844 introduce blobs to lower the cost of posting data needed by rollups without permanently bloating L1 state.

Documentation highlights:

• Proto-danksharding (EIP-4844): Temporary data accessible to consensus but pruned later.
• Rollup reliance on DA: Off-chain execution still requires on-chain data publication.
• Reduced calldata costs: Enabling higher throughput at predictable fees.

Why this matters:

• Rollups store transaction data on L1 but keep execution state off-chain.
• DA layers define trust boundaries for users verifying rollup behavior.
• Future sharding further reduces storage pressure on validators.

These resources are essential for understanding modern hybrid storage models.

Chainlink’s documentation explains how off-chain data and computation are securely bridged to on-chain smart contracts using decentralized oracle networks (DONs).

Key concepts include:

• Off-chain data aggregation with on-chain verification.
• Threshold signatures and fault tolerance assumptions.
• Hybrid smart contracts combining on-chain logic with off-chain execution.

Storage-relevant use cases:

• Referencing off-chain databases or APIs with cryptographic guarantees.
• Storing large datasets externally while anchoring results on-chain.
• Reducing gas by moving computation and data processing off-chain.

These docs illustrate real-world patterns where full on-chain storage is unnecessary, but trust assumptions must be explicitly modeled.