Yield aggregator problem(s) #2 (3, 4, and 5) too large to move.
The first version of yearn.finance was simple, extract APR from the downstream lenders. And if B > A then move to B.
Then we incurred problem #1 too large to gain yield.
The problem statement was simple. Even though B > A, we could not move the pool, because by moving the pool B < A. B decreases because of the pool volume and A increases because of the pool moving.
So we implemented new APR comparisons to calculate what the new A & B would be including the pools movement, where the pool, includes itself into the move.
At this point, we could no longer take advantage of small opportunistic spikes. Which would also mean, our APY would be equivalent to putting your assets in the highest liquid market, effectively making yearn break the reason it existed.
Problem #2 too large to take advantage
To combat this, we started moving small amounts of tokens from A to B, around 20,000 at a time, until the next reported value is slightly above our current position. This allowed us to balance out yield across platforms and keep our aggregate yield slightly above the highest liquid market.
Problem #3 front-running volatile markets
Now that the pool could manage smaller moves, we wanted to front-run the markets that have volatile spikes. The system only monitors on interaction, so it can’t constantly be aware of everything that is going on. So it might often miss a volatile spike in one of the less liquid markets that could have contributed further to APY. So next, we moved to aggregated yield over time as a measurement instead of current APR. We track the growth of a specific small asset we have at a given location, and make movement choices based on the downstream systems liquidity, risk (more in #5), and front-running volatility.
For this reason, you might notice we have some DAI in Aave for example, which perhaps at time of viewing, might be earning less APR than it could be at compound. However, in aggregate over time (and by front-running the volatile spikes) we can achieve higher overall APY.
Problem #4 too big to move
iearn has finally grown to where it is not a simple aggregator, but it is a large part of this market, at time of writing, iearn is the following # top provider to the downstream market;
- Compound DAI #5
- Aave DAI #1
- Compound USDC #3
- Aave USDC #2
- Aave USDT #1
- Aave TUSD #1
At this point, we have two new problems;
- Aave requires a minimum of 25% of their available market to remain liquid. We are more than 25%
- The pool is often bigger than the available liquidity. Where we might provide $1.1M, but the available liquidity is only $1M
The pool has literally become too big to move.
At this point, the pool can no longer make unilateral movements. So we have had to design and integrate a new system that manages the partial moves. At this point, full movements no longer occur, and instead batches are withdrawn and rebalanced.
Problem #5 Risk vs Reward
Lastly, while not implemented at time of writing, we are transcribing defiscore.io data on-chain, and only allowing for weighted movements and maximum caps, these caps are based on risk and available liquidity. The higher the risk, the higher the available liquidity requirement, and the balance is maintained. So as the liquidity decreases, funds will be rebalanced elsewhere.
Conclusion
It has been amazingly fun to face all these challenges, and each one I believe has created a more robust ecosystem. What started out as just a few very dumb (logic wise) smart contracts, have grown to an intelligent system that is not only aware of itself, but also manages its own impact and risk on the ecosystem.
Looking forward to many more problems to come.
