| CIP No. | 151 |
|---|---|
| Title | SELFDESTRUCT only in Same Transaction |
| Author | Chenxing Li (@ChenxingLi) |
| Status | Final |
| Type | Spec Breaking |
| Created | 2025-02-08 |
This CIP replicates EIP-6780, which prevents contracts from being destroyed by SELFDESTRUCT in most cases, with the only exception being the destruction of a contract within the same transaction as its creation.
EIP-7702 enables the setting of a proxy contract address for an EOA (Externally Owned Account), allowing the EOA to be called like a contract. However, if a contract executes SELFDESTRUCT, it would kill the EOA, reset its nonce to zero, and lead to significant security issues such as replay attacks.
Even if one argues that the owner of the EOA is responsible for delegating their account to secure code, the act of clearing the EOA breaks numerous assumptions in the blockchain system's implementation. Therefore, to implement EIP-7702, supporting this EIP-6780 is a prerequisite.
Same as EIP-6780.
Additionally, the destroy function in the AdminControl internal contract will no longer be usable and will result in an internal contract error.
The destroy function in the AdminControl contract is equivalent to a contract actively executing SELFDESTRUCT. As a result, after this EIP, the destroy function will only transfer the balance of the specified contract to the caller (its admin). However, there is almost no reasonable justification for this behavior. If the contract's business logic requires such functionality, it can be implemented directly within the contract's code. Retaining this capability solely introduces security risks to the contract is not advisable.
Another behavior that was previously considered was to leave the destroy function in the AdminControl contract unchanged, allowing it to retain the ability to destroy contracts. However, this option offers little benefit. First, the Ethereum community is actively encouraging the deprecation of this feature (see EIP-6049). Second, in the context of AdminControl interactions, 99% of transactions involve setting the contract's admin to the zero address, signifying that the project team responsibly relinquishes the destroy authority granted by the admin role, while less than 1% of transactions actually utilize this feature. So the benefits it provides are far outweighed by the complications it introduces. This modification also limits the admin's permissions to managing peripheral functionalities (e.g., managing contract sponsorship whitelists), allowing the ecosystem to benefit from the admin mechanism without being scrutinized for holding sensitive permissions.
This CIP is Spec Breaking.
N/A
Copyright and related rights waived via CC0.