STRIDE Threat Model: Z-TEXT's Honest Results
Z-TEXT ran Microsoft's STRIDE threat model against its own architecture — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Every category, every answer, honest limits included.
You already know Z-TEXT is a zk-SNARKs blockchain messenger. What you may not know is how it holds up when someone actually tries to attack it.
Microsoft's STRIDE threat model checks six ways a system can be attacked — not marketing claims, the actual categories security teams use. We ran Z-TEXT's own architecture through all six, and published every answer, including where the real limits are.
Whole-post mini-resume: Z-TEXT ran its own architecture through Microsoft's STRIDE threat model — six categories, every answer published, limits included. Spoofing: licence receipts signed and verified offline, no phone/email means no identity to impersonate. Tampering: messages are permanent on-chain zk-SNARKs transactions. Repudiation: every message and purchase is a signed, timestamped record. Information Disclosure: licence checks never touch the server, so there's no log to leak. Denial of Service: the default messaging server isn't even Z-TEXT's own infrastructure. Elevation of Privilege: the one honest weak spot — a bypassed licence costs Z-TEXT revenue, not user privacy. Same pattern as Z-TEXT's public bug bounty and LINDDUN audit: publish the real answer, gaps included, before anyone has to ask.
❓ 1. Z-TEXT's Pattern: Bug Bounty, LINDDUN, Now STRIDE
Bug bounty — paid, public, inviting outsiders to find real flaws.
LINDDUN privacy audit — scored against 7 competitors, honestly admitted the Data Disclosure gap.
STRIDE threat model (this post) — full six-category security audit, nothing skipped.
Mini-resume: As Z-TEXT scales toward public launch, transparency scales with it — each audit goes further than the last, published in full before the doors open.
❓ 2. Spoofing — Can Someone Impersonate a User or the Licence Server?
Licence receipts are signed with Ed25519 by the server and verified offline in the app against a public key built into the binary — a forged receipt won't pass.
Verification logic runs in Rust, not Dart — patching the visible app layer alone changes nothing.
The native library is hash-verified at startup — a tampered or pre-patched build gets caught before it can spoof a valid session.
No phone number, no email — there's no identity layer to spoof in the first place, since none exists.
Mini-resume: No phone number means no identity to steal, forge, or spoof in the first place — you can't impersonate an account that was never tied to a person.
❓ 3. Tampering — Can Someone Alter a Message or a Licence Receipt?
Messages travel as shielded zk-SNARKs transactions on the BitcoinZ blockchain — once confirmed, a transaction can't be altered without breaking the cryptographic proof.
Licence receipts are signed Ed25519 by the server — any modification invalidates the signature, and the app rejects it instantly.
The session token (HMAC-SHA256, random key per process, never leaves Rust) can't be forged or edited from outside the native layer.
Public key and receipt "magic string" are obfuscated in the binary — a simple strings-scan can't find what to patch.
Deploys are health-gated with automatic rollback — a bad or tampered deploy reverts itself before it reaches users.
Mini-resume: zk-SNARKs turn each message into blockchain math — once confirmed, changing it means rewriting arithmetic thousands of nodes already agreed on. Not a policy. Not a promise. Math.
❓ 4. Repudiation — Can Someone Deny Sending a Message or Making a Purchase?
On-chain transactions are the record — every message is signed and permanently timestamped on the blockchain, tied to the sender's cryptographic key. The transaction itself is the proof it happened.
Licence purchases work the same way: the server delivers a signed receipt on-chain to the buyer's z-address — a permanent, verifiable record that payment occurred.
The honest limit: this proves a specific key signed a specific transaction — it can't prove which human held that key. Z-TEXT has no phone number or email to tie a key back to a real identity, by design.
Mini-resume: A signature proves a key sent it. It can't prove which person held that key — not by policy, but by design.
❓ 5. Information Disclosure — What Could Leak, and to Whom?
Third parties in the payment/admin path (OxaPay, Cloudflare, CoinGecko, Blockchair, Pushover, Postmark, OpenRouter, Cloudflare R2) never touch the message path — they see purchase activity, never message content or metadata.
Licence enforcement is entirely client-side — the server is never asked anything when a message is sent, so there's no log of who's messaging or when to leak in the first place.
The public key and receipt "magic string" are obfuscated in the binary, reducing what a reverse engineer could extract even with direct access to the app.
The honest limit: obfuscation slows down extraction, it doesn't make it impossible on a determined attacker's own device — what it protects is the server side, not a guarantee against every local attack.
Mini-resume: Not holding the log is the actual privacy guarantee — there's nothing to leak because there was never anything collected. No authority can subpoena data that doesn't exist.
❓ 6. Denial of Service — What Happens If a Server Goes Down?
Messaging has real redundancy: three independent lightwalletd servers on three separate machines — the default (lightd.btcz.rocks) isn't even Z-TEXT's own infrastructure, plus a self-hosted server and a Tor onion service. Users can also point to their own.
The default server isn't even Z-TEXT's: lightd.btcz.rocks is run independently by the BitcoinZ community, not by Z-TEXT. There is nothing to attack that Z-TEXT controls — an authority pressuring Z-TEXT, seizing Z-TEXT's infrastructure, or shutting Z-TEXT down as a company changes nothing about that server's uptime. It was never Z-TEXT's to lose.
Switching between servers is manual, done in settings — not automatic failover.
The licence server is a single machine by design, but it's outside the message path — messaging keeps working even if it's down.
Payments don't get lost during downtime: OxaPay retries failed callbacks for 3.5 hours, ZEC payments are read directly from the blockchain (nothing to "miss"), and the payment handler is idempotent.
Z-TEXT doesn't issue BTCZ — the blockchain predates the company by years and runs independently of it. There's no token supply to protect, no price to defend, no incentive to manipulate uptime for financial gain.
The honest limit: a ZEC invoice expires after 60 minutes — a payment landing during a longer outage needs manual follow-up.
Mini-resume: Real denial of service means attacking something the target controls. Z-TEXT doesn't issue BTCZ, doesn't control the blockchain its messages run on, and doesn't own the server most users connect through by default — so there's no single point to pressure, seize, or shut down.
❓ 7. Elevation of Privilege — Could Someone Unlock Premium Features Without Paying?
Licence enforcement is entirely client-side: the server signs a receipt (Ed25519), delivers it on-chain, and the app verifies the signature offline against a built-in public key. Nothing is asked of the server when a message is sent.
Verification logic lives in Rust, not Dart — patching the visible Flutter layer alone achieves nothing.
A successful verification mints an HMAC-SHA256 session token with a per-process random key that never leaves Rust — every premium feature re-checks that token.
The public key and receipt "magic string" are obfuscated in the binary — a simple strings-scan can't find what to patch.
The native library is hash-verified at startup — a pre-patched build gets caught before it can run.
The honest limit: a determined reverse engineer can defeat any client-side gate on their own device. What they get is free premium features on that one phone — nothing more.
Mini-resume: This is the only category where the risk is business, not security. There's no higher privilege to escalate to, because message security was never behind the licence gate in the first place. zk-SNARKs, Ed25519, and the blockchain itself set the real limit. Bypassing the licence check unlocks features. It doesn't unlock more privacy, because there was never a "more private" tier to reach. A stolen licence is a lost sale — a financial risk to Z-TEXT, not a security risk to the network.
❓ 8. What Are the Honest Limits of This Audit?
This is a self-audit, not an independent third-party review — the same honest-gap approach used in the LINDDUN post, where an unaudited gap was stated plainly rather than hidden.
The code isn't open source yet (planned, not shipped) — so outside researchers can't independently verify these claims against the codebase yet.
This is a snapshot of today's system. As Z-TEXT ships new features, each one gets its own STRIDE pass — the same discipline applied here, applied again.
Mini-resume: A threat model isn't a certificate you earn once. It's a habit — published in full, and repeated every time something changes. Bug bounty. LINDDUN. STRIDE. Three audits, one habit — and it doesn't stop here.
Sources
STRIDE threat model: Wikipedia — STRIDE model
Microsoft — The STRIDE Threat Model: learn.microsoft.com
OWASP — Threat Modeling: owasp.org
Z-TEXT Security Documentation: z-text.com/docs/security
BitcoinZ: getbtcz.com
🔗 Also read: Signal vs Z-TEXT · WhatsApp vs Z-TEXT · Session vs Z-TEXT · Z-TEXT 4-in-1 · LINDDUN Score: Z-TEXT vs 7 Ultra-Privacy Messengers
STRIDE threat model · blockchain messenger security · zk-SNARKs messenger · threat modeling · censorship resistant messenger · zero-knowledge proof messenger · quantum-resistant messaging app
