For discussing the merits of deactivating SELFDESTRUCT
in general, I suggest using the thread for EIP-4758: Deactivate selfdestruct. This thread should be used only for discussing the advantages/disadvantages of preceding this with an exponential gas schedule as a warning to Dapps.
Hi @dankrad , great EIP. I support your idea for increasing the gas cost as a way to warn developer until finally change the functionality from SELFDESTRUCT to SENDALL.
I have a design question: do you have any preference if these smart contract holds ERC20s, ERC721 or other type of contract-based tokens other than just ethers
?
Context: the only relevant text about this question lies in :
Security section: 1. Any use where
SELFDESTRUCT
is used to burn non-ETH token balances, such as ERC20, inside a contract. We do not know of any such use (since it can easily be done by sending to a burn address this seems an unlikely way to useSELFDESTRUCT
)
Just wonder if it’s deactivated for now? Coz I found out it’s currently programmed in draft status
Spells are one use case of a smart contract design pattern that could be affected by this EIP.
Documenting here so that anybody looking to study on-chain usage of SELFDESTRUCT
and the like can know about it.
Spells are where you deploy a zero-code ephemeral smart contract, possibly ending with a SELFDESTRUCT
at the end. All the effect of the spell is in the “constructor” if you’re using a higher level language. Spells can be useful for all types of hacks, such as running a +EV sandwich, minting 100 NFTs in a for-loop against a contract that is expecting one-per-person, stuff with Aave, working with dangerous contracts like potential honeypots. Maybe others know of more mainstream applications and this approach is well documented in Solidity tutorials.