[BIP-656] Enable gUSDC-USDC gauges [Arbitrum]

https://github.com/BalancerMaxis/multisig-ops/pull/1138

Summary:

Gains Network (gTrade) is a decentralized perpetual futures trading platform on Arbitrum. Gains Network aims to list gUSDC, a token that benefits from protocol fees, on Balancer to establish significant liquidity and integrations within the Arbitrum DeFi ecosystem.

References/Useful links:

Link to: • Website: https://gains.trade/ • Documentation: https://gains-network.gitbook.io/docs-home • Github Page: https://github.com/GainsNetwork-org
• Other useful links: https://dune.com/gains/gtrade_stats

Protocol Description:

Gains Network (gTrade) is a decentralized perpetual futures trading platform with a robust infrastructure featuring 181 trading pairs with high leverage [up to 150x for crypto, 250x for commodities, and 1000x on forex], deep liquidity, guaranteed order execution, and accurate pricing. Since inception, the protocol has generated $73B lifetime volume. The asset Gains Network would like to list on Balancer is gUSDC. gUSDC is one of the gVault tokens that receives a share of the protocol fees by serving as a counterparty to trader wins & losses. The history price of gUSDC can be publicly viewed on our dune dashboard linked above. It has generally been an “up-only” asset with the exception of a few dips shortly after the launch of the asset back in January. The historical price of gUSDC can be found here: https://dune.com/queries/3385617/5681244

Motivation:

Gains Network aims to enable a gauge for a gUSDC / USDC pool to significantly increase the liquidity for gUSDC on secondary markets to set the foundation for more integrations with the purpose of expanding its utility across Arbitrum DeFi.

Specifications:

Gains Network will utilize a part of its STIP.B LP incentives budget to bootstrap more (sticky) liquidity for the gUSDC vault as it anticipates more USDC-collateral usage on gTrade over the coming months. Initially, the focus will be on building liquidity on partner DEXs for gUSDC/USDC pools, including this Balancer pool. This strategy aims to unlock various partnership opportunities, creating an ecosystem around gUSDC through lending markets, LP-strategy protocols, and more. Gains Network is seeking to co-incentivize this pool with Balancer to establish the required liquidity as a foundation for said gUSDC integrations and consecutively form a long-term partnership with Balancer as one of the main venues for gUSDC since Gains Network believes Balancer is a pool that can largely be maintained beyond incentives through swapping fees post the bootstrapping phase.

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.

The incentives distributor is governed by the following Multisig address: 0xc5fCA2c19c5Ca269a10e15ee4A800ed82F53787D And, Gains Network is actively working towards being a DAO governed through the $GNS token.

2. Oracles: Does the protocol rely on external oracles? If so, provide details about the oracles and their implementation in the protocol.

gTrade leverages their own custom-built Chainlink decentralized oracle network (DON) to provide real-time, aggregated prices for their leveraged trading products. Their oracle architecture uses a custom DON to supply on-demand prices to an aggregator contract while the official Chainlink Price Feeds serve as anchors, meaning if their price differs by more than 1.5% from Chainlink Price Feeds, a circuit breaker is triggered.

3. Audits: Provide links to audit reports and any relevant details about security practices.

Audits are conducted with each upgrade Gains Network undergoes. With the release of V8 in May, the entire codebase has been audited. Moreover, the release of V9 [current version] has been audited as well.

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.

We will state our centralization vectors by giving insights into our most centralized facet: the DON. The current custom decentralized oracle network is operated by 8 independent chainlink node operators & 1 price feed from StorkOracle.

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.

There’s no information available on the Balancer pool yet as it’s yet to be launched. However, the gUSDC asset is tradeable on a Ramses CL pool as per June 15th and started to get incentivized with $ARB from June 27th onwards. The pool is currently sitting at $2M TVL and can be found here: https://ramses.exchange/liquidity/v2/0xe9e3ef12f1f9dbaf7b7f57ab262c54117448884b Since the inception of this secondary market pool, Gains Network vaults have been consistently overcollateralized while the gUSDC asset has never been below peg and has not experienced significant volatility. Considering the ‘up-only’ nature of gTokens and gUSDC currently sitting at a 124.1% collateralization ratio, the price of gUSDC is expected to continue its upwards price action as time passes.

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?)

The pool will not serve as the primary source of liquidity in the bootstrapping phase, but will be leveraged as the primary source of liquidity once the bootstrapping phase has passed. The pool can generate consistent fees due to gUSDC depositors only being able to use Balancer as a means of exiting before our epoch system, looping through lending markets & liquidations through lending markets.

Pool: https://app.balancer.fi/#/arbitrum/pool/0xe8a6026365254f779b6927f00f8724ea1b8ae5e0000000000000000000000580 Child Gauge: https://arbiscan.io/address/0x0CE9489bBD4bfA0Da7b5bb06E4dFa7a5947F76e8 Root Gauge: https://etherscan.io/address/0x5A482e8478d63219bC33C7F1d7Cdb599039ABad7

The Balancer Maxi LM Multisig eth:0xc38c5f97B34E175FFd35407fc91a937300E33860 will interact with the GaugeAdderv4 at 0x5DbAd78818D4c8958EfF2d5b95b28385A22113Cd and call the addGauge function with the following arguments:

gauge(address): 0x5A482e8478d63219bC33C7F1d7Cdb599039ABad7 gaugeType(string): Arbitrum