Governance & Network Parameters
Governance in the Sova Network exists to coordinate upgrades, validator participation, and economic alignment — without compromising the network’s Bitcoin-anchored integrity. It is designed for minimal intervention: governance cannot modify or override consensus rules that link Sova to Bitcoin.
Instead, its role is limited to managing configuration parameters, validator onboarding, and the long-term decentralization roadmap.
Governance Philosophy
Sova governance is built on three foundational principles:
Determinism over discretion – Protocol correctness is algorithmic, not subject to votes.
Transparency over trust – All governance actions are executed and logged on-chain.
Progressive decentralization – Governance power transitions from the core multisig to a distributed validator DAO as the network matures.
These principles ensure that governance serves the protocol — not the other way around.
Governance Structure
Sova’s governance is composed of three main entities:
Entity
Function
Composition
Governance Multisig (Gen-0)
Interim operator managing protocol upgrades and parameter changes.
3–5 signers from Sova Labs & ecosystem partners.
Validator Council
Collective of active validators responsible for network security and coordination.
All active validators meeting staking and uptime thresholds.
SOVA DAO (Future)
Fully decentralized governance system controlling parameters, treasury, and validator registry.
Token-based or reputation-weighted voting.
Transition from the Governance Multisig to the DAO will occur once the validator network reaches a decentralized quorum and operational stability is proven.
On-Chain Governance Contracts
Sova uses a suite of governance contracts deployed directly on the network:
Contract
Purpose
NetworkParams.sol
Stores configurable parameters such as Bitcoin confirmation thresholds, gas multipliers, and lock expiry durations.
ValidatorRegistry.sol
Manages validator enrollment, slashing, and reward distribution.
UpgradeManager.sol
Coordinates protocol and client upgrades via the UUPS proxy pattern.
Treasury.sol
Receives protocol fees and distributes them for $SOVA buybacks, grants, or validator rewards.
All governance actions are executed as on-chain transactions — no off-chain votes or opaque council decisions.
Network Parameters
The following parameters define Sova’s operational policy and can be modified only through governance proposals:
Parameter
Default Value
Purpose
bitcoinConfirmationsRequired
6
Minimum confirmations for deposit finality.
lockExpirationBlocks
18
Number of Bitcoin blocks before unconfirmed locks expire.
lockRevertThreshold
21
Bitcoin block threshold for reverting expired locks.
maxReorgDepth
3
Maximum Bitcoin reorg depth tolerated before rollback.
checkpointInterval
100
Blocks between optional Ethereum state checkpoints.
feeCollector
0x...
Address collecting protocol fees.
sequencerBond
100,000,000 SOVA
Minimum bond for sequencer participation.
Parameter Modification Workflow
Proposal submitted via
NetworkParams.proposeChange().Validator Council reviews and approves through multi-sig or DAO vote.
Proposal executed automatically after delay window (default: 48 hours).
All changes emitted as on-chain events and logged for audit.
Example:
event ParameterUpdated(string indexed name, uint256 newValue, uint256 timestamp);Validator Governance
Validators are the operational core of the network. Their governance structure balances performance incentives with accountability.
Validator Registry
Onboarding: Validators register by staking $SOVA and linking a Bitcoin Core node endpoint.
Duties: Maintain uptime, process transactions, validate anchors, and participate in consensus.
Rewards: Earn transaction and protocol fees proportional to contribution.
Penalties: Slashed for downtime, incorrect anchor data, or malicious behavior.
Validator Lifecycle
Apply → Stake → Validate → Earn Rewards → (Optional) UnstakeValidator Governance Events
event ValidatorRegistered(address indexed validator, string btcNodeEndpoint);
event ValidatorSlashed(address indexed validator, uint256 amount);
event ValidatorUnstaked(address indexed validator);The validator set evolves dynamically based on stake, uptime, and governance rules.
Upgrade Management
Upgrades are handled through the UpgradeManager.sol contract, which supports the UUPS upgrade pattern for modular and transparent improvements.
Upgrade Process
Developer proposes new implementation contract.
Governance Multisig or DAO approves via proposal vote.
Upgrade executed on-chain with verifiable event log.
Previous implementation remains accessible for rollback if necessary.
Upgrade Event
event ImplementationUpgraded(address indexed newImplementation, uint256 timestamp);Upgrade Safeguards
Upgrades can only be authorized by governance-approved addresses.
Timelocks ensure at least 48-hour notice before activation.
Sentinel modules validate that upgrades do not alter Bitcoin-related logic.
Treasury & Economic Policy
The Treasury contract collects protocol fees and redistributes them to strengthen the ecosystem and maintain economic alignment.
Sources of Revenue
Gas and transaction fees from SovaEVM.
Small percentage of yield from Sova Prime vaults.
Sequencer and validator participation fees.
Use of Funds
$SOVA Buybacks: Burn or repurchase from open market to reduce supply.
Grants & Incentives: Funding ecosystem builders or partnerships.
Validator Rewards: Support network participation and uptime.
Operational Buffer: Treasury reserve for emergencies.
All Treasury operations are public, traceable, and verifiable on-chain.
Governance Process Lifecycle
1. Proposal Created → Describes parameter or upgrade change
2. Validation → Technical review by Governance Council or DAO members
3. Vote Period → Default: 48-72 hours
4. Execution → If quorum reached, change enacted automatically
5. Audit Log → All events stored on-chain and indexed for monitoringGovernance Events
event ProposalCreated(uint256 indexed id, address proposer, string description);
event ProposalExecuted(uint256 indexed id, uint256 timestamp);
event ProposalRejected(uint256 indexed id, string reason);This structure ensures transparent, verifiable decision-making throughout the network’s lifecycle.
Decentralization Roadmap
Sova’s governance will evolve in three progressive phases:
Phase
Controller
Description
Phase 1 – Genesis
Governance Multisig
Controlled by Sova Labs; ensures stability during bootstrapping.
Phase 2 – Validator Council
Validator quorum
Validators gain voting rights for parameter changes and upgrades.
Phase 3 – DAO Transition
SOVA DAO
Full decentralization with token-weighted voting and on-chain proposal execution.
Transition milestones are determined by validator count, uptime, and total sovaBTC locked.
Immutable Rules
Certain protocol rules are immutable — governance cannot modify or override them under any circumstance:
Bitcoin anchoring and validation logic.
Finality thresholds tied to Bitcoin confirmations.
Bridgeless mint/burn mechanics for sovaBTC.
Deterministic replay and audit functions.
No emergency powers that bypass Bitcoin verification.
These rules form the Constitution of the Sova Network — ensuring its independence, even as governance evolves.
Summary
Sova governance manages parameters and upgrades, not protocol truth.
Validators are the enforcement layer; governance provides coordination.
All actions occur on-chain with transparent event logging.
Bitcoin-related invariants remain immutable.
Governance decentralizes progressively, with SOVA DAO as the final stage.
Next → System Component Summary & Integration
Explore how all components — from sovaBTC to Sentinel to Governance — interconnect in a unified architecture, creating a Bitcoin-secured, EVM-programmable treasury network.
Last updated