The BentoBox lending solution
Platforms like Compound and Aave allow users to deposit assets as collateral and borrow other assets against this. These protocols have attracted billions of dollars, but they suffer from some major limitations. Taking away these limitations could see much larger adoption. This proposal aims to do just that.
We solve these issues by having a platform with:
- Isolated lending pairs. Anyone can create a pair, it’s up to users which pairs they find safe enough. Risk is isolated to just that pair.
- Flexible oracles, both on-chain and off-chain.
- Liquid interest rates based on a specific target utilization, such as 75%.
- Contracts optimized for low gas.
- The supplied assets can be used for flash loans, providing extra revenue for suppliers.
Isolated lending pairs
The current solutions allow users to supply a variety of collateral assets and borrow another set of assets. If one of the assets were to drop in price faster than liquidators can react, every user and every asset is affected by this. So the risk to the platform is based on the risk level of the riskiest asset listed on the platform. This risk increases with every extra asset that is added, leading to a very limited choice in assets on most platforms.
By isolating lending pairs, anyone can create a new pair similar to how anyone can create a SushiSwap pair. Some lending markets will be very stable and safe, others not so much if they include highly volatile assets with low liquidity. Because these are isolated pools, risk is limited to individual pools and interest rates will reflect that risk. Higher risk pools will attract less suppliers, pushing up the interest rate.
Margin shorting any token
This will allow for the creation of thousand of lending pairs for any token, creating the ability to go margin short on a large variety of tokens. This is something that is in high demand, but currently not available for most tokens.
Let’s say there’s a shiny new token called SHINY. We want to short this because we think it’s overvalued because it’s so shiny and new. We (or someone) create an ETH-SHINY lending pool, with a collateral rate of 80%.
We supply $1000 worth of ETH and borrow $750 worth of SHINY. We sell the SHINY for ETH and supply the ETH back to the pool. Now we have:
Supply: $1750 ETH and Borrows: $750 SHINY
We borrow an extra $500 SHINY and sell it for ETH. We resupply the ETH and have:
Supply: $2250 ETH and Borrows: $1250 SHINY
We can repeat this process a few more times, or we could have use a simple flash loan to get this done in 1 transaction. Depending on the collateral rate we can leverage 2–4x or more depending on our risk profile.
Now we are not only able to short this brand new token (which currently is often not possible) but we can even leverage the short. This will lead to a lot of volume on the associated swap pool, which we would encourage to of course be SushiSwap.
Flexible oracles
When a pool is created an oracle can be selected. I will provide 2 basic oracles, but the system can be extended and anyone could write a connector to an oracle. The basic oracles provided are:
- SushiSwap (UniSwap V2) Time Weighted Average Price — every SushiSwap and UniSwap can be used to get a TWAP.
- Open Oracle Price Feeds — these are the feeds Compound uses.
Liquid interest rates
Ideally you’d prefer a high, but not too high supply to borrow ratio (e.g. around 75%). The current platforms try to achieve this by making the interest rate go up with increase utilization. The minimum and maximum rates are however fixed. So these platforms don’t optimize towards an ideal utilization. During very low or high demand the rates have to be adjusted manually to get the utilization rate corrected. When utilization hits 100%, withdrawals are no longer possible. This problem has occurred on several of the platforms.
Each pool (and in each direction) will optimize the interest rate to get to the ideal utilization. If the pool is underutilized, over time the interest rate will keep dropping until it reaches 0% or until enough supply has left/borrowers have arrived. As the utilization goes too high, the interest rate will start climbing until it’s back at the ideal rate. The parameters for this will be configurable for each pool.
Optimized for low gas use
Most of the current implementations use quite a lot of gas, making them useless to users with smaller portfolios during high gas prices. One reason for this is that the contracts aren’t optimized for gas. A more fundamental reason is that having multiple assets supplied/borrowed requires more computation that gets worse the number of assets you enable. More recently some platforms have integrated governance tokens. This adds even more gas usage to each interaction with the platform.
Areas of more research during development
These features aren’t guaranteed, but will be researched as part of the development.
Allow for the investment of the locked funds in reputable yield zero-loss yields creating protocols. This should probably be optional per pool, so there can be multiple versions of the same pool pair. Users can trade of risk against rewards.
It may be possible to create one or more vaults that hold the actual assets. So while the pools are still separate from a risk perspective, this allows for easier investment of locked funds to create extra yield, larger flash loans and most importantly it could make moving between pools very low gas so liquidity can easily flow to the best pools. There are some drawbacks too and more research is required.
Revenue generation
A set percentage (to be set and controlled by Sushi) of the lending LPs interest proceeds will be sent to the SushiMaker. These will be converted into SUSHI and served in the SushiBar to holders of xSUSHI.
Who am I?
- Starting coding at the age of 6, hence 36 years experience coding in about every language and on every platform from large databases, accounting software to HFT and 3D engines.
- Successfully built and exited multi-million dollar internet company.
- Founder, architect and main coder on full CEX focused on security and transparency.
Background
Before I got involved helping out with Sushi, I spent weeks working on this lending solution. With the appointment of 0xMaki, ctrl and most likely OmakaseBar I feel confident about the future of Sushi and would be interested to bring this in under the Sushi brand.
Proposal
I will commit to delivering well tested (but not yet audited) solidity contracts closely matching the specs above. Slight changes may occur due to technical feasibility, but will be clearly communicated when encountered.
The success fee for this project is 25k SUSHI at the beta release and an additional 75k at final delivery.
Any costs of freelancers I may use for things such as creating unit tests, etc and any other expenses I have will be mine. The core code will of course be written by me.
Delivery deadline for a beta release will be 3 weeks from the time the funds are approved. Final delivery will be within 6 weeks. Every day delayed after that will reduce success fee by 5%.
While I may create a UI for testing purposes, it isn’t included in this proposal. But I will work with the team and provide help/guidance where needed so a good UI can be ready for launch.
License
Code will be open source, but full copyright will be retained by BoringCrypto. A perpetual unrestricted license will be granted to Sushi but only for the use within the Sushi ecosystem.
