Z-TEXT is a zk-SNARKs blockchain messenger. Nobody reads your messages but you.

The hard part wasn't privacy — it was space. A blockchain memo allows 512 bytes, total. After encryption and signatures take their cut, 482 bytes remain. Into that space, Z-TEXT had to fit a messenger, a password manager, a BTCZ wallet, and broadcast channels — with no server anywhere holding the data.

This is how.

A blockchain memo size isn't a Z-TEXT setting — it's a BitcoinZ network rule.

Z-TEXT does not own or control the BitcoinZ blockchain. BitcoinZ is an independent chain, live since 2017.

Z-TEXT could have built its own private blockchain instead, with any memo size it wanted. It didn't — it chose to build on an existing, independent chain, and accept that chain's limits as-is.

Every shielded BitcoinZ transaction carries exactly 512 bytes of memo space. No more, no less. Nobody can raise that limit — not Z-TEXT, not miners, not developers.

Before any content is written, the encryption envelope already takes its cut:

— 1 byte: version

— 12 bytes: encryption IV

— 16 bytes: authentication tag

— 1 byte: compression marker

Total taken: 30 bytes, gone before content starts.

What's left: 482 bytes — the entire budget for every message, password entry, wallet transaction, and channel post Z-TEXT handles on-chain.

1. Packed — the message is packed using MessagePack, a compact binary format, with short integer keys instead of long field names.

2. Signed — it's signed with Ed25519, a digital signature covering every part of the message except the signature itself.

3. Optionally compressed — Z-TEXT checks: would compressing this make it smaller? If yes, compress. If no, skip it.

4. Encrypted — the message is encrypted with AES-256-GCM, using a key only the recipient can derive.

5. Framed — the encrypted result is framed as: IV + ciphertext + authentication tag.

6. Versioned — a single version byte is added at the front, so future formats stay compatible.

7. Sent — the finished package becomes one 512-byte memo, sent as one BitcoinZ shielded transaction.

One detail worth flagging: Z-TEXT signs the message before encrypting it, not after. If it did it the other way around, anyone holding the group's decryption key could strip off the real sender's signature and replace it with their own — meaning messages could be forged. Signing first closes that door.

Every trick below is a real, measured decision — not a guess.

1. MessagePack instead of JSON — roughly 40% smaller right away.

2. Integer keys instead of named keys — another ~15% smaller on top of that.

3. Sender address dropped from the payload — it's recovered from the transaction itself, for free.

4. Binary data kept as binary, never base64 text — base64 costs a third more space; a 413-byte payload becomes 552 bytes in base64, which alone would blow the entire memo budget.

5. Topic lists stored as positional arrays, not named-key maps — roughly half the cost per topic.

6. Transaction references shortened to 128-bit instead of the full transaction ID — half the length, still unambiguous.

7. Media sent as a reference, never as the actual file — a GIF becomes a few characters, not 40 KB of image data.

None of these are small technical footnotes. They're product decisions. Z-TEXT's Topics feature exists specifically because positional arrays roughly halve the cost per topic — with named JSON keys, the topic list wouldn't fit in the memo at all, and the feature wouldn't exist.

This isn't theoretical — it happened.

On August 3, a real community invite was decoded off a phone. It carried 15 fields: a viewing key, a signature, an address, an epoch key, the owner's public key, an avatar, a name, a salt, and timestamps. Total size: 430 bytes. Wrapped in its encryption envelope: 515 bytes.

The limit is 512.

Three bytes over. Three bytes is roughly the width of the word "the."

The fix: rebuild a leaner invite. Drop the avatar and description — both reach the joiner seconds later anyway, through the owner's next identity broadcast. Re-sign it. Result: 411 bytes, a 496-byte memo, and 16 bytes of headroom.

The part worth reading twice is what happened before that fix. An earlier version of the code guessed the invite was 413 bytes and assumed it fit. The guess was wrong by 17 bytes — and the feature silently failed to send, the very first time anyone used it. There's now a test that measures the real byte count on every build, so a guess can never make that call again.

No — and assuming it does can break a feature.

Compression (gzip-style) adds its own overhead: roughly 23 bytes for headers and trailers. A channel invite is mostly a signature and random keys — data that's already random-looking and can't be compressed further.

Compressing that kind of data doesn't shrink it. It adds the 23-byte overhead on top, making it bigger. On the exact payload closest to the 512-byte limit, that extra 23 bytes was enough to push it over — and the entire invite-sharing feature refused to send.

The fix: compression is never assumed. For every message, Z-TEXT checks both options — compressed and uncompressed — and keeps whichever is smaller. That choice is recorded in a single marker byte, so the receiving side always knows which format it's reading.

Some things simply don't fit in one memo, no matter how well they're packed. A post-quantum public key is 1,184 bytes — more than twice the entire memo budget. Data that large is split across several memos and reassembled by the recipient.

The interesting part is what happens if something goes wrong mid-delivery. Only the last chunk carries a signature, and that signature covers a hash of every chunk, in order. Result: a half-arrived key can never be accepted — not because Z-TEXT detects and rejects it, but because it's mathematically impossible for an incomplete key to ever produce a valid signature.

The risk being closed here isn't "a chunk arrives late." It's "a partial, unverified key gets trusted as real." The design makes that second scenario impossible by construction, not by a check that could be skipped or bypassed.

Nowhere. That's the actual answer.

There is no server holding a list of admins, bans, or pinned posts. Instead, every action — promote someone, ban someone, pin a post — is written as a signed instruction directly into the same 512-byte memo space Z-TEXT uses for messages. Every user's device independently reads the entire history of these signed instructions and calculates the same result on its own.

Three things make that possible:

1. A total order everyone agrees on — operations are sorted by block height, then transaction ID, then position within the transaction. No clocks, no coordination.

2. Signed per-sender sequence numbers — a sender's own actions can't be reordered by anyone else, including a hostile relay.

3. A deferral system for out-of-order information — if a device learns someone was promoted before it learns they joined, it holds that instruction and retries it later, rather than guessing or dropping it.

Two more details matter here. A community's identity isn't assigned by Z-TEXT — it's a cryptographic hash of the owner's key, the address, and a salt, recalculated by every joiner. And enforcement happens on the receiving side, not in the app's interface: a modified client can hide every warning button it wants, but it still can't make an unauthorized action stick, because it's every other person's device that says no.

This is why Z-TEXT is censorship-resistant by construction, not by intent. It's not a promise Z-TEXT makes — it's a property of how the system is built.

A messaging interface can be rebuilt in a month. This can't. To copy what Z-TEXT actually does, a competitor starting today would have to redo, from scratch: the byte budget, the replay engine, the ordering rules, the deferral logic, and a wire format that stays backward-compatible — all before shipping a single feature a user can see.

One example shows why this compounds. When Topics were added to Communities, the topic identifier was written into the message only when it wasn't zero. A post with no topic is byte-for-byte identical to a post made before Topics existed. Every signature ever created still verifies — a protocol upgrade that cost existing users nothing and needed no migration.

This is also why Z-TEXT can add new capability without adding a server. Every new feature is just a new signed instruction, running through the same 482-byte budget and the same replay engine already built. That's why Channels, Awards, and Communities each took weeks — not quarters.

The expensive part is built. What it makes cheap is everything that comes next. One open question Z-TEXT is actively pursuing: AI agents may need the same thing people do — a way to act and prove it happened, without exposing the private data behind it.