Yield aggregator problem #1 too large to gain yield.
My goal with iearn.finance is simple; optimize and micro manage lending provider yield so that I (you) don’t have to do it manually.
So right now iearn.finance supports $DAI, $USDT, $USDC, and $SUSD and it optimizes yield between Fulcrum, Aave, Compound, and dYdX.
The way in which it does this is simple, get the on-chain APR results for each lending provider, calculate the highest rate, and move the underlying funds there.
It does this every time someone interacts with the contract, or via our own external web3.js feed that monitors the underlying APR numbers.
When you deposit $DAI, you get yDAI, a ERC20 anytime redeemable token for the underlying asset and your share of the pool. So the value of yDAI:DAI is ever increasing as the interest increases.
While building the above William Bergamo | bugduino.eth (very cool dude) from idle.finance reached out to me and mentioned a very interesting problem statement;
What happens when your liquidity pool is so large, that when you move to take advantage from a lending providers yield, you wipe out the yield.
A practical example;
The above are the current rates for Aave, let’s look at $USDC
Liquidity $109,999
Borrowed $94,117
APR 16.18%
Now what happens when we increase liquidity by $50,000?
The new APR rate would be 2.31%, wiping out our whole point of moving over to maximize the 16.18%
So turns out, it’s not just enough to calculate APR, but instead we have to calculate New APR. And if New APR is worth the move, then we move the funds.
Originally we built and deployed the APR Oracle but now we had to build a new Oracle that also took pool size into consideration.
Compound previously was very easy to get the rates, simply;
Now we have to replicate what supplyRatePerBlock() did and break it down with our adjusted values, so we ended up with;
Fulcrum had a very easy call;
And turns out they were kind enough to already think of this problem;
dYdX change was similarly straight forward since we already manually calculated the utilization ratio;
Aave’s was a bit more complicated;
But they were kind enough to expose all the variables we needed, so still easy enough;
So now, we could release APR Oracle with move data
So turns out it isn’t as straight forward as to just collect yield, but we have to also calculate how our pool will effect the network.
The guys at idle.finance are taking it even one step further and seeing how best to split the pool to optimize this yield, so not just seeing how the pool effects the APR, but also calculating where and how to best put the maximum amount of funds to best gain the highest aggregate yield
Really amazing stuff.
Enjoy building!
