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

Your wallet and messages are protected by a 6-digit PIN that you set during initial setup. The PIN is required to:

Open the app
Send transactions (messages and BTCZ transfers)
Export your seed phrase
Change security settings

The PIN is stored as a salted hash on your device. After multiple failed attempts, the app enforces a cooldown period to prevent brute-force attacks.

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 ECDH 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.

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 phone-home connections to Z-Text servers
The only network connections are to BitcoinZ blockchain nodes (lightd, or your own node)
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
Device theft	PIN/biometric protection, 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. We would rather pay a researcher to tell us about a flaw than have it found the hard way. Rewards are paid in ZEC and scaled by the real-world impact of the issue, not by how it sounds on paper.

Severity	Reward	Example
Critical	3 ZEC	Remote message decryption, key recovery, or fund theft
High	1.5 ZEC	Breaking a stated privacy property (e.g. de-anonymizing sender/recipient)
Medium	0.5 ZEC	Auth bypass or server-side flaw with limited blast radius
Low	0.1 ZEC	Minor information leak or hardening gap with a working proof of concept

Reward pool

Current pool: 7 ZEC. Rewards are paid to a shielded ZEC address you provide. The bounty pool address is published below so you can verify it on-chain.

BOUNTY-POOL-ADDRESS: t1bV6TkNwWBGBPtGhJCNEQZChpGVivHhHGE
Funded and verifiable on-chain.

In scope

The Z-Text mobile app -- wallet, messaging, PIN/biometric, and panic PIN
The Z-Text wire protocol and on-chain message encoding
Ed25519 receipt signing and verification
The premium-server APIs at z-text.com

Out of scope

Anything already listed under What Z-Text does NOT protect against is a known, documented limitation -- not a bounty-eligible bug. That includes ISP-level visibility, device or seed-phrase compromise, the underlying cryptography being broken, global passive adversaries, and social engineering. Also out of scope:

Denial-of-service and volumetric attacks
Missing security headers or best-practice gaps without a working exploit
Automated scanner output without a reproducible proof of concept
Issues only reproducible on outdated app versions
Social engineering of our team, testers, or infrastructure providers

How to submit

Send your report by email -- see Responsible Disclosure below for the address and timelines. A plain email is fine; PGP encryption is optional and entirely up to you. We never require it.

Rules

Report privately first and give us the coordinated 90-day window before any public disclosure.
Do not access, modify, or destroy data that is not yours, run denial-of-service tests, or social-engineer anyone.
One reward per unique root cause. The first reporter of an issue receives the reward.
Final severity and payout are determined by the team based on real-world impact.
We will not pursue legal action against good-faith research that follows these rules.

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

Settings