I’ve been watching the crypto security conversations closely for years, and every so often something lands that makes the whole industry sit up straighter. This week it was Charles Hoskinson pointing at what he called seriously dangerous code. He shared a detailed technical breakdown that ties Ethereum’s newer EIP-7702 delegation feature to the rapid emptying of a Binance hot wallet. The claims are technical, specific, and frankly unsettling if you hold assets on any large exchange.
What Sparked The Latest EIP-7702 Security Discussion
The conversation started with a straightforward post. Hoskinson simply warned that dangerous code exists out there and pointed people toward a reconstruction of bytecode allegedly used against Binance. He did not spell out every detail himself. Instead he let the analysis speak, which in my view is often more effective than a long thread of personal commentary.
According to the breakdown that circulated, the sweeper contract appeared purpose-built for the exchange’s wallet setup. It left behind a very precise amount of native ETH. That single detail alone has security people talking. The idea is that leaving just enough gas prevented certain automated systems from throwing the kind of alerts that would normally stop further withdrawals.
I’ve found that the most interesting security stories are rarely about one flashy exploit. They are usually about how several small design choices line up in the wrong order. This case seems to fit that pattern perfectly.
How The Alleged Sweeper Handled Native Balances
The reconstructed contract reportedly drained the native ETH balance of the targeted wallet but intentionally left one full ETH behind. On the surface that sounds almost polite. In reality the argument is that this leftover amount kept the hot-wallet processing queue from failing due to insufficient gas. No failure meant fewer internal alarms.
Think about how most large exchanges operate. Hot wallets are designed for speed. They process continuous streams of outgoing transactions. If a wallet suddenly cannot pay for gas, systems often flag the problem and pause activity. By leaving just enough ETH, the attacker may have bought extra time before anyone noticed the much larger asset movements happening in parallel.
That kind of attention to operational detail is what makes the analysis feel more than theoretical. It suggests the people who wrote the code understood more than just the protocol rules. They understood how the exchange’s internal monitoring likely behaved under normal conditions.
Token Processing That Refused To Stop
The same analysis described a loop that checked token balances through low-level calls. When an individual transfer failed, the loop simply continued. Blacklisted tokens or unresponsive contracts did not halt the entire process. The sweeper kept moving through whatever assets it could reach.
In practical terms this means the attacker did not need every single asset to succeed. Partial success was still highly profitable. That design choice reduces the risk that one problematic token would spoil the whole operation.
I keep coming back to how ordinary this approach feels once you see it written out. Good attackers plan for friction. They assume some transfers will fail and build around that assumption rather than hoping for perfect conditions.
The Vault Access Claim
One of the more striking parts of the breakdown involved an external vault holding a very large USDC balance. The claim is that the vault treated the compromised Binance wallet as a controller. Once the wallet was under the attacker’s influence through delegation, calls originating from that wallet could reach funds that were not sitting in the hot wallet itself.
If accurate, this moves the incident beyond a simple hot-wallet drain. It suggests the attacker could influence treasury systems that normally sit further away from daily operational wallets. That kind of reach is what elevates a theft from inconvenient to existential for the affected exchange.
Of course the analysis is still one technical reconstruction. Independent verification will matter. Yet the specificity of the claims has already forced the wider community to look harder at how delegation interacts with existing exchange infrastructure.
Understanding EIP-7702 Delegation In Plain Terms
EIP-7702 introduces a new transaction type that lets an ordinary externally owned account temporarily behave like a smart contract. The account signs an authorization that points to code living at another address. Once that authorization is processed, the account can execute the delegated logic as if the code belonged to it.
This is powerful for user experience. Batching multiple actions into one transaction becomes straightforward. Sponsored transactions where someone else pays the gas become easier to implement. Account abstraction features that many users have wanted for years suddenly sit closer to the protocol layer.
The trade-off is control. The specification itself is clear on this point. Delegated code receives unrestricted access to the account. Wallet developers and users are expected to treat that code with extreme caution.
Authorized code has unrestricted access to the account and must be closely audited by the wallet.
That warning is not buried in fine print. It sits in the security considerations section for a reason. Once delegation is active, the account is effectively running someone else’s code with full privileges until the delegation is cleared.
Why Signed Authorizations Matter
Delegation cannot be forced onto an account without a valid signature. Each authorization includes a chain identifier, the target delegate address, a nonce, and a cryptographic signature. The protocol recovers the authorizing address from that signature and checks the nonce before accepting the change.
In the alleged Binance case the analysis acknowledges this requirement. The attacker needed either the private key itself or unrestricted signing access inside the exchange’s security setup. EIP-7702 did not create a way to take over a random wallet. It provided a highly efficient way to act once control of signing was already obtained.
This distinction is important. Protocol design and operational security are two different layers. A feature can be correctly specified and still become dangerous when combined with weak key management or overly broad signing permissions.
The Fifty Authorization Batch Theory
One of the more technical claims involves fifty pre-signed authorizations covering consecutive nonces. The idea is that the hot wallet’s nonce was changing while normal operations continued. By preparing a long sequence of valid authorizations, the attacker could wait for the exact moment when the current nonce matched one of the signed values.
Ethereum processes authorizations in order. If one fails a check, the next one is still evaluated. A successful authorization updates the delegation and increments the nonce. Multiple consecutive authorizations can therefore succeed depending on the starting nonce and the signatures supplied.
This is more flexible than a single-shot authorization. It gives the attacker a window rather than a single precise moment. In high-volume environments where nonces move quickly, that flexibility can matter a great deal.
Whether this exact technique was used remains a claim from the reconstruction. The protocol rules themselves do allow the pattern. That alone is enough to make security teams re-examine how they handle batched authorizations and nonce tracking.
Speed As A Weapon
Delegation compresses what might otherwise require multiple separate transactions into a single operation. Once the account is delegated, complex sequences of transfers can execute rapidly. The analysis suggests this reduced the time available for any intervention that might have limited the damage.
In traditional hot-wallet theft scenarios, defenders sometimes have a short window after the first few anomalous transfers. If the attacker needs many sequential transactions, that window can still exist. When everything happens inside one delegated execution, the window shrinks dramatically.
I am not claiming every exchange would have stopped the theft after three transactions. That counterfactual belongs to the original analysis. What feels true is that speed changes the defensive equation. Features that accelerate legitimate use also accelerate abuse when credentials are compromised.
Persistent Delegation And Cleanup Risks
Delegation does not automatically disappear when the installing transaction finishes. It stays in place until explicitly cleared. An authorization pointing to the zero address is the standard way to remove it. Execution failures also do not roll back delegation indicators that have already been processed.
These details matter for incident response. If a compromised account still carries an active delegation after the main theft, further damage remains possible until someone issues a clear authorization. Teams that do not monitor for unexpected code pointers on high-value accounts are leaving an open door.
Perhaps the most interesting aspect is how little attention this persistence has received in everyday discussions of account abstraction. Most conversations focus on the convenience. The cleanup requirements only become obvious after something goes wrong.
What Exchange Security Teams Should Re-Examine
Large custodians operate under constant pressure to keep funds liquid and available for withdrawals. That pressure often leads to hot wallets with significant balances and relatively broad operational permissions. EIP-7702 does not invent that tension. It simply amplifies the consequences when those permissions are abused.
- Review every process that can produce signed authorizations for high-value accounts
- Monitor for unexpected code pointers appearing on operational wallets
- Test how internal alert systems behave when a wallet balance drops to a carefully chosen residual amount
- Evaluate whether consecutive nonce authorizations can be restricted or rate-limited
- Ensure that clearing a compromised delegation is both fast and practiced
None of these steps are glamorous. They are the unsexy work of operational security. Yet they are exactly the kind of measures that turn a theoretical protocol risk into a manageable one.
The Broader Account Abstraction Trade-Off
Ethereum has been moving toward more flexible account models for a long time. Users want better recovery options, better batching, and the ability to pay fees in tokens other than ETH. EIP-7702 is one more step along that path. It is not the first feature that increases power while increasing responsibility, and it will not be the last.
The honest conversation is not about whether the feature should exist. It is about whether the surrounding tooling, education, and exchange practices have kept pace with the new capabilities. Right now the answer appears mixed.
Wallet software needs clearer warnings when a user is about to sign an authorization that grants unrestricted access. Hardware devices need interfaces that make the nature of the signature obvious. Exchanges need internal controls that treat delegation events as high-priority security signals rather than ordinary transaction traffic.
Why Hoskinson’s Warning Carries Weight
Charles Hoskinson has spent years building and criticizing blockchain systems. When he flags something as seriously dangerous, the market tends to listen even if people disagree with his conclusions. In this case the warning was brief and the supporting analysis was detailed. That combination tends to travel far.
The post did not claim a fundamental protocol flaw that lets anyone drain any wallet. It pointed at dangerous code that appears tailored to a specific operational environment and that leverages a new protocol capability. Those two facts together create a credible risk narrative without requiring conspiracy theories.
I’ve noticed that the healthiest security discussions happen when people separate the protocol rules from the operational reality. The rules can be sound while the reality remains messy. EIP-7702 currently sits in that uncomfortable middle ground.
Practical Steps For Everyday Users
Most individual holders will never interact directly with EIP-7702 authorizations. Still, a few habits remain useful.
- Prefer self-custody for long-term holdings whenever practical
- Treat any request to sign unfamiliar transaction types with extreme caution
- Keep the majority of funds in cold storage that cannot be delegated without physical access
- Monitor official communication channels of any exchange that holds meaningful balances
- Understand that speed features cut both ways once credentials are compromised
None of this is new advice. The appearance of more powerful account features simply makes the old advice more relevant rather than less.
Looking Ahead At Protocol Evolution
Ethereum’s design culture has always accepted that new capabilities introduce new attack surfaces. The process then becomes one of observation, feedback, and incremental hardening. EIP-7702 is still early in that cycle. The current discussion is part of the feedback loop.
Future client releases or companion EIPs may add more guardrails around consecutive authorizations or persistent delegation. Wallet standards may evolve to surface delegation state more clearly. Exchange security practices will almost certainly tighten around any new transaction type that can move large balances in a single step.
In the meantime the industry has a live case study. Whether every claim in the circulating analysis holds up under further scrutiny, the core lesson already stands. Powerful account features demand equally powerful operational discipline. Leaving one without the other is how dangerous code finds its opportunity.
The conversation Hoskinson amplified is not primarily about blaming a specific protocol change. It is about recognizing that the combination of broad signing access and efficient delegation creates a high-speed path for theft once the first barrier is breached. Closing that path requires work on both the protocol tooling side and the exchange infrastructure side.
Security in crypto has always been a shared responsibility. Protocol designers, wallet developers, exchange operators, and individual users each hold part of the risk. When a new feature shifts the balance of power, every layer needs to adjust. The current debate around EIP-7702 and the alleged Binance sweeper is simply the latest reminder that those adjustments cannot lag too far behind the new capabilities.
I expect more technical write-ups and more formal responses in the coming days. Some claims will be confirmed, others refined or discarded. What will remain is the underlying tension between convenience and control. That tension is not going away. The only question is how carefully the ecosystem manages it as account abstraction continues to mature.
For now the practical takeaway is straightforward. Treat any new form of account delegation as high risk until proven otherwise. Audit the code that can receive that power. Limit the conditions under which high-value accounts can sign authorizations. Monitor the resulting state changes with the same seriousness given to traditional private-key compromises. Those habits will matter more as features like EIP-7702 move from experimental to mainstream.
The code that Hoskinson flagged may or may not represent the exact mechanism used in any particular incident. Its existence as a public reconstruction is already valuable. It forces the conversation out of abstract risk models and into concrete bytecode patterns. That shift from theory to practice is usually when real improvements begin.
Crypto security improves most when people share detailed technical observations rather than vague warnings. The current discussion, whatever its final conclusions, is already doing that work. Paying attention to the details is the least any of us can do while the full picture continues to emerge.
