Why governance is split across multiple public surfaces
DerivaDEX governance is not one page, one transaction, or one actor. Public governance work is spread across discussion, proposal design, voting, and later execution because each stage answers a different question:- discussion asks whether a change should happen
- formal proposal text asks what exactly is being changed
- voting asks whether the governed community approves that change
- execution asks whether the approved change has actually been carried out
The public actor model
Public governance surfaces usually involve several distinct actors:- proposers who frame the change and gather the first references
- token holders and delegates who supply voting power
- reviewers who compare the proposal against public safety, market, and contract references
- executors or implementation owners who move an approved change into the governed execution path
Why Security Council and governance are documented carefully
Security-sensitive governance functions need especially clear boundaries. Public readers need to understand that Security Council elections, emergency powers, and execution-sensitive roles matter, but they do not need a private operating manual. That is why the public docs document:- how public election participation works
- where to find the public decision context
- how Security Council topics fit into the broader governance story
- internal vetting steps
- unpublished operational procedures
- private escalation and response workflows
Why listing decisions are governance questions, not only market questions
A new listing affects much more than symbol availability. It changes pricing inputs, liquidation behavior, monitoring expectations, and user risk posture. That is why listing proposals belong in governance discussion as well as product reference. Public docs therefore need two layers:- reference pages that explain the current pricing, market, and safeguard model
- governance routes that explain how a proposed listing enters the public decision path
Governance and compliance are linked on purpose
DerivaDEX documentation treats governance and compliance as connected concerns because public trust depends on both:- governance explains who can approve meaningful platform changes
- compliance and safety explanations show why some surfaces remain bounded or restricted
- public references explain the concrete limits, safeguards, and contract surfaces those decisions affect
How to read the governance docs correctly
If you need to act, start with a tutorial or how-to guide. If you need facts, move to reference. If you need to understand why the governance model is split across public and bounded surfaces, use this page first.Sources
- Governance Process and Public Decision Reference for the public process stages and decision objects
- Governance Mechanics and Voting Threshold Reference for voting-power and approval mechanics
- Governance Proposal Templates and Requirements for proposal-shape expectations
- DDX Token Specifications for delegation, voting checkpoints, and token-linked governance mechanics
- Community Resources for the public forum and DIP surfaces that carry the discussion-to-proposal lifecycle
- For Governance and Compliance for the public operating-context and governance-routing entrypoint