# \[BIP-196\] Redistribution of recovered legacy incentives **URL:** \ **Category:** General Proposal\ **Created:** [February 17, 2023, 6:53pm UTC](https://forum.balancer.fi/t/bip-196-redistribution-of-recovered-legacy-incentives/4422 "2023-02-17T18:53:43Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![markus](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/markus/32/880_2.png) [@markus](https://forum.balancer.fi/u/markus)\ **Post date:** [February 17, 2023, 6:53pm UTC](https://forum.balancer.fi/t/bip-196-redistribution-of-recovered-legacy-incentives/4422/1 "2023-02-17T18:53:43Z")
## [Payload PR](https://github.com/BalancerMaxis/multisig-ops/pull/80) # 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]](https://twitter.com/Balancer/status/1620503172702953475) 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](https://etherscan.io/tx/0xecdc6c451db1c8882562ac9b9aac1b584ecd2095ed369466cdec3cd8013a3e6a) | 1,190,799.413994535558 | | Mainnet | BANK | 0x2d94AA3e47d9D5024503Ca8491fcE9A2fB4DA198 | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | [link](https://etherscan.io/tx/0x6561c0b6f418268fcbf8ca0d791b86d2f5d31ad75c5f65311dfedd076f5ebbda) | 267,578.13837963 | | Mainnet | D2D | 0x43D4A3cd90ddD2F8f4f693170C9c8098163502ad | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | [link](https://etherscan.io/tx/0x6561c0b6f418268fcbf8ca0d791b86d2f5d31ad75c5f65311dfedd076f5ebbda) | 18,320.05907868 | | Mainnet | LDO | 0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32 | 0x55c8De1Ac17C1A937293416C9BCe5789CbBf61d1 | [link](https://etherscan.io/tx/0x8a87275dc0e221603e8b48fd9a7758cc61090fe98afd26b33737f47938c05bdb) | 287,507.81357388 | | Mainnet | BAL | 0xba100000625a3754423978a60c9317c58a424e3D | 0xd2EB7Bd802A7CA68d9AcD209bEc4E664A9abDD7b | [link](https://etherscan.io/tx/0x751ef44aa2063df17beacac1d1debddeed308ce2af32068acf69ed62f749872c) | 296,749.181334172154 | | Mainnet | NOTE | 0xCFEAead4947f0705A14ec42aC3D44129E1Ef3eD5 | 0xF1C2dD9bD863f2444086B739383F1043E6b88F69 | [link](https://etherscan.io/tx/0x71a5a4ef8e40cb62dc2073e08b709cd0c92f5f96c4584c7b03835fe7c75f81bc) | 53,281.96362422 | | Polygon | WMATIC | 0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270 | 0x632208491602Dd205da8Cb9C0BA98620fc19854A | [link](https://polygonscan.com/tx/0x0642b29d44aee33893928dcccb98d978594ed4b7f7fe8505ec7a895d883a7aa8) | 23,488.53484699 | | Polygon | TUSD | 0x2e1AD108fF1D8C782fcBbB89AAd783aC49586756 | 0x09F3010Ec0f6d72EF8fF2008F8E756d60482c9A8 | [link](https://polygonscan.com/tx/0x71f9a6b3dfaf24a8c3e5fef18c0ff80f66b227c9d0e1e7f1784e971b99d8df89) | 11,693.113764907596 | | Polygon | TUSD | 0x2e1AD108fF1D8C782fcBbB89AAd783aC49586756 | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | [link](https://polygonscan.com/tx/0x2dff3b0792863b6bb60b917366c6f543e0f730b9aeb88c3c243b7ddf6ed21e12) | 31,666.40222074 | | Polygon | QI | 0x580A84C73811E1839F75d86d75d88cCa0c241fF4 | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | [link](https://polygonscan.com/tx/0x2dff3b0792863b6bb60b917366c6f543e0f730b9aeb88c3c243b7ddf6ed21e12) | 9,067.62018152 | | Polygon | BAL | 0x9a71012B13CA4d3D0Cdc72A177DF3ef03b0E76A3 | 0xd2EB7Bd802A7CA68d9AcD209bEc4E664A9abDD7b | [link](https://polygonscan.com/tx/0x627bfe6a01a838486c932fcbc8a8ad2b8a6cb2847fe455be0442cc41252ba097) | 33,852.28963519357 | | Polygon | LDO | 0xC3C7d422809852031b44ab29EEC9F1EfF2A58756 | 0x87D93d9B2C672bf9c9642d853a8682546a5012B5 | [link](https://polygonscan.com/tx/0xdcfd36d2f6d72d9858296d42453fb86013da241b4fa61923079e0900a0ae4143) | 5,462.47456626 | | Arbitrum | BAL | 0x040d1EdC9569d4Bab2D15287Dc5A4F10F56a56B8 | 0xd2EB7Bd802A7CA68d9AcD209bEc4E664A9abDD7b | [link](https://arbiscan.io/tx/0xb1f69f82a21a274ba0c99db5b9ea9c8bea8fe6297113ea248dbf155273620c3f) | 17,864.433032306076 | | Arbitrum | PICKLE | 0x965772e0E9c84b6f359c8597C891108DcF1c5B1A | 0xc38c5f97B34E175FFd35407fc91a937300E33860 | [link](https://arbiscan.io/tx/0xf412f4e2890abaf5adb5a0a2143340b93eb8ec13b5adc0008ed154e67c277f76) | 2,265.85940708 | # Redistributing outstanding claims [In a branch](https://github.com/balancer-labs/bal-mining-scripts/tree/incident-response) 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](https://github.com/balancer-labs/frontend-v2/pull/1628/files#diff-79394f4e3e933b0f855b34ae87db5c4499edcdf5985dbf26782cef7f3323b4b5R14521) - [week 98 specs](https://github.com/balancer-labs/frontend-v2/pull/1686/files#diff-79394f4e3e933b0f855b34ae87db5c4499edcdf5985dbf26782cef7f3323b4b5R14747) - [LDO token transfers](https://polygonscan.com/token/0xc3c7d422809852031b44ab29eec9f1eff2a58756?a=0x0f3e0c4218b7b0108a3643cfe9d3ec0d4f57c54e) 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](https://github.com/balancer-labs/frontend-v2/pull/1628/files#diff-79394f4e3e933b0f855b34ae87db5c4499edcdf5985dbf26782cef7f3323b4b5R14275-R14286) set the weekly amount at 6k for APR computation purposes… - …but at that point, due to the transition to veBAL, the [liquidity mining script](https://github.com/balancer-labs/bal-mining-scripts/commit/5ccb1e74ad146c9176006429777e9300c109b8b8) 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](https://etherscan.io/tx/0xfc71a601e873523f0501b050622c92ba1a922c917f9fd169dc05433237240fab) instead along with another 6 weeks. - Those funds were also [transferred](https://etherscan.io/tx/0x58b9dbf470d4415478031a637fea7117e70e6d89c857755f9907d9a1f1a90ff3) 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](https://github.com/balancer-labs/bal-mining-scripts/tree/incident-response/reports/_incident-response) 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. ---
**Author:** ![Tritium](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/tritium/32/2011_2.png) [@Tritium](https://forum.balancer.fi/u/Tritium)\ **Post date:** [February 22, 2023, 10:24pm UTC](https://forum.balancer.fi/t/bip-196-redistribution-of-recovered-legacy-incentives/4422/2 "2023-02-22T22:24:14Z")
Note that the addresses for the upgraded MerkleOrchard can be found here: [balancer-v2-monorepo/pkg/deployments/tasks/20230222-merkle-orchard-v2/output at deployment/merkle-orchard-v2 · balancer-labs/balancer-v2-monorepo · GitHub](https://github.com/balancer-labs/balancer-v2-monorepo/tree/deployment/merkle-orchard-v2/pkg/deployments/tasks/20230222-merkle-orchard-v2/output) ---
**Author:** ![Xeonus](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/xeonus/32/3621_2.png) [@Xeonus](https://forum.balancer.fi/u/Xeonus)\ **Post date:** [February 23, 2023, 7:23am UTC](https://forum.balancer.fi/t/bip-196-redistribution-of-recovered-legacy-incentives/4422/3 "2023-02-23T07:23:57Z")
[https://snapshot.org/#/balancer.eth/proposal/0xc46dd903439c1c29fa85738cf339c236735f62944e2fc8b265e753745ca6b7ef](https://snapshot.org/#/balancer.eth/proposal/0xc46dd903439c1c29fa85738cf339c236735f62944e2fc8b265e753745ca6b7ef) ---
**Author:** ![solarcurve](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/solarcurve/32/1487_2.png) [@solarcurve](https://forum.balancer.fi/u/solarcurve)\ **Post date:** [February 23, 2023, 11:59am UTC](https://forum.balancer.fi/t/bip-196-redistribution-of-recovered-legacy-incentives/4422/4 "2023-02-23T11:59:58Z")
I spoke to Luuk to get an address to send the D2D back to PrimeDAO and he gave me `0x567d220B0169836cBF351DF70A9c517096ec9De7` ---
**Author:** ![Tritium](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/tritium/32/2011_2.png) [@Tritium](https://forum.balancer.fi/u/Tritium)\ **Post date:** [February 23, 2023, 12:08pm UTC](https://forum.balancer.fi/t/bip-196-redistribution-of-recovered-legacy-incentives/4422/5 "2023-02-23T12:08:02Z")
Note that as this BIP mandates the Maxis to make this transfer anyway, we have changed the recipient address for the D2D from the specification originally posted above. If this is found to be an issue by any of the payload reviewers, the old payload can be used and the Maxi’s can handle the payment to Prime in a separate TX. > ---
**Author:** ![nventuro](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/nventuro/32/49_2.png) [@nventuro](https://forum.balancer.fi/u/nventuro)\ **Post date:** [February 23, 2023, 3:43pm UTC](https://forum.balancer.fi/t/bip-196-redistribution-of-recovered-legacy-incentives/4422/6 "2023-02-23T15:43:24Z")
> [@Tritium](#): > > Note that the addresses for the upgraded MerkleOrchard can be found here: [balancer-v2-monorepo/pkg/deployments/tasks/20230222-merkle-orchard-v2/output at deployment/merkle-orchard-v2 · balancer-labs/balancer-v2-monorepo · GitHub](https://github.com/balancer-labs/balancer-v2-monorepo/tree/deployment/merkle-orchard-v2/pkg/deployments/tasks/20230222-merkle-orchard-v2/output) This was incorrectly handled: this post linked to a branch that was not yet merged into the `master` branch, which is where the official deployments live. In the end, the branch was merged and the addresses did not change (found [here](https://github.com/balancer-labs/balancer-v2-monorepo/tree/master/pkg/deployments/tasks/20230222-merkle-orchard-v2)), but they could have. In this particular case code verification was failing, which means that the addresses could at that point contain arbitrary code, **including a malicious contract that could have easily stolen all $3M from the distribution**. It would not be particularly hard to achieve this. Fortunately the reason why verification was failing was due to unrelated issues with the Polygon network. There’s a reason why we have processes in place, and it’s important to not rush blindly forward just to get things done fast. Deployment addresses and Authorizer action IDs should **only** be retrieved from the `master` branch, where we have systems in place that guarantee they are correct. ---
**Author:** ![Tritium](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/tritium/32/2011_2.png) [@Tritium](https://forum.balancer.fi/u/Tritium)\ **Post date:** [February 23, 2023, 4:43pm UTC](https://forum.balancer.fi/t/bip-196-redistribution-of-recovered-legacy-incentives/4422/7 "2023-02-23T16:43:58Z")
> [@nventuro](#): > > This was incorrectly handled: this post linked to a branch that was not yet merged into the `master` branch, which is where the official deployments live. In the end, the branch was merged and the addresses did not change (found [here](https://github.com/balancer-labs/balancer-v2-monorepo/tree/master/pkg/deployments/tasks/20230222-merkle-orchard-v2)), but they could have. > > In this particular case code verification was failing, which means that the addresses could at that point contain arbitrary code, **including a malicious contract that could have easily stolen all $3M from the distribution**. It would not be particularly hard to achieve this. Fortunately the reason why verification was failing was due to unrelated issues with the Polygon network. > > There’s a reason why we have processes in place, and it’s important to not rush blindly forward just to get things done fast. Deployment addresses and Authorizer action IDs should **only** be retrieved from the `master` branch, where we have systems in place that guarantee they are correct. Thanks. Someone else gave me that PR address and I didn’t check that it was the master branch. Going forward we will make this validation when posting BIPs.