The $6.36 Billion Theft That Didn't Need Anything New

On the evening of October 29, 2026, something began moving out of Binance.

Not a bug being exploited. Not a bridge being drained, not a phishing campaign, not a compromised validator. Ten unrelated blockchains, ten different key types, ten different signing schemes — and within about twenty minutes, every one of them was paying out to the same adversary.

The total taken is estimated at $6.36 billion. That is more than four times the $1.5 billion pulled from Bybit in February 2025, which was itself the largest theft on record at the time. Bybit was a single signature on a single multisig. This was something else.

We worked the chain data ourselves rather than working from the press coverage, and the XRP Ledger leg turned out to be the interesting part. It is also the leg where the published reporting is wrong.

The shape of it

A single attacker address on Ethereum, 0x7C8601d4645b93cea45F71e118A729332e6B5CA0, received three small withdrawals from Tornado Cash on the morning of October 28. That is the only public trace of preparation visible on-chain, and it matches a familiar pattern: a North Korean unit the FBI calls TraderTraitor, the same group TRM Labs attributes to the Bybit heist and an April 2026 theft called the KelpDAO hack.

At 15:59:11 UTC on October 29, the operator deployed a contract, 0x63e842B054Bd624a465454D533C33F573e9c6fAe — unverified source, names the operator as its only authorized caller, and carries a function that moves every token and the account's ETH to a recipient. We confirmed the deployment independently: it was created in block 26299449, and the address the transaction produced is the sweeper address. The attacker then rehearsed the entire attack on three wallets it controlled, moving two to six dollars each time, before pointing it at anything of value.

Four hours later, the theft began.

The nonce spray

The first thing the attacker did was not move money. It was prepare a signature.

At 20:20:59 UTC, the operator sent one Ethereum type-0x4 transaction to Binance's hot wallet 0x28C6c06298d514Db089934071355E5743bf21d60 — one of the most recognizable addresses in crypto. The transaction carried 50 EIP-7702 authorizations, each signed by Binance's own key, each delegating the wallet to the sweeper contract, each tied to a different nonce:


authorizationList entries: 50

nonce range:              18,914,775 .. 18,914,824

delegation target:        0x63e842b054bd624a465454d533c33f573e9c6fae

chainId:                  0x1  (all 50)

EIP-7702, live on Ethereum since the Pectra upgrade on 7 May 2025, lets an ordinary wallet hand its behavior to a smart contract. The authorization only lands if its nonce matches the account's nonce at the moment it executes — and Binance's hot wallet was processing customer withdrawals continuously, so its nonce was always moving. The attacker signed a window of 50 consecutive nonces in advance and let the chain pick the one that hit.

Forty-nine did not apply. One did. And the delegation persisted.

That is the detail that makes this attack different in kind from every previous one. Before EIP-7702, a stolen hot-wallet key started a race: the attacker had to sign each theft while the exchange could still move the balance away, and once the exchange rotated to new addresses the key was worthless. A key that can sign a delegation is not a race. It is standing infrastructure. The address effectively becomes a program the attacker owns, and it keeps owning it after the key is burned. Rotating keys does not clear it, because the delegation belongs to the address, not the key. Only one more signature from the compromised key — pointing at the zero address — resets it.

The sweep

The delegation transaction itself is 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b (block 26300753) — verifiable on any Ethereum explorer.

At 20:24:23 UTC, three minutes and twenty-four seconds later, the operator called sweep. The sweep transaction is 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3. One transaction moved 167,464.24785655882 ETH and 63 different ERC-20 tokens — including 1,615,409,498.97 USDT — to a collection address with no prior history, 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c. Binance's wallet was left holding exactly one ETH.

We pulled the receipt and counted the events ourselves: 63 ERC-20 Transfer events plus one native ETH transfer, all 63 ERC-20s going to the same single destination, and the USDT figure matching to the cent. A trace of the same transaction confirms the ETH movement: 167,464.24785655882 ETH, to the cent of the published figure.

Twenty-four seconds later, a different Binance wallet on Ethereum, 0xDFd5293D8e347dFe59E90eFd55b2956a1343963d, sent 28,005.6 ETH, 55.7 million USDT, 25.9 million RLUSD and 84.5 WBTC to the same collection address. No delegation involved — an ordinary transfer, signed by that wallet's own key. We found that transaction at block 26300772, timestamped 20:24:47 UTC, with the ETH amount matching exactly.

Within twelve minutes: 44.2 million OP from Optimism, 74.6 million ARB and 8,426 ETH from four Arbitrum wallets, 1.81 million AVAX and 8.41 million USDT from four Avalanche wallets.

Then, on the XRP Ledger, five more Binance wallets were emptied. On Tron, another. On Solana, another. On Bitcoin, 18,270.

The standing drain

The delegation stayed live, and the attacker kept coming back. Binance's delegated wallet was swept at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 UTC — each time taking whatever had arrived since the last sweep, without any further signature. We located all six and confirmed the timestamps. The same delegated wallet also served as the executor for a separate Binance smart account, pulling 823 million USDC out of it at 20:41 — in two movements, 780 million at 20:41:23 and 43 million moments later.

The delegation was finally revoked at 00:10:35 UTC on October 30, in a single type-0x4 transaction, 0xafbf94c92a8d749988411669fa14d4f8866d9b4420b4ebd299f28e958dac7209, pointing Binance's wallet at the zero address. We read the authorization list on that transaction: exactly one entry, and its address is all zeros. That is three hours and forty-nine minutes after the delegation was installed — and roughly half of that window was spent with the drain still live.

Why this one is different

Three things, and they compound.

It was not one chain. Eleven Binance hot-wallet keys across ten blockchains produced valid attacker-directed signatures within about half an hour. Different chains, different key types, different signing schemes, same outcome. No single compromised contract explains that. The natural explanation is control of the signing layer itself — and Binance has not published a root cause.

It was not one signature either. The nonce spray works because the hot wallet is busy. An address that signs one transaction a day is trivially protected by nonce discipline. An address that signs thousands of withdrawals a day cannot be. The attacker did not need to guess a nonce or wait for a lucky moment; they needed to be willing to prepare fifty signatures and send them in one transaction, which is exactly what a signing system that accepts a batch of requests will happily do.

The delegation changed what a transfer can mean. A wallet that has delegated its code can authorize later transfers without another signature. In the space of four hours, one address became both a vault and a standing withdrawal authorization — and the exchange's own routine withdrawal traffic kept feeding it.

Where the money went

Ethereum — $3.79B

The single sweep transaction moved 63 tokens. The largest positions:

Token	Contract	Amount
USDT	`0xdac17f958d2…`	1,615,409,498.97
RLUSD	`0x8292bb45bf1…`	62,597,239.68
USDe	`0x4c9edd5852cd…`	9,707,546.77
USD1	`0x8d0d000ee449…`	27,760,801.82
UNI	`0x1f9840a85d5…`	6,189,795.75
wBETH	`0xa2e335661084…`	29,934.01
XAUt	`0x68749665ff8d…`	11,372.47
PAXG	`0x45804880de22…`	1,898.47
ONDO	`0xfaba6f8e4a5e…`	21,844,883.66
WLD	`0x163f8c246792…`	17,317,869.01
(+ 53 more tokens)

Notice the composition. The stablecoins — USDT, RLUSD, USDe, USD1, FDUSD — are all issuer-reachable, and therefore freezable. The ones that are not issuer-reachable — wBETH, XAUt, PAXG — are exactly what an attacker wants to be holding. The basket was a read on what could not be clawed back.

Bitcoin — $1.47B

TRM Labs reports that at 20:20 UTC a Binance Bitcoin hot wallet sent 18,270 BTC to an attacker address, which immediately began breaking the total into round 1,000 BTC and 100 BTC chunks inside the same block. That is a peel chain, and its purpose is not speed but obscurity: each layer exists to break the trail. We did not re-derive this leg against a Bitcoin node — it is TRM's account, and we have kept it as reported rather than dressing it up as something we checked.

Tron — $628M

TRM Labs reports 612.7 million USDT and 46.4 million TRX, the latter moved within two minutes of the Bitcoin transfer. Like the Bitcoin leg, this one is reported rather than re-derived here.

The XRP Ledger — $296M

This is the leg we traced ourselves, end to end, and it is the one that behaves differently from all the others.

The XRP Ledger leg: 233 million XRP, and a transfer that failed

TRM Labs reports that five Binance wallets on the XRP Ledger sent 233.46 million XRP to a single attacker address between 20:05 and 20:09 UTC on October 29 — the first chain hit, before the EIP-7702 delegation even landed.

We traced that independently against a full-history XRPL node. One note on attribution before the details: TRM does not publish the XRP Ledger addresses in its report, so the identification of these five wallets as Binance's is TRM's attribution, and we could not confirm it from the ledger alone — exchange hot wallets carry no public label on XRP Ledger the way a domain field would label a business account. What the ledger does show is that five wallets emptied themselves into a single new address inside four minutes, and that one of them sent 42.75 million RLUSD to that same address eight seconds earlier and failed. The attacker address is:


rK21t6nGLy4MNDqhvy3pGwcLFy25qgfzMx

It has eleven transactions in its entire existence. Ten inbound payments and one CheckCreate. That is the whole history — and not one of the eleven is outbound.

Time (UTC)	From	XRP
20:05:00	`rDAE53VfMvftPB4ogpWGWvzkQxfht6JPxr`	185,017,485.50
20:07:00	`rBtttd61FExHC68vsZ8dqmS3DfjFEceA1A`	14,693,052.50
20:08:20	`rfQ9EcLkU6WnNmkS3EwUkFeXeN47Rk8Cvi`	13,140,680.40
20:08:50	`rarG6FaeYhnzSKSS5EEPofo4gFsPn2bZKk`	11,955,157.60
20:09:20	`rNU4eAowPuixS5ZCWaRL72UUeKgxcKExpK`	8,655,567.10
	(5 dust payments of 10 drops each — 0.00001 XRP)	0.00005


TOTAL IN:  233,461,943.100050 XRP

TOTAL OUT: 0.00 XRP

TRM reported 233.46 million. The ledger says 233,461,943.100050.

The three smaller sending wallets now hold 9.997 XRP each — the XRPL minimum reserve, to the drop. The hub wallet holds 12.994, but that number is a snapshot of a working exchange wallet, not a residue: it kept taking payments and paying withdrawals for hours afterward. The three were emptied to the bone and stayed there.

And not one XRP has moved since. On every other chain the attacker was converting into assets issuers cannot freeze. On the XRP Ledger, the entire 233 million is still sitting on the attacker's address. Not sold, not swapped, not bridged, not deposited.

The transfer that failed

Eight seconds before the XRP landed, the same Binance wallet attempted to send 42,750,000.10 RLUSD to the same attacker address. It failed:


hash:   AE08D54F8E7B05473AD5A1E3BF2C1D76A818B119DFBD3396C9C9F7BC7EF55A59

time:   2026-10-29 20:04:52 UTC

from:   rDAE53VfMvftPB4ogpWGWvzkQxfht6JPxr

to:     rK21t6nGLy4MNDqhvy3pGwcLFy25qgfzMx

result: tecNO_DST

tecNO_DST means no destination trust line. On the XRP Ledger, sending an issued token to an address requires that address to already hold a trust line for the issuer. The issuer in question was rMxCKbEDwqr76QuheSUMdEGf4B9xJ8m5De — RLUSD, whose account domain field decodes to https://ripple.com/. The attacker had not set one up. The ledger rejected the transfer.

Three independent signals confirm it, and each is worth stating because this kind of thing is easy to misread:

The transaction's result code is tecNO_DST, and the only ledger node it modified is the sender's account — the fee. No trust line was created.
The transaction does not appear in the attacker's history at all, only the sender's. A successful payment appears in both.
The attacker address has no RLUSD trust line, then or now. We asked the node directly and got an empty line list back.

So the answer to an obvious question — why would an attacker want a clawback-able stablecoin? — turns out to be: on the XRP Ledger they never got one.

Compare the same attacker on Ethereum, where they did hold 88.5 million RLUSD. According to TRM Labs, roughly half of that moved through a couple of intermediate wallets and was sold on decentralized exchanges in a nineteen-minute window running from 21:42 to 22:01 UTC, with Ripple freezing what remained — 40.5 million — moments later. Nineteen minutes of freedom. On the XRP Ledger, the equivalent transfer never executed at all.

That is the asymmetry worth noticing. The XRP Ledger's requirement for a pre-existing trust line — a piece of friction that looks like a formality from a distance — was enough to stop a 42.75 million dollar stablecoin transfer that a low-friction chain let through in seconds. In the same seconds, on the same chain, the same attacker took 233 million XRP without trouble.

One more line, because it shows what the freeze mechanics actually look like on the ledger. The Binance XRPL wallet still carries 14,196,082.04 SOLO, on a trust line set to no_ripple: true and limit_peer: 0 — the holder cannot send it onward. It is pinned in place.

One caution about how that line is often read. no_ripple and limit_peer are not freeze indicators; the real freeze bits are lsfLowFreeze and lsfHighFreeze, and neither is set on this line. The issuer here, rsoLo2S1kiGeCcn6hCUXVrCpGMWLrRrLZz, carries lsfNoFreeze — which means it lacks freeze authority over its own trust lines entirely. So this balance is not "frozen by the issuer." It is pinned by the holder's own line settings and by the absence of anyone with authority to release it.

The freeze race

The response was fast, and incomplete.

Time (UTC)	Who	What
21:01	Tether	971.1M USDT frozen in the main receiving wallet — 37 minutes after the sweep
21:04	Circle	823M USDC frozen in the main receiving wallet
22:01	Ripple	RLUSD frozen; 40.5M of 88.5M still inside
22:10	World Liberty Financial	27.8M USD1 frozen
22:26	World Liberty Financial	USD1 frozen in the compromised Binance hot wallet
23:35	Binance	Announces $2.54B verified frozen
00:08	Arbitrum Security Council	Forced 8,426 ETH and 74.6M ARB out of the attacker's wallet

About $2.7 billion frozen in total — the remainder of that total sitting on Tron, Avalanche and Polygon.

The attacker was racing it. TRM documents the conversion:

~325 million USDT sold to professional fillers and market makers via UniswapX and other intent-based contracts for ~122,300 ETH — implying roughly $2,650 per ETH when ETH traded around $2,330. A discount of more than ten percent. The remaining 175 million USDT from that batch was frozen.
60 million USDT supplied to Aave, borrowing ~19,760 ETH against it. Aave then froze the affected markets.
On Tron, 300 million USDT went to a wallet that started supplying it to JustLend; a further 200 million passed through a series of hop wallets and was swapped on Uniswap, of which 30 million was frozen.
The 88.5 million RLUSD was sold on DEXs between 21:42 and 22:01 — the nineteen minutes it got.

There is a moral in the Aave case worth stating plainly. A market maker who bought $325 million of USDT for ETH ninety minutes after the theft, at a ten-percent discount, was doing good business and had no way to know. The compliance exposure attached to them the moment the funds arrived. Real-time address screening would have flagged it. Most of the industry does not have that.

What is still out there

As of TRM's on-chain snapshot at 00:30 UTC on October 30, the attacker still controlled more than 420,000 ETH and 18,270 BTC — about $2.4 billion in assets beyond any issuer's reach.

Recovered: ~$2.7B. Still in the attacker's hands: ~$2.4B.

That unrecovered figure exceeds the entire Bybit heist, after Bybit's freezes. And it does not include the 233 million XRP on the XRP Ledger, which is still sitting there, or the peel chain on Bitcoin, which is designed specifically to be hard to follow. TRM expects the next stage of the laundering to involve bridges, swap services, and over-the-counter brokers.

A note on the numbers in this article

Two of the published figures do not survive an arithmetic check, and it is worth being explicit about which parts of this story are solid and which are reported rather than verified.

The by-chain breakdown sums to $6.357B, consistent with the reported $6.36B total. But the Ethereum line does not reconcile against its own components. ETH traded at $2,334.55 at 20:00 UTC that day — a figure we pulled independently, and one consistent with the $2,300–2,350 range TRM itself quotes when describing the Aave sale. At that price:


200,630 ETH                                    $0.468B

+ 1.875B USDT + 823M USDC + 88.5M RLUSD         $2.787B

                                               --------

                                               $3.255B

against a stated $3.79B — a gap of roughly $0.54 billion that would have to be accounted for by the unnamed "185 other tokens." It is also worth noting that 167,464.25 ETH (the sweep) plus 28,005.6 ETH (Binance 16) is 195,469.85 ETH, not 200,630 — so the published total is probably aggregating ETH from additional legs without saying so.

Treat the Ethereum composition as reported, not reconciled. The total holds. The breakdown is softer than it looks.

One more date worth stating plainly, because the sources around this incident disagree about it. EIP-7702 arrived with Ethereum's Pectra upgrade, and Pectra activated on 7 May 2025 — we pulled block 22,431,084 from the chain and its timestamp is 2025-05-07 10:05:11 UTC. TRM Labs gets that right in their writeup. Blockaid's writeup carried it as "May 2026" when we read it, though their page now reads "May 2025" — so if you are checking this against a source, check which version you are looking at.

It is worth stating because the mechanism had been live for roughly seventeen months before this attack. That is the whole point of the next section: it was not exotic, and it was not new.

What an exchange should take from this

The defensive lessons follow directly from the mechanism. TRM Labs and Blockaid published guidance within hours of this incident and their conclusions overlap heavily, so treat the list below as the emerging industry consensus rather than our own invention. The wording is ours.

A delegation request belongs in the same risk class as a cold-wallet transfer. It hands a third party standing control of the account, so it should need the same approvals, and should be refused outright when nothing asked for it.
Ask how many authorizations a request carries, and over which nonces. A single type-0x4 transaction carrying dozens of them across a nonce window is the signature of the spray used here, and it is visible in the transaction before the theft lands. It is still an ordinary valid signature, so a rule that screens for it has to be written on purpose.
Watch every hot wallet for code, not just for balance. A wallet that goes from empty code to a delegation pointer is the earliest reliable warning sign, and by then there is a window to act — the delegation sat on-chain for three minutes and twenty-four seconds before the sweep.
Have the revocation transaction written, signed and ready before you need it. Here the revocation took a signature from the very key that had been compromised, which means the ability to produce one cannot be assumed to be intact.
Do not park inventory at an address whose delegation state you have not confirmed.
When a compromise happens, cancel the delegation first and rotate keys second. The other order leaves the standing authorization live while you are busy changing everything else.
Pass the full authorization list to whatever screens your transactions. Without that list a delegation transaction looks like an unremarkable call to a familiar address, and a filter working on the visible fields alone will wave it through.
Split signing infrastructure and approval paths by chain and by wallet tier. One actor obtained usable signatures on ten chains within about half an hour.

And for everyone downstream of the theft: the funds touched Permit2, LI.FI, Uniswap, UniswapX and Aave within ninety minutes. Every pool, market maker, bridge and exchange on that path now holds or has processed proceeds of the theft.

Why this happened now, and why it matters more than ever

Every technical fact above sits inside a larger sentence.

Crypto spent a decade being treated as a criminal-adjacent corner of finance — a place regulators tolerated, then chased, then began licensing in earnest. That chase produced real hardening. The custodians, the auditors, the compliance staff, the on-chain analytics firms: an entire industry of defenders that did not exist in 2016 and does now. The bridges, the custodians, the audit firms, the insurance desks, the sleuths — all of it grew out of pressure, and pressure is a kind of research funding. The crypto of 2020 would have been trivially defeated by this attack. Crypto of 2026 is defended by people who have been attacked before.

Theft did not get more sophisticated. Defenses got more sophisticated — and then the attack surface grew faster than the defenses.

That is the sentence that matters. Look at what was actually exploited here: not a novel cryptographic break, not a zero-day in a smart contract, not a bridge accounting flaw. It was a signing system that accepted a batch of fifty requests without asking whether a batch of fifty was ever a legitimate pattern. That vulnerability was sitting in plain sight the entire time EIP-7702 existed, for seventeen months, and it was not found by auditors because there was nothing exotic to audit. It was found by a criminal with patience and a nonce calculator.

Now look at what is happening on the regulatory side. Governments and regulated industries around the world are onboarding blockchain at speed — licensing regimes, custody frameworks, tokenization mandates, bank settlement pilots, stablecoin legislation, and institutional rails. Every one of those onboarding tracks pulls more capital, more signing keys, more automated transaction pipelines, and more machine-to-machine approval paths onto public ledgers. The attack surface is expanding because the uses are expanding.

And AI is moving at least as fast, and it is already in the middle of it. Agents do not sign like humans and they do not fail like humans. An agent batching approvals, retrying on failure, or optimizing for throughput can manufacture the exact pattern that killed Binance here — fifty signatures across a nonce window is what an efficient signing system looks like from the outside. The same property that makes delegation powerful for a user makes it devastating for a batch. AI does not introduce a new class of vulnerability here; it raises the volume and the speed of the existing class. That is more dangerous, because volume is what gets missed.

So the cracks are real, and they are a direct product of the rush. There is a window — a few years, maybe a handful of regulatory cycles — where adoption outruns hardening. Institutions that arrive late inherit mature defenses. Institutions that arrive in the rush inherit this attack, and the version of it that arrives is always the one that was written while they were still shipping.

What the rush leaves behind is not a clean ledger. It is an unmonitored one. The 233 million XRP is still sitting there right now, untouched, because nobody built the monitoring that would have flagged it. The $2.4 billion that is already beyond issuer reach is beyond issuer reach because nobody built the pre-emptive screening that would have caught it in the first ninety minutes. Every market maker who bought $325 million of stolen USDT at a ten-percent discount was doing good business and had no way to know — which means the tooling that would have told them did not exist yet.

This is the pattern worth naming for anyone holding a key right now: the defense that matters is the one you build before you need it. The revoke transaction. The nonce-range rule. The address screening. The trust line. All of it is cheap in advance and impossible afterwards, because afterwards the money is in a peel chain on Bitcoin or sitting untouched on an address nobody was watching.

There is a version of 2027 where this article reads as a historical curiosity — the last big theft of the transition period, before signing infrastructure was rebuilt around the assumption that a batch is a threat. There is another version where it reads as the template every incident analysis copies for the next five years. Which one we get is decided by people writing rules and monitoring code in the next eighteen months, not by people writing essays about it.

The attack worked because the mechanism was legal, documented, and seventeen months old. That is worth sitting with. The most expensive theft in the history of cryptocurrency did not require anything novel. It required a system that was working exactly as designed, being used by someone who understood the design better than the people responsible for it.

How we know what we know

This article is a forensic analysis. We wrote it from chain data, and we separate what we verified ourselves from what we are relaying.

Verified directly by us, against the chains: the EIP-7702 delegation transaction and its 50 authorizations, including the exact nonce range; the sweeper contract deployment and the address it produced; the sweep transaction and its 63-token basket; the 167,464.24785655882 ETH movement, traced; the Binance 16 transfer; the 780 million USDC movement from the smart account; all six standing-drain transactions and their timestamps; the delegation revocation and the zero address it pointed at; the XRP Ledger leg in full — the five sending addresses, the ten inbound payments and one CheckCreate, the 233,461,943.100050 XRP balance, the failed tecNO_DST RLUSD transfer and the absence of a trust line; the no_ripple/limit_peer state of the SOLO line and the issuer's lsfNoFreeze flag; the ETH market price at the time of the theft.

Reported by third parties, and attributed as such in the text above: the Arbitrum, Optimism, Base, Avalanche, Tron, Solana, Bitcoin and Polygon legs; the peel-chain address structure on Bitcoin; the Aave and JustLend positions; the $2.7 billion freeze total; the $2.4 billion still outstanding; the North Korean attribution itself; and the identification of the five XRP Ledger sending wallets as Binance's, which is TRM's attribution — TRM publishes no XRPL addresses, and the ledger carries no public label on exchange hot wallets. Binance has not published a root cause, so every mechanism claim here is a third-party forensic assessment, not a vendor admission.

The story is live. Everything here reflects on-chain state observed on October 30, 2026, and it will move.

Sources

TRM Labs, "North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History," Oct 29, 2026
Blockaid, "Binance $5.5B Hack: Using Advanced AI Models, Blockaid Detects the Biggest Theft in Crypto History," Oct 29, 2026
BBC News, Osmond Chia, "Crypto giant Binance hit by 'largest hack in history'," Oct 30, 2026
Decrypt, "Binance Drained of $5.5 Billion in Suspected Hack," Oct 29, 2026
The Defiant, "Binance-Labeled Wallet Swept Minutes After EIP-7702 Delegation"
Binance, "Security Incident Update #2"
rippled, include/xrpl/protocol/LedgerFormats.h (ledger-object flags) and include/xrpl/protocol/TxFlags.h (transaction flags)
EIP-7702 — https://eips.ethereum.org/EIPS/eip-7702

*Chain data: Ethereum via ethereum-rpc.publicnode.com, eth.drpc.org, 1rpc.io/eth; XRP Ledger via https://s2.ripple.com:51234 (full-history node); market prices via CoinGecko.*