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

Why decision‑makers should care

• Smart contracts aren’t built to know much outside of their own blockchain. That’s where a VDP comes in--it makes off-chain information accessible while providing cryptographic guarantees and predictable costs.
• How you package and deliver your data really impacts things like latency, gas fees, liveness risk, compliance, and even your profit and loss, especially for products like RWA tokenization, perps, lending, payments, and enterprise integrations.

Working definition: a Verifiable Data Package (VDP)

A VDP is essentially an unchangeable message that includes:

• Header: This part covers all the essentials like version, schema ID, data source identifiers, chainId, timestamp, nonce/sequence, expiration, and replay domain.
• Payload: Here you'll find one or more data items--think prices, NAV/AUM, proofs-of-reserves, KPI metrics, and so on--along with their types and units.
• Proofs: At least one proof is required, which could be a signature set, Merkle branch to a signed root, cross-chain attestation, TLS-origin proof, or zero-knowledge proof.
• Verifier hints: This section outlines the expected on-chain verifier contract interface and may include some optional network addresses.
• Policy: This specifies the staleness window, minimum signer threshold (m-of-n), and outlines the behavior in case of failure.

The VDP allows a contract to reliably check if something is authentic and up-to-date. Based on that check, it can either update its local state, roll back to a previous state, or activate certain contingencies.

Common proof patterns you can assemble into a VDP

• Signature-only: Think ECDSA/EIP‑712 signatures from a select group of signers on the payload or even a Merkle root. This is perfect for grabbing quick facts from a single source. EIP‑712 gives us that typed-struct domain separation to dodge replay attacks. (eips.ethereum.org)
• Merkle-batched with cross-chain attestation: Here, you sign once for a bunch of items (the root) and just send the leaf + branch when needed. Pyth does this by pulling together prices, locking in a Merkle root, and having Wormhole guardians sign a VAA; then, contracts check those guardian signatures and Merkle proofs before updating the on-chain price storage. (docs.pyth.network)
• Gateway-confirmed offchain lookup: This one's all about EIP‑3668 (CCIP-Read) where the contract can revert with an OffchainLookup and then checks the gateway’s response (like a signature or Merkle proof) later on in a callback. It’s a super handy way to fetch proof in real-time without needing to store the data beforehand. (eips.ethereum.org)
• Optimistic assertion: Here’s the deal: propose a fact with a bond attached; if no one disputes it in a set timeframe, it gets accepted; otherwise, you can escalate to a decentralized oracle/DVM if there’s a disagreement. With UMA OOv3, you can set those bonds and liveness periods however you want for each assertion. (docs.uma.xyz)
• Attested TLS data: This allows you to prove that a specific HTTPS response came from a certain server without giving away all the details (thanks to DECO) or using MPC notarization (with TLSNotary). It’s super useful for those compliance-level facts coming from Web2 APIs. (blog.chain.link)
• ZK compute receipts: You run some code in a zkVM, get a proof (or receipt) along with minimal public output (“journal”), and then verify it on-chain. This is fantastic for heavy lifting like transformations, HTML/CSV parsing, or digging through historical chain analytics. (dev.risczero.com)

Delivery models in 2025: when to use which

1) Push Feeds (Pre-Published On-Chain)

• What: Here’s the deal: Oracle nodes send updates to a main on-chain contract, so consumers can easily read the current state.
• Use When: This setup is great when you need a straightforward read path, can handle a few seconds of latency, and have enough readers to spread out the costs.
• Example: Check out API3 dAPIs--these first-party oracle nodes, known as “Airnodes,” push out beacon values that are bundled together as dAPIs. They're kept up to date through Airseeker, and their first-party design combined with the OEV Network helps snag back oracle MEV. You can dive deeper into it here.

2) Pull on demand (report included with your transaction)

• What: You can attach a VDP (Validated Data Package) to your call, and the contract will verify and use it all in one smooth go.
• Use when: You need super quick updates--like sub-second latency--or you want to avoid those pesky global storage fees racking up every tick.
• Examples:
  • Pyth: This lets you fetch the latest price updates along with a Wormhole-signed Merkle root from Hermes. Just call getUpdateFee, update the price feeds, and you can read the price, all in the same transaction. Keep in mind that fees can vary by network, but it’s usually just a tiny bit of native token. (docs.pyth.network)
  • RedStone: Here, you can attach signed data packages from their cache or gateways directly to the calldata. The contract checks the signer set and timestamp, pulling out values with minimal gas. Plus, it’s live across 100+ chains and can handle both push and pull. (github.com)

3) Low-latency signed reports with an on-chain verifier

• What: Here’s the deal: a vendor signs off on reports, and then your contract taps into a network-owned verifier to check their authenticity before using them.
• Use when: This is perfect for those times when trading or settling requires lightning-fast data--think sub-second speeds--and you want that verification to happen right in the contract.
• Example: Check out Chainlink Data Streams! They provide these signed “reports” that get verified by a Streams Verifier contract. The cool part? On-chain verification is priced at $0.35 per report, but there’s a 10% extra fee if you pay with something other than LINK. Plus, they’ve got new offerings like the SmartData package, which conveniently rolls up NAV, AUM, and reserves all in one report for RWA tokens. You can find more details in their documentation.

4) Optimistic assertions (write, accept if undisputed)

• What: You post a claim along with a bond. If no one disputes it within the set time frame, it gets finalized. If there’s a dispute, the DVM steps in to sort it out.
• Use when: This approach is great for situations where the “truth” can be tricky or costly to prove right off the bat. Think governance proposals, audit states, or outcomes from off-chain events.
• Example: Check out UMA’s OOv3, which has configurable bonds and liveness, plus cool integrations like oSnap for seamless Snapshot-to-Safe execution. You can dive deeper into it here: docs.uma.xyz.

5) Permissionless Reporter Networks

• What: In these networks, anyone can jump in to report, stake, or challenge submissions. The protocols handle the dirty work by reading medians or finalized values after the dispute period is over.
• Use When: You’re looking for a reliable and unbiased source of custom data types that go beyond just the basic price info.
• Example: Take Tellor, for instance. Their reporters stake TRB, submit data, and can get into disputes. It's smart to keep some TRB reserves on hand so you can quickly dispute any dodgy data. Check it out at tellor.io.

6) TLS-attested facts (decentralized web attestations)

• What: This helps you confirm that an HTTPS response came from a particular domain while keeping things private.
• Use when: You need to bring in regulated Web2 facts, like bank balances or BEA stats, and there are privacy concerns to think about.
• Examples: Check out DECO’s TLS-based ZK attestations and TLSNotary’s MPC notarization, which is eyeing TLS 1.3. (blog.chain.link)

7) ZK Coprocessors

• What: These are all about doing off-chain computations while providing verifiable receipts. Basically, contracts can check a compact proof.
• Use when: They come in handy for heavy data transformations, digging into historical reads of the chain, or when you need to pull together data from multiple sources.
• Examples: You’ve got the RISC Zero zkVM along with the Bonsai proof service, and then there’s Axiom V2 (which is now winding down as the team shifts to OpenVM). Axiom really brought ZK-verified access to Ethereum’s historical data into the spotlight. Check it out here: 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; must be 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

You can totally use EAS to register your schema and anchor off-chain attestations, especially if having an attestation registry fits well into your trust model. Check it out on GitHub!

Concrete implementation recipes

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

1. When you're ready to make a transaction, grab the updateData from Hermes for the feed IDs you need.
2. Next, call IPyth.getUpdateFee(updateData) and send the fee you get back as msg.value to updatePriceFeeds(updateData).
3. Right after that, check getPriceNoOlderThan using your recency threshold.

Key Details:

• Hermes is now rolling out REST/SSE for the latest updates. The payload includes the Wormhole-attested Merkle root and inclusion proofs. You can find more about it here.
• The contract confirms guardian signatures using Wormhole, checks for Merkle inclusion, and then updates the on-chain price storage. If you want to dig deeper, check it out here.
• Keep in mind that fees are charged per update and can vary by chain. To get the specifics, take a look at the “Current Fees” table or programmatically check the getUpdateFee. Details are available here.

Example Solidity (simplified):

Here’s a simple Solidity example to help you get started:

pragma solidity ^0.8.0;

contract SimpleStorage {
    uint storedData;

    function set(uint x) public {
        storedData = x;
    }

    function get() public view returns (uint) {
        return storedData;
    }
}

Breakdown

• pragma solidity ^0.8.0;
  This line specifies the version of Solidity you want to use. In this case, it’s version 0.8.0 or higher.
• contract SimpleStorage
  Here, we’re defining a new contract called SimpleStorage.
• uint storedData;
  This declares a state variable called storedData, which stores an unsigned integer.
• function set(uint x) public
  The set function lets you set the value of storedData. It takes one argument, x.
• function get() public view returns (uint)
  This get function allows you to retrieve the current value of storedData.

How to Use It

1. Deploy the Contract:
   You'll need to deploy the contract on the Ethereum network (or a test network).
2. Set a Value:
   Call the set function to store a number. Just pass in the value you want to save.
3. Get the Value:
   Use the get function to retrieve the number you stored earlier.

And that’s it! Pretty straightforward, right? This is just a basic example to get you familiar with how things work in Solidity.

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

• To kick things off, use the Streams API to snag a signed report that includes NAV, AUM, reserves, and timestamps. Then, make sure to verify it on-chain through the Streams Verifier on your chosen network.
• Just a heads up, each on-chain verification will cost you $0.35, and there's a 10% extra fee if you're not using LINK. It’s a smart move to design your contract in a way that batches and caches reports to help spread out those verification costs. (docs.chain.link)
• Data Streams is specifically designed for fast-paced markets and offers modular fields like mid price, LWBA, and volatility, all while hitting a 99.9%+ uptime target. Plus, SmartData packages financial servicing metrics for your tokenized assets. (docs.chain.link)
• Lastly, don’t forget about the “Weekend Usage Disclaimer” for some tokenized asset streams; it's a good idea to implement a policy.failClosed during market holidays and weekends. (docs.chain.link)

Extra: On Sei, Streams has become the go-to for oracle infrastructure. Plus, with Chainlink’s partnership in commerce, we’re seeing Bureau of Economic Analysis data--like GDP and PCE--getting plugged into the blockchain. This is super handy for creating automated macro-linked coupons. Check it out here: (blog.sei.io)

C) Gas-minimal calldata delivery: RedStone packages

• Off-chain: grab the info from RedStone gateways (or Streamr), then bundle it up into a RedStone data package.
• On-chain: the contract pulls the attached payload from msg.data, checks ECDSA signatures against an allowlist, looks at the timestamp for freshness, and finally retrieves the values for the desired symbols. (github.com)

Why Teams Go for It

• There's no need for constant storage writes; values come along with the transaction.
• It’s got solid tooling for EVM, TON, and more, supporting over 1,300 assets along with both push and pull models. Check it out here: (npmjs.com)

D) Governance or compliance statements: UMA OOv3

• Go ahead and post a bonded assertion--something like, “Snapshot Proposal X passed with quorum Y.” If no one disputes it within your liveness window (which is usually 2 hours but can be adjusted), it gets finalized and can be used.
• If there is a dispute, that’s where the Data Verification Mechanism (DVM) steps in to settle things. For more serious assertions, it’s wise to set higher bonds and liveness times. UMA has some handy app patterns, like oSnap (Snapshot→Safe). Check it out here: (docs.uma.xyz)

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

• API owners can easily set up Airnode (which is serverless) and connect their API operations to on-chain endpoints using OIS. Then, dApps can either request data through RRP or read from dAPI feeds.
• Airseeker takes care of updating beacons and dAPIs based on deviation thresholds, and the OEV Network is there to help your protocol get back any oracle MEV from update auctions. You can dive deeper into it all on Airnode's documentation.

F) CCIP-Read for read-time retrieval

• For those heavy or rarely used tasks, you should set up an EIP‑3668 flow: revert with OffchainLookup(sender, urls, callData, callbackSel, extraData). Your client will grab the response from the specified URLs and then call back; your contract will need to verify the response signatures or inclusion proofs before moving forward. Check it out here: (eips.ethereum.org)

G) TLS-attested reports

• Check out DECO or TLSNotary to demonstrate a tuple like (issuer=api.example.com, path=/v1/nav, body_hash=H, time=T) while keeping the full payload under wraps. This is super handy for sensitive compliance data, such as custody reserve snapshots. (blog.chain.link)

H) ZK receipts for complex transforms

• Use RISC Zero zkVM to run parsers or handle multi-source reconciliation. Just submit your Groth16 proof along with the journal to your contract and verify it with the canonical verifier. This is perfect for when you need to cryptographically demonstrate how a metric was calculated. (dev.risczero.com)

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

• Verification fees: When it comes to Chainlink Streams, the verifier charges $0.35 per report. If you decide to pay with a token other than LINK, there's a 10% surcharge. It’s a good idea to budget for batching reports or caching those verified values to keep costs manageable. You can find more info here.
• Pyth pull update fees: These fees depend on the network. Most EVM chains will have pretty low fees quoted in their native tokens, like 0.01 SEI on Sei. Just make sure to run getUpdateFee to get the latest fee info. More details can be found here.
• Optimistic oracles: To keep things secure, set bonds that are higher than any potential gains from manipulation. The default liveness for Optimistic Oracles is around 2 hours, but if you’re dealing with something of high value, you might want to increase that timeframe. Check out the specifics here.
• Pull models: These models help avoid constant storage writes, and signature verification tends to eat up gas. To keep things efficient, consider using packed structs and pre-registered signer sets to cut down on overhead. RedStone has an on-chain parser that’s been tweaked with assembly to save on gas. You can see their setup here.

Security and compliance playbook (emerging best practices)

• Split up the verifier and consumer contracts. Keep the verifier nice and lightweight, make sure it's audited, and set it up to be upgradable through a slim proxy. Route any new schema versions through a registry.
• Rotate keys securely. Use EIP‑712 domain separation (think name, version, chainId, verifyingContract) along with on-chain allowlists that have clear validity windows. Check it out here: (eips.ethereum.org).
• Make sure you enforce policies in the VDP: set stalenessSec, notBefore/notAfter rules, and circuit-breakers. For market-linked RWAs, block updates on weekends and holidays, or make sure to include “market open” flags in the report. Chainlink Streams has you covered with market status updates and even a weekend usage disclaimer for some tokenized asset feeds. Take a look: (chain.link).
• Be ready for data-source outages. It’s a good idea to support multi-provider quorum (m-of-n) signatures or have a backup plan with an optimistic route (like UMA assertion) that allows for longer liveness windows.
• Reclaim oracle MEV. If your protocol is footing the bill for updates, think about using OEV-style flows to funnel that update value back into the app instead of letting external arbitrageurs scoop it up. Read more about it here: (medium.com).
• Observability is key: log schemaId, source set, proof type, fees paid, and latency measurements. Create a public status page; for reports that are signed, make sure to note the verifier contract address and version.

End-to-end example designs

1. Latency-Critical Perpetuals on a High-Throughput Chain

• Primary Source: We're using Chainlink Data Streams, which give us signed reports along with a verifier. This setup lets us grab the mark price and the Last Valid Block Announcement (LWBA) while caching the most recent verified report for N blocks.
• Secondary Source: We also pull updates from Pyth as a backup. We’ll only make trades if the price from either source is fresh and under X milliseconds. If things get dicey, we’ll set wider limits when we're falling back.
• Controls: If things start to feel stale or if the sources are off by more than δ%, we'll hit pause on trading. (chain.link)

Tokenized Fund with On-Chain NAV and Issuance Guards

• Primary: We've got a SmartData report that keeps you updated on NAV, AUM, and reserves. Plus, our minting and burning are protected by a “proof valid and within T seconds” mechanism.
• Secondary: For extra peace of mind, we use a TLS-attested NAV snapshot through DECO/TLSNotary to back things up periodically.
• Governance: If we hit a snag and both primary and TLS attestations fall short, we'll freeze the minting process and escalate an UMA assertion for emergency resolution. (chain.link)

3) Cross-chain Price Consumer on an EVM L2

• Start by pulling the updateData from Hermes via Pyth; don’t forget to pay the getUpdateFee.
• Use getPriceNoOlderThan for the asset pairs you're interested in.
• Cache the last good price and make sure to include some minimum confidence rules, since Pyth provides confidence intervals. Check it all out in the Pyth docs.

4) Enterprise API Integration (like logistics SLA)

• Set up a first-party Airnode by the enterprise to create an “SLA breach count” endpoint linked through OIS. The dApp can either read data from a dAPI or directly call RRP.
• If necessary, consider adding CCIP-Read to let clients pull proofs as needed, and don’t forget to include a signer set for those gateway responses. You can find more details here.

CCIP-Read callback structure (sketch)

• Step 1: The user makes a call using read(), and the contract responds by reverting with OffchainLookup(sender, urls, callData, callbackSel, extraData).
• Step 2: The client then grabs the response from the provided URLs using callData.
• Step 3: Finally, the client executes callback(response, extraData);, and the contract checks the signature/Merkle/zk receipt before sending back the data.

This setup helps dodge those pesky pre-publishing costs while still keeping everything verifiable. (eips.ethereum.org)

EAS for governance/compliance breadcrumbs

• Go ahead and register a schema for either “DataReport v1” or “ReserveAudit v1.” After that, make sure to publish the attestations that anchor the report hashes and signers on-chain.
• For those looking to dig into the details, consumers can use EAS Scan to query attestations and verify them against the events emitted by your verifier. Check it out here: (github.com)

Implementation checklist before mainnet

• Choose your model(s): go for a mix of push (dAPI), pull (Pyth/RedStone), signed reports (Streams), optimistic (UMA), TLS attested, and ZK. This way, you get some solid redundancy.
• Nail down your VDP schema and versioning. Make sure to pin those methodology docs to IPFS and include schemaId in each package.
• Time to build the verifier:
  • You’ll want to handle signature verification (EIP‑712 or raw ECDSA), Merkle proofs, and VAAs if you’re using Wormhole.
  • Don’t forget about replay protection (nonce/sequence + notBefore/notAfter).
  • Keep an eye on staleness checks and policy gates.
• Integrate fees and billing on a per-network basis:
  • Check the cost accounting for Chainlink Streams verifier and think about a batching strategy. (docs.chain.link)
  • Also monitor the Pyth getUpdateFee flow and fee table. (api-reference.pyth.network)
• Add some operational controls: circuit breakers, divergence checks across different sources, and make sure you can pause things if needed.
• For monitoring, emit structured events that include schemaId/source/quorum/fee/latency; set alerts for any stale data.
• When it comes to security, don’t skip an audit of the verifier; go ahead and fuzz test malformed packages; and run those failover fire drills.
• As for legal and compliance, especially for RWA or regulated data, keep your TLS attestation trails intact; and think about weekend/market-closed policies when necessary. (docs.chain.link)

Where the space is heading

• Broader low-latency coverage: Streams now covers equities/ETFs, FX, and commodities, delivering updates in under a second! Plus, there are new SmartData features for RWA servicing. Check it out here: (chain.link).
• On-demand pricing at scale: Pyth's pull model is really taking off, with hundreds of millions of updates rolling in each quarter, and they’re fine-tuning fees by chain. More details here: (messari.io).
• First-party dominance: A growing number of enterprises are running Airnodes to publish reliable data straight from the source. They’re getting support from OIS/RRP and OEV to make it happen. Learn more here: (airnode-docs.api3.org).
• Privacy-preserving attestations: DECO/TLSNotary is becoming a go-to for facts coming from Web2; it looks like enterprise-level RWAs will probably need this as well. More info is available here: (blog.chain.link).
• ZK coprocessors as a standard: With zkVM receipts, you’ll get both the data and the transformation bundled together, turning “verifiable analytics” into a core component of VDP. Dive into the details here: (dev.risczero.com).

---

When you're working on a new protocol or moving enterprise data on-chain, start by designing your verifiable data package (VDP). Once you've nailed that down, you can choose the delivery models that suit your needs regarding latency, cost, and control. With a clear VDP and a solid verifier in place, you’ll have the flexibility to connect to various sources like Pyth, Chainlink Streams/SmartData, RedStone, API3, UMA, Tellor, TLS attestations, or ZK coprocessors. This way, as your product grows, you can easily swap or combine these sources to keep everything running smoothly.