Verifiable Data Package: What It Is and How to Deliver It to Smart Contracts

Summary: A verifiable data package (VDP) is a compact, tamper-evident bundle of data plus proofs that a smart contract can validate on-chain without trusting off-chain systems. This guide explains the anatomy of a VDP, compares delivery models (push, pull, optimistic, attested TLS, and ZK), and shows precise, production-ready ways to ship VDPs to contracts in 2025.

Why decision‑makers should care

Smart contracts can’t natively “know” anything beyond their chain. A VDP makes off-chain facts consumable with cryptographic guarantees and predictable costs.
The right packaging and delivery model directly affects latency, gas, liveness risk, compliance, and P&L for products like RWA tokenization, perps, lending, payments, and enterprise integrations.

Working definition: a Verifiable Data Package (VDP)

A VDP is an immutable message consisting of:

Header: version, schema ID, data source identifiers, chainId, timestamp, nonce/sequence, expiration, and replay domain.
Payload: one or more data items (e.g., prices, NAV/AUM, proofs-of-reserves, KPI metrics) with types and units.
Proofs: at least one of signature set, Merkle branch to a signed root, cross-chain attestation, TLS-origin proof, or zero-knowledge proof.
Verifier hints: the expected on-chain verifier contract interface and optional network addresses.
Policy: staleness window, minimum signer threshold (m-of-n), and failure behavior.

The VDP lets a contract deterministically check authenticity and freshness, then either update local state, revert, or trigger contingencies.

Common proof patterns you can assemble into a VDP

Signature-only: ECDSA/EIP‑712 signatures from approved signers over the payload or a Merkle root. Good for low-latency single-source facts. EIP‑712 gives typed-struct domain separation to prevent replay. (eips.ethereum.org)
Merkle-batched with cross-chain attestation: sign once over many items (root), ship only the leaf + branch on demand. Pyth aggregates prices, commits a Merkle root, and Wormhole guardians sign a VAA; contracts verify guardian signatures and Merkle proofs before updating on-chain price storage. (docs.pyth.network)
Gateway-confirmed offchain lookup: EIP‑3668 (CCIP-Read) where the contract reverts with OffchainLookup and later verifies the gateway’s response (e.g., a signature/Merkle proof) in a callback. Great for read-time proof fetching without pre-storing data. (eips.ethereum.org)
Optimistic assertion: propose a fact with a bond; accept if undisputed within a liveness window; escalate to a decentralized oracle/DVM on dispute. UMA OOv3 lets you set bonds and liveness per assertion. (docs.uma.xyz)
Attested TLS data: prove a specific HTTPS response came from a particular server without revealing everything (DECO) or with MPC notarization (TLSNotary). Useful for compliance-grade facts from Web2 APIs. (blog.chain.link)
ZK compute receipts: run code in a zkVM, get a proof (receipt) and minimal public output (“journal”), then verify on-chain. Ideal for heavy transforms, HTML/CSV parsing, or historical chain analytics. (dev.risczero.com)

Delivery models in 2025: when to use which

Push feeds (pre-published on-chain)

What: Oracle nodes publish to a canonical on-chain contract; consumers read state.
Use when: simple read path is paramount; latency tolerance is seconds; costs amortized by many readers.
Example: API3 dAPIs (first-party oracle nodes “Airnodes” push beacon values aggregated as dAPIs), maintained via Airseeker; first-party design and OEV Network to recapture oracle MEV. (airnode-docs.api3.org)

Pull on demand (report included with your transaction)

What: User attaches a VDP to the call; the contract verifies and uses it atomically.
Use when: sub-second latency or high-frequency updates are needed; you don’t want to pay for global storage every tick.
Examples:
- Pyth: fetch latest price update data + Wormhole-signed Merkle root from Hermes; call getUpdateFee and updatePriceFeeds, then read price within the same tx. Fees vary per network (often a tiny native token amount). (docs.pyth.network)
- RedStone: attach signed data packages from cache/gateways to calldata; contract verifies signer set and timestamp and extracts values with minimal gas. Live across 100+ chains and supports both push and pull. (github.com)

Low-latency signed reports with an on-chain verifier

What: Vendor signs reports; your contract calls a network-owned verifier to validate authenticity then consume.
Use when: trading/settlement needs sub-second data and contract-native verification.
Example: Chainlink Data Streams provides signed “reports” verified by a Streams Verifier contract; on-chain verification is priced per report (currently $0.35, 10% surcharge when paying in non-LINK). New product surfaces like SmartData package NAV/AUM/reserves in one report for RWA tokens. (docs.chain.link)

Optimistic assertions (write, accept if undisputed)

What: Post a claim with bond; if no dispute within liveness, it finalizes; otherwise, DVM arbitrates.
Use when: the “truth” is subjective or expensive to prove up front (governance proposals, audit states, off-chain event outcomes).
Example: UMA’s OOv3 with configurable bonds/liveness and integrations like oSnap for Snapshot-to-Safe execution. (docs.uma.xyz)

Permissionless reporter networks

What: Anyone can report, stake, and be disputed; protocols read medians or finalized values after dispute windows.
Use when: you want a credibly neutral, resilient supply of custom data types beyond vanilla prices.
Example: Tellor’s reporters stake TRB, submit values, and face disputes; guidance suggests keeping TRB reserves to dispute bad data quickly. (tellor.io)

TLS-attested facts (decentralized web attestations)

What: Prove an HTTPS response originated from a specific domain with confidentiality.
Use when: ingesting regulated Web2 facts (bank balances, BEA stats) with privacy constraints.
Examples: DECO’s TLS-based ZK attestations; TLSNotary’s MPC notarization with plans toward TLS 1.3. (blog.chain.link)

ZK coprocessors

What: Off-chain computation with verifiable receipts; contracts verify a succinct proof.
Use when: heavy data transforms, historical chain reads, or multi-source aggregation.
Examples: RISC Zero zkVM + Bonsai proof service; Axiom V2 (now sunset as the team moves to OpenVM) popularized ZK-verified access to Ethereum history. (dev.risczero.com)

Anatomy of a robust VDP schema (practical fields)

version: uint32
schemaId: bytes32 (EIP‑712 typehash or EAS schema UID)
chainId, verifyingContract: domain separation
data: array of { id: bytes32, value: int256/bytes, unit: bytes16 }
timestamp: uint64; notBefore/notAfter
nonce or sequence: uint128; monotonic per sender
source: array of publisher IDs; quorum m-of-n
proofs:
- signatures: array of { signer, alg, sig }
- merkle: { leaf, path[], root, rootSig[] }
- crossChain: e.g., Wormhole VAA bytes
- tls: proof transcript or ZK claim
- zk: receipt + imageId/verification key
policy: { stalenessSec, minSigners, rejectOnWeekends, failOpen | failClosed }
audit: off-chain URLs or IPFS CIDs for methodology docs
fee: optional payment directive for verifier-owned contracts

EAS can also be used to register the schema and anchor off-chain attestations if your trust model benefits from an attestation registry. (github.com)

Concrete implementation recipes

A) Sub-second prices for trading: Pyth pull model

At transaction time, fetch updateData from Hermes for required feed IDs.
Call IPyth.getUpdateFee(updateData) and forward the returned fee as msg.value to updatePriceFeeds(updateData).
Immediately read getPriceNoOlderThan with your recency threshold.

Key details:

Hermes exposes REST/SSE for latest updates; payload contains the Wormhole-attested Merkle root and inclusion proofs. (docs.pyth.network)
Contract verifies guardian signatures via Wormhole, then Merkle-inclusion, then updates on-chain price storage. (docs.pyth.network)
Fees are per update and chain-specific; check the “Current Fees” table and programmatically query getUpdateFee. (docs.pyth.network)

Example Solidity (simplified):

function trade(bytes[] calldata updateData, bytes32 feedId, uint maxStaleness)
  external payable returns (int64 price, int32 expo)
{
  uint fee = pyth.getUpdateFee(updateData);
  pyth.updatePriceFeeds{value: fee}(updateData);
  PythStructs.Price memory p = pyth.getPriceNoOlderThan(feedId, maxStaleness);
  return (p.price, p.expo);
}

B) RWA servicing data in one report: Chainlink Data Streams

Use Streams API to request a signed report containing NAV, AUM, reserves, and timestamps; verify on-chain via the Streams Verifier on your target network.
On-chain verification is priced per report at $0.35 (10% surcharge for non‑LINK payments). Design your contract to batch and cache reports to amortize verification cost. (docs.chain.link)
Data Streams is purpose-built for low-latency markets with modular fields (mid price, LWBA, volatility) and 99.9%+ uptime targets; SmartData packages financial servicing metrics for tokenized assets. (docs.chain.link)
Note “Weekend Usage Disclaimer” for certain tokenized asset streams; implement policy.failClosed during market holidays/weekends. (docs.chain.link)

Extra: On Sei, Streams is the preferred oracle infra, and Chainlink’s Commerce partnership brings Bureau of Economic Analysis data (GDP, PCE) onchain—useful for automated macro-linked coupons. (blog.sei.io)

C) Gas-minimal calldata delivery: RedStone packages

Off-chain: fetch from RedStone gateways (and/or Streamr), pack into a RedStone data package.
On-chain: the contract extracts the appended payload from msg.data, verifies ECDSA signatures against an allowlist, checks timestamp staleness, then reads target symbol values. (github.com)

Why teams choose it:

No continuous storage writes; values are “brought with the tx.”
Tooling exists for EVM, TON, and more; supports >1,300 assets and both push/pull models. (npmjs.com)

D) Governance or compliance statements: UMA OOv3

Post a bonded assertion (e.g., “Snapshot Proposal X passed with quorum Y”). If undisputed after your liveness window (default 2 hours, configurable), it finalizes and becomes consumable.
If disputed, the Data Verification Mechanism (DVM) arbitrates; set higher bonds/liveness for high-stakes assertions. UMA provides app patterns like oSnap (Snapshot→Safe). (docs.uma.xyz)

E) First-party API data without middlemen: API3 Airnode

API owners deploy Airnode (serverless) and map API operations to on-chain endpoints with OIS; dApps request via RRP or read dAPI feeds.
Airseeker updates beacons/dAPIs on deviation thresholds; OEV Network helps your protocol reclaim oracle MEV from update auctions. (airnode-docs.api3.org)

F) CCIP-Read for read-time retrieval

For anything heavy/rarely used, implement an EIP‑3668 flow: revert with OffchainLookup(sender, urls, callData, callbackSel, extraData). Your client fetches response from urls and calls back; your contract verifies response signatures or inclusion proofs before returning. (eips.ethereum.org)

G) TLS-attested reports

Use DECO or TLSNotary to prove a tuple like (issuer=api.example.com, path=/v1/nav, body_hash=H, time=T) without exposing full payload. Good for sensitive compliance data (e.g., custody reserves snapshots). (blog.chain.link)

H) ZK receipts for complex transforms

Run parsers or multi-source reconciliation in RISC Zero zkVM; submit Groth16 proof + journal to your contract and verify with the canonical verifier. Ideal when you must cryptographically show how a metric was computed. (dev.risczero.com)

Cost, latency, and risk trade-offs (practical numbers)

Verification fees: Chainlink Streams verifier $0.35/report (10% surcharge if paying in non‑LINK). Budget to batch reports or cache verified values. (docs.chain.link)
Pyth pull update fees: per network; many EVM chains quote nominal native token amounts (e.g., 0.01 SEI on Sei). Query getUpdateFee for exact current fee. (docs.pyth.network)
Optimistic oracles: set bonds to exceed potential gain from manipulation; default OO liveness ~2 hours but should be raised for high-value actions. (docs.uma.xyz)
Pull models avoid continuous storage writes; signature verification dominates gas—use packed structs and pre-registered signer sets to minimize overhead. RedStone’s on-chain parser is optimized with assembly for gas savings. (github.com)

Security and compliance playbook (emerging best practices)

Separate verifier and consumer contracts. Keep verifier minimal, audited, and upgradable behind a narrow proxy; route new schema versions via a registry.
Rotate keys safely. Use EIP‑712 domain separation (name, version, chainId, verifyingContract) and on-chain allowlists with explicit validity windows. (eips.ethereum.org)
Enforce policy in the VDP: stalenessSec, notBefore/notAfter, and circuit-breakers. For market-linked RWAs, block updates on weekends/holidays or require “market open” flags included in the report. Chainlink Streams provides market status and even a weekend usage disclaimer for some tokenized asset feeds. (chain.link)
Plan for data-source outages. Support multi-provider quorum (m-of-n) signatures or fallback to an optimistic route (e.g., UMA assertion) with higher liveness windows.
Reclaim oracle MEV. If your protocol pays for updates, consider OEV-style flows to return update value to the app instead of external arbitrageurs. (medium.com)
Observability: log schemaId, source set, proof type, fees paid, and measured latency. Publish a public status page; for signed reports, record verifier contract address and version.

End-to-end example designs

Latency-critical perps on a high-throughput chain

Primary: Chainlink Data Streams signed reports with verifier; consume mark price and LWBA; cache last verified report for N blocks.
Secondary: Pyth pull updates as redundancy; only trade if price from either source is fresh under X ms; impose wider limits under fallback.
Controls: pause trading during stale periods or if sources diverge > δ%. (chain.link)

Tokenized fund with on-chain NAV and issuance guards

Primary: SmartData report carrying NAV/AUM/reserves; mint/burn guarded by “proof valid and within T seconds.”
Secondary: TLS-attested NAV snapshot via DECO/TLSNotary to corroborate periodically.
Governance: if both primary and TLS attestations fail, freeze mint and escalate an UMA assertion for emergency resolution. (chain.link)

Cross-chain price consumer on an EVM L2

Pull Pyth updateData from Hermes; pay getUpdateFee; use getPriceNoOlderThan for asset pairs. Cache last-good price and include min confidence rules (Pyth includes confidence intervals). (docs.pyth.network)

Enterprise API integration (e.g., logistics SLA)

First-party Airnode by the enterprise; expose a “SLA breach count” endpoint mapped via OIS; dApp reads a dAPI or calls RRP directly.
If needed, add CCIP-Read so clients can fetch proofs lazily; attach a signer set for gateway responses. (airnode-docs.api3.org)

CCIP-Read callback structure (sketch)

Step 1: User calls read() → contract reverts with OffchainLookup(sender, urls, callData, callbackSel, extraData).
Step 2: Client fetches response from urls with callData.
Step 3: Client calls callback(response, extraData); contract verifies signature/Merkle/zk receipt and returns data.
This pattern avoids pre-publishing costs while preserving verifiability. (eips.ethereum.org)

EAS for governance/compliance breadcrumbs

Register a schema for “DataReport v1” or “ReserveAudit v1”; publish attestations anchoring report hashes and signers on-chain.
Consumers can query EAS Scan for attestations and cross-check against your verifier’s emitted events. (github.com)

Implementation checklist before mainnet

Choose model(s): push (dAPI), pull (Pyth/RedStone), signed reports (Streams), optimistic (UMA), TLS attested, ZK. Mix for redundancy.
Define your VDP schema and versioning. Pin methodology docs to IPFS; include schemaId in each package.
Build the verifier:
- Signature verification (EIP‑712 or raw ECDSA), Merkle proofs, VAAs if using Wormhole.
- Replay protection (nonce/sequence + notBefore/notAfter).
- Staleness checks and policy gates.
Integrate per-network fees and billing:
- Chainlink Streams verifier cost accounting; batching strategy. (docs.chain.link)
- Pyth getUpdateFee flow and fee table monitoring. (api-reference.pyth.network)
Add operational controls: circuit breakers, divergence checks across sources, and pausability.
Monitoring: emit structured events with schemaId/source/quorum/fee/latency; set alerts for stale data.
Security: audit the verifier; fuzz test malformed packages; run failover fire drills.
Legal/compliance: for RWA or regulated data, keep TLS attestation trails; consider weekend/market-closed policies where applicable. (docs.chain.link)

Where the space is heading

Broader low-latency coverage: Streams now spans equities/ETFs, FX, commodities with sub-second delivery; new SmartData surfaces for RWA servicing. (chain.link)
On-demand pricing at scale: Pyth’s pull model continues to grow, with hundreds of millions of updates per quarter and fees tuned per chain. (messari.io)
First-party dominance: more enterprises run Airnodes to publish verifiable data directly from the source, aided by OIS/RRP and OEV. (airnode-docs.api3.org)
Privacy-preserving attestations: DECO/TLSNotary adoption for Web2-origin facts; enterprise-grade RWAs will likely require this. (blog.chain.link)
ZK coprocessors as a standard: zkVM receipts will package both the data and the transformation, making “verifiable analytics” a VDP primitive. (dev.risczero.com)

If you’re architecting a new protocol or bringing enterprise data onchain, design your verifiable data package first, then pick the delivery model(s) that fit your latency, cost, and control requirements. With a well-specified VDP and a battle-tested verifier, you can plug into multiple sources—Pyth, Chainlink Streams/SmartData, RedStone, API3, UMA, Tellor, TLS attestations, or ZK coprocessors—and swap or combine them as your product scales.