Radix can’t attract traders wanting full privacy (not pseudonymity), payroll use cases, institutional or regulated users while every transaction detail and balance is publicly visible. Could optional privacy be added to Radix without ZKPs, without breaking composability, and without a massive network overhaul?
A way forward could be:
Transactions flagged as private go through Cerberus consensus exactly as today, whereby validators see and validate everything. After consensus, two things are redacted from the public view:
- The transaction manifest (who sent what to whom, through which components, on what terms), gets discarded by validators post-consensus, retained only by originating parties
- The resulting substate values (balances, contents, component states) gets published to the public network as committed hashes only, not plaintext
- Validators maintain full plaintext state internally in a durable encrypted state store, which they’ll need to validate future transactions. The public sees only that substates exist, not what they contain.
Both layers are necessary: transaction redaction alone still exposes balances, which is just pseudonymity and Bitcoin has proven that doesn’t survive analysis.
Could state survive shard rotation?
Private substate values are stored in encrypted form across the validator infrastructure. Only the current shard group holds the decryption keys. During rotation, keys are handed off alongside shard responsibility. Incoming validators receive current state (not full history) and can immediately validate. Full network reconstruction operates from this encrypted store, not from the public view.
Rotation is also a security feature. A compromised validator only accesses their current shard’s private state for the duration of their assignment. A successful attacker would only get a time-limited snapshot, not persistent access.
What already exists on Radix that makes this viable
- Personas - identity compartmentalisation at the protocol level, no linkage between Personas visible to the network
- Badges - protocol-enforced, revocable, scoped access control for selective disclosure to auditors/regulators
- On-chain multi-party recovery - private transaction records survive wallet recovery
- Cerberus shard isolation - no single validator sees a full cross-shard transaction
Why not ZKPs right now?
ZKPs hide data from validators. This proposal hides data from public view. We already trust validators with consensus integrity - would we say trusting them with data confidentiality is a lesser requirement? ZKPs would add computational overhead, latency, and complexity to solve a problem the existing trust model already covers. ZKPs don’t appear to be mature enough for complex multi-party atomic transactions yet.
As it seems to be the talk of CT right now. How does it compare to Canton?
Canton achieves stronger theoretical privacy - its infrastructure genuinely never holds full state. But Canton requires identified, legally bound participants and depends on participants maintaining their own state. In theory, this proposal achieves strong practical privacy on a permissionless network with cryptoeconomic enforcement and network-held resilient state. Different deployment contexts, different optimisations etc…
Implementation: parallel validator client?
The consumer-side changes are minimal (a privacy flag, local record retention). The real work is a new validator client implementing the encrypted state store, split state view, key handoff during rotation, and post-consensus data discard. This client runs in parallel with the existing client. Public transactions are unaffected, private transaction capability grows as validators upgrade. No flag day. Potential for premium fees from private transactions incentivise adoption.
Questions for the developer community:
- What are the practical implications of the durable encrypted state store for validator infrastructure requirements and costs?
- How could the shard rotation key handoff be implemented to ensure no key material is exposed during transfer?
- How do private transactions interact with Scrypto components that expect to read public on-ledger state? Should components declare whether they accept private inputs?
- What migration threshold should be required before private transactions are generally available?
- Are there edge cases in the Cerberus braiding process for cross-shard private transactions that this model doesn’t account for?
Full disclosure, I’m a systems engineer by trade but in Civils Infra. Not software. Hence many of the oversimplifications above. Overall though, could this work in future? Haven’t seen it discussed in detail elsewhere so far, but I might just be in the wrong telegrams.