Closed Zena-park closed 2 months ago
npx hardhat run scripts/33-issue-setwithdrawalDelay/deploy/0.deploy.js --network sepolia
DepositManager_setWithdrawalDelay 0x7E459BC07736f735E3E758fbB740c385FB4d466B
setWithdrawalDelayByOwner function, which lets owner to set the withdrawal delay, will be activated only if we find that an operator has abused this feature prior to the agenda is passed.
Simple staking is already patched so that the "Unstake" button is deactivated if it detects that the vulnerability is abused.
DAO agenda to resolve this issue:
Simple Summary Fix overflow vulnerability and limit Operator's ability to set custom withdrawal delay period to at most 30 days.
Motivation Community member, Black Cow, identified overflow attack for withdraw delay that allows the operator to basically reduce the withdraw delay time to 0, effectively removing the withdraw delay time. Tokamak Network contract team verified the result, and also identified that the function can be abused to lock staked TON for very long time (~10^32 years), permanently locking staked TON.
Specification This proposal will limit operator account's ability of setting withdraw delay for their layer2 to maximum of 216000 blocks (~ 30 days).
References
Copyright Copyright and related rights waived via CC0.
develop test and script for CreateAgenda on Sepolia and Mainnet (issue)
createAgenda Tx : https://etherscan.io/tx/0x31d1370bad392ad46f79452be3d40126fd8f00a6f65175faf94ffd0073097cf8
AgendaID : 11 getAgendaNoticeEndTimeSeconds : 1723796759 (24년 8월 16일 오후 5시 26분) Agenda Page : https://dao.tokamak.network/#/agenda/11
I think it would be good if the withdrawal logic also had some delay like the adjustCommissionDelay. https://github.com/tokamak-network/ton-staking-v2/blob/main/contracts/stake/managers/SeigManager.sol#L615
I think it would be good if the withdrawal logic also had some delay like the adjustCommissionDelay. https://github.com/tokamak-network/ton-staking-v2/blob/main/contracts/stake/managers/SeigManager.sol#L615
In terms of service, it seems to be a good function. I will share it with internal developers to hear their opinions and let you know.
this my personal opinion: I think setWithdrawDelay and adjustCommissionDelay have two different goals:
-> in conclusion, I don't think we should add delay effect to setWithdrawDelay
@suahnkim I think the problem can be solved by keeping "setWithdrawalDelayByOwner" method to change the withdrawal delay without delay. If there is a problem in Layer2, it seems more appropriate to call 'setWithdrawalDelayByOwner' method through DAO proposal rather than operator changing delay arbitrarily without the consent of the users.
@blackcow1987
I am not convinced that delay effect is necessary if setWithdrawDelay is used correctly by Operator, and if they use it incorrectly, it will simply add 16 more days to existing withdraw delay time.
If delay effect is added to setWithdrawDelay(), what is your recommended delay effect time?
@suahnkim
setWithdrawDelay
method correctly.setWithdrawDelayByOwner
should not be executed as a DAO agenda, because someone could abuse it.stopping withdrawals
through DAO agenda rather than a withdrawal delay. Since the minimum withdrawal delay is about 2 weeks, I think there is enough room to process the DAO agenda.The goal of this opinion is that when there is an event such as a change in withdrawal period, users need time to react to the change.
@blackcow1987 I understand your point of view, but I disagree.
If there is a security assumption where withdrawDelay has to be set right away, it may be dangerous to have a delay effect. The negative of allowing setting withdrawDelay without a delay effect is far less than the increase of 16 days to withdraw for users, from my point of view.
Please remember that commission is beneficial for Operators, whereas withdrawDelay can affect the whole ecosystem (although this may depend on how our staked TON is used in the future, ex: bonding using staked TON for state root verification or challenge mechanics)
-> this is just my personal opinion.
@suahnkim Thank you for sharing your opinion :) I agree that the change to withdrawal delay has very limited impact for users. I'll leave the decisions up to the team !
@blackcow1987 since we do not know the exact terms of the security assumptions right now,
one compromise we can have is
This way, I think your concerns are met and we can prevent any security issues in the future if we need to.
Anyways, we are always thankful, and appreciate your comments and concerns Thanks @blackcow1987
@suahnkim @blackcow1987 First of all, I agree with Suah's opinion.
The reason I agree with Suah's opinion is that using setWithdrawDelay is the operator's right.
However, even if you have the right, you can't use it as you please. This is because if there is a lot of staking in the operator's layer, the operator will benefit. If the operator uses setWithdrawDelay at will, all the users there will leave and move to other layers, which will ultimately result in the operator suffering a loss.
Therefore, using setWithdrawDelay is the operator's right, and it is also the operator's responsibility to suffer losses by using it without reason.
Thank you for always giving BlockCow good opinions.
@blackcow1987 Our internal team had a discussion about your request.
We are thankful for your opinion and support and look forward to your vote on this agenda.
If you have any questions or other concerns, feel free to share them.
Sincerely, Tokamak Network contract team
@suahnkim Thank you to the Tokamak Network contract team for considering my opinion :)
@blackcow1987 3,300 TON has been paid as bounty
This will be recorded in the description under DAO agenda as well.
Please note that this issue will be closed when DAO agenda is successfully passed.
Describe the bug
Configuration
Impact
Recommendation
Exploit Scenario
Demo