Verifiable Data Package and Verifiable Data Feed: New Primitives for Web3 Apps

Enterprise-grade Web3 needs data you can independently verify, reuse across chains, and plug into onchain logic with predictable cost and latency. This post introduces two practical building blocks—Verifiable Data Packages (VDPs) and Verifiable Data Feeds (VDFs)—and shows how to design, ship, and govern them with today’s best-in-class infrastructure.

TL;DR

• A Verifiable Data Package (VDP) is a portable container that bundles data + schema + provenance + cryptographic attestations (signatures/commitments/proofs) and anchors into durable storage or DA layers. Think “shipment with bill of lading and notary proofs,” but machine-verifiable. RedStone’s signed data packages and unpack/verify-on-chain flow exemplify this pattern. (docs.redstone.finance)
• A Verifiable Data Feed (VDF) continuously delivers VDPs via push or pull models with onchain verification and freshness/SLA controls. You can implement VDFs today using: Chainlink Data Streams/OCR for sub‑second, quorum‑signed reports; API3 first‑party dAPIs; or Pyth/RedStone pull models for low cost and low latency when you need updates on demand. (docs.chain.link)
• Anchor VDPs and feed checkpoints using EIP‑4844 blobs for cheap, ephemeral DA (≈18 days), plus permanent stores (Arweave) or DA layers (Avail, EigenDA) for long-term verifiability and cross‑chain proofs. Use storage proofs (e.g., Herodotus) when contracts must verify remote state synchronously. (eips.ethereum.org)

---

Why new primitives now

• L2s scaled compute, but the hard part is verifiable data movement. Even after Ethereum’s EIP‑4844 introduced blob transactions with separate “blob gas” and cheap, short‑lived DA, you still need a repeatable way to package, attest, and re‑anchor data across chains and time. (eips.ethereum.org)
• Oracle stacks matured. You can choose between quorum‑signed reports (Chainlink OCR/Data Streams), first‑party oracle nodes (API3), or pull‑based updaters (Pyth, RedStone) with onchain verification of signatures and staleness. These map cleanly to VDF patterns. (docs.chain.link)
• Cross‑chain proofs are production‑ready. Storage proof services (Herodotus) and ZK light‑client initiatives (e.g., Telepathy) reduce trust in bridges and make “verify elsewhere’s state” a standard tool for feeds that span L1/L2/L3. (docs.herodotus.dev)

---

Definition: Verifiable Data Package (VDP)

A VDP is a deterministic, signed, and anchorable data container. It lets any contract or service re‑derive integrity and provenance independently, even years later.

Required parts:

• Payload: opaque domain data (e.g., price tick, NAV snapshot, emissions reading).
• Schema and version: canonical typing and semantic meaning (e.g., JSON‑Schema, Cap’n Proto, SSZ).
• Provenance: data source URIs, collection method, time, jurisdiction, license.
• Attestations:
  • Signatures (e.g., secp256k1 or BLS aggregate) from issuers/oracle nodes.
  • Commitments (Merkle/KZG) over payloads/batches for efficient inclusion proofs.
  • Optional zero‑knowledge proofs (e.g., Proof of SQL for query correctness). (prnewswire.com)
• Anchors: references to where the package or its commitments are published (EIP‑4844 blob commitment, Arweave TXID, IPFS CID, Avail/EigenDA certificate). (eips.ethereum.org)

VDP pattern in the wild:

• RedStone encodes signed “data packages,” appends them to calldata only when needed, then verifies signatures and timestamps on‑chain before aggregation. (docs.redstone.finance)

Example VDP (minimal JSON, fields are illustrative):

{
  "vdp_version": "1.1.0",
  "schema": "com.7block.price.v1",
  "payload": {
    "asset": "ETH-USD",
    "price": "3567.42",
    "price_type": "mid",
    "venue_set": ["CBOE", "CME", "Kraken"],
    "asof_ms": 1765753200123
  },
  "provenance": {
    "collectors": ["did:web:data.vendor.example"],
    "method": "VWAP_3s_venue_weighted",
    "jurisdiction": "US",
    "license": "CC-BY-4.0"
  },
  "attestations": {
    "signers": [
      {"kid": "did:pkh:eip155:1:0xabc…", "alg": "secp256k1", "sig": "0x…"},
      {"kid": "did:pkh:eip155:1:0xdef…", "alg": "secp256k1", "sig": "0x…"}
    ],
    "commitment": {
      "type": "merkle",
      "root": "0xMERKLEROOT…",
      "leaf_hash": "0xLEAF…",
      "path": ["0x…","0x…"]
    }
  },
  "anchors": {
    "eip4844_kzg": "0xKZGCOMMITMENT…",
    "arweave_tx": "bT2…q7E",
    "da_cert": {"layer": "Avail", "block": 1234567, "proof": "0x…"}
  }
}

• EIP‑4844 makes the KZG commitment accessible to contracts while blob contents remain transient; long‑term auditability comes from re‑anchoring (e.g., Arweave) or DA certificates (Avail/EigenDA). (eips.ethereum.org)

---

Definition: Verifiable Data Feed (VDF)

A VDF is a transport and lifecycle for VDPs. It defines how packages are produced, disseminated, verified, aggregated, and expired/slashed, with SLAs for freshness and liveness.

Feed archetypes you can deploy today:

• Quorum‑signed push feeds: Chainlink OCR aggregates node observations off‑chain, produces a quorum‑signed report, and submits to an aggregator contract (with median + timestamp). Data Streams extends this with sub‑second, pull‑to‑verify reports you can check onchain when used. (docs.chain.link)
• First‑party operator feeds: API3 dAPIs are run by data providers themselves and published on‑chain across many L1/L2s. (businesswire.com)
• Pull‑on‑demand feeds: Pyth and RedStone let users fetch latest signed updates off‑chain and attach them to the call; the contract verifies signatures, freshness, and aggregates. This minimizes gas and maximizes timeliness. (docs.pyth.network)

Key knobs:

• Freshness policy (stale‑after N seconds/blocks; revert on

  StalePrice

  ). (docs.pyth.network)
• Deviation/heartbeat policy (push oracles update when threshold or heartbeat elapses). (docs.chain.link)
• Transport: REST/WebSocket/SDKs for low‑latency pull streams (e.g., Chainlink Data Streams SDKs). (docs.chain.link)
• Anchoring cadence: how often the feed rolls up batch commitments to blobs/DA/permanent storage. (eips.ethereum.org)

---

Practical pattern 1: Low-latency market data for DeFi perps

When to use:

• Sub‑second reads and frequent writes, with onchain verification when executed.

Recipe:

1. Use Chainlink Data Streams to subscribe to a “mark price + LWBA + staleness bit” channel for your instruments; consume via WebSocket and verify reports onchain at trade time. (chain.link)
2. Normalize into VDPs client‑side (include venue list, timestamp, data quality flags), aggregate signatures where available, and anchor batch commitments every minute to an EIP‑4844 blob; also persist full batch to Arweave for permanent audit. (eips.ethereum.org)
3. In your solidity, check: (a) report cryptographic validity; (b)

   updatedAt

   /staleness bound; (c) guardrails during halted markets. Chainlink maintains “market availability” signals to help distinguish open/closed trading hours for tokenized equities/ETFs. (chain.link)

Why it works:

• You get the speed of pull‑verification with the assurances of quorum signatures and immutable anchoring for downstream audits.

---

Practical pattern 2: Cost-efficient, on-demand price reads for AMMs/lending

When to use:

• You prioritize gas efficiency and only need updated data at interaction time (swap, borrow, liquidate).

Recipe:

1. Integrate a Pyth or RedStone pull model: dApp callers fetch the latest signed update and attach it to the tx; your contract calls

   updatePriceFeeds()

   and then reads. Enforce a per‑asset

   maxAge

   and permitted signers list. (docs.pyth.network)
2. Package each update into a VDP and anchor hourly to a blob for cheap DA; roll daily to Arweave for permanence and to Avail/EigenDA if you need cross‑rollup readers to verify inclusion cheaply. (eips.ethereum.org)
3. For TON, Solana, or non‑EVM chains, reuse the same pattern with vendor SDKs; RedStone documents TON connectors and pull verification semantics. (docs.ton.org)

Why it works:

• Update costs scale with usage; verification is explicit and programmable.

---

Practical pattern 3: RWA reserve and NAV feeds with automated safeguards

When to use:

• You must demonstrate “verifiably backed” assets and enforce mint/ redeem guardrails onchain.

Recipe:

1. Use Chainlink Proof of Reserve or SmartData to stream reserve balances, composition, timestamps, and supply into a single report; enforce onchain checks that pause minting if reserve ratio drops below thresholds. (chain.link)
2. Wrap each report as a VDP with bank custodian attestation metadata and auditor certificate hash.
3. Anchor commitments to blobs for operational cost control and mirror to Arweave for investor‑facing transparency. (eips.ethereum.org)
4. If your governance or sub‑DAOs live on other chains, let them verify L1/L2 states with storage proofs (e.g., show that “reserve feed at block X equals Y” without trusting bridges). (docs.herodotus.dev)

---

Practical pattern 4: Operational analytics and compliance KPIs via ZK-verified queries

When to use:

• You need to prove query correctness over chain data and your enterprise DBs without revealing raw tables.

Recipe:

1. Run queries in Space and Time; obtain a Proof of SQL that your WHERE/JOIN/AGG steps were executed faithfully over specified snapshots. Package query result + proof as a VDP. (prnewswire.com)
2. Publish VDF updates to governance contracts that unlock budget or trigger alerts only when KPIs pass (e.g., “30‑day net collateral inflows above threshold”).
3. Anchor commitments; keep full proofs and input data hashes in permanent storage for third‑party audit. (prnewswire.com)

---

Data availability and anchoring choices (and how to combine them)

• EIP‑4844 blobs (Ethereum): cheap, transient DA (≈18 days retention), KZG commitment accessible to contracts for inclusion checks. Ideal for rolling anchors and short‑term retrieval. Plan a re‑anchoring policy to permanence. (eips.ethereum.org)
• Permanent storage (Arweave): keep full historical feed packages and provider history; RedStone uses Arweave for this to enable trustless provider performance assessment. (ar.io)
• DA layers (Avail, EigenDA): for high data volumes or multi‑rollup consumers; Avail mainnet provides fast DA guarantees with KZG + DAS and a growing validator/light‑client set; EigenDA v2 launched July 30, 2025 (per L2BEAT) and is increasingly used by rollups for higher throughput. (blog.availproject.org)
• Cross‑chain verification: storage proofs let contracts verify block/header/account/storage roots from other chains synchronously (e.g., L2 reads L1 state). (docs.herodotus.dev)

Decision guide:

• Low cost + short retention: blobs only; re‑anchor daily to Arweave. (eips.ethereum.org)
• High‑throughput feeds: post commitments or data to Avail/EigenDA, then provide succinct proofs/headers to consumers. (blog.availproject.org)
• Cross‑rollup governance: pair DA layer with storage proofs so each rollup can verify others’ feed checkpoints without trusted relays. (docs.herodotus.dev)

---

Emerging best practices for VDP/VDF design

• Deterministic encoding and canonicalization
  • Use CBOR/SSZ with explicit endianness and sorted fields to avoid signature malleability.
• Attestation strategy
  • For quorum feeds, prefer BLS aggregate signatures (compact) or Chainlink OCR‑style multi‑ECDSA quorum with explicit signer sets and rotate keys quarterly. (docs.chain.link)
  • For first‑party feeds (API3), document operator identities and SLAs; onchain consumers should track stale timestamps and fail closed. (businesswire.com)
• Freshness and safety rails
  • Implement

    maxAge

    and “circuit breakers” that halt actions when data is out of hours or stale—Data Streams surfaces market availability/staleness signals. (chain.link)
• Anchoring policy
  • Blob rollups every 1–5 minutes during peak; daily archival to Arweave; DA‑layer anchoring for cross‑rollup consumers. EIP‑4844’s blob gas is separate from EVM gas; monitor blob base fee dynamics. (eips.ethereum.org)
• Disputeability and auditability
  • Keep historical packages and signatures in permanent storage; RedStone’s Arweave record enables post‑facto provider assessment. (ar.io)
• Cross‑chain verifiability
  • Where contracts need external state, integrate storage proofs or ZK light clients to eliminate trusted relayers. (docs.herodotus.dev)
• Observability
  • Expose onchain metrics (latest round,

    updatedAt

    , signer quorum) and off‑chain telemetry; Chainlink documents heartbeat/deviation parameters you should monitor. (docs.chain.link)

---

Security checklist (ship this with your design doc)

• Package integrity
  • Use domain‑separated signing (

    EIP‑191

    ‑style) over canonical bytes; pin signer sets onchain.
• Feed misbehavior
  • Revert on staleness or missing quorum; require multiple independent providers for sensitive markets.
• DA failure modes
  • If blobs/DA unavailable, fail to safe mode (pause redemptions/mints); expose a manual governor circuit breaker. (chain.link)
• Cross‑chain assumptions
  • Prefer onchain‑verified storage proofs over centralized relayers; document any trust (e.g., whitelists) if unavoidable. (docs.herodotus.dev)
• Key lifecycle
  • Rotate keys regularly; publish keyset VDPs and anchor them; alert on signature set drift.

---

Implementation guide (90-day pilot)

Weeks 1–2: Discovery and threat model

• Pick 2–3 critical KPIs or price instruments.
• Choose a feed archetype (OCR push, first‑party dAPI, pull on demand). (docs.chain.link)

Weeks 3–4: VDP spec

• Lock schema, canonicalization, and attestation formats; define anchors (blob every 5 min; Avail/EigenDA hourly; Arweave daily). (eips.ethereum.org)

Weeks 5–6: Onchain integration

• Implement verification libraries and freshness checks; for pull models, integrate

  updatePriceFeeds()

  or RedStone contract wrappers. (docs.pyth.network)

Weeks 7–8: Cross‑chain consumers

• Add storage proof verification to one downstream chain for the same feed checkpoint. (docs.herodotus.dev)

Weeks 9–10: Observability and runbooks

• Dashboards for staleness, signer quorum, blob anchoring success; incident procedures for DA outages. (docs.chain.link)

Weeks 11–12: Audit and tabletop

• Simulate stale data, signer loss, DA unavailability, and cross‑chain reorgs; finalize SLAs and onchain safety switches.

---

Vendor/system map (when to use what)

• Chainlink Data Streams or OCR Data Feeds
  • Sub‑second DeFi, tokenized markets needing market‑status metadata, global distribution, and quorum‑signed reports. (chain.link)
• API3 managed dAPIs
  • First‑party operators (data providers run the nodes) across many L1/L2s, with a marketplace UX. (businesswire.com)
• Pyth
  • Pull‑oracle pattern with explicit

    maxAge

    enforcement and Hermes updates; ideal for cost‑efficient dApps that only update at interaction. (docs.pyth.network)
• RedStone
  • Modular pull/push, TON/non‑EVM support, and permanent Arweave history for provider accountability. (docs.ton.org)
• Space and Time (Proof of SQL)
  • ZK‑verified analytics/BI queries used as onchain KPIs or guardrails. Mainnet live since May 2025. (prnewswire.com)
• DA and persistence
  • Blobs for cheap rolling anchors; Avail for fast DA guarantees with KZG+DAS; EigenDA v2 for high‑throughput rollup posting (milestone launch July 30, 2025). (eips.ethereum.org)
• Cross‑chain verifiability
  • Storage proofs (Herodotus) and ZK light clients (Telepathy) to drop trust in relayers. (docs.herodotus.dev)

---

Brief, in‑depth: how EIP‑4844 changes feed economics

• Blobs separate data availability from EVM gas via a “blob base fee” market, decoupling feed posting costs from execution congestion. Blobs store up to ~128 KiB each; blocks include a limited number of blobs; retention is roughly 18 days. This is perfect for rolling feed anchors but insufficient for long‑term audits—hence Arweave/DA layering. (eips.ethereum.org)

---

What 7Block Labs will deliver

• VDP/VDF architecture and schema tailored to your domain (DeFi, RWA, DePIN, compliance).
• Onchain integrations with Chainlink/API3/Pyth/RedStone and storage‑proof rails for cross‑chain consumers. (chain.link)
• Anchoring policy across blobs, Avail/EigenDA, and Arweave with cost modeling and SLAs. (eips.ethereum.org)
• Runbooks for staleness, signer rotation, and DA outages; dashboards and incident response.

If you want verifiable data to be a competitive advantage—not a liability—VDPs and VDFs are the quickest path from slideware to provable, production‑grade Web3 systems.

---

Summary (meta description)

Verifiable Data Packages (VDPs) and Verifiable Data Feeds (VDFs) let you ship cryptographically attested data across chains with predictable cost, latency, and auditability. This guide shows how to build them today using Chainlink, API3, Pyth, RedStone, Space and Time, storage proofs, and EIP‑4844/DA layers—with concrete patterns, SLAs, and anchoring strategies. (chain.link)