Instructions & Overview

BAL Gauges
1

In order for your proposal to go to a vote you must explicitly request a vote, ideally via a reply on the forum.

We only start snapshot votes every Thursday. There is no minimum required discussion time but common practice is to allow a week or so.

In the case of an L2 gauge please note there is a one week delay in BAL emissions. i.e. if the gauge gets votes in a voting round that ended on June 8th, the pool would see emissions begin on June 15th. Additionally any L2 gauge getting less than 0.1% of the vote might not see emissions bridged every week due to gas costs.

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 2% capped gauge, enter 20000000000000000 for relativeWeightCap. For uncapped, enter 1000000000000000000.

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. This is the Polygon Root Gauge Factory - call create using the contract address on polygon you got from the previous step. For 2% capped gauge, enter 20000000000000000 for relativeWeightCap. For uncapped, enter 1000000000000000000. The result of this transaction 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. This is the Arbitrum Root Gauge Factory - call create using the contract address on Arbitrum you got from the previous step. For 2% capped gauge, enter 20000000000000000 for relativeWeightCap. For uncapped, enter 1000000000000000000. The result of this transaction 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. This is the Optimism Root Gauge Factory - call create using the contract address on optimism you got from the previous step. For 2% capped gauge, enter 20000000000000000 for relativeWeightCap. For uncapped, enter 1000000000000000000. The result of this transaction is your optimism root gauge that should be included in your gauge proposal.

For pools on Gnosis-chain

  1. This is the child chain liquidity gauge factory on Gnosis. Call create function with your pool’s gnosis contract address.
  2. This is the Gnosis Root Gauge Factory - call create using the contract address on gnosis you got from the previous step. For 2% capped gauge, enter 20000000000000000 for relativeWeightCap. For uncapped, enter 1000000000000000000. The result of this transaction is your gnosis root gauge that should be included in your gauge proposal.

For pools on Polygon zkEVM

  1. This is the child chain liquidity gauge factory on Polygon zkEVM. Call create function with your pool’s polygon zkevm contract address.
  2. This is the PolygonzkEVM Root Gauge Factory - call create using the contract address on zkEVM you got from the previous step. For 2% capped gauge, enter 20000000000000000 for relativeWeightCap. For uncapped, enter 1000000000000000000. The result of this transaction is your polygon zkevm root gauge that should be included in your gauge proposal.

For pools on Avalanche

  1. This is the child chain liquidity gauge factory on Avalanche. Call create function with your pool’s Avalanche contract address.
  2. This is the Avalanche Root Gauge Factory - call create using the contract address on AVAX you got from the previous step. For 2% capped gauge, enter 20000000000000000 for relativeWeightCap. For uncapped, enter 1000000000000000000. The result of this transaction is your Avalanche root gauge that should be included in your gauge proposal.

For pools on Base

  1. This is the child chain liquidity gauge factory on Base. Call create function with your pool’s Base contract address.
  2. This is the Base Root Gauge Factory - call create using the contract address on Base you got from the previous step. For 2% capped gauge, enter 20000000000000000 for relativeWeightCap. For uncapped, enter 1000000000000000000. The result of this transaction is your Base root gauge that should be included in your gauge proposal.

Once you, the proposer, feel sufficient discussion has taken place you must find a delegate with over 200,000 veBAL to post your snapshot for you. The Balancer Maxi’s often provide help with this, so feel free to contact @solarcurve, @Xeonus, @ZenDragon , @zekraken, @Mike_B, @Tritium or @Danko8383 for help posting your snapshot.

More details on the snapshot/governance process can be found in the governance section of the docs

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.

Gauges for Custom Pools

The following conditions must be met for a custom pool to be added to gauges:

  • There must be a analytics dashboard that shows:
    • Swap volume over time
    • Deposit Balances in LP
    • Fees earned
  • 50% of all collected fees must be sent to the balancer treasury
    • One example of such a trade should exist.
4 Likes
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.

2 Likes