New Proposal To Circumvent Direct Token Increase

Dan from P-OPS threw down the gauntlet and challenged me to come up with another way to massively reward current validators, without an inflationary increase in rewards. Let me pre-emptively say I still strongly believe new tokens should be minted, my opinion has not changed there.

But in the spirit of the challenge, a few neuronal circuits closed…perhaps from all of the financial engineering I’ve read about in my life, and I came up with the following idea, which is admittedly a bit out of left field and to my knowledge unprecedented in the blockchain world.

VNS: Validator Network Security token (Dan’s name)

How, exactly, could a validator be rewarded without money? Really, there is no way, and frankly I nor anyone who would potentially come in and validate from the outside world would be interested anything other than money. This is a financial revolution after all.

So rather than giving the validator extra money now, we mint a new token which gives him/her the right to money LATER. Specifically, a percentage of ALL future returns from fees on the network.

Eventually, long term, every protocol from harmony to bitcoin wants to run entirely off fees, not new rewards. New rewards really are at their core solely a bootstrapping mechanism for a protocol, not a steady state. But this is really a long term goal. So why not dangle this carrot on the stick in front of validators and have them chase it?

More specifically, lets say a totality of “T” VNS tokens are ever issued, to be rewarded to validators at some preset rate, for some preset time while the network is being boot-strapped. Let’s say 1% of all future fees are blocked off to be rewarded to holders of this token. Then, by holding “t” VNS tokens, every epoch an account holding t tokens would be credited with .01*t/T proportion of all fees from that epoch. For every epoch, for eternity.

So this proposal does a couple things:

  1. it meets the requirement that no new tokens are issued, but validators are still financially rewarded.

  2. It strongly binds the holder to the future health of the network. The validator only makes money if the network succeeds. And if it succeeds wildly, potential ENORMOUS levels of money for the remainder of his/her life. This truly is the crucial component which in some ways makes it preferable to a new token insurance: it aligns the incentives better than just handing out extra tokens which the validator could then market dump and leave (although, I DO believe locking would solve this problem also). It makes the validator WANT the network to succeed, and do everything he/she can to make that happen, beyond just validating. It dangles a carrot on the stick in a way and forces the validator to chase it, with potentially enormous (and therefore highly seductive) reward.

One thing I will say is the 1% was really arbitrary. The total amount of future fees to be rewarded to this token should be really small…This is potentially an enormous return, and not just enormous but perpetual cash flow, similar to a perpetual annuity, for the eternity of the life of the protocol…really a potentially huge payoff. Risky, but that’s why we’re here anyways.


What happens if VNS gets traded on a Harmony Dex? Wouldn’t people prefer to buy VNS to earn rather than stake their ONE? Sort of a weird problem.

1 Like

I think this adds too much complexity to the problem, more things to worry about, a no from my side. I understand you are trying to incentivize staking, but i think this should be done at protocol level on ONE tokens.

I agree with @Lucian on this, it could drive away interested on ONE and other problems we haven’t even thought about yet.

With all due respect you didn’t really think that through: of course it would be tradeable in any way the owner of the coin wanted, and the market would set the rate. That’s nothing that we as the creators have to worry about. And there’s nothing wrong with the market setting the rate: this whole crypto revolution is about radically free markets, after all

That being said, I agree with the next comment, it probably adds too much complexity at a protocol level to be worth the implementation, a more elegant solution would simply be deal with the ONE token directly. I was simply throwing down this idea as a result of a request

1 Like