We 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.
In order for trades to start on the pool, we need an initial resting (seed) liquidity. After the concept is proven out, we believe new TWAMM pools will be launched permissionless on Balancer. We believe the trading fees paid to LPs from traders and arbitrageurs of TWAMMs will far exceed the current status quo.
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.
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.
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.
Super excited to see TWAMMs making their way to the balancer ecosystem. That being said, we need to be careful around custom pools as we don’t understand them as well or have as much visabilty into how they are working.
As this is a custom pool, there’s a few things I would like to see before this goes to a vote:
1: A UI where users can deposit, withdraw and get info about their holdings in this pool.
2: Evidence that 50% of fees are being paid to the ProtocolFeeCollector
3: Some sort of dashboard or other metrics showing some amount of active trading volume in a pool that already has at least enough liquidity to trade semi-frequently.
Further I see another request for a custom relayer. Will this pool function without a relayer or is the functionality of the pool and hence this gauge dependant on the relayer being deployed, allowed and tested?
Happy to see the excitement for our protocol, we can’t wait for the launch!
We are unable to provide a dedicated UX for users to interact with TWAMMs due to the hostile regulatory environment, see the Wells notices served to Coinbase, Uniswap, Sushi, etc. This was a major factor for us to pursue the relayer to simplify interacting with TWAMMs from Etherscan/Gnosis Safe etc.
We want to maximize the permissionless and decentralized nature of the product and a dedicated UX is the Achilles heel targeted by regulators. Furthermore, we are actively working with integrators to expose these functionalities via their UX, see DefiLlama, Zerion, InstaDapp, etc
It was agreed upon that initially the fees will be set to 0 and will be increased as the protocol gets traction and a fair fee split can be agreed upon. Currently, all the fees flow back to the pool LPs including the MEV. Here’s the initial proposed fee schedule:
The relayer and pool are independent. Advanced users can and should (gas efficiency) interact with the pool directly via the core smart contracts. The relayer is a convenience layer to abstract the complexity of interacting with TWAMMs for less sophisticated users in the absence of a dedicated UX.
Thank you for all your answers. Where you’re going looks great. Have you considered offering a bounty for someone to write a safe app to allow DAOs and entities to more easily interact?
Gauges are meant to pay emissions out to revenue generating pools. I don’t think it’s appropriate to have a gauge on a pool that doesn’t generate any protocol fees with it’s trading. I may be an odd man out here. The standard fee split is 50%, a portion of which may be redirected to bribes on the pool depending on the gauge arrangement.
We can enable a gauge to allow you to setup an emissions schedule of your own in order to directly incentivise deposits without adding it to the veBAL system until the pool is revenue generating.
Maybe others see things differently. My entire vote is delegated so I’m just here to provide feedback, not decide.
After discussing this further, I think the appropriate thing to do is the standard 50% revenue share via BIP-19, as this is a core pool. It’s also efficient as bribes are paid out directly from the DAO revenue.
Capturing a good chunk of the ETH/USDC volume would be extremely beneficial for the Balancer protocol, and thus should be included in that improvement proposal.
With the protocol fee at 50% I think it is fair for this pool to have an uncapped gauge; contingent upon the relayer proposal mentioned above passing. I appreciate your flexibility on this to align with the DAO’s usual expectations. Interested to finally see a TWAMM pool in action. Will likely be in everyone’s best interest to have stats visible to showcase this pool type down the line. Congrats on making it to the end of a chapter for this thorough product development cycle.
I still lean towards a 2% cap because it’s likely the user base for this will be quite limited without a UI. If that proves to not be the case governance can raise or remove the cap.
I also lean towards 2% cap to start, it can always be adjusted in the future. I don’t think the project needs more than 2% of emissions to start with anyways.
