The trust layer for agent data.

Abstract

Autonomous software now buys data on the open internet at a scale no human workflow ever reached. An agent can discover an API, call it, and pay for the response in the same second, thousands of times an hour, with no person in the loop. What none of these agents can do is tell whether the data they received is correct. The response arrives well formed, the status code says success, the schema matches what was promised, and the value inside can still be stale, biased, scraped from a page that changed last week, or simply wrong.

Metera is the trust layer for that economy. Its engine, called M-ONE, decides which source an agent should trust for a given request, verifies the response before it is delivered, and returns the data together with an honest label describing how much confidence that answer earned. Metera does not promise that data is true. It promises something narrower and more defensible: it never overstates what it knows. A source that cannot be confirmed is returned labeled as unconfirmed, every single time, and the agent decides what to do with that.

This document explains the problem in detail, the architecture that addresses it, the verification model that is the core of the product, the results of nine rounds of adversarial simulation and the first measurements against live sources, the economics that make the system sustainable, and the role of the $METERA token within the protocol.

The problem

A new kind of buyer

For most of the history of software, the consumer of an API was a human developer or a program a human wrote and supervised. Quality control lived in that human. A developer read the documentation, tried the free tier, noticed when a response looked wrong, complained, switched providers, and built a mental model of which sources could be trusted for which tasks. This process was slow and expensive, and it worked, because judgment was always present somewhere in the chain.

Agents removed the human from that chain. An autonomous agent selects a source, calls it, interprets the response, and acts on it, often without any person reviewing the intermediate steps. The agent makes far more purchases than a human ever could, and it inspects none of them the way a human would. The judgment that used to protect the transaction is gone, and nothing has replaced it.

Why a valid response is not a correct one

The failure is subtle because the signals a machine can easily check all pass. Consider an agent that asks for the current price of a token. The endpoint returns HTTP 200. The body parses as JSON. The schema contains every field the agent expected. The price is a plausible number. Every automated check an agent typically performs is green. And the number is three months old, because the source is a cache that stopped updating, or it is scraped from a page whose layout changed, or the provider quietly degraded under load and started returning its last known value.

If a human reads that response, they often notice, because humans carry context a schema does not encode. If an agent reads it at three in the morning and acts on it, the wrong number becomes a decision. A trade executes. A report goes out. A message reaches a customer. The cost of the error is not the bad response itself. It is everything the agent did because it believed the response.

Why existing infrastructure does not solve this

Discovery layers for agent data already exist and are growing quickly. Coinbase x402 Bazaar indexes thousands of paid endpoints. Independent directories catalog and rank sources. These systems solve discovery, and they solve payment. They do not solve trust.

The ranking signals these systems use are transaction volume, buyer reach, and recency. These are popularity metrics. A source that returns garbage but successfully collects payment ranks well, because from the directory point of view the transaction succeeded. The one property none of these systems measure is whether the answer was correct, because measuring that is hard, and because their business does not depend on it. The result is an information asymmetry the buyer cannot resolve, rebuilt at machine speed, with a buyer that makes thousands of purchases an hour and inspects none of them.

Design principles

Four commitments shaped every decision in the architecture. They are stated up front because the rest of the document is, in effect, the consequence of taking them seriously.

Architecture

Overview

At its center Metera is a routing and verification engine that sits between an agent and a field of possible data sources. A request enters. The engine selects the source most likely to deliver a correct answer, calls it, verifies the response through a series of layered checks, fails over to another source if a check does not pass, and returns the data together with the verification level it earned and a full trace of how the decision was made. The agent that made the request sees a slightly higher latency when failover occurs and nothing else.

Routing as a learning problem

Choosing which source to call is a decision made under uncertainty, repeated continuously, where the quality of each source is unknown at the start and changes over time. This is the classic structure of a multi armed bandit problem, and Metera treats it as one.

Each source, for each type of query, carries a probability estimate of delivering a good response, represented as a distribution rather than a single number, so that the system tracks not only how reliable a source appears but how confident it is in that appraisal. For each request the engine samples from these distributions and routes to the source with the best sampled value under the caller policy. This approach, known as Thompson sampling, naturally balances using sources known to be good against occasionally trying sources whose quality is still uncertain. The routing decision itself is arithmetic. It runs in well under a millisecond at the ninety ninth percentile. There is no language model in this hot path, because a model call would cost more than the data being selected and would add latency the decision cannot afford.

Staleness and re-exploration

A source that performed well last week may have degraded since. To handle this, the confidence the engine holds in a source decays when that source goes unobserved. As certainty erodes, the engine naturally begins to try the source again, on its own, without any scheduled probing. Re-exploration is a consequence of the way uncertainty is modeled, not a separate background process that must be maintained and paid for. This design replaced an earlier scheduled probing scheme that proved too costly and too rigid.

Verification in layers

Verification runs in layers, cheapest first, so that most responses never reach the expensive checks.

The first layer is deterministic and structural. Did the source respond, and in time. Does the payload conform to the declared schema. Is any required field present. Is the response non empty and not hollow, meaning a technically valid body that carries no real content. Is any timestamp fresh. Are the values within plausible bounds.

The second layer is statistical. The response is compared against other sources answering the same question, and against an authoritative on chain reference where one exists for that type of data. Agreement across genuinely independent sources is evidence. Agreement across sources that secretly share an upstream is not, which is why independence is measured rather than assumed.

The third layer is semantic. A model assesses whether the response actually answers the question that was asked. This layer is expensive and is applied selectively rather than to every response. Critically, the verdict of this layer is itself treated as fallible. It carries a confidence weight rather than being sealed as ground truth, because a judge that is right most of the time but not always will poison the system if its verdicts are trusted absolutely.

The provenance invariant

One rule cuts across the entire system and protects it from a class of silent corruption: nothing unverified ever becomes a learning signal. A response that failed verification, or that was never confirmed, does not update a source reliability estimate, does not seed a prior, does not enter a cache that later informs a decision. Bad data is delivered, if at all, clearly labeled, and it dies there. It never quietly becomes the basis on which the next decision is made.

The verification levels

The verification level attached to every response is the product. Everything in the architecture exists to make these labels honest.

A level describes which checks passed. It is not a guarantee of accuracy. The caller sets the minimum level their agent will accept, and below that line Metera refuses to deliver rather than dress up an unconfirmed answer as a verified one. That refusal is the system functioning as designed.

An important structural consequence follows from this model. Some kinds of data, such as a follower count or a token circulating supply, have a single source of truth at their origin, and every scraper ultimately reads the same upstream. For this kind of counted data, genuine consensus is impossible by construction, no matter how many providers are added, because they are all reading the same place. Such data can only rise above single_source through an anchor. Other kinds of data, such as an engagement rate or an estimated reach, are computed independently by different providers using their own methods, and for these consensus is genuine. The system distinguishes these cases rather than pretending that more providers always produce more confidence.

Adversarial validation

Before Metera was pointed at a single real source, it was developed against adversarial simulation across nine rounds. The purpose was to discover the dynamics of the system, and the ways it could be fooled, in an environment where ground truth was known and every failure could be inspected. The simulation found real behavioral bugs that would otherwise have reached production silently, and the results that follow are drawn from it.

Across every adversarial scenario, the mislabeled rate was zero. Data can be wrong. The label describing the system confidence in that data never was.

The simulation also corrected the engineering itself. In one instance a more accurate judge produced worse outcomes than a less accurate one, an impossible result on its face, traced to a caching rule that let only the most confident judge record a rejection and therefore only that judge could wrongly silence an honest source for an extended period. The fix, requiring two consecutive rejections rather than one confident rejection, restored the expected ordering. Results of this kind are the reason the system was built against adversaries first.

Measurement against the real world

Simulation demonstrates that an engine behaves correctly. It does not reveal what the world is actually like. The first measurements against live sources established that.

Five hundred live calls were made against independent exchange feeds, with the results judged against a signed on chain oracle. There were zero lies and zero unavailable responses. The lying rate of the sources measured below one percent at ninety five percent confidence, and it is reported as an interval rather than a single figure, because a rate reported as a single number is not a measurement.

The independence estimator was validated against real data as well. Two large exchange feeds, tested for residual correlation against the anchor, measured at 0.154, confirming genuine independence. Two social data providers, tested across eleven handles, agreed one hundred percent of the time, identical to the byte. They were not two observations. They were one, counted twice. The system refused to treat their agreement as consensus, which is precisely the behavior the design requires.

Economics

How Metera charges

Access to data is metered in credits. One credit is not one call. Different sources cost different amounts to serve, and the credit weight of a call reflects the real cost of the source that delivered it plus a margin. Verified data from the long tail can cost several times more per delivery than anchored data from a high volume source, and the pricing reflects that honestly rather than averaging it away.

Charging occurs on delivery. A call that fails verification, or that falls below the caller minimum level and is refused, is not charged. The failed attempts made in the course of fulfilling a request are absorbed by Metera. The system only earns when it delivers something that passed.

How providers earn

A provider lists a source and is paid per successfully delivered call, in USDC, settled to the wallet configured in their account, on a recurring schedule. A provider is not paid for calls that fail verification, and the cost of those calls is borne by Metera, not the provider. This aligns incentives cleanly: Metera earns only when a provider delivers something that passes, and a provider earns only when its data is good enough to be delivered.

Ranking cannot be bought. No listing fee, stake, or commercial relationship moves a source up in routing. This follows directly from the price blind routing invariant and is a property of how the engine is built rather than a policy that could be waived. A trust layer that sold placement would not be a trust layer.

Sustainability

The margin embedded in the credit weight of each call is calibrated against the real cost of serving that call, including the cost of sources that must be paid in the course of verification and the overhead of attempts that do not result in a delivery. The economics are designed so that the paid tiers are sustainable across the full range of usage, including the case where a customer consumes entirely from the expensive long tail, while the free tier operates as a bounded subsidy whose maximum loss per user is capped by the size of the grant.

The $METERA token

The token exists to align the participants in the network. It is not required to use the product. Agents pay in USDC, and that will remain true. Holding and using the token is economically rational for reasons described below, and usage drives the token rather than the token gating usage.

Launch and lock

$METERA launched on EasyA Kickstart, a permissionless ideas launchpad on Solana. The development allocation is locked on Streamflow until August 5, 2027, in a contract that is immutable and can neither be canceled nor transferred. The lock, its amount, its unlock date, and its recipient are all on chain and readable at any time.

This mirrors the principle the product itself runs on. The platform payout wallet is a multisig with a spending limit written into Solana and locked so that not even the team can raise it. The development allocation is locked so that not even the team can move it for a year. In both cases the design does not ask anyone to trust the team. It removes the team ability to misbehave.

Known limits

A document that only stated strengths would contradict the product it describes. The following limits are stated plainly because being explicit about them is consistent with the entire thesis.

The system cannot establish that a real world fact is true where no reference for it exists. Verification compares sources against each other and against anchors. It cannot conjure ground truth from nothing.

Two sources colluding in a category without an anchor are indistinguishable from two honest sources agreeing. The system labels this situation as unconfirmed rather than resolving it, because it cannot be resolved by measurement alone.

Independence is estimated from observed behavior, not verified at the infrastructure level. Sources that share an upstream in a way that does not show up in their outputs may not be detected as related, though the estimator is designed to catch the common cases.

Some canonical types cannot reach consensus with the sources that exist today, because genuine independent providers for them do not yet exist, and the catalog states this rather than promising a level it cannot deliver.

Certain capabilities described in this document as part of the protocol design are aspirational and are being built rather than fully deployed. The document distinguishes what is measured and live from what is planned.

Conclusion

The economy of autonomous agents is being built on data that nothing checks, purchased by software that never hesitates and never inspects. Discovery for that data exists. Payment for it exists. What has been missing is any way for the buyer to know whether the answer it paid for is correct, or at least to know honestly how much that answer can be trusted.

Metera is that missing layer. It does not claim to make data true, because no system can. It makes something narrower and more valuable possible: an agent that knows what it does not know, that can be told to refuse rather than to guess, and that carries with every answer an honest account of how far that answer can be trusted. Verification is not a feature of the agent economy. It is the condition for that economy existing at all.