Pythscan
Network primitive · Network primitives

Proposal lifecycle

How a proposal becomes a decision in Pyth governance. Draft on the forum, temperature check, on-chain vote (if applicable), execution.

Every change to Pyth governance — a new feed listing, a slashing parameter tweak, a treasury allocation — goes through a structured lifecycle. The exact path depends on the proposal type, but the broad stages are consistent. The Constitution and the forum process docs are the canonical sources for what's required at each step.

The general flow

  1. 01Forum draft — author posts the proposal on forum.pyth.network in the appropriate section
  2. 02Discussion — community comments, sponsors emerge, concerns get raised
  3. 03Temperature check — informal signal of whether the idea has support, before any binding vote
  4. 04Formal proposal — the proposal is formatted as a PIP, OP-PIP, or EXC-PIP with full specification
  5. 05Vote — council multisig (for OP-PIPs and PIPs within scope) or stake-weighted DAO vote (for EXC-PIPs)
  6. 06Execution — on-chain action via the appropriate multisig
  7. 07Reporting — outcome documented on the forum

Where each type goes

  • OP-PIP — routine work inside a council's mandate. The council ratifies it via their multisig; no DAO-wide vote needed.
  • PIP — standard proposal inside a council's mandate. May involve a wider discussion period and a more formal review before the council acts.
  • EXC-PIP — anything outside any council's standing mandate. Requires a stake-weighted DAO vote, with the Constitution defining the quorum and threshold.

What to look for on Pythscan

/governance mirrors the live forum. Each topic shows the section it lives in (Proposals, Ideas, Council updates, etc.), reply count, and last-activity timestamp. /governance/sections/* groups proposals by council. For council-level decisions in progress, the /councils/* pages link to the relevant forum threads.

Related concepts