Skip to content
Hacker Posts

Trail of Bits: audit what your signing systems can approve

After the Binance incident, Trail of Bits argues teams must inventory what signing infrastructure can authorize — including standing EIP-7702 delegations — not just watch transfers.

Published 3 min read
researchtrail-of-bitsbinanceethereum

Trail of Bits published a post-Binance review of transaction-signing controls on November 6, written by Tarun Bansal, Jaime Iglesias and Anish Naik. The argument is narrow and useful: a server that can request a signature can abuse a protected key without ever extracting it, so the question that matters is not "where is the key" but "what can the thing that holds it approve." For anyone running custody or on-chain treasury infrastructure, it's worth forwarding to whoever owns your signer.

This is the research/analysis beat — the primary is the firm's own write-up, pegged to Binance's October security incident, not a vendor pitch.

The thesis

Monitoring transfers and ownership changes is not enough. A compromised machine with signing access can move funds, and — more dangerously — grant standing authority. Trail of Bits singles out EIP-7702 delegations, which can keep draining an account after the initial signed transaction, because the delegation itself is the persistence mechanism. If your detection watches balances rather than authority changes, you miss it.

What they recommend

The piece reads as a checklist, each item paired with a way to verify it:

  • Inventory signing access. List every service that can request a signature and what it can authorize. Separate signing infrastructure from everyday business systems, and verify transaction details through an independent path. The firm points to its TRAIL threat-modeling method for tracing how a compromised host reaches the signer.
  • Treat delegation as an admin privilege. Reject EIP-7702 authorizations for accounts that don't need them, including via generic digest-signing APIs. Where delegation is required, approve the account, delegate, chain and nonce separately, and simulate the delegation's effect on future authority — not just the immediate balance.
  • Cap the blast radius. Keep assets behind custody controls the operational key cannot change: independently enforced limits, monitored delays. Test by assuming the operational key is already compromised, then confirm transfers, delegate replacement and policy changes are all blocked.
  • Detect authority changes. Map each wallet to the assets and contracts it controls, even empty ones, and attribute direct calls, module execution and ERC-4337 operations back to their authorization paths — including edge cases like failed UserOperations inside successful bundles.

Limits

There's no tool or repo to clone here; it's a method and a set of checks, which means the work lands on your team to run. The recommendations assume an EVM, account-abstraction-aware stack — EIP-7702 and ERC-4337 are the load-bearing concepts — so operators on other chains will need to translate the principle (watch granted authority, not just movement) into their own primitives.

Context

The lesson generalizes past crypto: any system that brokers a privileged action on request — a signing oracle, a secrets broker, a CA — has to be evaluated on what it can approve, not just on whether its key leaked. Binance made the on-chain version expensive and public; Trail of Bits is using the moment to push teams from "protect the key" to "constrain the approval."

Related stories