Coin Voting / Shielded Airdrop / Proof of Balance

(Speaking just for myself and not for ECC or as a ZIP Editor.)

This is only a thought exercise on how this functionality could be achieved, not whether we should do it.

It’s not necessary to require proofs of balance (which have potential privacy weaknesses when used for this purpose) in order to claim interest for holding funds in the Orchard pool. To do that, we could alter the protocol as follows:

Define the “compounded value” of an Orchard note at a given block height to be 1 at the activation height of this protocol change, and to be multiplied at each block by (1 + the per-block interest rate).

The per-block interest rate can vary; at each block, we subtract \mathsf{ceiling}(\mathsf{perBlockInterestRate} \cdot \mathsf{orchardChainValuePoolBalance}) from the block subsidy and add it to \mathsf{orchardChainValuePoolBalance}, in order to account for the increase in value of Orchard notes relative to other ZEC notes/UTXOs.

(Due to rounding both here and in the circuit below, the Orchard chain value pool balance becomes a slight overestimate of the actual sum of values of Orchard notes, but since a zatoshi is very small in practical value, that might be acceptable.)

Define the “anchor height” of a note output in a transaction with a given anchor, to be the height of the block with final treestate referenced by that anchor.

The relation between compounded values and note positions is public. Find a way to check this relation in zk, for example:

  • recompute the note commitment tree so that it commits to both note commitments and compounded values; or
  • include the compounded value in each new note commitment input and validate it on the output side of the circuit.

Change the Orchard Action circuit so that in each Action, the net value balance input to \mathsf{ValueCommit^{Orchard}_{rcv}} becomes \mathsf{floor}\!\left(\frac{\mathsf{compoundedValue^{new}}}{\mathsf{compoundedValue^{old}}}\right) \cdot \mathsf{v^{old}} - \mathsf{v^{new}}.

The idea here is that the value of each Orchard note relative to other ZEC notes/UTXOs is multiplied by 1 + \mathsf{blockInterestRate} each block, but this is only claimed when the note is spent. It’s equivalent to splitting ZEC into two currencies that are pegged to each other, with the peg being deflationary on the Orchard side. (I make no comment on the economic consequences of that, which could be quite substantial.)

Notice that this could easily be generalized to keep track of arbitrary exchange rates between pairs of ZSAs or other subsets of notes, as long as there is some way to agree on them as part of consensus.