Suggestion: Locked tokens from Transfer Fees - could be burned
BlockLunch opened this issue · comments
Catwifhat ($CWIF), contract address "7atgF8KQo4wJrD5ATGX7t1V2zVvykPJbFfNeVf1icFv1" is a Token Extension project that uses Transfer Fees as an auto-burn mechanism.
The token currently has 964 trillion+ of a 1,000 trillion supply locked forever using Token Extensions, which leads to an insanely high Fully Diluted Market Cap on sites like CoinGecko/CoinMarketCap and Solana Explorer.
My request as the creator of $CWIF is an addition to Token Extensions where projects that use a Transfer Fee with no withdraw authority can have their permanently locked supply burned periodically. In our case, this would get rid of the confusing ~$1.8 billion FDMC while $CWIF's market cap is actually only around $65 million.
I don't think this is generally the best option -- in some cases, a mint with no fee withdraw authority might not like the burn behavior, perhaps using the amount withheld as a proxy for total amount transferred. In that case, the behavior you're proposing would be destructive for them.
The better option is to give the withdraw authority to a PDA on a program that will withdraw and burn withheld tokens all at once, and then anyone can run a crank to harvest and burn fees.
I appreciate that this isn't possible for this token since the authority has been revoked unfortunately, but we shouldn't change the protocol for everyone based on one-off needs, especially when a good, simple, and composable solution exists.
I don't think this is generally the best option -- in some cases, a mint with no fee withdraw authority might not like the burn behavior, perhaps using the amount withheld as a proxy for total amount transferred. In that case, the behavior you're proposing would be destructive for them.
The better option is to give the withdraw authority to a PDA on a program that will withdraw and burn withheld tokens all at once, and then anyone can run a crank to harvest and burn fees.
I appreciate that this isn't possible for this token since the authority has been revoked unfortunately, but we shouldn't change the protocol for everyone based on one-off needs, especially when a good, simple, and composable solution exists.
Those are very interesting suggestions for needs that other projects may have in the future. Those are not our needs however. Unfortunately a program that withdraws and burns the tokens is a very centralized approach, and we have stuck with completely decentralized methods for $CWIF from day 1, hence no withdraw authority.
Sorry, maybe it wasn't clear, but the burn program should be permissionless, making the whole thing totally decentralized!
In my opinion there can't be any trust in a system that has a withdraw authority. The withdraw authority enabled would make the entire process itself centralized.
Would it be possible to add a process_burn_withheld_tokens_from_accounts() function that just clears the withheld amount but does not add it to the destination? Or it could even take an amount and do a checked_sub() instead. If you wrap this in an instruction and invoke in a transfer-hook this is an auto tax burn.
If you think this is an okay idea, I will submit a PR for it!
Maybe I'm misunderstanding, but people can't just burn withheld tokens -- they belong to the withdraw withheld authority
And unfortunately, since there's no re-entrancy in Solana, you can't call token-2022 from a transfer hook program
@joncinque The main issue here isn't whether the transfer fee is burned; the issue is rather that transfer fees that have no withdraw authority (a revoked withdraw authority) still appear in the token's Max Supply. This seems misleading as the tokens will never be in circulation again, so why do they appear in the Max Supply? I believe @tonton-sol's function aims to solve the Max Supply issue without burning any tokens, but please correct me if I am wrong.
It's a similar situation to tokens held in frozen accounts where the mint has no more freeze authority -- those tokens will also never be in circulation, but they are still part of the mint supply.
@joncinque The idea would be for the withdraw authority to burn these tokens from the recipients account. When you say Solana does not support re-entrancy, are you referring to the recipient account being write-locked during the transfer? So in the same vein, you couldn't also withdraw the tokens in the transfer-hook as well? (I know the transfer-fee extension itself was designed to avoid this for parallelism)
@tonton-sol If that's the case, I believe it would be beneficial to separate the "Withdraw Authority" and "Burn Authority" into two distinct entities. Withdrawals of transfer fees can significantly impact projects, whereas burning transfer fees primarily affects the Max Supply with minimal other consequences.
Personally, I am in favor of a Burn Authority and wish it could be implemented for $CWIF. The issue with having a "Withdraw Authority" is that it compromises decentralization by placing too much trust in a single party, which could potentially misappropriate the transfer fees. However, if Withdraw Authorities could be revoked while allowing the original Withdraw Authority to retain a Burn Authority, it would be a revolutionary step towards decentralized burns.
When you say Solana does not support re-entrancy, are you referring to the recipient account being write-locked during the transfer?
@tonton-sol Not quite -- on Solana, you can't:
- execute program A
- from A, CPI into program B
- from the program B CPI, do another CPI back into program A <-- this is the re-entrancy step
@BlockLunch we could potentially add a separate BurnWithheldTokens instruction and burn_withheld_authority, but it would have to be a new extension, which means that it could not be added to existing tokens
@joncinque So you couldn't even cpi into token22 to mint a token while inside a transfer-hook?
So you couldn't even cpi into token22 to mint a token while inside a transfer-hook?
@tonton-sol that's correct