Instructions & Overview

BAL Gauges
#1

If you want to add a gauge for your pool to receive BAL emissions, please create a new topic in this category following the template which will appear upon creating the new topic.

Note that after you create a pool you must create a gauge for it before you start a governance proposal. Include the address of the gauge you deployed in your proposal.

For pools on Ethereum
This is the gauge factory on Ethereum. Simply call the create function with your pool’s contract address.

For pools on Polygon

  1. This is the child chain liquidity gauge factory on Polygon. Call create function with your pool’s polygon contract address.
  2. Go to read contract on the child chain liquidity gauge factory and call getPoolStreamer using your pool’s polygon contract address.
  3. This is the Polygon Root Gauge Factory - call create using the streamer contract address on polygon you got from the previous step. Then go to read contract and call getRecipientGauge using the same streamer contract address on polygon. The result of this query is your polygon root gauge that should be included in your gauge proposal.

For pools on Arbitrum

  1. This is the child chain liquidity gauge factory on Arbitrum. Call create function with your pool’s arbitrum contract address.
  2. Go to read contract on the child chain liquidity gauge factory and call getPoolStreamer using your pool’s optimism contract address.
  3. This is the Arbitrum Root Gauge Factory - call create using the streamer contract address on optimism you got from the previous step. Then go to read contract and call getRecipientGauge using the same streamer contract address on arbitrum. The result of this query is your arbitrum root gauge that should be included in your gauge proposal.

For pools on Optimism

  1. This is the child chain liquidity gauge factory on Optimism. Call create function with your pool’s optimism contract address.
  2. Go to read contract on the child chain liquidity gauge factory and call getPoolStreamer using your pool’s optimism contract address.
  3. This is the Optimism Root Gauge Factory - call create using the streamer contract address on optimism you got from the previous step. Then go to read contract and call getRecipientGauge using the same streamer contract address on optimism. The result of this query is your optimism root gauge that should be included in your gauge proposal.

Once you, the proposer, feel sufficient discussion has taken place you can request the proposal be moved to a snapshot vote by simply replying to the topic. If there is significant discussion ongoing and you request a vote too early it will increase the risk of a failed vote.

After a vote is requested, the Governance Council (solarcurve, zekraken, Mike B, Xeonus, and Zen Dragon) will vote on whether your proposal includes all the necessary information outlined in the topic creation template. Once a majority has voted in favor, one of us will post the proposal to snapshot.

All snapshot votes must last for three full days and be announced in Balancer’s discord and twitter. A quorum of 200k veBAL must be reached and the majority must vote in favor for a proposal to pass.

Please note that Balancer protocol has an Emergency subDAO, that empowers a small group to “kill” pools and gauges in the event of malicious activity and/or potential loss of funds. Ultimately, veBAL holders have the collective power over gauges activity, being able to kill gauges at anytime through governance regular voting process.

1 Like
[BIP-28] Kill CREAM/WETH Gauge
#2

For reference, the template:

Summary:

Describe what this proposal is about

References/Useful links:

Link to:
• Website
• Documentation
• Github Page
• Communities
• Other useful links?

Protocol Description:

Describe the proposed asset(s), the corresponding protocol(s), and historic prices of the token (price must come from the source of highest liquidity).

Motivation:

Explain why this pool needs incentivization

Specifications:

  1. Governance: Provide current information on the protocol’s governance structure. Provide links to any admin and/or multisig addresses, and describe the powers afforded to these addresses. If there are plans to change the governance system in the future, please explain.

  2. Oracles: Does the protocol rely on external oracles? If so, provide details about the oracles and their implementation in the protocol.

  3. Audits: Provide links to audit reports and any relevant details about security practices.

  4. Centralization vectors: Is there any component of the protocol that has centralization vectors? E.g. if only 1 dev manages the project, that is a centralized vector. If price oracles need to be updated by a bot, that is a centralized vector. If liquidations are done by the protocol, that is also a centralization vector.

  5. Market History: Has the asset observed severe volatility? In the case of stablecoins, has it depegged? In the case of an unpegged asset, have there been extreme price change events in the past? Provide specific information about the Balancer pool: how long has it been active, TVL, historical volume? You must provide a direct link to the pool AND a link to your pool’s gauge.

  6. Value: Is this pool intended to be the primary source of liquidity for the token(s)? If this is not the case, explain the expected value add to Balancer (can this pool generate consistent fees?)

Note: Please ensure the owner of your pool on Ethereum is set to 0xba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1b If this is not done, please clearly explain why in your proposal.

1 Like