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.

Governance infrastructure is specified. Tier 1 parameters operate under core team authority during the first 12 months, with progressive migration to token-holder control.
Three tiers of governance, each with a defined scope and decision process. The design is explicit about the tradeoffs between fast iteration during early phases and permissionless protocol operation at maturity.

Tier 1. Protocol parameters (first 12 months)

Operational parameters that need rapid iteration in the first year after launch. These parameters have bounded ranges defined in the spec. Changes within those ranges are routine. Changes outside the ranges require Tier 2 token governance. Scope. Challenge window durations. Fee rates within spec bounds. Supported subnet list (adding, removing, or modifying the routed subnets). Trusted relayer set (v1 only, phased out in v2). AI model versions used in the fallback frontier-model council. Process. Core team authority with a 48-hour timelock on any change. Changes are announced publicly before the timelock expires. The timelock gives token holders time to react, and the 48-hour window specifically prevents flash-changes to parameters during market volatility. Why it exists. Early-phase protocols need to iterate faster than full on-chain governance allows. A 7-day governance cycle for a 1-hour challenge window adjustment is operationally dead. Tier 1 provides the speed. The timelock provides accountability. Sunset. Tier 1 scope shrinks over time. Parameters migrate to Tier 2 as the protocol matures and specific parameters prove stable. The spec describes the specific migration milestones. A parameter is eligible for migration once it has not changed for 90 days and the protocol has seen sufficient volume at that parameter value.

Tier 2. Token governance (live day 1)

Protocol-level decisions made by token-holder vote. This is the permanent governance layer. Scope. Treasury alpha-management policy (harvest vs compound ratio). Major protocol upgrades (new modules, significant interface changes). Tax schedule adjustments beyond the auto-decay path. Migration of specific parameters from Tier 1 to Tier 2. Adding or removing subnets from the routing list (approved Tier 1 changes can be challenged into Tier 2 if controversial). Voting weight. Quadratic. A holder’s voting weight is the square root of their token balance, not the balance itself. This is a deliberate dampener on whale dominance. A holder with 100x another holder’s balance gets only 10x the voting weight. Quorum. Decisions require a minimum participation threshold, set at a level that allows genuine consent rather than rubber-stamping by a small active fraction. The specific quorum is a governance parameter itself and adjusts as token-holder participation patterns emerge. Timelock. Decisions that pass quorum and majority still go through a timelock before taking effect. The timelock length scales with the decision’s scope. Small parameter changes, short timelock. Major upgrades, longer timelock.

Tier 3. Escalation council

A randomly selected council drawn from qualified token holders. Handles disputes that are too ambiguous for the automated resolution path. When it activates. Two scenarios trigger escalation. A verdict returns UNRESOLVABLE and the requesting contract escalates (rather than accepting the UNRESOLVABLE outcome). A verdict survives the challenge window but faces substantial community pushback that could be formalized through a challenge-after-challenge-window mechanism. Member eligibility. Token holders who have staked at least a threshold amount (making them economically committed) and have passed basic KYC (for legal protection, especially for council members making binding judgment calls). The KYC threshold is the minimum required to shield the council from being treated as anonymous agents by regulators. Selection. Randomly sampled from the eligible pool. Council size varies by case complexity, typically 7 to 12 members per case. Members are not pre-assigned to cases, they are selected per-escalation. This prevents council capture by dedicated members. Decision process. Members review evidence, deliberate, and vote. Majority plus quorum required for a decision. Dissenting members’ reasoning is published along with the majority opinion. Incentives. Members are rewarded per correct ruling (measured against ground truth when ground truth eventually becomes available). Members are slashed for rulings later proven wrong by ground truth. At the meta-level, the council itself is judged by Pelion over time. Its rulings become dataset entries. Council members’ track records become public.

Progressive decentralization

The three tiers are designed to evolve. A specific roadmap. Year 1. Tier 1 covers all routine operational parameters. Tier 2 covers major decisions. Tier 3 is live for its specific use cases but expected to see low volume. Year 2. Tier 1 scope shrinks. Parameters that have stabilized migrate to Tier 2. The core team retains only parameters that genuinely need fast iteration (new subnet onboarding, AI model version updates). Year 3 and beyond. Tier 1 effectively dissolves. All routine parameters are under Tier 2 control. The core team’s role narrows to proposing changes like any other participant. Tier 3 continues to handle disputes as a permanent feature of the protocol. The progression above is a committed direction, not a fixed timeline. Actual pace depends on how quickly parameters stabilize and how confidently they can move to slower governance. A parameter that is still being tuned does not migrate, regardless of calendar date.

Why quadratic voting

One-token-one-vote gives whales dominant control. It is the failure mode Pelion specifically designs against in its economic security analysis of UMA. Strict equality (one-person-one-vote) would be fairer in principle but is Sybil-attackable. Anyone can create multiple wallets. Without identity verification at scale, which Pelion avoids outside the Tier 3 council, one-person-one-vote is not enforceable. Quadratic voting is the middle path. It preserves some proportionality (larger holders have more influence than smaller holders) while dampening the dominance of very large holders. A whale who owns 10x the median holder’s balance gets roughly 3.16x the voting weight, not 10x. A whale with 100x the median balance gets 10x voting weight. Quadratic voting is a tradeoff rather than a solution. The alternatives (strict proportionality, strict equality, delegation schemes) each introduce worse failure modes for Pelion’s specific use case, so quadratic voting is the least-bad option among the set.