The goal of this proposal is to gather the community’s feedback on the following:
- A framework to evaluate assets that should have markets (Silos)
- Proposed token assets for phase 1
- 50 token assets to evaluate
- Set LTV/LT for each asset
- Next steps following community conversations
- Capping deposits in beta Silos
Evaluating token assets
REMINDER
Beta markets are limited to token assets that have liquidity pools paired with ETH on either Uniswap V3 or Balancer V2. In the near future, the community will be able to create markets for token assets that pair with assets other than ETH.
I suggest the following framework to evaluate token assets and their risk parameters:
Vulnerability to oracle manipulation
Later in this post I use an oracle manipulation simulator to illustrate the cost of attacks on Uniswap V3 oracles. Community can use the tool in the future when proposing markets.
Note that the cost of attacks is mainly a function of how liquidity is distributed across the price range in the pool whose oracle is feeding the asset price to the Silo. This means changes to liquidity distribution across the price curve can render the cost of an attack too low, rendering the Silo vulnerable to attacks. There is not a good way to react fast enough to such a change, unfortunately.
Pool liquidity
Liquidity is an extremely important factor to consider since it likely impacts Silos in two ways:
- An asset with deep liquidity on the market can be liquidated with little slippage. This means sizable collaterals can be sold to pay off an undercollateralized borrow position without the Silo incurring bad debt.
As a good benchmark, I suggest we simulate liquidating a collateral of the asset in question worth of 2,000 ETH and set high LTV and LT if the simulated liquidation doesn’t result in slippage exceeding the liquidator’s bonus (in our case the liquidator’s bonus is 100% minus LT%).
- Decentralization: How many LPs are in the pool? If a pool is controlled by a few token holders (excluding the project itself), token holders can remove liquidity and consequently leave the pool prone to oracle manipulation.
Smart contract risk
We should be careful about listing unverified tokens. Verified tokens on Etherscan should be considered. We can look at the token smart contract to evaluate the token risk. This is by no means enough to evaluate smart contracts risk.
Asset popularity
This can be measured by the strength of the community, trading volume, token use cases, etc.
Other aspects
Community can favor projects that are willing to collaborate with our community.
For each token asset, the community will decide on the following aspects:
- Price oracle
- Loan-To-Value (LTV)
- Liquidation Threshold (LT)
Proposing 50 markets
I propose we launch 10 markets in the first 4 weeks of beta (phase 1). In this phase, the core team and community work together to uncover vulnerabilities and undesired behaviors in both the smart contracts and the application i.e. user interface (UI). After the first 4 weeks, the community starts proposing new Silos at the rate of 5-10 markets every other week.
I’ve gathered a list of 50 token assets of which 10 can be considered. I’ve used Euler’s oracle manipulation simulator to test the strength of Uniswap V3 price oracles for a small set of token assets to illustrate risk. We will simulate the risk of voted assets before we decide to deploy them.
Please consult this spreadsheet with the following in mind:
- We will run a snapshot vote (gas-free) for 50 assets, or any number after the community addes/removes to/from the list.
- We will use quadratic voting where voters spread their voting power across any number of assets.
- Top 10 voted assets will be deployed through an on-chain vote. Please note that if a voted asset cannot be added for technical reasons, we will replace it with the asset that succeeded it in the vote, e.g. 11th voted asset replaces the ousted 10th - you get the point.
How to read the spreadsheet?
- Base Asset: Name of the asset candidate for a Silo.
- Asset Address: Token address as read on Etherscan.
- Price Provider: Project providing the oracle e.g. Uniswap.
- Pool Name: The name of the liquidity pool whose price oracle is used to feed the Silo with the asset price.
- Price Oracle: A link to the pool whose price oracle is used.
- Manipulation scenario: A scenario simulated using the oracle simulator where the asset’s 30-minute TWAP is pumped by 20%.
- Attack Cost: The cost an attacker would incur if tried to pump the asset’s TWAP by 20% in one block.
- Pool $TVL: Liquidity depth of the base asset at the time of preparing the spreadsheet.
- Loan-To-Value (LTV): A collateral factor that determines how much the user can borrow against the collateralized asset. For example, if we set 90% LTV for USDC, USDC depositors can borrow up to 90% of their USDC collateral.
- Liquidation Threshold (LT): LT is the point at which your collateral is signaled for liquidation. Liquidation must take place to maintain the solvency of our Silos.
PS: I highly recommend we vote for two Balancer-listed assets so we can test the resilience of Balancer V2 oracles.
Setting LTV/LT
By default, risky assets with shallow afloat on-chain liquidity should be assigned a maximum of 50% LTV. The community can assign lower than 50% LTV for assets that cannot be easily liquidated.
LTV/LT proposed in the spreadsheet are based on the following:
- I’ve consulted parameters that other lending protocols set and increased them since Silos are risk-isolated. We just need to make sure that assets are liquid on the market.
- For assets that are not whitelisted on known lending protocols, I’ve used the parameters of comparable assets.
Next steps
- Share your thoughts on the proposed evaluation framework and markets including collateral factors and price oracles.
- Reply to the proposal with token assets that you would like to add to the spreadsheet.
- Join Discord to discuss the proposal with community members.
Once we are done, we move to voting which is two-fold:
- Snapshot vote: The result of which determines the markets we will launch in phase 1.
- On-chain vote: The core team runs an on-chain vote (executable code that deploys voted Silos with their collateral factors and price oracles as voted by the community.)
Capping deposits
Deposit caps determine how much value each token asset can have in its Silo. For example, a $25,000 cap on USDC Silo means users can deposit up to 12,500 USDC and $12,500 worth of ETH in the Silo - effectively the Silo’s TVL is capped at $25,000.
Caps can be increased/decreased by the team’s multisig following a snapshot vote or through an on-chain vote. The team might reduce caps in response to an emergency.
I propose the following weekly caps:
