Introducing Transaction Controls in Zcash
In the current version of Zcash, fund transfers occur without explicit recipient consent. While this simplicity offers convenience, it creates significant challenges for users and businesses alike. This proposal introduces transaction user controls - a mechanism allowing recipients to actively participate in the transfer process by approving or rejecting incoming transactions.
This enhancement addresses crucial needs in the Zcash ecosystem, particularly at a time when privacy-preserving assets face increased scrutiny from major exchanges. The proposed controls offer robust safeguarding solutions while maintaining Zcash’s core privacy features
This piece of work comes at a time where privacy-preserving assets are under heavy scrutiny by major crypto exchanges. We believe that user controls can offer a robust safeguarding solution to prevent fund loss during transfer; while offering a promising avenue to keep Zcash listed on exchanges.
NOTE
This post summarizes two longer write-ups:
- Zcash User Controls: Transaction approvals and rejections, and
- Zcash Transaction Confirmation Via Recipient Counter-Signatures
It also relates to this presentation which video is available here.
Current State of Payment Authorization
Today, network users have one way to control who can send them funds on the blockchain. This is done primarily through address sharing. By controlling who has their payment address, recipients can “authorize” or “not authorize” someone to pay them.
[Caption] Left: Recipients authorize a sender to send them funds by sharing their address. Right: Recipients refuse to receive funds from a sender by refusing to share their address
However, using “address sharing” as a mechanism to control the receipt of funds is fragile and error prone. The main drawbacks of this approach are listed below.
1. It is transitive (which is bad)
[Caption] Charlie can pay Alice while Alice never shared her address with him
As illustrated above, address sharing is a transitive operation. If Alice shares her payment address with Bob and Bob shares Alice’s payment address with Charlie; this is equivalent to the case where Alice shares her payment address with Charlie. So, basically, by sharing Alice’s address with Charlie, Bob can “authorize Charlie to pay Alice” on Alice’s behalf.
This is a problem that becomes worse every time Alice shares her address with a sender. Every time she shares her address, she must trust the sender to never (willingly or unwillingly - e.g. hack) share her address with anyone.
2. It’s loose
Sharing one’s address with other network participants allows them to transfer funds to one’s wallet. However, it does not, in any way restrict the terms of those said transfers.
[Caption] Two users agree on a transfer of 2 ZEC, but the sender unilaterally decides to transfer another amount.
Here again, this lack of restriction over incoming transfers is an issue for the recipient who has no efficient way of refusing the payment.
3. It’s not easily revocable
In a case similar to the one above, once recipients have shared their payment address with senders, they do not have an easy way to revoke the senders’ rights to transfer them funds.
Of course, recipients can generate new payment addresses. But, to revoke senders’ right to pay them, they would need to delete their old keys after sending all their assets to a new wallet. This operation can lead to lost funds, however, especially if legitimate senders continue to send funds to the old address.
[Caption] Once a sender has a recipient’s address, nothing prevents them to send funds to the recipient beyond the initial agreement.
4. It’s error prone
Finally, relying exclusively on the sender to create the transaction using the recipient’s address is error prone.
If the sender makes a typo in the recipient’s address (or if they “fat finger” the amount to be sent), funds may be lost for ever.
Despite the design of user friendly websites & interfaces (with clipeable fields etc) user mistakes will continue to happen. Likewise, UI & clickjacking attacks will always be a threat for crypto users.
[Caption] A sender making a typo in the address of the recipient
Note: Mechanisms like Unified Addresses (zip 316) can make it easier for users to share their addresses. That being said, typos / fat finger mistakes (e.g. on the amount) can always happen.
Note 2: Mistakes during fund transfers are extremely common in the banking sector, too. This led to the introduction of mechanisms like Confirmation of Payee (CoP) that offer account / name checking services to make sure senders send the funds to the right person during bank transfers.
Key Use Cases of User Control
Transaction controls are a set of mechanisms that address the drawbacks aforementioned. Having user-controls allows recipients to play an active role in the transfer of funds which enables several use-cases. We group these use cases in 2 main categories.
1. Loss Prevention / better safeguarding
The types of safeguarding use cases that become possible with user controls mechanisms are:
- Double opt-in verification of transfers: both sender and recipient must approve the transfer which limits mistakes. The sender still puts the transaction together and the recipient reviews it to approve it, or not.
- Confirmation that recipients can access funds: By approving the transaction, the recipient also confirms that they can receive the funds (i.e. they still have access to their wallet).
While relevant to every user of zcash, we believe these safeguarding use cases to be particularly relevant to custodians (e.g. CEXs), and businesses - more generally.
2. Enhanced Wallet Management
Allowing recipients to play an active role accepting or rejecting a transaction gives them a fine-grained control over incoming transactions. For instance, they can:
- Inspect the transaction and decide whether or not it aligns with their expectations (e.g. “does the payment align with the terms of a contract?”)
- Only accept payments above a certain value
- Only accept shielded payments with at most X notes (e.g. payment with at most 2 notes, to avoid the total sum due to be split across too many notes, which would make it expensive to consolidate in the future for the recipient)
- Control the timing of the payment (e.g. “don’t pay me before date X”)
etc.
Design Considerations
In order to be secure and versatile enough, we believe that user-controls protocol designers must bear the following design considerations in mind.
Firstly, recipient confirmation might not always make sense or be necessary. As such, it might be relevant to make user-controls / transaction approvals optional or use-case specific (e.g. for certain ZSAs only).
Secondly, user-control protocols must not undermine the Zcash’s privacy properties nor add significant overhead on the blockchain network. What this means is that any extra communications between sender and recipient must not generate additional privacy leaks on the blockchain. Likewise, any change in the transaction format or any extra transaction validity checks must not undermine the privacy of transacting parties.
Finally, user-control designers should ask themselves a series of question to make sure that the control protocols align with the desired goals. Some of these questions are:
- What needs to be approved? The full transaction object? An Action? An Action Group (see Asset Swap ZIP228)?
- Should “lack of approval” mean “rejection”?
- Does “approval” (resp. “rejection”) need to happen on-chain? If so, who should be responsible for paying the fee between the sender and the recipient?
- Should all blockchain transactions be subject to “approval”/“rejection”? If not, which transactions should, and which should not?
- What about malicious recipients? E.g. How to prevent malicious recipients from freezing a transfer by withholding approval?
etc.
Avenues for user controls
Multiple options can co-exist to allow recipients to have better control over incoming funds to their wallet.
Rejection: Ignoring funds
For instance, recipients can reject an incoming transfer by simply ignoring it and never touching the associated funds. This does not require any protocol change but might necessitate some changes in wallet softwares to make it easier (and less error prone) for users to “ignore” rejected notes.
Rejection: Sending funds back
In some scenarios, recipients can also express their rejection of incoming funds by sending them back to the sender. This is possible if the incoming funds originate from a transparent address. To be feasible in all circumstances, this rejection method will require protocol and wallet changes (e.g. see TEX Addresses ZIP320).
Note: As described here, the derivation of payment addresses could be modified to encode specific payment instructions. This would be a step towards programmability and would generalize on the notion of TEX Addresses (which force incoming funds to be unshielded).
Rejection: Burning the funds
Another way in which recipients of funds can reject incoming funds is by simply burning them. However, burning funds when supply is bounded has a tendency to increase the asset price (demand stays constant while supply dimishes) which isn’t a neutral operation.
Approval via countersignature
Transaction approval can be done using a digital signature scheme. In this case, the recipient of the funds signs the transaction object (or a subset of the transaction like a specific Action/Action Group) to approve a specific transfer of funds for which it is the recipient.
This construction assumes that both the sender and the recipient are willing to engage in an interactive protocol to generate the transaction approval. More details about the protocol can be found in Zcash Transaction Confirmation Via Recipient Counter-Signatures.
Automated payment approval or rejection: towards programmable addresses?
As explained in Zcash User Controls: Transaction approvals and rejections, it could be possible to modify the address derivation in the Zcash protocol to let recipients create special address types encoding specific payment authorizations.
As done with TEX Addresses - which constrain payments to be done from transparent addresses - the Zcash protocol could be modified to allow recipients to derive addresses which would constrain the type of funds that can be sent to them.
For instance, it could be possible to modify the address derivation for users to generate:
- Addresses that can only be paid once per sender
- Addresses that can only receive payments of (or above) a specific value
- etc.
[Caption] A sketch showing how a more versatile address derivation mechanism could allow users to “generate payment invoices” on Zcash
Looking Ahead
Transaction user controls open new possibilities for the Zcash ecosystem, such as:
- Enhanced exchange integration
- Better compliance tools for businesses
- Improved user experience for all participants
- Potential for more sophisticated approval policies and payment flows
The introduction of transaction user controls represents an important step forward in Zcash’s evolution, providing users and businesses with better tools to manage their digital assets while maintaining the network’s core privacy features.
References
- Full write up: Zcash User Controls: Transaction approvals and rejections - HackMD
- Presentation slides: Zcash User Controls - Google Slides
- Presentation video: Video Conferencing, Web Conferencing, Webinars, Screen Sharing - Zoom
- Zcash Transaction Confirmation Via Recipient Counter-Signatures: Zcash Transaction Confirmation Via Recipient Counter-Signatures - Google Docs