NodeX validators participate in SCP v3.1.4 consensus, produce blocks, sign Finality Certificates, and vote on governance proposals. The programme operates three validator classifications — Foundation, Institutional and Custodian — each with distinct admission criteria and operational roles. The classification is a field of the on-chain validator registry returned by the chain itself, so it can be read and checked independently rather than taken from a directory.

A validator here is not an anonymous node. Institutional and Custodian validators are admitted by on-chain proposal against verified corporate credentials, which is what allows a settlement produced by this set to mean something to a registry or a regulator. That admission is recorded on chain with the block it happened at, so the composition of the set is auditable by anyone rather than asserted by the Foundation. SWSS Chain defines the consensus they run, the Identity Verification Layer issues the credentials they are admitted against, and SWSS Governance is where their votes are cast.

Validators stake SWSS Coin to secure their governance weight, which ties the security of the settlement layer to the same currency every settlement consumes — the relationship set out in Tokenomics. Consensus security and settlement volume therefore rise together rather than independently, and the Ecosystem Flywheel describes how that compounding works across the ecosystem.

Three Validator Classifications

The registry returns these as fields on the validator record rather than as a label held off chain, which is what allows the set to be audited by a stranger. A delegate is not a fourth classification: delegation is an operating model in which a validator has its infrastructure run by another party, and the registry records no such class.

Admission runs through governance, and governance is live inside NodeX on both networks. A validator opens the governance page in the NodeX portal, reads the open proposals and votes on them — on SwssChain mainnet 122605 for decisions that bind production, and on the SwssChain testnet 122606 where the same proposals are rehearsed first. SWSS Governance sets out the mechanism; the point here is that it is not a separate destination from operating a node.

Scaling The Validator Set

NodeX is built to onboard a validator set in the thousands, and the property that makes that possible is BLS signature aggregation. Every Finality Certificate is signed by the active set, but the aggregated signature is a constant size no matter how many validators contributed to it — a certificate produced by a thousand validators is the same size as one produced by ten. The cost of proving finality therefore does not scale with participation, which is the ceiling that limits validator counts on chains without aggregation.

That is an architectural property rather than a projection, and it is the reason the programme can admit institutions continuously without renegotiating the protocol. Admission is gated by credential verification rather than by capacity: the limit on how many banks, funds and custodians can operate validators is how many qualify, not how many the consensus can carry. The current set, its classifications and the block each validator was admitted at are readable from the chain at swssscan.swss.io — this page does not restate a node count, because a number written here would be stale the week the set changes and the registry never is.

Validator Network