← All news

Independent Ethereum forensic review

Following the Binance outflows: where the Ethereum funds went

A chronological forensic review of the Binance Ethereum outflows: preparation, authorization, fund distribution and a later BNB Chain mint that does not establish common control.

Scope and snapshot

This investigation covers a defined Ethereum branch of the reported Binance incident, not the entire incident across chains. Publication balances and blacklist checks were refreshed at Ethereum block 26,307,581, 30 October 2026, 19:11:23 UTC. Earlier collection at block 26,307,521 is preserved in our evidence archive. The graphs are dated snapshots, not live balances.

We used publicly available transaction identifiers as investigation leads and independently checked signatures, transaction hashes, receipts, transfer logs and contract state. We do not claim to have first discovered the incident. This is a manual forensic investigation, not an automated Archalis token rating.

Updated on 30 October 2026 with preparation evidence and a cross-check against Archalis records. The narrative below follows event time; all times are UTC. Ethereum is the incident branch examined here. The later UNSAFU mint is explicitly identified as a separate BNB Chain event. Each balance section retains its own observation block; these are not live balances.

28–29 October — the immediate funding sources

Three Withdrawal events from 0x12d66f87a04a9e220743712ce6d9bb1b5616b8fc name the external sender as recipient. Their net amounts after the event’s fee are 0.09825699656315, 0.09789260928915 and 0.09794285280185 ETH. The first occurred on 28 October at 07:39:47 UTC. We decoded the events from RPC receipts and cross-checked the net amounts against Etherscan’s internal transfers.

The separate funding address also appears as recipient in Withdrawal events from that pool and 0x47ce0c6ed5b0ce3d3a51fdb1c52dc66a7c3c2936. Tornado Cash’s own documentation identifies these as its Ethereum 0.1-ETH and 1-ETH pools.

At 01:15:35 on 29 October, another address, 0xfd41da53d1175b29d40599a0e63545067f58f408, received a withdrawal from the 0.1-ETH pool. Its event records a net 0.0979387044329 ETH after the fee. This address later supplies the small tokens used in the preliminary operations. We verified the withdrawal in the RPC receipt.

This establishes the immediate withdrawal source, not the original depositor. We have not linked these withdrawals to particular deposits. Relayers are transaction intermediaries and must not be identified as attackers on that basis.

29 October, 02:28:59 — the first contract

The external sender 0x7c8601d4645b93cea45f71e118a729332e6b5ca0 deployed 0x19bee294a6daab49c9e5ab69a5da6c035c70f2bf. The successful creation receipt and the address derived from sender and nonce agree. This was 17 hours, 55 minutes and 24 seconds before the main sweep.

Later in the day, the same sender submitted delegations and sweep calls involving three other accounts. The common sender, funding and recipient support a preparatory-testing interpretation. They do not independently identify the people operating the accounts.

29 October, 13:51–14:24 — two delegations and small sweeps

At 13:51:35 and 13:51:59, type-4 transactions named the first contract as delegate for 0x837810e3be7a3e89c570e7a01a13d3b566aafbc3 and 0x9c29ba2de4b2d6c3630685650663cfe7b70dbb6b. We recovered the respective account addresses from the authorization signatures. A successful outer receipt does not establish that every authorization entry applied.

The common token funder 0xfd41da53d1175b29d40599a0e63545067f58f408 received 11.541994 USDT at 13:59:35 and 2.303727 USDC at 14:02:47. The receipts show these tokens arriving through 0x74de5d4fcbf63e00296fd95d33236b9794016631. This records a counterparty in the transfer path, not attribution of that counterparty to the incident.

Between 14:04:23 and 14:06:35, this funder sent 6 USDT and 1 USDC to the first account, and 3 USDT and 1 USDC to the second. At 14:19:59 and 14:24:11, sweep receipts show those amounts moving to the same recipient, 0x24a4ae3674f08b70665fcb91f2aa6ad204aba4de. We verified both the incoming funding transfers and the outgoing token transfers against canonical token-contract logs.

29 October, 15:59:11 — a second contract with an additional capability

The same sender deployed 0x63e842b054bd624a465454d533c33f573e9c6fae, later named in the Binance authorizations. Comparing the subsequently captured runtimes reveals a specific difference: the second contract includes a function matching callExecute(address,address,uint256,bytes). It allows the authorized caller to invoke execute(address,uint256,bytes) on another contract and forwards msg.value.

We removed that function from the independently bytecode-matched reconstruction of the second contract and recompiled with solc 0.8.28. Excluding CBOR metadata, the result exactly matches the first contract’s 1,203 executable bytes; the second has 1,621. This is a reproducible code comparison, not a claim to possess the original source or historical state at deployment.

The main outflow transaction examined below calls sweep, not callExecute. The added capability does not establish why the second contract was deployed or that this additional function caused the incident.

29 October, 16:13–18:20 — the third account and returned ETH

At 16:13:59, the same token funder sent the remaining 2.541994 USDT to the third account, identified in the preparation appendix. At 16:20:47, a delegation transaction named the second contract for that account.

The funding address 0xe4f9070e1316de2988fc6f869fead8fb99cc74cd sent 1.01 ETH to 0x43aedb9bad6219677a2c8d6858321c16988404bd at 16:24:11 UTC. We checked this external transfer and its successful receipt via RPC.

A further delegation transaction at 16:25:59 again named the second contract. At 16:30:11, the sweep receipt records 2.541994 USDT moving to the same small-transfer recipient as before. Etherscan’s internal trace also records 0.01 ETH sent to that recipient. At 16:47:23, the controller called withdrawETH requesting 1 ETH back to the funding address; Etherscan records that internal transfer as successful. These native-ETH movements are trace-provider evidence, not independently reproduced execution traces.

At 18:20:47, the funding address sent 1.082218220676983978 ETH to the external sender that subsequently submitted the Binance authorization and sweep. This external transfer is verified through its transaction and receipt.

The funding, return and subsequent financing form a concrete operational link. Together with the repeated delegations and small sweeps, it strengthens the preparatory-testing interpretation. It does not establish that every linked address has the same owner.

29 October, 20:20:59 — the Binance authorization

The account is 0x28c6c06298d514db089934071355e5743bf21d60. The external transaction sender is 0x7c8601d4645b93cea45f71e118a729332e6b5ca0. The named delegate is 0x63e842b054bd624a465454d533c33f573e9c6fae.

Authorization transaction 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b was included in block 26,300,753 at 20:20:59 UTC on 29 October. All 50 authorizations specify chain ID 1. We recovered their signing addresses cryptographically; all recover to the affected account. Their nonces run down consecutively from 18,914,824 to 18,914,775.

This is not evidence of 50 successful delegations. EIP-7702 checks the authority nonce and increments it after an authorization applies. For these descending nonces, at most one entry can apply. The list alone does not establish why these 50 authorizations were assembled.

A valid authorization establishes a signature attributable to the account key. It does not distinguish theft of a key from abuse or compromise of a signing workflow. It does not establish the identity of the person operating it. We could not independently retrieve the complete historical account-code transition from the RPC providers used, so we do not claim that additional state proof.

29 October, 20:24:23 — the main sweep

Transaction 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3 was included in block 26,300,770 at 20:24:23 UTC, 204 seconds after the authorization transaction. The same external sender called the affected account. The outer transaction has ETH value zero.

Its calldata contains selector 0x8a179be4, a recipient and 65 asset entries, including the zero address. The successful receipt contains 63 Transfer logs from 63 distinct token contracts, all from the affected account to 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c. The canonical USDT contract emitted a transfer for 1,615,409,498.973240 USDT.

Etherscan’s internal-transfer trace also records 167,464.247856558836135296 ETH from the affected account to this recipient. This native transfer is trace-provider evidence: we could not cross-check it with an independent RPC execution trace. The 63 token transfers are independently observable in the transaction receipt.

We independently reconstructed the signed authorization and sweep transactions and reproduced their transaction hashes. Two RPC providers agreed on the checked sweep receipt’s block, status and logs. A reconstructed source listing found on an explorer was not treated as original verified source code.

After 20:24:23 — distribution of the main outflows

The recipient sent 500,000,000 USDT to 0x9749292d74fd460982d0912ea9515ea24736c762 at 20:30:11 UTC and 200,000,000 USDT to 0x0ddf0480016e6bcb2c1f5d190d221fba1320697e at 20:33:23 UTC on 29 October. Both transfers were checked against RPC receipts.

The 500-million branch passed 175 million through 0x811f15855476156ebf86ba3b84fafb8ceaa4e84c to 0xaa246bf639586a6ba46762d378ce50ca4fc654a0. At the snapshot the final address retained 174,999,872.327620 USDT and was blacklisted. Its indexed outgoing USDT transfer was 127.672480 USDT; tiny incoming amounts explain why the retained balance is not simply 175 million minus that transfer.

The 200-million branch distributed 10 million across several recipients, then passed 190 million to 0x8d53903625b8e839b9df4bd28b0efb1cd6b8639a. That address sent 60 million to 0x23878914efe38d27c4d67ab83ed1b93a74d4086a and 130 million to 0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb. Aave’s own governance documentation identifies the former as aEthUSDT. A protocol contract receiving funds is not evidence that its operator is an accomplice; the corresponding position and debt require separate reconciliation.

The 130-million recipient distributed 50 million in two multi-recipient transactions and forwarded 80 million to 0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd1. We then verified the full outgoing 80 million USDT: 50 million to multiple recipients and 30 million to 0xccbef95633adb5cd2b5038db5a38d77e726ca263, which forwarded 30 million to 0xb171ca86f82070282138352ff7111b494060c8c3. This final address retained 30 million USDT and was blacklisted. Swap outputs and beneficial ownership of protocol positions remain outside the completed reconciliation.

The remaining recipients on the 500-million branch include large transfers to contracts and other counterparties. The appendix records the transfers without assigning all recipients to a common operator or treating every payment as a final resting place.

The main recipient also sent 197,460 ETH and 17,260.1 ETH to separate addresses shown in the fund-flow overview. These are historical movements; the later balances are recorded separately below.

The money trail at a glance

Ethereum fund-flow overview distinguishing retained USDT and USDC from ETH branches and unresolved conversions.
Blue: transfers and ETH destinations. Amber: stablecoin balances at blacklisted addresses. Click to open the full-size graphic. Arrows show historical movements; boxes report balances.

29 October, 22:51:41 — a separate BNB Chain mint to the collection address

A later cross-check of Archalis records found the collection address 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c holding 50% of a BNB Chain token named Funds are UNSAFU: 0x2ef4a1d34dd9dad06271a5793b6a205649cd8f43. This is a separate chain and asset, not part of the verified Ethereum proceeds.

We retrieved the creation transaction 0xd21785dc74e5c4808c9bd07b0f685fd2874cd3f5035c0f19d5ad70bda026eac6 and its successful receipt through BNB Chain RPC. The sender is 0x031558796117e235f2c614178e14b69b82ba6572. Two mint events assign 500 million tokens to that creator and 500 million directly to the collection address. The block timestamp is 22:51:41 UTC, 2 hours, 27 minutes and 18 seconds after the Ethereum sweep.

The creator signed the deployment transaction; the collection address did not sign it. Assigning tokens to another address does not require that recipient’s cooperation. This is therefore not evidence that the collection address controls the token project, consented to the mint, or belongs to the creator’s network. We cannot establish the creator’s intent from the mint alone.

30 October, 19:11:23 — major balances at the pinned snapshot

The table records balances, not an attribution of beneficial ownership. Blacklist flags apply to the named token; they do not freeze native ETH. Stablecoin amounts below are token units, not a guaranteed dollar valuation.

AddressVerified balanceState / interpretation
0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c1,175,464,712.875462 USDT; 823,000,000 USDC; 4.807820566576213549 ETHUSDT and USDC blacklist flags true
0x8532fa14acaf483729c449b8458aeddb900543d4197460.00841201204141417 ETHCurrent balance at the pinned block; no issuer blacklist applies to native ETH
0x03b0ee5d82990cff1bda48651ac3e436d1a020ea17260.1047365969331411 ETHCurrent balance at the pinned block; no issuer blacklist applies to native ETH
0xaa246bf639586a6ba46762d378ce50ca4fc654a0174999872.32762 USDTUSDT blacklist flag true
0x9749292d74fd460982d0912ea9515ea24736c7620.0006 USDTIntermediate address; USDT blacklist flag true
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0.0001 USDTIntermediate address; USDT blacklist flag true
0xb171ca86f82070282138352ff7111b494060c8c330,000,000 USDTUSDT blacklist flag true

The main recipient combines multiple inflows. The downstream ETH totals cannot be assigned exclusively to the initial 167,464 ETH transfer without a full accounting of subsequent receipts and conversions. We do not use a first-in-first-out assumption to imply provenance.

Retained stablecoins, measured separately

USDT balances at three blacklisted addresses and USDC at the collection address.
Balances at block 26,307,581. A blacklist flag is not evidence that the assets have been returned to Binance.

What we know about the main recipient

At the snapshot, 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c returned empty account code. At the earlier collection block 26,307,521, its indexed outgoing normal transactions numbered 705, with nonces 0 through 704. The earliest activity in the retrieved normal, internal and token histories was the 29 October sweep at 20:24:23 UTC. This describes the returned Ethereum history; it is not proof of no earlier use elsewhere.

The transfer pattern supports describing it as a collection and distribution address in this Ethereum branch. It does not identify a natural person, organization, nationality or exchange customer. No verified KYC identity is available from our checks.

Unsolicited inbound transfers, dust and messages are not treated as evidence that the senders share control with the recipient. We also excluded zero-value USDT transfers to lookalike addresses, including 0x9749110a86941480dbefca1efdc0ceb528a0c762. It resembles the genuine 500-million recipient but received zero USDT in the excluded event.

30 October — the small-transfer recipient still holds the amounts

At Ethereum block 26,307,850, 0x24a4ae3674f08b70665fcb91f2aa6ad204aba4de held 11.541994 USDT, 2 USDC and 0.01 ETH. The balances match the small token transfers and the trace-recorded ETH transfer described above. Account code was empty and the nonce was zero. The retrieved histories showed no outgoing transfers; this is a bounded observation, not proof of no activity on other chains.

30 October — comparison with networks already followed by Archalis

We compared 38 investigation addresses with production records of creators, funders, token origins and network links. No exact matches appeared in the structured fields checked. We then searched 25,601 saved analyses, 157,419 evidence observations, 1,639 token-evidence records and the available creator and token-origin evidence. Queries ran in read-only mode against a live database, so these counts are not an atomic snapshot.

Six saved analyses contained searched addresses. Five referenced 0x0000000000be226afde21672a5e4adc45692e69d only as a holder, with recorded percentages of zero or 0.0003%. A holder overlap does not establish common control. The sixth was the UNSAFU case described above.

Archalis already records the UNSAFU creator in its network data. That is a heuristic grouping of observed links, not proof that every member shares an operator. Neither the unilateral mint nor the creator’s graph membership establishes that the collection wallet belongs to a known scam network. The cross-check produced no substantiated attribution of the operational preparation addresses to those networks.

A separate BNB Chain state check found empty code and zero nonces for all nine principal preparation addresses. The external sender held 0.001000000000001 BNB; the origin of that small credit remains unresolved. Receiving funds is not evidence of signed activity. Historical BNB Chain account queries were unavailable under the API plan used, so this state check must not be presented as a complete transaction-history search.

Assessment: what the evidence establishes and what remains open

The examined sequence supports abuse of valid account authorizations. It does not demonstrate a flaw in Ethereum consensus or signature verification. Valid signatures do not distinguish key theft from abuse of a signing service or theft of previously signed authorizations; inclusion times do not reveal when signatures were created.

The new findings provide a pre-incident timeline and linked addresses for comparison with internal records. A decisive next check is whether the 50 Binance authorization digests correspond to requests in signing-service, HSM or MPC audit logs, and which identity or policy approved them. The earlier accounts and funding recipient can also be compared with records available to the incident responders.

Our work remains a public-chain investigation. We have not accessed Binance’s internal systems, established a real-world attacker identity, or determined the original off-chain entry point.

Method and limits

  • Discovery: Etherscan account histories collected at block 26,307,521 and extended for the final USDT branch through publication block 26,307,581. Histories are provider-indexed data; some secondary history endpoints hit rate limits, so we do not claim exhaustive coverage of every address.
  • Verification: successful RPC receipts and exact contract/from/to/value matching for 63 downstream USDT transfer rows in the appendix; pinned-block eth_getBalance and eth_call for balances and blacklist state.
  • Signature checks: recovered EIP-7702 authorities, reconstructed signed transaction hashes and compared the original sweep receipt across two providers.
  • Evidence preservation: raw responses, query parameters, timestamps and SHA-256 digests saved locally. File digests establish integrity of the captured files, not independent consensus inclusion proofs.
  • Open work: complete swap outputs, lending positions and debts, subsequent conversions and positions after the verified USDT transfers, other tokens and chains, and issuer recovery actions. No total loss or recovery figure is inferred from this partial branch.
  • No on-chain evidence examined here establishes an AI-related cause, a vulnerability in BNB Chain or PancakeSwap, or the attacker’s real-world identity.
  • Preparation update: bounded account histories through block 26,300,770; RPC transaction and receipt checks, recovered earlier authorization signers, contract-creation address checks and decoded pool Withdrawal events. Native internal transfers are explicitly identified as Etherscan trace evidence. The earlier balance snapshot remains unchanged.
  • Archive cross-check: structured address fields plus the listed saved analyses and evidence records. Full text of every pools, ratings and alerts record was not exhaustively searched. A negative result does not exclude undiscovered addresses or activity outside Archalis coverage.
  • UNSAFU: independently checked BNB Chain creation transaction, receipt, mint logs and block timestamp. A recipient is not treated as a signer or controller solely because it receives minted tokens.

Appendix: preparation transaction references

All times below are UTC on 29 October 2026. We checked transaction bodies and successful receipts via Ethereum RPC, recovered the earlier authorization signers, and checked both contract-creation addresses against the sender and transaction nonce. Source links for each transaction are included below.

UTCObservationTransaction
02:28:59Sender deploys 0x19bee294a6daab49c9e5ab69a5da6c035c70f2bf0x6b76e8748ba1c6bc81e674c830a0b3603db6bde04ec4bd4a2d3126c1a12706d8
13:51:35 / 13:51:59Delegations name the first contract for 0x837810e3be7a3e89c570e7a01a13d3b566aafbc3 and 0x9c29ba2de4b2d6c3630685650663cfe7b70dbb6b0x16b5acc35a82d194aadb21a4a56d666310fe83982c387c974f4796275f499dca / 0xec5af21dc34fc8a3ac131f694aa0df5b27c0525ea3a71d97daa7e597abcb21d9
14:19:59 / 14:24:11Sweep receipts show 6 USDT + 1 USDC and 3 USDT + 1 USDC transferred to the same recipient.0xa2e0cd4123cf4463cf43685232142d680e9994f5bd29f0540bf977a158216c4c / 0x6aaae5bcb5e0bafd1e79e70670864f8f726624d50d99d16152c5e684f571ddf4
15:59:11Sender deploys 0x63e842b054bd624a465454d533c33f573e9c6fae, later named in the Binance authorizations.0x97408e7562eb2b28efcd24ba01609607b5749bc89448d007fa8b50ecf290329c
16:20:47 / 16:25:59Delegations name the second contract for 0x43aedb9bad6219677a2c8d6858321c16988404bd.0xb2148eb825cac75efe0ae7fb5c319e6b66df62631738ba252185960e50dc5782 / 0x7c5206cb7aa77ce5b54f030e94ad127af0184e856689526602ffcd21a238e95d
16:30:11Sweep receipt shows 2.541994 USDT sent to the same small-transfer recipient.0x9c2dbed15322072e35e767c0c9b4cd962abf58fe51937e62a7020c742b834f2f
20:20:59 / 20:24:23Binance authorization transaction, followed 204 seconds later by the main sweep.0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b / 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3

The common recipient of the small token transfers is 0x24a4ae3674f08b70665fcb91f2aa6ad204aba4de. Token amounts come from Transfer logs of the canonical USDT and USDC contracts, not merely from calldata. The first deployment precedes the main sweep by 17 hours, 55 minutes and 24 seconds. A successful outer transaction alone does not prove that every authorization entry applied.

Every verified USDT connection

The graph is unfolded into one panel per sending address to avoid overlapping lines. W-identifiers remain the same across all panels and the balance register. Every displayed connection is a checked USDT transfer; recurring sender–recipient transfers are summed. ETH branches are shown in the overview. This is the complete network verified in this investigation, not a claim to cover every asset or wallet involved in the incident.

Complete verified USDT network, unfolded by sender with stable wallet identifiers, transfer amounts, balances and blacklist state.
Open the full-size SVG to follow each W-number. Counterparty balances may include unrelated customer or liquidity-provider funds; never count them as attacker holdings.

Address register and publication balances

All balances below were read at the same publication block. A contract or counterparty balance is not a measure of the attacker’s assets. Code status is a technical observation, not an identity attribution. Native ETH and other token balances do not follow from the USDT blacklist flag.

ID / addressETHUSDTUSDT blockedUSDCUSDC blockedAccount code
W01 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c4.8078205665762135491175464712.875462true823000000.0trueEmpty
W02 0x9749292d74fd460982d0912ea9515ea24736c7620.0006893079136740710.0006true0.0falseEmpty
W03 0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0.0000240368843612540.0001true0.0falseEmpty
W04 0x8532fa14acaf483729c449b8458aeddb900543d4197460.008412012041414170.0false0.432644falseEmpty
W05 0x03b0ee5d82990cff1bda48651ac3e436d1a020ea17260.10473659693314110.0false0.0falseEmpty
W06 0x74edc79fea13bdf1f7841570227127cec493bdd90.00.000002false0.0falseContract code
W07 0x0000000000be226afde21672a5e4adc45692e69d0.00.000002false0.007298falseDelegation designator
W08 0xbeef02961503351625926ea9a11ae13b29f5c55521.1033097265255882980.334754false0.0001falseDelegation designator
W09 0xec4fb7e7c35c241e1138a2d8cfbb09f3ad1ccb220.07.483137false0.507513falseContract code
W10 0x9b1303ebf09bc51b7fac376c9e421e8daae63b820.0000000000000000010.000001false0.000001falseContract code
W11 0x811f15855476156ebf86ba3b84fafb8ceaa4e84c0.0014224854279280.0001false0.0falseEmpty
W12 0x3416cf6c708da44db2624d63ea0aaef7113527c60.027657042.985666false6752043.506884falseContract code
W13 0x56534741cd8b152df6d48adf7ac51f75169a83b20.07456938.20498false0.00134falseContract code
W14 0x9db9e0e53058c89e5b94e29621a205198648425b0.011621025.260351false0.0falseContract code
W15 0x0d4a11d5eeaac28ec3f61d100daf4d40471f18520.06915820.096659false2700.0falseContract code
W16 0x11b815efb8f581194ae79006d24e0d814b7697f60.03200483.857964false0.0falseContract code
W17 0x4e68ccd3e89f51c3074ca5072bbac773960dfa360.021675061.072969false0.003066falseContract code
W18 0xc7bbec68d12a0d1830360f8ec58fa599ba1b0e9b0.0595032.74712false0.004804falseContract code
W19 0x000000000004444c5dc75cb358380d2e3de08a9052172.35172221403712276776896324.308297false43624329.585523falseContract code
W20 0x8d53903625b8e839b9df4bd28b0efb1cd6b8639a0.0000089269010429810.0001true0.0falseEmpty
W21 0xaa246bf639586a6ba46762d378ce50ca4fc654a00.001094865305973571174999872.32762true0.0falseEmpty
W22 0x23878914efe38d27c4d67ab83ed1b93a74d4086a0.063586891.600871false0.0falseContract code
W23 0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0.0139877665552787710.0002false0.0falseDelegation designator
W24 0xe3478b0bb1a5084567c319096437924948be196431.31081238508428523557577.879399false34386.466275falseEmpty
W25 0x3041cbd36888becc7bbcbc0045e3b1f144466f5f0.01823106.927894false1817943.870849falseContract code
W26 0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10.0440478964740833570.0001true0.0falseDelegation designator
W27 0xc5af84701f98fa483ece78af83f11b6c38aca71d0.098328.806298false0.0falseContract code
W28 0xccbef95633adb5cd2b5038db5a38d77e726ca2630.0290175937355317220.0001true0.0falseEmpty
W29 0xb171ca86f82070282138352ff7111b494060c8c30.00280299462845289730000000.0true0.0falseEmpty

Appendix: independently matched downstream USDT transfers

Each of the 63 downstream transfer rows below matched a successful receipt log from the canonical USDT contract. The two direct 500-million and 200-million hub transfers were checked separately and appear in the graph and Sources.

FromToUSDTTransaction
0x9749292d74fd460982d0912ea9515ea24736c7620x74edc79fea13bdf1f7841570227127cec493bdd950000000.00x290e94a9d14294b1c22bbc5d167343fd91fe91233e89434f20532fe5fe7e8668
0x9749292d74fd460982d0912ea9515ea24736c7620x0000000000be226afde21672a5e4adc45692e69d100000000.00x4fa182626c85ca0cdc18ba736930bdbdfbcf5d201d373913317df6ec58d23d61
0x9749292d74fd460982d0912ea9515ea24736c7620xbeef02961503351625926ea9a11ae13b29f5c55550000000.00xfa949551eeec164133714f7658e232bf7eb8140a67d8f5edb95ea41b31b93a72
0x9749292d74fd460982d0912ea9515ea24736c7620xbeef02961503351625926ea9a11ae13b29f5c55575000000.00xa861a556b73df4e084aca07663d63b26eec33136ed7328712a7418361d856f36
0x9749292d74fd460982d0912ea9515ea24736c7620xbeef02961503351625926ea9a11ae13b29f5c55514999999.9999990xe5ccc3a8b32f7c52683390fa75f57cec53394421bd05132400806533e661843a
0x9749292d74fd460982d0912ea9515ea24736c7620xbeef02961503351625926ea9a11ae13b29f5c5555000000.00x7b0ad8b5814a048086dab1236284e677e430cac142c84ab6bbbc985da1f282e6
0x9749292d74fd460982d0912ea9515ea24736c7620xec4fb7e7c35c241e1138a2d8cfbb09f3ad1ccb22692922.2968760x1b623b4349356c6c5699f953c5df9d9a4bc278e598f90f1ef42f385399a07b66
0x9749292d74fd460982d0912ea9515ea24736c7620xec4fb7e7c35c241e1138a2d8cfbb09f3ad1ccb22706623.3359380xc59188f11b6b7bd18a45b2afc91e787bf66d767dd5b95d01730f3c5c92f1e490
0x9749292d74fd460982d0912ea9515ea24736c7620x9b1303ebf09bc51b7fac376c9e421e8daae63b8228600454.3671870x3fd5ec345eaf60faca94c652f5ac5c0dca77b4ef3c355fb12cb8f5108464a0b6
0x9749292d74fd460982d0912ea9515ea24736c7620x811f15855476156ebf86ba3b84fafb8ceaa4e84c175000000.00x1fb992f92a45afec23d7d5740c7958a644fb90ef0cba19ca39bd2c6534fb670b
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0x3416cf6c708da44db2624d63ea0aaef7113527c660000.00x152e005f6dcccd941e0a2c7156b955c6baad08a347685bcf5518776dab04f8cc
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0x56534741cd8b152df6d48adf7ac51f75169a83b21390000.00x152e005f6dcccd941e0a2c7156b955c6baad08a347685bcf5518776dab04f8cc
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0x9db9e0e53058c89e5b94e29621a205198648425b500000.00x152e005f6dcccd941e0a2c7156b955c6baad08a347685bcf5518776dab04f8cc
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0x0d4a11d5eeaac28ec3f61d100daf4d40471f1852110000.00x152e005f6dcccd941e0a2c7156b955c6baad08a347685bcf5518776dab04f8cc
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0x11b815efb8f581194ae79006d24e0d814b7697f6330000.00x152e005f6dcccd941e0a2c7156b955c6baad08a347685bcf5518776dab04f8cc
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0x4e68ccd3e89f51c3074ca5072bbac773960dfa363390000.00x152e005f6dcccd941e0a2c7156b955c6baad08a347685bcf5518776dab04f8cc
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0xc7bbec68d12a0d1830360f8ec58fa599ba1b0e9b100000.00x152e005f6dcccd941e0a2c7156b955c6baad08a347685bcf5518776dab04f8cc
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0x000000000004444c5dc75cb358380d2e3de08a904120000.00x152e005f6dcccd941e0a2c7156b955c6baad08a347685bcf5518776dab04f8cc
0x0ddf0480016e6bcb2c1f5d190d221fba1320697e0x8d53903625b8e839b9df4bd28b0efb1cd6b8639a190000000.00xc0fab33d0ec562d3feef6b23946402b1af80dade21ab4f5fbea7384cc4615183
0x811f15855476156ebf86ba3b84fafb8ceaa4e84c0xaa246bf639586a6ba46762d378ce50ca4fc654a0175000000.00xb6d7d3ffcbdd0465e1ab743a8d943218176cac7b15edefa7b7bcd5e853e4266f
0x8d53903625b8e839b9df4bd28b0efb1cd6b8639a0x23878914efe38d27c4d67ab83ed1b93a74d4086a10000000.00x420e74015336a44f3056c00bf5a1313889a7f6ed30a053ad59832d4a4a1f14eb
0x8d53903625b8e839b9df4bd28b0efb1cd6b8639a0x23878914efe38d27c4d67ab83ed1b93a74d4086a50000000.00x65bd82f19985a569ef87b3926dd5f2247ba7bd06640141060f1b2d9ddedec3f6
0x8d53903625b8e839b9df4bd28b0efb1cd6b8639a0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb130000000.00xd2e7e5e6ee32a3552de469d97e90d83b707d314ffe7b8747786de92daa3fc3d8
0xaa246bf639586a6ba46762d378ce50ca4fc654a00xe3478b0bb1a5084567c319096437924948be1964127.672480x11be88b460501b4652e760c41e08cc1f18575e14b6c6ffbb3383e043c2decf34
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x56534741cd8b152df6d48adf7ac51f75169a83b22000000.00xb7d294873bf18a56ce99115794b8a9a76542791b58456e7a4f94d74f1ae4e41f
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x9db9e0e53058c89e5b94e29621a205198648425b740000.00xb7d294873bf18a56ce99115794b8a9a76542791b58456e7a4f94d74f1ae4e41f
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x3416cf6c708da44db2624d63ea0aaef7113527c680000.00xb7d294873bf18a56ce99115794b8a9a76542791b58456e7a4f94d74f1ae4e41f
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x0d4a11d5eeaac28ec3f61d100daf4d40471f1852180000.00xb7d294873bf18a56ce99115794b8a9a76542791b58456e7a4f94d74f1ae4e41f
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x11b815efb8f581194ae79006d24e0d814b7697f6760000.00xb7d294873bf18a56ce99115794b8a9a76542791b58456e7a4f94d74f1ae4e41f
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x4e68ccd3e89f51c3074ca5072bbac773960dfa366740000.00xb7d294873bf18a56ce99115794b8a9a76542791b58456e7a4f94d74f1ae4e41f
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0xc7bbec68d12a0d1830360f8ec58fa599ba1b0e9b140000.00xb7d294873bf18a56ce99115794b8a9a76542791b58456e7a4f94d74f1ae4e41f
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x000000000004444c5dc75cb358380d2e3de08a909360000.00xb7d294873bf18a56ce99115794b8a9a76542791b58456e7a4f94d74f1ae4e41f
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x56534741cd8b152df6d48adf7ac51f75169a83b24170000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x9db9e0e53058c89e5b94e29621a205198648425b1920000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x3041cbd36888becc7bbcbc0045e3b1f144466f5f90000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x3416cf6c708da44db2624d63ea0aaef7113527c6210000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x0d4a11d5eeaac28ec3f61d100daf4d40471f1852390000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x11b815efb8f581194ae79006d24e0d814b7697f61140000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x4e68ccd3e89f51c3074ca5072bbac773960dfa3612480000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0xc7bbec68d12a0d1830360f8ec58fa599ba1b0e9b300000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x000000000004444c5dc75cb358380d2e3de08a909300000.00xcb8075f1d07bc56e54e59ccd4477d75b6a7b21f265dabe2ee86beeb3f3b38a9d
0x77edef23fbd05921c26fe29fcc3a65e14d2ac3eb0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd180000000.00x279d12e9a7f594eeaf0eb83fe649f7f2cdf82ced156a82f85014dc56369b36d8
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x56534741cd8b152df6d48adf7ac51f75169a83b22720000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x9db9e0e53058c89e5b94e29621a205198648425b1260000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x3041cbd36888becc7bbcbc0045e3b1f144466f5f60000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x3416cf6c708da44db2624d63ea0aaef7113527c6160000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x0d4a11d5eeaac28ec3f61d100daf4d40471f1852260000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x11b815efb8f581194ae79006d24e0d814b7697f6660000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x4e68ccd3e89f51c3074ca5072bbac773960dfa367840000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10xc7bbec68d12a0d1830360f8ec58fa599ba1b0e9b200000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x000000000004444c5dc75cb358380d2e3de08a906840000.00x808f54a951b7fd051600937b45c6c3fb42d59850c6bf459cea8615dfadbcad39
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x3041cbd36888becc7bbcbc0045e3b1f144466f5f180000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x3416cf6c708da44db2624d63ea0aaef7113527c6480000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x56534741cd8b152df6d48adf7ac51f75169a83b24650000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x9db9e0e53058c89e5b94e29621a205198648425b3600000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x0d4a11d5eeaac28ec3f61d100daf4d40471f1852780000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x11b815efb8f581194ae79006d24e0d814b7697f61590000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x4e68ccd3e89f51c3074ca5072bbac773960dfa3610680000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10xc5af84701f98fa483ece78af83f11b6c38aca71d150000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10xc7bbec68d12a0d1830360f8ec58fa599ba1b0e9b1320000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10x000000000004444c5dc75cb358380d2e3de08a906570000.00x2a1979ae32a40c0aaa0df757f6af690857c6c8cb86097cac29316597de9469f6
0x7aa4d3029e4c6a8e916300014ad95b6d6c03bfd10xccbef95633adb5cd2b5038db5a38d77e726ca26330000000.00x9a7645882a20445c5a731a15f34e1757f0b6c52e8f51a4ddb8c09cdc424295ce
0xccbef95633adb5cd2b5038db5a38d77e726ca2630xb171ca86f82070282138352ff7111b494060c8c330000000.00x1e6f851d072ae0ad448dca2446552cbb4e76516029b34980d5189e4353aae7a7

Sources

Investigate a token of your own

Start with its public risk findings. A free account adds saved tokens, comparison and five fresh checks per UTC day.

Check a BNB Chain token → · Create a free account

Ratings are automated assessments of structural risk from public blockchain data, not investment advice. Methodology.