Governance
Specter uses the Cosmos SDK x/gov module for on-chain governance. GHOST token holders and validators participate in protocol-level decisions through proposals and voting, with the validator set serving as the current governance authority.
Governance Mechanism
The Cosmos SDK governance module provides a structured process for protocol changes:
-
Deposit Period: A governance proposal is submitted with an initial deposit. Other token holders can add to the deposit. If the minimum deposit is not reached within the deposit period, the proposal is discarded.
-
Voting Period: Once the deposit threshold is met, validators and delegators vote. Each validator's voting power is proportional to their staked GHOST.
-
Tallying: After the voting period, the votes are tallied. The proposal passes if quorum is met and a majority votes yes. Failed proposals may result in deposit burning (to deter spam).
-
Execution: Passed proposals are executed automatically by the Cosmos SDK runtime -- parameter changes take effect immediately.
What Governance Controls
Governance proposals can modify a range of protocol parameters and configurations:
Ghostmint Precompile Authorization
| Parameter | Current Value | Governance Can Change |
|---|---|---|
Authorized callers for mintNativeTo / burnNativeFrom | NativeAssetHandler (0x35cd...02b7) | Add or remove authorized callers via chain upgrade |
| MaxMintSupply | 1 billion GHOST (10^27 aghost) | Requires code change + chain upgrade (not a runtime parameter) |
Adding new authorized callers to the ghostmint precompile requires a chain upgrade proposal. This controls which contracts can mint and burn GHOST tokens.
Policy Registry
The PolicyRegistry contract is permissionless (anyone can register a policy), but governance can:
- Deploy updated versions of reference policy contracts
- Recommend specific policies for ecosystem use
- Fund audits of policy contracts
Contract Upgrades
Key protocol contracts can be upgraded through governance:
| Contract | Upgrade Mechanism |
|---|---|
| ProofVerifier | Owner (governance-controlled) deploys new verifier, vault points to it |
| CommitRevealVault | New vault deployed, NativeAssetHandler updated to authorize it |
| CommitmentTree | New tree deployed, vault configured to use it |
| NullifierRegistry | New registry deployed, vault configured to use it |
Contract upgrades are coordinated through governance proposals that include the new contract addresses and the sequence of ownership transfers required.
Staking Parameters
| Parameter | Description |
|---|---|
| Minimum self-delegation | Minimum GHOST a validator must stake |
| Unbonding period | Time validators must wait after unstaking |
| Maximum validators | Size of the active validator set |
| Slashing conditions | Penalties for double-signing and downtime |
Chain Upgrades
Binary upgrades (new node software versions) are coordinated through governance:
- Proposal specifies the upgrade name and block height
- Validators vote to approve
- At the specified block height, nodes halt and await the new binary
- Validators upgrade their software and restart
- Consensus resumes with the new version
This process enables protocol evolution (new modules, new precompiles, circuit upgrades) without hard forks.
Current Governance Structure
Specter's current governance authority is the consensus of validators. Validators vote on proposals proportional to their staked GHOST, including delegated stake. This is the standard Cosmos SDK governance model.
| Aspect | Current State |
|---|---|
| Who votes | Validators + delegators (via their validators) |
| Voting power | Proportional to staked GHOST |
| Proposal deposit | Required (prevents spam) |
| Execution | Automatic via Cosmos SDK runtime |
| On-chain enforcement | Parameter changes take effect at end of voting period |
Future Governance Evolution
The governance structure is designed to evolve as the protocol matures:
Community DAO
A future governance layer may introduce a dedicated DAO structure with:
- Token-weighted voting for protocol parameters
- Council elections for operational decisions
- Treasury management for ecosystem funding
- Grant programs funded by governance-allocated GHOST
Protocol Evolution
Governance will be the mechanism for major protocol transitions:
| Phase | Governance Role |
|---|---|
| Scaling rollout | Approve deployment of BatchCommitRevealVault, SessionVault, ShardedTreeRegistry |
| Runner network | Set runner staking requirements, slashing parameters, shard assignments |
| Circuit upgrades | Approve new ZK verifier contracts with updated circuit parameters |
| Cross-chain expansion | Configure IBC channels and cross-chain commitment bridging |
Decentralization Timeline
The protocol follows a progressive decentralization model:
- Current: Core team operates initial validator set; governance proposals require validator consensus
- Near-term: Open validator set with permissionless staking; community proposals enabled
- Medium-term: DAO structure with elected council and treasury
- Long-term: Fully decentralized governance with minimal core team involvement
Each transition is itself governed by a governance proposal, ensuring the community has a say in every step of the decentralization process.