Security & Transparency

Z-Text is built around a zero-trust model: no analytics, no tracking, no server-side data storage. This page documents how that is achieved, what it does not protect against, and how to report security issues.

PIN Protection

Z-Text locks the app with an 8-digit PIN that you set during initial setup. The app asks for it before it will:

Open
Send transactions (messages and BTCZ transfers)
Show your seed phrase
Change security settings

The PIN itself is never stored in readable form. Repeated wrong guesses on the lock screen trigger a cooldown.

Biometric Authentication

On supported devices, you can enable fingerprint or facial recognition as an alternative to PIN entry for app access. Biometric data is handled entirely by the device's secure enclave -- Z-Text never accesses raw biometric data.

Two-Layer Encryption

Z-Text employs a dual encryption architecture that provides defense-in-depth:

Layer 1: Blockchain Shielding (zk-SNARKs)

The BitcoinZ blockchain's shielded transactions use zk-SNARKs to encrypt the transaction memo field. This means:

The message content is encrypted on-chain
The sender and recipient z-addresses are hidden
The transaction amount is hidden
Only the holder of the z-address viewing key can decrypt the memo

Layer 2: Contact Key Encryption

Before placing the message in the transaction memo, Z-Text encrypts it with the shared key derived from the handshake. This adds a second layer of protection:

Even if someone obtains your z-address viewing key, they cannot read messages
The shared key is unique per contact pair
The key is derived through a hybrid X25519 + ML-KEM-768 exchange and never transmitted directly

Why Two Layers?

Layer 1 protects against blockchain observers. Layer 2 protects against viewing key compromise. Both layers must be broken to read a message -- an extremely difficult proposition.

Post-Quantum Handshake

From version 3.7.0 every contact handshake runs ML-KEM-768 (NIST FIPS 203) alongside the classical X25519 exchange. The two shared secrets are combined, so the result is never weaker than X25519 alone -- adding the post-quantum half cannot lower the floor.

The threat this addresses is harvest now, decrypt later: an adversary recording shielded traffic today, intending to break it once a quantum computer exists. Against a hybrid ML-KEM handshake, that archive stays unreadable.

What is post-quantum today, and what is not

Key exchange -- post-quantum. ML-KEM-768 (FIPS 203), hybrid with X25519, on every handshake since 3.7.0.
Signatures -- still classical. Handshake payloads are signed with Ed25519. ML-DSA-65 (FIPS 204) keys are already derived from your seed phrase and stored with your identity, but nothing signs with them yet.
Payloads -- AES-256-GCM. Grover's algorithm reduces this to roughly 128-bit effective security, which remains infeasible.
On-chain layer -- unchanged. Sapling shielded transactions are fixed by BitcoinZ network consensus. Any post-quantum transition there is a network-level effort, not an app change.

Because ML-KEM keys are derived from the same BIP39 seed as the rest of your identity, restoring from your seed phrase recovers them too. There is no separate post-quantum backup to keep.

To be precise about what a hybrid handshake buys: it protects the key exchange. It is not a claim that Z-Text is immune to all future cryptanalysis.

zk-SNARKs Explained

Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) are cryptographic proofs that allow one party to prove they know a value without revealing the value itself.

In Z-Text's context, zk-SNARKs prove that a transaction is valid (correct balances, authorized sender) without revealing who sent it, who received it, or how much was transferred. This is what makes shielded transactions truly private.

Zero Telemetry

Z-Text collects no user data:

No analytics or tracking of any kind
No crash reporting that sends data externally
No usage data is sent to us
The app connects to the lightd server you choose (ours by default, or your own node) and looks up the public BTCZ price; with Tor on, both go through Tor
Website icons in the password vault are fetched only if you turn them on
No IP address logging by the app itself

Source code & protocol

The Z-Text wire protocol will be published as a specification document for public review. See Protocol Publication below for the current status. Closed-source server components are standard in the privacy-messenger industry: WhatsApp and Telegram both ship closed-source server software and remain widely used.

Threat Model

Z-Text is designed to protect against:

Threat	Protection
Server compromise	No Z-Text server in the message path -- messages live on the blockchain
Network surveillance	zk-SNARK shielded transactions hide sender, recipient, amount, and memo
Recipient learning sender's IP	Architecturally impossible -- the recipient pulls from the mempool, no direct channel exists
Someone else holding your locked device	PIN or biometric lock screen, encrypted local storage, panic PIN
Viewing key leak	Layer 2 contact-key encryption prevents message reading
Censorship of the operator	Default lightd can be replaced with Tor or self-hosted lightd; no single point of failure

What Z-Text does NOT protect against

Honest framing matters. The privacy properties above hold under specific assumptions. Here is what Z-Text deliberately does not address:

ISP-level visibility into BitcoinZ participation. Z-Text does not hide from your ISP that you are connected to the BitcoinZ network, unless you also run Tor or a VPN. Use the Tor tier or run a self-hosted node if this is in your threat model.
Compromise of your device or seed phrase. Anyone with the 24-word seed can read all messages and spend funds. Local malware, screen recording, or shoulder-surfing fall outside Z-Text's protection boundary.
Underlying cryptography being broken. Z-Text relies on the security of the BitcoinZ network and the zk-SNARKs Sapling protocol. If either is broken (advances in zk-SNARK cryptanalysis, consensus failure, etc.), the privacy properties no longer hold.
Global passive adversaries. Z-Text does not provide cover-traffic against an adversary capable of correlating BitcoinZ network membership with timing or volume across the whole internet. Tor mitigates this partially but not completely.
Endpoint social engineering. If an attacker convinces you to share your seed or to install a tampered app, no on-chain protocol can recover from that.

Bug Bounty Program

Z-Text runs a paid bug bounty, with rewards from $250 to $1,500 paid in ZEC from a public pool. The Bug Bounty page is the whole program: what is rewarded, what is not, how to report, and how reports are decided. Nothing on this page adds to it or changes it.

Responsible Disclosure

Security researchers: please report vulnerabilities privately before any public disclosure. We aim to acknowledge within 72 hours and to coordinate disclosure within a 90-day window. Credit is given on request.

Email: [email protected] (preferred)
Fallback: [email protected]
Encrypt sensitive reports with the PGP key below.
Key fingerprint: 13B8 6375 AEBD 6AF9 EBE4 06FE 92CA 539F 9E6C 1ADC

Security Advisories

No advisories at this time

No published security advisories. This page will list past advisories with date, severity, affected versions, and remediation. Researchers and operators can subscribe to updates by emailing [email protected].

Audit Roadmap

An AI-tool-assisted security review (using Claude, GPT, and adversarial review tooling) is planned. The resulting report will be published on this page. We do not list a specific date or auditor name until the audit is scheduled and the report is ready for publication. Past-tense statements about audits will only appear here once the corresponding report is linked.

Protocol Publication

The Z-Text wire protocol -- message framing, handshake, key derivation, and on-chain encoding -- will be published as a specification document for public review. This lets independent reviewers verify that the privacy properties hold without requiring full server source disclosure. We will link the specification here once it is ready.

Closed-source server components are standard for privacy messengers: WhatsApp and Telegram both ship closed-source server software and remain widely used. Publishing the protocol -- rather than every byte of server code -- is the meaningful public-audit artifact for a system like Z-Text, because what matters cryptographically is what goes on the wire and on-chain.

Password Manager

Tor