Scope note
This page is the public lookup surface for what a DerivaDEX governance proposal should include and what the on-chain proposal machinery requires. It does not publish a private governance review checklist or a hidden internal approval form.Public proposal artifact set
| Artifact | Why it matters |
|---|---|
| canonical forum thread URL | identifies the public discussion surface |
| DIP or formal design link when available | identifies the mature specification or implementation-linked design artifact |
| problem statement | tells readers what is being changed and why |
| proposed change | tells readers what action or policy change is actually being requested |
| public mechanism references | ties the proposal to the current public docs rather than historical assumptions |
| implementation links when applicable | lets readers inspect code, merge requests, or execution notes connected to the proposal |
Minimum public thread content
| Topic | Public expectation |
|---|---|
| title | states the change plainly rather than using an ambiguous discussion title |
| scope | identifies the affected market, contract surface, policy area, or user group |
| expected outcome | states what should be different if the proposal succeeds |
| stage | makes clear whether the thread is early discussion, DIP-bound, or already paired with execution work |
| next-step path | tells readers whether the thread is expected to advance to a DIP, on-chain vote, or implementation follow-up |
Public reference requirements
| If the proposal affects… | Link these public routes |
|---|---|
| trading rules, safeguards, or liquidation behavior | Trading Safeties and Guards and Margin Requirements |
| price inputs, mark-price behavior, or funding | Price Feeds and Mark Price Inputs and Funding Rate Logic |
| governance mechanics or voting thresholds | Governance Mechanics and Voting Threshold Reference |
| contract or upgrade surfaces | Smart Contract Addresses and Core Contract Reference and Smart Contract Facet, Selector, and Event Reference |
| operating posture or public-boundary changes | Regulatory and Compliance Approach and For Governance and Compliance |
On-chain proposal action constraints
| Constraint | Public contract |
|---|---|
| proposer threshold | proposer must be above the current proposing threshold |
| action parity | targets, values, signatures, and calldatas must stay length-matched |
| action minimum | zero-action proposals revert |
| action maximum | more than 10 actions revert |
| one-live-proposal rule | one proposer cannot keep more than one live proposal at a time |
Evidence to keep after posting
| Evidence | Why it matters |
|---|---|
| forum thread URL | preserves the discussion anchor |
| DIP URL when applicable | preserves the formal design anchor |
| proposal ID | preserves the on-chain identity once the proposal exists on-chain |
| vote, queue, and execute transaction hashes | preserves state-transition evidence for later review |
Template boundary
| Topic | Public status |
|---|---|
| fixed markdown template | not currently published as a mandatory first-class public docs artifact |
| requirements reference | this page states the public minimums that proposals should satisfy |
| internal governance review forms | not published on this Mintlify surface |