SV Governance

Governance model, voting and proposals, and Super Validator responsibilities

The Global Synchronizer is governed by a decentralized collective of Super Validators (SVs) through on-ledger governance mechanisms. Canton Coin, the Canton Name Service, and synchronizer configuration are all managed through this governance model, implemented in the splice-dso-governance Daml package.

The DSO party

At the center of governance is the DSO party — a decentralized Daml party hosted on all SV nodes with a confirmation threshold of ceiling(numSvNodes * 2/3). Any action taken “by the DSO” requires confirmation from at least 2/3 of the SV nodes.

The implementation uses three key techniques to achieve this Byzantine fault tolerance:

• DSO party: it sets up a decentralized Daml party, called the DSO party, with confirmation threshold t and hosted on all SV nodes.
• on-ledger confirmations: it requires explicit on-ledger confirmations from t SV nodes for exercising choices with off-ledger input in the name of the DSO party.
• decentralized automation: all SV nodes run automation code that attempts to exercise choices required to be executed by the DSO party.
• median-based voting: agreement on conversion rates and like configuration parameters is achieved using median-based voting, where every SV operator publishes their desired value on-ledger and the DSO party uses the median of these values.

What the governance model guarantees

Users who are willing to assume that no more than f SV nodes are dishonest (where f = numSvNodes - t) can rely on:

• Valid transactions — Every transaction requiring DSO confirmation follows the Daml ledger integrity model
• Timely automation — Actions required by the DSO party are executed promptly
• Predictable fees and configuration — Fees and parameters represent the aggregate preferences of roughly 2/3 of SV operators, who can be assumed to act in their own interest

Governance actions

Super Validators govern the network through several mechanisms:

On-ledger voting

SVs vote on proposals through the SV web UI under the Governance tab. Proposals that receive confirmation from the required threshold of SVs are executed. Examples include:

• Updating SV reward weights
• Featuring or unfeaturing application providers (granting or revoking FeaturedAppRight)
• Changing the AmuletRules configuration schedule (fee parameters, traffic pricing)
• Withdrawing a ValidatorLicense

Median-based parameter voting

For continuously changing parameters like the USD-to-CC conversion rate, each SV operator publishes their preferred value on-ledger. The DSO party uses the median of all published values. This prevents any single SV from disproportionately influencing the rate while still reflecting the collective judgment of the SV operators.

The conversion rate set through this mechanism is written to OpenMiningRound contracts and used as the reference rate for traffic purchases and CC transfers.

Decentralized automation

All SV nodes run the same automation code. Choices that do not require off-ledger input are exercised directly by the DSO party. Choices that require off-ledger input (such as transitioning a mining round to its issuing phase) are exercised indirectly — each SV creates an on-ledger confirmation, and the choice executes once the threshold is met.

The automation keeps the system running: advancing mining rounds, converting FeaturedAppActivityMarker contracts into AppRewardCoupon contracts, expiring old coin contracts, and archiving expired CNS entries.

SV responsibilities

Each Super Validator is responsible for:

• Operating infrastructure — Running sequencer, mediator, SV app, Scan app, and validators
• Governance participation — Voting on proposals, publishing conversion rate preferences, reviewing CIPs
• Validator onboarding — Generating onboarding secrets for new validators that want to join the network
• Fee configuration — Jointly ensuring synchronizer traffic parameters are sound and aligned with network objectives
• Monitoring — Tracking traffic consumption, reward expiry, and overall network health
• Upgrades — Keeping pace with network upgrades and ensuring the reward expiry automation runs correctly across Daml package upgrades

Daml package structure

The governance-related Daml packages are:

• splice-dso-governance — Implements Global Synchronizer governance and decentralized CC/CNS automation
• splice-validator-lifecycle — Implements workflows for SV nodes to onboard validators
• splice-amulet — Implements CC (the DSO party requirements for honest behavior are defined against this package)
• splice-amulet-name-service — Implements CNS

All packages other than splice-dso-governance and splice-validator-lifecycle are written under the assumption that the DSO party behaves as an honest provider. This separation of concerns simplifies the codebase — decentralization logic is contained in the governance package, while business logic focuses on correctness under an honest-DSO assumption.

How upgrades work

Network upgrades — including Daml package upgrades — are coordinated through the governance process. SVs vote on configuration changes that schedule upgrades. Once a vote passes, all SV nodes apply the change through their automation.

During Daml package upgrades, the reward expiry automation (ExpireRewardCouponsTrigger) may need temporary adjustments if some validators have not yet upgraded to a sufficiently recent Splice version. SV operators may need to pause the trigger, determine which party IDs to exclude, and resume with an exclusion list until all validators catch up.

Validators that fall behind on upgrades may have their reward coupons excluded from expiry processing, which can block the archival of closed mining rounds. Keep your validator current with network versions.