This is not a performance argument. It is a consequence of two design commitments that most infrastructure teams will recognise immediately.
A ledger whose rules can be changed by any single party is not independently verifiable — a participant can verify yesterday, but not tomorrow. So the protocol rules are frozen: there is no upgrade key, no governance switch, no mutable contract layer.
But swapping a signature algorithm is a change to consensus rules. A system that can perform that swap on demand is, by definition, a system whose rules can be changed. The two properties cannot both be held later — which is why the signature scheme has to be settled before the first block, not after.
There is a second, narrower consequence. Independent verification here means replaying the entire history against one rule set. If the signature rule changes at some height, replay no longer runs against one rule set but against a sequence of them, assembled by block height. That weakens exactly the property the design exists to provide.
| Signature point | Scheme | Key holder |
|---|---|---|
| Value transfer on QCC | ML-DSA-87 | Address owner |
| Clearing result signature (ResultSignature) | ML-DSA-87 | Clearing institution |
| Inter-institution node authentication | ML-DSA-87 | Member institution |
| Settlement token issuance and redemption | ML-DSA-87, joint signing | Three separate signatories, all required |
ML-DSA-87 is the highest parameter set of the NIST-standardised module-lattice signature scheme (FIPS 204). Content integrity throughout the message object uses SHA3-256 (FIPS 202).
Hash-based schemes such as SLH-DSA remain available as an alternative parameter family, but adopting one later would itself be a consensus rule change and is therefore treated as out of scope rather than as a planned upgrade path.
Institutions running post-quantum readiness programmes are generally planning three separate pieces of work for any ledger they connect to: an inventory of classical key material, a migration path with a cutover, and a policy for keys and records created before the cutover. On OSN none of the three arises, because no classical signature exists in the ownership path at any point in the history.
Key rotation remains a normal operational task and is deliberately kept simple: an institution generates a new keypair, transfers its settlement tokens to the new address, and updates its whitelisted address. No protocol change and no coordination window is involved.
Scope note: this position covers signatures and content integrity. Transport-layer confidentiality between nodes, and any key-encapsulation used for it, is tracked separately and is not claimed here.
