Governance defines who can propose and authorize supported network or administrative changes, how competing interests are resolved, and what evidence surrounds execution. It is an institutional operating model expressed through configured roles and rules, not a shortcut around internal approval or a universal unrestricted administrator.
The platform supports administrative, democratic, and hybrid governance approaches. The institution chooses the appropriate authority, thresholds, voting population, delays, and responsibilities. Validator admission and removal, mutable parameters, and upgrades must be considered alongside routine policy changes, while Chain ID remains fixed after network creation.
Define authority before choosing a model
Start with a responsibility map: who may submit a proposal, who can approve it, which threshold is required, who executes an approved action, and who independently reviews the result. Separate duties where institutional policy calls for it. Record the scope of each role and how access is maintained, reviewed, and changed through the institution’s process.
Governance applies to supported actions within the configured system; it does not determine the bank’s legal obligations, customer policy, or internal authorization outside that system. Clarify which network settings are mutable, which actions require a coordinated software upgrade, and which operational decisions remain with the institution even when a service provider assists.
Governed changes connect proposal, approval, and execution
- ProposalAn authorized participant submits a scoped change for consideration.
- Voting or approvalsConfigured participants apply thresholds and quorum rules.
- Delay or reviewApplicable waiting period and review responsibilities are observed.
- ExecutionThe approved action runs within its assigned permissions.
- Audit and reconcileOperators inspect the result and retain institutional evidence.
Administrative, democratic, and hybrid models
Administrative governance uses an authorized council and configured multi-approval rules. The institution defines its administrator roster, proposal authority, threshold, permissions, and applicable delays. This model can align with established delegated decision-making, but it still requires clear role ownership, access review, separation of duties, and a defined response when an approver is unavailable.
Democratic governance uses a configured voting population and policy for weights, proposal thresholds, voting period, quorum, and execution. Hybrid governance combines administrative and voting paths according to configured rules, including whether either side or both sides must approve. Equal voting rights, delegation behavior, or a particular outcome should not be assumed unless the deployed policy states it.
Govern validators and immutable network identity
Validator participation is a governance and operations concern. Document eligibility, admission and removal authority, permissions, maintenance ownership, monitoring, and incident responsibilities. The configured validator set and supported counts depend on the deployed consensus version and available infrastructure; network expansion is constrained by the agreed design and is not an unlimited capacity promise.
Choose Chain ID before the network is created because it is immutable afterward. This identifier affects application and integration assumptions, so confirm it with relevant teams and environments. Other supported parameters may be governed and can require coordinated software upgrades; plan testing, communication, execution ownership, and recovery considerations for changes that affect network participants.
Match decisions to authority and change characteristics
Admission, removal, permissions, and operating responsibilities follow governance.
Assigned roles use the configured approval and execution path.
Governed change may require review and coordinated execution.
Confirm before creation; it cannot be changed after launch.
Approvals, delays, and operating evidence
Configure proposal thresholds, voting weights, quorum, voting periods, multi-approval requirements, and execution delays to reflect the institution’s approved model. Do not treat a setting as meaningful until the responsible teams understand its effect and can operate it. Define how rejected, expired, or incomplete proposals are handled and who may initiate a new review.
For each change, retain the proposal context, approvals or votes, applicable timing, execution result, and post-change review in the institution’s established evidence process. A pilot can validate configured workflows with approved test cases, while production commitments require separate scope and agreement. Continue to the deployment and security chapters to connect governance with operational controls and recovery planning.