[PIP-038] Proposal to LP ULTRA from the Fee Receiver to boost ULTRA liquidity

DAO Proposals
1

Abstract

To assist with ULTRA liquidity we propose depositing the ULTRA accumulated in the Fee Receiver to the ULTRA<>USDC pool. The resulting LP tokens would then be sent back to the Fee Receiver.

Motivation

Low ULTRA liquidity makes it difficult to manage LRT vaults on Prisma. Currently the TVL for ULTRA pools on Curve stands at $220,000 between the two ULTRA pools. The DAO’s Fee Receiver has roughly $380,000 ULTRA and adding this ULTRA to the ULTRA<>USDC pool it will help users who need to buy ULTRA to manage their LRT vaults.

Specification

It is proposed that the ULTRA from the Fee Receiver is managed manually via the deployer, as undertaking this via a smart contract adds unnecessary complexity and would require an audit.

ULTRA would be sent to the deployer address and deposited single-sided into the ULTRA<>USDC pool with caution taken to avoid slippage. Once completed the LP tokens will be sent to the Fee Receiver and any further action with these tokens would be subject to governance.

The LP tokens will not be deposited into Prisma to earn rewards and as such will not be diluting other depositors.

Next steps

Feedback is important and this proposal suggests sending DAO funds to the deployer address. Please comment if you have concerns. If a consensus is reached, the proposal will go next on a Snapshot vote.

3 Likes
2

Instead of providing liquidity in the ULTRA<>USDC pool, I suggest using the ULTRA<>mkUSD pool, provided the protocol matches it with mkUSD. This approach offers several advantages:

  1. Using mkUSD from the protocol’s treasury for balanced deposits eliminates the need for single-sided ULTRA deposits, which can lead to slippage. In addition, if we were to add ULTRA single-sided we’d add liquidity for people who sold for USDC already and want to buy ULTRA to pay off loans (we’re basically selling ULTRA). We’d be making it more expensive for people who want to open an ULTRA position and then swap for USDC, which I don’t assume is the goal.

  2. mkUSD offers more liquidity options and opens up more routes for ULTRA to flow through, including connections to pools with crvUSD, Paypool, and USDC. If an ULTRA user wants any of those they need to route through mkUSD anyway.

  3. mkUSD/ULTRA has similar TVL as ULTRA/USDC.

4 Likes
3

Maybe when we put this to a snapshot vote, instead of YES/NO we can do:

  1. Add only ULTRA to ULTRA<>USDC
  2. Add ULTRA and MKUSD to ULTRA<>MKUSD in equal amounts
  3. Do nothing.
5 Likes
4

Sorry for the late input.

We should work towards moving all POL out of EOA and into a DAO owned contract. Yes, contracts need audits, but using an EOA isn’t a workaround for this. Other protocols have experiences losses through compromised EOA accounts. It relies on trust that the deployer keys are being properly secured.

While I’m sure those keys are being properly secured, it’s antithetical to being a DAO. It’s a single point of failure that relies on trust and ongoing good practices from individuals. Even with good practices, it’s susceptible to wrench attack or seizure.

The contract does not need to be purpose built for POL. It can be a very simple contract that is owned by the DAO and includes an execute function, and possibly a transferOwnership option if it’s ever a possibility that the DAO voting contract is updated.

This would be very minimal lines of code for a contract, and should be a very simple audit. And by doing so, the DAO would control all payloads instead of relying on trusting an EOA wallet.

1 Like