Summary:
Enable gauge for gDAI-MAI-USDC on Arbitrum.
Protocol Descriptions:
MAI
MAI is the most crosschain decentralized stablecoin. It is overcollateralized by decentralized collaterals. A detailed list of collaterals and risk profiles can be found here. MAI has been tested and maintained its peg during several market downturns, notably in May 2022.
MAI currently maintains pools on Balancer’s Ethereum and Polygon deployments.
gDAI
gDAI is a receipt token for DAI deposits on Gains Network. DAI is used by gTrade users to perform trading activities. gDAI depositors act as counterparty facilitators to trades on gTrade.
Gains Network is a leading defi platform on both Polygon and Arbitrum. The protocol leads rankings as one of the most profitable in defi.
Motivation:
Gains Network has seen impressive growth since its launch on Arbitrum. Demand for gDAI liquidity is high and so far untapped. For this reason, adding a pool for gDAI is a significant opportunity for Balancer to grow on Arbitrum.
This pool will also represent MAI’s main liquidity hub on Arbitrum. As such, it will take most of the volume related to liquidations and leverage.
Specifications:
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.
MAI is controlled by a DAO. More info can be found here: link in reply
There is currently no governance process at Gains Network. A timelock of 2 weeks is in place.
Oracles: Does the protocol rely on external oracles? If so, provide details about the oracles and their implementation in the protocol.
MAI uses Chainlink oracles to price collateral assets.
Audits: Provide links to audit reports and any relevant details about security practices.
MAI: The protocol has been audited twice. Audits can be found here: link in reply
gDAI: Seen the audit for Gains here: link in reply
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.
MAI: The protocol runs on decentralized systems such as competitive liquidations, and vote-based collateral onboarding. No single person has admin controls over the protocol. The treasury and some part of the protocol are secured by a multisig of doxxed team members.
Gains: The protocol is run in a decentralized way, with changes made to the protocol being secured under a 2-week timelock.
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.
MAI is one of the most stable decentralized stablecoins and has remained with the peg range for almost 2 years. Below is a chart of normalized volatility for MAI vs peer stablecoins:
The price of gDAI is largely stable, as the underlying asset is DAI. The price of gDAI fluctuates in correlation to its collateral to debt ratio. This metric and other information related to gDAI can be found here.
The pool in question on this proposal was created recently with the aim of kickstarting liquidity for gDAI and MAI on Arbitrum.
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?)
This pool will be the main source of liquidity for both gDAI and MAI. It will also be gDAI’s first liquidity pool.
Link to pool: 0x70Ba7DC356B41c849e74c679932c852CC0331a90
Link to gauge: 0x49A0e3334496442A9706E481617724e7E37EAA08
Specification
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 the gauge address 0x49A0e3334496442A9706E481617724e7E37EAA08
and the corresponding gauge type for the data(bytes) argument.
data(bytes) : 0x3a04f90000000000000000000000000049a0e3334496442a9706e481617724e7e37eaa080000000000000000000000000000000000000000000000000000000000000004