# Simple idea for incentivizing zaddr use

Hi folks, just sharing a simple idea for incentivizing zaddr use.

Keep two counters in the state of the chain, n_s and n_t (n “shielded” and n “total”). n_s tracks the number of shielded coins, n_t tracks the number of zec that went in minus the number of zec that went out. In the current implementation, those number are supposed to be the same, but that doesn’t have to be the case.

1. When coins are being shielded, increase n_s, when they are being unshielded, decrease n_s. This is easy, it lets you track the total number of shielded coins.

2. Now, at every block symbolically assign some amount b to the pool of shielded coin. b can be inflationary, it can be taken from the block reward, it can come from gifts, it just has to come from somewhere.

3. Each time b zec are “assigned” to the shielded pool, increase n_t by b but do not increase n_s. Each time coins are being shielded, also increase n_t.

4. When c coins are unshielded to a taddr, credit it ot with c zec but with c \times n_t / n_s zec. Decrease n_s by c and decrease n_t by c \times n_t / n_s.

This is rather easy to do and incentivize keeping coins shielded over time. The downside is that one shielded zec is now worth more than a non shielded zec, and the ratio between the two (n_t / n_s) changes over time.

7 Likes

There is a simpler idea: Kill transparent addresses altogether.

Problem solved

2 Likes

Happy cake day

1 Like

Congratulations on hitting your 1 year mark!

1 Like

A related idea was posted a while back on Reddit:

This thread looks (at a glance) like a generalisation of the incentivisation part of that proposal.

1 Like

Is there a zip for the idea described on reddit? I see a comment from @nathan-at-least that ZIP was in-works. Is there a better strategy to go fully shielded?

1 Like

While we’re in the paradigm of suggesting fixed fees (I believe current recommendation is 0.0001 ZEC fee for any transaction with shielded components), perhaps we could implement some variation of a discount. For example, consensus enforces 0.0001 ZEC fee for transactions sending to/within sapling shielded pool, and 0.0002 ZEC for other transactions.

A few small notes on boundary conditions:

To incentivize users to prioritize the sapling shielded pool, they should pay more for a non-sapling transaction.

To avoid perverse incentives for miners they should receive more fees for sapling transactions. Otherwise, transparent transactions would be smaller and better paying!

How can we reconcile these two? Some of the fee could be burned (or donated to dev fund or whatever). So we might have something like this:

Transaction to/within sapling: user pays 0.0001 ZEC, miner takes home 0.0001 ZEC
Transaction without sapling: user pays 0.0002 ZEC, miner takes home 0.00009 ZEC

Just floating this idea, nothing to take too seriously.

(Quick note: If we ever implement a dynamic fee mechanism to keep things running smoothly with high transaction volume, then fee per unit size to meet the constraints listed above.)

// edit: typos //

2 Likes