Proposal: btnFORTH Liquidity Pool on ElasticSwap

Ampleforth Governance
1

SUMMARY

The HourGlass team is proposing for the FORTH-DAO to utilize a portion of its treasury to provide liquidity on ElasticSwap with btnFORTH, which is the foundation in the elastic stack for the HourGlass DAO-bonds being prepared for FORTH-DAO.

RELEVANT DISCUSSIONS

BACKGROUND
The HourGlass team is a decentralized marketplace where the FORTH-DAO will be able to issue convertible-bonds against its FORTH equity. We are doing this with the help of the ButtonWood Contracts (rebasing wrappers + tranching). The foundation of this elastic stack is the rebasing wrapper which will be used to deploy buttonFORTH (btnFORTH for short). btnFORTH is the supply-volatile version of FORTH. HourGlass bonds will also be able to use the supply information given by btnFORTH as a parameter to determine payoff.

MOTIVATION & SPECIFICATION
In order to deploy btnFORTH, a FORTH-USD Chainlink Oracle on ETH mainnet will need to be sponsored. HourGlass team is currently planning on sponsoring the FORTH oracle with it’s Hackathon winnings, but Chainlink also requires confirmation that there will immediately be value being secured on-chain before they can deploy the FORTH-USD oracle on mainnet. We would like to deploy btnFORTH ASAP instead of waiting for the remaining HG & BW contracts since it gives an opportunity to test the elastic stack in stages rather than all at once.

If the FORTH-DAO is willing to provide liquidity with btnFORTH on ElasticSwap, it will help with the following:

  • Rapid deployment of FORTH-USD oracle to enable btnFORTH for the HG elastic stack
    • This oracle can also be used as a KPI in the HourGlass bonds explained here
  • Allow FORTH-DAO to earn TIC-USDC LP token on it’s idle equity
    • TIC-USDC yields are unrealized until platform fees are generated. The configuration of emissions can be followed in ElasticSwap’s discord server in the configuration channel
  • Bring more use cases & awareness to the ButtonWood contracts (rebasing wrapper)

IMPLEMENTATION/ FINANCIAL IMPLICATIONS

There are a few different ways this can be implemented:

  1. btnFORTH/ wAMPL pool
  • Pros: Fastest to implement, only requires btnFORTH deployment
  • Cons: Since wAMPL is a fixed supply token, there will be IL incurred
  1. btnFORTH / USD pool
  • Pros: No impermanent loss
  • Cons: Requires selling $500k of AMPL or FORTH into USD in order to get the minimum recommended liquidity ($1M total) for a pool on ElasticSwap
  1. btnFORTH / AMPL pool
  • Pros: doesn’t require wrapping AMPL, or any additional USD, no IL besides from AMPL’s price
  • Cons: ElasticSwap currently only supports rebasing/fixed pairs, they do not have a timeline for rebasing/rebasing pairs
  • While this option doesn’t make sense w.r.t. timelines for the reason above, it was listed here in case anyone else was considering

POLL

  • btnFORTH / wAMPL Pool
  • btnFORTH / USD Pool
  • btnFORTH / AMPL pool (no timeline yet from ElasticSwap)
  • I do not support this proposal

0 voters

ABOUT THE TEAM
https://test.hourglass.wtf initially started as a project for the 2021 ChainLink fall hackathon, where we won one of 20 Top Quality Awards, and the first prize for the Ampleforth Award. In as little as 1.5 months we went from idea to a proof-of-concept on testnet. In the months since, we’ve expanded the scope of what the concept can support, as well as the benefit it can provide to the ecosystem.

2 Likes
2

I’d prefer the btnFORTH/USDC pool for its no IL benefits, but now really isn’t a good time for selling AMPL or FORTH to get that USDC.

There’s scope for the DAO borrowing against AMPL on Mooncake: this would result in it converting AMPL into some USDT (to be swapped for USDC) and AMPL Z tranches, selling A and B tranches at some sort of discount. I’d expect there to be sufficient demand for purchasing those discounting A and B tranches but I think now is an unwise time to be holding Z tranches. It’s unclear whether we’re on the precipice of another market fall or not, but to minimise risk it would be far more prudent to simply wrap some AMPL into WAMPL to use as the pair token.

One thing I’m not clear on though… why does Chainlink have this requirement?

Does it need on-chain liquidity to source price data from? If so, there’s a chicken and egg scenario - can’t make btnFORTH without oracle feed, can’t make oracle feed without on-chain liquidity.

Or is Chainlink simply requiring that its oracle is destined to be used, so that they’re not running something pointlessly?

2 Likes
3

That’s a great point, I hadn’t considered borrowing against the AMPL.

Or is Chainlink simply requiring that its oracle is destined to be used, so that they’re not running something pointlessly?

This is the reason; it’s due to Chainlink’s Sponsorship model and the costs associated with having an oracle running that’s not being used. We’ve already confirmed that there’s enough CEX and DEX liquidity & trade volume with FORTH to create the oracle feed.

4

Ah interesting, but if they just need assurance the oracle will be used can’t we achieve that by creating the btnFORTH and calling the oracle regularly even if btnFORTH doesn’t have a market itself?

5

Hey @Fiddlekins,

can’t we achieve that by creating the btnFORTH and calling the oracle regularly even if btnFORTH doesn’t have a market itself?

Just checked in with our Chainlink reps and this is absolutely acceptable; so this liquidity proposal is by no means a hard requirement from Chainlink to deploy the oracle. We will continue to move forward as planned with the oracle & btnFORTH deployment. This would make the primary motivations for this liquidity proposal to be the following:

  • Gives the FORTH-DAO a way of diversifying its LP exposure
    • btnFORTH/wAMPL should provide a different IL exposure compared to FORTH/AMPL (would appreciate if someone can confirm this?)
    • btnFORTH/USDx would have the benefit of being IL-less

Personally I still see a significant benefit in creating a decently liquid market with btnFORTH before we launch the rest of the contracts in the elastic DAO bond stack for the following reasons:

  • IIRC, this will be the first buttonToken on ElasticSwap. Not planning on any hiccups; but if there is something missed, it’s always preferrable to find out sooner rather than later. I imagine we can be more assured that there’s no outstanding issues once we have a significant amount of TVS (total value secured)
  • The other main benefit I see is that since the DAO-Bonds will eventually settle in btnFORTH at maturity, I would think that it would helps to start building out a liquid market for it as soon as possible. It will make it easier for marketing/advertising the DAO-bonds when they are ready because there will be some familiarity
2 Likes
6

If it’s not required for the oracle then I don’t think this proposal is worth it.

Whilst the bonds will settle into btnFORTH, we can set up a router contract that will automatically unwrap them back to FORTH when redeeming so from a user perspective this is a non issue. On the flipside, making a btnFORTH pool would disrupt DEX aggregators as they wouldn’t recognise it when trying to optimise the path for a FORTH transaction.

If we were to pursue a DEX pool with AMPL and FORTH in as per the other outstanding thread I think AMPL/FORTH makes a lot more sense than WAMPL/btnFORTH

Glad to hear the FORTH oracle can be set up without issue though :raised_hands:

I don’t believe it would. As I understand it the ElasticSwap pools work such that IL is minimised to price divergence only, and completely eliminated in price ratio returns to what it was when entering the pool. Assuming this is the case then I don’t see why being wrapped one way or another would have any impact on this.

EDIT: I take back what I said about AMPL/FORTH behaving the same as WAMPL/btnFORTH. They have mirrored effects around which way the price divergence goes

7

Agreed, if the chainlink oracle requirement has a path forward, an AMPL/FORTH pool makes more sense this early on.