TIP-100 preparation #171
TIP-100 preparation #171
Conversation
vzotova
commented
Feb 13, 2025
•
vzotova
commented
- Block new stakes, top-ups, authorization increases, slashing, and everything that won’t be needed during transition
- Forced deauthorization of Beta stakers
- Forced deauthorization of all stakes above 15m T -> so only 15m T is authorized and earns rewards
- Opt-out deauthorization of 50% of each remaining stake
…xisting deauthorization
vzotova
force-pushed
the
tip-100-preparation
branch
from
ce10810 to
50df19c
Compare
vzotova
requested review from
cygnusv,
pdyraga and
lukasz-zimnoch
as code owners
|
I am confused about the proposed changes and how they relate to TIP-92. The TIP-92 says:
What I believe this Pull Request currently proposes is to allow anyone to decrease their stake up to 15M T but it does not allow them to unstake everything. Also, I am not sure if using the I am also unsure about removing the functions for staking and increasing authorization. Why to prevent new T stakers from staking if they want to run TACo nodes or why to prevent the DAO from adding new beta stakers to tBTC? Until a change is made to how the wallet registry and sortition pool work - and note the sortition pool is not an upgradeable contract - this is the only way to add new beta stakers. Same question for increasing authorization. One that currently has 1M T stake in TACo, may want to increase it to 15M T stake, I think we should not be disallowing it. Last but not least, I fundamentally disagree with TIP-92 idea of locking the stake of an arbitrary group of stakers by majority vote. The beta stakers did not opt-in for the new rules and the majority shouldn't change them in the middle of the game, especially with such short notice. |
| /// Can be called by anyone. | ||
| // TODO consider rename | ||
| function forceCapDecreaseAuthorization(address stakingProvider) public { | ||
| //override { |
There was a problem hiding this comment.
is this comment useful? or just a leftover of some code you wanted to delete? I mean the //override {
| } | ||
| } | ||
|
|
||
| require(deauthorized > 0, "Nothing was deauthorized"); |
There was a problem hiding this comment.
just in case you prefer this wording
| require(deauthorized > 0, "Nothing was deauthorized"); | |
| require(deauthorized > 0, "Nothing to deauthorize"); |
| ); | ||
| cleanAuthorizedApplications(stakingProviderStruct, 1); | ||
| } | ||
|
|
||
| // TODO consider rename |
There was a problem hiding this comment.
I think this name is ok. Or at least I can't think of a better one.
| maxAuthorization = MAX_STAKE; | ||
| availableToOptOut = HALF_MAX_STAKE; | ||
| } | ||
| require(availableToOptOut >= amount, "Opt-out is not available"); // TODO rephrase |
There was a problem hiding this comment.
What about...
| require(availableToOptOut >= amount, "Opt-out is not available"); // TODO rephrase | |
| require(availableToOptOut >= amount, "Opt-out amount too high); |
