{"assessments":[],"deployments":[],"fuzz":[],"identity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"interpretation":"Records acceptance and evidence. Neither completion nor an AI assessment establishes correctness, safety, or independent review.","jobId":"fd546fc0-111c-4c51-883c-ee5126b1e52c","kind":"research","nodes":[{"acceptedSubmissionHash":null,"dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"tools":[]},"key":"panel","kind":"research","role":"review","skillHash":null,"skillId":null,"state":"accepted"}],"objective":"D.S.I - Decentralized Swarm Investigation, the signing-path question behind the Binance 14 drain of 2026-10-29: on Ethereum mainnet the hot wallet 0x28C6c06298d514Db089934071355E5743bf21d60 got an EIP-7702 delegation through 50 authorizations signed with its own key for 50 consecutive nonces (18914775 to 18914824), included at 20:20:59 UTC in transaction 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b. An EIP-7702 authorization is not a transaction: the key signs keccak256(0x05 || rlp([chain_id, address, nonce])). Which custody, MPC, HSM and wallet-infrastructure providers used by exchanges and institutions document how their signing policies treat EIP-7702 authorizations (refused, allowed, allowed only with approval, or not mentioned), and which public incidents since 2025-05-07 drained an exchange, custodian, treasury or other institutional wallet through an EIP-7702 delegation? From those sources, what must a signing policy inspect to recognise and refuse an unwanted EIP-7702 authorization?","parentJobId":null,"planHash":"5f999b94d198a96f9751f29af6d980248b60af6d6845aa9d5c1eebcd7676eb41","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"fd546fc0-111c-4c51-883c-ee5126b1e52c","publication":{"commit":null,"deliveredAt":null,"repoUrl":null},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[{"answer":"**Short answer:** I found no provider whose public documentation says it refuses EIP-7702 authorizations as a class. The only concrete, checkable policy control is Turnkey's allow-list example. I also found no verified public incident, other than the Binance 14 event itself, in which an exchange or custodian was drained through a 7702 delegation. Several things are still unknown, including how the Binance signature was obtained. All Binance details below come from a single trade-press article and are unconfirmed.\n\n## 1. Provider documentation on EIP-7702 authorizations\n\n| Provider | Mentions 7702? | Documented policy | Source (date) |\n|---|---|---|---|\n| Turnkey (signing infrastructure, policy engine) | Yes | **Allowed only if a policy matches.** Its docs have an `EFFECT_ALLOW` example, \"Allow signing of EIP-7702 Authorizations\", which matches the encoding, the delegate `address` in a list, and the `chain_id`. A second example also pins the `nonce`. Turnkey's docs do not say what happens without such a rule. | [Turnkey Ethereum policy examples](https://docs.turnkey.com/concepts/policies/examples/ethereum.md) (undated) |\n| Fireblocks (MPC custody) | Yes, as general guidance | **Not a product policy.** The March 2025 post says \"A security oriented approach would limit the delegations that can be performed.\" The May 2025 post says \"Any combination of on-chain and off-chain policies is available to an organization utilizing 7702 enabled MPC wallets.\" Neither says authorizations are refused or approval-gated. | [Security First Approach to EIP-7702](https://www.fireblocks.com/blog/security-first-approach-to-eip-7702) (2025-03-12); [Mutualism, MPC, and EIP-7702](https://www.fireblocks.com/blog/eip-7702-mpc-wallets-smart-account-abstraction) (2025-05-07) |\n| Safeheron (MPC custody) | Yes | **Recommended, not a documented product behaviour: allowed with approval.** It advises using \"an off-chain policy engine to block unapproved delegations\" and to \"require multi-party approval for any delegation change\". | [What Is EIP-7702?](https://safeheron.com/blog/what-is-eip-7702/) (2026-10-21) |\n| Privy (wallet infrastructure) | Yes | **Allowed.** It provides signing methods through its SDKs and REST API. The fetched page mentions no policy, no `chain_id` 0 handling and no security warning. | [Privy sign-7702-authorization](https://docs.privy.io/wallets/using-wallets/ethereum/sign-7702-authorization.md) (undated) |\n| Para, Magic, Portal | Yes (search listing only) | **Allowed.** Each has a sign-authorization or 7702 endpoint. I did not open these pages, so I have no policy detail. | Search results only |\n| BitGo, Anchorage, Copper, Dfns, Cobo, Utila, Coinbase Custody, HSM vendors | Not found | **Not mentioned** in anything I retrieved. | Searches returned no first-party 7702 documentation. This is not proof that none exists. |\n\nWintermute's finding that most delegations point to the same sweeper code concerns attacks on individual wallets rather than providers' signing policies. Cointelegraph reports Wintermute said \"over 97% of all EIP-7702 delegations were authorized to multiple contracts using the same exact code\" ([Cointelegraph](https://cointelegraph.com/news/wintermute-crimeenjoyor-flags-malicious-ethereum-contracts), 2025-06-02).\n\n## 2. Public incidents since 2025-05-07\n\n- **Binance 14 hot wallet, 2026-10-29, Ethereum.**\n  - Wallet: `0x28C6c06298d514Db089934071355E5743bf21d60`.\n  - Delegate: the article gives it only as truncated, `0x63e842B0…`, or `0x63e8…6fAe` in the timeline. I could not verify the full address.\n  - Loss: about $2.8B on Ethereum, including 167,464 ETH and 1.615B USDT. Other-chain outflows of up to $3.55B are described as unconfirmed.\n  - The delegation transaction is the one in your question (20:20:59 UTC). The sweep transaction is `0x53bd38b8…e2f3` at 20:24:23 UTC.\n  - Source: [CryptoTicker](https://cryptoticker.io/en/binance-hack-hot-wallet-drained/). The article says \"None of the three scenarios is proven, and Binance has not commented on this yet.\" The three scenarios are a stolen key, a manipulated signing system, or an insider.\n  - Other outlets reported the loss as high as $5.8B. These figures conflict and I did not verify them.\n- **IPOR USDC Optimizer vault, 2026-01-06, Arbitrum.** This is a protocol administrator account, not an exchange or custodian, so it is borderline.\n  - The vault's administrator EOA had delegated via 7702 to a contract with an arbitrary-call function, which the attacker used to add a malicious fuse.\n  - Vault: `0xa91267a25939b2b0f046013fbf9597008f7f014b`.\n  - Attacker: `0x9b1bd925a752cca6a28a27ec1058cf06b6434cee`.\n  - The administrator and delegate addresses are truncated in the source.\n  - Loss: about $336K, fully restored.\n  - Source: [IPOR post-mortem](https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62), dated 2026-01-07.\n- **DxSale lockers, 2026-05-27, BNB Chain.** This is also borderline, because it was an owner-key takeover and 7702 delegators were used for scale.\n  - Attacker: `0xC4574DDEF299e7E563971e200433e592EeaaFA69`.\n  - Primary locker: `0xEb3a9C56d963b971d320f889bE2fb8B59853e449`.\n  - The attacker's delegate addresses are not listed.\n  - Loss: $7.3M drained, with more reported at risk.\n  - Source: [Rekt](https://alpha.rekt.news/dxsale-rekt).\n- **Not verified:** Search results also mentioned a WLFI-related drain and a QNT pool drain. I could not open the WLFI source (HTTP 403) and the QNT claim came from a single social post, so I do not rely on either.\n\nI found no other verified case of an exchange or custodian drained through 7702.\n\n## 3. What a signing policy must inspect\n\n- **Message type and prefix.** The signed digest is `keccak(MAGIC || rlp([chain_id, address, nonce]))`, where `MAGIC` is `0x05` ([EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)). It is not a transaction. A policy that only parses transaction fields will see an opaque 32-byte hash. The signer must either receive and decode the preimage or refuse raw-hash signing. Turnkey's example keys on the encoding `PAYLOAD_ENCODING_EIP7702_AUTHORIZATION`, which is the kind of check needed.\n- **`chain_id`.** The spec accepts 0 or the current chain's ID, and says \"When universal deployment is preferred, simply set chain ID to 0.\" A chain_id of 0 is therefore valid on every chain. A policy should reject 0, or pin an exact chain ID as Turnkey's `chain_id ==` condition does.\n- **Delegate `address`.** This is the code that will control the account. Turnkey's example allow-lists it. Fireblocks says delegations should go only to audited, trusted contracts. The default should be deny unless the address is on a pre-approved list.\n- **`nonce`.** The authority's nonce must equal the tuple's nonce. The spec says \"Verify the nonce of `authority` is equal to `nonce`.\" Turnkey can pin a single nonce. Your incident used 50 consecutive nonces, so a policy should allow at most one authorization per approval, with the nonce tied to the account's current nonce. It should also alert on any run of authorizations. No source I read documents a rate limit.\n- **Approval and signer scope.** The EIP says wallets should not offer an interface for applications to request authorizations: \"There is no safe way to provide this interface.\" Safeheron recommends multi-party approval for any delegation change.\n\n**Unknown:**\n- How the Binance signature was produced.\n- Whether Binance's signing stack could sign a 7702 authorization at all.\n- Any first-party policy statement from BitGo, Anchorage, Copper, Dfns, Cobo or any HSM vendor.\n- The full Binance delegate address.\n- Whether the two borderline incidents involved signing-path failures.\n\n---\nSources offered but not confirmed by this machine:\n- https://eips.ethereum.org/EIPS/eip-7702 — does not contain the quoted text\n- https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page\n- https://www.fireblocks.com/blog/eip-7702-mpc-wallets-smart-account-abstraction — did not return a page\n- https://cryptoticker.io/en/binance-hack-hot-wallet-drained/ — did not return a page\n- https://cointelegraph.com/news/wintermute-crimeenjoyor-flags-malicious-ethereum-contracts — did not return a page","citations":[{"contentHash":"969327b24d7d10fec0e056dc943290d26bd86574a4ac1f999737e96a2059496d","quote":"msg = keccak(MAGIC || rlp([chain_id, address, nonce]))","retrievedAt":"2026-10-30T01:14:55.851Z","url":"https://eips.ethereum.org/EIPS/eip-7702"},{"contentHash":"969327b24d7d10fec0e056dc943290d26bd86574a4ac1f999737e96a2059496d","quote":"When universal deployment is preferred, simply set chain ID to 0.","retrievedAt":"2026-10-30T01:14:55.869Z","url":"https://eips.ethereum.org/EIPS/eip-7702"},{"contentHash":"e5b8471e954da187bb8f3138abdba204b3d4573fad1695527ec5e4a0cbd08f77","quote":"eth.eip_7702_authorization.chain_id ==","retrievedAt":"2026-10-30T01:14:56.136Z","url":"https://docs.turnkey.com/concepts/policies/examples/ethereum.md"},{"contentHash":"e5b8471e954da187bb8f3138abdba204b3d4573fad1695527ec5e4a0cbd08f77","quote":"Allow signing of EIP-7702 Authorizations","retrievedAt":"2026-10-30T01:14:56.288Z","url":"https://docs.turnkey.com/concepts/policies/examples/ethereum.md"},{"contentHash":"4c8bc2ffe9ddbbe15d389fce97afec6afc35c068849478d635d91549a292759d","quote":"use an off-chain policy engine to block unapproved delegations","retrievedAt":"2026-10-30T01:14:56.747Z","url":"https://safeheron.com/blog/what-is-eip-7702/"},{"contentHash":"4c8bc2ffe9ddbbe15d389fce97afec6afc35c068849478d635d91549a292759d","quote":"require multi-party approval for any delegation change","retrievedAt":"2026-10-30T01:14:56.755Z","url":"https://safeheron.com/blog/what-is-eip-7702/"},{"contentHash":"4c23240c83f42395002d4955a69a32f2dd012117ca9ac260683a404788891628","quote":"used the EIP-7702 mechanism to delegate its execution to an implementation contract","retrievedAt":"2026-10-30T01:14:57.027Z","url":"https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62"},{"contentHash":"b32aa9548a8725871f4c24b5977f62eefd62acd15d1072be647ff0439e5d1dbe","quote":"the batch delegation mechanism introduced in the Pectra upgrade","retrievedAt":"2026-10-30T01:14:57.314Z","url":"https://alpha.rekt.news/dxsale-rekt"}],"device":"37eed9f56188ea8b","id":"26b84a7f-153c-4f0a-9081-2f48fbd6e871","model":"claude-sonnet-5-5","nodeId":"1be26c53-c7fa-4fb0-ae23-d90e51cff3d2","runtime":"claude"},{"answer":"**The critical control is authorization-aware signing, including every raw-signing route.** Blocking type-4 transactions alone does not prevent a wallet’s key from signing an authorization that someone else submits. Turnkey explicitly documents this distinction and the bypass risk from opaque payloads. [Turnkey policy language](https://docs.turnkey.com/features/policies/language)\n\nThe sources below do **not** establish which custody provider Binance used, how the signatures were obtained, or whether an MPC/HSM boundary was breached. Blockaid reports the delegation and outflows; contemporary reporting still describes Binance’s investigation as ongoing. Those are different evidentiary claims. [Blockaid, October 29, 2026](https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history), [The Defiant](https://thedefiant.io/news/security/binance-labeled-wallet-swept-minutes-after-eip-7702-delegation)\n\nThis is a bounded public-documentation review as of **2026-10-30**. “Allowed” means the documented workflow can produce an authorization—not that arbitrary delegations are permitted. “Not mentioned” applies to the cited documentation, not necessarily every product or private deployment. **n.d.** means no publication/update date was visible; those pages were accessed on 2026-10-30.\n\n| Provider / product | Explicitly mentions EIP-7702 authorizations? | Documented treatment and limits | Source and date |\n|---|---|---|---|\n| **Turnkey** | Yes | **Allowed under configurable policy; refusal supported.** Exposes authorization `address`, `chain_id`, and `nonce`; documents allowlisting and raw-payload bypasses. Batch-signing and alternate encodings need separate restrictions. No universal human-approval requirement stated. | [Policy language](https://docs.turnkey.com/features/policies/language), n.d. |\n| **Privy** | Yes | **Allowed under configurable policy; refused when no applicable allow rule exists on a policy-controlled wallet.** Dedicated `eth_sign7702Authorization` method and `ethereum_7702_authorization` field source; example restricts the delegation contract. This is not a claim that every wallet has such a policy attached. | [Policy semantics](https://docs.privy.io/controls/policies/overview), [delegation restriction example](https://docs.privy.io/controls/policies/example-policies/ethereum), n.d. |\n| **Ripple Custody — Vault** | Yes | **Allowed with approval.** Separate `SetDelegation` and `SubmitAuthorization` orders pass through the standard intent-approval flow; policies can distinguish those operations. Delegation is not automatic. Customers choose the contract; audit guidance is not an enforced vendor allowlist. | [Delegation API guide](https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api), n.d.; [v1.43 release](https://docs.ripple.com/products/custody/support/change-history/v143), **2026-10-05** |\n| **Fordefi** | Yes, through its activation workflow | **Allowed with user confirmation in the documented UI.** Activation requires signing in the mobile app and uses `Simple7702Account`. Whether every API/raw-signing route enforces the same delegate restriction or human approval is **unknown** from this guide. | [EVM Vaults](https://docs.fordefi.com/user-guide/vaults/evm-vaults), n.d.; [release notes, version 100](https://docs.fordefi.com/changelog/platform), **2026-01-11** |\n| **Dfns** | Yes | **Allowed.** Documents `Eip7702` authorization signing. General signing policies can **block or request approval** when required fields cannot be extracted; raw serialized payloads are not introspected. An authorization-specific delegate/chain/nonce policy schema is **not shown** in the cited policy guide. | [EVM signing reference—deprecated](https://docs-legacy.dfns.co/d/api-docs/keys/generate-signature/evm), n.d.; [gas sponsorship](https://dfns.co/article/fee-sponsor-on-evm), **2025-06-04**; [signing policies](https://docs.dfns.co/guides/signing-policies), updated **2026-10-23** |\n| **Fireblocks** | Yes | **Allowed in its Universal Gasless implementation.** Separately, production raw signing is disabled by default and raw requests require enabling the feature plus policy rules. Its security article recommends limiting delegations to trusted, audited contracts, but does not establish a comprehensive authorization parser or blanket refusal across all signing routes. | [Security guidance](https://www.fireblocks.com/blog/security-first-approach-to-eip-7702), **2025-03-12**; [gasless launch](https://www.fireblocks.com/blog/universal-gasless-evm-transactions-launch), **2025-05-23**; [raw-signing controls](https://fireblocks.readme.io/docs/raw-signing), n.d. |\n| **Utila** | Yes | **Allowed in sponsored transfers.** Source wallet signs a delegation message to Utila’s audited contract; sponsor submits it with the transfer intent. A standalone rule governing arbitrary authorization signatures, chain-zero requests, or nonce ranges is **unknown** from these pages. | [Sponsored-transfer explanation](https://support.utila.io/en/articles/11727423-sponsored-transfer), [API guide](https://docs.utila.io/reference/sponsored-transfer), n.d. |\n| **Alchemy Wallet APIs** | Yes | **Allowed; 7702 mode enabled by default.** API prepares authorization payloads; application prompts for signing. Documents supported Modular Account delegates and a non-7702 alternative. An external signer’s custody approval policy is outside this documented workflow. | [How EIP-7702 works](https://www.alchemy.com/docs/wallets/transactions/using-eip-7702), n.d. |\n| **Blockdaemon DeFi API** | Yes | **Allowed as an integration workflow; signer policy not mentioned.** API supplies a batcher address; the customer’s EOA signs. Supports default or customer-supplied batcher contracts. This does not establish CubeSigner/custody-level authorization enforcement. | [EIP-7702 batching](https://docs.blockdaemon.com/docs/eip-7702-transaction-batching), n.d. |\n| **BitGo** | Not in the cited policy overview | **Not mentioned.** Documents destination, initiator, amount, velocity and webhook policies, but no authorization-specific treatment here. Refusal, approval requirements and parsing coverage remain **unknown**. | [Policies overview](https://developers.bitgo.com/docs/policies-overview), n.d. |\n| **AWS KMS** — signing building block | Not in the cited signing API | **Not mentioned.** `Sign` accepts messages or digests subject to key permissions. No EIP-7702 semantic inspection is documented. A customer’s application policy cannot be inferred from this primitive. | [KMS Sign API](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html), n.d. |\n| **Microsoft Azure Key Vault** — signing building block | Not in the cited signing API | **Not mentioned.** Signs a supplied digest with `keys/sign` permission. No authorization-specific recognition/refusal is documented. | [Sign API](https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01), API version **2025-07-01**; publication date unknown |\n\n**No blanket “refuses every EIP-7702 authorization” conclusion is supported for these providers.** There are documented configurable refusals, approval workflows, supported delegation workflows, and documentation gaps. In particular, Fireblocks’ default raw-signing restriction must not be misreported as a universal 7702 ban, given its documented gasless implementation. [Fireblocks raw signing](https://fireblocks.readme.io/docs/raw-signing), [Universal Gasless](https://www.fireblocks.com/blog/universal-gasless-evm-transactions-launch)\n\nThe institutional incidents I could substantiate or identify as explicitly reported are below. The distinction between a **victim’s unwanted delegation** and a **vulnerability in previously delegated administrator code** matters.\n\n| Date / chain | Institutional wallet or account | Delegate address | Reported loss and evidence status |\n|---|---|---|---|\n| **2026-01-06 — Arbitrum One** | **IPOR legacy USDC Optimizer vault:** `0xa91267a25939b2b0f046013fbf9597008f7f014b`. Delegated administrator: `0xd8a1087d6bbCd5533F819A4496a06AF452609b99`. | `0xA3CCb120cD4CE39507eDB684d4Ed17aA7194F83c` | **About $336,000.** Project post-mortem attributes it to an arbitrary-call vulnerability in the administrator’s delegate combined with missing vault fuse validation. **Not established as fraudulent authorization signing.** Vault ultimately received 336,580 USDC; DAO covered the bounty and conversion difference. [IPOR post-mortem, Jan 7](https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html); [Arbiscan transaction identifying administrator and delegate](https://arbiscan.io/tx/0x238b4e619158432ff5ceb279cfea38007d048af4f59901c7af2efcf32e9671b6). |\n| **2026-10-09 — Ethereum**; initial reporting Oct 10 | **Reported institutional entity:** `0x4943b0c9959dcf58871a799dfb71bece0d97c9f4`. | **Unknown from the sources verified here.** Do not substitute recipient/operator `0x24a9…` for the delegate. | **Approximately $3.5–3.55 million**, claimed from legacy bridges and transferred away. Later linked by ZachXBT to the institutional-wallet theft below. Initial BlockSec reporting explicitly could not establish owner intent or how signing authority was obtained. [The Defiant](https://thedefiant.io/news/security/3-55-million-in-unclaimed-bridge-funds-moved-via-eip-7702); [ChainCatcher, Oct 10](https://h.chaincatcher.com/en/article/2295365); [ZachXBT’s addresses and linkage](https://t.me/s/investigations/363). |\n| **2026-10-21 — Ethereum, reported** | Same reported entity; wallets `0x4943b0c9959dcf58871a799dfb71bece0d97c9f4` and `0x10bf1dcb5ab7860bab1c3320163c6dddf8dcc0e4`. | **Unknown from the sources verified here.** | **Approximately $2.3 million / 973,000 MORPHO.** Researcher-attributed institutional theft, reported by Lookonchain and CoinNess; both addresses reportedly used EIP-7702 delegations. These reports repeat ZachXBT, rather than constituting independent forensic confirmation. The suggested Nima Capital connection is **unconfirmed**. [Lookonchain, Oct 21](https://www.lookonchain.com/feeds/77968); [CoinNess](https://coinness.com/en/news/1090119); [original address disclosure](https://t.me/s/investigations/363). |\n| **2026-10-29 — Ethereum mainnet** | **Binance 14:** `0x28C6c06298d514Db089934071355E5743bf21d60`. Authorization transaction: `0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b`. | `0x63e842B054Bd624a465454D533C33F573e9c6fAe` | **About $2.5 billion in the initial sweep**, including 167,464 ETH and 63 tokens; subsequent delegated calls reportedly pulled **823 million USDC from Hot Wallet 34**. These are components, not a final net-loss reconciliation. Blockaid reports the 50 signatures and delegate; separate reporting describes the delegated sweep and downstream wallet permissions. **Custody provider and signing-compromise mechanism remain unknown.** [Blockaid, Oct 29](https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history); [drk, Oct 30](https://drk.vc/news/binance-14-eip-7702-drain); [The Defiant](https://thedefiant.io/news/security/binance-labeled-wallet-swept-minutes-after-eip-7702-delegation). |\n\nFor Binance, I could retrieve the forensic reports but could not independently retrieve the supplied Etherscan transaction through this research interface. Accordingly, the transaction-level assertions above are **attributed findings**, not my own RPC reconstruction. Nor should the reported multichain total be called an EIP-7702 loss: the accounts describe separate direct-transfer activity as well. [Blockaid report](https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history)\n\nI did not establish a qualifying institutional-wallet case during **2025-05-07 through 2025-12-31** from the sources reviewed; that is a research limit, not proof of absence. For example, the May 2025 Inferno Drainer case is described as a **user** loss, while POT’s August exploit used an **attacker’s** delegated EOA to bypass a protocol’s EOA-only assumption. Neither establishes an institution’s wallet being maliciously delegated. [SlowMist H1 2025 report](https://www.slowmist.com/report/SlowMist-first-half-of-the-2025-report%28EN%29.pdf), [OpenZeppelin incident analysis](https://www.openzeppelin.com/news/the-notorious-bug-digest-5)\n\nA signing policy should apply the following checks. These are **engineering requirements inferred from the protocol and documented signing limitations**, not claims that every provider implements them.\n\n1. **Inspect the actual signing preimage and domain.** Recognize `0x05 || rlp([chain_id, address, nonce])` before hashing, validate its encoding, and bind the policy decision to exactly those bytes. The authorization’s `0x05` domain is distinct from the outer transaction’s `0x04` type and the installed code’s `0xef0100` marker. [EIP-7702 specification](https://eips.ethereum.org/EIPS/eip-7702), [Ethereum’s implementation guidelines](https://ethereum.org/roadmap/pectra/7702)\n\n2. **Close opaque-signing bypasses.** A supplied 32-byte digest does not expose its preimage’s prefix or fields. Refusing a named authorization method while permitting arbitrary digests—or unparsed messages hashed with Keccak—does not enforce refusal. Require a verified structured/preimage route, or deny opaque signing for the protected key. Cover single, batch, SDK, automated, and recovery signing paths. Turnkey expressly documents alternate-encoding bypasses; AWS and Azure document digest-signing primitives rather than Ethereum-aware inspection. [Turnkey](https://docs.turnkey.com/features/policies/language), [AWS](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html), [Azure](https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01)\n\n3. **Inspect the authorization’s own `chain_id`.** Reject `0` unless cross-chain authority is explicitly intended: it removes chain binding on networks implementing the mechanism, subject to their other validity checks. Checking only the sponsor transaction’s chain is insufficient. A chain-zero signature does not automatically install code everywhere, but can be submitted elsewhere when valid. Ethereum warns that code at the same delegate address can differ across chains; ERC-7902’s authorization capability requires a nonzero matching chain ID. [Ethereum guidelines](https://ethereum.org/roadmap/pectra/7702), [ERC-7902](https://ercs.ethereum.org/ERCS/erc-7902)\n\n4. **Inspect and approve the delegate as account-control code.** Match the exact address against a chain-specific allowlist and verify the intended implementation, initialization, upgradeability and execution permissions. Treat zero-address revocation separately. A transfer-recipient allowlist is not a delegate allowlist. Fireblocks recommends audited, trusted implementations; Privy publishes a dedicated delegation-contract restriction. [Fireblocks security guidance](https://www.fireblocks.com/blog/security-first-approach-to-eip-7702), [Privy policy example](https://docs.privy.io/controls/policies/example-policies/ethereum)\n\n5. **Inspect the nonce and aggregate signing history.** Require an intentionally reserved account nonce; reject unexplained future-nonce ranges and repeated requests across a range. Each tuple has one exact nonce, not a validity interval. Successful authorization processing increments the authority nonce; processing continues through the list, and the last valid delegation wins. Consequently, “50 signatures means exactly one can apply” is **not a general protocol rule**. A range can cover uncertain account state and potentially apply successive authorizations. [EIP-7702 processing rules](https://eips.ethereum.org/EIPS/eip-7702)\n\n6. **Make approval cover the enduring change of authority.** Display the authority account, chain scope, delegate and nonce, and explain that delegation persists. Do not infer safety from zero transaction value, empty calldata, a trusted sponsor, or a successful simulation of one call. ERC-7902 calls for separate delegation confirmation; Ripple likewise separates authorization approval from submission. [ERC-7902 security considerations](https://ercs.ethereum.org/ERCS/erc-7902), [Ripple delegation lifecycle](https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api)\n\nThe signatures establish that the account’s signing authority was exercised. **They do not identify the off-chain failure.** The 50-nonce pattern is relevant evidence for investigating signing requests, approvals and audit logs; attributing it to a particular vendor, extracted private key, compromised MPC participant or deceived approver requires evidence the public sources do not supply. [BlockSec caveat reported by The Defiant](https://thedefiant.io/news/security/3-55-million-in-unclaimed-bridge-funds-moved-via-eip-7702)\n\n---\nSources offered but not confirmed by this machine:\n- https://docs.privy.io/controls/policies/overview — does not contain the quoted text\n- https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page\n- https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html — did not return a page\n- https://arbiscan.io/tx/0x238b4e619158432ff5ceb279cfea38007d048af4f59901c7af2efcf32e9671b6 — did not return a page\n- https://www.lookonchain.com/feeds/77968 — did not return a page\n- https://thedefiant.io/news/security/3-55-million-in-unclaimed-bridge-funds-moved-via-eip-7702 — did not return a page\n- https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history — did not return a page","citations":[{"contentHash":"969327b24d7d10fec0e056dc943290d26bd86574a4ac1f999737e96a2059496d","quote":"Verify the chain ID is 0 or the ID of the current chain.","retrievedAt":"2026-10-30T01:19:37.956Z","url":"https://eips.ethereum.org/EIPS/eip-7702"},{"contentHash":"64e94f4fbe19160be01aad8b9f344b44d7fde363d590391daf81da8699f824c1","quote":"The private key of the EOA retains full control over the account after the delegation.","retrievedAt":"2026-10-30T01:19:38.073Z","url":"https://ethereum.org/roadmap/pectra/7702"},{"contentHash":"0cf10badb654d51ca50542fa200146cd4d8624a7455cdbeac6586caf512f0d8e","quote":"No policy can stop a key that signs these payloads from signing an authorization.","retrievedAt":"2026-10-30T01:19:38.199Z","url":"https://docs.turnkey.com/features/policies/language"},{"contentHash":"4ccb9293d7a8dda54b605d8e1f77ac0ced0adae47c0b7d2f6cff38dbb1150886","quote":"Restrict the delegation contract for EIP-7702","retrievedAt":"2026-10-30T01:19:38.560Z","url":"https://docs.privy.io/controls/policies/example-policies/ethereum"},{"contentHash":"80b42c3219e127457b30b703df83c9b0eeda0f0c74e37d00f93977d3027884bd","quote":"Both orders go through the standard intent approval flow.","retrievedAt":"2026-10-30T01:19:38.973Z","url":"https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api"},{"contentHash":"a9c916cd9a32a1add8e12565054699aaec75a5f447a63004453fa911f6be90d4","quote":"To complete the activation process, sign the transaction in your mobile app.","retrievedAt":"2026-10-30T01:19:39.360Z","url":"https://docs.fordefi.com/user-guide/vaults/evm-vaults"},{"contentHash":"8abc93ade894e81a63d2a9a4f412823bdc742717b9ead914553543bfaff0f2f3","quote":"DFNS policies don’t introspect raw serialized signature payloads.","retrievedAt":"2026-10-30T01:19:39.476Z","url":"https://docs.dfns.co/guides/signing-policies"},{"contentHash":"c947ddac6dd67894a3690219dec44791f1c33e68ea0949074d1d73f832959465","quote":"Policies reject all raw transactions by default.","retrievedAt":"2026-10-30T01:19:39.602Z","url":"https://fireblocks.readme.io/docs/raw-signing"},{"contentHash":"0a6fd58ff252e69a1b45a0886bbbc28880f67f28fd15f4542711f447fbc33c40","quote":"To delegate, sign a message with your source wallet.","retrievedAt":"2026-10-30T01:19:40.264Z","url":"https://support.utila.io/en/articles/11727423-sponsored-transfer"},{"contentHash":"5fde49c541b646f9d60926dce6eeeccaf98766b8253deddc9a83ac68e1c7ab57","quote":"Your application prompts for signing when required","retrievedAt":"2026-10-30T01:19:40.405Z","url":"https://www.alchemy.com/docs/wallets/transactions/using-eip-7702"},{"contentHash":"334015c7561fab4e942c3b99b9840fac50f65794b6400d3fca96e536e5ad1638","quote":"A wallet that supports EIP-7702 authorization signing.","retrievedAt":"2026-10-30T01:19:40.551Z","url":"https://docs.blockdaemon.com/docs/eip-7702-transaction-batching"},{"contentHash":"ad019a52f24a5afef264d2d0339ac1918d94b291a8f1cf91830a6864fe7a9107","quote":"Policy rules for withdrawals apply only to transactions that involve BitGo.","retrievedAt":"2026-10-30T01:19:40.686Z","url":"https://developers.bitgo.com/docs/policies-overview"},{"contentHash":"6cc09e6889969b5460de17bd181b44f496329ee20c803b913d269fd5a3a0930b","quote":"Creates a signature from a digest using the specified key.","retrievedAt":"2026-10-30T01:19:40.780Z","url":"https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01"},{"contentHash":"4c23240c83f42395002d4955a69a32f2dd012117ca9ac260683a404788891628","quote":"No depositor lost funds.","retrievedAt":"2026-10-30T01:19:40.815Z","url":"https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html"},{"contentHash":"09f944a64f7a0275f2ac7722cc5e961756328d858b20ca81867fb67151a7e804","quote":"There is no limit to the damage that can be done by signing the wrong authorization.","retrievedAt":"2026-10-30T01:19:41.541Z","url":"https://ercs.ethereum.org/ERCS/erc-7902"}],"device":"377843575071cdb1","id":"631e2fc5-6e98-494b-a8fd-5df5a19aa504","model":null,"nodeId":"1be26c53-c7fa-4fb0-ae23-d90e51cff3d2","runtime":"codex"},{"answer":"**The critical control is authorization-aware signing before a signature leaves custody.** Blocking type-4 transactions alone is insufficient: another account can submit the signed authorization. The signature must therefore be governed separately from the transaction carrying it. [EIP-7702 specification](https://eips.ethereum.org/EIPS/eip-7702)\n\nThe Binance reports establish a reported delegation mechanism, but **do not establish which custody provider was involved or whether the attacker extracted a private key, compromised a signing service, or obtained signatures through another route**. Fifty signatures across consecutive nonces do not, by themselves, distinguish those possibilities. Public reporting still describes the signature’s origin as unknown. [Cointribune, 2026-10-30](https://www.cointribune.com/en/binance-hit-by-historic-hack-5-8-billion-drained-part-of-it-frozen/)\n\nThis is a bounded review of public documentation available on **2026-10-30**, not a certification of deployed configurations. “Not mentioned” means the cited documentation does not establish an authorization-specific policy. “Allowed” means a supported signing path exists; it does not mean every caller is authorized. Undated pages below were accessed on that date.\n\n| Provider / product | Mentions EIP-7702 authorizations? | Documented treatment and limits | Source and date |\n|---|---|---|---|\n| **Turnkey** | **Yes**, explicitly distinguished from a type-4 transaction’s authorization list | **Allowed, with configurable allow/deny policies.** Exposes `eth.eip_7702_authorization.address`, `.chain_id`, `.nonce`. Documents delegate allowlisting, chain restrictions and future-nonce risk. Its authorization allow example also checks `PAYLOAD_ENCODING_EIP7702_AUTHORIZATION`; omitting that check can unintentionally allow other payloads. This is configurable enforcement, not a universal refusal. | [Policy language](https://docs.turnkey.com/features/policies/language), undated |\n| **Privy** | **Yes** | **Allowed under configured policy; refused when no applicable allow rule exists on a policy-bearing wallet.** Documents `eth_sign7702Authorization`, with `ethereum_7702_authorization.contract` available for conditions. Deny takes precedence. The cited authorization-field table lists `contract`; it does not establish dedicated chain/nonce controls for this method. | [Policies and controls](https://docs.privy.io/controls/policies/overview), undated |\n| **Ripple Custody — Vault** | **Yes** | **Allowed with approval.** The authority’s `SetDelegation` and sponsor’s `SubmitAuthorization` both follow the standard intent approval flow. Policies can distinguish those operations through `parameters.operation.type`. Earlier Vault images can sign the authorization while being unable to sign its submission transaction—an explicit example of the two paths differing. | [Delegation API](https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api), undated; [v1.43 release](https://docs.ripple.com/products/custody/support/change-history/v143), **2026-10-05** |\n| **Dfns** | **Yes** | **Allowed.** Generate Signature includes an EIP-7702 Authorization input. Sponsored flows are documented as requiring policy authorization of sender and sponsor. The cited material does not establish a universal human-approval requirement or authorization-specific delegate/nonce refusal defaults. | [Generate Signature](https://docs.dfns.co/api-reference/keys/generate-signature), undated; [Fee Sponsors on EVM](https://dfns.co/article/fee-sponsor-on-evm), **2025-06-04** |\n| **Fordefi** | **Yes for EIP-7702 activation; separate authorization policy not described in this guide** | **Allowed with signing approval in the documented UI flow.** Smart-account activation uses Simple7702Account and requires signing in the mobile app. Whether a separate API or raw-signing path can authorize arbitrary delegates is **unknown from this guide**. | [EVM Vaults](https://docs.fordefi.com/user-guide/vaults/evm-vaults), undated |\n| **Fireblocks** | **Yes in security guidance** | **Authorization-specific enforced policy: not mentioned in the cited material.** Guidance recommends audited, trusted delegates. Separately, raw signing is **refused by default in production** and needs enablement plus policy rules; sandbox differs. This is not evidence of an unconditional EIP-7702 prohibition, nor proof of semantic filtering after raw signing is enabled. | [Security First Approach](https://www.fireblocks.com/blog/security-first-approach-to-eip-7702), **2025-03-12**; [Sign Raw Messages](https://fireblocks.readme.io/docs/raw-signing), undated |\n| **Alchemy Wallet APIs** | **Yes** | **Allowed.** EIP-7702 is enabled by default; APIs prepare authorization payloads and the application prompts for signing when required. Documents a default Modular Account delegate. The external signer’s custody policy remains a separate question. | [How EIP-7702 works](https://www.alchemy.com/docs/wallets/transactions/using-eip-7702), undated |\n| **Safe** | **Yes** | **Signing-provider refusal/approval policy: not mentioned.** Its technical overview explains the special authorization hash and says wallet providers must support that signing method. This does not establish that Safe’s multisig approval policy governs an EOA owner’s separate authorization signature. | [What is EIP-7702?](https://docs.safe.global/advanced/eip-7702/overview), undated; page retains pre-mainnet wording |\n| **Securosys Primus / Transaction Security Broker** | **Not in the cited Ethereum-signing and SKA-policy pages** | **Not mentioned.** Documents Ethereum-compatible signing and configurable key-use approval rules. Empty rules permit the operation without conditions. No EIP-7702 decoder, delegate allowlist or chain-zero refusal is established by these pages. | [Ethereum signing](https://docs.securosys.com/tsb/Tutorials/Blockchain/sign/), updated **2026-09-07**; [SKA authorization policy](https://docs.securosys.com/ska/Concepts/authorization_policy/), updated **2026-10-12** |\n| **AWS KMS** | **Not in the cited Sign API** | **Not mentioned.** Documents message/digest signing controlled by `kms:Sign` permission and compatible key/algorithm selection. No EIP-7702 semantic policy is documented here. Digest-signing capability should not be mistaken for authorization-aware inspection. | [Sign API](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html), undated |\n| **Blockaid Cosigner — signing-security integration, not key custody** | **Yes, particularly authorization lists in type-4 transactions** | **Refused when classified malicious**, according to its documented default policy, regardless of approver count. Its report describes screening the carrying transaction; it does **not establish interception of every standalone authorization or opaque-digest endpoint** of every integrated custodian. | [Binance analysis / Cosigner description](https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history), **2026-10-29** |\n\nNone of these sources establishes a blanket, product-wide refusal of every EIP-7702 authorization across every signing interface. In particular, a general approval quorum, a raw-signing prohibition and a parsed authorization policy are three different controls; their documented scope must not be conflated. [Fireblocks raw signing](https://fireblocks.readme.io/docs/raw-signing), [Securosys SKA](https://docs.securosys.com/ska/Concepts/authorization_policy/), [Turnkey policy language](https://docs.turnkey.com/features/policies/language)\n\nThe public incident evidence since **2025-05-07** falls into different confidence and mechanism categories:\n\n| Incident date | Chain; institution / scope | Wallet address | Delegate address | Loss and evidence |\n|---|---|---|---|---|\n| **2026-10-29** | **Ethereum; Binance 14 — direct delegated-wallet drain** | `0x28C6c06298d514Db089934071355E5743bf21d60` | `0x63e842B054Bd624a465454D533C33F573e9c6fAe` | Reported first sweep: **167,464 ETH plus 63 tokens**, including approximately **1.615B USDT**; estimated **$2.5B** in the cited analysis. Subsequent sweeps make that an initial outflow, not a final net-loss figure. [Blockaid, Oct 29](https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history), [drk transaction analysis, Oct 30](https://drk.vc/news/binance-14-eip-7702-drain) |\n| **2026-10-29**, same incident | **Ethereum; Binance Hot Wallet 34 — indirect drain through delegated operator Binance 14** | Report abbreviates it as **`0xEe7a…4055`**; full address not established here | Same Binance 14 delegate above; **not evidence that Hot Wallet 34 itself received a delegation** | **823M USDC**, reported as 780M followed by 43M, transferred through its operator’s delegated execution. Keep this separate from the initial Binance 14 sweep and from other chains’ ordinary signed transfers. [drk analysis and evidence ledger](https://drk.vc/news/binance-14-eip-7702-drain) |\n| **2026-10-21** | **Unnamed institution; chain not explicitly established in the cited MORPHO report** | **Two addresses; not published in the cited reports** | **Unknown** | **973,000 MORPHO, approximately $2.3M**. Both thefts reportedly involved EIP-7702 delegation. News coverage attributes this to ZachXBT; it is **reported, not independently reproduced here**. The suggested Nima Capital connection is not confirmed ownership. [Lookonchain, Oct 21](https://lookonchain.com/feeds/77968), [KuCoin/MarsBit, Oct 21](https://www.kucoin.com/news/flash/institutional-morpho-theft-worth-2-3m-reported-funds-moved-to-tornado-cash) |\n| **2026-10-09**, alert dated Oct 10 | **Ethereum / Polygon; bridge-claim wallet, reportedly linked to the institution above** | `0x4943b0C9959dcf58871A799dfB71becE0D97c9f4` in the alert registry | **Unknown** | Approximately **$3.5M–$3.55M** in unclaimed bridge assets. Registry reports delegation-assisted claims; later reporting links an Oct 9 bridge theft to the MORPHO victim. **The linkage and institutional identity are not independently confirmed.** The registry’s duplicated “$5.8M” headline should not be counted as an additional incident. [thatsRekt registry](https://thatsrekt.com/), [Lookonchain follow-up](https://lookonchain.com/feeds/77968) |\n| **2026-01-06** | **Arbitrum; IPOR legacy USDC Optimizer — vault drain through a delegated administrator** | Administrator **`0xd8a1…`**, full address unknown from postmortem; drained vault **`0xa91267a25939b2b0f046013fbf9597008f7f014b`** | **`0xa3cc…`**, full address unknown from postmortem | Approximately **$336K**. Project-confirmed combination of an arbitrary-call delegate and missing vault validation. Attacker returned 92 ETH, retained an agreed bounty; DAO covered the shortfall and restored **336,580 USDC**. This was a vault loss through administrator authority, not a direct sweep of the administrator’s balance. [IPOR postmortem, Jan 7, subsequently updated](https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html) |\n\n**Evidence limits matter:** the October institutional reports largely trace back to social alerts, even when republished by news sites. Their missing delegate addresses and transaction-level corroboration remain unknown. They should not receive the same evidentiary weight as IPOR’s project postmortem or the transaction-linked Binance analyses. I could not independently retrieve the Binance authorization transaction from Etherscan during this review, so its exact execution details above remain attributed to those analyses.\n\nTwo related cases should **not silently inflate the direct institutional-wallet-drain list**:\n\n- **GANA Payment, 2025-11-20, BNB Chain, approximately $3.1M:** Hacken describes compromised or misused deployer privileges, ownership rotation, and attacker accounts delegated to execute reward manipulation. That establishes a protocol/pool exploit involving EIP-7702, not a demonstrated sweep of an institutional EOA’s holdings through its own delegation. [Hacken forensic analysis](https://hacken.io/insights/gana-payment-hack-explained/)\n- **DxSale, 2026-05-29, BNB Chain, approximately $7.3M:** BlockSec says a delegated deployer compromise assisted fee manipulation, but the locker’s missing state updates independently enabled the drain; delegation was not a prerequisite. [BlockSec analysis](https://blocksec.com/blog/web3-security-dxsale-squidrouter-more)\n\n**What the signing policy must inspect**\n\nThe following is an engineering conclusion from the protocol and provider documentation, not a claim that every provider implements it.\n\n1. **Inspect the actual signing preimage and domain.** Recognize `0x05 || rlp([chain_id, delegate_address, nonce])` before hashing. `0x04` identifies the carrying transaction; `0xef0100` identifies installed delegation code. Neither substitutes for recognizing the authorization-signing request. Validate the decoded structure and bind it to the exact bytes being signed. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)\n\n2. **Close opaque-hash and alternate-signing paths.** A digest does not reveal its preimage’s `0x05` prefix. Therefore, deny unrestricted digest signing for protected keys, or require a trusted component to supply, validate and hash the preimage itself. Cover batch, raw-payload and automatic sponsorship paths, not merely an endpoint named `signAuthorization`. This follows from digest-signing semantics; AWS explicitly skips hashing for `DIGEST`, while Turnkey documents a policy example denying `NO_OP` raw signing. [AWS Sign](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html), [Turnkey policy language](https://docs.turnkey.com/features/policies/language)\n\n3. **Inspect the authorization’s own `chain_id`.** Reject **zero** unless universal replayability is deliberately authorized; restrict nonzero IDs to intended chains. Zero is valid on every supporting chain, subject to that chain’s other validity checks—it does **not** automatically install code everywhere. Checking the sponsor transaction’s chain alone is insufficient. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), [Ethereum’s Pectra guidance](https://ethereum.org/roadmap/pectra/7702)\n\n4. **Inspect the delegate, its code and the authority being changed.** Allow only reviewed implementations on the intended chain, with trusted initialization and upgrade behavior. A denylist cannot cover newly deployed malicious delegates. Treat zero-address revocation as a distinct approved operation. The policy decision must concern the wallet surrendering execution control, not just the sponsor or outer recipient. [Ethereum guidance](https://ethereum.org/roadmap/pectra/7702), [Turnkey policy language](https://docs.turnkey.com/features/policies/language)\n\n5. **Inspect individual nonces and aggregate nonce ranges.** Require an explicitly intended nonce, account for pending activity, and reject or escalate unexplained consecutive-nonce batches such as the reported 50-signature request. Future-nonce authorizations are latent permissions, so per-request checks should be supplemented by cross-request tracking. This recommendation follows from documented nonce validity and future-nonce risk. [Turnkey policy language](https://docs.turnkey.com/features/policies/language)\n\n   Do not assume that only one authorization in a consecutive range can apply: processing increments the authority’s nonce after success, and the last valid occurrence determines the resulting code. The cited Binance analysis’s “one matches” description is insufficient to establish how many tuples actually applied. [EIP-7702 processing rules](https://eips.ethereum.org/EIPS/eip-7702)\n\n6. **Approve persistent account control, not a nominal zero-value action.** Display and approve the authority, delegate, chain scope and nonce together. Delegation remains active until replaced or cleared, so a harmless-looking initial call is not a sufficient risk assessment. If delegation is unwanted for that wallet, refuse the authorization entirely. [Ripple Custody release documentation](https://docs.ripple.com/products/custody/support/change-history/v143), [Fireblocks security guidance](https://www.fireblocks.com/blog/security-first-approach-to-eip-7702)\n\nFor the Binance signing-path question, the missing evidence is **the signing-service audit trail tying each signature to its preimage, endpoint, caller, policy decision and approval record**. On-chain signatures establish authorization by the account’s key; they do not identify the off-chain custody architecture or prove key extraction. [Dfns on indistinguishable MPC signatures](https://dfns.co/article/ethereum), [Cointribune on the unknown signature origin](https://www.cointribune.com/en/binance-hit-by-historic-hack-5-8-billion-drained-part-of-it-frozen/)\n\n---\nSources offered but not confirmed by this machine:\n- https://docs.privy.io/controls/policies/overview — does not contain the quoted text\n- https://docs.ripple.com/products/custody/support/change-history/v143 — does not contain the quoted text\n- https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page\n- https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html — did not return a page\n- https://lookonchain.com/feeds/77968 — did not return a page\n- https://thatsrekt.com/ — does not contain the quoted text\n- https://hacken.io/insights/gana-payment-hack-explained/ — did not return a page","citations":[{"contentHash":"969327b24d7d10fec0e056dc943290d26bd86574a4ac1f999737e96a2059496d","quote":"Verify the chain ID is 0 or the ID of the current chain.","retrievedAt":"2026-10-30T01:18:05.028Z","url":"https://eips.ethereum.org/EIPS/eip-7702"},{"contentHash":"0cf10badb654d51ca50542fa200146cd4d8624a7455cdbeac6586caf512f0d8e","quote":"It does not describe the authorization list of a Type 4 transaction.","retrievedAt":"2026-10-30T01:18:05.175Z","url":"https://docs.turnkey.com/features/policies/language"},{"contentHash":"80b42c3219e127457b30b703df83c9b0eeda0f0c74e37d00f93977d3027884bd","quote":"Both orders go through the standard intent approval flow.","retrievedAt":"2026-10-30T01:18:05.666Z","url":"https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api"},{"contentHash":"aaa1fe04c7503621c4719319ca925f4fb1803923c949413959eea82af671029c","quote":"EIP-7702 Authorization","retrievedAt":"2026-10-30T01:18:06.137Z","url":"https://docs.dfns.co/api-reference/keys/generate-signature"},{"contentHash":"d73d1fffad5e1d4395688cef446894e5f44a9b4f7af56b9ffb570ba687589560","quote":"The transaction only proceeds if both the sponsor and sender are properly authorized through policy checks.","retrievedAt":"2026-10-30T01:18:06.905Z","url":"https://dfns.co/article/fee-sponsor-on-evm"},{"contentHash":"a9c916cd9a32a1add8e12565054699aaec75a5f447a63004453fa911f6be90d4","quote":"To complete the activation process, sign the transaction in your mobile app.","retrievedAt":"2026-10-30T01:18:07.276Z","url":"https://docs.fordefi.com/user-guide/vaults/evm-vaults"},{"contentHash":"c947ddac6dd67894a3690219dec44791f1c33e68ea0949074d1d73f832959465","quote":"Policies reject all raw transactions by default.","retrievedAt":"2026-10-30T01:18:07.528Z","url":"https://fireblocks.readme.io/docs/raw-signing"},{"contentHash":"5fde49c541b646f9d60926dce6eeeccaf98766b8253deddc9a83ac68e1c7ab57","quote":"If delegation is required, Transaction APIs prepare the correct authorization payload","retrievedAt":"2026-10-30T01:18:07.815Z","url":"https://www.alchemy.com/docs/wallets/transactions/using-eip-7702"},{"contentHash":"9bff099e59a3da276646658cfedcd48f55ee68259d462a827bdf428039dcb6aa","quote":"This signing method is not compatible with the EIP-712 or EIP-191 standards.","retrievedAt":"2026-10-30T01:18:08.340Z","url":"https://docs.safe.global/advanced/eip-7702/overview"},{"contentHash":"3d362a6698687523f3f84e62d4dcd442cf83ea82617c78a8e9bc256f21e77e9f","quote":"If a rule is empty, the associated operation can be performed without any conditions needing to be satisfied.","retrievedAt":"2026-10-30T01:18:08.605Z","url":"https://docs.securosys.com/ska/Concepts/authorization_policy/"},{"contentHash":"f111a5a4913d14776d41119d8d3cf4efb10083db0db50103d9c93434a6b2b9ad","quote":"Treat EIP-7702 authorizations as privileged operations under the same policy controls as a cold wallet transfer.","retrievedAt":"2026-10-30T01:18:09.083Z","url":"https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history"},{"contentHash":"4d75433b01c861f18b1764c9fef9021864a3f691811231292d864851eaf9984e","quote":"823M USDC pulled from Hot Wallet 34 via execute()","retrievedAt":"2026-10-30T01:18:09.153Z","url":"https://drk.vc/news/binance-14-eip-7702-drain"},{"contentHash":"4c23240c83f42395002d4955a69a32f2dd012117ca9ac260683a404788891628","quote":"This line allowed the attacker (or a specific actor aware of the vector) to call any function on any address on behalf of the administrator.","retrievedAt":"2026-10-30T01:18:10.270Z","url":"https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html"},{"contentHash":"4a6e6c09d746f8c790d49f8c42937689d9c98964cca8b20d9e5b7a1f309105ab","quote":"The prior compromise of the DxSale deployer via EIP-7702 delegation was not a prerequisite for the exploit, but it amplified the attacker's efficiency.","retrievedAt":"2026-10-30T01:18:10.603Z","url":"https://blocksec.com/blog/web3-security-dxsale-squidrouter-more"},{"contentHash":"64e94f4fbe19160be01aad8b9f344b44d7fde363d590391daf81da8699f824c1","quote":"When users perform delegated signatures, the target contract receiving the delegation should be clearly and prominently displayed to help mitigate phishing risks.","retrievedAt":"2026-10-30T01:18:10.822Z","url":"https://ethereum.org/roadmap/pectra/7702"},{"contentHash":"e1c29d2bc11577691a0a134e21f48a27785d3d650c74be02c3c5e3240ebdade4","quote":"while the origin of the signature remains unknown.","retrievedAt":"2026-10-30T01:18:11.231Z","url":"https://www.cointribune.com/en/binance-hit-by-historic-hack-5-8-billion-drained-part-of-it-frozen/"}],"device":"35c52a5b502e847c","id":"81fb7781-6c8a-41f8-b59d-6a905c0009c3","model":null,"nodeId":"1be26c53-c7fa-4fb0-ae23-d90e51cff3d2","runtime":"codex"},{"answer":"**The key control is authorization-aware signing, including restrictions on raw-digest signing.** Blocking type-4 transactions alone does not stop a key from signing an EIP-7702 authorization that another account later submits. Turnkey documents this distinction explicitly; the EIP defines separate signatures for the authorization and enclosing transaction. [Turnkey policy reference](https://docs.turnkey.com/features/policies/language#eip-7702), [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)\n\nThis is a public-documentation survey as of **30 October 2026**, not an audit of deployed products or customer configurations. “Not mentioned” means the cited documentation does not specify authorization handling; it does **not** mean the provider permits it. Undated pages below were accessed on that date.\n\n**Provider documentation**\n\n“Allowed” below means a documented supported signing path, potentially subject to customer policies—not unconditional permission.\n\n| Provider / product | Mentions EIP-7702 authorizations? | Documented treatment and limits | Source and date |\n|---|---|---|---|\n| **Fireblocks Vault Accounts** | Yes, in an official support response | **Refused for arbitrary delegation through the supported product path:** staff said customers cannot attach arbitrary contract code with `set_code`. This does not establish what an enabled raw-signing path can sign. Raw signing is separately disabled by default in production. | [Official support thread](https://community.fireblocks.com/t/eip-7702-set-code-with-fireblock-wallet/2928), **17 September 2025**; [raw-signing documentation](https://fireblocks.readme.io/docs/raw-signing), undated. A later thread question does not establish a changed policy. |\n| **Fordefi** | Yes | **Allowed with approval:** smart-account activation uses Ethereum Foundation `Simple7702Account`; the documented console flow requires signing in the mobile app. The page does not establish a blanket prohibition on alternative authorization-signing paths. | [EVM Vaults](https://docs.fordefi.com/user-guide/vaults/evm-vaults), undated; [release notes](https://docs.fordefi.com/changelog/platform), feature announced **11 January 2026**. |\n| **Ripple Custody — Vault** | Yes | **Allowed with approval:** `SetDelegation` signs the authority’s authorization; `SubmitAuthorization` submits it through a sponsor. Both orders pass through standard intent approval. Policies can match their operation types separately. | [Delegation API documentation](https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api), **v1.43 LTS**, publication date unstated. |\n| **Dfns** | Yes | **Allowed:** the signature API explicitly supports `kind: Eip7702`, with `chainId`, delegate `address`, and `nonce`. This reference does not specify a mandatory delegation allowlist or human approval requirement. | [EVM signature API](https://docs-legacy.dfns.co/d/api-docs/keys/generate-signature/evm), undated legacy reference. |\n| **Turnkey** | Yes, extensively | **Allowed under configurable policy; refusal is configurable.** Policies can inspect `eth.eip_7702_authorization.address`, `chain_id`, and `nonce`. Documentation explicitly warns that other raw encodings and batch-signing paths can bypass authorization-specific checks unless separately restricted. No universal human-approval requirement is established. | [Policy language—EIP-7702](https://docs.turnkey.com/features/policies/language#eip-7702), undated. |\n| **Privy** | Yes | **Allowed or refused by configured policy:** `eth_sign7702Authorization` is a distinct policy method; `ethereum_7702_authorization` exposes authorization data, including `contract`. For wallets with policies, missing method permissions default to denial; `DENY` overrides `ALLOW`. Mandatory human approval is not established here. | [Policies and controls](https://docs.privy.io/controls/policies/overview), undated. |\n| **Alchemy Wallet APIs** | Yes | **Allowed only for listed delegates; others refused:** APIs accept two specified `SemiModularAccount7702` deployments and reject other delegation addresses. This is an API restriction, not proof of restrictions on an externally controlled owner key. | [How EIP-7702 works](https://www.alchemy.com/docs/wallets/transactions/using-eip-7702), undated. |\n| **Ledger Ethereum application** | Yes | **Refused by default / conditionally allowed:** “Smart account upgrade” is disabled by default. Ledger’s published initial policy permits the Ethereum Foundation simple contract and blocks other delegates at device level. The documented hardware flow displays authorization parameters and requests confirmation. Current firmware-specific allowlist contents require separate verification. | [Support documentation](https://support.ledger.com/article/360009576554-zd), undated; [Ledger policy announcement](https://www.ledger.com/blog-pectra-upgrade-announcement), **7 May 2025**; [hardware integration description](https://zknox.eth.limo/posts/2025/05/09/integrating_7702_hws_090525.html), **9 May 2025**. |\n| **AWS KMS** | **Not mentioned** in cited signing API | **Not mentioned:** `Sign` accepts messages or digests under key permissions. The API reference documents no Ethereum authorization parser, delegate allowlist, or EIP-7702-specific refusal. Application-layer controls remain unknown. | [KMS `Sign`](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html), undated. |\n| **Microsoft Azure Key Vault** | **Not mentioned** in cited signing API | **Not mentioned:** the API signs a supplied digest using the selected key and requires `keys/sign` permission. It does not document EIP-7702-specific inspection or refusal. Application-layer controls remain unknown. | [Key Vault `sign`](https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01), API version **2025-07-01**; publication date unstated. |\n| **Cobo** | General EIP-7702 discussion, **not authorization policy** | **Not mentioned:** its account-abstraction article discusses EIP-7702, but does not establish whether custody/MPC signers refuse authorizations, permit them, or require approval. | [Account-abstraction guide](https://www.cobo.com/post/account-abstraction-wallet), publication date not independently established from the retrieved text. |\n\nFireblocks’ Dynamic-related EIP-7702 announcement should not be substituted for its Vault Account policy: it describes a different product integration. [Fireblocks/Dynamic announcement, 7 May 2025](https://www.fireblocks.com/blog/how-you-can-ship-eip-7702-today)\n\n**Public incidents since 7 May 2025**\n\nThe following separates direct wallet delegation drains from an administrator-delegation compromise that enabled a vault drain. Unknown delegate addresses are left unknown rather than inferred from attacker or recipient addresses.\n\n| Date | Chain | Institutional wallet / account | Delegate address | Loss or outflow; evidentiary status | Sources |\n|---|---|---|---|---|---|\n| **6 January 2026**, 21:02 UTC | Arbitrum | IPOR USDC Lending Optimizer vault `0xa91267a25939b2b0f046013fbf9597008f7f014b`; delegated administrator identified in the postmortem only as `0xd8a1…` | `0xa3cc…`; full address **unknown from the cited text** | Approximately **$336,000 taken**. An unsafe administrator delegate enabled arbitrary calls, malicious fuse installation, and withdrawal from the vault. The vault itself was not the delegated EOA. Subsequently restored to **336,580 USDC**, with the DAO covering the bounty; no depositor loss remained. | [IPOR’s own postmortem, 7 January 2026](https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html), including linked transactions. |\n| **9 October 2026** | Ethereum | `0x4943b0c9959dcf58871a799dfb71bece0d97c9f4`; subsequently described as belonging to an institutional entity | **Unknown from retrieved sources** | Approximately **$3.55 million** in previously unclaimed Agglayer/Rainbow Bridge funds claimed and moved through delegated execution. Initial reporting explicitly left theft versus authorized recovery unresolved; ZachXBT later described it as theft. Institutional identity remains unconfirmed. | [Detailed reporting and uncertainty](https://www.cryplounge.com/news/technology/roughly-3-55-million-unclaimed-bridge-funds-moved-ethereum); [ZachXBT investigation](https://t.me/s/investigations/365); [subsequent non-social reporting, 21 October](https://cryptovka.com/news/institutional-investor-loses-2-3-million-in-sophisticated-morpho-token-theft). |\n| **21 October 2026**, reported date | Ethereum | `0x4943b0c9959dcf58871a799dfb71bece0d97c9f4` and `0x10bf1dcb5ab7860bab1c3320163c6dddf8dcc0e4` | **Unknown from retrieved sources** | **973,000 MORPHO, approximately $2.3 million**, reportedly stolen through EIP-7702 delegations. Attribution to an institutional entity comes from ZachXBT; the suggested Nima Capital connection is an on-chain association, not confirmed ownership. | [Original investigation](https://t.me/s/investigations/365); [Cryptovka, 21 October 2026](https://cryptovka.com/news/institutional-investor-loses-2-3-million-in-sophisticated-morpho-token-theft). |\n| **29 October 2026**, delegation at 20:20:59 UTC | Ethereum mainnet | Binance 14: `0x28C6c06298d514Db089934071355E5743bf21d60` | `0x63e842B054Bd624a465454D533C33F573e9c6fAe`, as reported by the detailed investigation | Initial sweep: **167,464 ETH plus 63 ERC-20 transfers**, including approximately **1.615 billion USDT**. Later delegated calls reportedly reached another Binance smart wallet for **823 million USDC**. These are outflows, not an independently established final net loss. | [Detailed investigation, 30 October](https://drk.vc/news/binance-14-eip-7702-drain); [FinanceFeeds reporting](https://financefeeds.com/binance-hack-3-3b-hot-wallets-drained-tether-circle-freeze/); [The Defiant report syndicated by CryptoNews](https://cryptonews.net/news/market/33673817/). |\n\nFor Binance, the detailed investigation reports **50 authorizations at nonces 18,914,775–18,914,824**, with **18,914,809** applied. I could not retrieve the transaction directly through the explorer, so those precise details remain attributed to that investigation. Whether the signatures resulted from stolen key material, signing-service misuse, or another authorized-signing failure is **unknown**. Neither a nonce bracket nor valid signatures alone identifies the custody provider or proves a particular compromise route. [Detailed investigation](https://drk.vc/news/binance-14-eip-7702-drain), [reporting on the unresolved signing mechanism](https://ct.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo)\n\nThese sources do not establish a complete incident census. In particular, reports about anonymous retail wallets, or attacks using the **attacker’s own** delegated EOA to exploit a protocol, do not by themselves establish an institutional wallet delegation drain. OpenZeppelin’s August 2025 example is the latter category. [OpenZeppelin incident analysis](https://www.openzeppelin.com/news/the-notorious-bug-digest-5)\n\n**What a signing policy must inspect**\n\nThe following are engineering requirements inferred from the protocol and the documented signing-path limitations:\n\n1. **Recognize the authorization before hashing.** Identify and decode `0x05 || rlp([chain_id, address, nonce])`, binding those fields to the actual signature request. `0x05` is the authorization domain prefix; the enclosing transaction uses type `0x04`. A transaction-type filter therefore does not cover every authorization-signing path. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)\n\n2. **Close opaque signing paths.** A supplied 32-byte digest does not reveal whether its preimage was an authorization. Require a trusted, verified preimage and semantic policy evaluation, or refuse arbitrary-digest signing for the protected key. Cover single requests, batches, hexadecimal/UTF-8 encodings, and automatically generated sponsorship authorizations. Turnkey specifically documents these alternative paths and recommends separate keys where incompatible raw-signing needs remain. [Turnkey signing-path limitations](https://docs.turnkey.com/features/policies/language#eip-7702), [AWS digest-signing API](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html)\n\n3. **Inspect the authorization’s own `chain_id`.** Treat **zero as chain-unrestricted**, not missing or harmless. Restrict permitted chains explicitly, including zero unless deliberately approved. Its validity on a particular network still depends on that network supporting the mechanism and satisfying account-state checks. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), [Ethereum wallet guidelines](https://ethereum.org/roadmap/pectra/7702)\n\n4. **Inspect the delegate address and deployed implementation.** Use a positive allowlist with chain-specific code verification; an address blocklist cannot anticipate freshly deployed malicious delegates. Review initialization, upgradeability and caller authentication. Handle delegation to the zero address as a separate revocation operation. Ethereum’s guidance warns against proxy delegates and cross-chain deployment differences. [Ethereum guidelines](https://ethereum.org/roadmap/pectra/7702), [Alchemy’s concrete allowlist](https://www.alchemy.com/docs/wallets/transactions/using-eip-7702)\n\n5. **Inspect nonce values and aggregate ranges across requests.** Reject unauthorized future-nonce reservations and consecutive-nonce batches; log the authority, chain scope, delegate and nonce together. A future authorization can remain usable until the account passes its nonce. Merely invalidating today’s nonce does not eliminate higher signed authorizations. This makes a 50-nonce range a policy-relevant signing event, although it does not establish attacker intent by itself. [Turnkey nonce guidance](https://docs.turnkey.com/features/policies/language#eip-7702)\n\n6. **Approve delegation as an account-control change.** The review must expose the authority, delegate, chain scope and nonce—not merely transfer amount or transaction recipient. Also assess privileges the authority holds over other contracts: IPOR demonstrates that compromising delegated administrator execution can drain a separate vault. [Ripple’s separate delegation approval operations](https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api), [IPOR postmortem](https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html)\n\nFor a wallet that should never delegate, the defensible rule is to **deny recognized authorizations and deny opaque signing routes capable of producing them**. An HSM or MPC protecting key material does not, by itself, establish that those semantic restrictions exist. [Turnkey’s explicit restriction guidance](https://docs.turnkey.com/features/policies/language#eip-7702), [Azure’s digest-signing interface](https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01)\n\n---\nSources offered but not confirmed by this machine:\n- https://community.fireblocks.com/t/eip-7702-set-code-with-fireblock-wallet/2928 — does not contain the quoted text\n- https://docs-legacy.dfns.co/d/api-docs/keys/generate-signature/evm — could not be read: write EPROTO C0122F648B7F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:918:SSL alert number 40\n\n- https://docs.privy.io/controls/policies/overview — does not contain the quoted text\n- https://support.ledger.com/article/360009576554-zd — does not contain the quoted text\n- https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html — did not return a page\n- https://www.cryplounge.com/news/technology/roughly-3-55-million-unclaimed-bridge-funds-moved-ethereum — could not be read: www.cryplounge.com resolves to an address that is not on the public internet","citations":[{"contentHash":"969327b24d7d10fec0e056dc943290d26bd86574a4ac1f999737e96a2059496d","quote":"Verify the chain ID is 0 or the ID of the current chain.","retrievedAt":"2026-10-30T01:16:02.995Z","url":"https://eips.ethereum.org/EIPS/eip-7702"},{"contentHash":"0cf10badb654d51ca50542fa200146cd4d8624a7455cdbeac6586caf512f0d8e","quote":"No policy can stop a key that signs these payloads from signing an authorization.","retrievedAt":"2026-10-30T01:16:03.131Z","url":"https://docs.turnkey.com/features/policies/language"},{"contentHash":"c947ddac6dd67894a3690219dec44791f1c33e68ea0949074d1d73f832959465","quote":"By default, Raw Signing is not available in production workspaces.","retrievedAt":"2026-10-30T01:16:04.304Z","url":"https://fireblocks.readme.io/docs/raw-signing"},{"contentHash":"a9c916cd9a32a1add8e12565054699aaec75a5f447a63004453fa911f6be90d4","quote":"To complete the activation process, sign the transaction in your mobile app.","retrievedAt":"2026-10-30T01:16:04.484Z","url":"https://docs.fordefi.com/user-guide/vaults/evm-vaults"},{"contentHash":"80b42c3219e127457b30b703df83c9b0eeda0f0c74e37d00f93977d3027884bd","quote":"Both orders go through the standard intent approval flow.","retrievedAt":"2026-10-30T01:16:04.683Z","url":"https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api"},{"contentHash":"5fde49c541b646f9d60926dce6eeeccaf98766b8253deddc9a83ac68e1c7ab57","quote":"All other delegation addresses are rejected.","retrievedAt":"2026-10-30T01:16:05.023Z","url":"https://www.alchemy.com/docs/wallets/transactions/using-eip-7702"},{"contentHash":"6cc09e6889969b5460de17bd181b44f496329ee20c803b913d269fd5a3a0930b","quote":"Creates a signature from a digest using the specified key.","retrievedAt":"2026-10-30T01:16:05.436Z","url":"https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01"},{"contentHash":"4c23240c83f42395002d4955a69a32f2dd012117ca9ac260683a404788891628","quote":"The incident resulted from the combination of two independent factors:","retrievedAt":"2026-10-30T01:16:05.485Z","url":"https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html"},{"contentHash":"48cb2168673473f32f0626b79368d9ee8575093782e25dd7a6d95c3404bf8f4a","quote":"Both thefts from 0x4943 & 0x10bf involve EIP-7702 delegation transactions.","retrievedAt":"2026-10-30T01:16:05.949Z","url":"https://t.me/s/investigations/365"},{"contentHash":"36b838c8ba7630f4809da633ddca0c025c450a6de6d37f83e54e38aa404083c4","quote":"an unidentified institutional investor suffered a loss of 973,000 MORPHO tokens","retrievedAt":"2026-10-30T01:16:06.136Z","url":"https://cryptovka.com/news/institutional-investor-loses-2-3-million-in-sophisticated-morpho-token-theft"},{"contentHash":"4d75433b01c861f18b1764c9fef9021864a3f691811231292d864851eaf9984e","quote":"The one at 18,914,809 matches the live nonce and is applied.","retrievedAt":"2026-10-30T01:16:06.360Z","url":"https://drk.vc/news/binance-14-eip-7702-drain"},{"contentHash":"8cd7748b52a039c9f285aa9f2deaa298c8e4322b4023c891ec800e91abf70cf5","quote":"The onchain records connect the movements but do not establish whether they were authorized, or whether Binance or its customers suffered a loss.","retrievedAt":"2026-10-30T01:16:06.401Z","url":"https://cryptonews.net/news/market/33673817/"},{"contentHash":"64e94f4fbe19160be01aad8b9f344b44d7fde363d590391daf81da8699f824c1","quote":"When users perform delegated signatures, the target contract receiving the delegation should be clearly and prominently displayed to help mitigate phishing risks.","retrievedAt":"2026-10-30T01:16:07.024Z","url":"https://ethereum.org/roadmap/pectra/7702"}],"device":"376bf206e3a19921","id":"8930d7e8-c99c-4834-8010-d7134caba58f","model":null,"nodeId":"1be26c53-c7fa-4fb0-ae23-d90e51cff3d2","runtime":"codex"},{"answer":"**Scope and caveats.** This is a short desk review. I fetched or searched the pages cited below, and the date of each source is stated only where a page showed it. Most vendors turned up nothing on EIP-7702 authorizations. For those, \"not found\" means my searches didn't surface a page. It doesn't prove the vendor has no policy. The Binance 14 incident is only a day old (today is 2026-10-30). Everything about it comes from press coverage and Blockaid's statements. Binance has not confirmed the method.\n\n## 1. Provider policy table\n\n| Provider | Mentions 7702 authorizations? | Documented policy | Source (date) |\n|---|---|---|---|\n| Turnkey (wallet infrastructure, policy engine) | Yes | **Allowed only under policy.** Its policy examples allow named delegate addresses on named chains and deny `chain_id == 0`. They also deny batch raw-payload signing of authorizations and deny Type 4 transactions. | [Turnkey Ethereum policy examples](https://docs.turnkey.com/features/policies/examples/ethereum) (undated page, read 2026-10-30) |\n| Fireblocks | Yes, but only in a blog post, not in policy documentation | **Restrictive guidance, no product policy found.** The post says to limit delegations to audited, trusted contracts. It doesn't say whether the Fireblocks Policy Engine can refuse an authorization. | [Fireblocks blog](https://www.fireblocks.com/blog/security-first-approach-to-eip-7702) (12 Mar 2025) |\n| Privy | Yes | **Allowed.** The docs describe a signing method for authorizations and say nothing about policy or allowlisting of delegates. | [Privy sign-7702-authorization](https://docs.privy.io/wallets/using-wallets/ethereum/sign-7702-authorization) (undated) |\n| Dfns | Yes | **Allowed as a signing kind.** The page says nothing about policy. | [Dfns EVM signing](https://docs.dfns.co/api-reference/sign/evm) (undated) |\n| Safe (smart-account infrastructure) | Yes | **Not a custody policy.** Its docs describe how to delegate safely, and say existing Safe contracts can't be used with 7702. | [Safe docs](https://docs.safe.global/advanced/eip-7702/overview) (undated; from search result only) |\n| BitGo, Anchorage, Copper, Cobo (Argus), Ledger Enterprise, Fordefi, Coinbase | No page found in my searches | **Not mentioned (unverified).** My searches found no vendor documentation on 7702 authorizations for any of these. | No source; the gap is unknown |\n\nTurnkey is the only provider where I confirmed a documented, enforceable policy. Its own caveats say the policy engine has gaps:\n- The batch-deny rule \"blocks only `PAYLOAD_ENCODING_EIP7702_AUTHORIZATION`\".\n- \"A hexadecimal or UTF-8 payload can also be an authorization\".\n- \"The policy engine does not expose the authorization list of a Type 4 (EIP-7702) transaction.\"\n\n## 2. Public incidents since 2025-05-07\n\nI found one institutional drain through an EIP-7702 delegation.\n\n| Field | Binance 14 |\n|---|---|\n| Date | 2026-10-29. The delegation was included at 20:20:59 UTC in tx `0xad99264d…51298b`, and the sweep followed at about 20:24 UTC. |\n| Chain | Ethereum mainnet |\n| Wallet | `0x28C6c06298d514Db089934071355E5743bf21d60` (the question's address; I didn't check it against the press reports) |\n| Delegate address | **Unknown.** The FinanceFeeds and Cointelegraph articles don't give it. Blockaid describes it as an unverified sweeper contract. |\n| Other addresses | The sender was `0x7C8601d4645b93cea45F71e118A729332e6B5CA0`, and the receiver was `0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c`. |\n| Loss | Figures conflict: \"over $2.5 billion\" (Cointelegraph), about $3.3B (FinanceFeeds, with outflows up to $3.55B), and $2.8B and $5.8B in other outlets. 167,464 ETH plus 1.615B USDT and other tokens went out in the Binance 14 transfer. Tether and Circle froze about $1.8B. |\n| Root cause | **Unknown.** A delegation needs a signature from the wallet's own key. A stolen key, a manipulated signing system and inside access are all speculation. |\n\nSources: [FinanceFeeds](https://financefeeds.com/binance-hack-3-3b-hot-wallets-drained-tether-circle-freeze/) and [Cointelegraph](https://cointelegraph.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo). Blockaid says the attacker bundled 50 authorizations and that one matched the account's nonce. That is consistent with your nonce range, but the exact range 18914775 to 18914824 is from your question, and I found no source that confirms it.\n\nI found no other exchange, custodian or treasury drain through 7702 in these sources. The October 2026 cases (about $22.8K and $1.54M) were individual wallets. They were reported only by secondary news sites I did not read in full, so I don't treat them as institutional incidents.\n\n## 3. What a signing policy must inspect\n\n1. **The signed message and prefix.** The authorization is `keccak(0x05 || rlp([chain_id, address, nonce]))`, not a transaction ([EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)). A policy that matches only transaction fields will miss it. Raw-digest signing is the bypass route. Turnkey's guidance says a hex or UTF-8 payload can also be an authorization, so raw signing should be denied or restricted by encoding and hash function. Detection must therefore parse raw payloads for the 0x05 form, as Turnkey's `eth.eip_7702_authorization` keyword does.\n2. **`chain_id`.** The EIP says the field must be \"0 or the ID of the current chain\", and 0 makes the tuple valid on every chain. Turnkey's example denies `chain_id == 0`. The arXiv paper (arXiv 2512.12174) recommends that implementations \"forbid chainId = 0\".\n3. **The delegate `address`.** The EIP warns that \"The code specified by an authorization has unrestricted access to the account.\" Use an explicit allowlist of audited delegates (Turnkey's example, and Fireblocks's \"fully audited and trusted\"). Default to deny. The arXiv paper warns that attackers pick targets that \"resemble legitimate\" contracts, so match the exact checksummed address and not a label.\n4. **`nonce`.** A tuple is valid only if it equals the authority's current nonce, so a signer can't control which tuple lands. Binance 14 reportedly got 50 tuples with one matching. A policy should therefore:\n   - treat every tuple as a live signature;\n   - refuse batches and consecutive-nonce ranges;\n   - pin the nonce for one-off authorizations, as Turnkey's \"Allow one authorization only\" example does.\n   \n   The arXiv paper says nonce checks give weak containment across chains.\n5. **Authorization lists in Type 4 transactions.** The signature on each tuple authorizes the delegation, not the outer transaction. Turnkey's engine does not expose the list, so a Type 4 deny rule is the fallback, and it doesn't cover every Turnkey-built transaction. The arXiv paper also notes that wallets typically don't display the list.\n6. **Policy errors.** Per Turnkey's docs, a policy that errors does not match, so a deny rule that errors does not deny. Test deny rules.\n\n**Unknown:** whether most custodians' engines can inspect 7702 authorizations; which signing path produced the Binance 14 signatures; the delegate address; and the final loss.\n\n---\nSources offered but not confirmed by this machine:\n- https://eips.ethereum.org/EIPS/eip-7702 — does not contain the quoted text\n- https://eips.ethereum.org/EIPS/eip-7702 — does not contain the quoted text\n- https://docs.turnkey.com/features/policies/examples/ethereum — does not contain the quoted text\n- https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page\n- https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page\n- https://docs.dfns.co/api-reference/sign/evm — does not contain the quoted text\n- https://cointelegraph.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo — did not return a page\n- https://cointelegraph.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo — did not return a page","citations":[{"contentHash":"7fae5683149fe2f646149ee03ad39bd17b8f624277a92857b01bd0449bd13ef5","quote":"The policy engine does not expose the authorization list of a Type 4 (EIP-7702) transaction.","retrievedAt":"2026-10-30T01:15:02.323Z","url":"https://docs.turnkey.com/features/policies/examples/ethereum"},{"contentHash":"7fae5683149fe2f646149ee03ad39bd17b8f624277a92857b01bd0449bd13ef5","quote":"A hexadecimal or UTF-8 payload can also be an authorization","retrievedAt":"2026-10-30T01:15:02.422Z","url":"https://docs.turnkey.com/features/policies/examples/ethereum"},{"contentHash":"8054b89da4f02b76f48911e6d5fc580403a97dc96a43252f3a00893c0f6f1750","quote":"Privy provides methods to sign EIP-7702 authorizations","retrievedAt":"2026-10-30T01:15:02.910Z","url":"https://docs.privy.io/wallets/using-wallets/ethereum/sign-7702-authorization"},{"contentHash":"8c4b67fd5886fe1a50bf458506bbd6678024b6308354223ca0219738ba53bc00","quote":"Setting a delegation requires a valid signature from the wallet’s own private key.","retrievedAt":"2026-10-30T01:15:03.839Z","url":"https://financefeeds.com/binance-hack-3-3b-hot-wallets-drained-tether-circle-freeze/"},{"contentHash":"606f493808b09cce6368db04b1eb469d103cd6cc069fe6b13044aa19051d1b8b","quote":"implementations should forbid chainId = 0","retrievedAt":"2026-10-30T01:15:03.885Z","url":"https://arxiv.org/html/2512.12174v1"}],"device":"3711e7584237275d","id":"ecf4bb5b-e529-4d15-b2dd-ed7954a492f1","model":"claude-sonnet-5-5","nodeId":"1be26c53-c7fa-4fb0-ae23-d90e51cff3d2","runtime":"claude"},{"answer":"**A signing policy must control the authorization signature itself, across every signing API available to the key.** Blocking type-4 transactions alone does not stop delegation: another account can submit the signed authorization. Turnkey’s documentation expressly distinguishes these operations and warns about raw-signing bypasses. [Turnkey policy reference](https://docs.turnkey.com/features/policies/language)\n\nThe findings below reflect public sources checked on **2026-10-30**. “Not mentioned” means absent from the cited documentation, not proof that a provider lacks private controls. A documented capability also does not establish any particular customer’s configuration.\n\n**Provider documentation**\n\n| Provider / product covered | Mentions authorization signing? | Documented treatment and limits | Source and date |\n|---|---|---|---|\n| **Fireblocks — Vault Accounts** | Yes | **Refused for arbitrary delegation** in the cited support answer: customers cannot attach arbitrary contract code using `set_code`. This is a product restriction, not evidence that every raw-signing path rejects authorization digests. | [Official support response](https://community.fireblocks.com/t/eip-7702-set-code-with-fireblock-wallet/2928), **2025-09-17**; thread includes an unanswered update request dated 2026-04-14. |\n| **Turnkey** | Yes, explicitly | **Allowed under configurable policy.** Exposes authorization `address`, `chain_id`, and `nonce`; documents delegate/chain allowlists. Warns that rules on parsed authorizations do not cover every activity and that unrestricted hexadecimal/UTF-8 raw signing can still produce authorization signatures. | [Policy language, EIP-7702 section](https://docs.turnkey.com/features/policies/language), undated; checked **2026-10-30**. |\n| **DFNS** | Yes | **Allowed, subject to organizational permissions and policy checks.** Documents signing authorization tuples and sponsored flows checked for both sender and sponsor. The cited pages do not establish a universal mandatory human approval or blanket rejection of arbitrary delegation. | [Ethereum signing standards](https://dfns.co/article/ethereum), publication day unknown; [Fee Sponsors on EVM](https://dfns.co/article/fee-sponsor-on-evm), **2025-06-04**. |\n| **Fordefi — EVM vaults** | Yes, through its documented 7702 activation flow | **Allowed with approval in that flow:** activation requires a dedicated transaction and signing in the mobile app. Uses Ethereum Foundation’s `Simple7702Account`. This does not establish the treatment of every standalone authorization or raw-signing request. | [EVM Vaults](https://docs.fordefi.com/user-guide/vaults/evm-vaults), undated; checked **2026-10-30**. |\n| **Ripple Custody — Vault** | Yes, explicitly | **Allowed with approval.** `SetDelegation` signs the authorization after approval; `SubmitAuthorization` broadcasts it. Both use the standard intent approval flow, and policies can distinguish those operation types. | [Delegation procedure](https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api), undated; feature documented in [version 1.43](https://docs.ripple.com/products/custody/support/change-history/v143), **2026-10-05**. |\n| **Privy** | Yes, explicitly | **Allowed under configurable policy.** Supports authorization signing and any 7702 implementation; supplies an `eth_sign7702Authorization` policy example restricting the delegation `contract` to an allowlist. Mandatory human approval is not established by those pages. | [7702 integration](https://docs.privy.io/recipes/react/eip-7702), [authorization policy example](https://docs.privy.io/controls/policies/example-policies/ethereum), undated; checked **2026-10-30**. |\n| **Ledger — Ethereum device application** | Yes | **Refused by default; allowed after enabling the feature, with delegate restrictions.** Support documentation says “Smart account upgrade” is disabled by default. The rollout announcement permits only the Ethereum Foundation simple contract and blocks other contracts at device level. These statements concern the device application; equivalent Ledger Enterprise policy is **unknown**. | [Ethereum application settings](https://support.ledger.com/article/360009576554-zd), undated; [Pectra announcement](https://www.ledger.com/blog-pectra-upgrade-announcement), **2025-05-07**. |\n| **Alchemy — Wallet APIs / Smart Wallets** | Yes | **Allowed; enabled by default.** APIs prepare authorization payloads when delegation is needed; the application prompts for signing when required. Documents default and legacy delegate implementations. This is not evidence of a universal institutional approval quorum. | [How EIP-7702 works](https://www.alchemy.com/docs/wallets/transactions/using-eip-7702), undated; checked **2026-10-30**. |\n| **AWS — KMS signing backend** | **Not mentioned in cited signing API** | **Not mentioned.** Documents generic message/digest signing and `DIGEST` mode, rather than Ethereum authorization semantics. Authorization-specific rejection, delegate inspection, and nonce controls are **unknown** from this API reference. | [KMS `Sign`](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html), undated; checked **2026-10-30**. |\n| **Microsoft — Azure Key Vault signing backend** | **Not mentioned in cited signing API** | **Not mentioned.** API signs a digest using a specified key and requires `keys/sign` permission. The reference does not document 7702-specific parsing or refusal. | [Key Vault `sign`](https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01), API version **2025-07-01**; publication date unknown. |\n\nThese classifications apply only to the named product and documented route. For example, Fireblocks’ separate security article recommends restricting delegation to audited, trusted contracts; that recommendation alone does not demonstrate enforcement across its signing APIs. [Fireblocks, 2025-03-12](https://www.fireblocks.com/blog/security-first-approach-to-eip-7702)\n\n**Public incidents within the requested window**\n\nTwo cases below have sources connecting institutional or managed-vault losses to delegation of an account holding the relevant authority. This is a bounded finding, not a claim that no other cases exist.\n\n| Date / chain | Institution and affected wallet | Delegate | Loss and mechanism | Sources |\n|---|---|---|---|---|\n| **2026-01-06, 21:02 UTC — Arbitrum One** | **IPOR USDC Lending Optimizer**, drained vault `0xa91267a25939b2b0f046013fbf9597008f7f014b`; delegated administrator `0xd8a1087d6bbCd5533F819A4496a06AF452609b99` | `0xA3CCb120cD4CE39507eDB684d4Ed17aA7194F83c` | About **$336,000** taken. A vulnerable existing delegate allowed arbitrary calls as administrator; the attacker installed a malicious fuse and exploited missing vault validation. The project reports restoration of **336,580 USDC**, with the DAO covering the bounty and price difference; no depositor ultimately lost funds. This was an administrator-delegation compromise, not a direct sweep of the administrator’s balance. | [Project post-mortem, 2026-01-07](https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html); [Arbiscan transaction identifies administrator and delegate](https://arbiscan.io/tx/0x238b4e619158432ff5ceb279cfea38007d048af4f59901c7af2efcf32e9671b6); [Blockaid corroboration](https://blockaid.io/blog/blockaid-partners-with-ipor-fusion-to-bring-onchain-threat-monitoring-to-its-vault-ecosystem). |\n| **2026-10-29 — Ethereum mainnet** | **Binance 14**, `0x28C6c06298d514Db089934071355E5743bf21d60` | `0x63e842B054Bd624a465454D533C33F573e9c6fAe` | Blockaid reports an initial sweep worth approximately **$2.5 billion**, following delegation at **20:20:59 UTC** through the stated transaction and 50 signed authorizations covering **18,914,775–18,914,824**. Its delegate also supported forwarding calls. The total multichain incident estimate must not be treated as the amount stolen through this one delegation. | [Blockaid investigation, 2026-10-29](https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history); [separate transaction-by-transaction account, 2026-10-29](https://blog.nexuspool.io/binance-hack-what-miners-should-check/); [Cointelegraph reporting, 2026-10-30](https://ct.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo). |\n\nFor Binance, **the signing-path root cause and provider attribution remain unknown**. Cointelegraph reports that the precise method was unconfirmed and quotes Arkham saying the available information could not distinguish stolen keys from compromised infrastructure. Fifty valid signatures establish access to signing capability; they do not identify which custody vendor, MPC system, HSM, person, or compromised component produced them. [Cointelegraph](https://ct.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo)\n\nThere are important exclusions:\n\n- **Retail phishing is not evidence of institutional loss.** SlowMist describes a May 24, 2025 victim losing $146,551 through abuse involving an existing MetaMask delegation, but does not identify that victim as an institution. [SlowMist H1 2025 report](https://www.slowmist.com/report/SlowMist-first-half-of-the-2025-report%28EN%29.pdf)\n- **An attacker using its own delegated account is a different mechanism.** SubQuery’s disclosure says its TX3 used attacker-self-authorized 7702 code morphing, without phishing or key compromise. It does not establish unwanted delegation of an institutional signing key. [SubQuery disclosure](https://subquery.ghost.io/subquery-network-security-incident-report/?lng=en)\n\n**What the signing policy must inspect**\n\nThe following refusal design is a synthesis of the specification and the documented controls above, rather than a claim that every provider implements it.\n\n1. **Recognize the signing domain before hashing.** Parse `0x05 || rlp([chain_id, address, nonce])` and recompute its Keccak-256 digest inside the trusted policy/signing boundary. The outer transaction’s type byte is `0x04`; checking that alone misses authorization signing. Reject malformed or unrecognized inputs. [EIP-7702 specification](https://eips.ethereum.org/EIPS/eip-7702)\n\n2. **Close opaque-signing routes.** A 32-byte digest does not reveal its preimage or a visible `0x05` prefix. Require a verified preimage and semantic checks, or refuse opaque digest signing for the protected key. Cover single and batch APIs, hexadecimal/text payloads, and SDK adapters. Turnkey specifically warns that authorization-field policies cannot constrain every raw-signing route; AWS and Azure document digest-signing interfaces. [Turnkey](https://docs.turnkey.com/features/policies/language), [AWS](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html), [Azure](https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01)\n\n3. **Inspect the authorization’s own `chain_id`.** Require an explicitly approved chain. Treat **`0` as universal scope**, not an absent value or Ethereum-mainnet identifier: it can authorize delegation on every supporting chain, subject to that chain’s other validity checks. Reject it unless cross-chain authority is expressly intended. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), [Nethereum’s universal versus chain-specific explanation](https://docs.nethereum.com/docs/core-foundation/guide-eip7702/)\n\n4. **Inspect the delegate address and implementation.** Use an allowlist of audited implementations per chain, with a separately authorized zero-address revocation path. Review initialization, caller authorization, dependencies, and upgradeability. Address matching alone cannot establish code safety; IPOR demonstrates the consequence of a vulnerable delegate. [Ethereum wallet guidance](https://ethereum.org/roadmap/pectra/7702), [Fireblocks security analysis](https://www.fireblocks.com/blog/security-first-approach-to-eip-7702), [IPOR post-mortem](https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html)\n\n5. **Inspect nonce scope and aggregate issuance.** Bind approval to the intended authority, delegate, chain, and exact nonce. Account for the sender’s nonce increment when it also submits the transaction. Reject unsolicited future-nonce ranges and detect consecutive requests across API calls. These are defensive recommendations: the protocol checks equality, increments the authority nonce, and processes tuples sequentially; it does **not** guarantee that only one authorization in a list takes effect. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)\n\n6. **Approve delegation as a persistent authority change.** Show the account, chain scope, delegate, and nonce explicitly. Do not classify it as harmless because it moves zero assets. Ripple documents zero-amount authorization orders and separate approval stages; Ethereum’s guidance emphasizes that the underlying EOA key retains authority despite delegated wallet logic. [Ripple delegation procedure](https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api), [Ethereum guidance](https://ethereum.org/roadmap/pectra/7702)\n\nFor a wallet that must never delegate, the resulting rule is straightforward: **deny authorization signing and every alternative route capable of signing the same digest**. For a wallet that needs delegation, permit only explicitly approved authorization tuples through a parsed, enforced signing path. [Turnkey’s documented restrictions and bypass analysis](https://docs.turnkey.com/features/policies/language)\n\n---\nSources offered but not confirmed by this machine:\n- https://community.fireblocks.com/t/eip-7702-set-code-with-fireblock-wallet/2928 — does not contain the quoted text\n- https://support.ledger.com/article/360009576554-zd — does not contain the quoted text\n- https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html — did not return a page\n- https://ct.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo — did not return a page","citations":[{"contentHash":"0cf10badb654d51ca50542fa200146cd4d8624a7455cdbeac6586caf512f0d8e","quote":"No policy can stop a key that signs these payloads from signing an authorization.","retrievedAt":"2026-10-30T01:16:30.935Z","url":"https://docs.turnkey.com/features/policies/language"},{"contentHash":"d73d1fffad5e1d4395688cef446894e5f44a9b4f7af56b9ffb570ba687589560","quote":"The transaction only proceeds if both the sponsor and sender are properly authorized through policy checks.","retrievedAt":"2026-10-30T01:16:31.433Z","url":"https://dfns.co/article/fee-sponsor-on-evm"},{"contentHash":"a9c916cd9a32a1add8e12565054699aaec75a5f447a63004453fa911f6be90d4","quote":"To complete the activation process, sign the transaction in your mobile app.","retrievedAt":"2026-10-30T01:16:31.612Z","url":"https://docs.fordefi.com/user-guide/vaults/evm-vaults"},{"contentHash":"80b42c3219e127457b30b703df83c9b0eeda0f0c74e37d00f93977d3027884bd","quote":"Both orders go through the standard intent approval flow.","retrievedAt":"2026-10-30T01:16:31.806Z","url":"https://docs.ripple.com/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api"},{"contentHash":"4ccb9293d7a8dda54b605d8e1f77ac0ced0adae47c0b7d2f6cff38dbb1150886","quote":"Restrict the delegation contract for EIP-7702","retrievedAt":"2026-10-30T01:16:31.988Z","url":"https://docs.privy.io/controls/policies/example-policies/ethereum"},{"contentHash":"844138f85ab23f1f88693707d1dcfa7b6368485c53c3a9e5eeae70d935a1d2d6","quote":"Until then, all other contracts using 7702 will be blocked at the device level.","retrievedAt":"2026-10-30T01:16:32.545Z","url":"https://www.ledger.com/blog-pectra-upgrade-announcement"},{"contentHash":"5fde49c541b646f9d60926dce6eeeccaf98766b8253deddc9a83ac68e1c7ab57","quote":"Your application prompts for signing when required","retrievedAt":"2026-10-30T01:16:32.791Z","url":"https://www.alchemy.com/docs/wallets/transactions/using-eip-7702"},{"contentHash":"6cc09e6889969b5460de17bd181b44f496329ee20c803b913d269fd5a3a0930b","quote":"Creates a signature from a digest using the specified key.","retrievedAt":"2026-10-30T01:16:33.146Z","url":"https://learn.microsoft.com/en-us/rest/api/keyvault/keys/sign/sign?view=rest-keyvault-keys-2025-07-01"},{"contentHash":"4c23240c83f42395002d4955a69a32f2dd012117ca9ac260683a404788891628","quote":"No depositor lost funds.","retrievedAt":"2026-10-30T01:16:33.261Z","url":"https://ipor.io/news/post-mortem-ipor-usdc-optimizer-arbitrum-vault-exploit-aff11fd01b62.html"},{"contentHash":"05b1830bfa2fd9f1fd4416377a5d16022905f9a838e77970489632e3fd778b80","quote":"0xA3CCb120cD4CE39507eDB684d4Ed17aA7194F83c","retrievedAt":"2026-10-30T01:16:33.521Z","url":"https://arbiscan.io/tx/0x238b4e619158432ff5ceb279cfea38007d048af4f59901c7af2efcf32e9671b6"},{"contentHash":"f111a5a4913d14776d41119d8d3cf4efb10083db0db50103d9c93434a6b2b9ad","quote":"The Nonce Spray: 50 Authorizations, One Hit","retrievedAt":"2026-10-30T01:16:33.701Z","url":"https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history"},{"contentHash":"969327b24d7d10fec0e056dc943290d26bd86574a4ac1f999737e96a2059496d","quote":"Verify the chain ID is 0 or the ID of the current chain.","retrievedAt":"2026-10-30T01:16:34.124Z","url":"https://eips.ethereum.org/EIPS/eip-7702"},{"contentHash":"47cf7426dda8b09441a9c88413e2702461fb4c6cc0694d8f25a32e3e5af8283b","quote":"The authorization is valid on any chain.","retrievedAt":"2026-10-30T01:16:34.259Z","url":"https://docs.nethereum.com/docs/core-foundation/guide-eip7702/"},{"contentHash":"5717f15ed645d658a0ec9810b30f3161a7fd713a365fce4c399f8a23fc5698fa","quote":"No phishing or key compromise occurred – the attacker self-authorized the morph.","retrievedAt":"2026-10-30T01:16:34.402Z","url":"https://subquery.ghost.io/subquery-network-security-incident-report/?lng=en"}],"device":"35eaae2310a66c78","id":"eeb35d24-a372-491e-9bda-9298857cdffa","model":null,"nodeId":"1be26c53-c7fa-4fb0-ae23-d90e51cff3d2","runtime":"codex"}],"schema":"identitymd-work-v1","signals":[],"site":null,"snapshotHash":"0852f83ee9649cd019c04575c10d34258010b023924c68c0c834793875418d63","state":"completed","submissions":[],"verification":[]}