Summary: Picking a verifiable data vendor isn’t just like grabbing any old API off the shelf. When you make this choice, you’re investing in cryptographic assurances, operational guarantees, and how they’ll handle incidents. This guide provides decision-makers with a solid framework for evaluation, including checklists, metrics, and real-world examples. You’ll be able to weigh services and SLAs across areas like oracles, verifiable compute, data availability, cross-chain messaging, attestations/credentials, and indexing.

Verifiable Data Vendor Selection Guide: How to Evaluate Services and SLAs

Today’s decision-makers are swimming in a sea of options when it comes to “oracle-like” and “verifiable data.” We’re talking about everything from price feeds and verifiable compute to cross-chain messaging, data availability (DA), decentralized indexing, and attestations. The tricky part isn’t just finding a vendor; it’s figuring out which one aligns with your risk tolerance, latency requirements, coverage, and compliance needs. Plus, you’ve gotta negotiate an SLA that really safeguards your protocol and your users.

Here's a handy and current playbook you can start using right away.

---

1) What “verifiable” should mean in your contracts

Before diving into product comparisons, take a moment to figure out what “verifiable” means for you and your needs. Once you have that down, make sure to include it in your vendor questionnaires and Service Level Agreements (SLAs).

• Evidence: What kind of cryptographic proof do you have with the data? Is it a signature scheme, a Merkle/KZG commitment, zkSNARK, or maybe MPC attestation? And who's doing the verifying--an on-chain contract, off-chain verifier, or both? Pyth and Chainlink’s latest low-latency setups are “pull”-style and serve up signed updates that users can request whenever they need. Make sure to ask for the specific signature domain separation and verification path you’ll be using. (pyth.network)
• Provenance: If you're dealing with first-party oracles like API3, can you confirm the source identity via DNS-based Airnode verification? Also, can you check the aggregation set on-chain? It's a good idea to ask for a demonstration and scripts you can run yourself. (blog.api3.org)
• Independence: When it comes to "cross-chain" setups, how many independent networks are backing each lane, and what does the validator/client diversity look like? Chainlink CCIP has a great resource that lays out the principle of multiple independent networks per lane--definitely include this in your RFP language. (chain.link)
• Standards alignment: For identity and credentials, make sure to ask vendors how they align with the W3C Verifiable Credentials Data Model v2.0 test suites and DID Core. Don't just take their word for it when they say “we support VCs.” (w3.org)

---

2) Vendor landscape: what you’re really buying

• Price oracles and market data
  • There are two main architectures here: push and pull. You’ve got to consider things like price freshness, gas costs, who’s covering update expenses, and how cross-chain delivery works. Pyth uses a “pull” approach (thanks to Pythnet and Wormhole), while Chainlink Data Streams are quick, coming in at under a second, but they integrate in their own unique ways. On the other hand, RedStone has a cool signed “data-on-demand” model with an EVM connector. Check it out here: (docs.pyth.network)
• Cross‑chain messaging and token movement
  • CCIP is all about layered security and redundancy--it really helps to sidestep a single-network dependency in bridges. Make sure to pair this with your own research on bridge risks to stay ahead. Dive deeper into it here: (blog.chain.link)
• Proof of reserve and asset attestations
  • Live reserve feeds and smart contract circuit breakers are getting some love from ETF issuers and exchanges like 21Shares CETH and Coinbase cbBTC. This tech is giving us “verifiable data” for collateral. You can read more about it here: (theblock.co)
• Verifiable compute / zk coprocessors
  • There's a lot to consider between general-purpose zkVM PaaS solutions like RISC Zero Bonsai and specific use-case provers such as Space and Time Proof of SQL. You’ll want to keep an eye on things like proof latency, concurrency limits, and verification costs. Get the details here: (dev.risczero.com)
• Data availability (DA)
  • Take a look at EIP‑4844 blob space with its 18-day retention versus modular DA layers like Celestia, EigenDA, Avail, and NEAR DA. DA is shaping up to be a service market with various security and cost structures. Here’s more info: (eips.ethereum.org)
• Decentralized indexing/query
  • The Graph’s decentralized network (which includes Indexers, Curators, proof of indexing, and those nifty gateway/SLA knobs) is a game changer compared to a centralized API. Make sure you understand how curation signals work and the ins and outs of indexer selection. More on that here: (thegraph.com)
• Web2 data attestations
  • Check out TLSNotary (MPC‑TLS), which lets you create portable proofs of HTTPS responses with selective disclosure. It's a work in progress and has its own trade-offs in bandwidth and latency--so be sure to know the limits that apply to your SLA. Learn more here: (tlsnotary.org)

---

3) SLA levers that actually matter (per category)

When you’re thinking about your SLOs, make sure to include error budgets, alerts, and on-chain fail-safes. Here’s a list of key metrics we suggest you aim for and put into practice:

A) Price oracles (per feed, per chain)

• Freshness and drift
  • SLO: We’re aiming for a p95 “time-to-freshness” of ≤ 1 second for L2 perps and a p99 of ≤ 2 seconds. It’s also important to clearly state the maximum signed update interval during times of congestion. Both Data Streams and Pyth say they can publish updates in less than a second, but you’ll need some empirical dashboards for self-querying. Check it out here: (chain.link).
  • Deviation guardrails: It’s essential to have a worst-case deviation specification when things get volatile--think about the 99.9th percentile max tracking error compared to a reference exchange basket. Pyth has published some accuracy claims, so don’t hesitate to ask for asset-level error bands. More info here: (pyth.network).
• Delivery model
  • Pull cost model: We need to clarify who covers the cost per update, the granularity of fees, the exact signature domain, and how replay protections are set up. Pyth’s pull model charges per update, but it would be great to have access to fee tables and caps. Dive deeper here: (pyth.network).
• Chain coverage and finality handling
  • We should have a clear reorg policy, define the minimum confirmations, and map out the re-submission logic across different chains--especially for those speedy L2s.
• Resiliency
  • It's crucial to look at multi-provider aggregation (a mix of first-party and third-party sources), the size of the signer set, and the variety of data sources. We also need incident runbooks and a shadow-feed failover plan--like disabling trading if both feeds go stale for more than X seconds.

B) Cross‑chain messaging / token transfers

• Lane-level security
  • It’s crucial to have lane independence, which means separate validator sets for each lane. Also, an auxiliary risk-management network can come in handy (just like with CCIP). Make sure to check out the per-lane status endpoints, which you can find published by the CCIP Explorer, and look into proof-of-delivery semantics as well. If you want to dive deeper, check out this link.
• Liveness and ordering
  • Our Service Level Objective (SLO) aims for 95% of settlements to happen within X blocks on the destination side. We need clear replay and nonce rules, and let's not forget to establish bounded failure modes along with compensating controls to keep everything in check.

C) Proof of Reserve (PoR)

• Update cadence and sources
  • SLO: Make sure to reserve feed updates whenever there are significant changes within Y minutes. We need to pinpoint the custodians and exchanges, plus clarify how the oracle pulls that info (for instance, using the Coinbase feed for 21Shares CETH). It's essential to have on-chain circuit breakers in place that halt mints and redemptions if the data gets stale or if there's under-collateralization. (theblock.co)

D) Verifiable compute (zk)

• Proof Latency and Concurrency
  • SLO: Keep an eye on the median proof time for each workload class, the highest queueing delay, and set your per-tenant concurrency limits along with cycle budgets (check out the Bonsai documents for API limits; make sure to incorporate these into your capacity plan). (dev.risczero.com)
• Proof Verification Cost
  • It’s important to have on-chain verification gas benchmarks handy and explore batching options (like aggregation/recursion). Also, don’t forget to include a backup plan for off-chain verification with an optimistic challenge if on-chain costs start to creep up.

E) Data Availability (DA)

• Retention and Retrievability
  • So, here’s the deal: EIP-4844 blobs end up getting pruned after about 18 days. If you need to hang onto stuff for longer, you’ll want a solid retrieval plan in place (think archivers like Blockscout’s Blobscout). If you’re going with modular DA, don’t forget to outline availability sampling/NMT proof paths (Celestia), restaking assumptions/slashing (EigenDA), validator set size, roadmap (Avail), or even light-client verification (NEAR DA). Check out this link for more info: (info.etherscan.com).
• Throughput and Cost
  • When it comes to throughput, don’t just buy into the marketing hype--ask for the real numbers. You want to see the actual MB/s that real users are getting, and a good place to find that is on public dashboards like L2BEAT for EigenDA. Your Service Level Agreement (SLA) should clearly outline both peak and sustained posting SLOs, along with who’s responsible for covering costs if the target prices go overboard. For more details, check this out: (l2beat.com).

F) Decentralized indexing/query (The Graph)

• Indexer policy
  • Set a minimum number of Indexers that you need, decide on the fee structure you prefer, and make sure you have proof-of-indexing validation for allocations. If you want to get indexers onboard quicker in production, it's a good idea to curate your own subgraph (aim for at least 3,000 GRT). Check out more about this here.
• SLOs
  • Keep an eye on p95 query latency targets. It’s also important to manage re-sync times after any schema updates. Don’t forget about version pinning and the rules for auto-migration!

G) Web2 data attestations (TLSNotary)

• Trust model and limits
  • Check out what TLS versions are supported (we're sticking with TLS 1.2 for now), keep an eye on bandwidth overheads, explore selective disclosure tools, and figure out if a Notary service is part of the plan. Also, nail down which domains are acceptable and how you're going to verify attestations, whether that’s on-chain or off-chain. (tlsnotary.org)

---

4) Practical examples with current tech

Example 1: Selecting a price oracle for perpetuals on an L2

Scenario

So, you’re about to launch perpetual contracts on Arbitrum, and to make this a success, you'll need some lightning-fast prices and solid market coverage, especially in crypto and FX. Here's your game plan: you’ve narrowed it down to using Chainlink Data Streams and Pyth pull oracles as your top picks. And just to keep things cost-effective, you’re keeping RedStone in your back pocket as a secondary option.

What to Ask and Why

• Update Path and On-Chain Call Pattern: Set up a dry-run integration to check the p95 time from when an off-chain update happens to when you can read it on-chain, especially during those busy mempool times. Both Chainlink Data Streams and Pyth aim for sub-second updates, so make sure the vendor can show you how your symbol set performs at production scale. Check it out here: chain.link.
• Cross-Chain Delivery: If you’re working across different L2s and Solana, Pyth’s Pythnet and Wormhole delivery are important to consider. Make sure to confirm VAA validation and the availability of Hermes. More info can be found here: docs.pyth.network.
• Economic Model: Remember that fees will pile up with each update (Pythnet makes money through on-demand updates). It’s worth negotiating fee caps and burst allowances, especially when things get volatile. You can read more about it here: pyth.network.
• Incident Playbook: It's super important to set thresholds for what counts as a “stale-feed circuit breaker” and include automated halts. You should also require a shadow-price sanity check (like VWAP from exchanges) and a median-of-two setup with a fallback delay.

Bonus: When you settle exposure across different chains, you can include CCIP lane SLAs. This way, post-trade transfers won’t be your sole point of failure. Just keep an eye on the public lane status through your monitors. Check it out here: (ccip.chain.link)

Example 2: Verifiable compute for on‑chain NAV/risk metrics

Scenario

So, here’s the deal: You need to calculate your portfolio’s NAV (Net Asset Value) and some key risk metrics using off-chain data. Once you’ve got those figured out, you’ll want to commit a proof to the blockchain.

Options and Trade-offs

• Domain-specific: If you’re into table analytics and need things to move quickly, Space and Time’s Proof of SQL can give you sub-second proofs for your SQL aggregations. Just remember to check out the GPU requirements and the costs for the on-chain verifier. You can dive deeper here.
• General-purpose zkVM PaaS: RISC Zero Bonsai offers remote proving with clear API limits like concurrency and cycle budgets. Make sure you put together a solid capacity plan and have a backoff strategy in place in your SLA--think about options like paid burst pools for those critical month-end NAV reports. More info can be found here.
• SLA Hooks:
  • p95 proof time per workload class
  • On-chain verification gas ceiling per proof
  • Queueing/backpressure policy and credit allocation
  • Data custody and deletion (especially critical for client portfolios)

Example 3: DA selection for a high‑throughput rollup

Scenario

• Your app-chain is looking for consistent posting speeds of 4-8 MB/s, and you'll need to keep a record for 30 days.

Options

• EIP‑4844: This is the most budget-friendly native option, but keep in mind that blobs only stick around for about 18 days. If you need your data for longer--like 30 days--consider pairing it with an archival strategy, such as Blockscout Blobscout. Just make sure your Service Level Agreement (SLA) specifies who’s in charge of running the archive and the retrieval service level objectives (SLOs). Find more info here.
• EigenDA: This one offers restaking-secured data availability (DA) and comes with published usage stats (check it out on L2BEAT). Make sure to evaluate the current slashing posture and think through your censorship/failure plan. Once you have that sorted, negotiate both peak and sustained megabytes per second (MB/s) along with any penalties. More details can be found here.
• Celestia: With features like DA sampling and namespaced Merkle proofs, this option is worth considering. You’ll want to assess how well it integrates with light clients and compare the per-MB pricing versus throughput. Get the lowdown here.
• Avail: This is a chain-agnostic data availability solution that utilizes sampling and KZG. It’s a good idea to verify your validator set and ensure there's integration support across your tech stack. Dive deeper here.
• NEAR DA: This option offers affordable posting and light-client verification. Be sure to check how it fits into your OP/Arbitrum CDK integration path and what the retention model looks like. For more info, check it out here.

---

5) Compliance and security posture to verify (don’t assume)

• Independent certifications
  • If your stakeholders are looking for solid enterprise controls, it’s a good idea to ask for the scope and evidence. Chainlink Labs has made it clear that they cover ISO 27001 and SOC 2 Type 1 for Data Feeds (including PoR/NAV) and CCIP. Don’t hesitate to request those reports under NDA and see how they map to your controls. (chain.link)
• Audits and formal verification
  • When it comes to cross‑chain, definitely ask for code audits (think multi‑client), ongoing monitoring, and even some governance around kill-switches. Make sure to check their claims against security literature on bridge exploits to see if their mitigations really hold up against today’s attack vectors. (arxiv.org)
• Status transparency
  • Keep an eye on public status and lane dashboards (like CCIP Explorer) as part of your monitoring routine. It's smart to require webhooks or APIs in the SLA to stay updated. (ccip.chain.link)

---

6) Pricing models you’ll encounter (and what to negotiate)

• Pull oracle fees: Check out the volume/burst tiers and pricing for each asset. Make sure there’s a cap during market stress (like a specific max per block) and that there's “no double-charge” on transactions that get reverted. Pyth’s pull model is all about cashing in on every update. (pyth.network)
• zk proving: This one’s about per-proof plus compute cycles. You’ll want to reserve concurrency in your contract and set those “surge pricing” ceilings (just like what you see with Bonsai API quotas). (dev.risczero.com)
• Data Availability (DA): Think about per-byte or per MB posted. Take some time to audit how your rollup is really using blobs versus calldata and look into those retention/archival add-ons. Also, keep an eye on the practical limits for blobs (it's six blobs per block, around ~128 KB each). (eips.ethereum.org)
• Indexing: Get ready for per-query fees and curation costs (think GRT signal). Go ahead and publish your production subgraph, and don't forget to budget that initial 3,000+ GRT signal to attract better indexer engagement. (thegraph.com)
• Proof of Reserves (PoR): This one's straightforward: flat fee plus a per-asset charge. If the reserves data goes stale beyond the SLA, definitely ask for those incident-response credits.

---

7) RFP/RFI checklist you can copy-paste

Make sure to get every vendor to respond to these questions, along with any links or proof they can provide:

1. Evidence and verification

• What kind of cryptographic proof backs each piece of data? Also, where does the verification take place (like the contract address, verifier version, or curve/circuit)? Feel free to include any code snippets and test vectors. Check out the details here: (docs.pyth.network)

2) Delivery and Latency

• Check out the p50/p95/p99 update latency dashboards for each chain, symbol, and time of day over the past 90 days. We’ve also included the methodology behind these metrics. You can find all the details at chain.link.

3) Finality/Reorgs

• Let's check the minimum number of confirmations, how reorgs are managed, and what the process is for clients to get notified when values get updated.

4) Coverage and Diversity

• Provide details on data sources, weights, signer set size, and rotation policy. If you're using first-party oracles, be sure to confirm DNS-verified ownership of Airnode. Check this out for more info: blog.api3.org

5) Incident Response

• We've got a solid pager duty rota, status endpoints, and on-chain kill switches in place. Here are the three most recent postmortems, including those “near-miss” incidents:

6) Cross‑chain Security

• It’s all about creating a solid architecture for every lane, keeping an eye on how many independent networks we've got, ensuring we have a variety of clients, and actively managing risks. Don't forget to provide a lane status API! Check out more about this over at chain.link.

7) DA specifics

• Retention window: Think of it like an 18-day blob TTL, plus some archival options.
• Performance: Check out the MB/s peak and sustained guarantees to see what you can really rely on.
• Censorship resistance: Keep an eye on slashing statuses if you’re considering restaking.
• Telemetry links: Don’t forget to explore third-party telemetry options like L2BEAT for more insights.

1. Credentials/identity

• Check out the W3C VC v2.0 implementation along with the test-suite results, the DID methods it supports, and how it handles revocation and expiry models. You can dive into all the details here: (w3.org)

9) Verifiable Compute

• Keep an eye on quotas like concurrent proofs and cycle limits, plus latency SLOs and gas benchmarks for all your verification needs. Don’t forget to consider your failure/backoff policies too! Check it out here.

10) Compliance

• Share the certification scope (like ISO 27001, SOC 2 type), outline the services included (such as CCIP, Data Feeds), and detail the control mappings. Check it out here: chain.link

---

8) Emerging practices to adopt in 2025

• When it comes to high-frequency trading, it’s best to go for pull-based oracles. Make sure you have clear freshness service-level objectives (SLOs) and cap the per-update fees during any spikes. Pyth’s Perseus upgrade aims for a speedy 400ms cadence, while Chainlink Data Streams can deliver sub-second data--definitely check how both perform in your setup. (pyth.network)
• If you're thinking about cross-chain solutions, prioritize lane-level independence and real-time lane health checks. Stay clear of those multi-bridge “any-of” minting setups, as they can raise your attack surface. (chain.link)
• Treat Proof of Reserve (PoR) as a solid circuit breaker rather than just a fancy press release. It’s crucial to enforce on-chain rules when reserves go off track or feeds go stale--just look at how ETF/issuer integrations handle this. (theblock.co)
• Mix up your Data Availability (DA) choices: consider using EIP-4844 for your baseline posting and modular DA for those bursts of activity or extended audit periods. Don’t forget to include an archival service in your service-level agreement (SLA). (eips.ethereum.org)
• For minimizing trust in cross-chain scenarios, keep an eye on ZK light-client initiatives and proving platforms like Succinct SP1 and Wormhole ZK. If you’re depending on hosted proving, be sure to make quotas and latency top-tier SLOs. (docs.succinct.xyz)
• If you’re diving into Web2 provenance, give TLSNotary a spin with small payloads and make sure you’ve got your bandwidth and latency budgets nailed down. Stick to whitelisted domains, and clearly outline the roles of verifiers and oracles upfront. (tlsnotary.org)
• For identity and compliance, if your application involves credentials, it’s time to upgrade to the VC Data Model v2.0 (remember, this recommendation kicks in as of May 15, 2025). Also, make sure you ask for test-suite evidence during procurement. (w3.org)

---

9) Negotiating remedies that actually help

• Financial credits alone don't cut it. Let's connect SLA breaches to:
  • Quick access to raw signed updates (bypass endpoints) when incidents happen.
  • Temporary fee breaks or capacity boosts (for proving/DA) while we're in recovery mode.
  • On-chain configuration tweaks (like tightening collateral factors or pausing mints) that kick in automatically if SLOs aren’t met--vendors need to provide reference contracts for these hooks.

---

10) Minimal incident playbook template (copy)

• Detection: Tune into vendor webhooks and keep an eye on your own shadow monitors (think CCIP lane status, price freshness, and DA post success).
• Classification: Figure out whether it's stale data, bad data, or a delivery failure--this helps you pick the right fix.
• Actions:
  • Oracles: If data is stale for more than N seconds, switch to read-only mode; if one feed starts drifting over X bps, medianize it; bump up the initial margin until the drift falls below the threshold.
  • Cross‑chain: If you hit a red lane status, freeze the bridge route; hold onto any inbound mints until things turn green for M blocks. (ccip.chain.link)
  • DA: If the primary misses its p95 posting SLO for K minutes, redirect to a secondary DA; also, make sure the archival service is current.
• Comms: Share the root cause and how you're handling things; don't forget to set up a Blameless Postmortem with the vendor.

---

11) One-page comparison crib notes (grounded in current info)

• Chainlink
  • Products: They've got some cool stuff like Data Streams (pull), Proof of Reserve, and CCIP (lane-based, defense-in-depth). Plus, there’s a public lane status explorer, and they’re ISO 27001 + SOC 2 Type 1 certified. Ideal for institutions and those high-throughput DeFi projects. Check it out here.
• Pyth
  • Offering a pull-oracle through Pythnet + Wormhole, Pyth delivers updates in a flash--sometimes as low as ~400ms with Perseus. It has a solid cross-chain presence, making it a great fit for perps/options that need fast refresh rates and on-demand economics. Learn more here.
• RedStone
  • This one's a modular, data-on-demand EVM connector that's also looking into restaking for extra security. It's perfect for those cost-effective feeds and custom assets. Find out more here.
• Space and Time (Proof of SQL)
  • They focus on domain-specific proofs for SQL analytics, with super speedy sub-second claims for large data aggregations. If you’re into data-driven DeFi, this is definitely worth a look. Explore more here.
• RISC Zero Bonsai
  • This is a hosted zkVM that comes with quotas and a remote proving API. It's well-suited for general zk workloads, ensuring you have the capacity you need. Check their site here.
• DA options
  • You’ve got 4844 blobs that hang around for about 18 days, with six blobs per block. Options include Celestia (DAS/NMT), EigenDA (restaked DA with dashboards for throughput), Avail (sampling + KZG), and NEAR DA (affordable posting + light client). The best fit really depends on what you need in terms of retention, throughput, and trust model. Get the details here.
• The Graph
  • Think decentralized indexing with Indexers/Curators, POI, and query/SLA options. You can even curate your own subgraphs for a more predictable service. See how it works here.
• TLSNotary
  • They've got browser/native MPC-TLS proofs for Web2 data, allowing you to set up bandwidth/latency and domain constraints in your SLA. Check it out here.

---

12) Final quick-start: 30‑day evaluation plan

• Week 1: Let’s narrow it down to 2-3 vendors in each category. We’ll need to ask for their dashboards and some signed sample payloads. Also, we need to make sure everything checks out with the standards (like VC v2.0 tests and DID methods). You can find more about that here.
• Week 2: Time to bench in staging:
  • Oracles: We’ll measure freshness and drift under stress by simulating 2× market volatility scenarios.
  • Cross‑chain: Let’s create a lane failure scenario to verify alarms and ensure everything halts as it should. More info on that can be found here.
  • DA: We need to sustain MB/s for one hour and run tests for archiving and replay. Check out the details here.
  • ZK: We’ll measure proof time and variance, as well as the on-chain verification gas. Details can be found here.
• Week 3: We should start SLAs negotiations, making sure we have clear SLO tables, remedies, and on-chain hooks for those fail-safe actions.
• Week 4: Let’s run some game day drills (think oracle drift, lane down, DA congestion, and proving backlog) and finalize everything with signatures.

---

If you stick to this playbook--tying your choices to measurable cryptographic features, actual production data, and enforceable service level objectives (SLOs)--you’ll find vendors who offer guarantees that align with the scope of your protocol, not just what you can afford.

References for this guide come from the latest vendor documentation and some solid independent milestones. This way, your procurement language is in tune with how these systems actually function today. Here’s what to check out:

• Pyth pull architecture and cross-chain delivery
• Chainlink Data Streams and CCIP lane status
• Modern bridge risks
• PoR integrations (21Shares, Coinbase)
• 4844 blob details and retention
• Celestia DAS/NMT
• EigenDA status and risk analysis
• NEAR DA architecture
• The Graph Indexer/POI design
• TLSNotary docs and limitations
• W3C DID Core and VC v2.0 (Recommendation as of May 15, 2025)

For more details, visit: pyth.network

7Block Labs is here to help you with your evaluation, set up benchmarks, and transform those results into solid contracts that really count.