This is a great update to the proposal, @Eastban - thank you! I wanted to comment on the slashing for downtime. We need to be mindful that the current mechanism of uptime calclulation has some warts and corner cases and there have been cases of stakers losing rewards due to this. Personally, I think that rewarding or slashing on uptime is problematic and should be moved to a system of rewarding / slashing based on work done / missed. I don’t think this issue should hold up your proposal update but it is something to keep in mind.
2 Likes
Sybil resistance is fighting a fight we can’t win without sacrificing decentralization.
In this proposal you suggest to kill the economic power protecting tBTC and introduce centralizing elements such as:
- Refusal of new nodes
- A working group; centralized committee who will formulate a sybil resistant plan (which in practice will end up functioning like the current beta node approval process)
You do this by disincentivizing large stakers.
So, we are essentially expanding the beta-set process with none of the advantages. These nodes do no work and they will get paid to do nothing.
If the idea is to retain nodes for the future, there is a major issue here of catering the proposal to low stake nodes over high stake nodes, precisely because of the aforementioned sybil attack.
To fight it, tBTC will have to remain a permissioned protocol forever. This is going backwards. And to fix it the caps will have to be removed in the future. So why introduce them now?
Massively preferential treatment of small nodes is the exact opposite of what we should do to protect the network against very real and serious economic attacks.
I’m counting 75 nodes with more than 3M T staked atm and 58 nodes with 3M T or less. Ignoring beta nodes, the numbers would be roughly the same. So half of the stakers have 3 million T or more.
Assuming 10% APR in T, with current price and maximum of 3M T staked your gain is 3,000,000 * 0,1 * 0,03 = $9000 per year / 12 = $750 per month. Now deduct hosting and operating costs and it’s not worth the time of many stakers. tBTC fees would help on top of that, but I suspect a lot of the larger stakers will leave. I would leave for sure.
I don’t see the benefit of retaining small stakers only, in fact I believe due to the risk of future economic attack we need to retain the larger staker first.
If you flip the proposal on its head and require a minimum of 3M T then the proposal makes more sense. Or better yet: you could limit the number of nodes to 200, and order by T staked. Whoever is node #201 earns zero T. This would introduce competition amongst nodes and force nodes to buy more T in order to not fall out of the top 200 list. This would be much healthier for tBTC security.
5 Likes
Thank you East for the thorough analysis and proposal refinements.
I believe we need to make changes to the protocol, but I’m not certain I understand the thinking behind limiting stake size. I think limiting stake size to 3M would create incentive for large holders to sell their excess, which would create significant sellpressure. Furthermore, the intent behind the beta staker program expansion (TIP-067 Part 1 & Part 2) was to add highly competent operators with significant amounts of T staked to increase security of the network. I feel like limiting stake size would be opposing this.
Based on data from tbtcscan.com, adjusted for inactive and miss-configured nodes:
| Group | # of nodes | Percentage |
|---|---|---|
| Small (<3M) | 78 | 48% |
| Medium (>3M,<10M) | 25 | 15% |
| Large (>10M) | 61 | 37% |
| Totals | 164 | 100% |
According to the sortition pool contract there are 35 beta stakers, which accounts for over half of the large stakes.
I do like the idea of limiting emissions, however.
Another point I believe should be discussed is the allocation between tBTC and TACo. I think it would make sense to adjust a few levers here: adjust the minimum required to stake tBTC to 3M, hold the min for TACo at 40K. Remove the 75/25 split and replace with reward caps for each application that are distributed pro rata. I envision the share of the monthly rewards to be determined based on a twap calculation of stake size.
I also like @Agoristen’s thought:
Limiting the number of nodes that are eligible to participate in this manner would create a strong incentive to buy T, or at least incentive to NOT sell staking rewards. Distributing bridge fees to tBTC operators in the manner @East proposed above appears adequate to me.
I’m not sure there would be a reason to complete the auto-compounding dev work because half of the current stakers wouldn’t be able to take advantage of this option due to stake size limits. However, I think auto-compounding would be a fantastic way to reduce selling incentives.
Another facet to consider are the bootstrap nodes. They are paid monthly in T, which I imagine gets dumped on the market to cover operating expenses. That’s $30,000 in T per month potentially being sold each month. The bootstrap node IP’s are hard-coded in the tBTC client to enable nodes to discover other nodes on the network - I think we should consider hard-coding the beta staker IP addressees in order to sunset the bootstrap nodes hereby saving the DAO a solid stack per month.
5 Likes
I put together a breakdown of the changes to inflation and node profitability based on the current staker set: Node profitability with inflation adjustments - Google Sheets
The spreadsheet presents scenarios based on keeping TACo rewards as they are, and reducing tBTC rewards. Please feel free to fork and input your own numbers for T price/node cost etc.
If tBTC rewards are reduced from 11.25% to 3.75% (a 50% reduction in inflation) nodes with greater than 2M T are profitable, based on the assumed infrastructure costs and T prices.
While this makes the economics unfavourable to some small stakers, the overall impact of reducing inflation appears to be a net benefit. I am in favor of reducing tBTC rewards from 11.25% to 3.75% and keeping TACo rewards as they are.
I think measures can be made to preserve community stakers by the DAO delegating some threshold amount of T to subsidise node running costs. I would love to see a proposal of this kind brought from community operators.
4 Likes