[Proposal] BAL for Gas

On behalf of the Balancer community, I’d like to propose significant modifications to the ongoing gas reimbursement campaign. We have heard some concerns that the campaign is confusing and that it isn’t clear how much BAL a user will receive for a given trade. During these times of network congestion and high gas costs, we want to provide everyone with an opportunity to trade on Balancer. With that in mind, it doesn’t seem fair to ask users to exercise blind faith and wait until “next Wednesday” to find out what they’ve earned from trading. We would like to make every effort to simplify the campaign and improve transparency; what you see is what you get, or at least as close as possible. We plan to accomplish this by removing various sources of uncertainty from the reimbursement calculations so that it is possible to get an estimate ahead of time and display it to the user at the time of trade submission.

The Proposal

Allocate 30,000 BAL from the Ecosystem Fund to the “BAL for Gas’’ campaign. There is no fixed time period; the budget is consumed on a first-come, first-served basis. When the budget is exhausted, the campaign is suspended until it is replenished by BAL governance.

For each eligible trade made through the Balancer Exchange Proxy, award claimable BAL tokens to the trader. An eligible trade is a trade containing one or more eligible swaps, where an eligible swap is a swap between any two tokens on the whitelist. Claims are made available at the BAL claims interface on Wednesday (UTC time) following the close of the weekly period (00:00 UTC Monday - 23:59 UTC Sunday) in which the trade occurred.

The amount of gas to be reimbursed is predetermined by the number of eligible swaps within the transaction:

For converting gas to BAL, use the median gas price of the enclosing block and the BAL/ETH price from CoinGecko closest to the block time.

Motivation

The proposal above may seem familiar, but there are some very important distinctions between this and the previous reimbursement program. All modifications share the common goal of improving user experience, which we believe is a matter of simplification and transparency.

First, this proposed campaign makes no effort to account for the actual expenses of the user. Both the amount of gas consumed by the transaction and the gas price ultimately paid are irrelevant. Instead, deterministic figures are favored: the amount of gas is fixed depending on the number of swaps, and the gas price is the block median, rather than the user’s own price. It is simply too difficult to accurately predict the parameters of a given transaction ahead of time, whereas it is much easier to predict block-wide parameters. Predictability informs transparency.

The second major shift pertains to the budget. The existing program allocates a fixed weekly budget, which can sometimes necessitate cuts to the reimbursements in order to avoid excess spending. Such cuts can only be known after the weekly period has ended, and therefore the existence of a weekly budget renders any trade-time estimates useless. In contrast, here we propose a fixed total budget which is distributed on a first-come, first-served basis. This allows us to add reimbursement estimates to the Exchange UI at the time of the trade. If there are still funds remaining in the budget, the user will see an estimate of the amount of BAL to be awarded; and if the budget is exhausted, then the user will simply be informed as such and the estimate will be zero. When the well runs dry, BAL governors can decide whether to replenish and continue the campaign.

Third, the BAL/ETH price model is modified. Whereas the ongoing campaign uses the median price for the whole weekly period, the proposed campaign uses the price as close as possible to the actual block time. Knowing the approximate price at the time of the trade allows us to make informed estimates about the amount of BAL to be awarded.

Finally, the fixed amounts of gas (130k, 220k, 300k, 400k) were chosen so that only 1% of all trades, on average, would be overcompensated. This should be sufficient to prevent gaming the system for profit, but nonetheless we reserve the right to filter out suspicious activity. The Balancer Exchange UI will never perform more than four swaps in a single trade, which is why only four numbers are provided; any transactions containing 5+ swaps must belong to bots, whereas the target audience is end users. We simply cap the reimbursement amount at 400,000 gas; any additional eligible swaps beyond the first four will yield no further benefit.

Mechanics

Although every effort is made to be as transparent and accurate as possible, there is still a very small amount of room for error. Here we will detail how the BAL amounts are computed both at trade time (estimated) and at dispersal time (actual).

At the time of the trade:

  1. Determine the number of eligible swaps. An eligible swap is one leg of the overall trade in which both tokens are on the whitelist.
  2. The amount of gas to be reimbursed depends directly on the number of eligible swaps: 130,000 gas for one swap; 220,000 gas for two swaps; 300,000 gas for three swaps; and 400,000 gas for four or more swaps.
  3. The estimated gas price for display purposes is the median from the last few blocks according to the getGasPrice() function from the web3 provider. This should provide a good corollary to the median of the actual trade block, which cannot be known in advance.
  4. The estimated BAL/ETH price for display purposes is queried from the large 80/20 BAL/WETH pool. This acts as a real-time oracle which isn’t worth manipulating because it is only used to display an estimate and not to compute an actual award amount.
  5. The user will see, in one summary number, the final result of #1-4: the approximate amount of BAL to be awarded for this particular trade, assuming there are still funds left in the budget. A USD estimate is also provided for completeness, with the BAL/USD price being queried from CoinGecko’s API.

The UI changes are still being finalized, but as a mockup consider the image below.

At dispersal time (computed by the open source mining scripts):

  1. Determine the number of eligible swaps. An eligible swap is one leg of the overall trade in which both tokens are on the whitelist.
  2. The amount of gas to be reimbursed depends directly on the number of eligible swaps: 130,000 gas for one swap; 220,000 gas for two swaps; 300,000 gas for three swaps; and 400,000 gas for four or more swaps.
  3. The actual gas price is the median from the block containing the trade. We will filter out artificially low-price transactions which are sometimes included by miners and can skew the median - these are typically 0-gwei or 1-gwei transactions.
  4. The actual BAL/ETH price is queried from the CoinGecko API for the time closest to the block time of the trade.

It should be clear that the only possible sources of error between the estimate and the actual award are most likely quite small: the median gas price from the last few blocks may not perfectly match the median of the trade block, and the 80/20 BAL/WETH price may not perfectly match CoinGecko’s BAL/ETH price. All in all, the user should see a highly accurate estimate of the BAL award at trade time, and this improved user experience should bring more traders to the campaign.

References

If any details of the ongoing campaign are not made clear in the proposal above, it may be helpful to consult the proposals from former iterations of the campaign.

Original: [Proposal] Balancer Exchange Gas Reimbursement

Expand the eligible token list from 5 tokens to over 400 tokens: [Proposal] Expand the Exchange Gas Reimbursement to all Whitelisted Tokens

Extend the program duration from 4 weeks to 8 weeks: [Proposal] Extend the Exchange Gas Reimbursement Program 4 Weeks

2 Likes