What the founder must not be able to do
Not "promises not to". Must not be technically able to. Each of these has a numbered acceptance exercise that tries to do it and must fail.
| # | Prohibited unilateral power | Tested by |
|---|---|---|
| P1 | Force a software update | A3 |
| P2 | Rewrite valid signed records or the registry | A4 |
| P3 | Override client ranking | A8 |
| P4 | Revoke an arbitrary node identity | A7, A15 |
| P5 | Add a permanent takedown authority | A5 |
| P6 | Change trust roots silently | A8 |
| P7 | Hide legal content from all clients | A5 |
| P8 | Prevent alternate governance channels | A8 |
| P9 | Destroy a compatible fork | A8 |
These become binding at public-network genesis: the first public release that accepts third-party uploads or independent nodes. The founder may remain one keyholder. The founder must not retain a private override.
The qualification that keeps this honest
Founder neutrality does not require every node to possess every authority. It requires each authority to be explicit, limited, replaceable, and unable to turn its propagation role into unilateral control.
Somebody has to carry legal notices around the network. Carrying them is propagation. Deciding what they say would be issuance. Decenter separates the two so the courier can never become the court.
Separated key roles
Compromising one key must not grant control over an unrelated function. A release key that also carried registry authority could both ship malicious software and hide it by rewriting which nodes clients can see.
software release authorization protocol and schema publication default registry governance legal-processor delegation legal-process issuance model-registry authorization emergency key revocation transparency-log signing
The delegating key - who may issue - is more valuable than the issuing key, and is held offline under threshold control.
Compatibility is not conformance
People argue about whether a safety floor contradicts node autonomy. It does not, because they operate at different tiers.
| Tier | Means |
|---|---|
| Protocol-compatible node | Understands the wire protocol; can exchange permitted records |
| Governance-channel participant | Also follows a declared channel's authority and delegation policies |
| Conforming public node | Also satisfies that channel's safety, legal, reliability and operational requirements |
| Recognized infrastructure contributor | Also earns registry inclusion, storage credit, attestation weight and aggregate influence |
A node that refuses a channel's rules keeps running. It keeps talking the protocol. It simply stops being recognized as conforming under that channel. That is the entire consequence, and it is sufficient.
Protocol interoperability does not imply entitlement to registry inclusion, relay service, storage credit, attestation weight, aggregate influence, or the "conforming node" designation.
There is deliberately no universal conforming = true flag. Recognition is scoped to a channel and to a capability. A node can be conforming under one channel and not another, at the same moment, correctly.
What is not solved
Separating node identity from account identity defeats server-fleet amplification. It does not defeat someone running many fake accounts. That remains an ongoing cost-and-detection problem, handled with account aging, identity continuity, clustering analysis, possession audits and exposure-normalized rates - not a claim of victory.