Permissionless Listing / Isolated Markets

Ideas
1

I’ve had an idea in the back of my mind for the past month now, so let’s bring it to light!

Wouldn’t it be great to support the lending and borrowing of any sort of crypto asset? I have yet to see support for this in DeFi.

The main challenge to this idea is that every new market on Compound presents risks to the whole protocol. What if one token added as a market experiences a rug pull, price manipulation, or some other similar situation? Liquidations and losses can occur across all of the markets on Compound.

So how can we mitigate or contain these risks while simultaneously offering permissionless listings? Isolated markets!

Right now when you deposit an asset as collateral on Compound (granted > 0% collateral factor), you can borrow any other asset supported by Compound.

With isolated markets, we can use pairs, where the collateralization of one asset allows for the borrowing of ONLY the other asset for the pair.

Let’s consider an example: isolated GRT/USDC market. Are you a holder of USDC and you believe GRT is a safe asset? Lend out your USDC in this pool. What if all suppliers borrowing USDC against GRT get liquidated? The pool would be composed of mostly GRT. How comfortable are you as a USDC lender? If you’re not comfortable with this scenario, then simply don’t participate in this market. If you are comfortable with this, then you have an opportunity to make interest on your USDC at the rate of this specific isolated market.

The risk of permissionless listing is then contained to each and every isolated market.

The benefit of permissionless listing for, say, stablecoin lenders is that they have MANY more opportunities to make interest on their stablecoins. Theoretically, the more risky the non-stablecoin asset is, the higher the APR will be for lending stablecoins. The stablecoin lenders more skilled in risk assessment and management will then have much more opportunity to make higher returns.

There are most likely still risks to the overall protocol involved with this idea, as well as various challenges. Let’s discuss them here!

Going forward in this thread, let’s refer to the current Compound markets as cross markets and the new idea as isolated markets.

4 Likes
2

yes yes yes and yes. How can I help? Love the idea!

3

Great idea… I had the same idea a while back:

And it’s been live for a while:
https://app.sushi.com/bento/kashi/lend/0x795feb1c35dc07991bfd23ab74378885ec86c233

Happy to talk about licensing the code to Compound.

1 Like
4

Interesting, maybe compound could be a Kashi strategy? if I am saying that right?

5

Thanks for sharing this idea on the dev call today. I support the aspiration to offer permissionless listings for isolated markets. That said, I think the reputational risk to the protocol can’t be overstated. Kashi has been running for a while now, on multiple chains, but it still hosts a small, selective set of lend/borrow markets with Chainlink oracles.

We know from the experience of other protocols that permissionless listing on a protocol with decent network effects attracts projects seeking to take advantage of new user naivety. For example, if you quickly peruse recent activity in the Uniswap Discord, you’ll find a deluge of new Uniswap users clamoring for help after trading or providing liquidity to long-tail assets – dog tokens, “safe” this-or-that tokens, tokens with transfer taxes – with enormous slippage and finding themselves unable to trade out and/or frustrated that they have to pay for failed transactions. These are users completely new to DeFi buying a meme token on Uniswap, then failing to be able to sell it despite paying a huge gas fee, and their impression at the end of the day is that they have been robbed and that Uniswap is the thief.

It would be painful to see people having similar first-time experiences with the Compound protocol.

Assuming crypto market caps take off again within the next several years, permissionless listing for isolated lending/borrowing markets will bring the next generation of meme tokens, projects with tax-on-transfer and/or Ponzi-like tokenomics. Those projects will permissionlessly list lending markets for their tokens and announce them as “partnerships” with Compound to lend credibility, bringing novice users to the protocol. With lower liquidity and easier-to-attack-oracles, these markets are likely to be very high-risk for novice users, leaving most of them with fewer assets and a sour taste in their mouth about Compound and DeFi in general.

Long term, I love the idea of permissionless listing. How can Compound do it in a way that disincentivizes opportunistic money-grab projects and proactively educates users about the higher market and oracle risks of lending/borrowing long-tail assets? Or do folks feel like such efforts would amount to censorship?

6 Likes
6

Great feedback, I really appreciate it!

I am very supportive of the free market. One of the things that I love most about DeFi is how there are no governments or regulators here to “protect” users or to fix markets.

Like here in Canada and the US, regulators “protect” investors by severely limiting access to investment opportunities because of risk. In doing so, these regulators severely limit the average person’s ability to learn how to significantly grow their wealth. In particular, accredited investors get access to MANY more and better deals, but one has to first make $1M to get that accredited status.

Protecting users from anything which could hurt them generally hurts them more because they’re denied the opportunity to learn and grow.

But yes, Compound does have a reputation to maintain and we don’t want users to get scammed or lose a lot of money. It also goes without saying that protocol security is of utmost importance.

Therefore, it’s our responsibility to educate users on the risks and to develop a UI/UX which aids the user in this regard as much as possible.

1 Like
7

Infrastructure: Price Oracle

A really basic overview of the price oracle to be used in these isolated markets are as follows.

  1. If the price exists in Compound’s Chainlink powered UniswapAnchoredView, use that price. Otherwise,
  2. Use a TWAP of the price returned from a DEX aggregator.

We first try to use the price reported by Compound’s current price oracle as this feed contains the most accurate, secure, and reliable prices.

Since Chainlink only supports a limited number of assets and we want to support any asset, we must get the price from a different source if our current price feed doesn’t support the asset in question.

The best on-chain source for prices are DEXs, but which DEX is best? Well, we can’t rely on any single DEX for prices because liquidity is fragmented across DeFi. The exchange with the most liquidity usually has the most reliable price. Hence the need to use a DEX aggregator.

1inch as Price Oracle

1inch is arguably the best 100% on-chain DEX aggregator, so we will use their contract/code.

The source code is available here: https://github.com/1inch/1inchProtocol.

Note: 1inchProtocol was recently deprecated, so we’ll have to coordinate with the 1inch team to maintain it. We could also fork it and maintain it ourselves.

Here’s an example of using the contract to get the price of GRT:

image
image576×586 31.9 KB

Reported is a price of 0.589060 USDC/GRT.

Is it as easy as this to get the price of any asset? Sadly, no. It’s possible to manipulate this price through one of the supported DEXs which has low liquidity.

Solutions to this problem?

  • Okay solution: Alter the amount. Maybe 1% of the max supply of the token? 10%? The amount contained in the isolated market? Some combination of these approaches?
  • Better solution: fork the 1inch contracts to calculate a volume/liquidity weighted price. Impose minimum liquidity constraints to protect us from market manipulation. Remove the swap functionality of these contracts as we don’t need them - reducing overhead.

Conclusion

That’s the end of my basic overview of the proposed price oracle for isolated market supporting permissionless listing.

Please let me know your thoughts!

1 Like
8

Update

I’ve decided to build a new price oracle as there are no existing fully on-chain manipulation resistant reliable price oracles which aggregate multiple DEXs for the purpose of lending and borrowing.

Having a solid fully on-chain price oracle will be the hardest aspect of this proposal. It must be fully on-chain to support permissionless listing. The downside is that a lot of liquidity of various tokens are on CEXs, which makes on-chain prices easier to manipulate.

To combat price manipulation, I’m using the following strategies:

  • Aggregating DEXs
  • Weighting the price from each DEX by the total liquidity of the base token (ETH or stablecoin) and possibly other factors
  • Using sliding window oracles
  • Using a large observation period (8 hours or more)
  • Using a somewhat small period granularity (15 minutes)
  • Choosing the best algorithm(s) to calculate [stable] price and liquidity (for weighting)

One of the easiest ways to manipulate an aggregated DEX price oracle is to create a new liquidity pool on one of the smaller DEXs (assuming one doesn’t exist) and setting the token price really high (or low). Arbitrage bots and regular traders would probably be slow to realize this discrepancy making it less costly to pull off such an attack.

To combat such an attack:

  • Use large observation windows
  • Use algorithms that give more weighting to DEXs/pools which have had large amounts of liquidity earlier on

The oracle solution I’m building is/will be very abstract and flexible so as to support many different ways to calculate prices.

More discussion of algorithms and parameters will follow.

Cheers to DeFi Summer 2.0!

2 Likes
9

so what you want to do is create an entire protocol which would involve people actively picking and optimizing dex data sources, weighting, and methodology, continuously and individually for each coin?

i think take a step back and look at what ur proposing.

at that point just start a new oracle protocol.

the focus should be on making it easier to list tokens, not creating an imaginary obstacle course to play mental gymnastics with. adding 300 layers of voting doesn’t make the token listing feel any more permissionless.

10

Starting a new oracle protocol isn’t out of question (but this is off topic).

The process to get new tokens listed is complex because currently every new asset added adds risk to the entire protocol.

With isolated markets, the risks are a lot more contained. They have to be for permissionless listing so that anyone can list a new market without having to go through the governance process; without putting the entire Compound protocol at risk.

300 layers of voting? No, no, no. Anyone will be able to create a new market at their own discretion. This is why we need a really strong price oracle that is resistant to manipulation.

We won’t need to optimize the parameters for each different coin. We just need one optimal set of parameters for the purpose of lending and borrowing at Compound. Then add DEX configurations here and there (or not). The more DEXs we aggregate, the more reliable and accurate the prices are.

11

Oracle Update

I’ve written the majority of the new oracle infrastructure code. Below are some results.

Token = ETH
Base = USDC

UniswapV2 Price = 1785242344 , Token Liquidity = 66009898700084902688646 , Base Liquidity = 117843666286804
UniswapV3 Price = 1785275963 , Token Liquidity = 84902713181993030425960 , Base Liquidity = 46104943013566
Sushiswap Price = 1785850053 , Token Liquidity = 104407714235399694110022 , Base Liquidity = 186456522071834
Aggregate Price = 1785570139 , Token Liquidity = 255320326117477627224628 , Base Liquidity = 350405131372204

The aggregated price is weighted by the liquidity of the base token as the base token will usually be the strongest asset and hardest to manipulate.

An aggregated oracle may seem trivial when used for large-cap tokens. but it’ll be very beneficial for small-cap tokens as they are less costly to manipulate. For example, on UniswapV2, $100k can cause ETH price to move by ~0.38% whereas for BIRD it’s ~12.9%. We can’t assume arbitrage bots/people are actively trading all tokens, so it’s possible for an attacker to manipulate the price on one DEX long enough to liquidate users and make a profit.

Let’s consider the above results in terms of relative cost for manipulation.UniswapV2 has 117843666286804 in base (USDC) liquidity (117,843,666.28 USDC), whereas the aggregate totals 350405131372204 (350,405,131.37 USDC), making the aggregate price about 3x more costly to manipulate. The cost to manipulate the aggregate price goes up with the more liquidity pools (DEXs) we aggregate.

An aggregated oracle is essential for permissionless listing of lending/borrowing markets. The oracle must be very resistant to price manipulation to protect users’ funds which this new oracle system is designed to be.

More updates to follow as I get closer to completing the aggregated oracle.

Side note: Compound’s price anchor to UniswapV2 could be upgraded (in time) to use an aggregate, further strengthening the existing protocol.

4 Likes
12

cheering you on here. Keep. It. Up.

1 Like
13

So Kashi on Sushi has “strategies” but out own @jared worked on this bomb IRM and cDAI delegate contract that swept into the DSR, lets not toss this, rather we shall cherish the good times we have had and look into the future that we shall all seize, hand in hand.

14

@TylerEther,
Is it possible to use data from 3 different protocols (uniswap, sushi, 1inch) for “t” time. Then, rank the protocols from most changed in price to least change in price. Give the protocol with the least change in price 60% weight, while the other two get 30% and 10% respectively. This would make it very difficult to manipulate price since it would have to be done on all 3 markets.

On tokens with very small liquidity, you could add the previous oracle price into the mix of the weighting system. If you gave it 50% all would be needed would be to figure out the above weighting 60/30/10 and then average that price to the previous oracle price.

Just a couple of ideas… I think we should also attack this from a gas perspective as well, to minimize any unwanted gas fees.

15

I’m not sure how weighting it this way would play out as crypto assets are very volatile.

I took a break from working on this to work on other Compound proposals… seeing as this idea has been getting more attention and support as well as being near completion of the other proposals, I’ll put more focus on this idea again. :slight_smile:

16

Using 3 different protocols/markets to help with the risks involved with volatility/manipulation is a good way to combat the risk, especially as you mentioned:

However, if you could place emphasis – more weighting – on the protocol that has the least price change would make a malicious actor have to manipulate all 3 markets.

Example:

During the DAI Liquidation Event… If Compound was getting price data from 3 sources. And adjusted weighting system, where:

Price = (Latest Price * 0.25) + (((P0 * 0.6) + (P1 * 0.3) + (P2 * 0.1)) * 0.75)

The latest price of DAI = $1.0005.

Coinbase: DAI = $1.30
Uniswap: DAI = $1.005
1inch : DAI = $1.05

Price = ($1.005 * 0.25) + ((($1.005 * 0.6) + ($1.05 * 0.3) + ($1.30 * 0.1) * 0.75)

P = $0.25125 + ($0.603 + $0.315 + $0.13) * 0.75
P = $0.25125 + ($1.048) * 0.75
P = $0.25125 + $0.786
P = $1.03725

Doing the weighting like this would make it to where a malicious actor would have to move all 3 markets. You could even drop the algorithms (less gas) you were planning on using to weight DEXs by liquidity. Even if the bad actor was able to move the largest AMM pool’s price significantly, it would have less than a 10% weight factor.

Hope I explained it right, just want to simplify the oracle while maintaining the lowest risk possible and maybe even saving a lil gas.

17

Interesting idea, would be great for pegged/stable coins which are expected to not change much.

As for other tokens whose prices fluctuate a lot, I’m not sure if this would work well.

Here’s an attack scenario for this idea. We aggregate Uniswap V2, V3, and Sushiswap. There’s some small-cap token, $XYZ, which is only listed on Uniswap V2. An attacker creates a pool on Uniswap V3 with only $1 worth of assets and initializes it at a very low price. Arbitrageurs won’t trade in this pool as gas costs are higher than the value extracted, keeping the low initial price. An aggregated oracle would then give the highest weighting to this data source - as the price doesn’t move - resulting in a price much lower than the market price. The attacker is then able to liquidate loans where $XYZ is the collateral.

If this attack scenario were to use the base token (ETH) liquidity strategy, the low amount of tokens used to create the pool would have almost zero effect on the aggregated price (assuming Uniswap V2 has much more liquidity).

Keep the ideas coming! Every challenge to ideas proposed here will make the final product more resilient. :slight_smile:

18

Here’s an overview of what I’ve designed so far.

image
image664×809 10.7 KB

We have 3 data sources: Uniswap V2, Uniswap V3, and Sushiswap. We create 3 different sliding window oracles - one for each data source - and they all use time-weighted average algorithms to calculate price and liquidity.

Then we have our aggregated oracle which takes the market data (price and liquidity) from the 3 underlying oracles to compute the final price - weighing by the liquidity of the base token (ETH).

Here’s a scenario - getting the price of XYZ, denominated by ETH (XYZ/ETH pools).

Uniswap V2: price(XYZ) = 1 ETH, liquidity(ETH) = 100
Uniswap V3: price(XYZ) = 0.01 ETH, liquidity(ETH) = 0.0001 ETH
Sushiswap: price(XYZ) = 0.95 ETH, liquidity(ETH) = 8

totalBaseLiquidity = 108.0001
aggregatedPrice(XYZ) = 1*(100/108.0001) + 0.01*(0.0001/108.0001) + 0.95*(8/108.0001) = 0.996295383

Without the innaccurate price from Uniswap V3:

aggregatedPrice(XYZ) = 1*(100/108) + 0.95*(8/108) = 0.996296296

The presence of the attacker’s Uniswap V3 pool had an impact of 0.000000913 ETH on the final price. :slight_smile:

I argue that if gas and protocol fees were 0, arbitrageurs would correct the price discrepancy between Uniswap V2 and Sushiswap to around the price reported by the aggregated oracle (all other things held constant) as the price impact of trades is determined by the liquidity of the pool. I’m too lazy to mathematically prove this point.

Going back to the design of this system, the underlying oracles have been designed to be immutable so that they can be used by other protocols without the concern of anything changing. The more other DeFi protocols use these immutable oracles, the less gas consumed by the ecosystem as a whole, benefiting everyone, and lessening the oracle maintainer responsibilities of individual protocols.

I’ll publish the aggregated oracle system on Github tomorrow. :slight_smile:

1 Like
19

Oh, I didn’t clarify. The more weighting would go to the protocol/pool that had the least price change from the previous oracle price, not the actual protocol’s change in price.

Previous oracle price in the above example was $1.0005 which gave the Uniswap price of $1.005 more weight since it represents the least change. This should work on any asset, really. If the asset is highly volatile across all pools then it would still be weighted 25% from the previous oracle price.

20

I’m a bit confused because the oracle’s price reflects the protocol’s price (with time delay).

My previous argument still holds. An attacker can create a pool with an invalid price and liquidity so small that users won’t swap using it, keeping the same invalid price that has the heaviest weighting as the price doesn’t change.