Summary:
This pool will be replacing the previous wstETH/rETH gauge as we’ll be deploying a different type of TWAMM pool that’s better suited for the type of asset pair, see previous post: [BIP-265] Enable wstETH/rETH Gauge [Ethereum].
We’d like to request governance to disable the old pool gauge. No liquidity has been added and we have paused the pool so no liquidity can be added or trades can happen.
We’d like to request a gauge for the new pool. We have launched a brand new Balancer pool type: TWAMM. This will be a cornerstone in Balancer’s vision of the go-to AMM for DeFi protocols to build and trade upon. TWAMMs are extremely capital efficient and are critical to improve the blockchain’s anti-fragility by facilitating large asset swaps completely on-chain, see asset monetary policy, whale liquidations, treasury management, index fund re-balancing, etc.
References/Useful links:
Link to:
• Website: GitHub - Cron-Finance/Cron-Finance
• Documentation: https://docs.cronfi.com/
• Github Page: https://github.com/Cron-Finance/twamm
• Communities: Mirror, Twitter
Protocol Description:
Motivation:
In order for trades to start on the pool, we need an initial resting (seed) liquidity. We believe the trading fees paid to LPs from traders and arbitrageurs of TWAMMs will far exceed the current status quo. We’re trying to execute a large treasury diversification for the Nouns DAO, more context here: Nouns DAO
Disable Old Gauge
Link to old pool
Link to old gauge
Enable New Gauge
Link to new pool
Link to new gauge
Specifications:
- Governance:
- Factory Owner: Gnosis Safe Deployer
- Admin Privileges: Admin Privileges - TWAMM
- Governance plans: initially the factory owner will be the default administrator of the pools. However, as new pools are created we plan on handing over the admin privileges to the token’s DAO or controlling party as needed.
- Oracles:
- No external reliance, we have a built-in oracle.
- Audits: Provide links to audit reports and any relevant details about security practices.
- Centralization vectors:
- The only centralization vector is the factory owner controls the admin privileges. The factory multi-sig is a 2/3 Gnosis Safe. The capabilities that the admin has is pausing and setFees. Both of these are in place to ensure optimal operations of the pool. LPs can monitor these events and are free to withdraw liquidity at any time.
- Market History:
- Both tokens are wrapped staked ETH.
- 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?)
- No, the pool would need roughly $100 - 200k in liquidity to begin with. TWAMMs are extremely capital efficient because they split the trade across thousands of blocks and dedicated arbitrageurs are constantly replenishing the capital when they correct asset price deviations.
- Nouns DAO is interested in diversifying their treasury of stETH to rETH, roughly $28M at current prices - wallet . This will be an extremely important trade to prove the concept of our protocol and make Balancer the go-to venue for treasury diversification needs.
- Once TWAMMs become the de-facto solution for large asset swaps, we believe Balancer protocol will become the schelling point for protocols interested in advanced trade execution.
Please write a new bip-xxx post to encompass the changes of killing old gauge and adding the new one.
Specifications:
Part A:
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 0xB5bd58C733948e3d65d86BA9604e06e5dA276FD1 and the corresponding gauge type for the data(bytes) argument.
data(bytes) : 0x3a04f900000000000000000000000000b5bd58c733948e3d65d86ba9604e06e5da276fd10000000000000000000000000000000000000000000000000000000000000002
Killing Old Gauge
Part B:
The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the AuthorizerAdaptor at 0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75 and call performAction using 0xab8f0945 for the data(bytes) argument and 0xEeDEd342aa2Cc1b48ECcAfeB663fdf2c1d166934 for the target(address) argument.
