Data Disclaimer

Metera does not guarantee that data delivered through the Service is accurate.

What Metera guarantees is narrower and different: we do not overstate what we know. Every response carries a verification level describing the checks that were actually performed and passed. A response labelled as unverified is not a failure of the Service — it is the Service telling you the truth about the limits of what it could confirm.

You are responsible for deciding whether a given verification level is sufficient for your purpose, and for configuring minimum verification levels accordingly.

Metera does not produce data. All data delivered through the Service originates from third-party sources: public APIs, commercial data providers, scraping services, blockchain nodes, and sources listed by independent providers.

We route requests to these sources, verify their responses to the extent possible, label the result, and deliver it. We have no control over the underlying data, and a source may be inaccurate, incomplete, outdated, biased, or unavailable at any time.

Every delivered response carries one of the following levels. The level describes the strongest form of verification that the response actually passed.

anchored

The response was compared against an independent authoritative reference — typically an on-chain oracle or blockchain state — and was consistent with it.

What this does not mean. The reference itself may be wrong, delayed, or manipulated. Consistency is assessed within a tolerance and at a point in time. Data can change between verification and your use of it.

consensus

The response was compared against responses from other sources that our measurements indicate are independent of one another, and agreed with them within tolerance.

What this does not mean. Independent sources can be wrong in the same way, particularly where they derive from a common upstream that our measurements have not detected. Agreement is evidence, not proof. Where a small number of sources agree, agreement can reflect a shared error rather than truth.

single_source

The response passed structural and plausibility checks but no independent confirmation was available. Either no other source could answer the request, or the available sources were not measurably independent.

What this means in practice. The data may be correct. It may also be entirely wrong, and the Service had no way to detect that. Treat single_source data as unconfirmed.

A note on derived metrics: for measurements of change over time computed from a single consistent source — trends, deltas, variations — a systematic bias in that source partially cancels in the comparison. This does not make the underlying absolute values reliable. Where a response is used for a derived metric, the trace records which requirement was met.

unverified

The response could not be verified beyond basic structural checks, or verification was not possible for that request type. No confidence should be placed in the correctness of this data.

Verification is performed in layers. Not every layer runs on every request.

Structural checks (every response). HTTP status and timeout, schema conformance, presence of required fields, non-empty and non-hollow response, freshness of any timestamp, and domain plausibility bounds.

Statistical checks (where possible). Comparison against other sources answering the same question, deviation from a source's own historical behaviour, and comparison against an authoritative on-chain reference where one exists for that data type.

Semantic checks (sampled). An automated judgment of whether a response actually answers the question asked. This layer is applied selectively and is not applied to every response. Where applied, it is itself subject to error; its verdicts carry a confidence weighting rather than being treated as ground truth.

What no layer checks. Whether the underlying real-world fact is true. Verification compares sources against each other and against references. It cannot establish ground truth where no reference exists.

The Service maintains reliability measurements for each source, based on observed latency, availability, response completeness, deviation from peers, and outcomes of past deliveries.

These are statistical estimates from historical observation. They describe past behaviour and are not predictions. A source with a strong record can fail on the next call. Measurements decay over time and are re-established through continued observation.

Independence. Where the Service reports that sources are independent, this is an estimate derived from statistical comparison of their outputs. Sources that share an undisclosed upstream may not be detected as related. Independence is estimated, not verified at the infrastructure level.

Where we publish measurements about data quality — such as error rates, availability, or reliability figures — the following applies.

All published rates are reported with a confidence interval. A rate stated as a single number is not a measurement. Where we report zero observed errors, we state the upper bound of the confidence interval, because zero observations in a finite sample does not establish a zero rate.

Measurements are specific to the sources, data types, time periods, and sample sizes stated. They do not generalise to other sources, other types, other periods, or to your particular requests.

Anchored and unanchored measurements mean different things. Where an authoritative reference exists, we can report a rate of incorrect responses. Where no such reference exists, we can only report disagreement with a reference source — a figure that carries the error of the reference source itself and is not a measure of truth. We label these distinctly and they must not be read as equivalent.

Published measurements are historical and are not commitments about future performance.

Not every kind of data can be verified to every level.

A data type is served at consensus only where sufficient independent sources exist for it and, where required, a measured judgment mechanism is available. Where those conditions are not met, the type is served at single_source only, and this is stated in the interface with the reason.

This is a structural limit, not a temporary one. Where only one source in the world provides a kind of data, no amount of engineering can produce independent confirmation of it.

Cost projections shown when configuring an agent are estimates based on source list prices at the time of the projection. Actual costs may differ where sources change pricing, where failures require additional attempts, or where response sizes vary.

You are responsible for setting budget limits. Credit weights differ substantially between data types — verified data from the long tail can cost several times more per delivery than anchored data from high-volume sources.

Data delivered through the Service is not financial, investment, trading, legal, medical, safety, or professional advice, and must not be treated as such.

Do not use the Service as the sole basis for any decision with financial, legal, safety, or health consequences. The verification level attached to a response does not change this. Even anchored data is a point-in-time comparison against a reference that may itself be wrong.

Where the stakes of a decision are high, obtain independent confirmation appropriate to those stakes.

Third-party sources may become unavailable, change format, alter pricing, or restrict access without notice. Where a request cannot be fulfilled at your configured minimum verification level, the Service refuses the delivery rather than returning unverified data labelled as verified. A refusal is the Service functioning correctly.

Automated agents may be paused, throttled, or terminated by budget limits, rate ceilings, auto-kill triggers, or Service protections. Scheduled collection is best-effort and exact timing is not guaranteed.

• ·Choosing a minimum verification level appropriate to your use case
• ·Independently verifying data where the consequences warrant it
• ·Setting and monitoring budget and rate limits
• ·Ensuring your use of delivered data complies with applicable law and with the terms of the originating source
• ·Not representing data delivered through the Service as verified beyond the level assigned to it

The disclaimers and limitations of liability in Sections 12 and 13 of the Terms of Service apply in full to everything described here. In particular, and to the maximum extent permitted by law, Metera is not liable for losses arising from decisions made in reliance on data delivered through the Service, regardless of the verification level assigned to it.

hello@metera.xyz

This document is drafted in English. Any translation is provided for convenience; the English version prevails.