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.
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.
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.
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.
Excellent discussion on this proposal (thanks for initiating, @maclane). In an effort to move Threshold forward on this, the Treasury committee discussed in our last meeting and recommends the following:
-
As there appears to be consensus on substantially reducing tBTC staking rewards, we recommend the approach @sap noted in the comment above: cut emissions in half by reducing tBTC rewards from 11.25% to 3.75% and keeping TACo rewards as they are
-
Continue community discussion on whether to “extend the Beta Staker program through the Schnorr upgrade, maintain the permissioned operator set”
-
Assuming this revised proposal moves to snapshot, TTG will discuss with beta stakers and determine any efforts required to keep them staked, or for deprecated nodes provide for “inter-wallet sweeping and the appropriate handover+refresh mechanism”
-
Let the current bootstrap node agreement expire Jan. 31, 2025 (saving $360k annually), and replace the hard-coded IP addresses with beta staker addresses
1
1
Subject to confirmation from @mhluongo & team, as well as scoping of what’s required to implement and whether DAO devs can implement, with Keep guidance.
There are too many opposing proposals and ideas floating around at the current time, with no clear direction of where we’re going.
While reducing inflation addresses the issue to some extent, it does so without any clear direction or bigger purpose. For example, there is another proposal out and likely one soon that propose printing of more T.
To ensure tokenomics and the future of tBTC remains a hot-button issue I do not support a mere reduction in inflation. I am suggesting that we keep this issue hot, and continue to look at alternatives.
Bumping this TIP as a critical component of TIP-100.
TIP-100 specifies February 15 as the end date of the current staking rewards regime, which means this should progress to the next governance stages ASAP.
We plan to move TIP-92 to snapshot tomorrow with these amendments, pending comment:
-
No immediate change to TACo rewards. TIP-100 outlines a transition plan that is being actively developed, and tokens minted in TIP-94 are sufficient for “TACo stakers will continue to be compensated for their availability and service provision for at least six months”.
-
tBTC rewards will end February 15 as described in TIP-100. Upon passage of TIP-92, tBTC stakers may begin the unstake process, and the 45-day cooldown requirement is waived. Development work is underway to allow those who unstake to claim their T soon after Feb. 15, and we will post an update here confirming the date.
Please note that Arj has posted on TIP-100 extensive detail on TACo rewards plan for the 6-month transition period.
Snapshot (noting amendments) is here: https://snapshot.box/#/s:threshold.eth/proposal/0xd334afe182b0aa6aee48c4df3668ad5fe68c2983ed3f914bf2477ab3d937ca82
Hey folks, there’s something that’s not entirely clear to me here I want to make sure we’ve captured, with apologies as I have been off for a week and haven’t been able to follow extra closely. First, let me state some facts as I understand them:
- Currently we don’t pay all beta stakers from the DAO. (There are at least 6 nodes that are operated by Boar that are being compensated entirely via rewards and operationally paid for by other entities out of pocket. I believe there are 35 total beta staking nodes, meaning this represents close to 20% of the beta stakers by count, 7% of the staked T in the system, and 23% of the T staked on beta staking nodes.)
- We are proposing killing all non-TACo incentive for running those nodes and allowing for immediate withdrawal effective February 15th (or as shortly thereafter as can be achieved). That is an insanely tight deadline for any decision-making for what is a fairly large change in value assessment, and is an extremely recent addendum to the TIP (effectively: 15 days from when the idea was proposed to when the compensation equation completely changes, vs the 3-month existence of this proposal). This means it’s likely folks will make some heavily short-term decisions instead of long-term ones—or will be caught completely unawares (e.g. I was off for roughly a week and I’ve returned to see, in snapshot, a proposal that completely changes how I should think about my node’s operations with 5 days’ notice).
- This TIP will pass without TIP-100 necessarily having passed, without a specific guarantee that it will, and without any language indicating that it should not take effect unless TIP-100 passes.
A few questions:
- Did I misunderstand anything?
- Have we done any math on how much T is being insta-unlocked in 5 days if this passes?
- Is the DAO going to initiate buybacks as soon as that happens?
- Have we considered what happens if we use a lower but nonzero cooldown?
- Have we considered what happens if we extend rewards and/or waiving of cooldown until March or April to allow for better decision-making and direct and comprehensive communication of all of the changes being made both to the community & with larger stakers? (And to make sure the rest of the plan passes before any subpart of it actually goes into effect.)
Immediate withdrawal applies only to non-beta stakers. Beta stakes will not be withdrawable until the beta nodes transition to DAO-provided delegations or a DAO-controlled whitelist, which I now prefer and which I think(?) would avoid the need to churn wallets into new nodes.
I’m fine with adding an addendum or vote option to TIP-100 that makes TIP-92 implementation contingent on TIP-100 approval (which I understand will move to snapshot today). But if the DAO decides to reject tLabs, I would strongly advise reapproving TIP-92 and the majority of the DAO reorg as described in TIP-100. The status quo is not sustainable.
To be clear: I don’t disagree that the status quo needs change, and don’t take significant issue with most of what’s in TIP-100 (or necessarily most of what’s in TIP-92). Some of the details are troubling, though.
Immediate withdrawal applies only to non-beta stakers. Beta stakes will not be withdrawable until the beta nodes transition to DAO-provided delegations or a DAO-controlled whitelist, which I now prefer and which I think(?) would avoid the need to churn wallets into new nodes.
So beta stakers, who are securing the most valuable asset in the network, are locked into T while a huge volume (~2B T, 2x the amount staying locked and ~20% of the total supply) unlocks simultaneously, and they don’t get rewards anymore, right? And this happens to beta stakers in 5 days?
Does that not seem like a poor outcome?
Twenty-three of the beta stake delegations are provided by NuCo, three are provided by the DAO, and four by @Agoristen.
I have confirmed that all thirty of these will remain authorized until a safe whitelist transition has occurred.
The changes in TIPs 92 and 100 are admittedly painful.
But this short-term pain (which is concentrated on NuCo) is necessary for Threshold to achieve a good long-term outcome. Stretching out the process delays the required changes and will result in a poor long-term outcome
This proposal has passed with the following results:
Results:
- For: 2b - 95.02%
- Against: 104.1m - 4.98%
- Abstain: 0 - 0%
The next steps for this TIP will take place in the next days, with a deadline to halt rewards for non-beta staker tBTC nodes on February 15th.
Several work groups will work to bring this proposal through the finish line, including the TACo team, Threshold’s Council, Threshold’s Marketing Guild. Please don’t hesitate to ask any questions or doubts remaining in our Discord.
I have confirmed that all thirty of these will remain authorized until a safe whitelist transition has occurred.
The beta stakers aren’t the only folks who are likely to suffer here, even though they get a riskier deal.
Perhaps most importantly, I want to emphasize: I do not see a world where a 15-day notice for a change of this magnitude is good governance! TIP-92 and -100 can be good pain, but the timeline for a change still has to be right. “We’ve been discussing this since November” isn’t an excuse, because there’s been no specific timeline until 11 days ago in a different proposal, at which point the timeline was set to… 2 weeks! 2 weeks isn’t even enough time to communicate to the community that the change is happening, much less enough for people to properly consider their followup actions.
This proposal is very controversial, as it does not provide an adequate notice period for stakers. I strongly agree that this kind of abrupt change is questionable and damages the reputation and
how the Threshold Network is perceived.
Contradiction with TIP-94
The previous proposal, TIP-94, clearly stated that staking rewards would be distributed until February 28, whereas TIP-092 now proposes stopping them on February 15.
Can we get a clear explanation for this misleading inconsistency?
Unreasonably Short Notice Period
The effective notice period for stakers is only four days from the time the proposal passed to the time rewards stop.
This is far too short to communicate with long-term protocol supporters properly. Stakers made decisions based on prior commitments, and such a sudden shift feels unfair.
Unstaking Readiness
Are the smart contracts and UI fully prepared to allow stakers to unstake their T on February 15 without issues?
Beta Stakers
The 30 nodes Maclane mentioned do not represent the entire set of Beta Staker nodes—there are 35 Beta Staker nodes in the network. However, the DAO has not compensated all these nodes, and they will remain locked without rewards or clear guidance on their future. While still being responsible for holding keys to a big chunk of $451MM worth of bitcoin.
The changes prescribed in TIP-100 are difficult. Unfortunately, Threshold is facing a difficult reality. No alternatives to TIP-100 are being advanced and my immediate priority is to ensure that Threshold continues to exist in a viable form.
TIP-94 includes a specific carveout for TIP-92:
As specified in the final TIP, development is underway to enable this soon after February 15: TIP-100 preparation by vzotova · Pull Request #171 · threshold-network/solidity-contracts · GitHub
The TIP calls for the inclusion of the three relevant beta operators into the TIP-67 payment plan:
Once the operators are transitioned to a whitelist, the beta stakers will be able to deauthorize and withdraw.