Protocol Changes Are Decided On Chain
Upgrades to SwssChain, admissions to the validator set and changes to protocol policy are proposed, voted and executed through a governance contract deployed on both public networks. Each decision leaves a transaction, so the claim on this page can be checked rather than believed.
A settlement network is only as dependable as the process that changes it. If an upgrade can be applied because somebody with access decided to apply it, every guarantee the network offers is conditional on that person's judgement continuing to be good. Governance replaces the judgement with a procedure, and the procedure leaves evidence.
swss://governance deployedOne Path, Two Networks
A proposal travels the same five states on the testnet and on mainnet
What Governance Decides
Four classes of decision reach the chain through this path. Everything else in the ecosystem is an operational matter, decided by the people accountable for it and subject to the same release gates as any other change.
Protocol Upgrades
The version of the client the network runs is adopted by proposal. An upgrade is not applied because it is ready; it is applied because a proposal carrying it was passed and executed.
reaches the chain as upgrade proposalValidator Admissions And Exits
Who may produce a block is a governance decision rather than an operational one. Admission to the active set is proposed, voted and recorded, so the set's composition has a history anyone can read.
reaches the chain as VALIDATOR_ADMISSION · VALIDATOR_EXITProtocol Policy And Treasury
Parameters that govern the network's economics and movements from the treasury are decided through the same path. No operator, and no entity in the group, changes them by instruction.
reaches the chain as parameter proposalIts Own Rules
The governance contract is upgradeable through governance itself. Changing how decisions are made is a decision made the same way, which is what keeps the process from being edited around.
reaches the chain as governance upgradeHow A Change Reaches The Chain
Five stages, each leaving something a reader can retrieve without asking us. That is the point of publishing a process at all: one that produces no evidence is indistinguishable from an assurance.
swss://proposal-lifecycle5 stagesProposed
A change is submitted to the governance contract, carrying what it does and the artefact it adopts. Submission is a transaction, so the proposal exists on chain before anyone votes on it.
Voted
Members of the active validator set vote within the window the contract defines, each signing in their own wallet. Votes are transactions, so participation is observable rather than reported.
Passed
The contract determines the outcome against its configured rules. A proposal passes or it does not, and the result carries the block and the time it was reached.
Executed
An executed proposal applies the change it carried. Until execution nothing has happened, which is why passing and executing are two facts rather than one.
Observable
The running network reports what it is actually running. Published facts across every SWSS property are read from that rather than from the proposal, so a page and the chain cannot drift apart unnoticed.
note the portal prepares the call, a wallet it does not hold signs it, the contract decides, and the portal reads the result back
Nobody Here Holds A Key That Can Act For You
The portal that operates governance cannot send a transaction. It prepares the call, a wallet we do not hold signs it, and the receipt is verified against the chain before anything is recorded. Three stages, and the middle one happens somewhere we have no reach.
The Portal Builds The Call
The operator asks the portal for an action. It returns the exact call that would be made and a signed intent describing it. Nothing has been sent, and the portal has no means of sending it.
The Wallet Sends It
The transaction is signed in the Foundation's own browser wallet, or for a vote, in the member's IVL wallet. The key never leaves the holder, and no server in this ecosystem has a copy of it.
The Receipt Is Checked Before Anything Is Recorded
The portal verifies the receipt on chain: sent from the Foundation address the governance contract itself reports, to the governance contract, with calldata identical to the intent. Only then is anything written down.
A test fails if a signing key returns
The rule is enforced by the test suite rather than by discipline. If a key finds its way back into the governance code, the build fails before anybody has to notice.
The server held a key once, and that is why
An earlier design read a Foundation signing key from parameter storage and signed server side. It was removed in September 2026, and the constraint above exists so the arrangement cannot quietly come back.
Where Governance Is Operated
Governance is decided by a contract. It is operated through SWSS NodeX, the portal institutional validators use to onboard, bond, run nodes and take part in proposals. The distinction matters: the portal is where the work happens, and the chain is where the decision lives.
Everything NodeX shows about governance is read from the contract rather than maintained by hand. An administrator cannot mark a proposal passed, cannot record one that was never submitted, and cannot make a validator active by editing a row. Those were all possible once, and removing them is why the rules below are written the way they are.
What stays local is policy the chain has no opinion about, such as whether a bond requirement is waived for a particular institution. Anything the chain has an opinion on is read from the chain, every time it is needed.
The portal serves the four validator classes the network runs: Foundation, Institutional, Open and Light. Which class an operator belongs to changes what is asked of them, not how a decision is reached.
The portal is gated, and that is the point
Access requires a verified institution and an SWSS IVL identity, so the portal is not a public site and will ask for sign-in before it shows anything. The public description of what it does lives on the product page.
What An Operator Does Here
The institutional portal, for verified validators
note nothing in this list signs a transaction on an operator's behalf
The Table Follows The Chain
NodeX keeps a local record of proposals so the portal renders quickly, and that record is synchronised from the governance contract on load, on demand, and every five minutes by a worker. The chain is the source; the table is a convenience.
sync · 5 minutesA Mirror Never Gates Anything
No decision is taken against the local copy. The rule is written beside the bond columns in the schema for a concrete reason: a stale mirror reading active would admit a validator the chain has not bonded.
stated in the schemaAdmission Is Dated By The Execution Block
When a validator becomes active, and therefore when tenure and billing begin, is taken from the block that executed the proposal rather than from an administrator marking it done.
execution block · not an operatorIdentity Belongs To IVL
Sign-in and the second factor are SWSS IVL's, not the portal's. NodeX authenticates nobody on its own, which keeps it out of the identity path entirely.
SWSS IVL · single authorityWho Votes, And How The Set Changes
Voting is carried by the active validator set. Joining it and leaving it are themselves governance decisions, which means the composition of the electorate has a public history rather than an administrator behind it.
Joining The Set
An institution completes business verification, posts its bond, and provisions a node. Admission itself is a proposal: the set votes, and the validator becomes active only when the proposal executes.
- Business verification, with the credential recorded on chain
- A slashable validator bond posted before the proposal is raised
- Active from the execution block, not from an administrator's click
Leaving It
A validator may leave, and leaving is a proposal as well. A minimum tenure applies, so the set cannot be churned, and the exit is recorded on the same ledger as the admission.
- A voluntary exit request, subject to a minimum tenure
- The same proposal path as admission, with the same evidence
- Bond release follows the chain's state rather than a request
The Vote Belongs To The Operators
Validators carry the consequence of every upgrade, parameter change and admission, in uptime, in collateral and in the work of running the result. The right to decide sits with the parties who have to live with the decision.
Collateral Held By The Operator, Not A Vendor
Institutional validators post slashable collateral, and the identity layer refuses a session backed by a wallet whose keys the operator does not hold. A stake somebody else controls is not a stake.
Verified Before Admitted
Business verification is completed and recorded before admission is proposed, so the set is composed of parties the ecosystem can identify rather than addresses that met a deposit threshold.
What This Page Does Not Publish
Everything below was available and was withheld on purpose. A page that prints every number it can reach is not transparent, it is indiscriminate, and the first figure that goes stale takes the credibility of the rest with it.
None of this is hidden. Each item names where it can be read by anyone who wants it, from a source that is correct at the moment they ask rather than at the moment we last deployed.
Quorum And Threshold Values
The testnet deployment record carries configured quorum values. They are the testnet's, and publishing them as though they were the protocol's would be the exact class of error this ecosystem keeps correcting. The shape of the rule is described; the values stay where they can be read.
where readable from the contractProposal Counts
A count is correct until the next proposal. A figure that needs a release to stay true does not belong on a published page, and the explorer answers the question accurately at the moment it is asked.
where readable from the explorerHow Individual Validators Voted
Every vote is a transaction and is therefore already public. Summarising a participant's voting record on our own page is a different act from the record existing, and it is theirs to discuss rather than ours.
where on chain, by whoever wants itOperational Detail Around A Vote
The release record holds operational steps taken around individual proposals. Those belong to the engineering record rather than to a public page, where they would invite interpretation without the context that makes them routine.
where in the release recordWhat A Vote Cannot Do
Governance is one authority among several, and it is bounded like the rest. Three limits matter more than anything else on this page.
Governance does not reach member funds
No proposal moves a member's holdings. Custody is SWSS App's domain, under an identity SWSS IVL established, and governance has no path into it.
enforced by SWSS App · separate authorityA passed proposal still meets the release gate
Automated verification runs regardless of what was decided. A change that fails a check does not ship because it won a vote.
enforced by release gate · automatedThe Foundation administers, it does not decide alone
Foundation stewardship covers the specification and the administrative surfaces. Protocol decisions run through this contract, on the record.
enforced by SwssGovernance · on chainGovernance Decides The Protocol, Not Everything Else
Four authorities own four domains completely. A governance decision changes the rules of the network; it does not reach inside the domains below.
| Authority | Identity who a party is | Custody moving what is held | Asset Records DEED-1 instruments | Block Production the validator set |
|---|---|---|---|---|
SWSS IVL Identity Authentication, KYC, KYB, credentials and signing. IVL holds no balance, stakes nothing and bridges nothing: it establishes who a party is and signs what that party approves. | owns | |||
SWSS App Custody & Treasury Wallet operations, staking, treasury movement and bridging. Everything a member's holdings do happens here, under the identity IVL has established and never inside it. | owns | |||
SWSS RWAX Deed & Exchange Data The DEED-1 instruments, their records and the exchange data around them. Asset truth is owned here and nowhere else in the ecosystem. | owns | |||
SWSS NodeX Validator Operations Validator onboarding, the operating set and the parameters that govern it. Who may produce a block is decided in one place, on the record. | owns |
A proposal can change what the network does. It cannot move what a member holds, establish who somebody is, or rewrite an asset record, because none of those belong to the domain governance operates in.
Do Not Take This On Trust
The governance contract, its proposal history and the versions the networks actually report are all public. Every claim on this page resolves to one of them.
If a record here and the running network ever disagree about what the network is running, the network is right. That rule applies to this page as much as to any other document in the ecosystem.
Write To The Foundation
Questions about the standards the Foundation stewards, the intellectual property it holds, or the administrative authority set out on this page.
Foundation Enquiries
For questions about the Foundation, the standards it stewards, the intellectual property it holds, or the administrative authority described on this page.
Stewardship
Protocol, standards and marks
Documentation
Specification and policy requests
Handled In Confidence
No distribution beyond the desk
Direct Contact
[email protected]Important notice
This page describes a mechanism and is published for information only. It is not an offer, a solicitation, or investment, legal or financial advice, and participation in governance confers no entitlement of any kind.
Nothing here promises that any proposal will be made, passed or executed, and no return, yield or appreciation is promised or implied. Statements about the direction of validator independence reflect present intention rather than a commitment to a date.
Before relying on anything above, read the Risk Disclosure and the white paper, and verify the contract state yourself on the explorer.