Decisions that change how a settlement layer behaves cannot be announcements. If a protocol version can advance, a validator can be admitted or a policy can change by a message from the operator, then the settlement guarantees the layer offers are only as durable as the operator's intentions. SWSS governance moves those decisions on chain, where a proposal, every vote cast and the address that cast it are permanently recorded and readable through SWSS Explorer.

Voting rights belong to NodeX validators holding SWSS Coin. That pairing is deliberate: validator status is credential-gated and admitted by proposal, while stake secures voting weight among validators — so influence follows a verified operator with a committed position rather than an anonymous balance. Stake gives weight to validators; it does not create them, which is what prevents governance being acquired outright.

Governance runs on SWSS Chain itself under the same consensus and the same finality as a deed settlement. A governance action is therefore as irreversible and as auditable as a property transfer, and the sequence from proposal to vote to enactment is readable end to end — there is no step where a decision leaves the record and reappears as a statement.

Live On Both Networks

Governance is deployed and in use on SwssChain mainnet 122605 and on the SwssChain testnet 122606. Both carry their own governance contract with its own proposal history, so a change can be rehearsed on the testnet under the same rules that will govern it in production rather than tested by argument. The testnet is a rehearsal of the mechanism, not a reduced version of it.

Quorum thresholds, voting windows and the veto period are configured per network and readable from the governance contract on each. They are deliberately not restated here: a parameter written into a document is a parameter that can fall behind the one actually enforced, and the contract is the thing that enforces it.

Governance In Practice

The clearest evidence that this mechanism is real is the protocol the network is running. The consensus version live on mainnet today — SCP v3.1.4 — was not deployed by decision and announced afterwards. It was proposed on chain, voted on by the validator set, and executed as proposal 17 on 15 August 2026, with the execution recorded in a transaction anyone can look up. The version before it arrived the same way, as the proposal preceding it.

That is the difference between governance as a stated intention and governance as the route by which the software actually changed. A reader who wants to test the claim does not have to take this section's word for it: the proposal, the vote, the execution block and the resulting version are all on chain, and the version the network reports can be compared against the proposal that authorised it.

Validator admissions follow the same path. A validator does not appear in the registry because the Foundation added it; it appears because a proposal admitting it passed, and the block that happened in is stored on the validator record. The composition of the set that secures settlement is therefore auditable in the same way the protocol version is — by reading the decisions that produced it rather than the summary of them.

Governance Mechanics

type                   VALIDATOR_ADMISSION  # one of the enumerated types
subject                the institution admitted
quorumThreshold        read from the contract  # per network, never from a document
votingWindow           read from the contract
vetoWindow             read from the contract
votesCounted           one institution, one vote  # never weighted by holding
state                  executed
record                 permanent  # cannot be revised after the fact

The Foundation operates the genesis validators and can propose, but it cannot decide privately: the record of who voted for what is public either way, and a proposal that passes is enacted as a chain event rather than as a release note.

Where Validators Vote

Governance is not a separate destination. It ships as a module inside SWSS NodeX and is live there today: a validator opens the governance page in the NodeX portal, reads the open proposals, and casts a vote through the same interface used to manage the node. That is why this product is described as on-chain governance within NodeX rather than as a platform of its own — the people entitled to vote are already operating validators, and asking them to hold a second login to exercise the right would add a step without adding a safeguard.

The voting path is deliberately two-stage. A vote is prepared and then confirmed, so the transaction a validator signs is the transaction they reviewed, and signing authority stays with the validator rather than with the portal. What reaches the chain is the validator's own signed action; NodeX presents the proposal and relays the result.

The governance contract itself is deployed on SWSS Chain mainnet and carries a proposal history that predates this page. That history is readable from the chain rather than restated here — a count written into a document is stale the next time a proposal is opened, and the registry never is. Anyone can read the proposals, the votes and the addresses that cast them through SWSS Explorer.