Background
The DAO recently voted to update the Bill Broker logic with a new price curve structure.
The old fee curves were flat at the tails:
While the new fee curves approach each other at the tails:
The upside of the new structure is that it allows the Bill Broker to remain in the market conducting trades for longer rather than sitting on the sidelines for sometimes extended periods of time. The downside is that these negative fees at the tails can lead to impermanent loss, as one would see in typical AMMs.
This occurrence was especially impactful at this instance because the Broker walked to an asset ratio with one curve, then immediately walked back using the different curve and different pricing structure.
When the logic updates were deployed, the asset ratio was far away from 1.0, which led to a near instant arbitrage against other markets by flash bots agents. This (rather impressive) transaction executed in the very next block, 12 seconds later, and can be seen here. Accounting for the profit and fee to the builder, there was a total profit of $34,030.35026. Interestingly, most of this went to the block builder.
Compensation
I propose doing a one-time compensation to the Bill Broker LPs at the time of the asset rebalance after the update occurred.
The LP addresses and BB-LP note balances at the time were:
| Rank | Address | Quantity | Percentage |
|---|---|---|---|
| 1 | 0x190f13321c37c3124e73ca530680e6b97bf930ec | 26,345,355,690.08 | 30.39% |
| 2 | 0xcb7e8cbbbd45f66efd699a538a67bf8c0e5f0636 | 20,362,096,737.29 | 23.49% |
| 3 | 0x62336d8a9651795de47aabd3aa22f2dc68d21072 | 12,279,513,029.83 | 14.17% |
| 4 | 0x270c71a312210d0dc87d5f43d5d10840599c8938 | 9,882,938,145.30 | 11.40% |
| 5 | 0x814611f0eb8c0befb5b6892ca836e51784e9b9b4 | 8,968,083,246.23 | 10.35% |
| 6 | 0x4c37700d949db46aa11a9f1627070f9af31f8011 | 2,945,009,759.30 | 3.40% |
| 7 | 0xe683c0751eacee3e6c4446bfa509413f2fb680dc | 2,200,000,000 | 2.54% |
| 8 | 0xe692171e4d49d4b889b218ebbe7eee2606e8744e | 1,736,996,537.98 | 2.00% |
| 9 | 0x4a8c0ae6d6590b4f8403e7cf0006a91d6be55155 | 770,420,860.20 | 0.89% |
| 10 | 0xb623352e078e57349fe5a8de96109e2395cb20fe | 548,509,817.32 | 0.63% |
| 11 | 0x0d0aca99686fced8e6fb39134aaed96f09b5283c | 484,498,382.40 | 0.56% |
| 12 | 0x234b6ea3094392ebf49393c0e73a54a5a31f29a1 | 123,437,610.84 | 0.14% |
| 13 | 0x5d13c850f3e8eb925b8ab73155b8d8b610e16e5a | 27,632,770.10 | 0.03% |
| 14 | 0x92891f12c9448fec7750aff2eb697a62b87659f8 | 12,620,954.29 | 0.01% |
| 15 | 0xa088aef966cad7fe0b38e28c2e07590127ab4ccb | 10,000 | 0.00% |
Which would lead to a proposed compensation structure of:
| Rank | Address | USDC |
|---|---|---|
| 1 | 0x190f13321c37c3124e73ca530680e6b97bf930ec | 10342.26584 |
| 2 | 0xcb7e8cbbbd45f66efd699a538a67bf8c0e5f0636 | 7993.457033 |
| 3 | 0x62336d8a9651795de47aabd3aa22f2dc68d21072 | 4820.501205 |
| 4 | 0x270c71a312210d0dc87d5f43d5d10840599c8938 | 3879.698142 |
| 5 | 0x814611f0eb8c0befb5b6892ca836e51784e9b9b4 | 3520.541825 |
| 6 | 0x4c37700d949db46aa11a9f1627070f9af31f8011 | 1156.113089 |
| 7 | 0xe683c0751eacee3e6c4446bfa509413f2fb680dc | 863.6562592 |
| 8 | 0xe692171e4d49d4b889b218ebbe7eee2606e8744e | 681.9001585 |
| 9 | 0x4a8c0ae6d6590b4f8403e7cf0006a91d6be55155 | 302.4277228 |
| 10 | 0xb623352e078e57349fe5a8de96109e2395cb20fe | 215.3100261 |
| 11 | 0x0d0aca99686fced8e6fb39134aaed96f09b5283c | 190.1956276 |
| 12 | 0x234b6ea3094392ebf49393c0e73a54a5a31f29a1 | 48.45921877 |
| 13 | 0x5d13c850f3e8eb925b8ab73155b8d8b610e16e5a | 10.85568173 |
| 14 | 0x92891f12c9448fec7750aff2eb697a62b87659f8 | 4.968431138 |
| Total | 34030.35026 |
Given the small number of address affected, I think fastest and easiest way to handle the payments is simply to send direct USDC transactions, rather than any more complicated claim structure.
If you are affected and you believe this data in incorrect, please reach out here or on the Discord server.