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 adapter contract is not yet deployed. This page describes the specified behavior. Actual implementation lands in Phase 1.
A question moves through five states from the moment it lands on the adapter to final payout. Each state has defined transitions, timing bounds, and clear error handling.

​
The state machine

​
State by state

Submitted. The adapter has accepted the question and escrowed the requester’s reward plus bond. The QuestionSubmitted event has been emitted. Router services are picking it up and dispatching to routed subnets. VerdictPending. A relayer has posted a verdict with a relayer bond. The challenge window is open. Its length scales with stakes. 1 hour for low-stakes routine questions, up to 6 hours for high-stakes markets. The window is committed at submission time, not negotiable later. Contested. Someone submitted a counter-verdict with a counter-bond of at least disputeBondMultiplier times the relayer bond (default 2x). The adapter now runs on-chain signature verification. Both verdicts carry validator signatures from the subnet block they reference. Whichever matches actual subnet consensus at that block height wins. The losing party’s bond is forfeited to the winner, minus a protocol fee. For contested verdicts that survive signature verification ambiguously (or where the subnet itself is in dispute), the adapter can escalate to the governance council. Finalized. The verdict is committed. The adapter calls back to the requesting contract with the outcome, confidence, and evidence hash. The requesting contract runs its own resolution logic (payouts, escalation, refunds) using the verdict as input. Expired. The question’s expiration time passed with no verdict submitted. The requester can reclaim their bond. The reward is returned. No payout happens. Cancelled. Explicit cancellation after expiration. Final state.

​
Edge cases

Multiple relayers racing to submit the same verdict. First submission accepted. Others refunded with a small gas reimbursement from the adapter to avoid penalizing them for participating. Relayer submits an invalid verdict (bad signatures). Automatic slashing at submission via on-chain signature verification. The adapter does not accept and store invalid verdicts, they are rejected at the gate. Challenger wins against the incumbent verdict. The challenger’s bond is returned plus a portion of the relayer’s bond as reward. The challenger’s counter-verdict is finalized. The original relayer’s bond is partially distributed to the challenger and partially to the protocol. UNRESOLVABLE verdict. The adapter respects it. It calls back to the requesting contract with the UNRESOLVABLE flag set. The requesting contract decides what to do. Refund, escalate, retry with refined criteria, apply its own undefined-outcome rules. Pelion does not force a coercion. Expired questions. The requester can reclaim their bond via cancelQuestion(). The reward goes back with it. This is the escape hatch for questions that never resolved, whether because no subnet picked them up, all subnets returned errors, or the requester’s resolution criteria were malformed.

​
Timing expectations

Standard questions. Minutes from submission to finalization. Subnet resolution takes seconds to a minute. Relayer bond posting takes a block (2 seconds on Base). Challenge window is 1 hour minimum. No challenge path finalizes in roughly 1 hour from submission. Contested questions. Hours. The challenge window extends the total time. Signature verification happens in a single transaction once both verdicts are posted. Council escalation adds days if triggered. High-stakes questions. Hours by design. Longer challenge windows allow for more scrutiny. The tradeoff is explicit. Faster finalization for smaller stakes, more deliberation for larger ones.

​
Why the challenge window scales with stakes

A 1-hour window on a 1,000marketisfine.A1−hourwindowona1,000 market is fine. A 1-hour window on a 10M market is not. The economic rationale for honest challenging scales with the size of the potential fraud. The challenge window scales with it so that challengers have time to notice, verify, and submit a counter-verdict. The specific scaling curve (whether it’s linear, logarithmic, or capped) is a governance parameter. The default at launch is a stepped curve. Small markets 1 hour, medium markets 3 hours, large markets 6 hours, with thresholds set at submission and not adjustable afterward.