From 77163628193624b049233770a3ac70bac3de830e Mon Sep 17 00:00:00 2001 From: Francisco Gindre Date: Mon, 23 Feb 2026 20:43:16 -0300 Subject: [PATCH 1/6] Add Use cases for Authenticated Reply-to addresses and Application layer also includes Suggestions by Daira-Emma and Str4d (via DM) the origin of these changes start in this PR: https://github.com/zcash/zips/pull/1185 --- zips/zip-0231.md | 40 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/zips/zip-0231.md b/zips/zip-0231.md index f3760e301..4709fbaf9 100644 --- a/zips/zip-0231.md +++ b/zips/zip-0231.md @@ -75,7 +75,7 @@ hides the sender(s) (that is, the addresses corresponding to the keys used to spend the input notes) from all of the recipients. For certain kinds of transactions, it is desirable to make one or more sender addresses available to one or more recipients (for example, a reply address). In such circumstances it -is important to authenticate the sender address(es), to give the recipient a +is important to authenticate the sender addresses, to give the recipient a guarantee that the address is controlled by a sender of the transaction; failure to authenticate this address can enable phishing attacks. These Authenticated Reply Addresses require zero-knowledge proofs, and for the @@ -119,6 +119,44 @@ recipient. By separating memo data from the decryption capability for those memos, it admits a greater variety of applications that utilize memo data, while decreasing the amount of data that needs to be stored on-chain overall. +# Use Cases + +## Authenticated Reply-to addresses +In a peer-to-peer transaction Bob and Alice can split a lunch check. +Bob can send a shielded memo to Alice that says "Nice Lunch! It was fun! this +is my half + tips. Hugs, Bob.". Bob would show Alice his transaction detail in +his wallet and Alice can visibly check hers and verify that the memo contained +in that transaction was authored by Bob. That in-person manual verification +process is only valid for that one transaction. Anyone that knows that Bob and +Alice exchanged messages over Zcash memos, can leverage this channel to send a +memo to Alice in trick her into thinking Bob sent it. Alice's wallet has no way +to judge the authorship of any of the received messages. + +If Bob's wallet had the capability to prove the authorship of a message. Alice's +wallet could help her notice such proof and guide her to either validate and +save Bob's authorship proof to her address book, or reject it. The rationale of +this use case is that application developers can use this mechanism to build a +user experience that can help user tell apart trustworthy memos from those +whose origin is undetermined. + +It has to be noted that providing a mechanism for wallet applications to attach +data that can help prove the origin of a transaction through the memo field will +not avoid that spoofers attempt such attacks. Spoofers can attach their authorship +proof. Additional verification steps would be needed to verify these authenticated +memos which are not part of the scope of this ZIP. + + +## Memos as input for application layer +Using unverifiable memo data as input for business logic is not safe. Repeatedly, +application developers have discussed memos an on-chain data layer for +privacy-minded software such as Instant (or ansynchronous) messaging applications +or marketplaces. These applications require that the memo field information can +be _trusted_ and therefore be treated as _actionable_ data by the application +business logic. Without such mechanism the application does not have a way to +choose which messages should be trusted and whichones shall be ignored. Although +all input must be sanitized before being used, the ability to attach proofs to +memos provide application developers with mechanisms to distinguish user intent +from arbitrary memos generated outside the application domain. # Privacy Implications From 0a7a8232360a729c8e30808db5f1a8d61a20c7ce Mon Sep 17 00:00:00 2001 From: Francisco Gindre Date: Tue, 24 Feb 2026 17:07:45 -0300 Subject: [PATCH 2/6] Further improvements. Adding ZecHub Newsletter use case --- zips/zip-0231.md | 44 ++++++++++++++++++++++++++++---------------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/zips/zip-0231.md b/zips/zip-0231.md index 4709fbaf9..bdab8c47d 100644 --- a/zips/zip-0231.md +++ b/zips/zip-0231.md @@ -123,28 +123,28 @@ while decreasing the amount of data that needs to be stored on-chain overall. ## Authenticated Reply-to addresses In a peer-to-peer transaction Bob and Alice can split a lunch check. -Bob can send a shielded memo to Alice that says "Nice Lunch! It was fun! this +Bob can send a shielded memo to Alice that says "Nice Lunch! It was fun! this is my half + tips. Hugs, Bob.". Bob would show Alice his transaction detail in his wallet and Alice can visibly check hers and verify that the memo contained in that transaction was authored by Bob. That in-person manual verification -process is only valid for that one transaction. Anyone that knows that Bob and -Alice exchanged messages over Zcash memos, can leverage this channel to send a -memo to Alice in trick her into thinking Bob sent it. Alice's wallet has no way -to judge the authorship of any of the received messages. - -If Bob's wallet had the capability to prove the authorship of a message. Alice's -wallet could help her notice such proof and guide her to either validate and -save Bob's authorship proof to her address book, or reject it. The rationale of -this use case is that application developers can use this mechanism to build a -user experience that can help user tell apart trustworthy memos from those -whose origin is undetermined. +process is only valid for that one transaction. Anyone that knows Alice's address +and the fact that she exchanged messages over Zcash memos with Bob could spoof a +shielded memo impersonating Bob. Neither Alice or her wallet have a to judge the +authorship of any of the received messages. + +If Bob's wallet had the capability to prove the authorship of a message, Alice's +wallet could help her notice such proof attempt. The rationale of this use case +is that application developers can use this mechanism to build a user experience +that can help user tell apart trustworthy memos from those whose origin is +undetermined. It has to be noted that providing a mechanism for wallet applications to attach data that can help prove the origin of a transaction through the memo field will -not avoid that spoofers attempt such attacks. Spoofers can attach their authorship -proof. Additional verification steps would be needed to verify these authenticated -memos which are not part of the scope of this ZIP. - +not prevent that spoofers attempt such attacks. Spoofers can attach authorship +proof as well. Therefore, this proving data is not self-sufficient to determine +that the author of a shielded memo should be trusted. Further verification +steps would be needed to determine a such a level of trust. These additional +steps are outside of the scope of this ZIP. ## Memos as input for application layer Using unverifiable memo data as input for business logic is not safe. Repeatedly, @@ -158,6 +158,16 @@ all input must be sanitized before being used, the ability to attach proofs to memos provide application developers with mechanisms to distinguish user intent from arbitrary memos generated outside the application domain. +## Broadcasting a newsletter +The ZecHub DAO runs a "Shielded Newsletter" service [^shielded-newsletter]. Users subcribe by sending a +one-time subscription fee with a memo that tells the service where to send the +newsletter to. Memo bundles with allow such a newsletter to avoid chain bloat by +making subscribers share a single key to decrypt a single memo instead of sending +individual memos to each one of them. Additionally by requiring subscribers to +prove the authorship of their subscription memos, the newsletter can verify that +the recipient address indicated in the memo is indeed the author of the subscription +and not a subscription bot attempting to make a sybill attack against the service. + # Privacy Implications Prior to the activation of this ZIP, every shielded output has an associated @@ -854,3 +864,5 @@ TBD [^pczt]: [zcash/zips issue #693: Standardize a protocol for creating shielded transactions offline](https://github.com/zcash/zips/issues/693) [^rfc-8439]: [RFC 8439: ChaCha20 and Poly1305 for IETF Protocols](https://www.rfc-editor.org/rfc/rfc8439.html) + +[^shielded-newsletter]: [ZecHub Shielded Newsletter](https://zechub.wiki/newsletter) \ No newline at end of file From fe2efbffc09bf8da99a31d56b0fdb0efed63246f Mon Sep 17 00:00:00 2001 From: Francisco Gindre Date: Tue, 24 Feb 2026 17:32:27 -0300 Subject: [PATCH 3/6] Add unsubscription scenario to the newsletter case plus other corrections --- zips/zip-0231.md | 41 +++++++++++++++++++++++------------------ 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/zips/zip-0231.md b/zips/zip-0231.md index bdab8c47d..470d6835f 100644 --- a/zips/zip-0231.md +++ b/zips/zip-0231.md @@ -129,44 +129,49 @@ his wallet and Alice can visibly check hers and verify that the memo contained in that transaction was authored by Bob. That in-person manual verification process is only valid for that one transaction. Anyone that knows Alice's address and the fact that she exchanged messages over Zcash memos with Bob could spoof a -shielded memo impersonating Bob. Neither Alice or her wallet have a to judge the -authorship of any of the received messages. +shielded memo impersonating Bob. Neither Alice or her wallet have an aid to judge +the authorship of any of the received messages. If Bob's wallet had the capability to prove the authorship of a message, Alice's wallet could help her notice such proof attempt. The rationale of this use case is that application developers can use this mechanism to build a user experience -that can help user tell apart trustworthy memos from those whose origin is -undetermined. +that can help users tell apart trustworthy memos from those whose origin cannot +be certainly determined. It has to be noted that providing a mechanism for wallet applications to attach data that can help prove the origin of a transaction through the memo field will not prevent that spoofers attempt such attacks. Spoofers can attach authorship proof as well. Therefore, this proving data is not self-sufficient to determine -that the author of a shielded memo should be trusted. Further verification +that the author of a shielded memo shall be trusted. Further verification steps would be needed to determine a such a level of trust. These additional steps are outside of the scope of this ZIP. ## Memos as input for application layer -Using unverifiable memo data as input for business logic is not safe. Repeatedly, -application developers have discussed memos an on-chain data layer for +Using unverifiable memo data as input for business logic is unadvisable. +Repeatedly, application developers have discussed memos an on-chain data layer for privacy-minded software such as Instant (or ansynchronous) messaging applications or marketplaces. These applications require that the memo field information can be _trusted_ and therefore be treated as _actionable_ data by the application -business logic. Without such mechanism the application does not have a way to -choose which messages should be trusted and whichones shall be ignored. Although -all input must be sanitized before being used, the ability to attach proofs to -memos provide application developers with mechanisms to distinguish user intent -from arbitrary memos generated outside the application domain. +business logic. Without such a mechanism the application does not have a way to +choose which messages should be trusted and which ones shall be ignored. The +ability to attach proofs to memos provides application developers with mechanisms +to distinguish plausible user intent from arbitrary memos generated outside the +application domain. ## Broadcasting a newsletter The ZecHub DAO runs a "Shielded Newsletter" service [^shielded-newsletter]. Users subcribe by sending a -one-time subscription fee with a memo that tells the service where to send the -newsletter to. Memo bundles with allow such a newsletter to avoid chain bloat by -making subscribers share a single key to decrypt a single memo instead of sending -individual memos to each one of them. Additionally by requiring subscribers to +one-time transaction with a subscription fee and a shielded memo that tells the +service where to send the newsletter to. As discussed in the motivation section, +Memo bundles with help the newsletter service to avoid chain bloat by enabling +subscribers to share a single key to decrypt a single memo instead of sending +individual memos to each one of them. Additionally, by requiring subscribers to prove the authorship of their subscription memos, the newsletter can verify that -the recipient address indicated in the memo is indeed the author of the subscription -and not a subscription bot attempting to make a sybill attack against the service. +the recipient address indicated in the one-time subscription memo is indeed the +author of the subscription and not a subscription bot attempting to make a sybill +attack against the service. Finally, the newsletter service can require one-time +unsubscribe messages to attach a proof-of-authorship that proves that the sender +owns spend authority over the address that the unsubcription is being requested +for. # Privacy Implications From 6203c20e14ade61fdf25080e0311fce34ecd65df Mon Sep 17 00:00:00 2001 From: Pacu Date: Tue, 24 Feb 2026 18:29:45 -0300 Subject: [PATCH 4/6] Apply suggestion from @daira Co-authored-by: Daira-Emma Hopwood --- zips/zip-0231.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zips/zip-0231.md b/zips/zip-0231.md index 470d6835f..9c2027fbb 100644 --- a/zips/zip-0231.md +++ b/zips/zip-0231.md @@ -133,7 +133,7 @@ shielded memo impersonating Bob. Neither Alice or her wallet have an aid to judg the authorship of any of the received messages. If Bob's wallet had the capability to prove the authorship of a message, Alice's -wallet could help her notice such proof attempt. The rationale of this use case +wallet could help her notice such a spoofing attempt. The rationale of this use case is that application developers can use this mechanism to build a user experience that can help users tell apart trustworthy memos from those whose origin cannot be certainly determined. From 62bab243990312a379c37f57419fdf7c46312b1e Mon Sep 17 00:00:00 2001 From: Pacu Date: Tue, 24 Feb 2026 18:31:33 -0300 Subject: [PATCH 5/6] Apply suggestions from code review These suggestions were added during ZIP editors meeting on February 24th 2026 Co-authored-by: Daira-Emma Hopwood --- zips/zip-0231.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/zips/zip-0231.md b/zips/zip-0231.md index 9c2027fbb..1efae4c63 100644 --- a/zips/zip-0231.md +++ b/zips/zip-0231.md @@ -150,7 +150,7 @@ steps are outside of the scope of this ZIP. Using unverifiable memo data as input for business logic is unadvisable. Repeatedly, application developers have discussed memos an on-chain data layer for privacy-minded software such as Instant (or ansynchronous) messaging applications -or marketplaces. These applications require that the memo field information can +or marketplaces. These applications require that the memo information can be _trusted_ and therefore be treated as _actionable_ data by the application business logic. Without such a mechanism the application does not have a way to choose which messages should be trusted and which ones shall be ignored. The @@ -159,15 +159,15 @@ to distinguish plausible user intent from arbitrary memos generated outside the application domain. ## Broadcasting a newsletter -The ZecHub DAO runs a "Shielded Newsletter" service [^shielded-newsletter]. Users subcribe by sending a +The ZecHub DAO runs a "Shielded Newsletter" service [^shielded-newsletter]. Users subscribe by sending a one-time transaction with a subscription fee and a shielded memo that tells the service where to send the newsletter to. As discussed in the motivation section, -Memo bundles with help the newsletter service to avoid chain bloat by enabling +Memo bundles will help the newsletter service to avoid chain bloat by enabling subscribers to share a single key to decrypt a single memo instead of sending individual memos to each one of them. Additionally, by requiring subscribers to prove the authorship of their subscription memos, the newsletter can verify that the recipient address indicated in the one-time subscription memo is indeed the -author of the subscription and not a subscription bot attempting to make a sybill +author of the subscription and not a subscription bot attempting to perform a pseudospoofing attack against the service. Finally, the newsletter service can require one-time unsubscribe messages to attach a proof-of-authorship that proves that the sender owns spend authority over the address that the unsubcription is being requested From 733416e9c0d3f0fdfd6f026a4364a61ce35f732d Mon Sep 17 00:00:00 2001 From: Pacu Date: Mon, 9 Mar 2026 18:17:07 -0300 Subject: [PATCH 6/6] Add rationale supporting a wallet UX that helps identifying spoofing this addresses commment from Daira-Emma Hopwood that can be found here https://github.com/zcash/zips/pull/1185#discussion_r2849602884 --- zips/zip-0231.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/zips/zip-0231.md b/zips/zip-0231.md index 1efae4c63..1283c0f33 100644 --- a/zips/zip-0231.md +++ b/zips/zip-0231.md @@ -140,11 +140,13 @@ be certainly determined. It has to be noted that providing a mechanism for wallet applications to attach data that can help prove the origin of a transaction through the memo field will -not prevent that spoofers attempt such attacks. Spoofers can attach authorship -proof as well. Therefore, this proving data is not self-sufficient to determine +not prevent that spoofers attempt such attacks. Spoofers continue to send memos +to attempt to deceive a user. The proving data is not self-sufficient to determine that the author of a shielded memo shall be trusted. Further verification -steps would be needed to determine a such a level of trust. These additional -steps are outside of the scope of this ZIP. +steps would be needed to determine a such a level of trust. This specification +enables wallet developers to build a user experience that helps Zcash wallet +users to identify authentic memos containing Reply-to addresses from spoofed ones. +The definition of such UX is outside of the scope of this ZIP. ## Memos as input for application layer Using unverifiable memo data as input for business logic is unadvisable.