Scope note
This page is the public lookup surface for DerivaDEX governance process and decision-state terminology. It covers public discussion, proposal, voting, and execution evidence. It does not publish private operational review or internal compliance workflow detail.Public governance surfaces
| Surface | Public role |
|---|---|
| Governance Forum | Canonical public discussion surface for proposals, election context, and governance feedback |
| DIPs repository | Public specification and mature proposal history for changes that reach formal design stage |
| Proposal or election page linked from the canonical thread | Public route where one active proposal or election exposes its identifier, slate, timeline, and wallet action |
| Governance-related contract surfaces | Public on-chain execution surfaces for delegation, voting, queueing, and execution evidence |
Canonical public artifact chain
| Stage | Public artifact that should exist |
|---|---|
| discussion | forum thread URL |
| formal proposal or election spec | DIP or equivalent public design artifact when the change matures past discussion |
| vote action | proposal-specific or election-specific page linked from the canonical thread or spec |
| execution evidence | queue or execute transaction hashes and on-chain event evidence |
Public proposal lifecycle states
| State | What public readers should expect |
|---|---|
| Discussion | Forum thread exists, but there may be no on-chain vote or formal proposal ID yet |
| Formal proposal draft | A DIP or equivalent public design artifact exists and narrows the proposal scope |
| Voting | A public voting surface and proposal identifier exist, and votes can be recorded |
| Queued | The decision has passed the vote stage and is waiting for its governed execution step |
| Executed | The proposal has moved through the public decision path and the execution evidence is available |
Public evidence to record
| Artifact | Why it matters |
|---|---|
| forum thread URL | proves which discussion thread is canonical |
| DIP or formal proposal URL | proves the mature proposal text readers should evaluate |
| proposal ID or election identifier | keeps wallet actions tied to the intended governance item |
| vote, queue, and execute transaction hashes | proves the public state transition rather than relying on screenshots or summaries |
Voting and delegation surfaces
| Action | Public reference rule |
|---|---|
| delegate voting power | use the DDX token delegation flow and verify the new delegate relationship after confirmation |
| vote on a proposal | verify the proposal identifier, wallet, and voting window before signing |
| vote in an election | verify that the election thread and voting surface refer to the same candidate slate and window |
| inspect governance contract surfaces | use the public contract map in Smart Contract Addresses and Core Contract Reference |
Governance decision families
| Decision family | Public routing rule |
|---|---|
| general parameter or policy changes | start from forum discussion, then follow the formal proposal path when it exists |
| Security Council elections | use the public election thread and vote surface; do not assume private vetting steps are part of the public docs contract |
| asset-listing proposals | treat listing changes as governance-routed requests that must include market, pricing, and risk references |
Public boundaries that matter
| Boundary | Public contract |
|---|---|
| discussion vs. execution | a forum thread alone is not execution evidence |
| public governance vs. private operations | public docs explain the decision path, not private implementation or review procedures |
| current deployment vs. timeless guarantees | active governance routes and contract addresses remain environment- and deployment-dependent |