Bootstrap Network

SV operations, network bootstrapping, identity management, and reward configuration

This page covers operational procedures for Super Validator (SV) nodes: managing identities, onboarding validators, configuring rewards, and bootstrapping new networks.

SV Node Identities

This section was adapted from existing reviewed documentation. Source: sv_operator/sv_operations.rst Reviewers: Skip this section. Remove markers after final approval.

An SV node involves several distinct identities across different layers:

• SV identity — An EC keypair (prime256v1) that identifies the SV operator. Stable across network resets and redeployments. Generated during initial setup (see Kubernetes Deployment).

• Participant identities — Automatically generated by the Canton participant node on first startup. These are specific to a particular deployment and are not reused across network resets.

• CometBFT node identities — The node key and validator key used by the CometBFT consensus layer. These identify your node within the BFT ordering protocol.

Security Notice

This section was adapted from existing reviewed documentation. Source: sv_operator/sv_operations.rst Reviewers: Skip this section. Remove markers after final approval.

An SV node operator must review any Daml code (DARs) installed on their participant node. Third-party Daml apps running on the same participant can interact with the Splice Daml models and potentially trigger unintended behavior. Only install DARs from trusted sources, and audit all third-party code before deployment.

Generating Validator Onboarding Secrets

This section was adapted from existing reviewed documentation. Source: sv_operator/sv_operations.rst Reviewers: Skip this section. Remove markers after final approval.

To onboard a new validator to the network, an SV generates an onboarding secret that the validator operator uses during their initial setup. The onboarding secret is a one-time credential that authorizes the new validator to connect to the Global Synchronizer.

The SV web UI provides an interface for generating these secrets. Each secret is single-use and should be transmitted securely to the validator operator.

Reward Weight Configuration

This section was adapted from existing reviewed documentation. Source: sv_operator/sv_operations.rst Reviewers: Skip this section. Remove markers after final approval.

Each SV has a configurable reward weight that determines its share of minted Canton Coin rewards. Reward weights are set through the DSO governance process — changes require approval from a threshold of SVs.

To update your SV’s reward weight, submit a proposal through the SV governance mechanism. The proposal must specify the new weight and requires sufficient votes from other SVs before it takes effect.

Synchronizer Traffic Parameters

This section was adapted from existing reviewed documentation. Source: sv_operator/sv_operations.rst Reviewers: Skip this section. Remove markers after final approval.

SVs collectively determine the traffic parameters for the Global Synchronizer. These parameters control the cost of ledger transactions in terms of Canton Coin.

Key parameters include:

• Read vs. write scaling factors — The relative cost of read operations versus write operations on the synchronizer
• CC transfer costs — The base cost for transferring Canton Coin between parties
• Traffic price — The per-byte cost for transaction data processed by the synchronizer

Changes to traffic parameters require governance proposals and approval from a threshold of SVs. Monitor the Scan API or SV web UI for current parameter values.

Bootstrapping a New Network

Bootstrapping a new Global Synchronizer deployment requires coordination among the founding SVs. The process establishes the initial network state, including the genesis configuration and initial governance parameters.

Process Overview

1. Agree on genesis configuration — Founding SVs agree on initial parameters: network name, initial reward weights, traffic parameters, and governance rules
2. Generate SV identities — Each founding SV generates their identity keypair
3. Exchange identity information — SVs share their public keys and desired SV names
4. Configure CometBFT genesis — Create the CometBFT genesis file with all founding validators
5. Deploy nodes — Each SV deploys their node with the agreed genesis configuration
6. Verify network operation — Confirm that BFT consensus is operational and the synchronizer is processing transactions

Helm Values for Bootstrap

This section was adapted from existing reviewed documentation. Source: splice/apps/app/src/pack/examples/sv-helm/sv-values.yaml Reviewers: Skip this section. Remove markers after final approval.

The release artifacts bundle includes example Helm values for each component. The SV values file configures the core SV identity and network connections:

onboardingName: YOUR_SV_NAME
nodeIdentifier: YOUR_SV_NAME
decentralizedSynchronizerUrl: "https://sequencer-MIGRATION_ID.sv-2.TARGET_HOSTNAME"
auth:
  audience: "OIDC_AUTHORITY_SV_AUDIENCE"
  jwksUrl: "https://OIDC_AUTHORITY_URL/.well-known/jwks.json"
cometBFT:
  enabled: true
  connectionUri: "http://global-domain-MIGRATION_ID-cometbft-cometbft-rpc:26657"
scan:
  publicUrl: "https://scan.sv.YOUR_HOSTNAME"
  internalUrl: "http://scan-app.sv:5012"
domain:
  sequencerAddress: "global-domain-MIGRATION_ID-sequencer"
  mediatorAddress: "global-domain-MIGRATION_ID-mediator"

Separate Helm values files configure the CometBFT, participant, global domain (sequencer + mediator), Scan, and validator components. Refer to the release artifacts bundle for the full set of example values.

Infrastructure Considerations

• Quorum requirements — The network requires at least 2f+1 SVs online for consensus, where f is the maximum number of faulty SVs tolerated
• Geographic distribution — Distribute SVs across regions for resilience
• Network connectivity — All SVs must be able to reach each other’s sequencer endpoints
• Time synchronization — Ensure NTP is configured on all nodes for consistent timestamps

Running a Hard Domain Migration (HDM)

In rare cases, the Global Synchronizer may need a hard synchronizer migration — replacing the existing synchronizer with a new one while preserving the application state. This corresponds to a Type 3 upgrade as described in Deployment Progression. HDMs are triggered by protocol-level changes that cannot be applied through standard upgrade procedures.

The migration preserves the active contract set (ACS) while creating a new synchronizer with updated protocol parameters. HDMs require coordination among all SVs and increment the migration ID. See Upgrade Procedures for the operational steps.

Next Steps

• Kubernetes Deployment — Detailed SV node deployment guide
• Upgrade Procedures — Upgrading SV nodes
• Security Operations — Hardening and key management