ZeroDev retweeted
Quick notes on 7702 to dispel fud and keep your funds safe.
First thing first -- 7702 itself isn't broken. Don't panic if you are using a wallet that supports 7702 (MetaMask, Uniswap, Ambire, etc.).
To recap, 7702 is an account abstraction EIP that allows an EOA to sign a special message, called a "7702 authorization," that would insert a smart contract into the account, which enables the account to do powerful things like transaction batching, e.g. doing "approve" and "transfer" in one transaction so you can swap on Uniswap with one click.
But unfortunately the same feature also allows a hacker to efficiently move all your tokens in one single transaction. In the Binance hack, the hacker moved ETH, USDT, and 62 other tokens in one transaction, whereas without 7702 they'd have had to send one transaction per token. In this particular case, many of those transactions would've failed because Binance was still using the hacked wallet for withdrawals, so all transactions sent by the hacker would've had to compete with the legit transactions for nonces. So using 7702 did help the hacker steal as much funds as possible, as quickly as possible. Ouch!
However, in order for the hacker to use 7702, they must have either 1) had access to the private key, or 2) tricked Binance into signing a 7702 authorization. The latter is very unlikely, as it's hard to imagine Binance being so incompetent as to expose an endpoint for signing 7702 authorizations or (even worse) for signing raw messages which the hacker could've repurposed for 7702 authorizations. But I can't rule that out until the official postmortem.
What does all this mean for you?
- If you are a wallet developer, do NOT, under any circumstances, expose a way for third parties to request 7702 authorizations. This is just handing your users a giant footgun to shoot themselves with. No wallets I know of do this, so don't worry if you are a user.
- If you are a user, use a well-known wallet. 7702 does let wallet developers screw up in more ways than before, so use only well-known wallets whose developers' competence you can trust.
- If you are a company (e.g. an exchange) operating hot wallets, do NOT, under any circumstances, expose an endpoint (even if it's an internal endpoint) for signing 7702 authorizations or raw messages.
As a contributor to AA, I feel partially responsible for hacks like this, since by increasing the power of accounts, we've indeed also empowered hackers (not unlike how any new technology empowers both the good guys and the bad guys). That said, it's important to note that 7702 was only a transitional EIP, and "endgame AA" such as Frame Transactions (EIP-8141) would allow wallet owners to set up their wallets much more securely. For example, if Frame Transactions were available today, Binance could've:
- Set up their wallets as multisig contracts only (not EOAs).
- Set up "post conditions" for their `transfer()` functions, so that even if the multisig got hacked, the contract itself would perform sanity checks such as "no transfers of more than 1000 ETH without additional signers."
In short, the endgame of Ethereum UX is one with both optimal security and optimal UX, and users never have to trade off between the two. But we still have a long way to go until we get there. Back to work!
First thing first -- 7702 itself isn't broken. Don't panic if you are using a wallet that supports 7702 (MetaMask, Uniswap, Ambire, etc.).
To recap, 7702 is an account abstraction EIP that allows an EOA to sign a special message, called a "7702 authorization," that would insert a smart contract into the account, which enables the account to do powerful things like transaction batching, e.g. doing "approve" and "transfer" in one transaction so you can swap on Uniswap with one click.
But unfortunately the same feature also allows a hacker to efficiently move all your tokens in one single transaction. In the Binance hack, the hacker moved ETH, USDT, and 62 other tokens in one transaction, whereas without 7702 they'd have had to send one transaction per token. In this particular case, many of those transactions would've failed because Binance was still using the hacked wallet for withdrawals, so all transactions sent by the hacker would've had to compete with the legit transactions for nonces. So using 7702 did help the hacker steal as much funds as possible, as quickly as possible. Ouch!
However, in order for the hacker to use 7702, they must have either 1) had access to the private key, or 2) tricked Binance into signing a 7702 authorization. The latter is very unlikely, as it's hard to imagine Binance being so incompetent as to expose an endpoint for signing 7702 authorizations or (even worse) for signing raw messages which the hacker could've repurposed for 7702 authorizations. But I can't rule that out until the official postmortem.
What does all this mean for you?
- If you are a wallet developer, do NOT, under any circumstances, expose a way for third parties to request 7702 authorizations. This is just handing your users a giant footgun to shoot themselves with. No wallets I know of do this, so don't worry if you are a user.
- If you are a user, use a well-known wallet. 7702 does let wallet developers screw up in more ways than before, so use only well-known wallets whose developers' competence you can trust.
- If you are a company (e.g. an exchange) operating hot wallets, do NOT, under any circumstances, expose an endpoint (even if it's an internal endpoint) for signing 7702 authorizations or raw messages.
As a contributor to AA, I feel partially responsible for hacks like this, since by increasing the power of accounts, we've indeed also empowered hackers (not unlike how any new technology empowers both the good guys and the bad guys). That said, it's important to note that 7702 was only a transitional EIP, and "endgame AA" such as Frame Transactions (EIP-8141) would allow wallet owners to set up their wallets much more securely. For example, if Frame Transactions were available today, Binance could've:
- Set up their wallets as multisig contracts only (not EOAs).
- Set up "post conditions" for their `transfer()` functions, so that even if the multisig got hacked, the contract itself would perform sanity checks such as "no transfers of more than 1000 ETH without additional signers."
In short, the endgame of Ethereum UX is one with both optimal security and optimal UX, and users never have to trade off between the two. But we still have a long way to go until we get there. Back to work!
24
80
329
45,054
Lots of people are blaming EIP-7702 for recent hacks.
7702 isn't the cause of the attacks. Attacks are caused by compromised apps, leaked keys, or a bad signature request. Every 7702 delegation needs the owner’s signature.
Always protect your keys and always watch what you sign.
7702 isn't the cause of the attacks. Attacks are caused by compromised apps, leaked keys, or a bad signature request. Every 7702 delegation needs the owner’s signature.
Always protect your keys and always watch what you sign.
3
12
65
4,775
ICYMI: ZeroDev Earn is now live across Ethereum, Arbitrum, Base, Robinhood Chain, Hyperliquid and more
DeFi teams can give users a simple way to discover and access yield opportunities across chains
All in one flow, from vault selection to deposit tracking
Try out the demo should check it out:
earn-demo.zerodev.app
DeFi teams can give users a simple way to discover and access yield opportunities across chains
All in one flow, from vault selection to deposit tracking
Try out the demo should check it out:
earn-demo.zerodev.app
2
2
11
1,053
@shaddoteth Ethereum, Arbitrum, Base, Hyperliquid, BNB and more :)
Find all the chains supported here:
docs.zerodev.app/onramp/smart-r…
Find all the chains supported here:
docs.zerodev.app/onramp/smart-r…
1
0
0
16
At launch: selected Aave and Morpho opportunities.
Try the demo, then read the quickstart.
earn-demo.zerodev.app
Try the demo, then read the quickstart.
earn-demo.zerodev.app
0
0
3
82
ZeroDev Earn is here.
Cross-chain yield across supported assets, routes, and opportunities through one integration.
No new ZeroDev Earn transaction-level fee at launch; existing API and SRA pricing still apply.
zerodev.app/earn
Cross-chain yield across supported assets, routes, and opportunities through one integration.
No new ZeroDev Earn transaction-level fee at launch; existing API and SRA pricing still apply.
zerodev.app/earn
6
5
41
3,097
Building an app that needs to accept cross-chain deposits?
Get in touch with our team to see how Smart Routing Address can simplify your funding flows
zerodev.app/book-a-demo
Get in touch with our team to see how Smart Routing Address can simplify your funding flows
zerodev.app/book-a-demo
0
0
0
78
ZeroDev gives you more control over your product with composable solutions to cover the entire dev stack.
@xLiquida adopted ZeroDev and instantly gained more control over their app with fewer boundaries.
Start building more with less today: zerodev.app
@xLiquida adopted ZeroDev and instantly gained more control over their app with fewer boundaries.
Start building more with less today: zerodev.app
IRL's is where we learn the most, without going to events and competitions we would never learn about amazing new ways to do things in this space, being in a community of people can get you far, really far! Thank you @ZeroDev for the support as always! x.com/i/article/2110…
1
0
2
266








