Both point at one property: the authorization stays onchain for a long time. The address and private key stay put, execution moves to another contract, and the permission holds until it is overwritten or revoked; for EIP-7702 delegation that means very different things to an account used ten times a day and one touched three times a year.
A hardware wallet is a device form factor, a cold wallet is a holding pattern, and the two often overlap without being the same thing. It suits readers who already separate custodial from self-custody setups and plan to hold assets onchain for years. The order of judgment runs from holding horizon, to the signing device's capability, to the trusted delegate list.
Key Takeaways
-
A cold wallet's risk surface scales with holding horizon, and one delegation can span years.
-
Delegating to a Safe-style multisig contract does not turn an EOA into a multisig; the original key still bypasses any signing policy.
-
Some hardware wallets cannot sign an authorization list, so gas sponsorship and smart-account activation are not open to every hardware user.
-
Delegate only to contracts that are immutable, not proxies, and deployed from standard CREATE2 initcode.
-
Enable delegation on a hot wallet for daily use and keep a long-term cold wallet as a plain EOA.
Why Does a Cold Wallet Carry a Different Risk Surface?
A cold wallet pushes three variables to their extremes at once: a long holding horizon, concentrated value, and rare signing. A cold wallet with delegation enabled is still a standard cold wallet, not a separate device category, so the same authorization is a reversible experiment on a hot wallet and a multi-year execution path on a cold wallet.
A long horizon means change notices never arrive. Cold storage is considered the gold standard for securing crypto because private keys stay offline and preserve access to assets on the blockchain, and EIP-7702 does not change that fundamental offline security, though delegated code still introduces smart-contract risk if the code has vulnerabilities.
Nothing prompts the holder when the delegate is upgraded, and if the target keeps an upgrade path, the upgrader holds execution power over every delegating account. Concentration raises the cost of a single judgment: the loss ceiling is the whole balance.
Multisig is the most common misreading. Pointing an EOA at a Safe-style multisig contract does not make it a multisig: delegation changes only the code field, signatures still come from the original private key, and one key can bypass any signing policy while delegated code can gain broad control of the account’s behavior.
Used to bolt a "two people must approve" gate onto a cold wallet, it raises no threshold and adds a layer of contract code to the attack surface.
What Access Does Delegation Add, and What Does It Take Away?
Delegation gives an externally owned account smart-contract-wallet functionality, allowing it to temporarily act like smart contracts during a transaction without moving funds to a new address, while keeping the same identity and transaction history, adding four capabilities and removing one natural limit.
-
Batching: approve and swap in one transaction, with no approval left sitting unfilled.
-
Gas sponsorship: signing split from paying, so the account needs no ETH up front.
-
Session keys: limited authority handed to a temporary key while the main key stays off duty.
-
Recovery: a passkey or guardian set can replace single-key validation inside the delegate, adding programmable permissions and other wallet features.
What leaves is the limit that an EOA sends one transfer at a time. A plain transfer used to skip contract code entirely; after delegation it must enter the execution path, and a delegate without receive() or fallback() makes exchange withdrawals and airdrops revert. That extra flexibility improves functionality, but if misused it can expose the wallet to phishing, malware, and smart-contract vulnerabilities.
Batching also lets one signature release several actions at once, so phishing risk in batch transactions is no longer capped at a single transfer.
Delegation has no expiry and stays live until it is overwritten or revoked with a zero address.
A hot wallet's delegation gets re-examined through daily use; a cold wallet's does not; users need to verify what delegated code will do before they accept the change, because the account will continue to behave under that code until revoked; checking and revoking a delegation shows that revocation clears code but leaves storage and token approvals in place.
Can a Hardware Wallet Sign an Authorization Tuple?
Not always. Signing an authorization list requires firmware that parses the type 0x04 structure and shows the chain ID, delegate address, and nonce on screen, so the holder can verify the authorization data needed to determine what the wallet will do after signing; the device must display the transaction details or full authorization message before the user can safely sign transactions, and some devices sign only ordinary transactions and reject an authorization tuple outright.
The consequence is a truncated feature set: gas sponsorship and smart-account activation both need that one signature from the device, and without support a cold wallet stays a plain EOA. Wiring it into a software wallet that does support delegation moves signing into a networked environment, such as a browser extension, which defeats the point of cold storage.
Some users may also need extra testing before they rely on a device workflow to perform authorization-list signing, especially when firmware support is new or incomplete. Setting up and validating that process may require extra research when support is still new. Linea's EIP-7702 notes record this gap on the signing side.
The check is whether the screen can show the full tuple; a device that displays only a "signature request" is worse than one that refuses.
What Is a Trusted Delegate List, and Why Does a Hardware Wallet Need One?
A trusted delegate list is a vetted set of contract addresses approved as delegation targets. It turns "who am I signing for" from an on-the-spot judgment into a pre-reviewed allowlist, and the wallet compares the target against trusted terms or a trusted allowlist before signing so the holder can verify the destination instead of relying on a generic signing interface.
Hardware wallets need it most because the screen cannot carry the full context. A device usually shows only the target address and function name, leaving the holder unable to check bytecode or proxy slots on a small display; moving that review into the list leaves the device one job, confirming the address is on it.
Wallets also should not expose an interface that lets applications suggest arbitrary delegation targets. EIP-7702 guidance in the Pectra docs treats arbitrary delegation with caution, and the trusted list is what practice converged on. EIP-7702 is designed for backward compatibility with ERC-4337, which is why wallets should still constrain delegation targets carefully.
For long-term storage the criteria tighten to three: immutable code, no proxy, and deployment from CREATE2 with standard initcode. Immutability blocks a later logic swap, the absence of a proxy blocks a rewrite through an EIP-1967 implementation slot, and CREATE2 with standard initcode makes the address recomputable from code.
Immutable code is also better battle-tested because users can inspect and verify exactly what will run, while unusual deployed patterns and other edge cases should stay outside the trusted list. Chain ID is separate: an authorization signed with chain_id 0 is valid on any EVM chain, so a cold wallet should sign the specific value per chain.
How Should Hot and Cold Wallets Split the Work?
The split depends on two types of use: usage frequency and value concentration. Frequency decides how often a delegation gets re-checked, and value concentration decides the loss ceiling of one mistake.
| Dimension |
Hot wallet |
Cold wallet |
Hardware wallet |
| Typical use |
Daily payments |
Long-term reserve |
Offline signing |
| Usage frequency |
Many times a day |
Monthly or less |
Connected per operation |
| Value concentration |
Low |
High |
High |
| Delegation suitable |
Yes |
Keep a plain EOA |
Depends on signing support |
| Main constraint |
Phishing amplification |
Semantic drift |
Small screen |
The dividing line is the holding horizon, not the form factor. Note the difference between a hardware wallet and a cold wallet: the terms are related, but not identical, because a hardware wallet can be used in hot or cold patterns. A hardware wallet can serve daily interaction or long-term storage; a device plugged into a laptop every day sits closer to the hot-wallet risk profile.
Hot wallets are typically more user-friendly, with browser or mobile wallets being the most common form, but less secure than cold setups, so the right split depends on your preferences and who will manage the keys.
Some cold-storage setups use air-gapped devices that never connect to the internet, which can secure assets well but make delegation workflows less practical; hardware wallets add an extra layer of protection when you store and manage assets while connected to a computer only for signing. Ask how often the assets move and what share of the portfolio they represent, then ask whether the device can sign an authorization tuple across different types of holdings.
Figure 1. Role split across hot, cold, and hardware wallets: usage frequency, value concentration, and authorization signing support decide whether delegation fits.
When Should You Enable It, and When Should You Not?
The criteria come in two groups, and whichever group an account matches more often points to the answer, with the choice also reflecting user preferences around security versus convenience, balancing the benefits of smoother use against the risk of compromise.
Enable when:
-
The account is interacting with crypto apps several times a week and batching clearly cuts signatures.
-
The balance stays within a loss the holder can absorb.
-
Gas sponsorship or session keys are needed, and self-sponsored use can be an advantage when the device signs authorization tuples as part of the process.
-
The delegate is on a trusted list and confirmed immutable and non-proxy.
Do not enable when:
-
The account is long-term storage touched a few times a year and holds the bulk of assets.
-
The signing device cannot display the full authorization list.
-
The goal is "several people must approve", which a multisig delegate does not deliver.
-
The delegate's upgrade status is unknown, or authorizations must be maintained on many chains, and clients should do research before interacting with unfamiliar delegates or apps and accept no more than one pending delegated transaction on a high-value account to limit invalidation risk if delegated code changes state.
When the two groups conflict, the holding horizon wins. An account with concentrated value and rare signing should route delegation to a separate hot address even if the device supports it.
The decision is reversible — a zero-address authorization returns the account to a plain EOA — but storage and past approvals stay behind, keeping the setup compatible with future account-abstraction integration without forcing ownership to move to a new address, while preserving the option to revoke.
Summary
Whether a cold wallet should enable delegation depends on the holding horizon, not the brand on the device, because the goal is to keep long-term crypto holdings secure and under the holder’s control while deciding whether delegation is worth the tradeoff.
An account used daily, funded lightly, and paired with a device that signs authorization tuples gets batching and sponsorship while the downside stays within a tolerable range; the choice sits at the wallet level rather than the device category, and a long-term storage account is better off as a plain EOA. What EIP-7702 brings to the table is a combination of ideas from ERC-4337, EIP-3074, and EIP-5003.
Two preconditions are not optional: the device must show the full authorization list, and the delegate must be immutable, non-proxy, and recomputable. Delegating to a multisig contract does not make an EOA a multisig.
FAQ
Does a hardware wallet support EIP-7702 delegation?
Not universally. Signing an authorization tuple requires firmware built to parse the type 0x04 structure and display chain_id, delegate address, and nonce; some devices sign only ordinary transactions and reject an authorization list. Support may also depend on firmware testing and whether the device can verify enough tuple data on its screen to determine what is being authorized. Ease of use matters, but not at the expense of showing enough on-device data to review the authorization safely.
Does an EIP-7702 delegation expire?
No. It does not expire automatically and stays in force until another authorization or revocation step changes it, so a cold wallet's delegation can sit unreviewed for a long time and can affect future wallet behavior until users overwrite or revoke it, which is why a cold wallet should avoid allowing long-lived delegation on high-value holdings unless the setup is reviewed regularly.
Can a delegated account still receive ETH normally?
Not by default. Once the account carries code, a plain transfer still sends ETH to the transfer destination, but it must enter the delegated execution path, and the account can still receive ETH only if the delegated code is set up to handle that transfer path correctly; otherwise, without receive() or fallback(), the transfer reverts, so exchange withdrawals and airdrops fail. In other words, the delegated account is interacting with that execution path rather than behaving like a plain EOA.
Does EIP-7702 turn my wallet into a smart contract wallet or a multisig?
No. Delegation changes only the code field, letting the account temporarily use smart-contract-wallet logic for a transaction, and signatures still come from the original key, so this does not make the account a multisig. The original private keys still retain full control of the account and can overwrite the delegation or send transactions without any multisig-style threshold.
Can a cold wallet return to a plain EOA after enabling delegation?
Yes. Sign a new authorization targeting the zero address and the node clears the code; in short, the reversal shortens the active delegation but does not remove stored state or prior approvals. Revocation returns only the delegated account behavior; it does not create new material that must be backed up, and it does not change how other cold-storage formats work. Additionally, revocation clears neither storage nor token approvals already granted, so keep this content informational only and do your own research before changing wallet settings.
