Idea summary:
Liquidity Amplifier Pools (LAPs) are a novel method of bootstrapping liquidity to protocols using the rebase mechanism (such as Ampleforth) through the use of Balancer smart pools and stable coin trading pairs. These pools have two distinct features:
- The ability bootstraps liquidity by farming AMM governance tokens (such as BAL) and subsequently sells those tokens for the pools underlying assets in a certain ratio which are then infused back into the pool
- The ability to mitigate impermanent loss by combining stable coins and Balancer smart pool functions with the Ampleforth rebase mechanism.
A simple example of this would be the creation of an AMPL/USDC Balancer smart pool. Liquidity providers of the pool would gain access to farming the Balancer governance token BAL while also be getting a share of the trading fees from the Balancer pool with little to no impermanent loss thanks the interaction between smart pools adjustable weights and the rebase mechanism. While in this scenario the liquidity providers are now in control of BAL tokens, the process of bootstrapping liquidity could be further automated by developing an yVault style strategy that automates the selling of the farmed BAL tokens and injects liquidity back into the pool pairs.
This, in theory, should increase the underlying pools liquidity. Because of the elastic nature of the Ampleforth token, this cloud potentially create almost perpetual liquidity growth that is only constrained by the stable coin supply capacities.
While this is an example of what a basic strategy could be, basically any strategy could be built on LAPs.
Example of different LAPs:
Basic:
- AMPL/USDC pool
- AMPL/sUSD pool
- AMPL/DAI pool
Advanced:
- AMPL/yUSD pool (currently low liquidity but would create exposure to CRV DAO token rewards, unsure if feasible)
- AMPL/sUSD pool via Synthetix mintr (depositing SNX to the Synthetix Mintr, minting sUSD and providing the sUSD to the pool, this requires extra capital but gains exposure to SNX rewards)
- AMPL/USDC/DAI/USDT/sUSD pool (multiple stable coins in the same pool could further amplify liquidity if it is possible to find a balancing mechanism that works with multiple stable coins)
Benefits and Risks:
Benefits:
- Potential long term liquidity bootstrapping (AMMs like Balancer and Curve have indicated that the governance token distribution will last multiple years. See notes at the end of the proposal)
- Liquidity providers are not exposed to impermanent loss which should attract more willing participants
Risks:
- At the time of writing it is unclear how the Balancer smart pool will react to infusion of outside liquidity and how the infusion affects liquidity providers when they want to withdraw liquidity from the pool
- It is also unclear how this type of liquidity bootstrapping would affect other pools with AMPL pairs (could possibly result in massive impermanent loss in those pools)
- Novel method might possess an unknown attack vector that has gone unnoticed in the audits and the team
- Multiple smart contract risks
- Dependance on 3rd party issuance and governance
- The use and creation of yVaults require the holding of YFI (this could possibly be mitigated by developing an own vault program)
- Stable coin supply side crunch could lead to temporary impermanent loss (no pun intended)
Budget/Cost:
unclear, but most likely requires solidity developers to implement and audits to confirm the safety.
Examples of similar ideas:
yVault automated yield strategies have been around for awhile but are not focused on pools probably because the risks related to impermanent loss.
Idea timeline:
unclear, most likely needs several months of development and testing
Notes:
BAL Distribution schedule (10 years):
https://medium.com/@fernandocmartinelli/proposing-balancer-liquidity-mining-897aecf744d4
CRV Distribution schedule (6 years):
https://guides.curve.fi/crv-launches-curve-dao-and-crv/
Absolutely love the idea, Tim.
Amplesense can add value by making the vault a one stop shop. A lot of the math and mechanics is very complex for most people. If they can just deposit into a smart vault that does all the work for them and spits out potentially a number of different coins that’s huge.
Yield farmer attention spans are low in my experience, and there is always another shiny thing just over there; so anything that is simplified and profitable will be a massive winner.

Ampl balancer smart pools are out.
How would this design impact this concept?
This is very interesting. You have laid out the proposal well and considered many of the variables.
My main question for now (I have others) is how this intersects with what the team is planning with smart pools currently (see comment from Brandon below).
The second is about the intended (or unintended) impact of the capital distribution method. Can you talk about the benefits for Ample holders and lps a bit more? Does this generate more organic demand for Ample? Would this harm Ample’s Balancer pools?

Thank you for the comments!
As for the main question it is definitely a good one. Many things in the LAP proposal hinge greatly on specific how the Balancer smart pools will work on the nuts and bolts level. Questions such as:
– “How will the smart pool react to infusion of new capital when it doesn’t come from the liquidity providers”,
– “How will the smart pool react to infusion of new capital when it doesn’t come in the same ratio that the pool currently has (for example infusing only the stable coin side)” and
– “Does the LAP create a conflict between liquidity providers that want to and don’t want to participate in the LAP because of the mechanism that drive liquidity to the LAP pool”
… will be better understood once the specifics of the smart pool come out. Most likely some of the assumptions made in the initial proposal must be rehashed in order for the implementation to work.
The second question is also important because at the moment it is unclear how the LAP would affect other liquidity pools if it becomes successful. In my mind a successful LAP could potentially create impermanent loss in liquidity pools such as AMPL/ETH if the price of the AMPL token surges significantly. This is however an unproven theory and needs more in-depth analysis of potential outcomes.
Pure holders should however stand to benefit from the increased supply of AMPL due to undilutable nature of the asset. As for creating organic demand, I think the Balancer smart pool without impermanent loss will in itself create massive demand for AMPL but in my mind the added buying pressures will garner interest with both traders and liquidity providers. However I imagine that some LP’s will prefer to hedge their bets by either holding to the BAL token or choosing to sell it for some other asset.

Yes. I understand this better now.
I guess I have a few more questions:
1. Generally the DAO would likely look to fund specific platforms or applications. Is this something that can be turned into a product that users will easily understand the benefits of?
2. One of the criteria for funding is that the projects don’t harm or counteract what the core development team is doing. The potential for harming the main Ample Balancer pool might be something that causes us to move carefully on something like this. It might be good to flesh that out a bit more. We want to be complimentary to the team, rather than additive or harmful. Can you address this concern also?
3. I’m also having a hard time understanding whether this is just a smart pool or a new project, which is related to question 1 above.

The end product would probably be similar to adding liqudity to the Balancer pools but instead of going straight to the Balancer website, the users would deposit the funds through the yVault webpage (https://yearn.finance/vaults) or something similar. If it is done separately of yVault (and if minimal to no governance is wanted, this would be preferable) then a robust user front-end website where users can deposit/withdraw funds (similar to yVaults) and an underlying smart contract deployment would be required.
I think it is safe to assume that the LAPs could potentially have some negative consequences for the Balancer smart pools and necessary steps should be taken to assure that something like that doesn’t happen. I think the DAO should not proceed in funding the Liquidity Amplifier Pool idea at least until further basic analysis can be made on the possible effects on the smart pool which can be done once the specifics of the smart pool are available. Even in the event that no risks are found, it would be a good idea to initially create a hard cap on the amount of capital that can be pooled through the LAP so that any possible damage that could arise can be controlled and minimized. When the safety of the interaction between the LAP smart contract and Balancer smart pool can be confirmed this hard cap could be then raised gradually or removed all together.
As for the third question, It is a new project that uses the existing smart pool as a tool to funnel generated funds back to the smart pool. Basic interaction between the user and the LAP smart contract goes like this:
1. User deposits funds to the LAP smart contract (yVault or other)
2. The LAP smart contract deposits the funds to the Balancer smart pool, effectively becoming a liquidity provider in itself
3. The LAP collects all the trading fees and BAL that is generated from its share of the smart pool
4. The smart pool allocates and keeps track of all the generated fees so that when the user wants to exit the LAP, they will receive those upon exit
5. The LAP will systematically trade the acquired BAL on the open market for the smart pools underlying assets in certain ratio (what this should be depends heavily on the inner workings of the smart pool and objectives of the LAP, see notes for more thoughts)
6. The newly acquired assets are then deposited into the smart pool where they continue to generate more trading fees and BAL (these newly acquired assets belong porpotionally to the LPs that were providing liquidity during acquiring and selling of the BAT, a mechanism to counteract reward theft by sudden big liquidity providers should also be created)
7. When user want, they can exit the LAP, which prompts the smart contract to remove the users share from the liquidity pool and return those assets and the trading fees they have acquired to the users wallet (note that yVaults have a general withdrawal fee of 5% that is given to the strategy writer)
Notes:
While the initial idea of the Liquidity Amplifier Pools is to grow the size liquidity of the liquidity pools, a myriad of different strategies can also be implemented through the LAPs. For example part of the acquired BAL could be held as a reserve which would be used used to:
buy AMPL when the AMPL price trends under the target price, used to buy smart contract insurance from Nexus Mutual or used to fund different EFi or general Ethereum ecosystem public goods. The possibilities are literally endless.
While it is being quite a while since I posted this idea. I have gone over my notes and noticed that this idea may indeed not be suitable in its current form because the Balancer whitelisting process quotes the following:
“The barrier to entry would be quite low for whitelisting tokens, but at any time, if a token is deemed to be either maliciously harming LPs or gaming the BAL distribution, it could be removed with a governance vote. Note that this approach passes no judgment on the intrinsic value of a token and leaves liquidity providers to decide for themselves what is and is not a “good investment” or a “legitimate project.” Tokens would never be omitted or removed from the list on subjective merits; rather, one of two explicit removal criteria must be met:
1. There is significant evidence supporting the hypothesis that a fraudulent event took place in which token holders lost funds, i.e. an exit scam.
2. The token is being used as a BAL farm, thereby disadvantaging other Balancer liquidity providers. For example, perhaps 80% of the token’s supply sits in a Balancer pool with a 0.0001% fee, and it draws either very little or mostly inorganic trade volume. Care must be taken not to over-emphasize volume here, but it may help to refine the list of potential manipulators. Another example of BAL farming could be that a single entity launches many different tokens to circumvent the $1M liquidity cap.
Since the idea in it’s original form has at its center to use the distributed $BAL to boost AMPL liquidity, it might be a good idea to take a step back and ponder if it is feasible.