Proposal to add CRV

Proposal to add CRV

Proposal to add CRV as a capped collateral to Interest Protocol.


The CRV token is the governance token to the Curve protocol.

The proposed parameters and cap are purposely very conservative. After the initial listing, a subsequent proposal could increase the cap.


Token Address: 0xd533a949740bb3306d119cc777fa900ba034cd52
LTV: 70%
Liquidation incentive: 10%
Cap: 6m (~$5m)
Oracle Address: [To be deployed]
Primary oracle: Chainlink CRV/USD
Secondary oracle: Uniswap v3 ETH/CRV
Price deviation: 20%


MCAP: $315m
Uniswap v3 liquidity: $4m
Coingecko 7-day avg 24hr volume: $41m
Notable exchanges: Binance, Coinbase, Okex, FTX

Technical risks

  1. Type of contract: governance token
  2. Underlying asset: governance token
  3. Time: +2 years
  4. Value: control of the CRV protocol
  5. Privileges:
    • The admin can change the name & symbol of the token.
    • The minter can mint more CRV up to the available supply. The miner is controller through the gauge controller.
  6. Upgradability: None

Volatility Data

The below shows the volatility of CRV relative to ETH

1 Like

First I want to point out that the Uniswap V3 liquidity is very small for CRV. CRV is a special case I suppose, but it would be more appropriate to report the liquidity in the CRV pool, ~50M - much better. At the end of the day volume on Exchanges does matter, but deep on-chain liquidity in collateral tokens is essential to keeping IP protected from accruing bad debts and impairing the redemption of USDi for USDC.

0xCLR makes a good point in the BAL thread, linked below. Because BAL has adopted the vetoken model, there is little demand to hold BAL token and not lock it. It may make sense for users to supply BAL to Aave to earn the carry from others who want to short BAL, but Interest Protocol does not currently have that capability. So I agreed with 0xCLR that although I did not think adopting BAL as collateral would introduce a risk to the protocol (indeed, the BAL pools are deep because so many BAL users lock their tokens), it still would probably not be very useful to IP users. I believe the same basic logic applies to the adoption of CRV.

0xCLR also states that, because IP’s differentiator is it’s ability to delegate collateral tokens, some of the benefits of IP are lost on users of BAL, and the same applies to users of CRV. It would appear that the way to circumvent this inconvenience for users would be to simply, make proposals to onboard any number of the liquid vote-locking token wrappers for BAL and CRV; AURA and CVX/yCRV… even aCRV or aBAL I am sure there are many others, and furthermore I wonder how IPs delegate function would interact with the various vote-locking and bribing systems? If these systems could still be used by USDi borrowers who delegate their collateral token voting power to themselves, it could be a good value proposition for IP.


Good call out on the Uniswap ETH/CRV pool. While the liquidity isn’t ideal (at $2.21m), I think it is sufficient for the purposes of an anchor oracle. Recall the price that is utilized by the protocol is the primary oracle’s price. The secondary oracle is only used to verify the primary’s price is within the deviation range defined for the market. If someone were to manipulate the secondary oracle’s data by trading, it would be costly and ineffective at hurting Interest Protocol. So long the net on-chain liquidity for the market, CRV, is sufficient and actively traded, it should be sufficient for the protocol.

Oracles are upgradeable. So if, down the line, IPT holders want to change/improve an oracle, they can do so through a governance proposal.

As to the utility of BAL & CRV as collateral assets on the protocol, I think there is a good opportunity for both tokens to be added to the protocol. The current Aave v2 CRV supply is at $145m, and BAL has generally been an underserved market. Regarding your question on ve tokens, the protocol could likely integrate them with some work. Part of IP’s beauty and efficiency is its design and flexibility.