RFI - Shielded Messaging (Not your Keys, Not your Messages)

Note: this project description was initially drafted earlier this year as a ZCG RFP, however, as ZCG is not currently committed to funding Shielded Messaging and therefore not actively soliciting bids, I am posting this here instead for discussion and posterity, as something we may be willing to fund in the future.

See also previously rejected but similar grant submission Zemo: Shielded Messaging


Zcash presents the opportunity, via its memo field, to provide secure, private messaging, arguably superior even to Signal, and other alternatives which, although end-to-end encrypted, have centralization dependencies, man-in-the-middle susceptibilities, and spam potential. However, there are constraints making it not immediately obvious how best to use the memo field in this way: space, time, cost, and connectedness of messages (eg. threading).

The envisioned project deliverables would include

  • a detailed design document outlining a protocol addressing specific features described below,
  • security and usability analyses where appropriate,
  • a demonstration of implementation on an existing wallet

(Rather than building a new, standalone app, I suggest a smaller iteration as a proof of concept that can be used on existing infrastructure, but could later be the basis of a message-focused app. This is partly because the shielded messaging use case will depend for adoption on solving current syncing and scaling issues, and partly because ZCG prefers to allocate funding for protocol development and apps/wallets separately.)


The memo field is limited to 512 bytes, so by itself cannot carry long messages or high-information-content images. The protocol design should specify standard ways to either combine messages, or optionally to use out-of-band file storage and operate by transmitting capabilities to files, such as with IPFS, Magic Wormhole, or Tahoe-LAFS, and demonstrate how this would work in practice.


Zcash transactions are fast, but not real-time. This limits usability in situations where essentially instantaneous turnaround time is a user expectation. However, it is compatible with more asynchronous communications. In communications where such time gaps exist, there is an increased likelihood that response chains are heavily branched due to “simultaneous” responses, especially in multi-party contexts. This may impact threading intuitions. Innovative protocol design that copes with delays, as is seen in space communications (eg. [1]) may be desirable.


Some community members have expressed skepticism that people would be willing to adopt a messaging system that entails a transaction cost, no matter how small. However, many are coming to realise that most information systems we currently use exact their costs in privacy and data access, as well as content moderation and manipulation. But beyond willingness to pay for such freedoms, the inherent micropayment associated with memo transactions can be seen as a feature, not a bug.

In particular, using micropayments on messaging systems has historically been a suggested mechanism for coping with unsolicited messaging–spam and phishing, by making the cost of broadcasting messages infeasible[2-4]. Not only could it be prohibitively expensive to send unwanted messages, but voluntary extra fees could be used as a filter, such that the recipient is not even alerted about messages that do not meet a threshold of payment [2]. The protocol could also implement an ACK system that returns voluntary excess payment to senders whose messages have been accepted, but not those whose messages are unwelcome.

The shielded messaging protocol design should make use of the transaction cost such that it is clearly providing value to the participants, rather than being an unfortunate side effect.


A feature that is considered fundamental in messaging systems is threading. This entails recognizing that messages are from the same sender, and intended as responses. Sender authentication is beyond the scope of this proposal (covered in the Zcash Memo Field Secure Messaging Extension RFP), but threading is an important feature to be standardized.

Potential Dependencies:

  • Syncing and scaling: because of the expectation of real-time interaction in messaging, messages over the Zcash blockchain may be more comparable to email or file-transfer/sharing systems than text messaging, however, if syncing times are decreased even with high transaction rates, this gap would narrow.
  • Secure message authentication of senders: the would relieve the need to address authentication as part of this protocol
  • Oblivious message retrieval: as with payments in general, messaging lookup is susceptible to traffic analysis (see Oblivious Message Retrieval)

[1] Braiding – A novel approach to supporting space/ground communication under signal latency)

[2] Cypherpunk mailing list (2005): Re: How to Stop Junk E-Mail: Charge for the Stamp

[3] Peer-To-Peer: Harnessing the Power of Disruptive Technologies Chapter 16: Accountability (2007)

[4] Bitcoin Forum (2012): Topic: include messages in transaction, alternate use: anti spam email


I think this blog does a good job at describing the challenges of message encryption.

Btw, ywallet uses age for its backup encryption.

I’m not sure which parts of this you’re suggesting would apply to messages on Zcash. Want to explain a little more?

  1. Making a secure messaging system is very hard: Look at PGP vulnerabilities.
  2. It’s unclear to me what use cases the zcash solution would solve. The blog goes on to describe existing apps for several common use cases. For example, messaging → Signal. Also, there is the network effect. 9/10 of my friends are on Signal/Whatsapp.
  3. Once you factor in the constraints you mentioned that are imposed by the zcash protocol, what advantage does it have?

As to point 1. while I agree that encryption is hard, we’re not starting from scratch here. If you’re questioning the ability of Zcash to provide the necessary encryption, then I’ve gotta question why you use Zcash at all.

Re 2. of the reasons the article gives for choosing Signal, all of them are also solved using Zcash, because again they are about encryption problems.

On 3. as I outlined above, Zcash messages would indeed have one major disadvantage compared to Signal, and that’s timing.

But it also could have advantages. My most paranoid cypherpunk friend won’t use Signal. Why? It depends on phone numbers and trivially traces your message network not only with certainty but to True Names! That’s a pretty serious leak, even though the contents aren’t revealed.

I also outlined the micropayment advantage, which I think is the core advantage, actually.

Yes, I agree networking effects are definitely a problem. That’s also a problem with Zcash generally.

To add one more response to the article:

For file transfer, they suggest using Magic Wormhole. I agree that MW is awesome for that which is why I listed it in the RFI. But MW actually requires an out of band signal to send the codes. Zcash memo fields is a good option for this, in my opinion.

I am a bit surprised that you are questioning my opinion about zcash encryption here. This seems uncalled for and honestly, defensive.

Zcash memos (messages) are persistent and permanent on the blockchain.

Oh, I’m sorry. That’s not what I intended at all!

I meant to say that since you obviously don’t question Zcash encryption, it doesn’t make sense to question messages on Zcash for encryption reasons.

I only said it like that because I thought it was obvious that no one, including I, would ever seriously think you weren’t confident in Zcash encryption.

My apologies for the confusion.

No problem. To answer your question, building a secure chat messaging system is much more complicated than sending short encrypted memos on the Blockchain. There are plenty of ways to shoot oneself in the foot even with a solid foundation.

Has your friend tried Session? It is based on Signal but doesn’t use phone numbers. You have a seed phrase instead.