[Proposal] Authorize Gauntlet for Oracle Pools

Governance General Proposal
1

Three weeks ago, Balancer governors voted to allow Gauntlet to set swap fees on pools deployed from the WeightedPoolFactory. At the time, this was the only Balancer V2 pool factory available; but since then, another specialization has been deployed for two-token pools which provide TWAP oracles. This proposal seeks to grant the same authorization to Gauntlet, but for the new pool factory.

Motivation

Please consult the original proposal for the full details. In short, this authorization would apply only to pools using the delegated owner address (0xBA1BA1ba1BA1bA1bA1Ba1BA1ba1BA1bA1ba1ba1B). For those pools which have opted in, Gauntlet’s power would extend only to the swap fee; Gauntlet cannot alter any other attributes of the pool nor extract funds.

Specification

The Balancer Governance Multisig would submit one transaction as follows. Here, “Multisig” refers to the Gnosis Safe at 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f and “Authorizer” is the smart contract at 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6.

  1. Grant Gauntlet the ability to set swap fees on pools deployed from the WeightedPool2TokensFactory
    Multisig → Authorizer → grantRole(0xc065d550fa98abc242b6baf98e7b2063590675f1ddd81bdb9ea8d8f5c5d52f98, 0xE4a8ed6c1D8d048bD29A00946BFcf2DB10E7923B);

For transparency’s sake, a developer could reproduce the bytes specifying the role above using this pseudo-code:

pool.getActionId(pool.interface.getSighash('setSwapFeePercentage')); // 0xc065d550fa98abc242b6baf98e7b2063590675f1ddd81bdb9ea8d8f5c5d52f98
1 Like
2

Appreciate the efforts to optimize fees and am all for exploring this further, but ideally we proceed via an experiment to evaluate impact.

Specifically:

  • Adjusting fees almost certainly involves tradeoffs and 2nd order effects on metrics like earnings, volume, & TVL. The methodology doesn’t estimate what these impacts might be, or share data on estimated impact from simulations.
  • If we imagine a perfect model (too complex to implement short term, but possible over time), it likely adjusts fees to poach trades from Smart Order Routing systems (e.g. 1inch, Metamask), setting fees that maximize per-transaction earnings & minimize IL while maximizing trade volume (bidding low enough to secure trades we’d otherwise lose, potentially prioritizing trades that reduce IL). Ideally our strategy explores what’s possible today (e.g. analyzing inefficiencies of the cross-platform auction & identifying potential opportunities)
  • Model weights (h0 - h7) appear to be arbitrary. If simulations estimate impact, these weights can be calibrated via regression to optimize earnings, IL, etc. Even if the model is imperfect, weights can likely be improved.

It’d be great to see this run as an experiment that measures impact Vs control groups. We performed similar optimizations all the time at Google. Doing so via controlled experiments establishes impact and enables data-driven improvements over time.

Without an experiment we’re forced to wonder “Did this change actually achieve a positive impact?” If this achieves a 6% gain in LP profitability without hurting TVL, that’s great. If this achieves a 5% gain in short term LP earnings, but appears to result in a 4% loss of TVL to competing platforms, that’s a trade-off to consider carefully. Without an experiment, we’ll never know.

Edit: If an experiment won’t happen this time around due to lack of time/resources, I’d likely vote to support this proposal in any case as a likely improvement over the status quo. That said, this is a great opportunity to run an experiment & lay the groundwork for continued data-driven improvements in the future.