Staking: Incentive Problem

Developers
1

You can find the slides at https://docs.google.com/presentation/d/1bBsHnmwLRTp4Ye0Z98_bW7Erf3V0Dxn-Rm-BmSu5yqg/

Would love to hear what people think about this video. Any other ways to incentivize users you can think of? Any problem you think I didn’t mention?

7 Likes
2

0:48 “Some pools may want to incentivize beyond the protocol reward”

Can you explain why you think this would be?

It seems from the recent materials released that Cardano wants to disincentive pools from getting to large. Additionally there seems to be a built in protocol benefit to joining a pool that is not full. My limited imagination can’t see this happening under reasonable circumstances, maybe you could share your thoughts on this.

3

If you implement the smart contract proposal I made, then the pool can take 0% fee and make its money in other ways (through promotions, etc). If that becomes the case, you may have pools that can handle going slightly over the cutoff for rewards because users still make more money from airdrops & other such things than they would gain by joining another pool.

I didn’t mention this in the video (because I forgot), but you can imagine if a pool suddenly announces an airdrop of a popular token for only one epoch. Everybody will switch to the pool even if they get nothing in order to get the airdrop and the pool could end up temporarily owning a large part of the network.

4

I would speculate that only whale dominated pools will try this 0% - with the idea in mind to make the rest quit

5

As far as I remember, there was mentioned somewhere in the videos/docs/papers that they do not really want to have a pool bigger than 1/k of the all stake delegated, where k is the number of the registered pools, which makes sense.

Also, I think the block generating rewards will be automatically rewarded to the stakeholders and not to delegates at the beginning of the next epoch. So, rewards only in every 5 days. But, that’s not really clear who will get the transaction rewards and how the pools will be incentivised.

We will know much more when testnet goes live.

1 Like
6

Afaik, that was reworked later to have some fixed, or at least limited k, since unbounded value would allow to reduce existing pool’s profits just by registering new pools, even without getting actual delegates to switch.

In any case we will have to wait for the Prof.Koutsoupias’ paper to get all the details.

UPD: If I remember correctly:

  1. Minimal K makes sense, so even if your system have <K pools - their profit will be bounded, incentivising people to make more pools
  2. Maximum K makes sense so that when you already have hundreds of pools - system will not get spammed by lots of empty pools that just reduce everyone’s profits. But that prolly might be calculated dynamically.
4 Likes
7

Yes, I agree, but I was referring the size of the pool and not the number of pools and both make sense.

So, these two would reduce the surface attack that Sebastian’s mentioned as pools would not have too much space to grow. So, they just could incentive the stakeholders to a certain degree which is 1/k (percentage) of the all delegated stakes, means if there are only 50 pools then max. 2% of the all delegated stakes can be delegated to that pool. So, I would not expect too much pool competition as the delegate rewards should be static across the pools.

But, I am not sure how they will bootstrap Shelley as currently every stake is automatically delegated to the IOHK’s dedicated core nodes. So, I think when new pools are getting registered all stakes will evenly be distributed to the pools until they reach the k number. Only after this, the stakeholders would be allowed to delegate their stakes to the pools directly.

Of course these above based on the following assumptions:

  1. defined number of pools (k)
  2. defined max allowable stakes delegated to a pool (1/k)
  3. pools must be registered
  4. Initially, evenly distributed stakes between pools
  5. rewards are paid automatically by the protocol.
  6. rewards are paid in the next epoch
  7. block generating rewards are paid to stakeholders directly
  8. transaction rewards are paid to the stakeholders directly
  9. rewards for pools are automatically deducted from the stakeholders’ rewards and paid directly to the delegates/pools
  10. Pool reward is global and can only be adjusted by the protocol and not by individual pools
  11. pools do not need to have stakes on the Core node (to protect the Core nodes for leaking private keys)
  12. pools need to be punished somehow (despite 11.)

I am curious how many of my assumptions would hold in Shelley. I would say only 30%.

4 Likes