Vector bonds: dynamic consensual liquidity in DPoS blockchains

edwardthomson (52)in #pos • 7 years ago

tl;dr: bonds in PoS blockchain which have dynamic liquidity and payout.

The idea for this post was inspired by a comment in the Polkadot whitepaper (PDF). As you will hopefully be aware of by now is that the upcoming Polkadot network will be Proof of Stake and consequently earning a block reward will require staking coins ("dots" in this case).

Image source: https://polkadot.network

In the whitepaper the value of the minimum holding period and the payout are static single values. My suggestion is to make both dynamic and to allow the values to be set by the market. The suggestion of a 'vector bond' is that you have a single address making multiple nominations to a validator at different levels of lock-in / return.

The word "vector" should probably be replaced by "array" but the former was the first that popped into my head, and sounds more pleasant on the ears, but the word "array" is more fitting from a technical accuracy point of view.

To the best of my knowledge current PoS blockchains don't pay a block reward to the validator nodes, as you get with mining, but rather the nodes only take transaction fees as their reward. What I'm suggesting here could be implemented in any PoS blockchain.

I could wrong in suggesting that this applies to all PoS chains as it may only be possible in Delegated PoS chains, but for now I'm going to overlook that nuance.

Bonds in (D)PoS

The staking of coins essentially creates a "bond" between the investor (polkadot: "nominator") and the validator node. You can think of this bond in two senses of the word, that

two nodes are logically linked, or bound, together.
having coins at stake will earn an 'income' similar to a financial bond.

As you will see from Wikipedia that the etymology of the latter implies the former.

Staking in Polkadot

The current suggestion is that in order to earn a reward in Polkadot you will have to stake your coins and incur some risk. Whilst the coins are bonded they are helping to secure the network (via cryptoeconomics). There is going to be a dynamic rate of inflation in Polkadot such that everyone who stakes their coins will earn a pro-rata payout of the new coins created. To re-state that: the supply of coins ("dots") in Polkadot will increase every year, but will be awarded to those addresses which have their coins being staked.

It should be clear to see why having dots at stake in Polkadot is just like a financial bond: you will earn an 'income' in dots when your dots are staked.

Minimum staking period

However, my issue with the mechanism described in the Polkadot whitepaper is that the minimum duration of being bound is a single static value which is hard coded into the protocol. At least, that's how it was described in the whitepaper; however, after talking with one of the developers that may not be the case. The reason for having a minimum period is to prevent "nothing at stake" attacks.

Dynamic minimum staking period

Nothing at stake attacks are a valid concern, although I do wonder if the lack of liquidity in Polkadot will be a turn off for many would-be investors. There is a balance to be struck between liquidity and preventing attacks. If you recall a previous article I wrote I called out my fears on the potential illiquidity of dots. My suggestion is to relax the minimum holding period in order to improve liquidity, but improving liquidity would come at a "cost": a smaller payout for enhanced liquidity. Ultimately, this means having your holding diluted due to inflation.

Polkadot Improvement Proposal 001:

Vector bonds with dynamic consensual liquidity

I dropped this idea into the technical chat channel of Polkadot a few months ago and joked that this was PIP001, hence the title. To be clear: this isn't an official suggestion. ;-)

Vector bonds will let the validators offer up differing values of minimum staking period and rates of return. The max payout (i.e. max rate of return) would be the pro-rata share of inflation which would relate to the highest value of minimum staking period. This value could potentially be set by the protocol, but I think it could be set by the validator notes. The lowest value for the minimum staking period might need to be set by the protocol in order to mitigate "nothing at stake attacks". I haven't done a full analysis of this idea: it is still quite raw.

Vector bonds have dynamic payouts

As it should be clear by now, the notion of a "vector bond" is to implement validator nodes in a blockchain in such a way that they can offer varying levels of return all at the same time. The varying levels of return are linked to the minimum staking period: e.g. the rates of return could be (1, 1/2, 1/3, 1/4) with minimum staking periods of (30, 15, 10, 7.5) days respectively. These payouts are fractions of the pro-rata creation of new coins that nominators are entitled by the protocol. These values can change from node to node, as well as change over time.

The benefit is that the nominators can stake coins at the rates best suited to their appetite for risk. Participants (nominators) with a low appetite for risk may wish for enhanced liquidity and accept a lower payout. In short, this would be a market solution to liquidity.

Could a validator offer minimum liquidity with full payout to all those whom are bonded with it? Yes, and this is probably seen as undesirable for the network on aggregate but there is an easy way to discourage this behaviour though.

How to discourage a validator from offering minimum holding period with full payout

When a nominator choses not to take the full payout the fractional tokens left over could be kept by the validator. The larger the fraction of inflation that validators give away the less they keep for themselves: by reducing the max payout for short term holding periods the validators can keep more of the inflation reward.

Validators are therefore incentivised not to offer the maximum payout, but if they keep too much reward then the nominators can look for another validator to bond with. Keeping tokens held in bonds at the max payout (longest holding period) is probably the most desirable state for nominators in the long term since those stakes suffers the least from inflation dilution.

There is a potential problem if all validators agree not to pay the max payout and force nominators to accept lower payouts: i.e. form a monopoly. However, I think this would require every single validator to agree to this. If just one validator chooses to be different then I believe the nominators could chose to bond with that validator. The Web3 foundation could provide such a node in order to prevent this sort of behaviour. They are incentivised to do so in order to preserve their reputation. I'm also guessing that there is no limit to the number of bonded nominators that a validator can accept (this may not matter in practice anyway).

Conclusion

Implementing my suggestion of "vector bonds" in Polkadot, or any PoS blockchain, will allow validators to offer dynamic liquidity and 'return'. For me this is desirable since it allows the market to set the rate of return and liquidity rather than having the values hard coded into the protocol by the developers. By default, this also allows for dynamic pricing of the bonds (per node) as well as yield curves as we see with the real bond market. In theory, the validators could set as many different rate returns and holding periods as they want: it doesn't need to be limited to just 4 rates as I illustrated above.

Even if this suggestion is implemented I suspect that many people will be lazy and won't differ from the default values coded into the Polkadot software. While validators could choose to offer varying levels of payout it may not turn out to be the case for most nodes.

Feedback from Peter at Parity

Peter at Parity responded to my comments in the Polkadot tech chat and pointed out that a minimum holding period exists to prevent "nothing at stake attacks". He also suggested that there might not be a single value of holding period and return but didn't say much else. This would be somewhere between my suggestion here and how I first understood what would be implemented when I read the whitepaper. Good to know and it will be interesting to see how the protocol develops over the next couple of years.