Closed mehdi-defiesta closed 3 months ago
It might be out of scope
A policy has been decided to allow individuals to burn their coinage during development.
- [ ] Check Coinage function (check if you can leave it as is below) ⇒ Leave it as is
- [O]burn → You can directly burn your own stake.
The burning of your seigniorage was not reflected in the total stake amount (tot.totalSupply()). Therefore, it does not affect the amount of seigniorage issuance. However, it does affect the total stake amount of the layer (coinage). Accordingly, the layer cannot receive seigniorage for the amount burned.
@ggs134 @suahnkim If there is a need to change the previous development policy, please let me know and I will reflect it. Note. To modify this function, coinage's logic for all currently deployed layers must be upgraded.
@Zena-park
Doesn't this function get used when user unstakes (before seigniorage is updated) and burns the amount that they are not supposed to get? Ah nevermind, it is external call never mind, got confused.
i think the design didn't consider actually burning the WTON amount, as it would increase the gas cost?
Anyways, that is my comment.
I think we have two options:
1. add WTON Burning based on _burn amount
2. just leave it and assume that users will not call it
I think it is better to assume that users will not call it, as it would increase the gas cost, and unstake is already expensive
When unstaking, the burnFrom(account, amount) function is used. The function that is currently an issue is burn(amount).
thank you @Zena-park for clarification
I see three options:
If I had to choose one of the above options, I would prefer choice 1. It is up to you to burn your staking amount, and it is a reasonable result that you will not be able to retrieve the amount you burnt. It doesn't affect the system, so I don't think we need to worry about it.
Summary
Burn function is made external and can be called by staked token holders
Vulnerability Detail
Any user can burn his own sWTON. By doing so, his WTON tokens within the DepositManager is not accessible anymore. Issue is Low because there is no possibility of calling this function on behalf of other users.
Impact
TON/WTON definitely stuck into deposit manager. This could lead to supply discrepancy as well. Indeed, as of today, there is no way of extracting WTON/TON from the DepositManager contract
Code Snippet
Proof of Concept
The following script shows the deposit manager discrepancy after burn function is called. As of today, there is no way of extracting WTON/TON from the contract
Tool used
Manual Review
Recommendation
the only function used is the burnFrom function which is restricted to minters only. I recommend deleting the burn function.