[BIP-57] Introduce Gauge Framework v1

Governance General Proposal
1

Authors: philjfry, solarcurve

Motivation

Recently Balancer has seen an influx of projects asking for gauge approvals, many of them with a relatively small market capitalization. The vast majority of Balancer’s revenue today is generated from a small handful of pools containing tokens with a relatively high market capitalization. There is a growing need to strike a balance between optimizing for revenue generation and being supportive of small cap or newer projects which might one day grow to become significant revenue generators themselves.

This “Gauge Framework v1” aims to deliver a simple and objective rating criteria that the Balancer community can use to filter all current and future gauges. There are two phases of analysis - first using a “weight” factor with a “market cap” factor to derive an “overall” factor. All gauges scoring below a certain threshold would proceed to the second phase which would apply a “revenue” factor, helping those small pools which are generating significant revenue reach the threshold. If a pool remains below the threshold after phase 2 it will undergo a mandatory migration to a new gauge with a 2% or 5% maximum cap on the emissions it can receive.

Phase 1

Weighting Factor

We’ll be borrowing the old weight factor from v1 liquidity mining. You can copy this spreadsheet and play around to see the results of various pool configurations.

Market cap Factor

Based on depth of pool assets and taking into consideration that assets weighting in the pool.

Each asset in the pool is analyzed individually, and the lowest score from the pool is taken into account.

token mcap factor = mcap (in USD millions) / % weighting

mcapFactor = square root (min(token mcap factor))

Source for market cap information is Coingecko.

Note: For the purposes of this calculation any asset that can be freely minted is assumed to have the market cap of whatever asset is used to mint it. auraBAL is minted with BAL, graviAURA is minted with AURA, maticX is minted with MATIC, etc.

Overall Factor

mcapFactor^weightFactor = overall factor

The proposed threshold for an uncapped gauge is an overall factor of 5 or higher.

Sample Calculation

Aura/WETH 50/50

Weighting Factor: 1

Aura mcap factor: $28M market cap / 0.5 weighting = 57

WETH mcap factor: $809B mcap / 0.5 weighting = 1,619

Lowest mcap factor: square root(57) = 7.53

Overall factor: 7.53^1 = 7.53

Phase 2

Revenue Factor

An average of the percentage of total revenue a pool contributed during the most recent two protocol fee distribution periods. This factor is bounded by 1 to 100 and is multiplied by the overall factor from Phase 1.

Total Revenue source is the core pools worksheet.

Pool revenue source is this dune dashboard.

Sample Calculations

Aura/WETH

July 11th → July 25th

Total Revenue = $489,308 * 2 = $978,616

Aura/WETH 50/50 Revenue: $24,060

Percentage of total: 2.45

July 25th → August 8th

Total Revenue = $686,997 * 2 = $1,373,994

Aura/WETH 50/50 Revenue: $34,504

Percentage of total: 2.51

Average of both periods percentage of total: 2.48

Overall factor of 7.53 * 2.48 = 18.67

Conclusion

You can find a mostly complete spreadsheet here that shows the relevant factors for each gauge Balancer has. The proposed threshold for imposing a 2% or 5% cap is a factor of 5, after the revenue factor is applied. This effectively means a 50/50 token/weth pool with token having a market cap of $12.5M would have a factor of 5 and be right on the cut-off line. All gauges below this threshold would migrate to a new gauge with a max_weight modifier. Governance can adjust this in the future so if a gauge becomes a strong revenue generator or the market cap of tokens increases significantly there is no migration required to remove the cap.

What defines how a gauge moves between being capped and uncapped and vice versa? The crypto market can change rapidly as we all know. If a gauge crosses the threshold in either direction the community can put forth a proposal to adjust that gauge’s status and voters will decide if it is justified or not based on the data.

Most new gauges won’t have a revenue factor so they will only be assessed on the overall factor - any new gauge with less than a 5 would be introduced with a cap. As it earns a revenue factor if that pushes it above a 5 a proposal can be made to remove the cap.

A complete list of gauges which will undergo a migration to a capped gauge:

TEMPLE/DAI (Ethereum)

USDC/TEL/DFX (Polygon)

RBW/WETH (Polygon)

BADGER/wBTC (Ethereum)

NOTE/WETH (Ethereum)

DFX/WETH (Ethereum)

VSTA/WETH (Arbitrum)

TCR/DAI (Ethereum)

VITA/WETH 80/20 (Ethereum)

wBTC/DIGG/graviAURA (Ethereum)

WNCG/WETH (Ethereum)

NOTE/WETH 80/20 (Ethereum)

HAUS/WETH (Ethereum)

PAL/USDC (Ethereum)

FDT/WETH (Ethereum)

D2D/USDC (Ethereum)

D2D/BAL (Ethereum)

PICKLE/WETH (Arbitrum)

CRE8R/WETH (Arbitrum)

Specification

#1
If approved, the DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRole with the following arguments:

role: 0xaf9696666cd7f5e2ffb6abcf1a60f195cf8c7a99e7c63db98d14948fd4855f06

This corresponds with the role for calling addGaugeFactory on the gaugeAdder v2 as seen here.

account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

This gives the DAO Multisig the ability to call the above function.

#2
The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the gaugeAdder 0x2fFB7B215Ae7F088eC2530C7aa8E1B24E398f26a calling addGaugeFactory with the following arguments:

factory: 0xf1665E19bc105BE4EDD3739F88315cC699cc5b65

This corresponds to the mainnet gauge factory v2 as seen here.

gaugeType: 2

This corresponds to the Ethereum gauge factory, which can be confirmed by calling gauge_type_names with the argument of 2 on the gaugeController.

#3
The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the gaugeAdder 0x2fFB7B215Ae7F088eC2530C7aa8E1B24E398f26a calling addGaugeFactory with the following arguments:

factory: 0x1c99324EDC771c82A0DCCB780CC7DDA0045E50e7

This corresponds to the arbitrum root gauge factory v2 as seen here.

gaugeType: 4

This corresponds to the Arbitrum gauge factory, which can be confirmed by calling gauge_type_names with the argument of 4 on the gaugeController.

#4
The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the gaugeAdder 0x2fFB7B215Ae7F088eC2530C7aa8E1B24E398f26a calling addGaugeFactory with the following arguments:

factory: 0x866D4B65694c66fbFD15Dd6fa933D0A6b3940A36

This corresponds to the optimism root gauge factory v2 as seen here.

gaugeType: 5

This corresponds to the Optimism gauge factory, which can be confirmed by calling gauge_type_names with the argument of 5 on the gaugeController.

#5
The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the gaugeAdder 0x2fFB7B215Ae7F088eC2530C7aa8E1B24E398f26a calling addGaugeFactory with the following arguments:

factory: 0xa98Bce70c92aD2ef3288dbcd659bC0d6b62f8F13

This corresponds to the polygon root gauge factory v2 as seen here.

gaugeType: 3

This corresponds to the Polygon gauge factory, which can be confirmed by calling gauge_type_names with the argument of 3 on the gaugeController.

#6
The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling renounceRole with the following arguments:

role: 0xaf9696666cd7f5e2ffb6abcf1a60f195cf8c7a99e7c63db98d14948fd4855f06

This corresponds with the role for calling addGaugeFactory on the gaugeAdder as seen here.

account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

This removes the DAO Multisig’s ability to call the above function.

Then to add the gauges to the voting list:

#7
The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRole with the following arguments:

role: 0xf49d7ffb5922642adc9f29cfb52b2214e81e0b0e54e9cd1e9f70439f0011f368

This corresponds with the role for calling add_gauge on the gaugeController as seen here.

account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

This allows the DAO Multisig to directly add gauges to the controller.

#8

The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the AuthorizerAdaptor at 0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75 and call performAction with the GaugeController at 0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD for the target(address) argument and using 0x3a04f900 followed by each one of the gauge addresses listed below and their corresponding gauge types for the data(bytes) argument. Each gauge will be its own transaction, thus there will be a total of 19 transactions.

List of contracts

0xb0FB3e031224bd449974AB02cae369E81db58Fa6
0xb61014De55A7AB12e53C285d88706dca2A1B7625
0xa3E3B2C9C7A04894067F106938cA81e279bC3831
0x3F29e69955E5202759208DD0C5E0BA55ff934814
0x96d7e549eA1d810725e4Cd1f51ed6b4AE8496338
0x27Fd581E9D0b2690C2f808cd40f7fe667714b575
0xd863DA50435D9FCf75008f00e49fFd0722291d94
0xf46FD013Acc2c6988BB2f773bd879101eB5d4573
0xAde9C0054f051f5051c4751563C7364765Bf52f5
0xc2D343E2C9498E905F53C818B88eB8064B42D036
0xE5f24cD43f77fadF4dB33Dab44EB25774159AC66
0x47c56A900295df5224EC5e6751dC31eb900321D5
0x09AFEc27F5A6201617aAd014CeEa8deb572B0608
0x00Ab79a3bE3AacDD6f85C623f63222A07d3463DB
0xe2b680A8d02fbf48C7D9465398C4225d7b7A7f87
0x59E7DBfF74B2B76957E6a3f25cCEe40b2f3421D0
0x1249c510e066731FF14422500466A7102603da9e
0x231B05F3a92d578EFf772f2Ddf6DacFFB3609749
0x077794c30AFECcdF5ad2Abc0588E8CEE7197b71a

#9
The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling renounceRole with the following arguments:

role: 0xf49d7ffb5922642adc9f29cfb52b2214e81e0b0e54e9cd1e9f70439f0011f368

This corresponds with the role for calling add_gauge on the gaugeController as seen here.

account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

This removes the ability for the DAO Multisig to directly add gauges to the controller.

Transaction json for #7, 8, and 9

Transaction json
{"version":"1.0","chainId":"1","createdAt":1661868407382,"meta":{"name":"Transactions Batch","description":"","txBuilderVersion":"1.9.0","createdFromSafeAddress":"0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f","createdFromOwnerAddress":"","checksum":"0x948dc5b0b328579096c0c1ef4458efc048b725b93e64d186ae58db5ed2069247"},"transactions":[{"to":"0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"bytes32","name":"role","type":"bytes32"},{"internalType":"address","name":"account","type":"address"}],"name":"grantRole","payable":false},"contractInputsValues":{"role":"0xf49d7ffb5922642adc9f29cfb52b2214e81e0b0e54e9cd1e9f70439f0011f368","account":"0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000b0FB3e031224bd449974AB02cae369E81db58Fa60000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000b61014De55A7AB12e53C285d88706dca2A1B76250000000000000000000000000000000000000000000000000000000000000003"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000a3E3B2C9C7A04894067F106938cA81e279bC38310000000000000000000000000000000000000000000000000000000000000003"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f9000000000000000000000000003F29e69955E5202759208DD0C5E0BA55ff9348140000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f90000000000000000000000000096d7e549eA1d810725e4Cd1f51ed6b4AE84963380000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f90000000000000000000000000027Fd581E9D0b2690C2f808cd40f7fe667714b5750000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000d863DA50435D9FCf75008f00e49fFd0722291d940000000000000000000000000000000000000000000000000000000000000004"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000f46FD013Acc2c6988BB2f773bd879101eB5d45730000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000Ade9C0054f051f5051c4751563C7364765Bf52f50000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000c2D343E2C9498E905F53C818B88eB8064B42D0360000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000E5f24cD43f77fadF4dB33Dab44EB25774159AC660000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f90000000000000000000000000047c56A900295df5224EC5e6751dC31eb900321D50000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f90000000000000000000000000009AFEc27F5A6201617aAd014CeEa8deb572B06080000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f90000000000000000000000000000Ab79a3bE3AacDD6f85C623f63222A07d3463DB0000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000e2b680A8d02fbf48C7D9465398C4225d7b7A7f870000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f90000000000000000000000000059E7DBfF74B2B76957E6a3f25cCEe40b2f3421D00000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f9000000000000000000000000001249c510e066731FF14422500466A7102603da9e0000000000000000000000000000000000000000000000000000000000000002"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000231B05F3a92d578EFf772f2Ddf6DacFFB36097490000000000000000000000000000000000000000000000000000000000000004"}},{"to":"0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"address","name":"target","type":"address"},{"internalType":"bytes","name":"data","type":"bytes"}],"name":"performAction","payable":true},"contractInputsValues":{"target":"0xC128468b7Ce63eA702C1f104D55A2566b13D3ABD","data":"0x3a04f900000000000000000000000000077794c30AFECcdF5ad2Abc0588E8CEE7197b71a0000000000000000000000000000000000000000000000000000000000000004"}},{"to":"0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6","value":"0","data":null,"contractMethod":{"inputs":[{"internalType":"bytes32","name":"role","type":"bytes32"},{"internalType":"address","name":"account","type":"address"}],"name":"renounceRole","payable":false},"contractInputsValues":{"role":"0xf49d7ffb5922642adc9f29cfb52b2214e81e0b0e54e9cd1e9f70439f0011f368","account":"0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f"}}]}

For those gauges which are migrating, the new capped gauges will be live for voting by September 8th. The old gauges will be killed on September 21st. This allows enough time for votes and bribes to be moved over to the new capped gauges.

On September 21st, the DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the AuthorizerAdaptor at 0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75 and call performAction using 0xab8f0945 for the data(bytes) argument and the following list of contracts for the target(address) argument. Each contract will be its own transaction, thus there will be a total of 19 transactions.

List of gauge contracts

TEMPLE/DAI (Ethereum) → 0x7DfaDb8c3230890a81Dc9593110b63Bc088740d4
USDC/TEL/DFX (Polygon) → 0xEad3C3b6c829d54ad0a4c18762c567F728eF0535
RBW/WETH (Polygon) → 0xD13A839BB48d69A296a1fa6D615B6C39B170096B
BADGER/wBTC (Ethereum) → 0xAF50825B010Ae4839Ac444f6c12D44b96819739B
NOTE/WETH (Ethereum) → 0xC5f8B1de80145e3a74524a3d1a772a31eD2B50cc
DFX/WETH (Ethereum) → 0x7CDc9dC877b69328ca8b1Ff11ebfBe2a444Cf350
VSTA/WETH (Arbitrum) → 0x6cb1A77AB2e54d4560fda893E9c738ad770da0B0
TCR/DAI (Ethereum) → 0xE273d4aCC555A245a80cB494E9E0dE5cD18Ed530
VITA/WETH 80/20 (Ethereum) → 0xb154d9D7f6C5d618c08D276f94239c03CFBF4575
wBTC/DIGG/graviAURA (Ethereum) → 0x5204f813cF58a4722E481b3b1cDfBBa45088fE36
WNCG/WETH (Ethereum) → 0x86EC8Bd97622dc80B4a7346bc853760d99D14C7F
NOTE/WETH 80/20 (Ethereum) → 0x40AC67ea5bD1215D99244651CC71a03468bce6c0
HAUS/WETH (Ethereum) → 0xa57453737849A4029325dfAb3F6034656644E104
PAL/USDC (Ethereum) → 0xe3A3Ca91794a995fe0bB24060987e73931B15f3D
FDT/WETH (Ethereum) → 0xbD0DAe90cb4a0e08f1101929C2A01eB165045660
D2D/USDC (Ethereum) → 0x5A481455E62D5825429C8c416f3B8D2938755B64
D2D/BAL (Ethereum) → 0xc43d32BC349cea7e0fe829F53E26096c184756fa
PICKLE/WETH (Arbitrum) → 0x899F737750db562b88c1E412eE1902980D3a4844
CRE8R/WETH (Arbitrum) → 0xACFDA9Fd773C23c01f5d0CAE304CBEbE6b449677

If the framework is approved and the 5% cap option has the majority of votes, the following will happen:

The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will initiate a transaction to the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRoles with the following arguments:

roles: [0xae60dce27f51ce5815357b9f6b40f200557867f8222262a1646c005d09b7dfba,0xae60dce27f51ce5815357b9f6b40f200557867f8222262a1646c005d09b7dfba,0xae60dce27f51ce5815357b9f6b40f200557867f8222262a1646c005d09b7dfba]

These correspond to the roles for calling setRelativeWeightCap on gauges with this function.
First one is for the mainnet gauge factory v2 per this.
Second one is for the arbitrum root gauge factory per this.
Third one is the polygon root gauge factory per this.

account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

This allows the DAO Multisig to call the above function.

The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will then interact with the authorizer adaptor 0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75 and call performAction with the following:

data: 0x10d3eb0400000000000000000000000000000000000000000000000000b1a2bc2ec50000

target: each of the following gauge contracts (one tx per contract)

List of gauge contracts

0xb0FB3e031224bd449974AB02cae369E81db58Fa6
0xb61014De55A7AB12e53C285d88706dca2A1B7625
0xa3E3B2C9C7A04894067F106938cA81e279bC3831
0x3F29e69955E5202759208DD0C5E0BA55ff934814
0x96d7e549eA1d810725e4Cd1f51ed6b4AE8496338
0x27Fd581E9D0b2690C2f808cd40f7fe667714b575
0xd863DA50435D9FCf75008f00e49fFd0722291d94
0xf46FD013Acc2c6988BB2f773bd879101eB5d4573
0xAde9C0054f051f5051c4751563C7364765Bf52f5
0xc2D343E2C9498E905F53C818B88eB8064B42D036
0xE5f24cD43f77fadF4dB33Dab44EB25774159AC66
0x47c56A900295df5224EC5e6751dC31eb900321D5
0x09AFEc27F5A6201617aAd014CeEa8deb572B0608
0x00Ab79a3bE3AacDD6f85C623f63222A07d3463DB
0xe2b680A8d02fbf48C7D9465398C4225d7b7A7f87
0x59E7DBfF74B2B76957E6a3f25cCEe40b2f3421D0
0x1249c510e066731FF14422500466A7102603da9e
0x231B05F3a92d578EFf772f2Ddf6DacFFB3609749
0x077794c30AFECcdF5ad2Abc0588E8CEE7197b71a

9 Likes
2

This proposal is a real step back wrt utility of veBAL within just a few months of implementing the ve framework. This opening statement is completely incorrect. The vast amount of fee revenue may come from large cap pools but bribe revenue to veBAL holders is a major source of value flow into the system now and it is explicitly ignored in this proposal. Imo it is a proposal looking for a problem at best and at worst showing enormous preference to the value of DAO revenue over veBAL value capture.

The wBTC/ETH pool generates about $1,000 per day in fees over the past couple months. The 80-BAGDER/20-WBTC pool has generated probably close to $300 per day over the same timeframe (more volatile though). Only a portion of this fee goes to the DAO and veBAL holders. On the other hand there is currently a $25,000 incentive on the badger pool which will go directly to veBAL holders that vote for it. Thats ~$3,500 per day. This isnt counting the AURA bribe as well which still helps BAL but less directly. This is an easy 5-10x in value to veBAL holders vs the WBTC/ETH pool. If the BADGER pool were to be capped at 2% there would be no reason to add an incentive of that size. And given if the votes get redistributed to WBTC/ETH what result would that have? A slight increase in deposits which may support a bit more volume and likely a negligible increase in fee revenue.

The governance premium for BAL also takes a hit by clearly implying that veBAL holders should not have control over BAL emissions. If this is what BAL holders wanted then they wouldnt have voted for the implementation of the ve framework and kept the previous approach.

It is also purely focused on DAO revenue, not value to veBAL holders by completely ignoring HOW the smaller cap tokens got higher vote weight (locking BAL & AURA + hidden hands incentives). Enacting this policy would severely disincentivize incentives on pools, cutting a significant source of revenue to veBAL holders (>100% APR right now).

Its clear this proposal is in response to one actor in the system but in the end all vote weight by that entity was acquired through the purchase and locking of BAL tokens. You cant control their voting without hamstringing the rest of the system and voters. Also if this framework is put in place do you really think that entity will consolidate their voting onto the “large cap pools”? There is 0 evidence of that. And if they did would that really increase revenue for the DAO and BAL holders?

This is a proposal looking for a problem imo and would be a net negative for BAL holders and the Balancer/Aura ecosystem at large. A better option would be to enable more gauges and create more competition for the vote weight and when the yield-share pool factory is ready encourage pairings with yield generating assets. Look at all facets of value flowing into the system and then use that to evaluate if things are going in a positive direction before making any dramatic changes.

Full disclosure I am on the Badger team but I am also a BAL locker and a user of balancer ever since it launched. It seems to me there is a very vibrant ecosystem growing since Aura launch (I sure am earning a LOT more with my BAL than I was before!) and it would be a shame to artificially restrict its growth before seeing how it evolves.

4 Likes
3

This is a good distinction to raise. While Balancer is the #1 or #2 briber there is a strong 3rd party bribe market which could be temporarily dampened as a result of this framework. However, I think it may be short sighted to dismiss the importance of DAO revenue. We are spending significantly more than we’re earning and we have around 12-18 months to close this gap - if we don’t, a large amount of BAL will need to be sold in some form and that will dilute existing voters significantly. We need 3rd party bribers but we cannot let these bribers stifle the revenue of the protocol by directing uncapped emissions into pools which generate very little, if any, fees.

Suggesting wbtc/weth would not scale with more TVL feels incorrect to me. Would be interested to see data you have to back up this assumption that more emissions towards that pool wouldn’t result in increased fees. Also, it’s ~1,785 per day not $3,500 because Badger is bribing bi-weekly.

If BAL holders want this framework, they will vote it in. If they don’t, they won’t. I see no reason to expect governance premium to take a hit as veBAL holders are, have been, and will remain fully in control.

It is possible some entities may reduce bribing activity as a result of this framework. I wouldn’t be certain of that since the ROI on bribing is over 100% (thanks to aura emissions), so one could vote for other bribes and bribe their own pool that they are farming a significant % of the LP in and walk away very happy. Either way, any drop in bribing activity would be temporary as BIP-19 is very likely to grow significantly over the next few months.

I have no idea what Humpy will do. I like that he is bullish BAL and hope to see him around the ecosystem for a long time to come. This proposal is absolutely not intended to single him or anyone else out.

I would argue this framework is a huge long term positive for the ecosystem as it will make approving new gauges for small cap projects much more palatable. It will level the playing field and apply the same rules to everyone. It will make it a lot harder to make huge profits off of bribing, farming, and dumping. I’d actually argue the current state of the ecosystem is not too enticing for new entrants.

Glad to have Badger as such a strong and important participant in the Balancer ecosystem! Looking forward to both projects growing together for a long time to come. We all move forward together despite the occasional disagreements.

6 Likes
4

I am a fan of this framework. This will help direct emissions to the most profitable pools which is ideal from the perspective of a veBAL holder. I understand that there will be certain parties that won’t be happy with this change, but it’s important to reiterate that it is not veBAL holders responsibility to subsidize emissions for microcap projects. The point of emissions are to incentivize valuable liquidity. If a pool is overwhelmingly positive for the ecosystem then there is no reason for veBAL holders to leave the pool capped. This change allows us to be much more open to smaller projects looking to incentivize their liquidity while minimizing the opportunity to self direct emissions to farm and dump en masse. We have plenty of pools that have revenue generation that scales, and this framework will help ensure those pools get a majority of emissions.

5 Likes
5

Most of the rewards distributed in the Balancer & AURA gauge ecosystem have been bought or earned by its participants.
There is currently no “black hole” in the making where one user is increasing their holdings at a rate that can be viewed as dangerous to the Balancer’s governance.

It is up to the governance to consider whether the policy of disincentivizing the action of locking AURA and BAL to vote for a specific pool is a net positive.
But as far as the extent of that disincentivization goes, I believe that setting up the cap at 2% makes many use cases of building on top of Balancer unviable.

BadgerDAO has been building Balancer-focused products for a while now and plans to continue these efforts. Unfortunately, this proposal would throw a big wrench into our plans and make our products that leverage Balancer exclusive features unscalable.

Emission-based DEX ecosystems rely on:

  1. Trading fees
  2. Bribes
  3. The demand for buying the ecosystem assets to lock and vote for the pools and/or harvest the bribes.

It is debatable whether losing the demand for locking the tokens to vote would bring more harm or good. Ideally, I would like to get more rationale about why it is considered to be good for the DAO, but the main thing I’m here to address is the method used and the parameters chosen to follow through with that choice.

The proposed model is based on three factors:

  1. Market cap of the tokens in the pool
  2. Pool composition
  3. Revenue driven by the pool.

In my opinion, there is no good reason to use (1) and (2), and the system would be better off focused exclusively on the cost-efficiency of the DEX (3).

To do that, we need to ask the following question:
What amount of $ value in emissions was issued to the pool compared to how much revenue it managed to bring over a certain period?

Then we get the cost-efficiency ratio that is easy to understand (unlike the three-factor model) and which is focused on the protocol’s profitability.

Fees and bribes drive the DEX revenue, and bribes tend to make up for the absolute majority (up to 90%+) of that revenue.

Thus the “fee-efficiency,” which afaik is the main argument for capping the 80/20 type of pools, becomes irrelevant as long the pool compensates for the lack of trading efficiency with the bribes.

Unfortunately, I don’t have the data to illustrate the point, but I would bet that all the pools that get external bribing outperform the pools that don’t get it revenue-wise by a significant margin.

Also, if we consider the core pool bribing as negative revenue, the L2 pools would lose out in that comparison even further. It doesn’t mean, however, that they shouldn’t continue being incentivized as an exemption if that’s considered a strategic and not a revenue-oriented choice.

As for the market cap considerations, I believe that should be handled well already by the whitelisting process. The main potential vulnerability would be a Spiderman/Batman type of pool (the pool where a single entity controls all the tokens), but I wouldn’t expect that pool ever to make it through the gauge vote.

I would like to hear the rationale of why using (1) and (2) is necessary as I don’t find good arguments in that regard, and imo the model could be easier to comprehend and more effective at what it does.

So we set the minimal viable pool cost-efficiency at whatever number is chosen (it can be a fixed number or based on ecosystem-wide cost-efficiency percentiles). Then if a pool doesn’t get there over a certain period, it would get “demoted” and capped in the % of emissions it can get.

This way, instead of disincentivizing DEX participants, they would be incentivized to keep that ratio high enough, the ecosystem state would get more healthy and growing, and many use cases for building on top of Balancer wouldn’t be blocked.

1 Like
6

We are spending significantly more than we’re earning and we have around 12-18 months to close this gap - if we don’t, a large amount of BAL will need to be sold in some form and that will dilute existing voters significantly. We need 3rd party bribers but we cannot let these bribers stifle the revenue of the protocol by directing uncapped emissions into pools which generate very little, if any, fees.

Do I get it right that the main reason is the Stablecoin runway of the DAO?
Aren’t there other options for getting it other than making veBAL and vlAURA less attractive?
Personally, I see no issue with paying contributors with BAL when BAL is a token that ecosystem participants want to hold. On the other hand, making veBAL less valuable can lead to the result you’re trying to avoid:

a large amount of BAL will need to be sold in some form

Since it would likely affect the demand for veBAL and vlAURA.

==

About the bribes, I believe it is correct to count both AURA and BAL bribes as something that brings revenue to the ecosystem. AURA bribes bring value & demand to AURA, AURA is boosting Balancer TVL, fees and demand for BAL significantly.
From that standpoint, the Badger pool is bringing closer to 5.5 - 6 $k value per day to the ecosystem.

It will level the playing field and apply the same rules to everyone.

I believe the framework wouldn’t level the playing field as it puts tokens with lower market caps and different pool composition at a significant disadvantage.
The same rules for everyone could be based on revenue production, and the outliers could be disincentivized.
Badger/WBTC is quite far from being a revenue outlier for Balancer, and I would bet that this pool is among the most cost-efficient pools in the ecosystem. But like I said, I don’t have the data available.

it will make approving new gauges for small cap projects much more palatable.

What does the issue with approving small cap projects come down to?
With this framework, a cohort of use cases that could bring value to the ecosystem gets blocked since they wouldn’t be able to scale beyond 2% of the rewards.
The proposal is damaging to pool2 tokens entering the ecosystem, which is the niche that Balancer is uniquely positioned to get a larger market share in its current (or a modified) state.

If the Balancer community wants to manage the distribution of rewards in a way that creates fewer cost-efficiency outliers, I see the logic in that. But I would prefer if that change is done in a way that puts the pools on an even footing - and using market caps and pool compositions as factors does the opposite.

1 Like
7

So is this then explicitly a proposal to shift tokenholder revenue to DAO revenue? If so its a bit of an end around way to do it. Just enabling the locking of some operational BAL to bribe harvest would be a much simpler and clearer system.

Ah, yeah my bad on the biweekly part, got that confused. Inclusive of its fees its still 2x+ the revene of WBTC/ETH not counting AURA incentives. WRT scaling revenue, you are the one proposing a major change so I think the onus should be on this proposal to show that, if this is successful in directing more emissions to larger cap pools that revenue would increase and by how much. My pushback is just anecdotal from being in DeFi for a long time. Rewards>TVL>Volume is not linear in my experience and theres value loss along the way.

But you are using a binary vote to remove a relative control that they have. The original system was already voted in place, why rush to limit it? Its new, if the DAO needs more runway there are other options (speaking from experience at BadgerDAO, we are going through a similar process of looking at expenses, runway, etc and making hard decisions)

I can say that BadgerDAO will 100% change our behavior wrt incentives. No reason to add more if its capped.

Why would this change at all the decision making behind approving gauges? Shouldnt there be a check of legitimacy and then approval? I can say that to join and be singled out as a small cap and be limited in how a project could interact with the ecosystem, as someone contributing to building on balancer, makes it feel a lot less attractive. Allowing for maximum creativity using Balancers great flexible framework should provide the best chance at differentiated products emerging. Forcing pools into the same box limits the design space.

Same, I will just echo what I mentioned to the Badger team on seeing this proposal. I have never seen a group so committed to finding a problem with their system when there isnt one.

Get the boosted pools factory out (There are multiple projects badger has in mind to get pools launched for as soon as its ready and hopefully many more after), take hidden hands incentives into account in your modeling, reassess the point of this proposal (DAO revenue or more attractive for new entrants? whats the problem?) Get data to back up “more megacap rewards = more revenue” and see if it still makes sense.

1 Like
8

No, this is simply a positive side effect of pools making more revenue. I would appreciate if you didn’t try to spin a narrative where this isn’t one, its clear what the proposal addresses. Everyone wins when the pools generate revenue.

2 Likes
9

Just referencing what was shared directly

10

The proposal shoots the bribe ecosystem in the foot, which should reduce revenue, not increase it.
It also hurts the demand for BAL and AURA, and as revenue is tied to the emissions value, that is also likely to become a revenue loss factor.
Balancer & AURA losing their competitive advantage and becoming a worse place for investors and DAOs to enter should also have lasting effects on the DAO revenue.

1 Like
11

Ok. So in short. I like the concept. The way pools are weighted seems decent. The idea of limiting tokens under 50 million in marketcap seems about right. I also look forward to getting something in place and shifting everyones focus on building forward.

That all being said, the 2% cap for low mcap coins is too low. 5% works a lot better.

Instead of writing an essay, which I will probably end up doing by the end of this, let me try to illustrate with a paragraph and a couple of questions:

Around 50k in well placed bribes, which is a healthy bribe for the ecosystem but not extraordinary large, currently buys around 3-4% of veBAL. By limiting the pool to 2%, it seems to me that you are functionally telling any DAO under 50 million in market cap, that they can’t really bribe more than 12.5k a week for their pool without maxing out.

Does this seem like a good way for the ecosystem to grow? Is the expectation that some FRAX type DAO is going to swoop in with a big mcap and start bribing big bucks? The end solution here is to get more players in the game, to grow the ecosystem, at best with a diverse set of DAOs building on top of balancer isn’t it?

It seems to me like a 2% cap is really likely to stunt veBAL and BAL’s growth. I can’t support this proposal at 2%.

1 Like
12

I am in favor of this framework and have been of implementing caps since the DAO capped veBAL at 10% of emissions. The goals here are not to limit other projects who truly believe their token is worthwhile to Balancer, but to have them prove their worth.

The focus really allows the community / ecosystem to permit gauges for projects which are smaller in scale without high risk. In turn both benefit one another, where before approving a gauge became a one sided benefit. Any future projects whose price will collapse in the absence of a gauge, is not one the community should support.

I hope we can finally get past the unhealthy emissions thorn in our side to drive incentives and therefore increase the liquidity/depth on the most effective pools.

13

Hello,
Curious why 2%? vs 1 or 5 or 7 or 10 or 4.20 or 6.9? Thx

1 Like
14

to me it is as simple as allowing more pools to get a look in terms of votes

100/5 = 20 pools are able to be maxed out
100/2 = 50 pools are able to be maxed out

15

Do you think there are 100 pools that want to pay bribes into the ecosystem/actively use veBAL in this market? Do you think there are 50? 10 or 20 sounds more realistic right now, and if that happens there will be enough competition that these caps shouldn’t matter so much. Why chase off those who want to bootstrap the ecosystem?

THe point about having a decent amount of emissions going to higher revenue pools is important, so maybe you don’t want 100% of veBAL going to people paying more bribes than the core pools pay as it reduces DAO revenue, but I’d think it makes sense to at least kind of allow half of it to flow towards innovation.

30% going to one microcap token is by no means good, but 2% for a 40 million mcap token trying to really build something on top of balancer is also hard to work with.

Even with a 5% cap, I imagine it would take a while before there were 10 non-core pools taking 5% each of veBAL. If it turned out to be a problem the cap could be lowered.

1 Like
16

I might not be following.
We want to cap people/protocols from buying more BAL to gain more veBAL influence?
We want to cap birbs from protocols that would otherwise have the means to buy more votes than 2%?

1 Like
17

The free bribe market allows as many pools to enter as there is demand for, and limiting the competition would negatively affect Balancer and AURA revenue.
What harm does it bring if a pool gets 10% of emissions that it bought at the market rates?
All while the bribers would have to pay more for the same amount of emissions compared to the capped version.

18

I understand that the goal of this proposal is to create objective criteria for evaluating emissions to certain gauges. However, if pools will be automatically moved from the “A” gauge to the “B” gauge, why is a governance proposal and a favorable snapshot vote needed to relist a qualifying “B” gauge pool back to the “A” gauge?

This methodology introduces objective criteria for delisting a pool from the A gauge while simultaneously introducing a substantial element of subjectivity and popularity amongst veBAL voters for moving a qualifying pool from the B gauge back to the A gauge.

This seems logically inconsistent.

2 Likes
19

I can understand where you are coming from.
The health of the DAO and the Stablecoin runway are very important.

I’ll be blunt here, we all know who this is mainly targeted at.
But besides the DIGG pool, the only DAO it really hurts right now is Badger.
The main disconnect here seems to be that Badger feels they are bringing value to the ecosystem by paying out bribes but Balancer is not directly earning money from it.

In my opinion this is fair from the Badger point of view.
Bribes increase the ROI of veBAL, this should have a positive impact on BAL value. Higher BAL price means the emissions are worth more in general, which means every single pool becomes more attractive.

Wouldn’t locking BAL as veBAL and voting to earn bribes solve some of those issues?

I think we all agree that the DIGG situation, and the CREAM situation before is not healthy.
But here we are hurting smaller DAOs that try to build up their influence. Badger is the first one to do that in a large scale, but setting up a limit that low might disincentivize others from employing similar strategies.
Just to emphasize, right now Badger is paying out Badger tokens to increase their ecosystem influence. So basically they take a hit on their own mcap to get more exposure to BAL and Aura. But with those changes the better play would be to act as a mercenary, extract as much value as possible, dump the tokens on the free market and pump Badger token price so they can get the mcap high enough to reach a factor higher than 5.

Do you think that the Badger pool is currently hurting the ecosystem?
Wouldn’t a 5% cap, or even 10% cap resolve the issue at hand without hurting the Badger pool?
Maybe a 2% cap below a factor of 2, a 5% cap below a factor of 5 and a 10% cap below a factor of 10 would also resolve it and be more attractive to participants in the ecosystem.

2 Likes
20

I think Solar already made this point above.

If the 10% comes from core pools and core bribes, the DAO also gets some share for operations. If the 10% comes from bribes to a pool that generates little revenue, it may be good for HODLers and the ecosystem in some ways, but Balancer makes no money.

It seems like the goal is to fund runway with fees instead of token sales, so at the moment Balancer does not seem to perceive high bribe inflows as the answer/main objective.

I think the goal is to more find a balance of bribe/incentive type behaviours which bring new ideas and innovation to the DAO, and upward rebasing tokens that generate extra revenue and take part in core bribes (also competing on the same market).