Verifiable Data Vendor: Evaluation Criteria for Security, Coverage, and SLAs

Summary: When it comes to picking a “verifiable data” vendor, you're looking at a range of options including price oracles, identity credentials, cross‑chain messaging, and verifiable off‑chain analytics. This guide breaks down current evaluation criteria and gives you real examples to help you put vendors through their paces on security, coverage, and SLAs--ensuring they’re reliable before they become crucial to your operation.

---

Who this is for (and what “verifiable data” really means in 2025)

Decision-makers at both startups and big companies need data they can rely on from smart contracts and backend services, all without having to put their trust in the vendor. By 2025, we’ll see “verifiable data” fall into at least four clear categories:

• Market and state data oracles, like Chainlink, Pyth, RedStone, Switchboard, and Chronicle, are a big deal. They provide signed and auditable values to on-chain users, ensuring the data is fresh and tough to tamper with. Check it out here: (docs.chain.link).
• When it comes to cross-chain messaging and proofs, think about tools like Chainlink's CCIP, working alongside the Risk Management Network, or zk light‑clients from Lagrange/Succinct. There are also EigenLayer-secured AVSs like eOracle to consider. Dive into the details: (docs.chain.link).
• On the identity front and attestations, we have W3C Verifiable Credentials 2.0, along with OpenID4VCI/4VP and SD‑JWT, which are essential for KYC, gating, and B2B connections. More info can be found here: (w3.org).
• Lastly, verifiable off‑chain compute and analytics are gaining traction, like Space and Time’s “Proof of SQL.” Plus, you can validate web2 data with zk/TLSNotary. Check it out on GitHub: (github.com).

Here’s a handy evaluation framework that’s been tested in the field, which you can use with different providers. It includes specific checks and thresholds that you can easily incorporate into your RFPs and architecture reviews right away.

---

Pillar 1 -- Security: how to verify the verifiers

Security goes beyond just audits and flashy marketing claims. Your vendor needs to demonstrate integrity at three key levels: data generation, transport/aggregation, and on-chain verification.

1. Data generation and aggregation

Ask Vendors to Demonstrate:

• It's always a good idea to see products in action. Request vendors to give you a hands-on demo.
• This will help you get a feel for how the product works and whether it suits your needs.
• You might also want to ask them to showcase real-world examples of how their product has made a difference for other customers.
• Don't hesitate to ask questions while they demonstrate--this is your chance to clarify any doubts.
• Keep an eye on the user interface and functionality during the demo; it could save you from potential headaches down the line!
• First-party sources and publisher diversity. Take Pyth, for instance -- they pull data from over 120 first-party providers, giving you a price with a confidence interval and quick updates every 400ms for their Core feeds. Make sure to ask for their source list and the number of publishers for each feed. (docs.pyth.network)
• Robust aggregation and outlier handling. Pyth explains how they put together publisher intervals. If you're curious, go ahead and request their exact algorithm and parameters for each instrument. (docs.pyth.network)
• Update policy transparency. If you're dealing with threshold or heartbeat models (like Chainlink Data Feeds), you'll want to know the actual per-feed heartbeat and deviation thresholds that are crucial for your risk logic--and don’t forget to keep an eye on updatedAt. (docs.chain.link)
• Optimistic vs. immediate finality. For instance, UMA’s Optimistic Oracle is built on liveness windows and bonds. Make sure to nail down the default liveness, minimum bond, and the escalation policy you plan to enforce. (docs.uma.xyz)

Concrete Buyer Task

• Make sure to include a “per-feed security sheet” in your contract. This should cover details like publishers (count and names), the aggregation math, trigger rules (like deviation percentage and heartbeat), and fallback logic. Remember, vendors need to fill this out for each feed or credential they provide.

2. Network and protocol assurances

• Defense-in-depth for cross-chain: Chainlink's CCIP operates a separate Risk Management Network (distinct codebase and operators) that can hit pause when something seems off. Make sure you have evidence of RMN coverage for your lanes and the pause governance flow. Check it out here.
• Restaked security: If your vendor is using EigenLayer AVSs (like eOracle, Lagrange, or RedStone AVS), don’t forget to ask them about slashing conditions, the size of their operator set, and snapshots of Total Value Locked (TVL) at the time of integration. More details can be found here.
• ZK light-clients: Whenever possible, opt for proofs instead of multi-sig bridges (think Lagrange State Committees or Succinct Telepathy). Make sure to include proof formats and on-chain verifiers in your threat model. You can learn more here.
• TEEs and attestation: Some oracles are all about that TEE-attested compute (like the Switchboard Attestation Program). If you’re going this route, make sure to ask for the formats of the attestation reports and the verifier code. Check the details here.

Concrete Buyer Task

• Include a “Proof Preference” clause that outlines the following order: ZK or light-client proofs take priority over TEE attestation, which in turn is preferred over multi-sig attestations. This is unless you specifically agree to higher trust assumptions for your particular use case.

3. On‑chain verification and consumer‑side protections

• Staleness Guards and Confidence Checks: Pyth shows off its price confidence, while Switchboard offers insights like confidence intervals and staleness checks right in the contract. It's super important for your contracts to set limits on both max staleness and max confidence width. Check out more details in the Pyth documentation!

Example (Solana, Switchboard):

If you're diving into the Solana ecosystem, you might want to check out Switchboard. It's a pretty innovative solution for bringing off-chain data to smart contracts. Here’s how it works:

• Data Oracles: Switchboard acts as a decentralized oracle network, pulling in real-world data for smart contracts. This means your contracts can react to actual events happening outside of the blockchain.
• User-Friendly: One of the cool things about Switchboard is how straightforward it is to use. Developers can easily set up their own oracles without needing to dig too deep into complex code.
• Community Driven: It's built by a community of developers who are all about making the crypto space more accessible. The more people get involved, the better the network gets!

For more details about how it operates and how you can get involved, check out Switchboard’s official site.

let feed = AggregatorAccountData::new(feed_account_info)?;
feed.check_staleness(clock::Clock::get()?.unix_timestamp, 300)?;
feed.check_confidence_interval(SwitchboardDecimal::from_f64(0.80))?;

(docs.rs)

• Chainlink feed hygiene: Make sure to check that latestRoundData().updatedAt aligns with your freshness SLO before relying on the answer. It’s a good idea to set a maximum age for each market that’s based on the feed heartbeat. (docs.chain.link)
• Randomness consumption (VRF): Make sure you're matching the requestId, securing enough block confirmations, and ensuring fulfillments don't revert. Avoid any cancel or re-request logic that could lead to "rerolling" randomness. Check out more details in the docs.chain.link.
• Proof of Reserves caveats: If you're looking at PoR that depends on wallet lists provided by the issuer, make sure your risk register notes the potential risks of unauthenticated custody attribution. Check out Chainlink’s wallet address manager disclaimer for more details. (docs.chain.link)

4. Identity and attestations

• Standards compliance: The VC Data Model 2.0 has officially become a W3C Recommendation as of May 15, 2025! Be sure to check out the JOSE/COSE security profiles and keep an eye on the Bitstring Status Lists for any revocations. (w3.org)
• Protocols: Great news! OID4VCI 1.0 has hit OpenID Final as of September 2025. Make sure to verify the interoperability between wallets and issuers and keep tabs on the conformance test results. Also, check the status of OpenID4VP finalization. On another note, SD‑JWT has officially been made RFC 9901 as of November 2025. (openid.github.io)
• Regulatory alignment: If your audience includes EU users, it’s crucial to ensure you’re on track with eIDAS 2.0/EUDI Wallet acceptance. Remember, member states need to roll out wallets by 2026 according to the current schedule. (bundesdruckerei.de)

5. Verifiable web data and off‑chain analytics

• zk/TLSNotary: When it comes to web2 sources like banks and exchanges, it’s best to ask for proofs using TLSNotary-style methods or something similar to zkTLS, instead of just getting screenshots or CSV files. Make sure the vendors share their verifier code and have solid disclosure controls in place. Check it out here: (tlsnotary.org)
• ZK‑verified SQL: If you're depending on off-chain analytics, don't hesitate to inquire about how those results are actually verified. For instance, look into Space and Time's “Proof of SQL,” which uses on-chain verifiers and boasts GPU-accelerated proof times. Plus, it’s a good idea to review what SQL features they support and what the verification costs will be. Dive deeper here: (github.com)

6. Org and supply‑chain security

• Make sure to ask for SOC 2 Type II or ISO 27001 if it makes sense for your project, and keep an eye on software supply chain provenance (like SLSA and Sigstore). For example, more and more projects are publishing build provenance backed by SLSA. You can find out more here.
• Crypto-agility is a big deal! So, be sure to request a post-quantum migration plan that aligns with NIST FIPS 203/204/205 timelines (think ML-KEM, ML-DSA, SLH-DSA). It’s a good idea to allow for key upgrades and hybrid signatures in your contracts. Check out the details here.

---

Pillar 2 -- Coverage: chains, assets, freshness, and retrieval

1. Chain and asset coverage you can audit

• Chain reach: Pyth is pretty cool because it supports over 100 chains and offers both push and pull modes. Be sure to check out the per-chain list to see which feeds are “sponsored push” and which ones are pushed by the consumer. You can find more details here.
• Data domains: If you're on the lookout for reserves, PoR feeds are available across different assets and networks. Just make sure to clarify where the data is coming from, how often it updates, and if there’s any self-reporting planned. For more info, check out this link: chain.link.
• Indexing & analytics: If you need extensive historical data for research or business intelligence, double-check the available data through BigQuery's public datasets. Google Cloud has been covering more chains and is always adding more! Also, see if the vendor can integrate with your OLAP tools. You can dive deeper into this topic here.

2. Freshness and determinism

• Update frequency: In latency-sensitive markets, it’s super important to know the target median and 95th percentile update latencies for each instrument. For example, Pyth Core can update in as fast as around 400ms, while Chainlink feeds operate based on deviations or set heartbeats. Be sure to link these to your liquidation and pricing windows. You can check out more details here.
• Historical determinism: If your process involves liquidating or settling with historical prices, you’ll want to use Pyth’s Hermes endpoints. They let you get updates by timestamp or intervals, and with the parsePriceFeedUpdates, you can ensure a deterministic reconstruction. Just make sure to specify this in your protocol logic. More info can be found here.
• Cross-chain routes: When you’re working with CCIP or any data delivered through bridges, it’s crucial to document the specific source and destination pairs. Don’t forget to include details on rate limits, how you’ll detect anomalies or pause operations, and any fallback paths. For in-depth insights, check out this blog post.

3. Retrieval modes and client libraries

• Pull vs. Push: Dive into how your app figures out when to update on-chain (that's the pulling part) versus when it gets sponsored pushes. Plus, don't forget to ask about the costs during busy times. You can find more details here.
• SDK Maturity: For both Switchboard and Pyth, it’s a good idea to take a look at the on-chain methods for tracking confidence, staleness, and historical buffers. Make sure to set these up from the get-go. Check out the specifics here.

---

Pillar 3 -- SLAs, SLOs, and what to hard‑code in contracts

SLAs for verifiable data need to be more than just the usual uptime metrics. It's important to lay out some clear SLOs that cover things like freshness, correctness, incident response, and throughput. Plus, you should make sure to enforce these standards with on-chain guards.

1. Uptime vs. freshness

• Uptime Claims: When node/RPC providers brag about 99.99% uptime, make sure they back it up with public status pages that show uptime and incident history for each chain. For instance, Infura provides a handy 90-day breakdown across their chains and APIs. And don’t forget to tie credits to any major hiccups you might experience. Check it out here: (status.infura.io).
• Downtime Budgets: It’s super important to translate those marketing percentages into downtime budgets that actually make sense to you. For example, if you see 99.9%, that breaks down to about 43.2 minutes of downtime each month, while 99.99% means just 4.32 minutes a month. Use this info to help you negotiate better credits or even auto-termination clauses if things don’t go as planned. More details can be found here: (dotcom-monitor.com).
• Freshness SLOs: Get specific about your “answer age” targets for each feed in your contract--like aiming for 95% of updates to come in under X seconds and 99% under Y seconds. Then, make sure to enforce checks on updatedAt/confidence levels right in your contracts. You can find additional guidance here: (docs.chain.link).

2. Throughput and rate limits

• Infura has some credit limits that vary by plan, showing how many requests you can make per second or day. On the flip side, QuickNode lets you tweak the Requests Per Second (RPS), Requests Per Minute (RPM), and Requests Per Day (RPD) through their API. Don’t forget to implement burst handling and backoff libraries in your client code to manage any spikes! (support.infura.io)
• Alchemy provides details on batch and size limits, so make sure you include these factors when you're creating your load testing plans. It’s super important to keep everything clear! (alchemy.com)

3. Incident response and change management

I'm sorry, but it seems like your request is incomplete. Could you please provide the text or content you'd like me to rewrite?

• We’ve got some guidelines for response times--aiming for those P1 responses to be under 15 to 60 minutes--and we’ve set some targets for MTTR as well. Plus, we keep our public incident communications up to date through a status page, RSS feeds, and Slack/webhooks. Don't forget about our maintenance windows and how we handle backfill policies if any pushes are missed. And in case our PoR feeds hit pause, we’ve got a plan for triggering mint/burn circuit breakers. Check it out here: (status.infura.io)
• We also have a clear versioning and deprecation policy for feed IDs, schemas, and endpoints--like Pyth price IDs and Hermes versions. You can dive into the details here: (docs.pyth.network)

4. Example SLA/SLO clauses you can reuse

• Uptime: “We aim for 99.99% uptime every month per chain endpoint. If there's a 15-minute rolling window that dips below 99%, it counts as an incident for credits.”
• Freshness (oracles): “For BTC/USD on Chain X, we’re looking at a 95th percentile update latency of ≤1s, and 99th percentile of ≤2s. The max staleness is 10 seconds, and we keep confidence levels ≤0.1% during typical market volatility; otherwise, we'll fail-closed.”
• Incident response: “For P1 incidents, we promise to respond within 15 minutes. You’ll get hourly updates until everything’s resolved, and we’ll provide a root cause analysis within 5 business days.”
• Rate limits: “We can handle bursts of up to 5k requests per second for 60 seconds, and a steady rate of 1k requests per second. If we hit a 429 status, we’ll trigger an exponential backoff as outlined in our SDK, and we’ll offer per-IP exemptions during incidents.”

---

Practical integration patterns (cut‑and‑paste ready)

A. Lending protocol with Chainlink primary, Pyth secondary

• When reading the data: If the Chainlink feed's updatedAt is greater than maxAge or if the answer is outside the acceptable bounds, make sure to fetch the Pyth Core data via Hermes for that same timestamp. Then, run parsePriceFeedUpdates and use the lower-confidence bound. If not, just pause any borrows. (docs.chain.link)
• On the governance side: Keep a record of each feed’s heartbeat and deviation in the configuration. Make sure to set up alerts if the live feed parameters start drifting away from your baseline.

B. Derivatives with confidence‑aware pricing (Pyth)

• For placing your buy orders, you’ll want to use the aggregate price μ and the confidence σ. The formula goes like this: price = μ + k·σ. On the flip side, for sell orders, it’s price = μ − k·σ. Don’t forget to pick your k based on some backtesting! And remember, it’s a good idea to keep an eye on your max σ/μ during stressful times. (docs.pyth.network)

C. Proof of Reserves as circuit breaker

• Before you jump into minting wrapped assets, make sure to check the PoR feed and confirm that reserves are greater than or equal to the supply. If the feed is self-reported, it's a good idea to enforce stricter minting caps and include off-chain auditor hooks for extra security. (chain.link)

D. Cross‑chain messages with pause‑on‑anomaly

• When setting up CCIP lanes, make sure to configure the RMN blessing requirement and set up automatic pauses for any unusual flows. Also, outline your app's emergency "halt" that activates when RMN comes to a stop. Check out the details here: (docs.chain.link).

E. zk/TLSNotary for web2 proofs

• Swap out those tedious manual KYC screenshot checks for TLSNotary attestations straight from the issuer's domain. Make sure to keep a reference to the verifier contract/code and ask for selective disclosure to keep that PII on-chain to a minimum. (tlsnotary.org)

F. Verifiable analytics to contracts (Proof of SQL)

• Execute “Proof of SQL” queries to demonstrate joins and aggregations between on-chain and off-chain tables. Make sure to verify the on-chain data using the vendor’s verifier, and don’t forget to factor in the proof verification gas as part of the overall transaction cost. (github.com)

---

Emerging best practices (Q4 2025)

• Confidence-first integration: When designing your pricing logic, think about using confidence intervals (like Pyth or Switchboard) instead of just raw point values. During those shaky market times, consider widening your spreads or switching to EMA variants to keep things stable. You can check out more tips here.
• Restaked oracle defense: Take a good look at AVS-secured oracles (like RedStone AVS), but don’t just focus on their restaked TVL figures--make sure to understand their slashing rules and ensure there's a diversity of operators for solid security. More insights can be found here.
• ZK light-clients on critical bridges: For those big money flows, it’s smarter to go with state-proof-based verification methods (like Lagrange) or at least dual validation models to keep everything secure. Dive into the details here.
• Standards-based credentials: Aim for W3C VC 2.0 along with OID4VCI/OID4VP and SD-JWT to ensure you’re all set for maximum interoperability and future compliance with eIDAS 2.0. You can learn more about it here.
• PQC readiness line item in RFPs: Make sure to ask for a migration plan in your RFPs that includes references to ML-KEM, ML-DSA, SLH-DSA, and key rotation playbooks. For the latest on this, check out the info here.

---

A vendor‑scoring checklist you can paste into your RFP

Score each item on a scale from 0 to 2 (where 0 means not provided, 1 is partial, and 2 is complete). Don't forget to consider the weight indicated in parentheses.

Security (50%)

• Feed Transparency: We’re all about clear communication here. That means understanding our publishers, the math behind our aggregations, and the trigger rules for each feed. (10 points) Check it out here.
• Proof Model: Think of it as the backbone of our system. We're using ZK, light-client, and TEE setups, along with slashing and a solid operator set to keep things running smoothly. (10 points) Learn more.
• Consumer Guards: We’ve got your back with checks for staleness and confidence, and we even throw in some handy code samples to illustrate how it’s done. (8 points) Dive into the details.
• PoR Configuration and Issuer Risk Disclosures: This is all about transparency when it comes to configuration and any risks tied to our issuers. (5 points) Find out more here.
• Identity Standards Conformance: We're sticking to the latest standards, including VC 2.0 and OID4VCI/4VP, along with SD-JWT. It’s essential for maintaining trust and security. (7 points) Get the scoop.
• Org Security and Crypto-Agility: Keeping our organization secure is a top priority. We’re adhering to SOC 2 Type II, ISO 27001, SLSA, and have a plan for PQC to ensure we're ready for anything. (10 points) Explore more about our practices.

Coverage (25%)

• Check out the list of chains and assets, plus get the scoop on push vs. pull modes and historical APIs (10). (docs.pyth.network)
• Take a look at the update frequency targets for each market and how they ensure determinism for historical settlement (10). (docs.pyth.network)
• Make sure it lines up with your analytics setup, like BigQuery datasets (5). (cloud.google.com)

SLAs/SLOs (25%)

• Uptime details along with public status and incident history (8). You can check it out here: (status.infura.io).
• Freshness SLOs (95p/99p) and the patterns for on-chain enforcement (10). More info can be found at (docs.chain.link).
• Transparency around rate limits and how burst handling works (7). For more details, head over to (support.infura.io).

---

What 7Block Labs recommends

• Start with security patterns, not vendors. Focus on hard-coding those staleness and confidence checks, along with fail-closed logic. This way, if you need to change vendors later, you won't have to redo your risk controls. Check it out here: (docs.rs)
• Prefer proofs over trust. Whenever you can, lean on CCIP with RMN, ZK light-clients, and PoR with cryptographically verifiable custody instead of relying on self-reported lists. You’ll find more info here: (blog.chain.link)
• Treat identity like infrastructure. Get on board with VC 2.0 + OID4VCI/4VP + SD-JWT across your partners. This makes it super easy to plug in new wallets and issuers without having to build custom adapters--plus, you’ll be all set for eIDAS compliance. More details can be found here: (w3.org)
• Bake in PQC agility now. Make sure your new contracts are designed for key upgrades and dual-stack signatures so you can easily adapt to NIST's FIPS 203/204/205 ecosystem when the time comes. Take a look at what's new here: (nist.gov)

If you're looking for a solid 2-week vendor bakeoff plan that includes test harnesses for freshness, failover, and cost under load (plus prebuilt monitors for updatedAt/confidence and CCIP RMN events), just hit up 7Block Labs. We’ve got you covered with all the scripts and dashboards you need!

---

Appendix: handy snippets and references

• Chainlink Data Feeds: Before diving in, make sure to check updatedAt and heartbeat. You can find all the info you need here.
• Pyth: They update every 400ms, plus you’ll want to check out the Hermes historical endpoints. Don’t forget to use parsePriceFeedUpdates for a more predictable experience. More details are available here.
• Switchboard: When working with Solana programs, definitely look into check_staleness and check_confidence_interval. You can read up on it here.
• CCIP Risk Management Network: This one’s got an independent and diverse setup, plus it can pause on anomalies. Check out the full scoop here.
• Lagrange ZK light-client (AVS): Featuring ZK state committees on EigenLayer. If you're curious, you can read all about it here.
• Proof of SQL: This is all about verifiable SQL queries, complete with options for on-chain verification. You can see more here.
• VC 2.0 (W3C): Keep an eye on OID4VCI Final, SD-JWT RFC 9901, and the eIDAS 2.0 timeline. All the important updates are available here.

Use this as your starting point to transform vendors’ claims into solid guarantees--before your protocol, product, or enterprise integration relies on them.