Instructions & Overview

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.

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.
3 Likes

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