[BIP-498] Assisting DNS hack victims - final batch


Following the developments after the DNS hack reported here, and given the precedent set by BIP-443 and BIP-455, this proposal seeks to refund affected users by the frontend attack with 25% cut.


After refunds of BIP-443 and BIP-455, only 1 (one) user came forward publicly reporting the loss of funds due to the DNS attack. There could potentially be others that might be waiting for the formation of the volunteer committee described on BIP-433 and/or the public announcement of a claiming window.

Given the past refund allocations and known wallets impacted, the expenditure shouldn’t be greater than 34k, even though the program would still have 110.578,95 USDC provisioned. We find it would be better to put this program behind us and therefore suggest using the same deadline in the [BIP-445] regarding the Boosted Pools incident.


This proposal will override the specifications on BIP-443, and shall be voted as follows:

  1. Affected users will have until Dec 25th, 2023 to post on this thread (or by any means reach out to the Balancer Maxis), being this a final deadline to ask for refunds in a final payment batch coming January.
  2. To verify claims, the Balancer Maxis will cross-reference the user’s reported transactions with the spreadsheet made public in the incident post-mortem.
  3. Users will be asked to verify wallet ownership with a signed message on chain agreeing to the 75% cut and payment in USDC at the time of the attacks (precedent set by BIP-443).
  4. Final numbers will be posted in January’24 on a new BIP authorizing payments.

If passed, this proposal shall be posted by our Marketing team on Discord and Twitter, as well as any interested media outlets, for max comms amplification regarding the deadline.



This seems like a good resolution. Aura Contributors support this proposal.


How do I verify/submit my address and TXN’s to this claim?

1 Like

can you elaborate on why you think these transactions were a result of this particular dns hack?

although the txs you share consist of an approval to the malicious 0x00006DEAcd9ad19dB3d81F8410EA2B45eA570000, there is no transferFrom call from that address to the balancer attacker (0x645710Af050E26bB96e295bdfB75B4a878088d7E).

instead, stolen tokens are sent to the angel drainer address (0x412f10AAd96fD78da6736387e2C84931Ac20313f), which, although also involved in this dns hack, is a much more general scam/phishing address which has been involved in a wide scala of hacks (and is even still active today).

the fact that no transfers to the balancer attacker’s address took place, make it tough to relate your transactions to this particular dns hack.

1 Like

Well, the best I can do is this:
My browser history from the date of the DNS attack.

The two transactions as I initially discovered them

and, the Balancer.Fi site (note the HTTPS) as I later found it while re-tracing my activity.

As for proving a connection between the 0x412f10A Angel-Drainer’s address and that of the “attackers” (0x0006DEA). I’ve got nothing. Never the less, these funds were most certainly, maliciously transfer(ed)From my wallet on Sept 9th, 2023 as a result of the DNS hack on the Balancer.Fi website.

I simply don’t know what more I can/must/should produce to support my claim.

I’m seeing 4 transactions (5 total, but 1 was on Optimism, not Ethereum) on the spreadsheet with the transferFrom function by the same 0x00006DEAcd9ad19dB3d81F8410EA2B45eA570000 address (a.k.a. Fake_Phishing180397 per Etherscan); ALL 4 of them for the same Aave: Ethereum WETH V3 (aEthWETH) token, and happening ~1hr before my transaction(s).
Is there some material difference between those transactions and the two I’ve submitted?
(Asking in part for my own understanding here too.)

the difference with those transactions is that that victim (0xd14f0) also had a transferFrom with the actual balancer attacker address (0x64571) as the destination (tx hash 0x382dac2643fff099fcbe21c893ea807f66faf2a896ca7fe1be79ed5156c528e5).

for the optimism tx i agree with you though, the only difference with your tx there is that the destination was set to that 0x00006DEA. your destination was set to the angel drainer (0x412f1) directly, which is why the query missed yours.

a case could be made for including yours or excluding the optimism one—the problem is that it is practically impossible to prove the relationship either way.

given your screenshots however i would consider it plausible this was also a result of the dns hack. let me get a second opinion from someone else on how to proceed.


we have updated the query and gsheet to include transfers to the angel drainer (0x412f1) via 0x00006DEA during the time of the dns hack. this resulted in a total of 6 more transfers covered by this bip, worth a total of $8246.27.

this includes the two transactions you reported @derekclair.

1 Like

I’m genuinely impressed with the Balancer team on this one, both here and in the Discord server (not sure if you guys are staff or volunteer, but either way) my hat goes off to the effort and commitment put into this initiative. Refreshing to see in this space, and encouraging for the industry as a whole; in toto an exemplary display of integrity.

Regardless of the outcome of the vote, my personal thanks to all of you.