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 five layers
| # | Layer | Where it runs | What it does | Status |
|---|---|---|---|---|
| 1 | Application | Base (Solidity) | Prediction markets, insurance contracts, DAOs. Submit questions, consume verdicts. | Not built (reference market in Phase 1) |
| 2 | Adapter | Base (Solidity) | Accept question submissions, escrow bonds, handle challenges, fire callbacks. | Not built (Phase 1) |
| 3 | Router | Off-chain (Python) | Translate Base events to Bittensor queries, aggregate multi-subnet responses. | Not built (Phase 2) |
| 4 | Judgment | Bittensor (Python) | Miners produce verdicts. Validators score. TAO-backed economic security. | Built (pelion.miner, pelion.validator, pelion.judgment) |
| 5 | Relay | Bonded cross-chain | Carry verdicts from Bittensor to Base with permissionless challenge. | Not built (Phase 2) |
The lifecycle of one question
See Question lifecycle for the state machine and edge cases.Trust boundaries
A clean map of what each actor must trust, and what they don’t.| Actor | Must trust | Does NOT trust |
|---|---|---|
| Requester (app on Base) | Adapter contract correctness. Bittensor subnet honesty (economic assumption). | Router services, relayers, individual miners or validators. |
| Router service operators | Their own keys and code. | Miners, validators, or relayers. Verification via signatures. |
| Bittensor subnet participants | Subnet incentive mechanism. Bittensor chain. | Router services, Base chain. |
| Relayers | Bittensor subnet consensus signatures. Base chain. | Any single validator or miner. |
| Base verdict consumers | Adapter finalization logic and challenge economics. | Anything upstream directly. Everything routes through the adapter. |
Where the judgment happens
The built judgment layer (pelion.judgment) is a synthetic frontier council. A Python module that fans a question to Anthropic’s Claude, OpenAI’s GPT, and Google’s Gemini in parallel and aggregates responses via majority vote. It is not a Bittensor subnet. It is a fallback path and the baseline against which the real Bittensor judgment is measured.
When the Bittensor integration comes online, miners will wrap this same frontier council behind a Bittensor Axon (the pelion.miner module), so the quality of judgment is at least frontier-model quality. A validator on the subnet will score miners against known-answer backtest questions to separate honest miners from lazy ones.
See Run a miner and Run a validator for the operator view.
Multi-subnet routing
A single-subnet resolution is cheaper but has a concentrated attack surface. That subnet’s alpha market cap. Pelion’s adapter supports routing a question to multiple subnets. An attacker then needs to corrupt a quorum of subnets simultaneously, which scales attack cost close to multiplicatively across the routed subnets. Routing policy is per question. The adapter accepts asubnet_routing list (for example, [6, 28] for SN6 Numinous plus SN28 Foundry Oracle). Low-stakes questions go to a single subnet. High-stakes questions fan out.
See Economic security for the cost-to-attack math.
The UNRESOLVABLE path
A council that cannot reach agreement returns UNRESOLVABLE. A first-class verdict outcome, not an error condition. The adapter propagates it to the requesting contract, which decides what to do.
Refund both sides.
Escalate to an independent council.
Retry with refined resolution criteria.
Treat as an undefined outcome per the contract’s own rules.
This is the structural difference vs UMA. Pelion does not force a YES or NO on a question the evidence cannot settle.
See UNRESOLVABLE and calibration.
Relay and the v1 trust model
The bonded cross-chain relay carries verdicts from Bittensor-side (where subnet consensus lives) to Base-side (where the adapter contract lives). The v1 relay is a bonded federated committee. A small set of relay signing nodes run by the protocol and reputable validators. The adapter verifies a threshold of committee signatures rather than native subnet signatures. This is a documented centralization compromise for v1. The v2 design target is a light-client bridge that verifies subnet consensus natively (Hyperlane ISM, LayerZero DVN, or a Bittensor-specific bridge once infrastructure matures). The whitepaper is explicit that v1 users accept this trust assumption and that it narrows in v2. See Reference, full technical spec §4.5 for the full relay design.Where to go deeper
Question lifecycle
The state machine, edge cases, and what happens on challenges.
Economic security
Cost-to-attack math, multi-subnet defense, and the quantitative comparison to UMA.
UNRESOLVABLE and calibration
Why ambiguous questions need a structural escape valve and how the protocol handles them.
What's built today
The four Python modules that exist and run right now.