Triple-A leads: Seven DAI Receipts and 2,620 ETH in 28 Pool Deposits

On 25 July 2026, a researcher reported wallet-draining activity and named an Ethereum collecting address. Two days later, Triple-A said unauthorized access had affected wallets holding its own treasury assets, while client funds were unaffected. The company did not name the investigated addresses in that statement. This review therefore follows the researcher’s leads without treating every movement as independently proved victim loss. Original researcher alert; Triple-A statement.

The checked token route is source S → collector C → four DAI recipients. One recipient, R, also sends ETH through a router into two explorer-labeled Tornado Cash pools. These are connected address roles, but the trade that would connect the DAI and ETH legs has not been reconstructed. The confirmed diagram stops at the Ethereum pools; no withdrawal recipient or Zcash continuation is established.

Read the roles before the amounts

DAI is a token: its contract maintains a ledger of balances. ETH is Ethereum’s native asset and pays execution fees. A DAI transfer can attach zero ETH to its contract call while still moving tokens. The transaction’s target contract and the recipient named in a token Transfer event answer different questions. A router forwards a call or payment to another contract. A mixer is designed to make a deposit difficult to match with a later withdrawal; observing entry does not identify an exit.

These short names avoid asking the reader to memorize addresses. They describe movements, not people, common control or criminal intent. Full underlined Ethereum address links appear in Appendix A. The Etherscan nametag for C is corroborating attribution context, not a company ownership record.

What was checked

Three findings guide the chronology. First, three earlier DAI receipts materially change the former four-receipt account. Second, thirteen exact DAI departures can now be reproduced without counting an approval as a payment. Third, all 28 listed August pool deposits have transaction-level support, but their 2,620 ETH subtotal is not a verified incident-loss figure.

28 July — seven receipts, not just the last four

The earliest checked receipt is at 11:24:35 UTC: S sends 100 DAI to C. At 11:25:59, it sends 10,000 DAI. Thirty-six seconds later, another receipt carries 2,042,954.555997589733765540 DAI. These three earlier transactions are essential to understanding how much DAI reached C from S. I01 transaction; I02 transaction; I03 transaction.

At 11:44:59, a further 100 DAI arrives. The next two large receipts are separated by another small payment: 2,798,804.533028033525749663 DAI at 11:45:47, 100 DAI at 12:11:59, and 5,018,134.251077767199891897 DAI at 12:12:35 UTC. The same canonical token contract, source and collector are named in the checked events. I04 transaction; I05 transaction; I06 transaction; I07 transaction.

This compact table truncates amounts to six decimals; Appendix B preserves every raw integer and full precision. DAI uses 18 decimal places: each event’s integer amount is divided by 10¹⁸ to express tokens. The seven raw event amounts sum to 9,870,193.340103390459407100 DAI. Selecting only the last four would give 7,817,138.784105800725641560 DAI and omit the earlier 2,053,054.555997589733765540 DAI. The broader receipt selection repairs the accounting comparison; it does not establish the origin of S’s assets or prove treasury ownership.

6 August — DAI payments and ETH deposits interleave

At 02:59:11 UTC, C sends 100 DAI to R. At 03:01:23, it sends 1,000,000 DAI to the same address. The first checked ETH pool deposit follows at 03:20:11. The order is consistent with a later conversion, but does not itself supply the trade, settlement or authorization that would prove one. O01 transaction; O02 transaction; P01 transaction.

Four more 100 DAI / 1,000,000 DAI pairs follow at 06:26:59 / 06:28:11, 06:42:35 / 06:43:23, 06:55:59 / 06:57:11 and 07:22:23 / 07:24:23 UTC. Together, the ten payments send 5,000,500 DAI to R. The ETH deposits continue during this sequence, so the diagram must not imply that every DAI payment finished before every ETH deposit began. The full transaction links and log positions are retained in Appendix B.

R’s 28 checked deposit transactions span 03:20:11–07:37:23 UTC. Twenty-six send 100 ETH each through the router to the 100 ETH pool; the final two send 10 ETH each to the 10 ETH pool. That gives 26 × 100 + 2 × 10 = 2,620 ETH. The window measures these selected deposits, not the duration of the underlying compromise. Transaction fees are separate and excluded from this subtotal.

Start Figure 1 at R, then follow the router’s branches to the two pools. Solid arrows show ETH movements; the branch captions state transaction counts and quantities. The two stages carry the same ETH, so adding the router receipt to its forwarding would count it twice. The layout is schematic, not proportional to time or amount.

Figure 1. P01–P28. Sage boxes mark the sending and receiving roles; blue-gray marks the forwarding router. Solid arrows mean displayed asset movement, not identity or legal attribution. The 2,620 ETH appears at both stages but is counted once; no post-pool recipient is shown.

This is stronger than a list of hashes alone: every selected record now has a success status, block, timestamp, fee and displayed internal forwarding. It is still an explorer-record check, not an independent execution replay. Nor does verifying the deposit inventory prove that all deposited ETH was purchased with C’s DAI or belonged to the reported incident.

11 August — three further DAI recipients

Five days later, C sends DAI to three different addresses: 500,000 DAI to A at 09:44:11 UTC, 1,500,000 DAI to B at 09:51:11, and 2,869,693.351053390459407100 DAI to D at 09:56:47. These checked token events establish the recipients and quantities. Their further trades and any later pool deposits are not part of this verified subset. O11 transaction; O12 transaction; O13 transaction.

Read Figure 2 from S into C, then follow each branch separately. The R branch summarizes the ten 6 August payments; A, B and D are the later 11 August recipients. Each amount is DAI, not dollars. The figure combines separate dates to show address relationships, so its spacing is not a timeline. It draws no DAI-to-ETH conversion.

Figure 2. Seven incoming and thirteen outgoing canonical DAI events. Blue-gray identifies the source/collector; sage identifies receiving roles. Solid arrows show token movements. The artwork rounds quantities where marked; Appendix B retains all raw amounts. Fees, small unreviewed incoming events and later asset conversions are omitted.

The hub structure makes the central observation readable: one collector sends DAI to four recipients. It does not make those recipients one operator. The next accounting question concerns the difference between checked receipts and checked departures—not an assumption that all counterparties share a key.

What remains of the DAI accounting gap?

Adding the thirteen checked outgoing logs gives 9870193.351053390459407100 DAI. Subtracting the seven checked incoming logs leaves only 0.010950000000000000 DAI more outgoing than incoming. The formerly unexplained difference of roughly 2.05 million DAI is therefore largely explained by the three earlier receipts. It is not evidence of an additional multi-million-token loss.

That small difference does not settle the balance. The canonical-token listing contains 107 rows across all five pages, including small receipts outside these twenty individually checked events. The listing counts transfer rows, not unique transactions: its 107 rows correspond to 97 hashes. The small rows have not all received a raw-log verification pass, and a fixed-block balance has not been obtained. The explorer’s displayed current token holding is not substituted for one.

The review therefore does not claim a zero DAI balance, an exact unexplained deficit or a complete loss ledger. It also does not add the DAI payments to the ETH deposits as separate damage. A conversion could move the same economic value through both asset legs, and its execution remains to be joined.

Attribution and the Zcash boundary

The researcher’s original address disclosure is the basis for investigating C. Triple-A’s statement establishes what the company said about its incident, but it does not attest that C, R or each DAI recipient was a company-controlled wallet. The explorer nametag and the company statement must not be collapsed into an independent ownership finding. Valid transaction execution likewise does not establish human consent.

The later public Zcash allegation does not provide a deposit-specific source hash, service order and destination fulfillment for this selected route. No transparent Zcash receipt or post-mixer withdrawal is verified here. Its absence from the checked evidence is not proof that no such movement occurred. The report’s confirmed route ends at the Ethereum pools.

Alternative explanations remain for control and purpose: different users can share services, and similar batching does not prove a shared operator. A key compromise, an unauthorized internal action and an authorized movement require different authorization evidence. The examined transfers alone cannot choose among them. The broader October deposit grouping is not imported as a verified 5,220 ETH attribution bound; its complete history, opening balance and joins have not been independently reproduced.

The next records are specific

For a focused service or incident review, retain the exact hashes, token contract and receipt-log indices before requesting a broader cluster. No verified custodial-exchange deposit is identified in this selected evidence, so no exchange freeze target or successful cash-out is claimed. No party was contacted, no legal request was sent and no recovery action was executed.

The bounded conclusion is now materially firmer. Seven checked DAI receipts explain nearly all of thirteen checked departures, and 28 successful ETH transactions document 2,620 ETH entering two labeled pools through one router. Ownership, the connecting conversion, complete balances and post-pool destinations remain separate questions. The accounting repair supports a clearer report—not a larger loss claim.

Appendix A — full Ethereum address roles

Each address link targets Ethereum’s address-detail page. Role names establish neither natural-person identity nor ownership. Pool names are attributed explorer labels; no current legal status is inferred from historical label text.

Appendix B — transaction evidence and methodology

All times below are UTC. Rows are deduplicated by hash within each inventory. An event-level key is transaction hash plus log index, so multiple events in one transaction must not be silently merged. Amounts retain recorded precision; transaction fees are separate ETH costs.

Incoming DAI

I01

I02

I03

I04

I05

I06

I07

Outgoing DAI

O01

O02

O03

O04

O05

O06

O07

O08

O09

O10

O11

O12

O13

Selected ETH deposit inventory

P01–P26 each display 100 ETH to the router and matching forwarding to the 100 ETH pool. P27/P28 each display 10 ETH to the router and matching forwarding to the 10 ETH pool. All have successful status. Decimal ETH shown on the explorer is used here; no raw RPC receipt or execution replay is claimed.

Source and verification boundary: company statement for the company’s incident account; researcher alert for the seed attribution; later allegation for the unresolved Zcash claim; Etherscan transaction details and canonical event logs for the checked records. SentinelTX supplied the original investigation and repair leads; its larger graph totals and unverified attribution bounds are not adopted. Explorer checking is not execution replay, hardware examination, proof of operator identity or a full multi-chain audit.