> ## 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. # Architecture > Five layers, from application on mainnet to bonded cross-chain relay. The whole system in one page. The components marked "built" below exist and pass tests. The components marked "not built" are specified but not implemented. See [What's built](/whats-built/repository) for specifics. ## The five layers | # | Layer | Where it runs | What it does | Status | | - | ----------- | ------------------ | ---------------------------------------------------------------------------------- | ------------------------------------------------------------- | | 1 | Application | Mainnet (Solidity) | Prediction markets, insurance contracts, DAOs. Submit questions, consume verdicts. | Not built (reference market in Phase 1) | | 2 | Adapter | Mainnet (Solidity) | Accept question submissions, escrow bonds, handle challenges, fire callbacks. | Not built (Phase 1) | | 3 | Router | Off-chain (Python) | Translate mainnet 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 mainnet with permissionless challenge. | Not built (Phase 2) | Parallel to these. A treasury (mainnet contract plus self-custodied Bittensor coldkeys), a token (ERC-20 on mainnet with trading tax and buyback/burn), and a dataset (IPFS and Arweave archive of every question, verdict, and evidence bundle). ## The lifecycle of one question ```mermaid theme={null} flowchart TD A["User or contract
on mainnet"] --> B["submitQuestion()
escrow bond"] B --> C["QuestionSubmitted"] C --> D["Router translates
to subnet query"] D --> E["Miners produce
verdicts + evidence"] E --> F["Validators score
consensus extracted"] F --> G["Verdict bundle
pinned to IPFS"] G --> H["Relayer posts
to mainnet with bond"] H --> I{"Challenge window
1 to 6 hours"} I -->|no challenge| J["Finalize
payout callback"] I -->|challenge filed| K["Counter bond
sig verification"] K --> J ``` See [Question lifecycle](/how-it-works/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 mainnet) | 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, mainnet. | | Relayers | Bittensor subnet consensus signatures. Mainnet. | Any single validator or miner. | | Mainnet verdict consumers | Adapter finalization logic and challenge economics. | Anything upstream directly. Everything routes through the adapter. | The protocol's integrity reduces to three things. Subnet economic security. Relay challenge economics. Adapter contract correctness. Everything else is defense in depth. ## 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](/run-a-node/miner) and [Run a validator](/run-a-node/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 a `subnet_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](/how-it-works/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](/how-it-works/unresolvable). ## Relay and the v1 trust model The bonded cross-chain relay carries verdicts from Bittensor-side (where subnet consensus lives) to mainnet-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](/reference/full-spec) ยง4.5 for the full relay design. ## Where to go deeper The state machine, edge cases, and what happens on challenges. Cost-to-attack math, multi-subnet defense, and the quantitative comparison to UMA. Why ambiguous questions need a structural escape valve and how the protocol handles them. The four Python modules that exist and run right now.