# \[BIP-653\] Build a paylod for Paladin's bribe to liquidity mining **URL:** \ **Category:** BAL Gauges\ **Created:** [June 26, 2024, 5:01pm UTC](https://forum.balancer.fi/t/bip-653-build-a-paylod-for-paladins-bribe-to-liquidity-mining/5835 "2024-06-26T17:01:45Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![AkgEmilio](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/akgemilio/32/3265_2.png) [@AkgEmilio](https://forum.balancer.fi/u/AkgEmilio)\ **Post date:** [June 26, 2024, 5:01pm UTC](https://forum.balancer.fi/t/bip-653-build-a-paylod-for-paladins-bribe-to-liquidity-mining/5835/1 "2024-06-26T17:01:45Z")
### PR with Payload > > > NEEDS AN UPDATE AND INFO FROM PALADIN. > https://forum.balancer.fi/t/bip-xxx-buil…d-a-paylod-for-paladins-bribe-to-liquidity-mining/5835 > > Need Paladin to validate their desired reward token to take distributorship of on Arbitrum is indeed 0x0945Cae3ae47cb384b2d47BC448Dc6A9dEC21F55. Originally they had 0xcdf7028ceab81fa0c6971208e83fa7872994bee5 but I (Zen) assumed this change on their forum post. > > Mainnet payload can interact directly with Authorizer, on Arbitrum i needed to go through AuthorizerAdapterEntrypoint. As for Base i am not sure what they want the gauge the named has no rewards added at this time and desired reward token is the mainnet T address. I expect they just need an add\_reward we can do without governance. Revised: > > > Note that #1107 does not properly use the authorizer adapter to execute calls on… vyper contracts. These change simply send the same calldata through the proper passhthrough contract. **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](https://github.com/balancer/balancer-deployments/blob/22c7f941f49dfc3ed02b8e6ba289065514ebf21f/action-ids/mainnet/action-ids.json#L727C53-L727C119). 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`. ---
**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:** [July 3, 2024, 6:32pm UTC](https://forum.balancer.fi/t/bip-653-build-a-paylod-for-paladins-bribe-to-liquidity-mining/5835/2 "2024-07-03T18:32:18Z")
[https://snapshot.org/#/balancer.eth/proposal/0x5869cec1214f344fed63864a14aa56c1663f4469a34e4f7b94eaa5e1bd4ecd8a](https://snapshot.org/#/balancer.eth/proposal/0x5869cec1214f344fed63864a14aa56c1663f4469a34e4f7b94eaa5e1bd4ecd8a) ---
**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:** [July 22, 2024, 1:26pm UTC](https://forum.balancer.fi/t/bip-653-build-a-paylod-for-paladins-bribe-to-liquidity-mining/5835/3 "2024-07-22T13:26:22Z")
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: > > > Note that #1107 does not properly use the authorizer adapter to execute calls on… vyper contracts. These change simply send the same calldata through the proper passhthrough contract.