Users can delegate their ZEC and earn rewards, safely and while needing to learn only the minimal number of new concepts.

[shielded-nate]

Also from Scoping.md:

• Delegating to a validator does not enable the validator to steal your funds.
• Delegating to a validator does not leak information that links the user's action to other information about them, such as their IP address, their other ZEC holdings that they are choosing not to stake, or their previous or future transactions.

Prerequisites:

• Wallet and exchange partners are satisfied with protocol documentation for staking. #35
• We've published a "Notes on Stake Delegation and UX Security" which defines some of our protocol constraints. #36
• Technical white paper "Staking in Zcash" written for an audience of PoS-aware protocol experts summarizes key unique considerations for Zcash's design. #37
• Command line stake delegation tool works on Testnet. #38

[shielded-nate]

We're discussing how to be more specific about target users. Are "crypto people" who are already familiar with PoS delegation? Are they "Zcash-only" people who know about PoW, but not other features in the crypto space? Is Zcash the only crypto they've been exposed to?

A brainstorm about three kinds of UX from @zookoatshieldedlabs :

• The user's wallet has a simple "earn yield button". When they press it, it prompts for how much ZEC to supply. Once they've committed to that, they begin earning yield and that fact is apparent in the UI.
• The user's wallet provides a list of validators for a user to select from as part of the flow of delegating.
• The user's wallet has the ability to respond to mobile intents or other well-understood platform-provided handlers for "offers to receive delegated ZEC for staking".

In every case above:

• The wallet must learn sufficient protocol information to delegate to a specific validator.

• The wallet must learn that the user chose that specific validator in the latter two cases. (In the first case, this is baked-in by the wallet developers.)

• Security notes:

  • Two aspects of security for wallets learning sufficient information for delegation and that the user intends to delegate to that specific validator:

    • The content of an offer to serve as a validator for user delegations.

    • The source of the offer, which is either the user's brain or another computer source.

    • There are protocols for the user to transfer information between apps (in our case the intended flow is from another app to a wallet app). Each of these uses a "channel".

  • There are better and worse ways for wallets to learn this, some of them are vulnerable to phishing. On iOS the ways a user can share info between apps include:
    • cut'n'paste
    • typing
    • Scanning QR code with OS camera (invokes URL handling)
    • Scanning QR code with receiving app's internal QR scanner (can avoid URL handling)
    • Clicking a link in a sending app, such as a web browser (invokes URL handling)
    • "Share" flow

[I'm going to post this unfinished half-baked comment now before I transition away, because I don't have time to fully bake it.]