Proposal: Use Arrakis PALM for Deepening DAO Owned Liquidity

Ampleforth Governance
1

Summary

Deploy Arrakis PALM to conduct market-making on UniV3 for FORTH.

Arrakis and PALM

Arrakis Finance is a trustless market-making infrastructure protocol that enables running algorithmic strategies on top of Uniswap V3.

Since launch, Arrakis has acquired:

  • >$1.7b in TVL at its peak (currently around $460m), across Ethereum, Optimism and Polygon

  • >25% Uniswap V3 total TVL

  • >80 projects have their liquidity managed via Arrakis vaults

A SPOT/USDC Arrakis vault is already used within the Ampleforth ecosystem to create an easy entrypoint to being a SPOT Liquidity Provider. It is also used as a way to tokenize LP positions so the geyser program can work with Uniswap V3. This vault currently holds > 40% of the SPOT/USDC liquidity pool on Uniswap.

Arrakis PALM, Protocol Automated Liquidity Management, is a liquidity bootstrapping mechanism that taps into the organic trading volume on UniV3.

PALM is designed to bootstrap liquidity by acquiring more base asset inventory. For instance, the Forth DAO can seed liquidity with an initial asset ratio of 90/10 in FORTH/ETH. PALM can progressively balance it towards a target ratio, like 50/50, only by taking advantage of the volatility to make markets for FORTH. Not only will this approach save the DAO Treasury from spending ETH on liquidity and FORTH/AMPL/SPOT on LP incentives, but it will also put no downward pressure on FORTH price since the market-making is done via setting up LP positions instead of doing swaps.

During the time of deployment, the Forth DAO community would have full transparency of the execution and performance of PALM via a custom dashboard, and it retains full custody of the liquidity in the vault. At any point in time, the DAO could withdraw the fund from the vault or revoke the managing access from PALM. PALM can only conduct market-making with the liquidity deposited in the vault, and will never be able to remove the fund.

A case study of Arrakis’ first PALM deployment for Gelato’s GEL token showed very good results, accumulating from 2 ETH to nearly 170 ETH in under 3 months.

Arrakis charges two fees:

  • Management fee: 1% AUM fee on a yearly basis

  • Performance fee: 50% of trading fees generated

Read more at–

Website: https://www.arrakis.finance/

Docs: https://resources.arrakis.fi/

Current State of FORTH Liquidity

FORTH is listed on a variety of Tier-1 centralized exchanges like Binance, Coinbase, Kucoin, Kraken and does in excess of $5M of daily volume. Despite this, there is no meaningful FORTH liquidity onchain. Creating a pool onchain would allow the DAO to tap into the already decent volume in the surrounding ecosystem.

The Forth DAO Treasury currently owns 3.8M idle FORTH tokens. Deploying some of these into PALM would simultaneously support the ecosystem by providing liquidity and also safely diversity the treasury over time.

Proposed Phase 1 Deployment

The DAO also holds $1.14M of AMPL/ETH liquidity on Uniswap V2, which includes ~552 ETH (~$595K). We could utilize 10% of the ETH in the AMPL/ETH pool to initialize the FORTH PALM vault in a 90:10 FORTH/ETH configuration.

That would initialize PALM with approximately:

  • $540K in FORTH and

  • $60K in ETH

totaling ~$600K to start.

Since PALM is a new system, an option to minimize risk is to start with $200K of assets, then reserve a follow on with the remaining $400K after a period of observation–perhaps after 1 quarter.

Phase 2

After 50:50 equilibrium is reached, the DAO can revisit market making objectives. Since PALM is non-custodial and exists onchain, the DAO retains ownership of the assets and is free to withdraw them at any time. At this point, we can revisit if/how to adjust the parameters, or if/how much liquidity should be added or removed.

For example, the DAO could maintain the vault as is, repurpose the accumulated ETH and deepen AMPL or SPOT liquidity, or deploy the ETH for yield completely independently.

Previous Related Discussions

https://forum.ampleforth.org/t/ampleforth-should-acquire-protocol-owned-liquidity-on-eth-mainnet

https://forum.ampleforth.org/t/geyser-refresh-for-january-23rd-2023

6 Likes
2

I support this proposal. On-chain liquidity is important for the health of the ampleforth ecosystem, and deploying a small portion of the assets to support Forth liquidity seems prudent.

2 Likes
3

Thanks for the proposal @Brandon !
I’d be more than happy to answer any comments from Ampleforth community and move this collaboration forward!

4

I’m supportive of the ForthDAO taking an active role in market-making its own token ecosystem :100:

Ensuring sufficient liquidity on neutral exchanges (eg Uniswap) is an essential part of giving everyone the same chances to enter and exist the ecosystem.

About Arrakis PALM

I do not have any experience or background knowledge of Arrakis and their PALM system. However, skimming through their audit reports (v2-palm/audit at main · ArrakisFinance/v2-palm · GitHub, v2-palm/audit at main · ArrakisFinance/v2-palm · GitHub) it seems that the manager role is quite powerful and needs to be trusted.

Screenshot 2023-03-11 at 17.27.09
Screenshot 2023-03-11 at 17.27.091057Ă—652 217 KB

(Screenshot from one of PALMs audit reports, see v2-palm/arrakis-v2-core-and-palm-statemind-audit-rev2.pdf at main · ArrakisFinance/v2-palm · GitHub at page 8)

Maybe @barbarossa_Arrakis can bring in some more clarity regarding this issue?
My questions are:

  • Can we have a fully trustless manager, perhaps by having the manager being a DAO managed contract?
  • How can we reasonably assume that rebalancing does not drain the position due to MEV, especially in the context of the rebalancing parameters being openly in the public mempool before execution?

Independent of the above-mentioned issues, I would advocate for such a “risk minimized” start.

About Increasing the DAOs holdings of ETH

Very much in favor of increasing the ETH holdings of the DAO.

The DAO has real costs in regard to the oracle providers, whose costs are denominated in ETH due to having to push their reports on Ethereum. From that perspective, holding a substantial amount of ETH is existential for AMPL to guarantee a lively oracle system.

4 Likes
5

Thanks for such a thoughtful feedback ser :pray:
Definitely very much appreciated!

To address your questions:

  1. The trustless property of PALM comes from the fact that it is not able to remove the liquidity. However, as you rightfully pointed out, there is a certain trust element at the moment, which is that Ampleforth would still have to trust Arrakis team for setting up the proper parameters and correctly pushing them on-chain from our backend. We intend to reduce our accessibility to intervention as much as possible, though the tradeoff is the opportunity cost if every time we have to require access from the DAO first when a change is required, especially for emergent situations. Overtime, we intend to make PALM more autonomous and minimize the trust layer on us.

    Currently, the mitigation to this risk in case we go rogue (I’m probably the worst PR lol), is to monitor the vault activities through the dashboard we provide dedicated to your vault or on-chain data if you prefer going even one step further, and revoke the manager role from PALM if you deem necessary.

  2. On a high level, the most basic layer of protection is the built-in inventory management, i.e. only a portion of the total liquidity is deployed at a time to prevent a liquidity drain over the entire vault. As to the liquidity deployed, in order to prevent an MEV attack, there is a slippage control in place, i.e. addLiquidity with a minDeposit0 and minDeposit1 that does not allow for the price to move beyond reasonable slippage.

2 Likes
6

Many thanks for the reply!

Correct me if I’m wrong, but the trust does not seem to stop after the initial setup. Arrakis needs to continuously push them onchain, leading to the DAO having to continuously trust Arrakis to not change parameters.

This seems to support my upper point.

Were there already situations in which Arrakis changed parameters due to emergency situations without consulting the appropriate stakeholders before?

This is good to know! Thanks again for the thoughtful answer! So the DAO can at any point revoke all permissions regarding Arrakis? Not sure how much security this actually creates during extreme situations, as the DAO utilizes a timelock for governance actions (which ofc is never favorable in the moment of an emergency :sweat_smile:)

I like it! :100:

Yeah MEV is a tricky thing. Do you know by any chance whether the minDeposit arguments are computed off- or onchain? (Note: This is important regarding MEV bots that simulate tx executions, ie if the arguments are computed onchain during the execution of the tx a frontrunner can mutate the state the computation is based on and therefore influence the result).

Last question: Does Arrakis utilize private mempools (eg flashbots)?

Conclusion

As always, it boils down to a risk/reward question. Personally, I’m a strong advocate of DAOs being sovereign on their blockchain and taking part in the social governance regarding “the land they are living on”, ie they should hold ETH.

The DAO also needs to keep an eye on the costs regarding the oracles, which are denominated in ETH. (Does anyone know how much the Ampleforth genesis team pays per month in ETH for their oracle? Or how much of the initially allocated ETH is left? These costs are currently not expenses paid by the DAO directly… yet)

On the other side, new systems such as Arrakis have high risks - from technical problems to trust requirements up to liquidity management issues.

Therefore, I’d like to start with a low stake and revisit this discussion after some time passed, evaluating whether the stated goals were met and whether Arrakis managed to show progress regarding trust minimization.

2 Likes
7

I like hanging out here. You guys ask good questions and we can learn a lot from it as well :smile:

So I’ll respond to this together with the feedback above.
The trust bestowed on us is adjusting parameters as agreed. Other than the manager role revoke, which can be a bit cumbersome, our current idea to completely abolish the trust layer is to implement an off-chain oracle check that monitors and permits any parameter change pushed from our backend. Though we don’t have a timeline when it’s gonna be implemented yet. And fortunately, so far we have not encountered any instance of emergency, and we try to minimize the possibility of its occurrence by implementing the said safeguards before hand.

Correct. And an (easier perhaps) alternative is just to withdraw the liquidity out of the vault.

It is off-chain.

Yes.

Happy to provide more info if needed :+1:

1 Like
8

Hey there,

Out of curiosity, how do we move forward with this proposal?