Refusals

Most data infrastructure has exactly one behaviour available to it: return something. When the good source is down it returns the worse one. When nothing can be confirmed it returns the unconfirmed number in the same shape as a confirmed one. The caller cannot tell the difference, so the caller acts on both, and the cost of that shows up later in a decision nobody can reconstruct.

How to ask for one

Set minLevel on the call. It is the floor you are willing to act on, and below it you would rather have nothing.

get_verified_data({ type: "token.price", params: { token: "SOL" }, minLevel: "anchored" })

There is a stricter form for callers who meant chain state specifically. By default an independent signed oracle read over HTTPS also earns the anchored label, and the answer says which through anchorKind. Set requireOnChainAnchor and the off-chain fallback is skipped rather than substituted, so a caller who wanted a chain read is refused instead of quietly given something else.

Two moments a call can be refused

Before anything runs, when the level is unreachable in principle. Asking for anchored on a type no reference covers, or on a pair no oracle carries, is answered at the door. Nothing was called and nothing was spent, and the response names the ceiling the type actually reaches so the caller can decide what to do.

After the work, when the level was reachable but this call did not get there. The sources were tried, the checks ran, and none of it qualified. The trace holds the whole attempt. This is the expensive case for us and it is still free for you, which is the point.

Why they are free

This has to be structural rather than a promise. If refusals were billed, we would slowly find reasons to refuse. If deliveries were billed only when confident, we would slowly find reasons to be confident. Charging on delivery and nothing on refusal is the arrangement that keeps our incentive pointing the same way as our claim, and it is the only version of this that survives contact with a revenue target.

It also means a strict caller costs us more than a permissive one. That is the correct direction. The alternative is a pricing model that quietly rewards us for lowering the bar.

What a refusal is not

It is not an error. The transport succeeded, the engine did its work, and the result is information. An agent that treats a refusal as a transient failure and retries until it turns into an answer has converted a working guarantee back into a guess, usually at the exact moment the guarantee was doing something useful.

It is not an outage either. Refusal rates rise when the world gets noisier: an oracle behind a degraded RPC, a source drifting, a pair whose venues disagree. Those are the conditions under which a confident answer would be worth the least.

What to do with one

Read the reason, which is specific rather than a generic failure string. Then choose deliberately: retry later if the condition is transient, lower the floor for this particular decision if a weaker answer is genuinely enough, or do neither and let the agent do nothing.

Doing nothing is a real option and often the right one. An honest system refuses sometimes. A system that never refuses is not more capable, it has just stopped telling you when it does not know.