Whitepaper · SHA-WP-001

Your contacts list is your
settlement graph.

A post-quantum, end-to-end encrypted messenger that is also the consumer identity gateway to the Zakana settlement protocol—no native token, no public blockchain, no custody of customer funds.

DocumentSHA-WP-001SourceWebsite v1.0StatusDraft / planning thesisSource updated18 June 2026
Archived planning document

This page preserves the information published in website v1.0. Dates and implementation claims are historical planning inputs; the current delivery plan remains on the Roadmap.

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

  1. 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.
  2. Identity and payment are still two products. Wallets are usually grafted onto messengers after the fact—with separate keys, onboarding and trust assumptions.
  3. 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

01

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.

02

Identity = wallet = contact

A handle resolves to one cryptographic identity that authorizes messages, payment-channel updates and scoped agent delegations.

03

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.

ClientAndroid · iOS · Desktop · local signingMessaging + voiceE2EE messaging · calls · SRTPIdentity boundaryRegistry · capabilities · sessions · recoveryZakana / ZVMChannels · ledger · rules · settlementLicensed fiat railsRegulated settlement partner

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

  1. Standards readiness. NIST FIPS 203, 204 and 205 provide a standards baseline for controlled product development.
  2. Durable differentiation. PQC readiness compounds with time rather than user count.
  3. Regulatory direction. Cybersecurity strategies increasingly point toward migration planning, particularly in critical infrastructure.

07 · Business model

Monetize settlement, not attention

Settlement transaction feeBasis-point fee on net-settled channel finalization
B2B identity / API tierPaid node access for enterprise counterparties
Compliance / audit moduleRegulator-grade export of channel history
Premium UXSubscription for multi-device, larger groups and advanced features

Deliberately avoided: advertising, data licensing, native token sales and per-message fees.

08 · Go-to-market

A vertical wedge, not a horizontal launch

  1. Freelance and gig contracting: conversations and invoices in one thread, with explicit settlement review.
  2. Cross-border family remittance: pairwise channels between known counterparties with regulated fiat cash-out.
  3. B2B counterparty communication: vendor and customer threads with embedded transaction intents and corporate policy controls.

09 · Archived roadmap

Five phases originally proposed

Q2–Q3 2026Settlement API, identity registry and Android closed beta
Q4 2026Public beta concept with wallet sandbox and rule engine
Q1–Q2 2027iOS, voice/VoIP and PSP partnership
H2 2027Permissioned settlement network; any bridge subject to legal posture
2028Regulated-market and enterprise objectives

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

Cold startUse focused product lines and bilateral network effects.
Financial reclassificationLegal review and licensed PSP involvement before fund movement.
PQC parameter revisionCryptographic agility and algorithm-tagged key storage.
Mobile key compromiseScoped delegation, explicit review and hardware-backed storage.
Operational costSingle-cloud early phases; expand only when justified.
Brand trustOpen cryptographic core and independent audit before general availability.

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.
SHA-WP-001

v1.0 website text, preserved in the v5 interface for review. Not a statement that unfinished security or regulated-payment capabilities are production-ready.

Current roadmap