[BIP-196] Redistribution of recovered legacy incentives

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)

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.

4 Likes

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

1 Like

https://snapshot.org/#/balancer.eth/proposal/0xc46dd903439c1c29fa85738cf339c236735f62944e2fc8b265e753745ca6b7ef

I spoke to Luuk to get an address to send the D2D back to PrimeDAO and he gave me 0x567d220B0169836cBF351DF70A9c517096ec9De7

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.

1 Like

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), 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.

4 Likes

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.

4 Likes