[Grant Update] Zcash Shielded Assets Monthly Updates

[GGuy]

Transaction Reject

Good feature! While technically I assume the implementation of this feature is to simply reject the new notes and un-nullify the old ones I might suggest we rethink the name on this one. I assume one of the first things that come to mind with this feature is reducing ZSA spam. It’s definetly not good for that. Users might get the wrong idea and bork at having to pay fees to reject a spam . “Return to sender” or something might be more palatable?

While technically very different we will also likely want transactions that are rejected (e.g. not executed) by default. I discussed this a little in a seperate thread discussing “open recipient atomic swaps” (see below). While in the thread I’m talking about atomic swaps it should also applied to normal transactions too.

Asset Swaps

Here is the thread where I discussed some ideas on “open recipient atomic swaps”. It’s not perfect but might be a step in the right direction in terms of “combinatory” and “privacy” concerns (at least for one side).

@GGuy

Thoughts

Open recipient atomic swaps

I like to call them “options” and think of them in the same way we think of traditional financial options. Someone may receive (for free or paid) an option and can “optionally” execute the atomic swap before the expiry time.

One example is an exchange. They could allow a user to select the exchange pair on their website and enter amount to spend. The website would then issue them (e.g. via QR code) with an option based on the current exchange rate that’s only valid for a short period of time. The user can then execute that atomic swap if they choose. I imagine the slip is largely.dependent on how long the option is valid for.

The added benefit here is an exchange could allow users to purchase options with really long expiry times for additional hedging/trading options.

Ideas

Fail case open recipient atomic swaps

Open recipient atomic swaps that allow the receiver to execute a fail case in the event the atomic swap fails (e.g. insured loans, secured loans, etc). This would enable 3rd parties (or DAOs) to insure “options”.

Conditional “options”

Think of options that are condition on an option before it being executed.

Imagine a 1year car loan with monthly repayments. Ownership of the car doesn’t transfer until all 12 repayments are made (i.e. executed options). This could be done a few different ways:

• User receives 12 sequential options that must be executed in order. The first 11 are simply ZEC payment to the loan company. Last one is an atomic swap of ZEC and the cars NFT. Each option is conditional on the one before it being executed.
• Could allow multiple dependencies where the car transfer just depends on all car repayments being made before it. The first 11 car payment options could be executed in any order but the final payment which transfers the car NFT to the user is conditional on the first 11 having been executed/paid.