Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.pelion.dev/llms.txt

Use this file to discover all available pages before exploring further.

The behavior below is already implemented in pelion.judgment and pelion.validator. The on-chain path through the adapter is specified but not yet deployed.
Real-world questions are not always binary. Some of them cannot be cleanly adjudicated by the evidence available. Forced-binary oracles collapse these into YES or NO anyway. Pelion treats them as a third, structurally distinct outcome.

​
Why forced binary fails

Consider three scenarios. Each produces a question that has no single correct binary answer. Ambiguous event timing. “Did event X happen by midnight UTC on date Y?” If the primary source reports in a different timezone, the answer can flip based on interpretation. Contradicting primary sources. Two credible outlets report contradictory facts. Reuters says event happened. AP says it didn’t. The resolution criteria don’t specify which outlet to prefer. Edge cases not anticipated by criteria. The market asked “did X happen.” X almost happened, or something that resembles X happened. The resolution criteria didn’t anticipate the specific form of the event. A forced-binary oracle must pick YES or NO. Half the market believes the resolution is wrong. Controversy compounds. UMA’s historical data on contested markets shows this pattern consistently. Pelion acknowledges the underlying fact. The evidence does not decide. The protocol returns UNRESOLVABLE. The requesting contract decides what to do about it.

​
The UNRESOLVABLE sentinel

UNRESOLVABLE is a signed integer sentinel with value -1. It flows through every layer. Canonical Verdict. The outcome field on the off-chain Verdict schema is a signed integer. UNRESOLVABLE = -1, NO = 0, YES = 1. Multi-outcome markets use values at or above 2. This is documented in the schemas module and locked by the spec. Bittensor wire (PelionSynapse). The miner returns the same integer on the Synapse outcome field. Adapter contract state. PelionAdapter.sol preserves the signed integer through submission, challenge, and finalization. The Solidity interface uses int256 outcome specifically to accommodate negative sentinels. Requester callback. The adapter calls back to the requesting contract with the outcome integer. The requesting contract’s callback function interprets -1 as UNRESOLVABLE and handles accordingly.

​
What the requester does with UNRESOLVABLE

Pelion does not dictate the response. The requesting contract chooses. Refund both sides. For a simple prediction market, this is the safest default. Everyone gets their stake back. Escalate. For higher-value markets, the contract can route the question to an independent council (Pelion’s own escalation council, for example). Retry with refined criteria. The contract can reissue the question with tighter resolution criteria and let the protocol try again. Apply the contract’s own undefined-outcome rules. Some contracts have contract-specific rules for undefined outcomes. Insurance contracts, for example, might have a “disputed claim” path that goes to underwriter review. The protocol’s responsibility is to produce a verdict that is true to the evidence. The requesting contract’s responsibility is to handle the verdict according to its own logic. Pelion does not impose a single coercion policy.

​
Calibration scoring

Pelion’s scoring mechanism rewards miners for calibrated uncertainty, not just raw accuracy. This is enforced at the validator layer. On questions with available ground truth, validators score miners on three factors. Backtest accuracy (did the verdict match ground truth). Evidence quality (was the evidence diverse, authoritative, recent). Calibration (did the miner return UNRESOLVABLE on genuinely inconclusive questions, or did they overcommit to a wrong answer). A miner that always returns YES on ambiguous questions scores well on pure accuracy when the truth turns out to be YES, but poorly on calibration when the truth turns out to be genuinely ambiguous. A miner that always returns UNRESOLVABLE scores well on calibration (no wrong commits) but poorly on accuracy (no correct commits either). The scoring function rewards miners who are right when the answer is clear and UNRESOLVABLE when it isn’t. This is the incentive Pelion needs to produce reliable verdicts without manufactured certainty. v0 of the validator ships with accuracy-only scoring (1.0 for match, 0.0 for miss). The richer calibration-aware scoring lands later in the build sequence against live subnet data. The accuracy-only scoring is intentionally simple so that behavior is predictable while the subnet bootstraps.

​
The guardrail. UNRESOLVABLE is never an error handler

This is the most important design rule around UNRESOLVABLE. Infrastructure failures raise errors. They do not silently return UNRESOLVABLE. If a miner’s frontier model API times out, the miner raises rather than returning UNRESOLVABLE with empty reasoning. If a validator’s Dendrite call fails, the validator records a null score rather than recording UNRESOLVABLE as the miner’s answer. If a router’s subnet query returns malformed responses, the router retries or fails explicitly rather than synthesizing UNRESOLVABLE from the failure. The reason is simple. UNRESOLVABLE means “the evidence does not determine the answer.” If infrastructure failures silently map to UNRESOLVABLE, the outcome label loses information. Every verdict must carry its actual meaning. The failure path and the inconclusive path are different outcomes that deserve different handling. This guardrail is enforced in the reference implementation today. It is documented in each module’s README as a hard rule.