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

Enterprise-grade Web3 demands data that you can verify on your own, reuse across different chains, and easily integrate into on-chain logic while keeping costs and latency predictable. In this post, we’ll dive into two useful building blocks: Verifiable Data Packages (VDPs) and Verifiable Data Feeds (VDFs). We’ll also cover how to design, implement, and manage these with the top-notch infrastructure available today.

TL;DR

• A Verifiable Data Package (VDP) is like a handy little container that brings together data, schema, provenance, and cryptographic attestations (you know, those signatures, commitments, and proofs) all wrapped up nicely and stored in durable storage or decentralized archive layers. It’s kind of like a shipment with a bill of lading and notary proofs, but the best part? It’s machine-verifiable! RedStone’s signed data packages and their process for unpacking and verifying on-chain really captures this idea. Check it out here: (docs.redstone.finance)
• A Verifiable Data Feed (VDF) is all about continuously delivering those VDPs either by pushing them out or pulling them in, while also ensuring on-chain verification and keeping an eye on freshness and service levels. If you want to dive into VDFs today, you've got options: Chainlink Data Streams or OCR for lightning-fast, quorum-signed reports; API3 first-party dAPIs; or if you're looking for budget-friendly and quick updates on demand, you can go for Pyth/RedStone pull models. More details can be found here: (docs.chain.link)
• To anchor VDPs and feed checkpoints, you can use EIP‑4844 blobs for cost-effective, short-term data availability (think about 18 days), plus you’ve got options for permanent storage like Arweave or decentralized archive layers such as Avail and EigenDA for that long-term verifiability and cross-chain proofing. And if you need contracts to verify remote states in real-time, don’t forget about using storage proofs like Herodotus. You can read more about it here: (eips.ethereum.org)

---

Why new primitives now

• L2s have really leveled up when it comes to compute, but the tricky part remains how we handle verifiable data movement. Even with Ethereum’s EIP‑4844 rolling out blob transactions that come with their own “blob gas” and budget-friendly, short-lived data availability, we still need a consistent way to package, attest, and re-anchor data across different chains and timelines. You can dive deeper into it here.
• Oracle stacks have definitely matured. You've got some solid options now: you can go with quorum-signed reports through Chainlink's OCR/Data Streams, first-party oracle nodes like API3, or pull-based updaters such as Pyth and RedStone, all of which offer on-chain verification of signatures and staleness. These choices integrate nicely with VDF patterns. Check out more about it here.
• Cross-chain proofs are totally ready for prime time. Services like Herodotus are offering storage proof solutions, and ZK light-client projects like Telepathy are reducing the reliance on bridges. This makes the whole “verify elsewhere’s state” approach a go-to tool for feeds that connect L1, L2, and L3. For more details, take a look here.

---

Definition: Verifiable Data Package (VDP)

A VDP is basically a data container that’s deterministic, signed, and anchorable. What this means is that any contract or service can independently verify its integrity and origin, even if years have passed.

Required parts:

• Payload: This is where you'll find your opaque domain data--think things like price ticks, NAV snapshots, or emissions readings.
• Schema and version: Here, we’re talking about the standardized typing and semantic meaning. Examples include JSON-Schema, Cap’n Proto, or SSZ.
• Provenance: This includes details like data source URIs, how the data was collected, timing, jurisdiction, and licensing info.
• Attestations:
  • Signatures from issuers or oracle nodes (like secp256k1 or BLS aggregate).
  • Commitments (Merkle/KZG) on payloads or batches to help with efficient inclusion proofs.
  • Optional zero-knowledge proofs (like Proof of SQL for verifying query correctness). (prnewswire.com)
• Anchors: These are your references pointing to where the package or its commitments are published, such as EIP-4844 blob commitments, Arweave TXIDs, IPFS CIDs, or Avail/EigenDA certificates. (eips.ethereum.org)

VDP Pattern in Action

• RedStone takes signed “data packages,” adds them to calldata only when it's necessary, and then checks signatures and timestamps on-chain before bringing everything together. You can dive deeper into this in their documentation.

Example VDP (minimal JSON, fields are illustrative):

{
  "id": "12345",
  "name": "Sample VDP",
  "description": "This is a sample Vulnerability Disclosure Policy.",
  "version": "1.0",
  "created_at": "2023-10-01T12:00:00Z",
  "updated_at": "2023-10-02T12:00:00Z",
  "contact": {
    "email": "contact@example.com",
    "url": "https://example.com/contact"
  },
  "scope": {
    "assets": [
      "https://example.com",
      "https://api.example.com"
    ],
    "exclusions": [
      "https://example.com/private",
      "https://example.com/secret"
    ]
  },
  "policy": {
    "accepting_reports": true,
    "reporting_process": "Please submit reports via email or through our contact form.",
    "response_time": "We aim to respond within 72 hours."
  }
}

{
  "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 opens up KZG commitments for contracts, while keeping the blob contents temporary. For long-term auditability, we can rely on re‑anchoring methods like Arweave or DA certificates such as Avail and EigenDA. (eips.ethereum.org)

---

Definition: Verifiable Data Feed (VDF)

A VDF is basically the journey and lifecycle for VDPs. It outlines how packages get made, distributed, verified, brought together, and eventually expired or slashed, along with service level agreements (SLAs) that cover freshness and liveness.

Feed archetypes you can deploy today:

• Quorum‑signed push feeds: Chainlink's OCR takes node observations and does some off-chain magic to create a quorum-signed report, which it then sends to an aggregator contract (complete with median and timestamp). If you want to take it a step further, Data Streams adds the ability to pull reports in under a second and verify them on-chain when you need them. Check it out here: (docs.chain.link)
• First‑party operator feeds: API3 dAPIs are pretty cool because they’re run directly by the data providers. They publish their data on-chain across various L1 and L2 networks. If you want to dive deeper, here’s more info: (businesswire.com)
• Pull‑on‑demand feeds: With Pyth and RedStone, users can grab the latest signed updates off-chain and bundle them with their call. The contract then checks for valid signatures, freshness, and does the aggregation. This approach saves on gas fees while keeping your updates timely. Learn more about it here: (docs.pyth.network)

Key Knobs:

• Freshness policy: This one’s all about making sure we don’t use stale data--set it to go stale after N seconds or blocks, and you can revert using StalePrice. Check out the details here.
• Deviation/heartbeat policy: Oracles will push updates whenever they hit a certain threshold or when a heartbeat period passes. You can learn more about this here.
• Transport: We’ve got options here! Use REST, WebSocket, or SDKs to get low-latency pull streams (like those handy Chainlink Data Streams SDKs). Dive into the specifics here.
• Anchoring cadence: This refers to how frequently the feed aggregates batch commitments into blobs/DA/permanent storage. Find out more about it here.

---

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

When to Use:

• For scenarios involving sub-second reads and regular writes, especially when you need on-chain verification during execution.

Recipe:

1. Start by using Chainlink Data Streams to sign up for a channel that gives you the “mark price + LWBA + staleness bit” for your instruments. You’ll want to pull this data through WebSocket and double-check the reports on-chain when you’re making trades. You can find more info here: (chain.link).
2. Next, normalize the data into VDPs on the client side. Be sure to include the venue list, timestamp, and data quality flags. When you can, aggregate signatures and send out batch commitments every minute to an EIP-4844 blob. Don't forget to save the entire batch to Arweave for a permanent audit trail! Check out the details here: (eips.ethereum.org).
3. In your Solidity code, make sure to validate: (a) the cryptographic integrity of the report; (b) whether the updatedAt timestamp is within the staleness limit; (c) the safety measures for when markets are on hold. Chainlink has “market availability” signals to help you tell when tokenized equities/ETFs are open or closed for trading. Learn more at: (chain.link).

Why it works:

• You benefit from the fast pull-verification process while enjoying the peace of mind that comes with quorum signatures and the security of immutable anchoring for any audits that come your way.

---

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

When to Use

• If you're all about gas efficiency and only need fresh data right when you're about to interact (like swapping, borrowing, or liquidating).

Recipe:

1. Integrate a Pyth or RedStone pull model: This means the dApp callers will grab the latest signed update and stick it onto the transaction. Your contract will call updatePriceFeeds() and then read the information. Make sure to set a maxAge for each asset and have a list of permitted signers. You can find more details here.
2. Package each update into a VDP: Anchor that hourly to a blob for some cost-effective data availability. Then, roll it up daily to Arweave for permanence, plus use Avail/EigenDA if you need cross-rollup readers to verify inclusion in a budget-friendly way. Check out the specifics here.
3. For TON, Solana, or non-EVM chains: Go ahead and reuse the same pattern using vendor SDKs. RedStone has documentation on their TON connectors and pull verification semantics, so take a look at that here.

Why it works:

• The costs of updates grow based on how much you use it, and you can clearly see and program verification.

---

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

When to Use:

• You need to show that your assets are “verifiably backed” and make sure to set up mint/redeem guardrails on the blockchain.

Recipe:

1. Start by using Chainlink Proof of Reserve or SmartData to gather all the good stuff: reserve balances, composition, timestamps, and supply into one comprehensive report. Make sure to set up those on-chain checks to pause minting if the reserve ratio dips below your set thresholds. Check it out here: (chain.link)
2. Next up, wrap each of those reports as a Verified Data Package (VDP) that includes bank custodian attestation metadata and auditor certificate hashes.
3. For the next step, anchor your commitments to blobs to keep an eye on operational costs, and don’t forget to mirror this to Arweave for that extra layer of transparency for your investors. More info here: (eips.ethereum.org)
4. If your governance or sub-DAOs are hanging out on different chains, allow them to verify L1/L2 states using storage proofs. This way, you can demonstrate that “reserve feed at block X equals Y” without having to trust any bridges. You can find more details here: (docs.herodotus.dev)

---

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

When to use:

• You want to ensure that your queries are accurate across your chain data and company databases, but you don’t want to expose the raw tables.

Recipe:

1. Start by running your queries in Space and Time. Make sure to grab a Proof of SQL that shows your WHERE, JOIN, and AGG steps were executed perfectly over the chosen snapshots. Bundle your query results together with the proof into a VDP. Check out more about it here.
2. Next up, publish those VDF updates to your governance contracts. These updates should only unlock budgets or send out alerts when your KPIs hit specific targets--like when "30‑day net collateral inflows hit above a certain threshold."
3. Finally, make sure to anchor your commitments. Keep all full proofs and input data hashes safely stored for future audits by third parties. You can find more details about this process here.

---

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

• EIP‑4844 Blobs (Ethereum): Think of these as a cost-effective and temporary data availability solution, with around 18 days of retention. They've got a KZG commitment that smart contracts can tap into for inclusion checks. Perfect for rolling anchors and quick data retrieval! Just remember to craft a re-anchoring policy when you want to make that data permanent. (eips.ethereum.org)
• Permanent Storage (Arweave): This is your go-to for keeping track of the full historical feed packages and provider history. RedStone relies on Arweave to ensure that the assessment of provider performance is trustless and reliable. (ar.io)
• DA Layers (Avail, EigenDA): If you're dealing with high data volumes or multiple rollup consumers, these layers have got your back. The Avail mainnet offers speedy data availability guarantees using KZG + DAS, along with an expanding pool of validators and light clients. Plus, EigenDA v2 dropped on July 30, 2025 (thanks, L2BEAT!), and more rollups are jumping on board for extra throughput. (blog.availproject.org)
• Cross‑Chain Verification: With storage proofs, contracts can seamlessly verify block, header, account, and storage roots from other chains all at once (like when an L2 checks out L1 state). It's pretty handy! (docs.herodotus.dev)

Decision guide:

• Low cost + short retention: Stick to blobs only and re-anchor them daily to Arweave. (eips.ethereum.org)
• High-throughput feeds: Send commitments or data over to Avail/EigenDA, then hook consumers up with tidy proofs or headers. (blog.availproject.org)
• Cross-rollup governance: Combine the DA layer with storage proofs so each rollup can check out the feed checkpoints of the others without needing trusted relays. (docs.herodotus.dev)

---

Emerging best practices for VDP/VDF design

• Deterministic encoding and canonicalization
  • To steer clear of signature malleability, go with CBOR/SSZ and make sure you use explicit endianness along with sorted fields.
• Attestation strategy
  • For quorum feeds, it’s better to stick with BLS aggregate signatures (they're compact) or opt for the Chainlink OCR-style multi-ECDSA quorum. Make sure to have explicit signer sets and rotate those keys every quarter. Check out more details here.
  • When it comes to first-party feeds (like API3), it’s key to document who the operators are and their SLAs. Onchain consumers should keep an eye on stale timestamps and make sure to fail closed. You can read more about this here.
• Freshness and safety rails
  • Set up maxAge and “circuit breakers” to pause actions when the data is either too old or stale. Data Streams can help by showing market availability and staleness signals. Check it out here.
• Anchoring policy
  • Aim for blob rollups every 1-5 minutes during peak times and make sure to archive daily to Arweave. It’s also a good idea to have DA-layer anchoring for cross-rollup users. Remember, EIP-4844’s blob gas is separate from EVM gas, so keep an eye on blob base fee dynamics. More info can be found here.
• Disputeability and auditability
  • Store historical packages and signatures in a permanent way. RedStone’s Arweave record allows for post-facto assessment of providers. You can see more about that here.
• Cross-chain verifiability
  • When contracts require access to external states, integrate storage proofs or ZK light clients to get rid of the need for trusted relayers. Dig into the details here.
• Observability
  • Don’t forget to expose onchain metrics (like the latest round, updatedAt, and signer quorum) alongside off-chain telemetry. Chainlink provides documentation on heartbeat and deviation parameters that you should keep an eye on. Check it out here.

---

Security checklist (ship this with your design doc)

• Package integrity
  • Go for domain-separated signing (EIP‑191-style) instead of just relying on canonical bytes; make sure to pin your signer sets on-chain.
• Feed misbehavior
  • If things get stale or the quorum is missing, just revert back; it’s a good idea to use multiple independent providers for those sensitive markets.
• DA failure modes
  • When blobs/DA aren't available, switch to safe mode (which means pausing redemptions/mints); it’s smart to have a manual governor circuit breaker ready to go. (chain.link)
• Cross‑chain assumptions
  • Stick to on-chain-verified storage proofs instead of relying on centralized relayers; if you absolutely have to trust something (like whitelists), make sure to document it. (docs.herodotus.dev)
• Key lifecycle
  • Make it a habit to rotate keys regularly; share keyset VDPs and make sure they’re anchored; and keep an eye out for any signature set drift.

---

Implementation guide (90-day pilot)

Weeks 1-2: Discovery and Threat Model

• Select 2-3 key KPIs or pricing tools that are essential.
• Decide on a feed archetype: you can go with OCR push, first-party dAPI, or pull on demand. Check out the details here.

Weeks 3-4: VDP Spec

• Finalize the schema, canonicalization, and attestation formats; set the anchors (blobs every 5 minutes; Avail/EigenDA hourly; Arweave daily). (eips.ethereum.org)

Weeks 5-6: Onchain Integration

• Set up those verification libraries and freshness checks! If you're using pull models, don’t forget to integrate updatePriceFeeds() or the RedStone contract wrappers. Check out the details here.

Weeks 7-8: Cross-chain Consumers

• Integrate storage proof verification into one downstream chain for the same feed checkpoint. Check out the details here: (docs.herodotus.dev).

Weeks 9-10: Observability and Runbooks

• We're focusing on setting up dashboards to keep an eye on things like staleness, signer quorum, and blob anchoring success. Plus, we’ll draft up incident procedures for any downtime with DA. Check out the details here: (docs.chain.link)

Weeks 11-12: Audit and Tabletop

• Run some simulations for stale data, loss of signer, downtime of DA, and cross-chain reorgs. Wrap up those SLAs and nail down the on-chain safety switches.

---

Vendor/system map (when to use what)

• Chainlink Data Streams or OCR Data Feeds
  • Perfect for those fast-paced DeFi projects and tokenized markets that need real-time market-status metadata, global reach, and quorum-signed reports. Check it out here: (chain.link)
• API3 managed dAPIs
  • These are run by first-party operators (you know, data providers who actually run the nodes) across a bunch of L1/L2s, all with a user-friendly marketplace vibe. More details here: (businesswire.com)
• Pyth
  • This one's all about that pull-oracle pattern with strict maxAge checks and timely Hermes updates; it's a great fit for cost-effective dApps that only refresh when they’re interacted with. Learn more at: (docs.pyth.network)
• RedStone
  • Offering a mix of modular pull/push options, support for both TON and non-EVM projects, plus a permanent Arweave history to keep providers accountable. Find the details here: (docs.ton.org)
• Space and Time (Proof of SQL)
  • ZK-verified analytics and BI queries that can be used as on-chain KPIs or guardrails. It went live on the mainnet back in May 2025. Check it out here: (prnewswire.com)
• DA and persistence
  • Offering blobs for affordable rolling anchors; with Avail for speedy DA guarantees using KZG+DAS; and EigenDA v2 set for high-throughput rollup posting, having its milestone launch on July 30, 2025. Get the scoop here: (eips.ethereum.org)
• Cross-chain verifiability
  • Featuring storage proofs (Herodotus) and ZK light clients (Telepathy) to help you ditch the reliance on relayers. Dive deeper here: (docs.herodotus.dev)

---

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

• Blobs give us a way to separate data availability from EVM gas by creating a “blob base fee” market. This means we can keep posting feeds without being affected by execution congestion. Each blob can hold around ~128 KiB, and blocks can include a certain number of these blobs, with data sticking around for about 18 days. This setup is great for rolling feed anchors, but it doesn’t quite cut it for long-term audits. That’s where Arweave/DA layering comes into play. (eips.ethereum.org)

---

What 7Block Labs will deliver

• Customized VDP/VDF architecture and schema to fit your specific needs, whether you're into DeFi, RWA, DePIN, or compliance.
• On-chain integrations with Chainlink, API3, Pyth, RedStone, plus storage-proof frameworks for cross-chain users. Check it out at (chain.link).
• Setting up anchoring policy across blobs, Avail/EigenDA, and Arweave, complete with cost modeling and SLAs. Learn more at (eips.ethereum.org).
• We’ve got runbooks ready for handling staleness, signer rotation, and data availability outages; plus, we offer dashboards and incident response plans.

If you're looking to turn verifiable data into a competitive edge instead of a burden, VDPs and VDFs are your best bet for moving from vague ideas to solid, production-grade Web3 systems quickly.

---

Summary (meta description)

Verifiable Data Packages (VDPs) and Verifiable Data Feeds (VDFs) make it super easy to send cryptographically verified data across different blockchains, all while keeping costs, timing, and auditing in check. This guide will walk you through the process of setting them up right now using Chainlink, API3, Pyth, RedStone, Space and Time, storage proofs, and EIP‑4844/DA layers. You'll find clear patterns, SLAs, and anchoring strategies to help you out. Check it out here: (chain.link)