Selfdestruct in Smart Contracts: Historical Risk, Forced ETH Transfers, and Contract Safety Checks

What SELFDESTRUCT means in Solidity and the EVM

Solidity exposes the global function selfdestruct(address payable recipient). When compiled, that function produces the EVM SELFDESTRUCT opcode. The instruction takes a beneficiary address, halts the current execution frame, and transfers the executing account's ETH balance according to the network rules in effect.

The name creates an intuitive but incomplete picture. Developers often read selfdestruct as a permanent delete button. That description was closer to historical Ethereum behavior, but it is no longer a reliable description for a contract that existed before the current transaction on a Cancun-compatible Ethereum network.

Under modern Ethereum rules introduced through EIP-6780, an existing contract that executes SELFDESTRUCT generally retains its code, storage, nonce, and account. Its entire ETH balance is transferred to the beneficiary, and the current execution stops. The major exception is a contract that executes the opcode during the same transaction in which the contract was created. In that narrow case, the earlier deletion behavior remains.

This distinction means that reviewers should avoid statements such as “the owner can always delete this contract” without specifying the chain and transaction context. A more accurate finding may be that an authorized account can trigger a deprecated opcode that transfers the contract's full ETH balance, halts execution, and may delete the contract only under the same-transaction creation exception or on a network that retains older semantics.

Why the function still appears in security discussions

SELFDESTRUCT appears in older Solidity tutorials, capture-the-flag exercises, audit reports, factory patterns, emergency-withdrawal designs, metamorphic contracts, and contracts deployed before its deprecation. Older documentation often describes it as a way to destroy a contract and send the remaining ETH to an owner.

Security researchers also discussed the opcode because its historical deletion behavior could invalidate assumptions about code permanence. A contract address that contained code could later become empty. Some architectures paired deletion with CREATE2 to deploy code again at a predictable address. This created patterns where the meaning of a previously inspected address could change without using a conventional proxy.

Modern network changes reduce several of those risks on Ethereum, but they do not erase the historical record. Analysts still encounter old code, old audit language, old deployments, private EVM networks, and chains with different upgrade schedules. Understanding both behavior eras is therefore more useful than memorizing one simplified definition.

Selfdestruct Risk Timeline: historical behavior to modern analysis

The timeline below separates four ideas that are often mixed together: historical contract deletion, forced ETH transfers, the modern limitation on deletion, and the continuing value of finding the opcode during review.

Historical behavior and why contract destruction was considered dangerous

Under earlier Ethereum semantics, executing SELFDESTRUCT marked the executing contract for deletion at the end of the transaction. Its remaining ETH was assigned to the beneficiary. If the transaction completed successfully, the contract's code and storage were removed from the state.

Deletion did not necessarily occur at the precise opcode step. The current execution halted, but final state processing happened at the transaction boundary. A later revert that reverted the relevant execution path could undo the scheduled effect. This transaction-level behavior is one reason simplistic descriptions could be misleading even before Cancun.

The security impact depended on who could reach the opcode. If only a legitimate owner could call a clearly documented retirement function after users withdrew, the design might have been intentional. If any user could trigger it, an attacker could disable the contract and redirect the remaining ETH. If authorization relied on a weak role, compromised owner, or unsafe delegatecall, the apparent destruction function could become a hidden administrative backdoor.

Why code deletion changed the meaning of an address

Users often treat a contract address as an identity. They inspect the code, grant approvals, integrate the address, and assume its behavior will remain available. Historical deletion weakened that assumption. Once code was removed, calls to the address no longer executed the original application logic.

Other contracts could still store the address. Wallet allowances could still reference it. Off-chain databases could continue to identify it as a protocol component. The address remained visible in historical records, but its current executable state had changed.

When deletion was combined with deterministic deployment, a developer could sometimes recreate code at a predictable address. This supported legitimate counterfactual and factory experiments, but it also led to metamorphic-contract concerns, where the code associated with an address could change through deletion and redeployment instead of a conventional proxy upgrade.

Why older audit reports sound more severe

An audit written under pre-Cancun rules may state that a function can permanently destroy a contract, erase storage, break integrations, or enable later redeployment. That wording reflected the network behavior at the time. Applying the finding to modern Ethereum requires separating the original vulnerability from the current consequences.

The authorization issue may remain important even when deletion no longer occurs. An owner-only selfdestruct function can still transfer the contract's complete ETH balance. A delegatecall path that historically threatened code deletion may now threaten an unexpected balance drain from the caller context. A CREATE2 metamorphic design may no longer work as originally intended if it depended on deleting a long-lived contract before redeployment.

Modern Ethereum behavior after EIP-6780

EIP-6780 changed SELFDESTRUCT so that long-lived contracts are generally not deleted. When the contract executing the opcode was not created in the same transaction, the current execution frame halts and the complete account balance is transferred to the target. The contract's code, storage keys, and account remain.

This rule applies through the network protocol. Selecting an older EVM version in compiler settings does not restore historical behavior on a chain that has activated the new semantics. The deployed transaction runs according to the receiving network's consensus rules.

Solidity continues to expose the function for compatibility, but it is deprecated. Compiler warnings reinforce that developers should not create new systems that rely on it. Future EVM changes may reduce or alter its functionality further, which makes it unsuitable as a foundation for permanent lifecycle, upgrade, or fund-recovery guarantees.

The same-transaction creation exception

The historical behavior remains when the contract executes SELFDESTRUCT in the same transaction in which it was created. This includes creation through a contract-creation transaction, CREATE, or CREATE2. In that situation, the account can still be cleared as part of transaction finalization, and its ETH balance is transferred to the beneficiary.

This exception supports short-lived construction patterns that create and remove an account within one transaction. It also means that forced ETH examples using a disposable constructor contract can still work. However, it does not restore the older pattern of deploying a contract, using it across many transactions, destroying it later, and redeploying different code at the same address.

Forced ETH transfers and why recipient contracts cannot reject them

A normal ETH transfer to a contract can trigger its receive or fallback function. The recipient can revert, causing the transfer to fail. This creates the impression that a contract can completely control whether it receives ETH.

A SELFDESTRUCT balance transfer works differently. The beneficiary's code is not executed as part of the transfer. Its receive and fallback functions do not run, so the beneficiary has no opportunity to reject the ETH or update its internal accounting during delivery.

This is commonly described as forced ETH because the recipient's consent is not required. The ETH balance can increase even when the contract has no payable functions or deliberately reverts ordinary transfers.

Educational forced-transfer example

The following minimal contract demonstrates the concept. It receives ETH during creation and immediately sends the balance to a beneficiary through selfdestruct. Because the opcode is executed during the contract's creation transaction, the EIP-6780 exception preserves the earlier clearing behavior for this disposable contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

/*
 * Educational example only.
 * SELFDESTRUCT is deprecated and should not be used
 * as a normal production fund-transfer mechanism.
 */
contract ForceEther {
    constructor(address payable beneficiary) payable {
        selfdestruct(beneficiary);
    }
}

Forced ETH is not the same as stealing ETH

The transfer sends ETH from the contract executing SELFDESTRUCT. It does not let an attacker pull ETH out of the beneficiary contract. The security issue is that the beneficiary's observed balance can increase outside its expected deposit process.

That unexpected increase can still cause harm when contract logic treats raw balance as an exact accounting variable, phase condition, invariant, or source of truth. The vulnerability lies in the recipient's assumption, not in the recipient losing the forced amount.

How forced ETH creates accounting confusion

A contract's raw ETH balance is available through address(this).balance. Developers may compare that value with deposits recorded in storage. The values often match during normal operation, which can encourage unsafe equality assumptions.

Forced ETH breaks the assumption that every wei in the balance arrived through an approved payable function. The contract may hold more ETH than its internal ledger recognizes. If logic requires exact equality, the surplus can block execution or produce misleading calculations.

Fragile exact-balance logic

Consider a contract that waits until exactly 10 ETH has been deposited before advancing. If an external account forcibly adds 1 wei, the balance becomes slightly greater than the expected target. A condition requiring exact equality can remain false permanently, even though legitimate depositors supplied the intended amount.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract FragileFundingRound {
    uint256 public constant TARGET = 10 ether;
    bool public completed;

    receive() external payable {}

    function completeRound() external {
        // Fragile: forced ETH can make the balance exceed TARGET.
        require(address(this).balance == TARGET, "Target not exact");
        completed = true;
    }
}

Separate internal liabilities from raw balance

More resilient accounting records recognized deposits in storage and treats the raw balance as the assets physically available. Forced ETH becomes surplus rather than a new user liability. Business rules operate on accounted amounts, while a separate policy handles unassigned ETH.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract AccountedFundingRound {
    uint256 public constant TARGET = 10 ether;
    uint256 public accountedDeposits;
    bool public completed;

    mapping(address => uint256) public deposits;

    function deposit() external payable {
        require(!completed, "Round completed");

        deposits[msg.sender] += msg.value;
        accountedDeposits += msg.value;
    }

    function completeRound() external {
        require(accountedDeposits >= TARGET, "Target not reached");
        require(
            address(this).balance >= accountedDeposits,
            "Insufficient backing"
        );

        completed = true;
    }

    function unaccountedSurplus() external view returns (uint256) {
        return address(this).balance - accountedDeposits;
    }
}

Where balance confusion becomes dangerous

Exact-balance assumptions can affect lotteries, crowdfunding contracts, payment channels, auction completion, vault invariants, reward calculations, escrow release, collateral checks, and contracts that attempt to prove that no ETH is present. The issue is not limited to visible equality checks. Any formula that assumes raw balance equals internally recorded deposits deserves review.

A contract may also emit deposit events only when its payable function runs. Forced ETH can therefore create a difference between event-derived deposits and the actual balance. Indexers should avoid concluding that unexplained balance growth proves hidden minting or accounting fraud without checking protocol-level ETH movement and selfdestruct transfers.

Source-code review checklist for non-expert readers

Finding the word selfdestruct is only the beginning. The security impact depends on reachability, authorization, execution context, chain semantics, beneficiary control, and related assumptions. Non-expert readers can still ask structured questions without performing a complete audit.

When selfdestruct references are still worth noticing

Modern Ethereum's narrower behavior does not make every reference harmless. It changes the correct risk classification. Several situations still deserve careful investigation.

A privileged function can transfer the full ETH balance

An owner-only destructor may no longer erase a long-lived contract, but it can still move the entire native ETH balance to the selected beneficiary. If the contract intentionally holds ETH, this is a sweeping permission. Users should know who controls it, whether the beneficiary is constrained, and whether governance or a timelock applies.

If the beneficiary is supplied by the caller, a compromised owner may redirect funds to any address. If the recipient is immutable and represents a recovery treasury, the authority is narrower. The source code and permission path determine the practical risk.

The contract relies on deletion for lifecycle control

Some old designs used selfdestruct as a shutdown mechanism. They expected every function to become unavailable after retirement because the runtime code would disappear. On modern Ethereum, an existing contract's code remains. If the same transaction path does not update a permanent disabled flag, the contract may remain callable after the supposed shutdown.

A safer modern approach is explicit state. The contract can set a permanent shutdown flag, revoke roles, disable deposits, and provide controlled withdrawals. Those effects are visible in storage and do not depend on deprecated deletion semantics.

The contract expects CREATE2 redeployment at the same address

Historical metamorphic patterns could destroy a long-lived contract and later deploy different code to a deterministic address. EIP-6780 disrupts this approach because the old code and account remain after selfdestruct when the contract was not created in the same transaction. A later CREATE2 operation normally cannot deploy over an address that still has code or a blocking nonce.

The TokenToolHub CREATE2 guide explains deterministic address calculation and why the deployer, salt, and initialization code matter. Reviewers should distinguish legitimate deterministic deployment from obsolete designs that assume long-lived code can still be deleted and replaced.

The code executes on another EVM-compatible chain

Ethereum network changes do not automatically prove identical behavior on every chain. EVM-compatible networks can activate protocol changes on different schedules, modify execution rules, or maintain older behavior. Test environments and local development chains can also be configured with different hardfork settings.

A multi-chain protocol should document the behavior expected on each deployment. An audit conclusion based on modern Ethereum may not transfer directly to an older fork or alternative network.

The opcode is reachable through delegated execution

delegatecall executes another contract's code while preserving the caller's address, storage, and balance context. Historically, delegated code containing SELFDESTRUCT could threaten the caller account itself. Under modern Ethereum, a long-lived caller generally keeps its code and storage, but its complete ETH balance can still be transferred from the caller context.

This remains security-sensitive because the visible contract may not contain the opcode in its own source. It may delegate to an implementation, library-like target, plugin, facet, or module that contains the instruction. Use the TokenToolHub delegatecall security guide to trace whose storage, address, and balance are active during delegated execution.

Selfdestruct, hidden backdoors, and administrative control

A hidden backdoor is not defined by one opcode. It is a concealed or misleading path that gives an actor more control than users reasonably understand. A selfdestruct function can qualify when it is hidden behind indirect calls, weakly disclosed, controlled by an unexpected role, or able to redirect the full ETH balance.

The access path may be obvious, such as onlyOwner. It may also be indirect. A public function can delegate to caller-supplied code. A role manager can grant the required permission. An upgradeable implementation can introduce selfdestruct after deployment. A registry can change the module used by a router. A contract can decode arbitrary calldata and forward it to a privileged target.

The hidden backdoors research guide provides a wider framework for evaluating concealed minting, blacklist, fee, transfer, upgrade, delegatecall, and asset-recovery controls.

Do not confuse visible deprecation with unreachable code

A compiler warning tells builders that the opcode should not be relied upon. It does not prevent deployment. It also does not prove that the function is unreachable or harmless. A verified contract can contain deprecated logic and still execute it successfully according to the network's current rules.

Conversely, the opcode may be present in dead code that no external path can reach. Reviewers should prove reachability before assigning a severe finding. Source search is a screening method, not the final risk rating.

Selfdestruct inside upgradeable proxy systems

Proxy systems separate the user-facing address from implementation logic. Users interact with the proxy, while delegatecall runs code from an implementation using the proxy's execution context. This architecture changes how selfdestruct findings should be interpreted.

If an implementation contains a reachable selfdestruct instruction and the proxy delegates into that path, the opcode executes in the proxy's context. The relevant ETH balance is therefore the proxy's balance. On modern Ethereum, a long-lived proxy generally keeps its code and storage, but the complete ETH balance can be sent to the beneficiary and the current frame halts.

Under historical semantics, the consequences were more severe because delegated execution could mark the proxy itself for deletion. This is why old upgrade-safety guidance treated selfdestruct and delegatecall in implementation contracts as critical hazards.

Modern limitations do not remove proxy review requirements

An upgrade can introduce a new implementation containing selfdestruct even when the original implementation did not. Users who reviewed the proxy months earlier may not notice the new path. The TokenToolHub upgradeable proxy contracts guide explains how to identify the active implementation, upgrade authority, and implementation history.

Review the authorization for both the proxy upgrade and the selfdestruct function. A strong timelock on implementation upgrades can provide warning before the opcode is introduced. Once the implementation is active, another role may be able to trigger the balance transfer immediately.

Selfdestruct and CREATE2: what changed for metamorphic contracts

CREATE2 calculates a contract address from the deployer address, salt, and hash of the initialization code. This allows an address to be predicted before the contract exists. The mechanism supports counterfactual deployments, account systems, factories, and consistent deployment workflows.

Historically, some developers combined CREATE2 with SELFDESTRUCT to create metamorphic behavior. A contract could be deployed at a deterministic address, destroyed in a later transaction, and then replaced through a deployment process designed to produce the same address with different runtime code.

EIP-6780 limits this pattern for long-lived contracts. If the old contract was not created in the transaction where selfdestruct executes, its code is not removed. A later creation at that address fails while the address still contains code or a conflicting nonce.

The same-transaction exception is not a general upgrade mechanism

A contract can still be created and selfdestructed in one transaction. That exception does not provide the historical multi-transaction lifecycle required by common metamorphic upgrade patterns. Once a contract survives its creation transaction, later selfdestruct calls no longer clear its code on a Cancun-compatible Ethereum network.

New applications that need upgradeability should use an explicit, reviewable architecture rather than depending on deprecated destruction and redeployment behavior. Explicit proxies disclose that logic can change and allow governance controls, implementation events, storage rules, and upgrade delays to be analyzed directly.

What selfdestruct transfers and what it leaves behind

SELFDESTRUCT transfers the executing account's native ETH balance. It does not automatically transfer ERC-20 tokens, NFTs, vault shares, or other assets represented by external token contracts. Those assets are recorded in the token contracts' storage, where the selfdestructing address remains listed as the owner or balance holder.

Under historical deletion semantics, tokens left at a deleted contract address could become inaccessible unless another mechanism allowed the address to act again. Under modern semantics for an existing contract, the code remains, so token-recovery functions may still operate if the selfdestruct call did not permanently disable them through storage changes.

Reviewers should therefore inspect the surrounding function. A supposed emergency shutdown may call selfdestruct without moving ERC-20 assets first. The native ETH leaves, while tokens remain. The outcome can differ substantially from a project description claiming that all funds are recovered.

How to analyze a historical selfdestruct transaction

Historical transaction review helps determine whether the function has been used, which address triggered it, which beneficiary received ETH, and whether the contract's code remained afterward. The correct workflow depends on the block date and network rules active at execution.

Wallet analytics can add context when the caller or beneficiary belongs to a deployer, treasury, multisig, exchange, bridge, or related protocol entity. Nansen can help map some of these address relationships. Labels should be treated as research aids and verified against direct on-chain evidence.

Risk classification matrix for selfdestruct findings

A source-code scanner may flag every occurrence, but the final severity should reflect the executable consequence. The matrix below separates lower-risk appearances from conditions requiring deeper investigation.

Practical selfdestruct risk scenarios

Scenario one: an old owner-only retirement function

A legacy contract contains close(), restricted to the owner, which calls selfdestruct(payable(owner)). The documentation says the contract can be permanently retired. On modern Ethereum, a long-lived deployment generally keeps its code and storage after the call, but its complete ETH balance is transferred to the owner.

The correct review should flag two issues. First, the owner has a native-asset sweep permission. Second, the supposed retirement may not disable the contract. If the design requires permanent shutdown, it should use explicit state and tested access restrictions rather than deprecated deletion behavior.

Scenario two: forced ETH blocks exact settlement

An escrow contract releases an NFT only when its ETH balance equals an exact sale price. Before settlement, another account deploys a disposable contract that sends 1 wei to the escrow through selfdestruct. The balance becomes greater than the expected price, so settlement fails.

The attacker has not stolen funds, but has created denial-of-service through an accounting assumption. The fix is to track recognized payments in storage and avoid treating the raw balance as proof that only intended transfers occurred.

Scenario three: proxy implementation introduces a balance sweep

A protocol proxy originally used an implementation with no selfdestruct instruction. Governance later upgrades to an implementation containing an admin-only emergency function that executes it. The proxy holds ETH fees.

Under modern Ethereum, the proxy usually remains deployed, but the emergency admin may transfer its complete native balance to the selected beneficiary. Users should classify this as a privileged sweep path even if the word destruction no longer describes the final code state.

Scenario four: an audit describes obsolete metamorphic behavior

An older audit warns that a factory can destroy a CREATE2 deployment and later install different code at the same address. A researcher reviewing the protocol today should determine when the contract was deployed, whether the relevant chain activated EIP-6780, and whether the design still attempts multi-transaction deletion and redeployment.

The original audit may have been correct. The current network may now prevent the exact redeployment sequence. However, other factory, authorization, and deterministic-address risks can remain.

Scenario five: chain-specific behavior is assumed incorrectly

A multi-chain application deploys identical bytecode across Ethereum and several EVM-compatible networks. Its documentation states that selfdestruct cannot remove existing code because Ethereum changed the opcode. One network has not adopted equivalent semantics.

The security statement is incomplete. Each deployment must be assessed according to its own execution rules. Cross-chain uniformity in source code does not guarantee uniformity in opcode behavior.

TokenToolHub Research Note: historical risks still influence modern review

Some smart contract risks become historically bounded without becoming irrelevant. SELFDESTRUCT is a strong example. Its most dramatic behavior was reduced on Ethereum, yet understanding that behavior remains necessary for interpreting legacy source code, old audit findings, pre-upgrade transactions, deterministic deployment designs, and contracts running on networks with different rules.

Historical knowledge also improves present-day classification. Without it, a reviewer may overstate the current risk by claiming that every existing contract can still be deleted. Another reviewer may understate the risk by assuming the opcode is now harmless. Both conclusions miss the remaining forced-transfer, authorization, delegated-execution, lifecycle, and accounting consequences.

A mature security assessment records three layers separately: what the source intended, what the network allowed when the contract was deployed or used, and what the network allows now. This method preserves the value of older research without copying obsolete conclusions into a modern risk report.

Wallet safety and contract interaction boundaries

A hardware wallet protects signing keys and helps users review transaction approvals on a separate device. It does not change contract code or neutralize an unsafe protocol. If a user signs an interaction that grants a dangerous approval or deposits into a contract with hidden administrative controls, secure key storage does not remove the application risk.

Hardware wallets such as Ledger and Keystone can support wallet compartmentalization. Long-term assets can remain separate from wallets used for testing unfamiliar protocols. This reduces the exposure of unrelated holdings if an interaction wallet grants an unsafe permission.

The distinction is important: custody security protects the key, transaction review protects the authorization decision, and smart contract research evaluates what the application can do after authorization. All three layers matter.

Practical token and contract review workflow

Token investors rarely need to inspect SELFDESTRUCT in isolation. The finding should be combined with ownership, proxy, minting, blacklist, fee, transfer, and delegated-call analysis. The following workflow keeps the review proportionate.

The TokenToolHub Token Safety Checker can support the first-pass review. Automated results should be treated as evidence for deeper research, not as a guarantee that a contract is safe or malicious.

Related TokenToolHub research

Selfdestruct risk connects to hidden administrative paths, source verification, proxy architecture, delegated execution, deterministic deployment, and broader token risk analysis. Use the following resources when the initial finding points to another control layer.

Builder guidelines for modern contract safety

New contracts should avoid relying on SELFDESTRUCT. The opcode is deprecated, its semantics have changed, and future protocol changes may restrict it further. Explicit state transitions are easier to test, communicate, and preserve across networks.

Common mistakes when evaluating selfdestruct

Assuming the name guarantees modern deletion

On Cancun-compatible Ethereum, a long-lived contract generally keeps its code and storage. The instruction still halts the current frame and transfers the native balance, so the correct finding must describe the remaining effect.

Assuming the opcode is now harmless

Forced ETH, privileged balance sweeps, exact-balance denial-of-service, delegatecall context, same-transaction destruction, legacy chains, and obsolete lifecycle assumptions remain relevant.

Reviewing only the main contract file

The opcode may exist in inherited code, imported modules, inline assembly, a proxy implementation, a facet, or a delegatecall target. Review the complete executable path.

Treating native ETH and token balances as the same

Selfdestruct transfers native ETH. It does not automatically transfer ERC-20 or NFT balances. Asset-recovery claims should be checked token by token.

Applying Ethereum semantics to every EVM chain

Similar bytecode does not guarantee identical network behavior. Confirm the hardfork and protocol rules active on the exact deployment chain.

Ignoring historical context in old audits

Older findings may accurately describe the behavior that existed at the time. Update the consequence analysis without dismissing the original research.

Conclusion: treat selfdestruct as a context-sensitive risk signal

The SELFDESTRUCT opcode has moved from a broad contract-deletion mechanism toward a narrower, deprecated balance-transfer instruction on modern Ethereum. Existing contracts generally keep their code, storage, and account after execution, while contracts that destroy themselves during their creation transaction remain an important exception.

This change reduces historical code-deletion and metamorphic-contract risks, but it does not make the opcode irrelevant. It can still transfer a contract's complete ETH balance, bypass the recipient's payable logic, disrupt exact-balance assumptions, appear in delegated execution, expose hidden administrative power, and reveal designs that depend on obsolete network behavior.

The correct review method is contextual. Confirm the network, block rules, creation timing, caller context, beneficiary, authorization, balance exposure, proxy architecture, CREATE2 assumptions, and internal accounting. Then classify the actual consequence rather than relying on the opcode's name.

Your next action is to verify the deployed source through the smart contract verification guide, run an initial review with the Token Safety Checker, and investigate any indirect execution path through the delegatecall security framework.

FAQs

References and further learning

Use primary protocol documentation when evaluating opcode behavior, Solidity warnings, deterministic deployment, and network-specific execution rules.

• Solidity Documentation: Contract-Related Global Functions
• Solidity Documentation: Security Considerations for Sending and Receiving Ether
• Solidity 0.8.18 Release: Selfdestruct Deprecation
• EIP-6049: Deprecate SELFDESTRUCT
• EIP-6780: SELFDESTRUCT Only in the Same Transaction
• EIP-7569: Dencun Hardfork Specification
• EIP-1014: CREATE2 Deterministic Contract Creation
• TokenToolHub: Hidden Backdoors in Smart Contracts
• TokenToolHub: Smart Contract Verification
• TokenToolHub: Token Safety Checker
• TokenToolHub: Upgradeable Proxy Contracts
• TokenToolHub: Delegatecall Security
• TokenToolHub: CREATE2 Smart Contracts

This TokenToolHub guide is educational research only. It is not investment advice, trading advice, legal advice, tax advice, cybersecurity advice, or an audit. Always verify deployed bytecode, source code, proxy architecture, implementation history, opcode reachability, authorization, beneficiary addresses, network rules, delegatecall paths, native balances, internal accounting, and deterministic deployment assumptions before interacting with a smart contract.