Abstract
sha.chat is a post-quantum, end-to-end encrypted messaging and voice application that doubles as the consumer identity gateway to the Zakana settlement protocol. Every sha.chat user, by registering, receives an ML-DSA + ML-KEM identity that is simultaneously a Zakana settlement party. Messages, voice calls, and value transfers between users are signed and routed using the same cryptographic identity, with no native token, no public blockchain dependency, and no custody of customer funds. sha.chat does not attempt to displace WhatsApp on network effects; it attempts to be the only messenger where your contacts list is also your settlement graph.
01 · Problem statement
Three structural problems
- Cryptographic obsolescence is approaching. Mainstream messengers still depend on classical primitives that must eventually be migrated. “Harvest now, decrypt later” is already a rational threat model for state-level adversaries.
- Identity and payment are still two products. Wallets are usually grafted onto messengers after the fact—with separate keys, onboarding and trust assumptions.
- Consumer crypto wallets are the wrong abstraction. Seed phrases, gas fees, chain selection, smart-contract exploits and irreversible custody losses repeatedly block consumer adoption. Payments between known people need auditable bilateral settlement more than a public chain.
02 · Thesis
Three deliberate bets
Post-quantum from day one
Identity, signing and key exchange use ML-DSA and ML-KEM. PQC is treated as the externally visible key material, not a future migration.
Identity = wallet = contact
A handle resolves to one cryptographic identity that authorizes messages, payment-channel updates and scoped agent delegations.
No token, no custody, fiat-first
No native cryptocurrency and no customer funds held. Value transfers are bilateral Zakana channel updates settled through licensed fiat partners.
The unifying claim: a privacy-first messenger can own a different graph—the graph of people who actually move money to each other.
03 · System overview
One identity graph, two surfaces
Identity is a shared component consumed by both the messenger and settlement layer: one identity table, one registry and one set of recovery policies. sha.chat is conceived as a consumer surface on the same identity graph.
04 · Cryptographic design
Keys, capabilities, sessions
Key material
Each identity is designed to bind an ML-DSA public key for signatures, an ML-KEM public key for session establishment and an optional SLH-DSA backup public key for cold recovery. Root secrets remain in hardware-backed storage and authorize scoped per-device capabilities.
Capability-based authorization
identity: alice.zakana
scope: sha.chat:send_message
delegate_pk: <ephemeral ML-DSA public key>
not_before: 2026-06-18
not_after: 2026-09-16 (≤ 90 days)Device loss can invalidate a messaging capability without automatically removing settlement rights. The design separates scopes so compromise is containable.
Session establishment
The v1.0 thesis proposes ML-KEM encapsulation authenticated with ML-DSA and HKDF-derived, independently scoped keys for message encryption, authentication and rotation. The server is not intended to learn message, voice or transaction-memo content, although transport metadata remains a security and privacy concern.
05 · Identity as settlement
Why this is not a Signal clone
A conversation can carry the data needed to initiate a payment channel: both parties have cryptographic identities, an established messaging relationship and authenticated session material. A channel request becomes an explicitly reviewed, signed action in the conversation—not an invisible automated transfer. Disputes and audit trails remain subject to the separate Zakana rule and compliance layer.
06 · Why post-quantum, why now
A moat measured in calendar years
- Standards readiness. NIST FIPS 203, 204 and 205 provide a standards baseline for controlled product development.
- Durable differentiation. PQC readiness compounds with time rather than user count.
- Regulatory direction. Cybersecurity strategies increasingly point toward migration planning, particularly in critical infrastructure.
07 · Business model
Monetize settlement, not attention
Deliberately avoided: advertising, data licensing, native token sales and per-message fees.
08 · Go-to-market
A vertical wedge, not a horizontal launch
- Freelance and gig contracting: conversations and invoices in one thread, with explicit settlement review.
- Cross-border family remittance: pairwise channels between known counterparties with regulated fiat cash-out.
- B2B counterparty communication: vendor and customer threads with embedded transaction intents and corporate policy controls.
09 · Archived roadmap
Five phases originally proposed
Out of scope: native cryptocurrency, public-blockchain settlement, custodial wallets and automated lending or credit. These dates are archived; consult the current Roadmap for present planning.
10 · Risks
Known risks and controls
11 · Comparative positioning
Where sha.chat sits
The intended position is a messenger designed around post-quantum identity and user-reviewed settlement—with no native token, public-chain dependency or custody.
It does not claim incumbent-scale network effects. Its proposed advantage is the coupling of private communication, separated personal and professional contexts, scoped agents and regulated transaction workflows.
12 · Conclusion
A different graph is a defensible graph
sha.chat is conceived as the consumer surface of a settlement network that is post-quantum, identity-coherent and token-free, with a regulatory posture intended for operation in the EU. The bet is that a graph of people who actually transact can be more defensible than a universal graph of people who merely message.
Open questions carried forward
- Group cryptography: pairwise sessions versus sender keys.
- How to secure real-time voice key exchange with post-quantum mechanisms.
- Hardware-backed storage constraints across Android, iOS and desktop.
- Open-source licensing and independent audit scope.
- PSP selection, settlement posture and recovery-policy defaults.