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

Summary: Choosing a “verifiable data” vendor now spans price oracles, identity credentials, cross‑chain messaging, and verifiable off‑chain analytics. This guide provides concrete, up‑to‑date evaluation criteria and examples to help you pressure‑test vendors on security, coverage, and SLAs—before they sit on your critical path.

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

Decision-makers at startups and enterprises need data that smart contracts and backend services can trust without trusting the vendor. In 2025, “verifiable data” covers at least four concrete categories:

Market and state data oracles (e.g., Chainlink, Pyth, RedStone, Switchboard, Chronicle). These deliver signed, auditable values to on-chain consumers with freshness and manipulation resistance. (docs.chain.link)
Cross-chain messaging and proofs (e.g., Chainlink CCIP with Risk Management Network; zk light‑clients from Lagrange/Succinct; EigenLayer‑secured AVSs like eOracle). (docs.chain.link)
Identity and attestations (e.g., W3C Verifiable Credentials 2.0, OpenID4VCI/4VP, SD‑JWT) underpinning KYC, gating, and B2B integrations. (w3.org)
Verifiable off‑chain compute/analytics (e.g., Space and Time “Proof of SQL”), plus verifiable web2 data via zk/TLSNotary. (github.com)

Below is a field‑tested evaluation framework you can apply across providers, with precise checks and thresholds your RFPs and architecture reviews can adopt immediately.

Pillar 1 — Security: how to verify the verifiers

Security is more than audits and marketing claims. Your vendor should prove integrity at three distinct layers: data generation, transport/aggregation, and on‑chain verification.

1. Data generation and aggregation

Ask vendors to demonstrate:

First‑party sources and publisher diversity. Example: Pyth aggregates from 120+ first‑party providers, publishes a price with a confidence interval, and supports 400ms updates for Core feeds. Require the source list and per‑feed publisher count. (docs.pyth.network)
Robust aggregation and outlier handling. Pyth documents how it aggregates publisher intervals; request the precise algorithm and parameters per instrument. (docs.pyth.network)
Update policy transparency. For threshold/heartbeat models (e.g., Chainlink Data Feeds), demand the actual per‑feed heartbeat and deviation thresholds you’ll rely on in risk logic—and monitor updatedAt. (docs.chain.link)
Optimistic vs. immediate finality. UMA’s Optimistic Oracle uses liveness windows and bonds; require the default liveness, minimum bond, and escalation policy you’ll enforce. (docs.uma.xyz)

Concrete buyer task

Put “per‑feed security sheet” in your contract: publishers (count, names), aggregation math, trigger rules (deviation %, heartbeat), and fallback logic. Vendors should fill this out per feed or credential.

2. Network and protocol assurances

Defense‑in‑depth for cross‑chain: Chainlink CCIP runs a separate Risk Management Network (distinct codebase and operators) that can pause on anomalies; require evidence of RMN coverage for your lanes and the pause governance flow. (blog.chain.link)
Restaked security: If a vendor leans on EigenLayer AVSs (e.g., eOracle, Lagrange, RedStone AVS), ask for slashing conditions, operator set size, and TVL snapshots at integration time. (theblock.co)
ZK light‑clients: Prefer proofs over multi‑sig bridges where possible (e.g., Lagrange State Committees, Succinct Telepathy). Capture proof formats and on‑chain verifiers in your threat model. (lagrange.dev)
TEEs and attestation: Some oracles support TEE‑attested compute (e.g., Switchboard Attestation Program). If used, require attestation report formats and verifier code. (docs.rs)

Concrete buyer task

Add a “Proof Preference” clause: ZK or light‑client proofs > TEE attestation > multi‑sig attestations, unless you explicitly accept higher trust assumptions for the use case.

3. On‑chain verification and consumer‑side protections

Staleness guards and confidence checks: Pyth exposes price confidence; Switchboard exposes confidence interval and staleness checks in‑contract. Your contracts should enforce max staleness and max confidence width. (docs.pyth.network)

Example (Solana, Switchboard):

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: Always verify latestRoundData().updatedAt meets your freshness SLO before using the answer. Set per‑market max age anchored to the feed heartbeat. (docs.chain.link)
Randomness consumption (VRF): Enforce requestId matching, sufficient block confirmations, and non‑reverting fulfillments; never allow cancel/re‑request logic that could “reroll” randomness. (docs.chain.link)
Proof of Reserves caveats: When PoR relies on self‑reported wallet lists, your risk register should reflect the issuer‑side risk of unauthenticated custody attribution (Chainlink’s wallet address manager disclaimer). (docs.chain.link)

4. Identity and attestations

Standards compliance: VC Data Model 2.0 is now a W3C Recommendation (May 15, 2025); check for JOSE/COSE security profiles and Bitstring Status Lists for revocation. (w3.org)
Protocols: OID4VCI 1.0 reached OpenID Final (Sept 2025). Verify wallet/issuer interoperability and conformance test results; track OpenID4VP finalization status. SD‑JWT is now RFC 9901 (Nov 2025). (openid.github.io)
Regulatory alignment: If you target EU users, ensure path to eIDAS 2.0/EUDI Wallet acceptance (member states must offer wallets by 2026 per the current timetable). (bundesdruckerei.de)

5. Verifiable web data and off‑chain analytics

zk/TLSNotary: For web2 sources (banks, exchanges), require TLSNotary‑style proofs or an equivalent zkTLS approach instead of screenshots or CSVs. Vendors should provide verifier code and disclosure controls. (tlsnotary.org)
ZK‑verified SQL: If you rely on analytics off‑chain, ask how results are proven (e.g., Space and Time “Proof of SQL” with on‑chain verifiers and GPU‑accelerated proof times). Review supported SQL features and verification costs. (github.com)

6. Org and supply‑chain security

Require SOC 2 Type II/ISO 27001 where feasible and software supply chain provenance (SLSA, Sigstore). Example: projects increasingly publish SLSA‑backed build provenance. (docs.zktx.io)
Crypto‑agility: Ask for a post‑quantum migration plan aligned to NIST FIPS 203/204/205 (ML‑KEM, ML‑DSA, SLH‑DSA) timelines. Contractually allow key upgrades and hybrid signatures. (nist.gov)

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

1. Chain and asset coverage you can audit

Chain reach: Pyth supports 100+ chains, with both push and pull modes; insist on the per‑chain list and which feeds are “sponsored push” vs. consumer‑pushed. (docs.pyth.network)
Data domains: If you need reserves, PoR feeds exist across assets and networks; clarify data sources, update cadence, and any self‑reporting in the pipeline. (chain.link)
Indexing & analytics: If you need broad historical coverage for research or BI, verify availability via BigQuery public datasets (Google Cloud now covers many chains and continues expanding), and whether the vendor can align to your OLAP tooling. (cloud.google.com)

2. Freshness and determinism

Update frequency: For latency‑sensitive markets, require target median/95p update latencies by instrument (e.g., Pyth Core publishes as fast as ~400ms; Chainlink feeds update on deviation/heartbeat). Map these to liquidation and pricing windows. (docs.pyth.network)
Historical determinism: If you liquidate or settle on historical prices, Pyth’s Hermes endpoints (e.g., updates by timestamp/interval) plus parsePriceFeedUpdates allow deterministic reconstruction—spec this in protocol logic. (docs.pyth.network)
Cross‑chain routes: For CCIP or any bridge‑delivered data, document the exact source/destination pairs, rate limits, anomaly‑detection/pausing behavior, and fallback paths. (blog.chain.link)

3. Retrieval modes and client libraries

Pull vs. push: Ask vendors how your app decides when to update on‑chain (pull) versus receiving sponsored pushes, and the costs under congestion. (docs.pyth.network)
SDK maturity: For Switchboard and Pyth, check the on‑chain methods for confidence, staleness, and historical buffers—and wire them in from day one. (docs.rs)

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

SLAs for verifiable data must go beyond generic uptime. Specify SLOs for freshness, correctness, incident response, and throughput—and wire enforcement into on‑chain guards.

1. Uptime vs. freshness

Uptime claims (e.g., node/RPC providers advertise 99.99%): Demand public status pages with per‑chain uptime and incident history (Infura publishes 90‑day breakdowns across chains and APIs). Tie credits to your material incidents. (status.infura.io)
Convert marketing numbers to downtime budgets you understand. For example, 99.9% ≈ 43.2 minutes/month; 99.99% ≈ 4.32 minutes/month. Use this to negotiate credits or auto‑termination clauses. (dotcom-monitor.com)
Freshness SLOs: Contract “answer age” targets per feed (e.g., 95% of updates under X seconds, 99% under Y)—then enforce checks on updatedAt/confidence in your contracts. (docs.chain.link)

2. Throughput and rate limits

Infura exposes credit‑per‑second/day limits by plan; QuickNode exposes configurable RPS/RPM/RPD via API. Ensure burst handling and backoff libraries in client code. (support.infura.io)
Alchemy documents batch and size limits—make these constraints explicit in load testing plans. (alchemy.com)

3. Incident response and change management

Ask for:

P1 response times (≤15–60 minutes) and MTTR targets; public incident comms (status page, RSS, Slack/webhooks), maintenance windows, and backfill policies for missed pushes. If PoR feeds pause, how are mint/burn circuit breakers triggered? (status.infura.io)
Versioning and deprecation policy for feed IDs, schemas, and endpoints (e.g., Pyth price IDs, Hermes versions). (docs.pyth.network)

4. Example SLA/SLO clauses you can reuse

Uptime: “99.99% monthly per chain endpoint; any 15‑min rolling window under 99% counts as incident for credits.”
Freshness (oracles): “BTC/USD on Chain X: 95p update latency ≤1s, 99p ≤2s; max staleness 10s; confidence ≤0.1% during normal volatility; otherwise fail‑closed.”
Incident response: “P1 within 15m; hourly updates until resolved; RCA within 5 business days.”
Rate limits: “Sustain 5k RPS bursts 60s; 1k RPS steady; 429s trigger exponential backoff as per SDK; vendor to offer per‑IP exemptions during incidents.”

Practical integration patterns (cut‑and‑paste ready)

A. Lending protocol with Chainlink primary, Pyth secondary

On read: If Chainlink feed’s updatedAt > maxAge or answer outside bounds, fetch Pyth Core via Hermes for the same timestamp, parsePriceFeedUpdates, and use lower‑confidence bound; otherwise pause borrows. (docs.chain.link)
On governance: Store per‑feed heartbeat/deviation in config; alert if live feed parameters drift from your baseline.

B. Derivatives with confidence‑aware pricing (Pyth)

Use aggregate price μ and confidence σ; for buy orders, price = μ + k·σ; for sell, price = μ − k·σ; choose k by backtests; enforce max σ/μ during stress. (docs.pyth.network)

C. Proof of Reserves as circuit breaker

Before minting wrapped assets, call PoR feed and assert reserves ≥ supply; if feed configuration is self‑reported, set tighter mint caps and off‑chain auditor hooks. (chain.link)

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

For CCIP lanes, configure RMN blessing requirement and automatic pause on anomalous flows; define your application‑level emergency “halt” that trips when RMN halts. (docs.chain.link)

E. zk/TLSNotary for web2 proofs

Replace manual KYC screenshot checks with TLSNotary attestations from the issuer’s domain; store verifier contract/code reference and require selective disclosure to minimize PII on-chain. (tlsnotary.org)

F. Verifiable analytics to contracts (Proof of SQL)

Run “Proof of SQL” queries that prove joins/aggregations over on‑/off‑chain tables; verify on‑chain with the vendor’s verifier and treat proof verification gas as part of transaction cost. (github.com)

Emerging best practices (Q4 2025)

Confidence‑first integration: Design your pricing logic around confidence intervals (Pyth, Switchboard) rather than raw point values; during volatile periods, widen spreads or switch to EMA variants for stability. (docs.pyth.network)
Restaked oracle defense: Evaluate AVS‑secured oracles (e.g., RedStone AVS) but capture real slashing rules and operator diversity—restaked TVL headlines alone aren’t security. (blog.redstone.finance)
ZK light‑clients on critical bridges: Prefer state‑proof‑based verification (e.g., Lagrange) for high‑value flows, or at least dual validation models. (lagrange.dev)
Standards‑based credentials: Target W3C VC 2.0 + OID4VCI/OID4VP + SD‑JWT to maximize interoperability and future eIDAS 2.0 alignment. (w3.org)
PQC readiness line item in RFPs: Require a migration plan referencing ML‑KEM/ML‑DSA/SLH‑DSA and key rotation playbooks. (nist.gov)

A vendor‑scoring checklist you can paste into your RFP

Score each item 0–2 (0 = not provided, 1 = partial, 2 = complete). Weight in parentheses.

Security (50%)

Feed transparency: publishers, aggregation math, trigger rules per feed (10). (docs.pyth.network)
Proof model: ZK/light‑client/TEE; slashing and operator set (10). (lagrange.dev)
Consumer guards: staleness/confidence checks implemented with code samples (8). (docs.rs)
PoR configuration and issuer risk disclosures (5). (docs.chain.link)
Identity standards conformance (VC 2.0, OID4VCI/4VP, SD‑JWT) (7). (w3.org)
Org security and crypto‑agility (SOC 2 Type II / ISO 27001 / SLSA / PQC plan) (10). (docs.zktx.io)

Coverage (25%)

Chains/assets list, push vs. pull modes, historical APIs (10). (docs.pyth.network)
Update frequency targets per market and determinism for historical settlement (10). (docs.pyth.network)
Alignment with your analytics stack (e.g., BigQuery datasets) (5). (cloud.google.com)

SLAs/SLOs (25%)

Uptime with public status and incident history (8). (status.infura.io)
Freshness SLOs (95p/99p) and on‑chain enforcement patterns (10). (docs.chain.link)
Rate‑limit transparency and burst handling (7). (support.infura.io)

What 7Block Labs recommends

Start with security patterns, not vendors. Hard‑code staleness/confidence checks and fail‑closed logic; you can swap vendors later without rewriting your risk controls. (docs.rs)
Prefer proofs over trust. Where available, use CCIP with RMN, ZK light‑clients, and PoR with cryptographically verifiable custody rather than self‑reported lists. (blog.chain.link)
Treat identity like infra. Standardize on VC 2.0 + OID4VCI/4VP + SD‑JWT across partners so you can plug new wallets/issuers without bespoke adapters—and stay eIDAS‑ready. (w3.org)
Bake in PQC agility now. New contracts should allow key upgrades and dual‑stack signatures to transition with NIST’s FIPS 203/204/205 ecosystem. (nist.gov)

If you want a 2‑week vendor bakeoff plan with test harnesses for freshness, failover, and cost under load (including prebuilt monitors for updatedAt/confidence and CCIP RMN events), reach out to 7Block Labs—we’ll bring the scripts and dashboards.

Appendix: handy snippets and references

Chainlink Data Feeds: check updatedAt/heartbeat before use. (docs.chain.link)
Pyth: 400ms updates, Hermes historical endpoints, parsePriceFeedUpdates for deterministic use. (docs.pyth.network)
Switchboard: check_staleness and check_confidence_interval in Solana programs. (docs.rs)
CCIP Risk Management Network: independent, heterogeneous implementation and pause‑on‑anomaly. (blog.chain.link)
Lagrange ZK light‑client (AVS): ZK state committees on EigenLayer. (lagrange.dev)
Proof of SQL: verifiable SQL queries with on‑chain verification options. (github.com)
VC 2.0 (W3C), OID4VCI Final, SD‑JWT RFC 9901, eIDAS 2.0 timeline. (w3.org)

Use this as your baseline to turn vendors’ claims into verifiable guarantees—before your protocol, product, or enterprise integration depends on them.