You signed an EIP-7702 delegation authorization, then signed it again for various reasons, and now even your wallet nonce has changed. You start to worry: is this a replay attack? Will my assets be at risk?
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
The answer is: a nonce change does not invalidate your delegation authorization, but it does affect whether the signature can be broadcast on-chain. As long as the contract address you delegated to is safe, no matter how the nonce changes, your already active delegation status cannot be touched.
First, understand: what role does the nonce play in EIP-7702?
The authorization tuple in EIP-7702 has three core fields: chain_id, address (the delegation target), and nonce (the current nonce of the authorizing address).
The purpose of this nonce is replay protection. It ensures that the message you signed is only valid in that specific account state at that time.
When a type 0x04 transaction containing this authorization tuple is included on-chain, the node executes the applyAuthorization operation. The key execution order is: first increment the transaction sender's nonce, then applyAuthorization for each authorization entry. If the transaction sender and the authorizer are the same address, the nonce used when signing needs to be the current nonce plus 1.
What actually happens: when the nonce changes and you sign again
Case A: You signed a second authorization for the same delegation, but the wallet nonce has already changed
The first time you signed, the message used nonce N. You then sent a transaction in your wallet, and the wallet nonce became N+1. Then you signed the same delegation again.
At this point, the second authorization transaction carries a signature with nonce=N and is submitted to the node. What does the node do? It considers this an outdated signature, verification fails, and the transaction is rejected.
The message you signed itself causes no harm at all—it simply cannot be broadcast. The on-chain delegation status remains the same delegate address from the first successful authorization.
Case B: You signed a second authorization for the same delegation, intending to overwrite the first one
If you want to use the same delegation to overwrite the first one, you need to sign a new type 0x04 transaction. The nonce in the authorization tuple must match the current wallet nonce for the transaction to be included on-chain.
If the nonce does not match, the overwrite fails. If the nonce matches, you can change the delegate address to a new target (for example, from contract A to contract B).
How people end up signing the same delegation repeatedly
Common scenarios include:
The user initiates a type 0x04 transaction (EIP-7702 authorization) and confirms it in the wallet.
The transaction is not picked up by miners for a long time due to insufficient gas or network congestion.
The user does not realize this, so they initiate another identical authorization transaction in the wallet.
The nonce from the first transaction has not been used yet. If the second transaction uses the same nonce, it will fail directly, but usually the wallet will assign the next nonce (N+1).
If the first transaction (nonce=N) is later included in a block, the user's wallet address is then delegated to the malicious contract.
Common cause of failure: repeatedly signing the same delegation is not necessarily dangerous in itself. What is dangerous is the "delegate target address" you repeatedly sign. If the first one you signed was a malicious contract, signing it a hundred times will not make it safe. If the first one was a safe contract, signing it repeatedly will not cause problems.
Comparison of correct and incorrect approaches
| Approach | Explanation |
|---|---|
| Incorrect approach | Not looking at the "delegate address" before signing, only focusing on the nonce. |
| Correct approach | Before signing, first confirm whether the target address is an officially whitelisted address. An unsafe delegate address is wrong the first time you sign it, and still wrong the tenth time. The nonce only affects whether the signature can be included on-chain, not the security of the delegation. |
Risk reminder: The official Ethereum Pectra guide clearly states that when chain_id is 0, the delegation is valid on all EVM chains. This cross-chain mechanism increases the risk of signature replay. If the delegate target is not a malicious contract, cross-chain replay will not cause harm. If the target is a malicious contract, cross-chain replay will amplify the loss.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
A checklist for future reference
Before signing any EIP-7702 authorization next time, go through this checklist:
| Checklist item | Safe status | Danger signal |
|---|---|---|
| Delegate target address | An official contract address you have actively verified | An address you do not recognize at all |
| Wallet prompt content | The wallet clearly parses the authorization fields | Only a hash value is displayed |
| Authorization source website | An official DApp you actively visited | A link sent to you by a stranger |
| Whether the action was initiated by you | You clearly know what you are doing | Pop-ups like "upgrade your wallet" or "claim rewards" |
How to verify after completing the operation: Enter your wallet address on Etherscan and check the "Authorizations (EIP-7702)" field in the "More Info" area. If it shows empty or a contract address you trust, the delegation status is under control. If it shows a malicious contract address, no matter how many times you signed, clear the delegation immediately: send a new type 0x04 transaction pointing the delegate address to 0x000...000 (the zero address).
