[BIP-560] Enable Single Recipient Gauge for GEM/ETH on [Ethereum]

BAL Gauges
1

PR with Payload

Summary:

Proposal to add a single recipient gauge for the 80/20 GEM/WETH pool on Ethereum and redirect emissions rewards to the locker contract that will serve as the base layer for Opal’s vlGEM governance module.

References/Useful links:

Protocol Description:

Opal is a protocol built on the Ethereum network and deemed to expand on multiple L2s overtime. It employs yield bearing “Omnipools”, which are liquidity pools where users can deposit single sided liquidity within a set of whitelisted assets such as LSTs, LRTs and Stablecoins.

The protocol value proposition is a set and forget, gas efficient, diversified and less time consuming access to numerous farming opportunities.

Omnipools are liquidity pools that Opal uses to allocate a single underlying asset across various Balancer pools and stake it on meta-governance protocols like Aura Finance to take advantage of the multi-level incentive structure. The core mechanisms of Omnipools are: deposits and withdrawals, LP token pricing, external staking and rebalancing of liquidity across Balancer pools.

Each Omnipool allocates liquidity to a set of whitelisted Balancer pools. The distribution between the underlying DEX’s pools is determined by Opal governance through gauges weights votes, defining the share of an Omnipool’s total liquidity that should be supplied to each underlying pool.

Motivation:

Since Opal will harness the 80/20 pool structure to scale the GEM liquidity, reduce impermanent loss (IL) and increase upside exposure to the base asset. Users can lock their Balancer 80/20 GEM/WETH BPTs to obtain vlGEM, which is Opal’s governance token.

This tokenomics design requires that BAL emissions directed toward the gauge are redirected to another reward manager contract that distributes it to vlGEM holders.

Opal wants to become a reliable buyer of incentives to maintain and grow its liquidity and exposure to the Balancer ecosystem. We believe this would be beneficial for all veBAL holders.

Specifications:

1. Governance:

Opal is governed by holders of vlGEM which is a 80/20 GEM/WETH BPT token through snapshot votes and on-chain proposals.

2. Oracles:

Opal relies on Chainlink (for supported tokens, and Redstone is implemented for tokens that are not supported by Chainlink) in order to compute BPT Token’s valuation using the formulas provided in the documentation for each type of pool.

3. Audits:

As security is Opal’s top priority, we decided to conduct two audits. The first one was assessed by Halborn Security for the whole contract suite. The second one was a Cantina competition, allowing independent security researchers to review the code base.

4. Centralization vectors:

Treasury functions are controlled through a multisig. The core team multisig executes actual on-chain governance decisions.

5. Market History: Balancer

$GEM being a governance and unpegged asset with a small market capitalisation, it will probably observe high volatility.

There is very few historical data yet but $GEM was first made available during a Fjord LBP in January. In 3 days, there was a lot of interest with more than $2.8M of volume. Furthermore, the 80/20 Balancer pool initial liquidity is $1M TVL.

6. Value:

The 80/20 GEM/WETH pool will be the primary source of liquidity for $GEM. Since we use the BPT token as our governance token, it will be in Opal’s best interest to funnel the volume of the GEM into this pool because it will reward our Governors and therefore generate consistent fees on Balancer.

Pool details:

Gauge Weight Cap: Opal proposes to cap the gauge emissions to 2%.

Gauge Type: A single recipient gauge used as part of the ve80/20 program. As a result BAL incentives will be paid out to a single smart contract that redirects these tokens to lockers.

Details of Gauge to be whitelisted

Gauge address 2% cap: 0x24B7AEEEFDB612D43F018Cbc9c325680f61Ec96d
Pool address: 0x57766212638c425e9CB0C6D6e1683dda369C0FFF

Author:
Christopher is Opal business development lead.

Specifications:

The Balancer Maxi LM Multisig eth:0xc38c5f97B34E175FFd35407fc91a937300E33860 will interact with the GaugeAdderv4 at 0x5DbAd78818D4c8958EfF2d5b95b28385A22113Cd and call the addGauge function with the following arguments:

gauge(address): 0x24B7AEEEFDB612D43F018Cbc9c325680f61Ec96d

gaugeType(string): EthereumSingleRecipientGauge

3 Likes
2

Hi there, exciting to see another ve80/20 project launch on Balancer! Could you clarify on the following:

  • The multi-sig that will receive rewards approves spending on the reward manager contract to distribute to vlGEM? Your multi-sig doesn’t seem to have getVotingEscrow implemented so we just want to make sure.
  • can you clarify the intent / how the yields are distributed from the multi-sig (doesn’t have to be technical)

Thanks

2 Likes
3

Hey! Thanks for your support in setting this up, we’re really enthusiastic to harness the power of 80/20 governance.

Basically MSig receives yield from the SingleRecipientGauge weekly and it will be queued on the vlToken contract to be distributed.
Later on we can see for an onchain permisionless system

1 Like
4

It’s a bit unusual tio be sending coins to a multisig like this. I suppose it is fine assuming the tokens are all really given to locekrs/used in tokenomics and not kept/sold by the treasury.

I think it’s fine as is, but this gauge should be killed if the single recipient gauge pointing at a multisig is abused/used for anything other than the intended purpose stated above.

2 Likes
5

Hello, thanks for the detail, the msig recipient is a different one than Opal treasury hence all txs and cash flows on that msig will be for the sole purpose of redistributing the gauge rewards to vlGEM holders.

3 Likes
6

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

1 Like