So nice to read about so many possibilities. Iāve read and heard of many of them, but a forum post feels nice.
Iāll read this more than once, so far Iām very excited about everything. I think it will be important to give a timeline to whatever will eventually be in the roadmap, in order to create an ever growing interest and excitement about whatās coming next for Agave.
The way of 1Hive are infinite! Great job guys keep it up!
P.s. What is āOTTOā?
OTTO is based on pool together fair lottery, using Agave to produce the yield which is earned by the lottery winner.
Really Niiice, who is behind the development?
Just seeing this ik this project is legit
development of otto hasnāt started yet, but it will be worked on by 1hive members, which includes anyone who is interested.
Must we wait May for seeing the changes?
@befitsandpiper It is nice to see a consolidated view of Agave on a forum post. I hope either this post can be edited or a new post can be made up may be once month or so to provide a continuing update on the project.
I am really waiting for the AGAVE MVP launch as this will really put to test the theory of being able to bring larger liquidity to AGAVE/ 1HIVE and Honeyswap and then starting to build the lego blocks for the future of 1Hiveā¦ !
@Goldoni On the āOTTOā note, from what i know PoolTogether have already deployed on xDAI but the issue is that there is no active pools at the moment as there is no yield generating protocols to be used. Once AGAVE is launched i think 1Hive should seriously think of incentivising a few pools on the PoolTogether xDAI deployment instead of having to reinvent the wheel. I have read the paper on OTTO and it has some ācoolā additions to what PoolTogether currently do, but may be as a start we could use an existing project.
I made a post on this in the #proposals https://discord.com/channels/698287700834517064/770282095758802964/828781318568935445 but it did not receive any comment, so i assumed that the community is probably not very interested in this. Would be nice to kick this off again once AGAVE MVP is launched.
This is amazing we all all eager to see the BETA, v1, and at long last the amazing v2. 
Could KPI options work on layer2 and with AGAVE? The guys at UMA surely will like the idea.
can you elaborate on KPI options?
yes I think this is a good idea, I didnāt know they had already launched.
just to add a few I forgot about:
staking will allow you to vote with your staked agave
at some point upgrade to be able stake Agave LPās and vote with Agave LPās
As for the uma kpi, I will be pretty bummed if we donāt do this for the airdrop
Yeaā¦ i had not realised PoolTogether had deployed to xDAI until i was on one of their community calls on discord and someone pointed it out to me. There was at least a few in their community that were excited about the opportunity that this presents. I also discussed AGAVE with them briefly to say that yield generating protocols are on the way to xDAI which will make PoolTogther more interesting once AGAVE is launched.!!
I am going to start with this one because it has been something I have been trying to get Maker to consider. The idea a partial liquidation can return a borrower back into good standing is something to pay attention to. borrowers understand system needs to act, but they feel better if that system does everything possible NOT to liquidate them.
I had a crazy idea not posted to allow users to set their own liquidation fee to allow for an additional management tool on liquidation points.
Example default liquidation fee is 13% and say LR is 125% it might be nice for me to go well I will set this fee to 15% if i can have a LR of 123. etc. ofc there needs to be enough of a profit buffer. I also felt that people who maintained high CRs should get a SF fee rebate (DAI-R) that could then be exchanged to pay down loans or exchanged for DAIā¦ etc.
There are lots of ways to help users not get liquidated that donāt jeopardize the system. with respect to SC loans I like that idea but then wouldnāt we have to put a lien mechanism in the SC system? WOuld that be complex to implement?
There are security issues with this. not sure if we could do this in a securely automateable way.
i am looking at tjis more for L2 chains so that we donāt have like 5 different representations of same tokens on different side chainsā¦ We really need an integrated representation across all chains of the same tokenā¦ imo it is really messy to move DAI around from one chain to next.
Thanks for the update on plans for Agave!
connext solves the multiple representations issue for the same token. xpollinate already makes binance dai, binance usdc, etc completely redundant.
Yes, SourceCred would need to be a blockchain native system to allow SC loans. Weāre not there yet, so atm it wouldnāt be really possible.
I think we can add collateral types with certain pre-checks in Agave optimistically, then they can be disputed with celeste, so we could create a collateral blacklist.
I thought we can use hny for collateralā¦so it shouldnāt be ready at launch,right?
How long does it take to move V1 after launch?
unfortunately we wonāt be able to use HNY as collateral at launch because Chainlink is not willing to make an oracle for it right away. Hopefully the launch of honeyswap on polygon will help increase HNY volume and liquidity, then it may be easier to convince them.
so itās just a matter of time i think
matic - xdai bridge isnāt available yet,right?
I would like to add another idea here. For V1-V2 timeline:
It strikes me that it is a little weird that both ETH and USDC on aave are 80/85 max borrow/liquidation.
It seems at first glance like the usdc liquidation risk should beā¦ very low since it has no price volatility.
I believe this is likely bc liquidations in aave involve exchanging sets of tokens rather than just liquidating the collateralizing asset(unlike maker, where everything is liquidated for dai), and so the final return is dependent on the volatility of both assets, not just the collateralizing asset.
This makes me think that basing these ratios on the collateralizing asset is wrong, since it has no direct relationship to how risky a borrower is. Risk parameters should be related to correlations of assets lent and borrowed, higher correlations on each side would mean better collateralization ratios. Ratio trading should give you much better terms and higher leverage than straight levering volatile crypto. I propose we try to fix this issue in a future version of Agave.
One way of getting around actually calculating volatility and correlational data on chain or with oracles is just creating asset categories which we consider highly correlated, and assign some ābetaā parameter:
We could then beta weight the assets on the borrow and the lending side, and take the difference of the 2 sides for determining the riskiness of a borrower, and giving more aggressive/conservative lending terms based on that.
It is possible 1 risk parameter (called here beta) may not be enough to cover all our bases, but this seems like it would give a significant improvement in efficiency of collateralized lending, open up interesting future projects, and even help us get closer to a system that automatically assigns risk parameters.