How it works
Your agent asks for data. Metera delivers the version it can trust.
And tells you exactly how much it trusts it.
You ask
Your agent asks for what it needs — a token price, a social profile, on-chain state — in plain language or through the API. It doesn't pick a source. It doesn't manage a key for each provider. It asks.
M–ONE picks the source
Every source is scored on measured reliability — how often it delivers, how fast, how fresh, how often it disagrees with everyone else. The call goes to the one most likely to work right now.
Not the most popular. Not the one that paid to be listed. The one the measurements point to.
It verifies before delivery
The answer is checked before it reaches your agent. Structure, freshness, plausibility, agreement with independent sources, and — where an oracle or chain provides ground truth — agreement with that.
If a check fails, the source is swapped mid-request and another one is tried. Your agent sees slightly higher latency. Nothing else.
You get the answer, and its level
Data comes back with the verification level it earned.
{
"data": { "token": "SOL", "priceUsd": 72.46 },
"verification": {
"level": "anchored",
"source": "okx",
"cost": "0.0015",
"traceId": "tr_dr29wv"
}
}Verification
The three levels
anchored — checked against an independent authoritative reference, typically on-chain state or a signed oracle, and agreed with it.
consensus — agreed with independent sources. Independence is measured, not assumed: providers that turn out to read the same upstream count as one, not several.
single_source — passed structural and plausibility checks, but no independent confirmation was available. It may be right. We couldn't confirm it, and we say so.
A level is not a guarantee of accuracy. It describes which checks ran and passed. You set the minimum your agent accepts — below it, we refuse the delivery rather than dress up an unconfirmed answer.
That refusal is the product working, not failing.
Billing
You only pay for what worked
A failed verification costs you nothing. Failed attempts made while fulfilling your request are absorbed by us — that’s our problem, not yours.
Two ways to pay:
Credits
Subscribe, your agents spend from the balance. One credit isn’t one call: sources cost different amounts, and the weight is shown before you use them.
x402
No account, no subscription. Your agent pays per verified call, settled on Solana.
Same routing, same verification, same trace. Only the billing differs.
Transparency
Nothing is a black box
Every response carries the reasoning behind it: which source was chosen, why that one, what the alternatives scored, which checks ran, what it cost, and the transaction if there was one.
Directories in this space rank sources by transaction volume and buyer reach — popularity metrics that never touch whether an answer was correct. And none of them show you the ranking, only the result.
We show the reasoning because the reasoning is the product.
Agent controls
Spending limits the chain enforces
A limit in a database is a suggestion. A compromised key, a prompt injection, or a race condition walks straight past it.
Metera’s payout wallet is a Squads v4 multisig with a USDC spending limit written on Solana and locked so that nobody — including us — can raise it.
The lock, in four transactions
- TX1
Create the multisig
A dedicated Squads v4 multisig is created, funded by the setup payer.
- TX2
Add the spending limit
A SpendingLimit PDA is added for USDC with a fixed daily cap.
- TX3
Raise the threshold
The signature threshold is raised so no single key can move funds or alter config.
- TX4
Burn the authority
config_authority is set to Pubkey::default(). The limit becomes immutable. Irreversible.
Post-lock state
multisig Sq4…9kQ
spending_limit USDC · 500 / day
period SpendingPeriod::Day
threshold 2
config_authority Pubkey::default() ✓ locked
mutable falseThe cap is enforced by Solana on every transfer, not by our API. It holds even if our server is wrong or compromised. Funds are never moved into the vault until the lock is verified on-chain.
Most platforms ask you to trust that they’ll behave. This one removes our ability to misbehave.
Proven
Built against adversaries first
Before M–ONE was pointed at the real world, it was pointed at liars.
A source returning plausible wrong numbers that pass every structural check: wrong deliveries went from 78.5% to 0.5%.
Five providers with five different names reading one shared upstream: before detection they produced 575 confidently wrong "consensus" deliveries. After, zero — not because the data improved, but because the label got honest.
Two sources colluding in a category with no ground truth is informationally indistinguishable from the truth. No statistical judge resolves that. M–ONE doesn’t pretend otherwise — it labels those answers unconfirmed, every time.
Across every adversarial scenario, mislabeled rate: 0%. Data can still be wrong. The label describing our confidence never is.
Measured
Then against the real world
500 live calls against independent exchange feeds, judged against a signed on-chain oracle. Zero lies, zero unavailable. Lying rate below 1% at 95% confidence — reported as an interval, because a rate reported as a single number is not a measurement.
Two exchange feeds tested at residual correlation r=0.154 — genuinely independent. Two social providers tested at 100% exact agreement across eleven handles, identical to the byte. They weren’t two observations. They were one, counted twice. M–ONE refused to call it consensus.
Start
curl https://api.metera.xyz/v1/ask \
-H "Authorization: Bearer $METERA_KEY" \
-d '{"query":"SOL price"}'Free tier, no card. Test keys return fixtures with the same shape and no charge — integrate before you pay.