Off-Chain Data

Real-time price feeds for assets like cryptocurrencies, stocks, and commodities, essential for DeFi applications. This includes:

• Spot prices for trading and lending (e.g., ETH/USD).
• Interest rates (e.g., SOFR, LIBOR) for money markets.
• Derivatives data like futures and options prices.

These feeds are typically aggregated from centralized and decentralized exchanges by oracles like Chainlink and Pyth to prevent manipulation.

Physical data captured by sensors and systems, enabling blockchain integration with tangible assets. Key examples are:

• Supply chain logistics (GPS location, temperature, humidity).
• Weather data for parametric insurance contracts.
• IoT sensor readings for energy grids or manufacturing.
• Sports scores and event outcomes for prediction markets.

This data bridges the gap between blockchain smart contracts and real-world conditions and agreements.

Verifiable credentials and user history stored off-chain for privacy and scalability. This encompasses:

• KYC/AML attestations from regulated providers.
• Decentralized Identifiers (DIDs) and verifiable credentials.
• Credit scores and on-chain transaction history (e.g., DeFi creditworthiness).
• Social graph data and community reputation scores.

Storing this sensitive data off-chain, with on-chain proofs, enhances user privacy and complies with data regulations like GDPR.

Results of complex computations performed off-chain to save gas, with cryptographic proofs of correctness posted on-chain. This includes:

• Zero-knowledge proofs (ZKPs) for private transactions or scaling.
• Optimistic rollup state roots, where computation is disputed only if challenged.
• Machine learning model inferences or large dataset analyses.

This pattern, known as layer 2 scaling or verifiable off-chain computation, dramatically increases blockchain throughput and capability.

Proprietary data from traditional business systems and web APIs that smart contracts may need to access. Common sources are:

• Payment settlement status from traditional banks (SWIFT, ACH).
• E-commerce inventory and order fulfillment data.
• Corporate earnings reports or regulatory filings.
• Any authenticated REST API endpoint.

Oracles provide a secure middleware layer to query, format, and deliver this data on-chain without exposing private API keys.

References (like content identifiers or hashes) stored on-chain that point to larger data files stored on decentralized storage networks. The primary examples are:

• IPFS (InterPlanetary File System) Content Identifiers (CIDs) for NFTs' media and metadata.
• Arweave transaction IDs for permanently stored data.
• Filecoin storage deals and retrieval proofs.

This pattern keeps the expensive blockchain used for immutable proof of ownership, while the bulk data is stored cost-effectively off-chain.

The primary security risk for systems relying on external data. Attackers can exploit oracles—services that feed off-chain data on-chain—to provide false information, leading to incorrect smart contract execution. This can result in liquidations, incorrect pricing, or fraudulent settlements. Key attack vectors include:

• Data Source Compromise: Hacking the primary data provider.
• Oracle Node Takeover: Gaining control of a majority of nodes in a decentralized oracle network.
• Man-in-the-Middle Attacks: Intercepting and altering data in transit to the oracle.

Ensuring that off-chain data is genuine and has not been tampered with before being referenced on-chain. Without cryptographic proof of origin and integrity, smart contracts cannot trust the data. Solutions to this challenge include:

• Commit-Reveal Schemes: Hashing data before publishing it to hide manipulation.
• Trusted Execution Environments (TEEs): Using secure hardware enclaves to process data confidentially.
• Data Attestations: Cryptographic signatures from trusted authorities or hardware.

Reliance on a single or a small set of off-chain data providers creates central points of failure. This can lead to:

• Service Downtime: Making dependent dApps unusable.
• Censorship: A provider refusing to publish or attesting to certain data.
• Coercion: Providers being forced by external entities to supply incorrect data. Decentralized oracle networks aim to mitigate this but introduce their own consensus and liveness challenges.

The guarantee that critical off-chain data remains accessible when needed by the blockchain. If data is hosted on centralized servers or private storage, it may become unavailable, causing smart contracts to fail. This is distinct from data authenticity. Key concerns are:

• Link Rot: URLs or API endpoints becoming invalid.
• Hosting Costs: Incentives for data providers to keep data available long-term.
• Decentralized Storage: Using networks like IPFS or Arweave to improve persistence, though retrieval speed and guarantees vary.

When off-chain data is used to validate cross-chain transactions (e.g., in bridges), the security of billions in value depends on the correctness of the relayer software and cryptographic assumptions. Common flaws include:

• Signature Verification Bugs: Incorrectly validating multi-sig thresholds or cryptographic proofs.
• Race Conditions: Exploiting timing gaps between off-chain event observation and on-chain finalization.
• Governance Attacks: Compromising the multi-sig or DAO that controls bridge parameters.

While off-chain computation (e.g., zk-SNARKs, state channels) can enhance privacy, the data inputs and outputs must be handled carefully. Security risks include:

• Input Data Exposure: Revealing sensitive information submitted to generate a zero-knowledge proof.
• Metadata Analysis: Inferring transaction details from timing, frequency, or counterparties of off-chain data fetches.
• Trusted Setup Ceremonies: For some cryptographic systems, a compromised initial ceremony can undermine all subsequent privacy guarantees.

Data Availability Layers ensure that transaction data for a blockchain (like a rollup) is published and accessible, even if it's not stored on the main chain (e.g., Ethereum L1). This is critical for security and validity proofs. Key solutions include:

• Ethereum as a DA layer (using calldata or blobs).
• Celestia, a modular network specializing in DA.
• EigenDA, a restaking-based DA service.
• Avail, a Polkadot-based DA solution.

This refers to performing complex computations off-chain and generating a cryptographic proof that the computation was executed correctly. The small proof is then verified on-chain. This enables scalable dApps.

• Zero-Knowledge Proofs (ZKPs): Used in ZK-Rollups to prove the validity of batched transactions.
• Optimistic Rollups: Assume transactions are valid but allow for fraud proofs if challenged.
• zkEVMs: Execute Ethereum Virtual Machine (EVM) transactions and prove correctness with ZKPs.

A cryptographic technique used to submit data on-chain without immediately exposing it. It involves two phases:

1. Commit: A user publishes a hash (commitment) of their data.
2. Reveal: Later, they reveal the original data. The chain verifies it matches the hash. This prevents front-running in auctions or voting by hiding information until a deadline passes, using the blockchain as a judge for the revealed off-chain data.