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.

1. Provider documentation on EIP-7702 authorizations

Provider	Mentions 7702?	Documented policy	Source (date)
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 (undated)
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 (2025-03-12); Mutualism, MPC, and EIP-7702 (2025-05-07)
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? (2026-10-21)
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 (undated)
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
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.

Wintermute'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, 2025-06-02).

2. Public incidents since 2025-05-07

• Binance 14 hot wallet, 2026-10-29, Ethereum.
  • Wallet: 0x28C6c06298d514Db089934071355E5743bf21d60.
  • Delegate: the article gives it only as truncated, 0x63e842B0…, or 0x63e8…6fAe in the timeline. I could not verify the full address.
  • 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.
  • The delegation transaction is the one in your question (20:20:59 UTC). The sweep transaction is 0x53bd38b8…e2f3 at 20:24:23 UTC.
  • Source: CryptoTicker. 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.
  • Other outlets reported the loss as high as $5.8B. These figures conflict and I did not verify them.
• IPOR USDC Optimizer vault, 2026-01-06, Arbitrum. This is a protocol administrator account, not an exchange or custodian, so it is borderline.
  • 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.
  • Vault: 0xa91267a25939b2b0f046013fbf9597008f7f014b.
  • Attacker: 0x9b1bd925a752cca6a28a27ec1058cf06b6434cee.
  • The administrator and delegate addresses are truncated in the source.
  • Loss: about $336K, fully restored.
  • Source: IPOR post-mortem, dated 2026-01-07.
• 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.
  • Attacker: 0xC4574DDEF299e7E563971e200433e592EeaaFA69.
  • Primary locker: 0xEb3a9C56d963b971d320f889bE2fb8B59853e449.
  • The attacker's delegate addresses are not listed.
  • Loss: $7.3M drained, with more reported at risk.
  • Source: Rekt.
• 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.

I found no other verified case of an exchange or custodian drained through 7702.

3. What a signing policy must inspect

• Message type and prefix. The signed digest is keccak(MAGIC || rlp([chain_id, address, nonce])), where MAGIC is 0x05 (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.
• 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.
• 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.
• 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.
• 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.

Unknown:

• How the Binance signature was produced.
• Whether Binance's signing stack could sign a 7702 authorization at all.
• Any first-party policy statement from BitGo, Anchorage, Copper, Dfns, Cobo or any HSM vendor.
• The full Binance delegate address.
• Whether the two borderline incidents involved signing-path failures.

---

Sources offered but not confirmed by this machine:

• https://eips.ethereum.org/EIPS/eip-7702 — does not contain the quoted text
• https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page
• https://www.fireblocks.com/blog/eip-7702-mpc-wallets-smart-account-abstraction — did not return a page
• https://cryptoticker.io/en/binance-hack-hot-wallet-drained/ — did not return a page
• https://cointelegraph.com/news/wintermute-crimeenjoyor-flags-malicious-ethereum-contracts — did not return a page

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.

1. Provider policy table

Provider	Mentions 7702 authorizations?	Documented policy	Source (date)
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 (undated page, read 2026-10-30)
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 (12 Mar 2025)
Privy	Yes	Allowed. The docs describe a signing method for authorizations and say nothing about policy or allowlisting of delegates.	Privy sign-7702-authorization (undated)
Dfns	Yes	Allowed as a signing kind. The page says nothing about policy.	Dfns EVM signing (undated)
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 (undated; from search result only)
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

Turnkey is the only provider where I confirmed a documented, enforceable policy. Its own caveats say the policy engine has gaps:

• The batch-deny rule "blocks only PAYLOAD_ENCODING_EIP7702_AUTHORIZATION".
• "A hexadecimal or UTF-8 payload can also be an authorization".
• "The policy engine does not expose the authorization list of a Type 4 (EIP-7702) transaction."

2. Public incidents since 2025-05-07

I found one institutional drain through an EIP-7702 delegation.

Field	Binance 14
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.
Chain	Ethereum mainnet
Wallet	0x28C6c06298d514Db089934071355E5743bf21d60 (the question's address; I didn't check it against the press reports)
Delegate address	Unknown. The FinanceFeeds and Cointelegraph articles don't give it. Blockaid describes it as an unverified sweeper contract.
Other addresses	The sender was 0x7C8601d4645b93cea45F71e118A729332e6B5CA0, and the receiver was 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c.
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.
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.

Sources: FinanceFeeds and Cointelegraph. 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.

I 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.

3. What a signing policy must inspect

1. The signed message and prefix. The authorization is keccak(0x05 || rlp([chain_id, address, nonce])), not a transaction (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.

2. 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".

3. 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.

4. 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:

   • treat every tuple as a live signature;
   • refuse batches and consecutive-nonce ranges;
   • pin the nonce for one-off authorizations, as Turnkey's "Allow one authorization only" example does.

   The arXiv paper says nonce checks give weak containment across chains.

5. 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.

6. 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.

Unknown: whether most custodians' engines can inspect 7702 authorizations; which signing path produced the Binance 14 signatures; the delegate address; and the final loss.

---

Sources offered but not confirmed by this machine:

• https://eips.ethereum.org/EIPS/eip-7702 — does not contain the quoted text
• https://eips.ethereum.org/EIPS/eip-7702 — does not contain the quoted text
• https://docs.turnkey.com/features/policies/examples/ethereum — does not contain the quoted text
• https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page
• https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page
• https://docs.dfns.co/api-reference/sign/evm — does not contain the quoted text
• https://cointelegraph.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo — did not return a page
• https://cointelegraph.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo — did not return a page

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, EIP-7702

This 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.

Provider documentation

“Allowed” below means a documented supported signing path, potentially subject to customer policies—not unconditional permission.

Provider / product	Mentions EIP-7702 authorizations?	Documented treatment and limits	Source and date
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, 17 September 2025; raw-signing documentation, undated. A later thread question does not establish a changed policy.
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, undated; release notes, feature announced 11 January 2026.
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, v1.43 LTS, publication date unstated.
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, undated legacy reference.
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, undated.
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, undated.
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, undated.
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, undated; Ledger policy announcement, 7 May 2025; hardware integration description, 9 May 2025.
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, undated.
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, API version 2025-07-01; publication date unstated.
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, publication date not independently established from the retrieved text.

Fireblocks’ 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

Public incidents since 7 May 2025

The 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.

Date	Chain	Institutional wallet / account	Delegate address	Loss or outflow; evidentiary status	Sources
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, including linked transactions.
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; ZachXBT investigation; subsequent non-social reporting, 21 October.
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; Cryptovka, 21 October 2026.
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; FinanceFeeds reporting; The Defiant report syndicated by CryptoNews.

For 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, reporting on the unresolved signing mechanism

These 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

What a signing policy must inspect

The following are engineering requirements inferred from the protocol and the documented signing-path limitations:

1. 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

2. 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, AWS digest-signing API

3. 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, Ethereum wallet guidelines

4. 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, Alchemy’s concrete allowlist

5. 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

6. 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, IPOR postmortem

For 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, Azure’s digest-signing interface

---

Sources offered but not confirmed by this machine:

• https://community.fireblocks.com/t/eip-7702-set-code-with-fireblock-wallet/2928 — does not contain the quoted text

• 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

• https://docs.privy.io/controls/policies/overview — does not contain the quoted text

• https://support.ledger.com/article/360009576554-zd — does not contain the quoted text

• https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html — did not return a page

• 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

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

The 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.

Provider documentation

Provider / product covered	Mentions authorization signing?	Documented treatment and limits	Source and date
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, 2025-09-17; thread includes an unanswered update request dated 2026-04-14.
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, undated; checked 2026-10-30.
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, publication day unknown; Fee Sponsors on EVM, 2025-06-04.
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, undated; checked 2026-10-30.
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, undated; feature documented in version 1.43, 2026-10-05.
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, authorization policy example, undated; checked 2026-10-30.
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, undated; Pectra announcement, 2025-05-07.
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, undated; checked 2026-10-30.
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, undated; checked 2026-10-30.
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, API version 2025-07-01; publication date unknown.

These 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

Public incidents within the requested window

Two 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.

Date / chain	Institution and affected wallet	Delegate	Loss and mechanism	Sources
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; Arbiscan transaction identifies administrator and delegate; Blockaid corroboration.
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; separate transaction-by-transaction account, 2026-10-29; Cointelegraph reporting, 2026-10-30.

For 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

There are important exclusions:

• 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
• 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

What the signing policy must inspect

The following refusal design is a synthesis of the specification and the documented controls above, rather than a claim that every provider implements it.

1. 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

2. 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, AWS, Azure

3. 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, Nethereum’s universal versus chain-specific explanation

4. 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, Fireblocks security analysis, IPOR post-mortem

5. 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

6. 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, Ethereum guidance

For 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

---

Sources offered but not confirmed by this machine:

• https://community.fireblocks.com/t/eip-7702-set-code-with-fireblock-wallet/2928 — does not contain the quoted text
• https://support.ledger.com/article/360009576554-zd — does not contain the quoted text
• https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html — did not return a page
• https://ct.com/news/binance-hack-may-involve-private-key-misuse-not-theft-blockaid-ceo — did not return a page

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

The 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

This 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.

Provider / product	Mentions EIP-7702 authorizations?	Documented treatment and limits	Source and date
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, undated
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, undated
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, undated; v1.43 release, 2026-10-05
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, undated; Fee Sponsors on EVM, 2025-06-04
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, undated
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, 2025-03-12; Sign Raw Messages, undated
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, undated
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?, undated; page retains pre-mainnet wording
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, updated 2026-09-07; SKA authorization policy, updated 2026-10-12
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, undated
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, 2026-10-29

None 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, Securosys SKA, Turnkey policy language

The public incident evidence since 2025-05-07 falls into different confidence and mechanism categories:

Incident date	Chain; institution / scope	Wallet address	Delegate address	Loss and evidence
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, drk transaction analysis, Oct 30
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
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, KuCoin/MarsBit, Oct 21
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, Lookonchain follow-up
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

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.

Two related cases should not silently inflate the direct institutional-wallet-drain list:

• 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
• 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

What the signing policy must inspect

The following is an engineering conclusion from the protocol and provider documentation, not a claim that every provider implements it.

1. 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

2. 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, Turnkey policy language

3. 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, Ethereum’s Pectra guidance

4. 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, Turnkey policy language

5. 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

   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

6. 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, Fireblocks security guidance

For 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, Cointribune on the unknown signature origin

---

Sources offered but not confirmed by this machine:

• https://docs.privy.io/controls/policies/overview — does not contain the quoted text
• https://docs.ripple.com/products/custody/support/change-history/v143 — does not contain the quoted text
• https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page
• https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html — did not return a page
• https://lookonchain.com/feeds/77968 — did not return a page
• https://thatsrekt.com/ — does not contain the quoted text
• https://hacken.io/insights/gana-payment-hack-explained/ — did not return a page

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

The 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, The Defiant

This 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.

Provider / product	Explicitly mentions EIP-7702 authorizations?	Documented treatment and limits	Source and date
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, n.d.
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, delegation restriction example, n.d.
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, n.d.; v1.43 release, 2026-10-05
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, n.d.; release notes, version 100, 2026-01-11
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, n.d.; gas sponsorship, 2025-06-04; signing policies, updated 2026-10-23
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, 2025-03-12; gasless launch, 2025-05-23; raw-signing controls, n.d.
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, API guide, n.d.
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, n.d.
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, n.d.
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, n.d.
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, n.d.
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, API version 2025-07-01; publication date unknown

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, Universal Gasless

The 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.

Date / chain	Institutional wallet or account	Delegate address	Reported loss and evidence status
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; Arbiscan transaction identifying administrator and delegate.
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; ChainCatcher, Oct 10; ZachXBT’s addresses and linkage.
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; CoinNess; original address disclosure.
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; drk, Oct 30; The Defiant.

For 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

I 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, OpenZeppelin incident analysis

A 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.

1. 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, Ethereum’s implementation guidelines

2. 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, AWS, Azure

3. 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, ERC-7902

4. 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, Privy policy example

5. 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

6. 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, Ripple delegation lifecycle

The 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

---

Sources offered but not confirmed by this machine:

• https://docs.privy.io/controls/policies/overview — does not contain the quoted text
• https://www.fireblocks.com/blog/security-first-approach-to-eip-7702 — did not return a page
• https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html — did not return a page
• https://arbiscan.io/tx/0x238b4e619158432ff5ceb279cfea38007d048af4f59901c7af2efcf32e9671b6 — did not return a page
• https://www.lookonchain.com/feeds/77968 — did not return a page
• https://thedefiant.io/news/security/3-55-million-in-unclaimed-bridge-funds-moved-via-eip-7702 — did not return a page
• https://blockaid.io/blog/binance-55b-hack-using-advanced-ai-models-blockaid-detects-the-biggest-theft-in-crypto-history — did not return a page