Balancer

PR with payloads

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

Gauge Proposal Template:

Summary:

Swell DAO proposes the creation of a Balancer Boosted Gauge for a swETH-bb-a-WETH pool on mainnet, with a 10% emissions cap.

References/Useful links:

Link to: • Website -> swellnetwork.io • Documentation -> docs.swellnetwork.io • Github Page -> https://github.com/SwellNetwork • Discord -> https://discord.gg/swellnetwork • Twitter: https://twitter.com/swellnetworkio?lang=en

Protocol Description:

The Swell DAO was formed to build a liquid staking protocol to provide the holders of Ethereum (ETH) the means to earn yield through staking without the constraint of locking up capital. Swell’s mission is to create a more secure, decentralized and transparent financial future for the world that does not discriminate or censor economic freedom. The beginning of that journey for Swell starts with continuing to advance liquid staking as one of the fundamental building blocks of modern day decentralized finance (DeFi) that is composable and fully integrated with the Ethereum ecosystem. Similar to other LST protocols, Swell issues a liquid receipt token (swETH) representing your share of ether staked on the Beacon Chain via a permissioned validator set. The exchange rate between swETH/ETH will gradually increase as staking rewards accumulate, though swETH is not redeemable for the ether principal and rewards until after the Ethereum Shappella upgrade that will allow stakers to withdraw from the beacon chain.

Motivation:

Swell is currently is looking to host a swETH-ETH pool on Balancer, that serves as the main source of liquidity for swETH. Swell is looking to expand the availability and liquidity of its LST, starting with swETH, through Balancer. Ahead of and after the Ethereum Shapella upgrade, liquidity and yield on LSTs will be a key competing factor as LST protocols seek integrations and a broader base of holders. Swell is committed to driving value to the veBAL ecosystem by incentivizing pool liquidity via Hidden Hand voting incentives. Deeper liquidity should lead to increased volume and revenue accrual.

Specifications:

1. Governance: Governance will be carried out on the Swell DAO Forum. https://forum.swellnetwork.io/

2. Oracles:

• Direct Balance Query: The swETH token has an internal getRate() function (rate provider) that calls swETH’s own wETHToETHRate() function. See the contract here Contract Link. For this reason the token address can be specified as the rate provider.
• Chainlink PoR

3. Audits: https://github.com/SwellNetwork/v3-core-public/blob/master/Audit Reports/Sigma_Prime_Swell_Network_Security_Assessment_Report_v2_0.pdf

4. Centralization vectors: Based on current design, repricing and deposits are done through a centralised bot run by the foundation. Repricing requires off-chain information to be published to the contract. It is not possible to allow others access to this at this time as they could publish incorrect information leading to incorrect repricing rates which could have the primary effect of allowing an attacker to mint an excess of swETH. The foundation has a path to getting all data needed fully on-chain/decentralised through Chainlink, however this will take some time.

5. Market History: swETH has just launched so there is not much market history and balancer will be the first pool supporting swETH

6. Value: Swells swETH-bb-a-WETH pool will be the main source of liquidity for swETH holders. We have chosen to go with a balancer boosted pool to make our pool 100% yield bearing which will both benefit Balancer LPers and Balancer through increased fees once we transition to a core pool.

7. Link to the swETH/ETH pool on Balancer: 0x02D928E68D8F10C0358566152677Db51E1e2Dc8C Link to uncapped pool gauge: 0x11Ff498C7c2A29fc4638BF45D9fF995C3297fcA5

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 0x11Ff498C7c2A29fc4638BF45D9fF995C3297fcA5 and the corresponding gauge type for the data(bytes) argument.

data(bytes) : 0x3a04f90000000000000000000000000011ff498c7c2a29fc4638bf45d9ff995c3297fca50000000000000000000000000000000000000000000000000000000000000002