Payload PR
Background
A few weeks ago, Balancer Labs was notified of a bug in the MerkleOrchard contracts that were used to distribute token incentives before the migration to the new ve-tokenomics early last year. [1]
Funds were safely transferred to the Balancer DAO treasury to be distributed by a patched MerkleOrchard contract. This proposal contains the specs of this distribution.
Recovered Funds
The following table contains the amounts recovered from the MerkleOrchard contracts on each network by each one of the original distributors.
Network | Token | Token Address | Distributor | Txn | Amount |
---|---|---|---|---|---|
Mainnet | UNN | 0x226f7b842E0F0120b7E194D05432b3fd14773a9D | 0xBfbd6e720ffdF0497f69C95E5C03a4861C65A6E7 | link | 1,190,799.413994535558 |
Mainnet | BANK | 0x2d94AA3e47d9D5024503Ca8491fcE9A2fB4DA198 | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | link | 267,578.13837963 |
Mainnet | D2D | 0x43D4A3cd90ddD2F8f4f693170C9c8098163502ad | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | link | 18,320.05907868 |
Mainnet | LDO | 0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32 | 0x55c8De1Ac17C1A937293416C9BCe5789CbBf61d1 | link | 287,507.81357388 |
Mainnet | BAL | 0xba100000625a3754423978a60c9317c58a424e3D | 0xd2EB7Bd802A7CA68d9AcD209bEc4E664A9abDD7b | link | 296,749.181334172154 |
Mainnet | NOTE | 0xCFEAead4947f0705A14ec42aC3D44129E1Ef3eD5 | 0xF1C2dD9bD863f2444086B739383F1043E6b88F69 | link | 53,281.96362422 |
Polygon | WMATIC | 0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270 | 0x632208491602Dd205da8Cb9C0BA98620fc19854A | link | 23,488.53484699 |
Polygon | TUSD | 0x2e1AD108fF1D8C782fcBbB89AAd783aC49586756 | 0x09F3010Ec0f6d72EF8fF2008F8E756d60482c9A8 | link | 11,693.113764907596 |
Polygon | TUSD | 0x2e1AD108fF1D8C782fcBbB89AAd783aC49586756 | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | link | 31,666.40222074 |
Polygon | QI | 0x580A84C73811E1839F75d86d75d88cCa0c241fF4 | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | link | 9,067.62018152 |
Polygon | BAL | 0x9a71012B13CA4d3D0Cdc72A177DF3ef03b0E76A3 | 0xd2EB7Bd802A7CA68d9AcD209bEc4E664A9abDD7b | link | 33,852.28963519357 |
Polygon | LDO | 0xC3C7d422809852031b44ab29EEC9F1EfF2A58756 | 0x87D93d9B2C672bf9c9642d853a8682546a5012B5 | link | 5,462.47456626 |
Arbitrum | BAL | 0x040d1EdC9569d4Bab2D15287Dc5A4F10F56a56B8 | 0xd2EB7Bd802A7CA68d9AcD209bEc4E664A9abDD7b | link | 17,864.433032306076 |
Arbitrum | PICKLE | 0x965772e0E9c84b6f359c8597C891108DcF1c5B1A | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | link | 2,265.85940708 |
Redistributing outstanding claims
In a branch in the original bal-mining repository, a script was developed to check the claim status for each one of the LPs in the original distributions. Outstanding claims were then aggregated into a single one for each network and token.
Network | Token Address | Amount |
---|---|---|
Mainnet | 0x226f7b842e0f0120b7e194d05432b3fd14773a9d | 1,190,799.41399 |
Mainnet | 0x2d94aa3e47d9d5024503ca8491fce9a2fb4da198 | 267,578.13838 |
Mainnet | 0x43d4a3cd90ddd2f8f4f693170c9c8098163502ad | 14,891.48765 |
Mainnet | 0x5a98fcbea516cf06857215779fd812ca3bef1b32 | 287,507.81357 |
Mainnet | 0xba100000625a3754423978a60c9317c58a424e3d | 296,749.18133 |
Mainnet | 0xcfeaead4947f0705a14ec42ac3d44129e1ef3ed5 | 53,281.96362 |
Polygon | 0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270 | 23,488.53485 |
Polygon | 0x2e1ad108ff1d8c782fcbbb89aad783ac49586756 | 43,359.51598 |
Polygon | 0x580a84c73811e1839f75d86d75d88cca0c241ff4 | 9,067.62018 |
Polygon | 0x9a71012b13ca4d3d0cdc72a177df3ef03b0e76a3 | 33,852.28964 |
Polygon | 0xc3c7d422809852031b44ab29eec9f1eff2a58756 | 462.47457 |
Arbitrum | 0x040d1edc9569d4bab2d15287dc5a4f10f56a56b8 | 17,864.43303 |
Arbitrum | 0x965772e0e9c84b6f359c8597c891108dcf1c5b1a | 2,265.85941 |
Resolving inconsistencies
On Polygon, 5k LDO were seeded in excess by the distributor (2 x 2.5k, on weeks 97 and 98)
- week 97 specs
- week 98 specs
- LDO token transfers from the distributor to the orchard
- If this proposal is approved, 5k LDO will be transferred back to the original distributor,
0x87d93d9b2c672bf9c9642d853a8682546a5012b5
On Mainnet, ~3,428.57 D2D were seeded in excess by the distributor
- week 97 specs set the weekly amount at 6k for APR computation purposes…
- …but at that point, due to the transition to veBAL, the liquidity mining script downscaled that amount to 3/7
6000 * 4 / 7 = 3428.57
- If this proposal is approved, 3,428.57 D2D will be transferred back to the original distributor,
0xc38c5f97B34E175FFd35407fc91a937300E33860
On Mainnet, there was a leftover of 2,250,000 UNN in the distributor controlled by ecosystem participants. Those had been earmarked for distributions of 6 weeks worth of incentives, which ultimately were airdropped instead along with another 6 weeks.
- Those funds were also transferred to the DAO Multisig
- If this proposal is approved, 2,250,000 UNN will be transferred back to the original distributor,
0xBfbd6e720ffdF0497f69C95E5C03a4861C65A6E7
Specification
On mainnet, the DAO multisig(0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f
) will transfer:
- 3428.57 D2D to
0xc38c5f97B34E175FFd35407fc91a937300E33860
which is the LM multisig operated by the Maxis. The Maxi’s will contact D2D and return these tokens to their desired destination - 2,250,000 UNN to
0xBfbd6e720ffdF0497f69C95E5C03a4861C65A6E7
On polygon, the DAO multisig(0xeE071f4B516F69a1603dA393CdE8e76C40E5Be85
) will transfer 5000 LDO to 0x87d93d9b2c672bf9c9642d853a8682546a5012b5
For each of the following Merkle Orchards per chain:
mainnet = 0xE3881627B8DeeBCCF9c23B291430a549Fc0bE5F7
polygon = 0xc3ccacE87f6d3A81724075ADcb5ddd85a8A1bB68
arbitrum = 0x9805dcfD25e6De36bad8fe9D3Fe2c9b44B764102
The DAO multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f
on mainnet and 0xaF23DC5983230E9eEAf93280e312e57539D098D0
on Arbitrum and 0xeE071f4B516F69a1603dA393CdE8e76C40E5Be85
on polygon will call:
approve(orchard_address, raw amount) on each of the tokens listed in the table above where raw_amount is the remaining balance of the given token after the special processing described above.
followed by:
calling createDistribution(token, merkleRoot, amount, 1) on the specified orchard for the given chain. Where for token and amount comes from the table above, and the merkleRoot is identified by the the given token/chain identified in the Incident Handling PR as _roots*
The changes are described in exact detail in the transaction builder json payload files per chain linked at the top of this BIP.