[BIP-653] Build a paylod for Paladin's bribe to liquidity mining

PR with Payload

Revised:

Tldr:

Build a payload to enable Inverse and Threshold to take advantage of Paladin’s latest feature, bribe to liquidity mining, for their veBAL gauges.

Context:

Paladin quests provide DAOs with the ability to failover incentives intended to buy veBAL votes to direct incentives in cases where the target ROI is not reached through buying votes. As part of this process a number of gauges listed below were set up by the Balancer Maxis to allow Paladin’s questboard contract to distribute direct rewards in the required tokens. This work has revolved around work with Inverse Finance and Threshold who are customers of Paladin.
Paladin has upgraded to a new version of the questboard, and a new contract needs to take over the ability to distribute tokens. The quest contract does not have the capability to renounce its distributorship. This BIP therefore requests that the DAO multisig execute a transaction to move distributorship on the below mentioned gauges to the new Paladin quest contract.

Rationale:

Inverse Finance and Threshold are incentivizing liquidity provision across various pools, including DOLA/USDC, PYUSD/DOLA and sDOLA/DOLA for Inverse and 80/20 tBTC, base-tBTC+wETH, Arbi 50tBTC-50WETH, arbi-WBTC+tBTC and 2BTC for Threshold through veBAL voting incentives. Recently, the effectiveness of these voting incentives has turned net negative in free markets due to the correlation between the volume of incentives and the dilutive effect of available votes.

Gauges and Tokens:

Pool name Gauge address Reward token address
Balancer DOLA/USDC StablePool 0xbc02ef87f4e15ef78a571f3b2adcc726fee70d8b 0x41d5d79431a913c4ae7d69a668ecdfe5ff9dfb68
sDOLA Stable Pool 0xCD19892916929F013930ed628547Cc1F439b230e 0x41d5d79431a913c4ae7d69a668ecdfe5ff9dfb68
2BTC 0x21c377cBB2bEdDd8534308E5CdfeBE35fDF817E8 0xcdf7028ceab81fa0c6971208e83fa7872994bee5

Specification:

The DAO Mulitsig on mainnet would grant itself the ability to call set_reward_distributor on the gauge deployment. It would then call this function for each gauge/token in the list above, specifying the relevant token as the token address, and the new Paladin V2 Questboard(0xfEb352930cA196a80B708CDD5dcb4eCA94805daB) as the distributor. Finally the DAO multisig would revoke its own rights to call set_reward_distributor.

Mainnet - Part A

The DAO Multisig eth:0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 and call grantRole passing 0xd0090a09f425bba74e6c801fba7c6d15b44147ab0bd319e40076ce07e95168b6 which corresponds to set_reward_distributor verifiable here.

The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will then write set_reward_distributor for each gauge address on mainnet in the table above passing the corresponding reward token address as reward_token and 0xfEb352930cA196a80B708CDD5dcb4eCA94805daB as the distributor.

Lastly,
The DAO Multisig eth:0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 and call revokeRole passing 0xd0090a09f425bba74e6c801fba7c6d15b44147ab0bd319e40076ce07e95168b6 which corresponds to set_reward_distributor.

1 Like

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

Note that the originally submitted payload was unable to be executed due to it’s attempt to make admin calls to a Gauge (vyper) without going through the AuthorizerAdapterEntrypoint.

The Balancer Maxi’s have discussed and agreed that revising the payload to use the proper authentication method is not a significant change in the intention of this BIP, or in the operational effect of the proposed payload. We have decided to go ahead and load the below revised payload without further governance.

Please say something in the next 24 hours if you find this problematic and we can run another BIP with the new payload:

2 Likes