# Zcash User Controls: Transaction approvals and rejections

The goal of this document is to survey the use cases related to transactions approval and/or rejection (aka 'user controls') on the Zcash network. With such mechanisms, recipients of funds on Zcash (for any type of ZSA) can confirm (or ‘approve’) the receipt of the funds on chain.

The deployment of user control mechanisms would allow recipients to stay in full control of the asset inflows of their wallet. Senders would not be able to transfer funds to recipients against their will anymore, and recipients would be able to define their wallet receipt policy; determining from whom they accept funds, what minimum / maximum transfers they authorize to their wallet, at what time they accept funds etc.

The benefits of 'user controls' can be enjoyed by every Zcash user. However, we believe them to be most relevant to crypto-exchanges accepting ZSA deposits. In fact, many crypto-exchanges only accept ZEC deposits via t-addresses (see e.g. [here](https://www.nicehash.com/support/general-help/wallet/how-to-make-a-zcash-deposit-withdrawal)) which forces funds to be moved from the shielded to the unshielded pool each time users interact with an exchange. Moreover, despite only accepting deposits to t-addresses, established crypto exchanges have warned of [potential delisting of ZEC](https://forum.zcashcommunity.com/t/important-potential-binance-delisting/45954/3?page=4) because of difficulties to properly carry out due dilligence on deposited funds.
We believe that user-controls will not only make it easier for exchanges to comply with increased regulations, even when dealing with privacy-preserving assets like ZEC; but we also believe that user controls could pave the way for shielded deposits to and withdrawals from exchanges and other custodians. This, in turn, will benefit the Zcash ecosystem as a whole, by allowing users to keep their funds shielded for longer.

Additionally, it is common to see crypto-exchanges warn their users to deposit the correct asset type to their correct address to avoid fund loss ([some exchanges do NOT CREDIT deposits from shielded notes](https://ywallet.app/misc/cex)). Having 'user controls' will offer exchanges and their users a way to implement double opt-ins on deposit and withdrawal transactions. This will allow exchanges to carry out extended due dilligence to accept shielded funds as deposits, and will provide them with a robust mechanism to validate their users' deposit & withdrawal transactions. In doing so, exchanges will be able to play an active role preventing fund loss during deposit & withdrawal operations by their users (more on that below).

*Typical user interface for deposits on crypto exchanges. Users are warned to use the correct address and to deposit the right type of assets.*

<details>
<summary><b>Important (internal) note ⚠️</b></summary>
In this document, we focus on user-controls with the goal to *empower recipients* with a way to control the incoming funds to their wallet.

The purpose of this document is **NOT** to focus on user controls with an aim to offer regulatory compliance. Better regulatory compliance may be achieved as a byproduct of better user-controls, but user-controls, *on their own*, do not provide a robust compliance solution.

In fact, given Zcash's unlinkability properties, a network user (e.g. an exchange) receiving shielded funds remains hard to **audit comprehensively**. In fact, if/when asked by an auditor, a recipient could simply tell the auditor that they have not received any shielded transaction. The auditor will have no way to know if this is true or not.

Similarly, a crypto-exchange which has received, e.g. 1,050 **approved** shielded deposit transactions could **selectively** disclose only 1,048 of its approved deposits to an auditor. This will give the auditor an incomplete understanding of the exchanges deposit activity. The auditor will think they have all the deposit history of the exchange and will base their audit on this incomplete data. In reality, the 2 undisclosed deposits on the exchange might be coming from fraudulent sources and omitted by the exchange on purpose to keep them "off the auditor's books".

Given that Zcash addresses are re-randomized, one "real/natural person" may have many addresses on-chain, and may selectively disclose a subset of their approved/rejected transactions to auditors (and omit some others). To have the full picture (and be certain about it), the auditor would need to be able to link all addresses of a same person to the natural person owning them. Without further assumptions/context, this is hard - if not impossible - to achieve.

Conclusion: In this document, we focus on user-controls with the aim to empower transacting users/recipients of funds. If we want to look at "user controls" from a regulatory lense, we need to make further assumptions and add linkability requirements in the protocol design.
</details>

## Problem statement

Existing blockchain systems rely on the notion of "address" to identify network participants (aka "users"). Each user may have one or more address. If 2 users (a sender and a recipient) want to transact, they first need to "discover each other". More particularly, the sender of the funds, must get the address of the recipient in order to transfer their funds to the counterparty. This "address discovery" is usually done via off-chain communications (e.g. emails, forum).

By sharing (or not sharing) their payment address, users can decide (i.e. 'authorize' or 'not authorize') which other network participants can send them funds to their address.

Some individuals and/or organizations want to make one of their addresses public to allow everyone to issue a payment to them (e.g. charities like [Turing Trust](https://turingtrust.co.uk/donate/donate-crypto/)); while some others want to keep their payment addresses private to a restricted set of users.

:::info
All in all, recipients can control who can send funds to them by controlling who has access to their payment address(es). Recipients can (somewhat) control inflows in their wallet by deciding to share or not to share their payment addresses.
:::

But, relying exclusively on "address discovery" to authorize / not authorize incoming payments has the following limitations:

1. **Lack of revocation**. Sharing one's payment address only allows the recipient to "grant" the "authority to be paid by a user", but it doesn't allow the recipient to "revoke" this "authority to be paid". This could be an issue if recipients want to authorize the sender to pay them **only once**. *(Generating new addresses is not a clean way to revoke the authorization to pay because the sender can still send funds to the old address, potentially leading to lost funds. More on that below.)*
2. **Loose authorization**. Sharing one's address with a sender only allows the recipient to "grant" the "authority to be paid by a user" **but it does not constrain the terms of the payment**. The recipient might want to **only** authorize payments for specific amounts - or at specific times (e.g. for tax reasons) -, instead of authorizing "every kind of payments, any time" from the sender they shared their payment address with.
3. **Payment authorization is transitive (undesired property)**. A malicious sender could disclose the payment address of the recipient to other network participants which will - in turn - "grant them authorization to send funds to the recipient", against the recipient's will. Say, e.g. Alice gives her address to Bob to authorize him to pay her. If Bob leaks Alice's address to Charlie, then, now Charlie knows Alice's address - as if Alice gave her address to Charlie (to authorize him to pay her). In other words, **recipients can control who they share their address with, but once shared they can't control who else will get their address.** (*Obviously, not all senders will be malicious in reality, but every sender __can__ be compromised. This is why, we must assume all senders to be malicious in the analysis.*)

:::info
TL;DR: If "sharing one's payment address with someone" is seen as "authorizing a payment from this sender"; it is important to realize that this "authorization" is **weak**.
:::

### The issues of \*transparent\* unapproved fund transfers

Nowadays, any sender who has the address of another blockchain user can - **unilaterally** - send funds to this user. In doing so, the sender can:
- Create a link between the recipient and funds/an asset (e.g. [Vitalik and SHIB](https://www.coindesk.com/markets/2021/05/17/vitalik-buterin-burns-6b-in-shib-tokens-says-he-doesnt-want-the-power/)). This could be done to e.g.
- Achieve a marketing goal by associating a celebrity to a crypto project - potentially against their will.
- Create a link between a recipient and unlawfully acquired/tainted funds (e.g. blackmail, reputational damages)
- etc.
- Associate the recipient with a group of users or a set of on-chain transactions

:::warning
TL;DR: On transparent blockchains, senders knowing the payment address of recipients could use this information to transfer funds to recipients for the sole purpose of exposing the recipients of the funds to regulatory scrutiny, possible tax reporting requirements etc.
:::

But, this is not all, the lack of per-transaction recipient approval also:

1. **Exposes both the sender and the recipient to lost funds.** For instance, let's assume that Bob (sender) knows a payment address of Alice (recipient) and needs to pay her. If Alice loses access to her wallet (e.g. lost keys) and Bob transfers the funds to the "usual payment address of Alice", then funds might be lost (see e.g. [this subreddit](https://www.reddit.com/r/Nexo/comments/192h4aj/sent_bitcoin_by_accident_to_old_address_and_nexo/)). Having a "recipient approval" on the transfer could act as a double opt-in that would guarantee that **the recipient is able to receive funds on the specified address, at the time of the payment.**
2. **Creates a 'role asymmetry' between sender and recipient on-chain which could be used against the sender (or the recipient, depending on the context).** The lack of explicit recipient's approval on a transfer creates ambiguity around the recipient's intentions in the transfer, which could be used against the sender. Given that **only** the user transferring the funds must send a transaction on-chain (the recipient has nothing to do to trigger the state transition), malicious recipients could agree (e.g. on a call) to receive funds from a sender; but could then publicly shame/accuse the sender for sending funds to their address against their will. This type of behavior could undermine the reputation of the senders. It could also could serve as a way for people involved in fraudulent crypto projects to obtain "plausible deniability" over their approval of the receipt of the funds. This could give them a way to escape legal action by denying that they approved a payment to their address.

:::info
TL;DR: A blockchain transfer involves 2 addresses - yet, only one address / account / wallet has to submit the payment instruction to the network. This role assymetry creates edge cases and ambiguity that can be prevented by designing a protocol where both sender and recipient must play an active role in the fund transfer.
:::

:::warning
Importantly, seeking approval/rejection of the recipient of funds doesn't make sense for every use cases. More on this in the following sections (see e.g. [Should all transactions be subject to approval?](#Should-all-blockchain-transactions-be-subject-to-approvalrejection))
:::

### The case of Zcash and privacy preserving fund transfers

In the context of Zcash’s shielded transactions, a transfer of token from party A to party B is privy to the transacting parties. Thus, other network participants cannot see that party B received a specific amount of ZSAs. What this means is that even a malicious sender could not fully disclose the details of a transaction even if they disclose the (transferred) notes details to the rest of the network. In fact, the sender cannot prove that the re-randomized address of the recipient belongs to a specific natural person (except if they e.g., leak personal communications with the sender who might have shared their payment address via email with them etc.). **As such, most of the reputational attacks mentioned in the section above do not apply in Zcash.** For instance, someone creating a SHIBA-type ZSA on Zcash and sending half of the supply to a z-address controlled by V. Buterin, wouldn't be able to prove (on their own) to the rest of the network that Vitalik owns half of the supply. Vitalik would need to acknowledge receipt of the funds publicly. As such, these reputational attacks are really designed to be carried out on transparent blockchains.

:::warning
Moreover, Zcash offers the possibility for senders to include multiple Actions in their transactions. As such, a recipient will only have access to the notes they are the recipient of, and won't know about other transferred notes in the transaction for which they aren't recipients. This raises the question of [what needs to be approved?](#What-needs-to-be-approved)
:::

These points are important to note: self-custody and re-randomized addresses give Zcash recipients plausible deniability of the receipt of funds. To prove control of the receipt of funds, recipients must prove control of the re-randomized address on which they received the funds.

### Use-cases of user controls on Zcash

While reputational attacks are designed to be carried out on transparent blockchains, user-controls are still very relevant in the context of shielded transfer.

1. **User controls offer a loss-prevention mechanism.**

As explained above, having a double opt-in for fund transfer provides a robust way for recipients to acknowledge their ability to receive funds. **Such mechanism makes it impossible for senders to send funds to the wrong address, which would lead to lost funds.** For instance, modern banking apps already integrate with tools like https://www.sortcodes.co.uk/ to verify that the bank details entered in a bank transfer are correct and match with the name of the bank account holder before a transfer (see also [Confirmation of Payee (CoP) mechanisms](https://www.wearepay.uk/what-we-do/overlay-services/confirmation-of-payee/) used for CHAPS and Faster Payments in the UK). Such double opt-in / user controls mechanism for Zcash's ZSA transfers would achieve something similar. **For crypto-exchanges (and other custodians) in particular, having a double opt-in by both the sender (user) and the recipient of the transaction (exchange) will allow exchanges to have a robust mechanism in place to prevent fund loss when their users deposit and withdraw funds.** This would be significantly more robust than a mere "verify that the address is correct and only send XXX assets to this address" warning message on the website. Given exchanges focus on fund safeguarding and ease of use (see Binance's [Incorrect Deposits of Crypto Assets: How to Retrieve Your Funds](https://www.binance.com/en/blog/security/incorrect-deposits-of-crypto-assets-how-to-retrieve-your-funds-2581603470758819561)), we believe that a double opt-in on deposits would significantly improve the user experience on these platforms.

:::info
**Note:** The loss-prevention use-case makes even more sense in the context of Zcash's shielded transactions because the sender cannot "just look at the chain data" to see if the address they're about to pay has recently been active etc. This means that senders cannot easily check if the fund recipient has access to the wallet that is about to receive the funds. This is even more so problematic when payment addresses are shared well ahead of the expected date of a payment.
:::

2. **User controls offer enhanced wallet 'gatekeeping'.**

Providing a mechanism for recipients to decide what funds to receive and when to do so could be beneficial to them. In doing so, recipients would be able to have a fine-grained control over incoming funds to their wallet. For instance, with such mechanism, recipients will be able to "reject all ZSA payments of less than $1 in value" (or "where transferred notes have a value lower than 0.000001 ZSA") if they deem so. The rationale here, for example, can be that it's too expensive (fee-wise) for the recipient to consolidate these tiny notes into larger ones (a bit like we see many retailers [ditching AMEX](https://startups.co.uk/payment-processing/credit-card-processing-fees/) for micro transactions because their processing fees are too high). Such controls aren't new and already exist in some monetary systems. In the UK, for instance, under the [Coinage Act 1971](https://rradar.com/the-coinage-act-1971-and-legal-tender/), one penny and two pence coins are legal tender **only if used to pay for something that costs twenty pence or less.** This gives e.g. shop owners the right to refuse payment of expensive items in very low denomination coins. Letting ZSA fund recipients decide what constitutes an acceptable payment can significantly improve their user experience on the system.

Furthermore, recipients will have more control over the timing of their payment too (e.g. by delaying the approval, they can make sure a payment happens after a certain date, e.g. after the end of the tax year; or e.g. after a KYC process is completed).

Again, both of these use-cases could be used by any network participant. However, we believe them to be most relevant in the context of popular custodians like crypto exchanges.

Nowadays, many crypto exchanges, and services like [The Giving Block](https://thegivingblock.com/) usually use t-addresses for deposits / payments / donations of ZEC. Offering them a mechanism for granular user-controls would allow them to support z-addresses for payments, which, in turns, would benefit the Zcash ecosystem as a whole by keeping funds in the shielded pool.

:::success
**Open question:**

Is it really viable for crypto exchanges / charities and business to receive shielded deposits / donations / payments? Is that a pain they're currently facing (i.e. lack of solution to securely receive shielded funds)? Are we genuinely solving a problem here?

[Looking at this thread](https://forum.zcashcommunity.com/t/important-potential-binance-delisting/45954/7), it seems that exchanges like Binance aren't too happy to receive deposits from shielded addresses to their t-addresses, see:

> Their concern is that users are sending funds from a shielded address to a transparent address on the exchange and they have no way to confirm where the funds are coming from (e.g. an OFAC sanctioned country or individual).

Such discussions present an opportunity to use user-controls to solve the issues of exchanges listing ZEC (and ZSAs in the future).

**This needs to be validated.**

Maybe better user controls, **COULD** help get [ZEC off Binance's monitoring list](https://forum.zcashcommunity.com/t/important-potential-binance-delisting/45954/650)...

Ultimately, the "deposit of shielded assets" on an exchange wouldn't really be more cumbersome with user-controls than current deposits without controls. User wallets and exchanges' deposit pages could simply be modified to e.g.
- Add a clipeable text that must be signed as part of the approval -> users click the "copy" button on their wallet and paste it on the UI of the deposit page of the exchange
- Exchanges already know their users (KYC & AML as part of the onboarding), so they can sign the pasted message to form an approval of "shielded deposit"
- The user can now copy the signed payload, and paste it in their wallet app to form the final "approved transaction"



**The real questions are: would this add value? Does that solve a problem?**
:::

:::info
**Note:** Some of the motivations behind this document also echo some of what’s mentioned in: https://github.com/zcash/zips/issues/755, e.g. *“It could be nice if wallets have an opt-in or opt-out to receive funds, especially of a new Asset type. This doesn't necessarily require protocol support. For example, a wallet could have a "block this txn and all future txns involving this AssetId" button that simply mutes those txns from the history list.”*
:::

In the following sections, we describe the various scenarios by which fund recipients can be empowered with a way to *accept* or *decline* (i.e. *"control"*) the transfer of funds to their Zcash addresses.
We separate the discussion into 2 main sections. One section looks the design considerations and the pros & cons of various types of approaches. approval protocols. Another section looks at approval/rejection protocol candidates.

## Design considerations

To design viable solutions for targetted use cases, it is important to consider the following questions.

### What needs to be approved?

A transaction recipient can only access the notes for which it is the recipient. Given that a Zcash transaction can contains multiple Actions that all manipulate different notes, **it is possible that a single transaction sends funds to multiple recipients**.

As such, when recipient approve a transfer of funds to their wallet, they really **only** approve the creation of the notes they now own, nothing else (because they have no information about the rest of the transaction).

This is particularly important to note because if a transaction transfers notes to one honest recipient (e.g. a charity) and to a malicious recipient (e.g. someone involved in illicit activities), clearly an "approval from the charity" shouldn't be seen as an approval of the transaction as a whole - including the transfer to the malicious recipient.

:::warning
When designing a transaction approval protocol, it is important to bear in mind that the scope of the recipient's approval only applies to the Action creating the notes for the recipient.
:::

Given this, approval could either be set on the Action object, or on the overall transaction object.

### Does "lack of approval" mean "rejection"?

It could, but probably not always. Clearly, there must be cases where two parties A and B are due to transact but the receiving end (e.g. B) didn't receive the "request for approval". In this case, B may want to approve the payment (intent) but may have not done so because of issues in the communication with A.

Likewise, in more complex payment flows, the receiver could want to accept a payment only after a specific condition happens, e.g. "only accept the payment once the customer's order has been fully processed". In this case, a "temporary" lack of approval must not be mistaken for a "rejection".

In contexts where the recipient receives an unsolicitated payment request from an unknown sender (similar to a spam email), it is fair to assume that "lack of approval" equates "rejection" in this case.

TL;DR: The context really determines what lack of approval means.

#### When does 'lack of approval' mean 'rejection'?

It is also worth asking if **at some point**, a lack of approval shall be understood as a rejection of the payment. In fact, without additional constraints, the recipient could simply keep the non-expiring option to either approve or reject the payment; which gives leverage against the sender.

A robust design must address this scenario by making sure that, if approval is needed for the transaction to proceed, then this approval must be given within a specific time period (i.e. number of blocks).

### Is it important for "approval" and "rejection" of a payment to happen on-chain?

In other words, should "approval"/"rejection" be privy to the transacting parties or shall it be visible to the whole network - for auditability purposes?

The strongest form of approval (or rejection) is to change the transaction validity checks of the consensus level of the target blockchain protocol. Doing so allows fund recipients to either approve (or not) the sender's suggested "fund transfer" state transition on the chain. In the case of Zcash, recipients would be given a way to approve - or not - the mutation of the blockchain data structures like the commitment trees, nullifiers set etc.

Adding "user controls" validity checks on the chain has the following pros and cons.

#### Pros

- **It prevents disputes.** The sender (or recipient) can't claim that the contract's counterparty didn't fulfill their duty, even if they did. Both sender and recipient's intents are on the blockchain (if the sender sent/signed the transaction, this means they wanted to transact. Similarly, if the recipient approved the transaction, e.g. by countersigning it before it was sent on chain, it means they wanted to transact.) It's all clear, unambiguous and undeniable.
- **Rogue state transitions are prevented.** The blockchain state is kept consistent at all times with no need to "undo" transactions. In fact, including transactions on chain that end up being unapproved - by e.g., the recipient - is a poor use of blockspace. New transactions to "undo" a payment need to be added to the chain. Moreover, given the sheer amounts of composable blockchain use cases, the settlement of the payment that ends up being approved, may trigger other state transitions that may - too - need to be "undone" if the payment ends up being rejected.

#### Cons

- Potential added communication on chain
- Potential leakages undermining the unlikability of Zcash

### If approval/rejection comes with a fee - who should be responsible for paying the fee?

This is particularly relevant to the cases where:
1. Approval/rejection is verified on-chain
2. The sender / recipient must communicate off-chain to collect approvals and one of them has to submit the transaction on-chain.

In these cases, protocol designers must decide which user between the sender and the recipient must pay the fees for submitting the transaction on-chain.

### Should all blockchain transactions be subject to "approval"/"rejection"?

i.e. shall "user controls" only be applicable to a subset of blockchain transactions? If so, what types of transactions must be subject to "approval"/"rejection"?

It is worth asking how the "user controls" must be rolled out on a blockchain. Should they be "enabled for all transactions of a ZSA" or shall we have "selective approval" for a subset of transactions? (e.g. transactions moving more than US$ 1000)

:::warning
Be careful with indistinguishability!
:::

If "user controls" are not set by default on all transactions, and if they need to be set manually (e.g. using a flag in the transaction), then surely letting the sender decide whether or not approval is needed undermines the purpose of the construction. (i.e. a sender could never set the "user controls" flag and thus deprive the recipient from their approval/rejection rights).
If user controls are to be enabled by transacting parties, they must be enabled by the recipient.

#### Using addresses as payment authorizations

It could be possible for e.g. to modify the address derivation in the Zcash protocol to let recipients create special address types encoding a payment authorization.

For instance, this could be done by having the recipient give a unique payment address to the sender:

- This payment address could be unique to the sender (so that if the sender leaks this address to other users, none of the other users will be able to send funds to that recipient address because they aren't the expected senders) -> this way, if the sender wants to leak the payment address of the recipient that he received, he has to leak his own private key for others to "be able to prove that they are the correct senders".
- This payment address could be set to "unique payment" or "multiple payment" to determine how often it can be used. E.g. if the address is a "multiple payments" address, then the sender can prove that they are the intended sender of the transaction and they can "bypass" the sender's approval step (i.e. interactive protocol). If the payment address is a single payment the sender will still have to prove that they are the intended sender; but then they will also need to engage in an interactive protocol with the recipient to get their transaction approved (the recipient will keep track of the payment address issued and will decline future approvals).

By having the recipient manifest their intent/authorization in their payment address, we can have a nice protocol that doesn't need lots of extra communication rounds. The recipient will say "here is my address and it stipulates how you should pay me/seek my approval" and the blockchain transaction will represent the sender's approval of the transaction terms.

*See a larger version of this image by right clicking and selecting "Open Image in New Tab".*

:::success
With this approach, payment addresses almost become invoices that constrain the types of payments people can do. I think that's pretty cool!

**Note:** Looking at this suggestion from an other angle, one could see that it is an extension of TEX Addresses.
With [TEX addresses](https://zips.z.cash/zip-0320), the recipients of funds (e.g. an exchange) can express, via their address, their preferences around the source of the received funds (e.g. by forcing/or not the funds received to be transparent). Here, we allow recipients to express more than their preferences on the shielded/unshielded origin of the funds.

**The proposed approach on the screenshot above is rough around the edges, but that should give a taster.**
:::

:::warning
We also need to consider the case where someone wants to authorize one address to pay them many times, unconditionally. Today, they can do it by just sharing their address with the sender, but if we expect recipients to approve all incoming transactions, we kind of remove this possibility. This is why having multiple address types makes sense and can allow for all sorts of payment flows: single payment with specific terms, multiple payment that need to be approved, unconditional payments (what we have nowin Zcash) etc.
:::

### What about malicious recipients?

Adding "user controls" to let fund recipients accept or reject fund transfers to their address protects them against malicious senders (as described in the introduction).

However, the introduction of user controls give the power for the recipients to accept (i.e. enable) or reject (i.e. disable) specific incoming payments to their address. This allows a set of malicious behaviors for recipients who can now withhold approvals to delay payments and blaming senders.

Depending on the circumstances (i.e. depending how the approval/rejection is carried out), the payee (e.g. an employee or a landlord) could sue their employer (or tenant) for breach of contract due to lack of payments for their work (or rent). In fact, an honest sender (e.g. employer or renter) could trigger a payment that the payee must accept for settlement. The payee could withhold approval and thus delay/prevent the payments from happening by a certain date to cause a breach of contract.

To limit this attack scenario, it is important to design a protocol where approvals/rejections must be carried out within a specific time period.

:::info
Ultimatelly, it is key to balance the powers of "sender" and "recipient" in the transaction.
:::

### Other design considerations

As for other blockchain-based protocols, the design of user controls mechanisms should:
1. Minimize overhead: computational overhead (e.g. extra resources needed to generate the transaction), bandwidth overhead (e.g. transaction sizes), communication overhead (e.g. number of messages exchanged between sender and recipient etc)
2. Aim for simplicity (minimize protocol design complexity etc.)

## User-Control Protocols

### Scenario 1 / Approval: Recipient countersigns the transaction but sender settles it

The strongest form of approval (or lack thereof) is to change the transaction validity checks of the consensus level of the protocol in order for the recipient to either approve (or not) the relevant state transition on the chain, and thus approve - or not - the mutation of the blockchain data structures like the commitment trees, nullifiers set etc.

If such validity checks are added on the chain, then we can be sure that the recipient of a transaction has explicitly approved the receipt of funds and thus authorizes the state mutation on-chain associated to the transfer of funds. Without these set of changes at the consensus level, the recipient of the funds must be the one dealing with the funds received to explicitly discard/burn them or put safeguards in place to make sure to never touch such funds. This can be a problem for a large corporation with a complex balance sheet. They would need to keep track of “tainted” and “not tainted” assets on their balance sheets and make sure no employee can mistakenly touch “tainted funds”.

One way for the recipient to control the on-chain transfer of funds to their wallet, would be for them to countersign the sender's transaction (or part of it); and for miners to verify this countersignature as part of the transaction validity checks. This could be done reusing an approach like the one proposed in [Zcash Transaction Confirmation Via Recipient Counter-Signatures](https://docs.google.com/document/d/1MpzUneUIbn7KMWDZ73iZovPoXhc5LAZuPFz7vymOvu8/edit?usp=sharing).

The recipient would countersign a message, send it back to the sender and the sender would then be able to submit the transaction on-chain. In this case, the sender remains liable for sending the payment instruction on time, on the blockchain.

#### Implementation requirements

✅ Protocol changes (including circuit changes) required to modify the transaction structure, the validity checks etc.
✅ Wallet changes required to receive approval requests and generate counter-signatures.

### Scenario 2 / Approval: Recipient countersigns the transaction and settles it

Similar to the scenario above except that the recipient countersigns the transaction/message and sends it to the blockchain for execution and settlement, instead of sending it back to the sender.

As for the Scenario 1 above, this approach could be implemented following a derivation of the design described in [Zcash Transaction Confirmation Via Recipient Counter-Signatures](https://docs.google.com/document/d/1MpzUneUIbn7KMWDZ73iZovPoXhc5LAZuPFz7vymOvu8/edit?usp=sharing).

Likewise, this approach could be implemented by building on top of the Asset Swap protocol, which also fixes the non-expiring option to approve/reject mentioned in the section ["When does lack of approval mean rejection?"](#When-does-lack-of-approval-mean-rejection)

#### Implementation requirements

✅ Protocol changes (including circuit changes) required to modify the transaction structure, the validity checks etc.
✅ Wallet changes required to receive approval requests and generate counter-signatures.

### Scenario 3 / Rejection: Do nothing/ignore

Not touching the funds ever could be a form of rejection although nothing prevents the recipient from touching the funds in the future.

This approach will have different levels of efficacy for different user profiles. For veteran blockchain users using advanced CLI commands/flags etc, they will still be able to see the balances of all their assets. They can of couse decide to ignore some of them, but they will be able to access everything.

For the average users though, their wallet might be able to "mute"/ignore specific asset balances or transactions (e.g. see https://github.com/zcash/zips/issues/755 "a wallet could have a "block this txn and all future txns involving this AssetId" button that simply mutes those txns from the history list."). In this case, unapproved funds will be "out of sight" which will act as a "rejection", i.e. "nothing happens, my wallet doesn't show the transfer".

#### Implementation requirements

❌ No protocol changes needed
✅ Wallet changes required: UI changes needed to allow users to mute/ignore transactions (buttons etc), logic needed to keep track of "muted"/blacklisted payments and exclude them from the data shown to the user etc.

### Scenario 4 / Rejection: Recipient sends funds back via another on-chain transaction

Upon receipt of an undesired transfer of funds, recipients can simply send the funds back to the sender as a form of rejection - **if they have the sender's payment address**.

:::info
Rejecting the funds this way, is made easier if the users use [TEX Addresses](https://zips.z.cash/zip-0320). See also, [YWallet's recommendations](https://ywallet.app/misc/cex) to deposit to exchanges.
:::

If they can't send the funds back, they can either ignore the transaction (as pointed out above) or simply decide to burn the funds (see below).

Importantly, given that the terms of a shielded transaction are private to the sender and recipient of the transaction, simply sending the funds back using another shielded transaction simply allows the recipient to **privately** reject the payment.

If this rejection needs to be public, the recipient could decide to unshield funds and use t-addresses (if possible). Else, it might be desirable to design a protocol to allow recipients to provably reject transactions by allowing them to generate a proof that a transaction $T^{-1}$ is the inverse of another (already mined) transaction $T$ in that it moves the exact same quantity of funds back to the sender of $T$. In essence, we would define $T^{-1}$ as the inverse transaction of $T$ **w.r.t a specific recipient** if:
- The sender of $T$ is a recipient in $T^{-1}$
- The sender of $T^{-1}$ is a recipient in $T$
- The sum of the notes value transfered to the sender of $T$ in $T^{-1}$ equals the sum of the value transfer to the sender of $T^{-1}$ in transaction $T$. (i.e. both transactions move the same values to from/to the same parties, in opposite directions)

:::warning
**Note:** Due to Zcash's unlinkability and due to the fact that "real identities" can have multiple on-chain identities, it is hard to come up with a scheme to provably reject a transaction in a robust manner. In fact, Alice may want to pay Bob but they can collude to make it look like the transaction got rejected by Bob (to make is look like the value transfer never happened in the end). To do this, Bob can create 2 payment addresses, Alice can transfer notes to Bob's 2 payment addresses in a single transaction, and Bob can only reject the transaction with one of his identity, while not rejecting with the other payment address.
:::

#### Implementation requirements

🤔 Protocol changes MIGHT be needed. If the receiver has the payment address of the sender of the funds, the recipient can send the funds back to the sender without further changes needed in the protocol. That being said, the condition that the recipient has the sender's payment address won't always be met, so it might be necessary to change the protocol to make sure that the recipient of the funds can always send them back if need be.
🤔 Wallet changes MIGHT be needed. If the receiver has the payment address of the sender of the funds, the recipient can send the funds back to the sender without further changes needed in wallets. That being said, the condition that the recipient has the sender's payment address won't always be met, so it might be necessary to change the protocol (e.g. including TEX Adresses). If so, changes might need to be made in wallets as well.

### Scenario 5 / Rejection: Recipient burns the undesired incoming funds

Vitalik did something like this in the past with Shiba where he sent some funds to the 0x0 address to burn them.

See: https://www.coindesk.com/markets/2021/05/17/vitalik-buterin-burns-6b-in-shib-tokens-says-he-doesnt-want-the-power/ for Vitalik's burn of Shiba

:::warning
Publicly proving that all the funds received in a shielded transaction are burnt is not easy with shielded Zcash transactions.

If the goal of the user-controls protocol is to give a way for users to "protect" their wallet from undesired incoming funds, then the recipient of funds can just send these funds back to the sender (as above), or burn them.

**BUT**

If the goal of user-controls is to give a way for recipients to prove (to someone else, e.g. the network, an auditor) that they have rejected the funds, then merely burning the funds or sending them back is not enough! In fact, you'd need to prove that you burn all the funds you received, etc, which might be tricky to do given Zcash unlinkability guarantees and given that the notes' values are hidden to non transacting parties. Same thing for sending the funds back, if it needs to be proven to a 3rd party it's not so obvious on Zcash (while it is super easy on transparent blockchains).
:::

:::info
Burning tokens as a "rejection" is also a pretty strong form of rejection which has an impact on the value of the token, especially if supply is limited/bounded. So, burning funds publicly is more than just saying "I don't accept this payment". Burning tokens can push the price up for instance if demand stays constant but supply diminishes due to the burning of the coins.
:::

#### Implementation requirements

❌ No protocol changes needed
❌ No wallet changes required

## Conclusion

Improved user controls benefit:

- Transaction recipients: better means to control when, how and from whom they receive funds
- Transaction senders: Double opt-ins on transactions prevent fat finger errors (e.g. [send the wrong amount](https://www.risk.net/comment/7676356/op-risk-data-revlon-lenders-wont-make-up-over-citi-error)), and prevent address typos (i.e. lost funds)
- The ecosystem: keeping ZEC listed on key exchanges allows frictionless trading of ZEC.