Governance
Your voice matters. Specter is governed by its token holders — not a boardroom, not a foundation, not a multisig with five keys. If you hold GHOST, you have a direct say in how the protocol evolves.
How It Works
Specter uses the Cosmos SDK governance module, a battle-tested system that's governed billions of dollars across the Cosmos ecosystem. The process is straightforward:
The Governance Lifecycle
Governance Parameters
| Parameter | Value |
|---|---|
| Proposal deposit | 10,000 GHOST |
| Voting period | 7 days |
| Quorum | 33.4% of staked GHOST |
| Pass threshold | 50% + 1 of votes |
| Veto threshold | 33.4% of votes |
| Execution timelock | 48 hours |
1. Proposal Created — Any GHOST holder can submit a governance proposal by depositing 10,000 GHOST. This could be a protocol upgrade, a parameter change, a treasury spend, or a text proposal signaling community intent.
2. Deposit Period — After submission, the proposal enters a deposit period. Other GHOST holders can add deposits to show support. Think of it as a spam filter — proposals need enough backing to prove they're serious.
3. Minimum Deposit — If the deposit threshold is met, the proposal advances to voting. If not, the proposal is rejected and deposits may be returned or burned depending on the outcome.
4. Voting Period — All staked GHOST holders (validators and delegators) can vote during a 7-day voting window. Four options:
| Vote | Meaning |
|---|---|
| Yes | Support the proposal |
| No | Oppose the proposal |
| No with Veto | Strongly oppose — if 33.4% of votes are veto, deposits are burned |
| Abstain | Counted toward quorum but not toward the yes/no outcome |
5. Quorum + Majority — For a proposal to pass, 33.4% of staked GHOST must vote (quorum), and more than 50% of those votes must be "Yes."
6. Timelock — Passed proposals enter a 48-hour timelock before execution. This gives validators, delegators, and the community time to prepare for changes and provides a window to detect issues before they take effect.
7. Execution — After the timelock, proposals are executed automatically by the chain. For parameter changes, the new values take effect immediately. For upgrades, the chain schedules the upgrade at a specified block height.
What Can Be Governed?
Almost everything that matters:
- Protocol upgrades — New features, bug fixes, consensus changes
- Parameter changes — Gas pricing, staking parameters, governance thresholds
- Treasury allocation — Funding grants, ecosystem initiatives, partnerships
- Bridge configuration — Adding new bridge routes, adjusting bridge parameters
- Policy registry — Approving or flagging reveal policies
Foundation & Emergency Multisig
While governance is the primary decision-making mechanism, the protocol includes a 5-of-9 Foundation multisig for security-critical situations only.
Scope: The multisig can act only on security-critical matters — pausing bridge contracts during an exploit, emergency parameter changes to prevent fund loss, or coordinating responses to consensus failures. It cannot spend treasury funds, change tokenomics, or override governance decisions.
Dissolution: The Foundation multisig is designed to be dissolved at Month 24 after mainnet launch. By that point, the validator set and governance participation should be mature enough to handle emergency responses through expedited governance proposals. The dissolution itself is subject to a governance vote.
Transparency: All multisig actions are logged on-chain, and every action must be accompanied by a public post-mortem within 7 days explaining what happened, why the multisig acted, and what preventive measures are being implemented.
Foundation Treasury
The Foundation Treasury holds 90 million GHOST (9% of genesis supply) as a DAO-controlled reserve for long-term protocol needs.
- Governance-controlled — Every spend from the Foundation Treasury requires a governance proposal that passes the standard voting process
- Quarterly reporting — The Foundation publishes quarterly reports detailing treasury balance, spending, and allocation decisions
- Long-term reserve — Designed for strategic needs that emerge over time: security audits, legal defense, emergency funding, and opportunities that don't fit neatly into the Ecosystem & Grants Fund
The Foundation Treasury is distinct from the Ecosystem & Grants Fund (18% of genesis). The Grants Fund is for active ecosystem building — developer grants, hackathons, partnerships. The Treasury is the protocol's rainy-day fund, deployed sparingly and only with community approval.
Delegation and Voting
If you've delegated your GHOST to a validator, your validator votes on your behalf by default. But you can always override — casting your own vote takes precedence over your validator's vote for your portion of the stake.
This means you don't have to actively monitor every proposal if you trust your validator's judgment. But when something matters to you, your vote counts.
Why On-Chain Governance?
Off-chain governance (forum posts, multisig votes, social consensus) works for some projects. But it concentrates power in whoever controls the communication channels and the keys.
On-chain governance is transparent, verifiable, and permissionless:
- Anyone can propose
- Anyone who stakes can vote
- Votes are recorded on-chain
- Execution is automatic (after timelock)
No gatekeepers. No backroom deals. Just token holders making decisions about their protocol.