In Proof-of-Stake design, I think there are some low-hanging fruit along these lines.
The simplest kind of design constraint is to say something like “the staking / delegation mechanics are transparent” (*) but you can only delegate from the Orchard pool.
What motivates (*)? There are several motivations:
- IMO, the total amount of voting weight that validators have should be public. Some protocols actually make this private, but that seems risky to me, because then no one can tell which validators have more control over the network. Other protocol designs could make the total transparent while keeping every delegation position private. That is appealing, but it’s more complex, so IMO that might be a good “POS v2” feature (see next).
- Existing protocols use transparent staking mechanics, so if we use the (*) constraint, we can do less work by plugging Orchard into one of those existing protocols.
- This approach has “good-enough/practical privacy” IMO:
- These data/metadata are public: which validator is delegated to, the amount of the delegation, when it was created or withdrawn, and any rewards/penalties it has accrued.
- These data/metadata are private: which user or address the funds came from or are withdrawn to, whether or not any two delegation positions are associated with the same user/wallet.
So if we use that design constraint in v1 of proof-of-stake, then:
- No one may earn staking rewards without their funds first being in the Orchard (or latest/greatest shielded pool), so this may incentivize transparent ZEC to migrate into shielded.
- The total balance of ZEC in the latest shielded pool will exclude staked ZEC.
- The privacy of staked ZEC will be “good-enough/practical”: no one can observe the history of any staking positions, link any staking positions (outside of timing or other off-chain metadata), or trace funds that withdraw from staking (back into the latest shielded pool).
How much this incentivizes migration away from transparent ZEC remains to be seen. Staking rewards are a carrot. Maybe we can think of other carrots, for example, requiring shielded ZEC for interacting with ZSAs or bridges.
The PRINCE idea that @decentralistdan mentions above is a stick: imposing fees on transparent balances.
I’d personally like to see how much the carrot works first, because that doesn’t give any user a bad experience, whereas users who are hit with fees (especially if they didn’t expect it) may get turned off.