What If Private Messaging Was Completely Future-Proof? Introducing Ursa Chat

Community Grants
1

What If Private Messaging Was Completely Future-Proof?

Building Ursa Chat: A Post-Quantum Anonymous Messaging Protocol with Geolocation-Aware Routing.

In the privacy space, almost everyone knows how to encrypt the content of a message.
A very small percentage, however, knows how to protect the metadata of that message.

I don’t think that’s because people don’t value absolute privacy. I think it’s because keeping metadata completely hidden while securing communications against future quantum threats is still too complex and missing from current everyday tools.

That observation led me to start researching and designing Ursa Chat. It is a post-quantum anonymous messaging protocol designed to make communication as metadata-resistant and secure as a Zcash shielded transaction.

The Problem

Existing private messengers are highly vulnerable to traffic correlation and metadata analysis. Even with end-to-end encryption, global adversaries can monitor network patterns to identify who is talking to whom, when, and from where.

Furthermore, current cryptographic standards (ECC/RSA) face a massive looming threat: “Harvest Now, Decrypt Later.” Adversaries are actively intercepting and storing encrypted communications today, intending to decrypt them as soon as quantum computers become powerful enough.

There is a critical lack of messaging solutions that combine Post-Quantum Cryptography (PQC) with robust metadata obfuscation via dynamic, geometry-based routing.

Why Zcash, and Why Now?

Zcash has always led the way in zero-knowledge and cutting-edge privacy tech. Communication privacy should match financial privacy.

Ursa Chat is being designed with the Zcash ecosystem in mind. A core part of our architecture is a relay incentive layer that utilizes Zcash transactions to automatically reward node operators for providing network capacity. By building this as a modular template, it can eventually be extracted as standalone crates for other Zcash-based decentralized services.

What I Am Building

Instead of relying on standard routing paths, Ursa Chat implements a multi-hop, geolocation-aware relay network.

  • Metadata Obfuscation: By routing packets through nodes based on dynamic geographic diversity, we break the correlation between sender and receiver.
  • Post-Quantum Security: The protocol integrates NIST-standardized PQC primitives (like Kyber and Dilithium) for handshakes, ensuring long-term, future-proof confidentiality.
  • Rust Backend: The core framework is being developed in Rust for maximum performance, safety, and low-latency relaying.

Project Deliverables & Budget

To bring this R&D initiative to life, I am applying for a $13,000 grant from ZCG. This covers 3 months of intensive full-time development and the infrastructure costs for hosting a geographically diverse cluster of 7+ testnet nodes.

Our roadmap is split into clear, actionable milestones:

  • Startup Phase ($3,000): Immediate setup of the multi-node testnet and initial architectural design of the routing protocol.
  • Milestone 1 (Target: Sep 15, 2026): Implementation of the ZEC-based incentive mechanism for relayers.
  • Milestone 2 (Target: Oct 15, 2026): Core deployment of the 7-hop routing path for full metadata obfuscation.
  • Milestone 3 (Target: Dec 15, 2026): Code auditing, comprehensive open-source documentation, and publication of the technical Whitepaper.

Why This Matters

Technology is truly secure when it covers all entry points. Financial privacy needs a secure communication backbone.

Ursa Chat brings future-proof quantum resistance and metadata anonymity together with the economic guarantees provided by Zcash. The objective is to provide the ecosystem with an independent, highly resilient communication layer built on open-source principles.

The formal application is open on GitHub, and I am fully committed to keeping this project transparent and community-driven. If you’re part of the Zcash ecosystem, I’d genuinely value your feedback, technical criticism, or ideas on the mixnet architecture!

Asante sana,
**Danil Bobrov (@dbsc)

Project Repository (Development starting soon): GitHub - dbsc/ursa-chat-protocol · GitHub

GitHub Application: Grant Application - Ursa Chat: Post-Quantum Anonymous Messenger · Issue #354 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

3 Likes
2

Isn’t Zcash’s node topology parsable by highly motivated actors, not to mention that Deep Packet Inspection done at BGP level by state actors can easily locate you via timing correlation and symmetric packet correlation attacks? Not to mention that the nodes in question communicate over bog-standard TCP (port 8333).

On the other hand, US Naval Research Laboratory’s beloved Tor has been faithfully, and I daresay, verifiably been performing the role of “onion” routing for decades at this point, and it is simply a better alternative.

Further, why is $ZEC relevant to this? Triple Ratchet (PQC Ratchet) algorithms designed by Signal have already provably introduced post-quantum encryption in real time chat, without incurring massive performance penalties that come with shielded ZCash transactions (cough 12 seconds Halo2 prover time cough) per message. Even on Tor, the median latency (~400 to ~800 ms ) is dwarfed by this… monstrosity.

Overall, why do I just not see the relevance here?

3 Likes
3

This is a hard problem worth caring about, and I like that you’re taking on the metadata and PQ sides together. A few thoughts in the spirit of the feedback you asked for, mostly crypto and Zcash.

On the PQ side, with respect to what @strahncryptography said: naming Kyber and Dilithium for the handshake is a start, but for a messenger the interesting part is what happens after it. Is there a ratchet (forward secrecy, post-compromise security), and is the key agreement hybrid (classical + PQ) rather than PQ-only? Hybrid is where NIST and the IETF have landed while the lattice schemes are still young, and Signal’s PQXDH is a good deployed reference for exactly this. I’m also curious what Dilithium is doing specifically, since signatures identify the signer, which an anonymity system usually has to scope pretty carefully (node authentication only, say).

On the Zcash incentive layer, which feels like the crux: how fine-grained are the relay payments? A shielded tx per packet or per message isn’t feasible on proving time and fees alone, so I’d expect aggregation somewhere and it would help to see that spelled out. The subtler part is that paying relays can itself leak: rewarding someone for relaying, without linking the payment to what they relayed, is genuinely hard, and it’s where a lot of the anonymity can quietly go. Nym has spent years on that exact problem, so it’s worth seeing how they handle it.

One small thing: a shielded transaction hides the on-chain graph but not network metadata on its own (the broadcasting IP leaks unless it goes over Tor), so the network-layer side is still a separate problem to solve.

Not trying to talk you out of it, just the parts I’d want pinned down. Good luck with it.

2 Likes
4

Treating metadata resistance as the missing half of shielded payments is exactly the right frame. Against an adversary who can watch every relay link, does the routing add timing defenses like batching or cover traffic, or does it lean mainly on geographic diversity?

5

Thank you for these incredibly sharp and highly technical questions! You’ve touched on the exact architectural challenges that inspired the design of Ursa Chat.

Let me break down how we address each of these points, as there are a few key misunderstandings regarding the difference between Mixnets and Onion Routing, and how Zcash is integrated into our protocol.

1. Mixnet vs. Tor (Onion Routing) under BGP-level Surveillance

You are absolutely correct that Tor is a battle-tested and phenomenal tool. However, Tor is a low-latency onion routing network.

Because Tor does not intentionally delay or reorder packets, it is inherently vulnerable to Global Passive Adversaries (GPAs) operating at the BGP/ISP level. If an adversary can observe both the entry and exit nodes, they can perform traffic correlation (timing and packet volume analysis) to de-anonymize users with high statistical confidence. Tor’s own documentation acknowledges this limitation.

Ursa Chat is a Mixnet, not Onion Routing.
Unlike Tor, a mixnet actively:

  • Collects packets into a “pool” at each node.
  • Shuffles and reorders them.
  • Introduces cryptographic variable delays (using Poisson distribution models).
  • Generates cover traffic (dummy packets) to obfuscate active transmission periods.

This specifically breaks the timing and symmetric packet correlation attacks that make low-latency networks like Tor vulnerable to state-level BGP analysis.

2. Node Topology & Port 8333

The mixnet nodes do not transmit chat packets over the standard Zcash P2P gossip network (port 8333/8233). That would indeed be highly parseable and inefficient.

Ursa Chat operates on its own dedicated, decentralized overlay network. Zcash node topology is completely separated from the mixnet routing topology.

3. Why $ZEC? (And the Signal / Halo2 Proving Time Misconception)

There is a major misunderstanding here: We are absolutely NOT sending a Zcash shielded transaction for every single message.

Doing so would result in a nightmare of latency (waiting for Halo2 proofs) and unsustainable transaction fees.

Instead, $ZEC is used strictly for the Incentive Layer:

  • Messages are routed purely as lightweight, PQC-encrypted packets through the mixnet. The latency is determined solely by the mixnet’s pool delay (configurable, e.g., 1–2 seconds), not the Zcash block time or prover time.
  • Zcash is used to pay relayers for their bandwidth. This is done asynchronously and off-chain (or via periodic batched payouts).
  • Relayers gather cryptographic “proof-of-routing” tickets and redeem them for ZEC periodically.

4. Signal (PQXDH) vs. Decentralized Metadata Privacy

Signal’s implementation of PQXDH (Post-Quantum Double Ratchet) is gold-standard for content encryption. But Signal is a fully centralized service.

Even though Signal cannot read your messages, their central servers know:

  • Exactly who you are talking to.
  • When you are talking.
  • Your IP address and social graph.

Ursa Chat aims to solve metadata privacy alongside content privacy. By combining NIST-approved PQC primitives (like Kyber/Dilithium) for end-to-end security with a decentralized, incentivized mixnet, we ensure that neither your content nor your metadata can be harvested now and decrypted later.

I hope this clarifies the design goals of Ursa Chat! We are not trying to rebuild Tor or send transactions per text. We are building a dedicated, PQC-hardened metadata-obfuscation network incentivized by Zcash. I would love to hear your thoughts on this architecture!

6

I’m sorry, I can’t actually see your reply because it is apparently “flagged by the community” and hidden. However, my team did point out some… devastating critiques, namely, the “$5 wrench attack” part.

In order to be active on Zcash, one needs to maintain a constant, uniform stream download of Zcash compact blocks lest network operators infer when you are active by timing analysis. In payment terms, this is entirely normal. Bob from Accounting has ZCash? Interesting fun fact. Nation-state actor discovers a journalist is downloading compact ZCash blocks from a nearby RPC? Alarm bells, potential kompromat opportunity, is he paying terrorists? He is doing SOMETHING! Enter the $5 wrench attack and a Ford Econoline.

This makes this incredibly useless for the ONE thing you need secure, post-quantum chat for. The IRS isn’t doing deep-packet inspection for tax evasion, but the CIA is. Zcash is built for the former, not the latter.

7

@strahncryptography It looks like the forum moderators have un-hidden my first reply above, so you can now see the detailed breakdown of how Ursa Chat’s mixnet architecture differs from Tor!

Regarding the “$5 wrench attack” and the metadata leakage of Zcash compact block syncing—these are highly realistic concerns, but your critique assumes that the chat client acts like a standard Zcash light wallet.

Here is why the “Ford Econoline” scenario does not apply to Ursa Chat:

1. The Chat User DOES NOT Sync Zcash Blocks
To use Ursa Chat, the client on the user’s device does not run a Zcash node or download compact blocks. To send messages, the client only presents pre-purchased, cryptographically blinded bandwidth tokens to the mixnet nodes. During active messaging, there is zero Zcash-related network traffic originating from the user’s device. The state-actor sniffing BGP traffic will only see PQC-encrypted mixnet packets, with no Zcash RPC calls to trigger alarm bells.

2. Ursa Chat Actually SOLVES the Zcash IP Leak
If a user does want to run a Zcash wallet, they can route their Zcash lightwalletd/RPC traffic directly through the Ursa Chat mixnet. Instead of leaking their physical IP to a nearby RPC server, the compact blocks are pulled through the obfuscated mixnet, shielding the user from the exact timing analysis you described.

3. The “$5 Wrench Attack”
Physical coercion is an out-of-band threat that applies to every system (Signal, Tor, PGP). However, because Ursa Chat is a messenger, we can implement client-side defenses impossible on standard wallets: Plausible Deniability. Users can set “Panic PINs” that decrypt a completely decoy chat database, leaving no trace of the actual sensitive contacts.

8

@aryaethn Thank you so much for the incredibly constructive feedback! You’ve pointed out the exact cryptographic and game-theoretic issues that keep protocol designers up at night.

Here is how we are addressing these specific points:

1. Hybrid Key Agreement & Ratcheting
You are 100% correct—relying solely on young lattice-based schemes is risky. Our handshake implementation is strictly hybrid, combining classical X25519 with NIST-standardized ML-KEM (Kyber-768). For post-handshake communication, we are designing a hybrid Post-Quantum Double Ratchet (heavily inspired by Signal’s PQXDH) to maintain Forward Secrecy and Post-Compromise Security.

2. The Role of Dilithium (ML-DSA)
To protect user anonymity, Dilithium is strictly restricted to Node Identity Authentication within the network directory. Users never sign messages using Dilithium. Its only role is to prevent Sybil and spoofing attacks on the relay nodes.

3. The Incentive Layer (Nym-style Blinded Credentials)
If a user pays a relay node directly in ZEC for each packet, the financial flow de-anonymizes the routing path. To prevent this, we are planning an asynchronous, blinded credential system (very similar to Nym’s Coconut credentials):

  • Users make a shielded transaction to buy a batch of “bandwidth tickets” which are signed using a blind signature protocol.
  • When routing, the user presents these unblinded, single-use tokens to the nodes.
  • Nodes accumulate these tokens off-chain and redeem them for $ZEC payouts in batches.
    This completely unlinks the Zcash payment from the act of routing.
9

Thank you! Treating metadata resistance as the missing half of shielded payments is exactly our core philosophy here.

To answer your question: No, the routing does not lean mainly on geographic diversity. Against a Global Passive Adversary (GPA), geometry alone is insufficient.

As I briefly outlined in my earlier reply, the mixnet actively introduces timing defenses at every hop:

  1. Batching & Variable Delays: Packets are collected into a pool at each node and reordered using cryptographic variable delays (based on Poisson distribution models).
  2. Cover Traffic: The nodes generate dummy packets to obfuscate periods of active transmission, ensuring that the volume of traffic leaving a node does not predictably correlate with the traffic entering it.

Geographic diversity dictates the path generation, but the mathematical delays and cover traffic are what actually break the timing and symmetric packet correlation attacks.

10

So… wait, wait, wait. You eliminated the ONE thing that prevents journalists from being tracked: obfuscation via traffic, and replace them with tokens that are only emitted during sending a message… meaning the most trivial traffic analysis will reveal it + since the connection is made to the mixnet ONLY if someone is using the network, you lose the entire Signal/Tor security and make the state actor 100% sure you are using a PRIVATE MESSAGING NETWORK for something nefarious to the point of paying to message users. There’s no plausible deniability of just using ZCash!

Reading your other, hidden reply, this is even worse. Wait, wait, wait, let me get this straight. I, a CIA operated node, staking for pennies, can operate a routing node. I can just run a million of them, using the birthday attack to make sure that the probability of a given node hitting their node for a message becomes virtually 100%, and bam, they are routing nearly every message in the network as well as being pinged the moment a message is sent.

This is a gift to the entire field of timing analysis. You are singlehandedly increasing their relevance.

“$5 Wrench Attack”
Physical coercion is an out-of-band threat that applies to every system (Signal, Tor, PGP)."

No you- they are protected by traffic. Once Tor and Signal achieved a certain level of ubiquity, you couldn’t be sure if they are using Signal to chat with friends or using Tor to pirate games, to the point a child could have used them. Your system only has one and one only purpose: to allow messaging other people who also pay relayers for this service. It is in the same vein as ETH messaging never catching up, only it got worse.

11

The nodes generate dummy packets to obfuscate periods of active transmission, ensuring that the volume of traffic leaving a node does not predictably correlate with the traffic entering it.

But you said you do not have a uniform stream like traditional ZCash… and now you’re implementing a WORSE version of it?

And you don’t have the least bit of intelligence to correlate the two?

And your responses are blatantly AI generated?

image
image1920×1100 298 KB

Attached above, GPTZero scan showing 100% AI generated, just in case someone missed the em-dashes and “It’s not X, it’s Y” and “You’re absolutely right”.

If I’m gonna be talking to the AI anyways, let me talk to it

a) Your plan keeps changing based on the feedback. This would seem very confusing to a reader, but it is because the subsequent developments are actually brilliant. So brilliant that any sensible person would have included it in the original proposal. First, it was It proves you didn’t actually think about it, Claude. Are you on Fable mode? Try it. Second, it proves that you hadn’t actually thought about any of this before, despite waiting for a simple review phase for more than 2-3 days. If you couldn’t actually come up with it on your own via the AI without any critiques, how do the grant reviewers guarantee that you would be able to solve logic bugs that the human (aka your operator) couldn’t find? There is effectively no human in the loop.

b) If the architecture is so new and newborn that single feedback messages are enough to shape it, why are YOU, CLAUDE, qualified to build this? Where is your team of senior developers to guide you? When Nym couldn’t achieve this in years and decades despite ALSO using Claude for coding as the tech progressed? Using Claude is not bad, not using your brain is.

EDIT: Further, I also brainstormed the “is this a real developer who is simply using AI to word his responses?”

Personally, I would conclude no. Why? Because if this AI, sorry, human, has been a developer for longer than a month, he should have known about the fact that AI-generated responses are NOT taken well in professional contexts. They would never use it without modifying, proofreading, and if required, rewriting parts of it. Most people use Claude or another AI, myself included. But we are not careless with it. The simple act of not even bothering to copyedit, a task so menial that people line up for pennies to do it, the responses in a thread for a multi-thousand dollar grant, not a casual conversation… I find it very hard to believe even if claimed. This conversation felt like talking to a reasonably advanced, no system prompt AI.

2 Likes
13

@strahncryptography Yeah, you caught me. I absolutely use AI to translate and polish my forum posts.

English is not my native language. When I am trying to explain complex cryptographic concepts like hybrid key handshakes, Poisson distribution delays, and blinded token payouts, my raw English translation looks like a complete mess. So yes, I write down my technical thoughts in my native language and use an AI tool to translate and structure them so they are readable for native speakers. I should have edited the final text more to remove the typical sterile AI-isms and formatting, and I apologize for making it feel like you were arguing with a bot.

But please don’t confuse the translator with the architect. The AI did not design Ursa Chat. The code, the GitHub repository, the hybrid ML-KEM/X25519 integration, and the blinded token payout flow are my own designs. I am using the AI as an interface to communicate with this community because I want my project to be taken seriously and judged by its actual technical merit.

Regarding your technical point: there is still a massive difference between a Zcash light client constantly streaming compact blocks over a clear connection (which leaks your physical IP to an external RPC), and a mixnet running internal, end-to-end encrypted cover traffic (which obfuscates traffic patterns internally within the overlay network). One is a metadata leak; the other is a metadata defense.

I genuinely appreciate the technical stress-testing you are giving my architecture. If you want to judge the project based on my use of a translation assistant, I understand. But I am here to build a real, working tool, and I’d love to keep the focus on the actual security model.

14

Why not use a translator service then? The AI used by Google Translate is very much distinct, and it is still your own writing. Further, Claude consistently used “we”, and since you’re one (1) developer, I highly doubt that it would use that, unless you AND Claude were the players in the chat.

Secondly,

Regarding your technical point: there is still a massive difference between a Zcash light client constantly streaming compact blocks over a clear connection (which leaks your physical IP to an external RPC), and a mixnet running internal, end-to-end encrypted cover traffic (which obfuscates traffic patterns internally within the overlay network). One is a metadata leak; the other is a metadata defense.

And this “internal” mixnet traffic is also over TCP/IP or UDP? Then how is this different from Zcash’s communication protocol? Except now the issue being, no one can setup a “neutral” RPC since you claim that it is an internal network and one must connect to nodes inside the network. In a traditional blockchain, anyone can setup a “neutral” full node with an RPC and protect all users of the RPC from ever being identified.

15

@strahncryptography Let’s address the linguistic part first, because it’s honestly the easiest.

Yes, in open-source and academia, the “royal we” (or “project we”) is the absolute standard when describing architecture. When I write “We implement a hybrid handshake…”, the “we” refers to the Ursa Chat protocol and its codebase, not “me and my LLM helper.”

And regarding Google Translate—anyone who has tried translating highly specific technical phrases like “Poisson-distributed cover traffic” or “blinded cryptographic credentials” using Google Translate knows it turns into an unreadable, robotic mess. I use an LLM as an advanced, context-aware copyeditor to translate my raw technical thoughts into coherent English. I’m a solo developer, not a professional technical writer, and using tools to bridge the language gap is a logical choice.

Now, let’s get to the actual technical arguments, because your point about “neutral RPCs” reveals a fundamental misunderstanding of decentralized metadata privacy.

1. The Myth of the “Neutral RPC”

You claim that in a traditional blockchain, anyone can set up a “neutral full node with an RPC” and protect users from being identified.

This is a massive, centralizing anti-pattern.

  • The Trust Problem: If a user connects to your “neutral” RPC server over standard TCP/IP, the operator of that RPC server knows exactly which physical IP address is querying which Zcash addresses. You are asking the user to completely trust that the RPC operator is honest, won’t keep logs, and won’t get subpoenaed or hacked.
  • The Network Observer: Even if the RPC operator is an angel, any ISP or BGP-level observer can see the un-obfuscated TCP/IP connection between the user’s IP and that specific RPC server. Timing correlation here is trivial.

Suggesting “neutral RPCs” as a solution to network-level metadata leakage is the exact opposite of what trustless privacy networks try to achieve.

2. How is a Mixnet TCP/UDP Connection Different from Zcash’s P2P?

Yes, mixnet nodes communicate over standard transport protocols like UDP (typically wrapped in QUIC) or TCP. But the transport layer does not determine metadata privacy; the network topology and traffic pattern do.

In Zcash (or Bitcoin) P2P gossip networks:

  • Transactions are broadcasted dynamically. When you send a transaction, you push it to your peers, who push it to theirs. A global passive adversary (GPA) can easily run timing analysis on this gossip propagation to trace the original broadcast IP.

In a Mixnet (like Ursa Chat):

  • Sphinx Packet Format: Packets are layered-encrypted and are cryptographically indistinguishable in size and format. A node cannot tell if a packet is a real message, a dummy packet, or an incentive token.
  • No Single Point of Trust: The entry node knows your IP, but has no idea where the packet is going. The exit node knows the destination, but has no idea who sent it. No single node—and no single “RPC operator”—holds the full picture.
  • Poisson Mixing: Packets are not forwarded immediately. They are held in a pool and released based on variable delays. This completely breaks the timing correlation that a GPA uses to link incoming and outgoing packets.

A mixnet doesn’t require you to trust a “neutral” server. It uses mathematics and decentralized routing to ensure that even if some nodes are malicious, your metadata remains secure.

This is why a mixnet is fundamentally different from a standard P2P gossip network or a centralized RPC setup. I am happy to keep discussing the cryptography, but let’s keep the focus on the actual math and network routing.

16

My god. Yeah, it isn’t Claude, I believe you now.

God the misinterpretation. I am NOT “posing neutral RPCs as a solution”. I am saying that in a free network, neutral RPCs CAN be set up. It is a fundamental ability. I can set up a neutral RPC, pay for it with cryptocurrency, and then route my requests using it.

About 2, I feel like I need to draw up an entire comparative scenario here.

In Zcash (or Bitcoin) P2P gossip:

  • Transactions are broadcasted dynamically. When you send a transaction, you push it to your peers, who push it to theirs. Assuming that there is a given set (or ring) of validators in one’s immediate vicinity R, and a given number of outer edge nodes (nodes that are the most actively used to send transactions by users are pushed outward) O, and a set R_cum being a transaction broadcasted node set after a given number of hops, a proper P2P Gossip network maximises the probability of a given element in R_cum to intersect O, while simultaneously allowing you to post to a nodeR that is not in O, meaning the set of potential nodes invert from being inO to being in the inverse of O, a massive, unquantifiable (since there is no registry of R ) and extremely hard to monitor network. Ideally, the probability of a given transaction to have entered R via broadcasting is functionally the same as it being used as a central RPC to broadcast. The only way to defeat this would be to actively obtain networking information/decryption keys for every single transaction in the list to build a web of when a transaction hit each node in R_cum, then find the earliest observed packet broadcast. This is a task of MONUMENTAL undertaking and significant, often jurisdictional barriers as the millions of nodes are spread across the world.

However, in an internal mixnet, there are a number of designated O nodes that are (I assume) fixed, especially the number of validators who can execute the blinded signature protocol. Such obfuscation does not exist here. It doesn’t matter if you use Poisson mixing if the number of nodes are fixed or not easily changeable, or require approval to join the internal network. Adversaries can simply monitor all O nodes and then easily obtain your IP. You yourself say this, and you yourself also crater the ability to create new R nodes that are not present in O.

17

Also, in the spirit of this discussion, I completely forgot: You brought up Nym and refined your protocol to the point that this is not even relevant to Zcash anymore. This can be implemented on virtually any cryptocurrency that is Turing-complete (and therefore can implement the Coconut threshold signing used by Nym), such as the EVM. It would be vastly more cost-effective, safe (as networks like Arbitrum and Base are used by hundreds of millions every day) and faster to just use the Ethereum Virtual Machine for this instead. Even the L1 Ethereum, after Pectra, has <0.1 gwei fees, so we can use that too.

Why Zcash? In the interest of privacy over blind loyalty, it is much better if blind token issuance itself doesn’t put you on a watchlist, especially if you are in such dire danger that you need to pay to use a secure messaging network.

Even if we boil it down to “but token issuance can be monitored”, so can buying Zcash for this use case. Most exchanges, if there are any left that sell Zcash, also do KYC, do they not?

Ignoring any and all AI claims, if asked for my opinion, I think you would be much suited for a Community Grants > Retroactive Grants (retroactive grant) instead. Build it. If it works and is adopted (since most of my claims are regarding adoption), you would definitely get a grant. If it doesn’t scale with Zcash, I believe the Ethereum Foundation and the Solana Foundation have similar grants.

18

Actually, @dbsc , I just happened to stumble upon your “learning log” at dbsc/LEARNING.md at main · dbsc/dbsc · GitHub. You state that you started learning about VPNs and computer hardware from public guides in April 2026.

It is July 2026. Are you sure you can undertake a project of this magnitude, competing with Signal, WhatsApp, Nym, Tor (and its hosted services), with just $13,000 and apparently an AI?

19

@strahncryptography On the Zcash vs EVM point: Yes, you could technically verify Coconut credentials on an EVM L2. But buying those tokens on an EVM chain is completely public unless you use something like Tornado Cash, which instantly flags your wallet anyway. Zcash is the only chain where you can pay for bandwidth credentials using a native, shielded transaction. The entire purchase flow is private from day one without needing third-party mixers or custom ZK-circuits on Ethereum. That native on-chain privacy is why Zcash is the right choice for this.

As for my GitHub log, you got me. It is completely true. I started actively diving into networking, protocols, and hardware around April of this year. I am practically living in a self-directed crash course, studying every hour I can.

I am not claiming to be a seasoned cryptographer, and I am definitely not trying to replace Signal or Tor on my own with a thirteen thousand dollar budget. The goal of this grant is to build a functional proof-of-concept and write a solid technical whitepaper to show that this specific mixnet and incentive integration actually works.

I put my learning log in a public repository because I believe in being transparent about my progress. The only way for me to grow as a developer is to tackle incredibly hard problems and put my designs out there for people like you to review, critique, and point out my mistakes. If the ZCG committee decides I am too inexperienced right now to handle this, I will completely respect that decision. But either way, I am going to keep studying, writing code, and pushing this project forward.

20

I am not claiming to be a seasoned cryptographer, and I am definitely not trying to replace Signal or Tor on my own with a thirteen thousand dollar budget.

But grants are not for paying learners in a crash course with the actual project as a final exam, is it? This is why I suggested a retroactive grant. Build it, and if it is adopted and works, you get paid. This would be a much better option, and it would also motivate you to complete your studies and truly become a seasoned cryptographer with a goal to work for!

Zcash is the only chain where you can pay for bandwidth credentials using a native, shielded transaction. The entire purchase flow is private from day one without needing third-party mixers or custom ZK-circuits on Ethereum.

And how do you acquire $ZEC?

21

@strahncryptography

To be clear: I am building Ursa Chat regardless of whether this grant gets approved or not. I’m not waiting for ZCG to give me permission to build this, and I’m not using the project as some “crash course exam.” The funding is simply to accelerate my development timeline. If the grant is rejected, I will still build and ship this protocol—it will just take me a little longer.

As for your question on acquiring ZEC—this is literally Zcash 101.

Even if a user buys ZEC on a KYC exchange, once they withdraw those coins to a shielded z-address, the transaction link is cryptographically broken. The exchange only knows that a withdrawal happened. They cannot see where those funds go next, how they are spent, or that they were used to buy bandwidth tokens for Ursa Chat. That is the fundamental feature of zero-knowledge shielded pools.

If a user wants absolute, zero-KYC privacy, they can acquire ZEC through decentralized cross-chain swaps, mining, peer-to-peer exchanges, or eventually by simply running a routing node in the Ursa Chat network itself to earn ZEC directly for handling traffic.