[RFC] Allocate Balancer's 3M ARB

Motivation

As part of the Arbitrum token launch Balancer DAO was allocated ~3M ARB tokens. While spending some to accelerate our growth certainly makes sense I believe it’s prudent to retain the majority as a long term bet on Arbitrum’s future. Balancer has seen promising early signs of momentum on Arbitrum like the launch of wstETH and the adoption of ve8020 by two Arbitrum native projects (y2k and Radiant). Future catalysts like Aave v3 boosted pools, rETH, and Aura going multichain put us in a strong position to potentially become the top DEX on Arbitrum.

I suggest allocating 1M ARB towards a voting incentive matching program as this is the most direct growth mechanism in my view.

  • 10 round duration, aligning with the usual two week cycle of voting incentive allocations.
  • Max of 100k ARB per round. Any unspent ARB simply returns to the treasury.
  • Each pool can have a max possible allocation of 10k ARB per round to prevent one or two pools from taking the majority share of this program.
  • On the final day of Aura’s gauge voting snapshot, ARB will be allocated to each Arbitrum pool with voting incentives on a 1:1 USD basis.
  • ARB will be allocated proportionally to Aura & Balancer Hidden Hand markets based on existing bribes.
  • This would not begin until Aura is deployed and ready to emit AURA rewards.

Example: Pool A has voting incentives worth $20k ($15k on Aura market, $5k on Balancer market), Pool B has voting incentives worth $5k on Aura market, Pool C has voting incentives worth $1k on Balancer market. ARB price is $1. Pool A is allocated 10k ARB → 2500 on Balancer market and 7500 on Aura market, Pool B is allocated 5k ARB on Aura market, Pool C is allocated 1k ARB on Balancer market, and 84k ARB is returned to the treasury out of the 100k ARB allocated for this round.

In order for the above to be feasible Hidden Hand must support deposit/claim of bribes from Arbitrum both on Aura and Balancer markets. I’ve been in touch with them and they say this can be accomplished within two weeks.

For the remaining 2M ARB I suggest deploying protocol owned liquidity by pairing it 50/50 with BAL.

This creates TVL, volume, and revenue that we don’t need to spend incentives on. By increasing BAL liquidity on Arbitrum we make it easier for second order integrations like autocompounders to support Balancer pools. If another use case for ARB presents itself like participating in governance or another incentives program the liquidity can always be withdrawn. The risk here is the potential IL of ARB significantly under or outperforming BAL. If it underperforms we’re selling BAL to buy ARB, vice versa if it outperforms. Either outcome seems acceptable to me but the community must carefully consider this.

It’s also an option to bring Aura in and create an ARB/BAL/AURA pool, perhaps 40/40/20 or equal weighted. This would provide ample AURA liquidity on Arbitrum and require no incentives. Their treasury is smaller so this would be a bigger commitment on their part but perhaps a worthwhile one.

Specification

The Maxis are best positioned to handle the voting incentives campaign. If Aura participates in the POL there’s a few options that could be considered in terms of logistics. Without Aura we’d simply bridge BAL from mainnet and custody the BPT in the Arbitrum treasury. A more detailed specification can be filled out after the community has settled on the desired approach.

8 Likes

I understand that Balancer itself is not interested in the governance of other protocols, but I would like to propose an option to hold onto ARB tokens in order to participate in Arbitrum Governance itself.

The vote could be executed similarly to how votes are done for on Balancer by Aura. This could be viewed as a marginal utility for veBAL holders and furthermore strengthen the role of veBAL holders in the Arbitrum ecosystem.

Other than that, if we decide on using the ARB allocation I think that the two mechanisms proposed above could be a good use of funds.

1 Like

I express my full support for the incentive matching program. Regarding the remaining 2 million ARB, I suggest conducting further research and discussions to determine the most suitable strategies for deploying these funds. It may be beneficial to distribute the 2 million ARB across various fee-generating initiatives based on their risk:reward profile.

In my personal experience with v3 LP’ing, I utilise a methodology that takes into account the Volume/TVL ratio, Volume/TVL stability, Volatility, and Historical Correlation Matrix for LP Assets. Through this methodology, I have identified a pool on Polygon that periodically meets my criteria and has been a significant generator of fee APR. That is the WMATIC (25%)-ETH (25%)-USDC (25%)-BAL (25%) pool.

An ARB version of this balanced portfolio would bring in consistent fee APR and also has a higher likelihood of attracting organic LPs, particularly with the implementation of the voting incentive matching program.

A potential variation of this strategy could involve a portfolio of volatile-only assets, such as ARB-ETH-BAL (40/40/20), ARB-ETH-WBTC-BAL (25-25-25-25), and ARB-ETH-BAL-AURA (30-30-20-10).

I’m not particularly interested in the governance game - but don’t oppose keeping some % to participate.

2 Likes

main problem is we don’t have enough ETH in the treasury to be able to fully utilize 2M ARB in pools designed like that.

what we can do is start up ARB/WETH/USD all aave boosted once aave adds ARB as an asset. Then it’s one hop to go between ARB/BAL/AURA and that pool.

2 Likes

On voting incentives: it’ll be great to see an ROI analysis. i.e. will we make x+y in revenue for every x we spend on voting incentives? Otherwise, this would be a slightly more utilitarian way of distributing the airdrop to veBAL and auraBAL holders.

On deploying ARB in a liquidity pool: i’m directionally aligned. Though, this pool is only going to be generating revenue if there’s similar size BAL/WETH pool next to it. Since current BAL/WETH pool on Arbitrum is only $200k, i don’t think a $4mm BAL/ARB pool will be very useful.
I’d suggest an ARB/60BAL40WETH pool instead. I think that’ll route ARB trades to WETH and other tokens much better, assuming aggregators are supporting batch swaps.

edit: i realized after posting that C0 had brought up similar concerns with the utility of an ARB/BAL pool.

3 Likes

I think it’s an excellent move to start incentivizing a move to L2 for liquidity.
The targets seem reasonable if there are already enough gauges deployed there, otherwise it might be better to push some projects to release some there before enabling the program.

My main worry for such incentive campaign is on timing, not intentions.
Current incentives are on the verge of rupture as the number of incentivisers has grown a lot (which is excellent for voters) but emitted tokens (both in price and quantity) have dropped. The current result is that all incentives on Aura are unprofitable, and we’re nearing a similar point for veBAL incentives.
Adding 150,000$ weekly ARB incentives will seriously push us there.
I know it has been discussed several time on the topic of Core Pools that Balancer did not care about the profitability of its incentives, but in this case, it would push most external incentivisers to ragequit.

My advice is, let’s wait 2 months for the system to cool down and reconsider at that point.

3 Likes

It’s definitely a fair point, that printing ARB into a negative ROI is less ideal than printing core pool bribes into a negative ROI.

There’s always the option of just emitting ARB on the pools. Could even use the same logic for where the ARB is allocated (basing it on bribes made). This should lead to higher net TVL on Balancer across all networks since the ARB is additional rewards being printed. Perhaps the better way to go.

2 Likes

So it would be a matching program? To be fully transparent, we are working on an Arbitrum Balancer pool, so we are following the topic closely.

That’s the general idea for the 1M ARB, yea. Matching bribes made by the project and/or bribes made by Balancer thru bip-19

3 Likes

Following on from our comments on [Temperature Check] Create ARB/AURA/BAL Liquidity on Arbitrum - #3 by Tritium - Temperature Check - Aura Finance

We support the suggestion to target achieving potential growth on Arbitrum, by utilizing the 3M ARB, given its strong recent performance, and Balancer’s reasonable standing there already. (https://defillama.com/protocols/dexes/Arbitrum)

1M ARB to be spent on incentive matching is a respectable sum and could yield good results, but a strong marketing campaign should accompany this to maximize benefits, ideally involving Arbitrum and other ecosystem partners.

We acknowledge C0_G1 and Solarcurve’s comments regarding the limitations in deploying other pool compositions at this time and agree this is a good initial pool given these limitations, with further pools to be built out when able.

Emitting ARB through pools based on bribe allocation seems a sensible approach.

7 Likes

Hi guys, dev from Aura here. We’ve finalized a new contract based on the previous one used for BIP-252. This contract is designed to facilitate Balancer and Aura’s participation in an ARB/BAL/AURA pool.

  • The contract can be deployed prior to the Aura’s deployment on Arbitrum and initialized at a later stage. This allows us to proceed with the voting process while ensuring that the implementation is confirmed and ready.
  • Once the contract is deployed and initialized, it will provide the ability to join the ARB/BAL/AURA pool.
  • When either party involved decides to wind down the position, they can trigger a cooldown period. This cooldown period will last for 60 days, providing sufficient time for an orderly exit from the pool.
  • After the 60-day cooldown period has elapsed, the pool can be exited, and the remaining balance can be returned to the participants. Balancer will be responsible for providing the minimum out values and calling exit.
  • Balancer will receive all the ARB and BAL tokens, while Aura will receive all the AURA tokens.

We believe that this new contract proposal addresses the requirements and concerns raised during the previous discussions. It provides a clear framework for participation, winding down, and asset allocation, ensuring a smooth and transparent process for all participants.

View AuraArbBalGrant.sol contract

Look forward to hearing everybody’s feedback and input on this.

7 Likes

This contract would be easier to monitor if we could add add an event that included cooldown start time and end time on the startCooldown() and something on withdrawBalances().

2 Likes

thanks for doing this! Our integrations team will review, after that we can proceed with deployment and a vote to send the funds.

3 Likes

Since we’re getting closer to seeing this executed I wanted to update everyone with my latest thinking about the 1M ARB incentives.

The USD amount of bribes placed has fallen significantly in line with the decline in BAL & AURA prices. If we use ARB to bribe I believe we’ll only accelerate the reduction in 3rd party bribing activity as we push the ROI closer to 1:1. I’d argue this leads to no gain at all for voters and would be a waste of 1M ARB.

Directly emitting ARB on the pools seems to be a better option as that increases the amount of emissions up for grabs, thus pushing the ROI for bribers up rather than down. Of course this program is limited to incentivizing Arbitrum pools so it is fair to say only the ROI for Arbitrum bribers goes up - more Arbitrum bribers pushes down the ROI for everyone else and these two things cancel each other out to a large extent. Bottom line is more total emissions should lead to more bribes given we’re effectively pushing 1:1 ROI lately.

I’ll propose the following rule set:

  • 10 round duration, aligning with Aura’s two week cycle of voting incentive allocations.
  • Max of 100k ARB per round. Any unspent ARB simply returns to the treasury.
  • Each pool can have a max possible allocation of 10k ARB per round to prevent one or two pools from taking the majority share of this program.
  • On each Wednesday/Thursday after Aura’s gauge voting snapshot, ARB will be allocated to each Arbitrum pool according to bribes placed in the most recent round on a 1:1 USD basis, subject to ARB caps mentioned above.
  • This ARB will be emitted over a two week period
  • All voting markets are included - projects can choose where to bribe at their discretion. Bribes placed by Balancer under BIP-19 also count.
  • Balancer Maxis will publish a spreadsheet detailing the ARB allocation every two weeks and allow at least 24h for community feedback before execution. We’ll make a forum thread for this purpose.
  • This would not begin until the first Aura voting round after Aura is deployed and ready to emit AURA rewards.

Open to feedback or other ideas

5 Likes

I am in favor of this idea. Directly benefits LPs and drives our economic engine in the most efficient way given the current market situation (and brib dilution).

1 Like

I like this proposal, but I don’t think the emissions of the ARB to incentivise LPs on Arbitrum has been well thought out, and could be optimised/use more thought.

The vote markets are pretty oversubscribed right now, throwing more money into that pot is likely to make it unappealing to participate. On the other hand, we can follow incentives, fees or voting and emit arb directly. I don’t have the answers but I think more research is required.

I therefore suggest that this BIP is modified to cover the LP portion, and to allocate the funds for a incentive program, but that the details of said program are left to a later BIP to sort out. Split the conversation and take some time to figure out the best way/reasons.

Aura just had an interesting AIP that changed behaviours of their incentive programs based on the vote market premium, which is interesting in this case too.

Your ruleset looks good, but the methods for calculating things aren’t clear and IMO should be in a BIP (maybe we need to write some reports and provide an example).

Is there a rush to get that part done? We could also start with this and then adapt/move forward, but this seems to require a lot of reporting without providing any way to do it, nor person responsible for it, nor much of an on-chain specification about how it will be executed on.

there’s no rush for either part really. but in terms of the person responsible for it, that would be me. the reporting required is presenting the ARB allocations for community review 24h before execution which is easily doable. on-chain specification would probably be arbitrum treasury sends LM Multisig on Arbitrum 100k ARB every two weeks and we’ll return any unused amount before next batch is sent.

if the method for calculating isn’t clear I can make a mock sheet.

If you don’t mind making the mock sheet, I think that would be the last step to make things super clear.

The other thing, which is annoying but somewhat important, is exception handling. What happens if there are questions about your sheet? What is the process for deciding and moving forward? I know it’s not likely to happen, but good governance puts clear and deterministic processes around what can become messy and human :slight_smile:

Also fairness, how would a new vote market gaining some traction get included in this program?

The minimum 24 hour period for community review is for any questions. Ultimately the Maxis have to execute the transactions here so it’ll be up to us to come to internal consensus about concerns raised by the community. The only subjective part of this (if you can call it that) is taking the token price at the time we write up the sheet. Maybe yesterday token went down 25% so that project wouldn’t be happy about getting 25% less ARB than they thought. As long as we’re consistent with taking the token price every Wednesday or so, is what it is to me.

Any new vote market that gets a bribe on an Arbitrum pool just needs to alert us of that. I’ll be watching HH, warden, and vote market.

7 Likes

Sounds good enough to me :). I’d like to see a system where vote markets self-report, but if you can quickly pull everything together and save a bunch of partners time figuring it out… It makes good sense.

1 Like