DEV Community: ztext_zksnarks

How two AI agents traded privately on a blockchain, with proof of delivery

ztext_zksnarks — Fri, 30 Oct 2026 08:48:33 +0000

Yesterday, two AI agents made a deal with each other. Nobody clicked "approve".

Agent A offered to say hello in French for 5 BTCZ. Agent B paid. Agent A delivered. Agent B checked the delivery against a fingerprint and got MATCH. The whole thing took about 3 minutes, and every step was a shielded transaction on the BitcoinZ blockchain.

Here is how it works, what it proves, and what it doesn't.

The problem

AI agents are starting to call tools and spend money. Sooner or later they will buy small tasks from each other: a translation, a summary, a price check, a piece of code.

That raises three questions:

How does the buyer know it got exactly what was promised?
How do you stop one side from running away with the money or the work?
How do you keep the deal private, so the whole world doesn't see who paid whom, how much, and for what?
The idea: small steps, signed fingerprints

I added a feature called Deals to I Am Wallet, an open-source MCP server that gives AI agents their own shielded BitcoinZ wallet.

A deal is just five MCP tools:

deal_offer (seller): price per step, number of steps (1 to 10), what is delivered
deal_pay (buyer): pays the next step
deal_deliver (seller): delivers the paid step, the result plus its SHA-256 fingerprint, signed
deal_check (buyer): compares what arrived with the signed fingerprint, MATCH or NO MATCH
deal_status (both): what is offered, paid and delivered, with every transaction id

There is no escrow. Nobody holds the money in between. Instead, the deal is cut into small steps, so each side only ever risks one step.

The server enforces the order:

the seller can't deliver a step before it is paid (with 1 confirmation)
the buyer can't pay the next step before the previous one arrived
after a NO MATCH, the next payment is blocked until a check says MATCH
The live deal, step by step

These are the real values from deal yn6urs35:

text
A > deal_offer(to=B, price=5, steps=1, "Live test: say hello in French")
deal_id yn6urs35

B > deal_pay("yn6urs35")
step_paid 1 of 1, paid 5 BTCZ

A > deal_deliver("yn6urs35", result=...)
step 1 payment seen but not confirmed yet <- the rule holding
... one block later ...
result "Bonjour, je suis l'agent A."
sha256 93f49727...aae7a4f0a

B > deal_check("yn6urs35")
MATCH: exactly what A delivered and signed

If you change one letter ("l'agent B." instead of "l'agent A."), the fingerprint becomes completely different, and the check says NO MATCH.

What actually proves the delivery

It's tempting to say "the zk-SNARK proves it". It doesn't. The zero-knowledge proofs hide the sender, receiver, amount and message on the chain. The delivery proof comes from three plain things:

The SHA-256 fingerprint of the result, carried inside the encrypted message.
An Ed25519 signature on that message. Each wallet has a public signer id (awid_...). The signature also covers the receiver's address, so a message can't be replayed to someone else.
The block's date.

If an outsider (a client, a judge) needs to check it later, the fingerprint can also be stamped with ZKStamp Proof-100, a separate proof-of-existence service, and verified with a small open-source script on any BitcoinZ node.

Two design choices I like

Identity is a key, not an address. Reputation will follow the signing key, so addresses can change without losing your history.

Free starter coins that can't be farmed. The first 100 wallets get free BTCZ to try deals. Those coins are labelled on the server: they pay messages, fees and small deals between wallets, but they can never be withdrawn. Coins received from a starter-paid deal stay starter coins. So a bot farming free wallets gets nothing it can cash out.

Honest limits
A MATCH proves which result was delivered and when, not that it's good. The buyer still needs its own quality check before paying the next step.
Hosted wallets are custodial. The operator's server holds the keys. Keep balances tiny, or run your own copy (it's MIT licensed).
In link mode (big files delivered by link), the fingerprint is the seller's signed claim. The server never downloads the file. The buyer must hash it itself.
BitcoinZ is a small chain with thin trading volume, and one confirmation is a thinner guarantee than on bigger chains.
It's an early test (v0.2).
A nice surprise

After shipping, I asked another AI (Perplexity) to read the code and the agent guide and explain the protocol. It got it right, and it pointed out two gaps: a buyer could still pay after a NO MATCH, and link mode needed a clearer warning. Both are fixed now.

Try it
Agent guide (for your agent to read): https://proof.zketernity.app/agent/llms.txt
Code: https://github.com/ZKStamp/AgentWallet

Each send costs 1 BTCZ, which is probably the cheapest private coffee in the galaxy.

I'd love feedback, especially on what would break it.

Shielded timestamps for AI agents: proof of existence on BitcoinZ via MCP

ztext_zksnarks — Tue, 27 Oct 2026 13:07:10 +0000

Public blockchain timestamps have a quiet problem: the fingerprint is public too. Anyone holding the same file can hash it, search the chain, and find your stamp.

So we built ZKStamp Proof-100: the SHA-256 fingerprint goes into the encrypted memo of a shielded (zk-SNARK) transaction on the BitcoinZ blockchain. The block dates it. Nobody can see what's inside until you reveal it, one proof at a time. And it speaks MCP, so an AI agent can stamp in one sentence.

Here's the 60-second demo, a real run from 27 October 2026:

How it works
You compute the SHA-256 fingerprint locally. The file never leaves your machine.
The server writes PROOF100 sha256: into the encrypted memo of a shielded transaction, sent to a brand-new address made for that one proof.
You get back the txid and that address's viewing key.
To reveal one proof, share its txid + viewing key. That reveals this proof and nothing else.
Anyone verifies it with ZCheck on their own BitcoinZ node. No need to trust the operator.
For AI agents (MCP)
https://proof.zketernity.app/mcp

Three tools:

Tool What it does
timestamp_fingerprint Timestamp a SHA-256 fingerprint. Returns txid + viewing key.
timestamp_text The server hashes a short text (not stored) and timestamps it.
check_balance Proofs left and your deposit address.

In Claude: add a custom connector with that URL and the header Authorization: Bearer YOUR_KEY. Then:

Use Proof-100 to timestamp this text: My secret invention idea: a lock that opens with a song.

There's also an llms.txt so agents can read what the service does.

REST API

Create an account (the key is shown once):

bash
curl -s -X POST https://proof.zketernity.app/v1/account

You get a key (starts with p100_) and a deposit_address. Send 500,000 BTCZ to it; after 2 confirmations, 100 proofs are credited automatically.

Make a proof:

bash
FP=$(sha256sum MyFile.pdf | cut -d' ' -f1)
curl -s -X POST https://proof.zketernity.app/v1/proof \
-H "Authorization: Bearer YOUR_KEY" \
-H "Content-Type: application/json" \
-d "{\"fingerprint\": \"$FP\"}"

Returns txid, viewing_key and proofs_left. Takes about 10 to 60 seconds.

Verify with ZCheck
bash
python3 zcheck/ZCheck.py --txid --viewing-key --file MyFile.pdf

From the demo:

VALID: this exact fingerprint was written on the BitcoinZ blockchain
in block 1862988, on 27 October 2026, 09:33 UTC (11 confirmations).

Change one letter in the file:

NOT VALID: the proof exists (block 1862988, 27 October 2026, 09:33 UTC)
but holds a different fingerprint.

Under the hood, ZCheck imports the viewing key into your node (z_importviewingkey), reads the transaction with z_viewtransaction, and compares the memo with your file's hash.

Design choices
One address per proof. Revealing one proof never exposes your others.
No file storage, no fingerprint log. The server doesn't store which proof belongs to which account.
Pay in BTCZ only. No card, no email, no account name.
Honest limits
The server sees the fingerprint (and the text, for timestamp_text) when you submit it.
One operator, one server. If it's down, no new proofs. Existing proofs stay verifiable on any BitcoinZ node.
Block dates are approximate (think "that hour", not "that second").
BitcoinZ is a small chain with thin volume and concentrated mining. For high-stakes proofs, wait for many confirmations.
Quantum: the SHA-256 date should hold up well. The zk-SNARK privacy layer is not post-quantum; a future quantum computer could in theory read old memos (fingerprints, never files). Hence the slogan: Stamp it with Z. Before Q.
Blockchain timestamping isn't new: OriginStamp did it on Bitcoin back in 2015. What's different here is the shielding and the agent-first interface.
Code

Everything is MIT, server included: github.com/ZKStamp/Proof100

Questions, or no BTCZ yet? contact@z-text.com. Feedback and hard questions welcome in the comments.

Europol's Quantum Warning: What It Means for Messaging

ztext_zksnarks — Thu, 08 Oct 2026 05:14:44 +0000

H1: Europol's Quantum Warning: What "Harvest Now, Decrypt Later" Means for Private Messaging

Subtitle: Europol says encrypted data collected today could face future quantum decryption. Here's what post-quantum messaging means, what ML-KEM-768 actually protects, and where Z-TEXT fits.

Intro
Z-TEXT is a privacy messenger built on the BitcoinZ blockchain, with no phone number, no email and no SIM. On October 7, 2026, Europol published two reports on the quantum threat. This article explains what they say, what it means for private messages, and what Z-TEXT does, and doesn't, protect.

❓ 1. What did Europol announce on October 7, 2026?
Europol's European Cybercrime Centre published two reports. The first, "Quantum computing and cryptocurrencies", names crypto wallets as the main point of exposure, not blockchains. The second, "Harvest Now, Decrypt Later", was written with Carlos III University of Madrid. Both recommend preparing now, before a deadline appears.
Source: europol.europa.eu/publications-events/publications/quantum-computing-and-cryptocurrencies

❓ 2. What does "harvest now, decrypt later" mean?
An attacker copies encrypted data today and stores it. No quantum computer is needed for that step. Once a powerful enough quantum computer exists, the attacker decrypts the archive.

❓ 3. Why do encrypted messages have long-term value?
A message about a source, a deal or a health problem can still matter in 10 years. The EU's three financial supervisors (EBA, EIOPA, ESMA) warned in September 2026 that anything intercepted today with long-term value is already at risk.
Source: decrypt.co/379167

❓ 4. Why does post-quantum cryptography matter now?
Moving to new cryptography takes years. Estimates for Q-Day, the day a quantum computer breaks today's public-key cryptography, run from 2030 to 2032 or later. The EU recommends that member states adopt a post-quantum migration strategy by the end of 2026.

❓ 5. What is ML-KEM-768?
ML-KEM is a key encapsulation mechanism: a way for two people to agree on a secret key. It is designed to resist attacks from quantum computers. 768 is the mid-level parameter set.

❓ 6. What does NIST FIPS 203 mean?
FIPS 203 is the US government standard that defines ML-KEM. NIST published it in August 2024 as one of its first post-quantum standards.
Source: nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf

❓ 7. How do today's messengers approach the problem?
Signal added post-quantum key exchange (PQXDH) in 2023 and a post-quantum ratchet (SPQR) in 2025. Apple added PQ3 to iMessage in 2024. Both protect message content, and both tie your account to a phone number or an Apple ID.
Sources: signal.org/blog/spqr · thehackernews.com/2024/02/apple-unveils-pq3-protocol-post-quantum.html

❓ 8. How does Z-TEXT approach it?
Z-TEXT protects three layers:

Who: zk-SNARKs (zero-knowledge proofs) hide who is talking to whom on the BitcoinZ blockchain.
What: Z-TEXT encrypts every one-to-one message with a hybrid key that combines X25519 and ML-KEM-768 (NIST FIPS 203) before the message is written to the blockchain. Recording the chain today and breaking classical cryptography later is not enough to read it.
You: no phone number, no email, no SIM. Your identity is a 24-word seed.
Source: z-text.com/docs/security

❓ 9. What does Z-TEXT protect, and what doesn't it?
Protected against quantum decryption: one-to-one message content.
Not yet quantum-resistant:

Channels and Communities (classical key exchange)
The BitcoinZ shielded layer and the wallet (classical cryptography, set by the BitcoinZ network, not by Z-TEXT)
Signatures (still classical Ed25519)
Also: shielding hides sender and receiver on-chain, but not network data like IP address or timing. And the Z-TEXT zk-SNARKs messenger has not been independently audited yet.

❓ 10. Why does decentralised messaging change the threat model?
Z-TEXT has no central message server. Messages live on the BitcoinZ blockchain, copied on every node, and no one can delete them. That also means anyone can harvest them, forever. This is exactly why the quantum-resistant lock on the message itself matters: the chain is public, so the message has to stay unreadable on its own.

❓ 11. Sources

Europol, Quantum computing and cryptocurrencies (Oct 7, 2026)
EU supervisors' warning, via Decrypt (Sep 2026)
NIST FIPS 203
Signal, SPQR · Apple PQ3, via The Hacker News
Z-TEXT security docs: z-text.com/docs/security
Earlier Z-TEXT article: z-text.org/quantum-attack-z-text-wallet-messages-2026/
BitcoinZ: getbtcz.com

Ending: Message today. Still protected tomorrow.
Download Z-TEXT for Android, macOS, Windows or Linux: z-text.com/downloads

Z-TEXT PRODUCTHUNT

ztext_zksnarks — Mon, 05 Oct 2026 08:09:43 +0000

LAUNCH · MONDAY, OCTOBER 5, 2026

PRODUCTHUNT

Shielded Permanence™ is coming alive!

"Just another messenger?" NO.

Z-TEXT is a wallet-native, censorship-resistant communication layer, where:

• Your audience lives in your wallet
• Your identity is your seed phrase
• Your messages are shielded on-chain
• Your metadata stays hidden
• Your key exchange is quantum-resistant

A fundamentally different model from Signal, Telegram, or any centralized platform.

Building a messenger with no phone number: zk-SNARKs on the BitcoinZ blockchain

ztext_zksnarks — Tue, 29 Sep 2026 08:33:14 +0000

Z-TEXT goes public on October 5, 2026. Before launch, here's how it works under the hood, and where its limits are.

No phone. No email. No SIM. Zero metadata.

Identity: a seed, not a phone number

There is no signup. Your identity is a shielded address derived from a 24-word seed. The same seed unlocks five tools: a messenger, a BTCZ wallet, an on-chain password manager, Channels (on-chain broadcast) and disposable identities.

Lose the phone, restore the seed on any device, and your messages, contacts and vault rescan from the chain.

The message path

The message is encrypted on-device with AES-256-GCM.
The key exchange is hybrid: X25519 + ML-KEM-768 (NIST FIPS 203), live since version 3.7.0, so traffic recorded today resists a future quantum computer. Signatures are still classical Ed25519.
The ciphertext is sent as the memo of a Sapling shielded transaction on BitcoinZ. zk-SNARKs prove the transaction is valid without revealing sender, recipient or amount.
It is pushed through the mempool for delivery in about 1–5 seconds, then settles on-chain.

No central message server holds the conversation. What exists on-chain is an encrypted, shielded transaction, not a readable transcript.

Spam resistance through a micro-fee

Each message costs 0.0002 BTCZ: a 0.0001 network fee plus 0.0001 delivered to the recipient. In a normal back-and-forth that 0.0001 comes back with each reply. Negligible for people, expensive for bots at scale.

Choose your trust tier

Default: connect to the official lightwalletd. It sees that a shielded transaction was submitted, not who, to whom or what.
Tor: the same, but the operator no longer sees your IP.
Self-hosted: run your own lightwalletd or full BitcoinZ node. No third party in the loop.

Honest limits

Text only: no files, pictures or video.
No independent audit of the app yet. There is an active, paid bug bounty instead, but a bounty is not an audit.
Permanence is a feature and a responsibility: messages settle on a blockchain.

The chain

BitcoinZ launched on September 10, 2017, with no premine and no ICO. It is community-run and GPU-mineable. Z-TEXT does not issue or control BTCZ.

Launch day is October 5. Follow along at z-text.com, and read about the chain at getbtcz.com.

Questions about the design are welcome in the comments. 👇

Disposable Private Messaging Without a Phone Number: How Z-Text's Crypto-Erase Actually Works

ztext_zksnarks — Thu, 17 Sep 2026 11:52:50 +0000

A burner phone protects you only while you execute it perfectly. Z-Text's approach is different: the protection is built into the code, not dependent on your discipline.

The core mechanism

Z-Text lets you create a disposable messaging identity for $3 — no phone number, SIM, or email. Here's what's actually happening under the hood:

Local encryption: message database and wallet are each encrypted separately, with their own 32 random bytes stored in the platform keystore — not derived from a seed, not guessable.
The wipe: the panic PIN destroys both keys, then verifies the deletion happened. What's left on flash: encrypted blocks with no key anywhere to open them. Same principle as full-disk encryption on any modern phone — crypto-erase, not overwrite.
The transport: messages are AES-256-GCM encrypted on-device, then delivered as BitcoinZ shielded transactions (Sapling-family zk-SNARKs), hiding sender, recipient, and amount on-chain.

The identity/content distinction

This is the part worth understanding precisely: wiping an identity destroys the key, not the message. Z-Text never deletes anything from the blockchain — what's sent stays there permanently, shielded.

If both parties in a conversation eventually wipe their keys, with no backup anywhere, the message doesn't disappear. It becomes permanently unreadable — by anyone, including Z-Text. Not through deletion. Through the simple fact that nothing exists anymore that can decrypt it.

What it isn't

Worth being precise about limits:

A disposable identity on your daily phone still shares that device's IP and network fingerprint with your primary identity
No independent security audit yet — there's a live, funded bug bounty (7 ZEC, with a verified on-chain payout already on record: t1bV6TkNwWBGBPtGhJCNEQZChpGVivHhHGE), which is a real signal, not a substitute for a formal audit
Text-only by design — no files, images, or voice

Why now

India just mandated SIM-binding for WhatsApp, Telegram, Signal, and Snapchat — apps must reverify the physical SIM is present continuously, not just at registration. The FCC has an open proposal (Docket 17-59/02-278) requiring government ID before activating a phone line, opposed in writing by EPIC and CDT. Phone-number-bound identity is becoming a structural liability in more than one jurisdiction at once.

Z-Text sits outside that perimeter — built on a blockchain shielded by zk-SNARKs, not a phone number.

Currently in private beta. Full writeup: https://z-text.org/disposable-private-messaging-no-phone-number/

Can Quantum Attacks Break Z-TEXT's Wallet or Messages?

ztext_zksnarks — Mon, 14 Sep 2026 07:40:16 +0000

On September 8, 2026, IonQ (NYSE: IONQ) published the first full engineering blueprint for breaking secp256k1 — the elliptic curve Bitcoin uses to sign transactions. Not a simulation. An actual attack plan.

The numbers
19,397 physical qubits
1,457 logical qubits
~25.7 days per attempt
40.7% proven success probability (up to 63.3% under common heuristics, per IonQ)

No hardware exists yet that can run this. IonQ's own roadmap targets 10,000 fault-tolerant physical qubits by 2027 — about half of what this attack needs. They call it "a capability milestone first, a security finding second."

Why transparent wallets are exposed

The attack targets the public key. Transparent Bitcoin addresses expose that key the moment you spend — either it's already on-chain from a prior transaction, or it gets revealed the instant you broadcast a new one. That's the actual target for Shor's algorithm.

Why shielded wallets aren't

Z-TEXT runs on BitcoinZ and uses zk-SNARK shielded (z-address) transactions. The proof confirms a spend is valid without ever revealing the signing key — not at rest, not during spending. There's no exposure moment for this specific attack to exploit.

Important nuance: this isn't stronger math. The underlying curve is still classical and still theoretically breakable by a large enough quantum computer. The difference is opportunity, not cryptographic strength.

The message-layer story is different

Z-TEXT's key exchange runs on ML-KEM-768 (NIST FIPS 203), a genuinely post-quantum algorithm — automatically, on every handshake, since the 3.7.0 beta. This defends against harvest-now-decrypt-later: even captured ciphertext stays unreadable, because the exchange was never built on breakable math in the first place.

Signatures are still classical Ed25519. ML-DSA-65 isn't in use yet — worth being upfront about.

The one honest limit

The math hiding sender, receiver, and amount (ledger shielding itself) is still classical ECC — same family as HTTPS, online banking, VPNs. Breaking it needs ~2,500-4,000 error-corrected logical qubits. Real quantum hardware at that scale is 10-20 years out, per most researchers. That's an industry-wide limit, not a Z-TEXT-specific one.

Sources
IonQ blog post
IonQ investor press release
Interesting Engineering coverage

Full piece with more detail: https://z-text.org/quantum-attack-z-text-wallet-messages-2026/

Tags: #bitcoin #cryptography #quantumcomputing #privacy

The EU Escape Room: Chat Control vs. Z-TEXT

ztext_zksnarks — Thu, 10 Sep 2026 13:05:18 +0000

EU Chat Control would force messaging apps to scan messages before/after encryption — a compliance order aimed at the app layer, not your device or network.

I wrote up the technical breakdown of why some architectures simply can't comply, even under legal pressure:

No central server = nothing to seize or subpoena
No phone number/email account = nothing to attach a legal order to
zk-SNARKs hide sender, receiver, and content — even on a public ledger
Post-quantum key exchange (ML-KEM-768) closes the "harvest now, decrypt later" gap

Full breakdown, with a comparison to Signal/Threema's "comply or leave" dilemma vs. an architecture that structurally can't comply either way:

👉 https://z-text.org/eu-escape-room-chat-control-vs-z-text/

Curious what this community thinks about the EU's Digital Markets Act already forcing iOS sideloading — it's an interesting side effect that undercuts app-store delisting as an enforcement path too.

Z-TEXT Ran Its Own Threat Model. Here's What It Found.

ztext_zksnarks — Wed, 09 Sep 2026 07:26:06 +0000

Most messengers tell you they're secure. Few show their work.

Z-TEXT ran Microsoft's STRIDE threat model against its own architecture — the same framework security teams use internally, not a marketing checklist. Six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

Every answer got published. Including the one honest weak spot: a bypassed license costs Z-TEXT revenue, not user privacy.

A few highlights:

Spoofing — No phone number, no email. There's no identity to spoof in the first place, because none exists.

Tampering — Messages are shielded zk-SNARKs transactions on the BitcoinZ blockchain. Once confirmed, altering one means rewriting cryptographic math thousands of nodes already agreed on.

Denial of Service — The default messaging server isn't even Z-TEXT's own — it's community-run infrastructure (lightd.btcz.rocks), plus a self-hosted option and a Tor onion service. Nothing centralized to seize or pressure.

Elevation of Privilege — License enforcement is entirely client-side. A determined reverse engineer could unlock premium features on their own device. They can't unlock more privacy — message security was never behind that gate.

This follows the same pattern as Z-TEXT's public bug bounty and its LINDDUN privacy audit: publish the real answer, gaps included, before anyone has to ask.

Full breakdown: https://z-text.org/stride-threat-model-z-text-honest-results/

LINDDUN Score: How Z-TEXT Stacks Up Against 7 Privacy Messengers

ztext_zksnarks — Fri, 04 Sep 2026 07:55:32 +0000

Most messenger security comparisons stop at "is it end-to-end encrypted?" That question only covers message content. It says nothing about metadata: who you talk to, when, how often, from where.

LINDDUN closes that gap. Created in 2011 by the DistriNet research group at KU Leuven and now cited in the ISO 27550 privacy engineering standard, it breaks privacy into seven distinct threat categories instead of one encryption checkbox:

Linkability
Identifiability
Non-repudiation
Detectability
Disclosure of information
Unawareness
Non-compliance

We ran Z-TEXT — a zk-SNARKs blockchain messenger built on BitcoinZ — through this framework against six other metadata-focused messengers: Briar, SimpleX, Threema, Wire, Status, and Jami.

Where Z-TEXT ties for #1

Z-TEXT, Briar, and SimpleX tie on four of seven categories:

Category	Why
Linkability	Tor routing built in, opt-in — same model as SimpleX
Identifiability	No phone, no email, no SIM — just a 24-word seed
Detectability (on-device)	Panic mode + stealth mode, a combination none of the other six apps ship
Unawareness	Threat model publicly disclosed

The honest gap

Z-TEXT doesn't lead on Data Disclosure. The cryptography is built on librustzcash — the same audited codebase behind Zcash — but the Z-TEXT app itself has no independent third-party audit yet. SimpleX is the only messenger in this group of seven that has one, from Trail of Bits in November 2022. Briar, Threema, Wire, Status, and Jami share the same gap.

Built-on-audited-code and audited-as-an-app are different claims. We can make the first one. Not the second, yet.

Architecture notes

Tor routing is opt-in, not forced — same trade-off SimpleX makes. Turning it on covers wallet and price-check traffic too, since it protects the whole connection rather than a single app's messaging layer.
On-chain message persistence is also opt-in. Default is local-only. When toggled on, zk-SNARKs shield both content and parties, so what's visible on-chain is a shielded transaction, not who sent what to whom.

Full scoring writeup and sources: https://z-text.org/linddun-score-z-text-vs-7-privacy-messengers/

Z-TEXT: A zk-SNARKs Blockchain Messenger With No Phone Number

ztext_zksnarks — Thu, 20 Aug 2026 08:31:33 +0000

Every "private" messenger still asks for one thing that gives you away: a phone number, an email, or some other identity anchor.

Z-TEXT doesn't. It's a zk-SNARKs blockchain messenger built on BitcoinZ — combining a shielded messenger, a password manager, a crypto wallet, and Channels broadcasting, all under a single 24-word seed phrase.

The core idea

Instead of routing messages through a company's servers, Z-TEXT broadcasts them as shielded transactions on the BitcoinZ blockchain. zk-SNARKs zero-knowledge proofs hide sender, recipient, and content — not just encrypted in transit, but cryptographically invisible on-chain.

No phone number. No email. No SIM. Zero metadata by architecture, not by policy.

What's actually in the app

Shielded messenger — end-to-end encrypted, zk-SNARKs + AES-256-GCM
Password manager — on-chain, encrypted locally before it ever touches the blockchain
Crypto wallet — BitcoinZ, shielded (Z) and transparent (T) addresses
Channels — broadcast to unlimited subscribers for one flat 0.0002 BTCZ fee, same cost whether 1 person reads it or 500,000

Full breakdown here: What Is Z-TEXT? The Complete 2026 Guide

Curious what devs think of the zk-SNARKs-for-messaging approach vs. traditional E2E — happy to answer questions in the comments.

The Private Messenger That's Actually Simple

ztext_zksnarks — Sun, 16 Aug 2026 16:50:23 +0000

Every messenger arbitrages privacy against ease. zk-SNARKs don't.

So — is there a messenger more private than Signal that's still simple to use? Yes. zk-SNARKs shield the metadata Signal can't touch, and one 24-word seed replaces every signup, password, and phone number across messenger, wallet, password vault, and channels. No KYC. All in, $36/year. That's Z-TEXT.

Why Every Private Messenger Makes You Choose

Signal is easy — install it, use your phone number, message anyone. But that phone number is the one thing tying your identity to your real self. SimpleX and Session go further: no phone number, no user ID at all in SimpleX's case. But that privacy comes with friction — separate connection codes per contact, no simple "add by number" flow most people expect.

Every messenger on the market has made this trade. Simple and traceable, or private and complicated. Nobody has closed both ends at once.

Signal trades privacy for simplicity by keeping your phone number as your identity. SimpleX and Session trade simplicity for privacy, requiring manual connection codes per contact. That's the arbitrage every messenger has made.

Can Signal Really Not Be Subpoenaed?

Mostly true. Signal's 2021 subpoena response proves it: asked for a user's name, address, correspondence, contacts, could only hand over two things — account creation date, last connection date. Content encryption works.

But metadata is the real fight. Signal recently started rolling out phone-number-free accounts, closing the SIM-swap gap. Yet as Ethereum's Vitalik Buterin noted on August 7, message timing and contact-graph patterns can still identify users even without a phone number. Removing the number moves you from identified to pseudonymous — not invisible.

Signal genuinely can't hand over message content — its 2021 transparency report proves it. But metadata resistance is incomplete: phone-number removal doesn't stop behavioral re-identification through message timing and contact graphs.

Is There Anything More Private and Simpler Than Signal?

More private — yes. SimpleX Chat uses no user IDs at all, not even random ones. Session and Threema also skip the phone number entirely.

Simpler — no. Every one of them trades ease for that privacy. SimpleX's no-identifier model means separate connection codes per contact, no simple "add by number."

That trade-off is the same one Apple spent decades proving wrong. Apple didn't win by having more features — it won by removing friction until the product just worked. Nobody's done that for privacy yet.

More-private-than-Signal options exist (SimpleX, Session, Threema), but none match Signal's ease. The gap between "most private" and "most simple" is real and confirmed.

What zk-SNARKs Actually Fix

zk-SNARKs are the "moon math" — cryptography so advanced it can prove a transaction happened without revealing who sent it, who received it, or how much moved. No identity graph. Not hidden. Never created.

Signal hides metadata after the fact, server-side. zk-SNARKs shield it structurally, on-chain, before it's ever a data point to steal, leak, or subpoena.

zk-SNARKs prove a transaction happened without revealing sender, receiver, or amount — shielding metadata structurally, on-chain, rather than hiding it after the fact.

Z-TEXT: One App, Four Tools, No Trace

Four tools, one seed:

Messenger — shielded conversations, no one can graph who talks to whom.
Password manager — zero-knowledge vault, lives on-chain, not on a server.
Wallet — non-custodial BTCZ, your keys only. Two address types: t (transparent) and z (shielded).
Channels — on-chain broadcasts, same shielded protection.

No phone number. No KYC. No trace, because zk-SNARKs never let one form.

Z-TEXT bundles a shielded messenger, zero-knowledge password manager, non-custodial BTCZ wallet, and on-chain Channels — all unlocked by one seed, with no phone number or KYC required.

Price — Fixed

1-year license: $36. All in — no per-message fees, no hidden charges. 60 million messages included, automatic activation. Pay in BTCZ, ZEC, BTC, ETH, LTC, SOL, XMR, USDT, USDC, and more, or with shielded ZEC for a fully anonymous purchase.

How to Use It — Simple

Download the app, create your wallet, write down your 24-word seed phrase, add a contact by their z-address, send. First message lands in 1–5 seconds.

A full year of Z-TEXT costs $36, all in, with 60 million messages included. Setup is one seed phrase, written down once.

Privacy Highway — Open (No KYC)

One seed unlocks all four tools — messenger, wallet, password manager, channels. No signup per tool. No ID. No KYC, anywhere. Same seed, same recovery, every tool.

Sources:
Signal Transparency Reports — https://signal.org/bigbrother/
Z-TEXT Packages — https://z-text.com/packages
Electric Coin Company — What are zk-SNARKs? — https://z.cash/learn/what-are-zk-snarks/

Originally published at z-text.org