Approve the use of other AMM’s for nests liquidity.
This is the official PIP of @Jester concept. You can see the comments also that were written in the concept section of this PIP.
Currently we are using only Sushiswap for liquidity in minting our nests, This in itself is not an issue however coupled with the fact that we are the only one supplying and making a market for the liquidity for some of our synths to mint with is. For example, for nSTBL we currently make up all of the liquidity for RAI on Sushiswap, a majority of it coming from nDEFI-RAI.
This proposal aims to allow the galaxies to use any available AMM (Quickswap, Kyber, Curve, Uniswap) or aggregators (1inch) on Polygon to optimize the way the nests will acquire the necessary tokens, in an optimal way.
The first preference would go to start using the DEX aggregators 1inch, as we would be able to optimize our sources of liquidity and save on costs per mint by ensuring we have the best deals on Polygon for our underlying assets and in the case of RAI be able to capture more of it as it enters Polygon no matter what AMM it is, as it is a scarce token on this network. Also, this would benefit Polly in the long term because we wouldn’t be obligated to always create a market on Sushiswap for them.
The proposal will lead to the Smart Contract galaxy writing a different strategy of the nest to rely on dex aggregators or differents AMM on Polygon to acquire the underlying assets instead of solely rely on Sushiswap.
Agree, although would leave the selection of the DEX or aggregator up to the galaxy teams as we may find something like paraswap better to use
The proposal doesn’t limit options as its main thing is approving all other AMM’s instead of being limited to sushiswap, 1inch was just a direction to be given to the Smart Contract galaxy upon its approval. If you have a better one in mind to start with though I’m all ears. Whats paraswap and what are its advantages over 1inch?
Just curious, could smart contract figure out where is the best place to get liquidity rather than fixing it to one or another protocol?
Well the reason for going to 1inch in the proposal for me is because it takes from every source of liquidity on the network from several AMM’s, there is not enough RAI in any one place. Sushiswap has some of the most in one place thanks to POLLY.
On a basic level that is doable.
As in: Is DAI cheaper on Sushi, Uni or Quickswap?
But what 1inch is doing is: Buy 5% here 1% there, and buy DAI via USDC, etc…
That is to much to put into a smart contract. At least for one like ours where we have +10 assets in our nests. We would probably hit the gas limit pretty quickly.
I finally had a proper look at 1Inch.
They have an API that builds the buying path depending on our inputs and then we can send that data to their contract, which then buys the assets. (which makes sense, as their calculations are probably a bit to extensive for a smart contract).
So we cannot simply use 1Inch swaps from our Recipe contract.
There is probably still a way to integrate it into our protocol, but we will have to trust the 1Inch API (which might be have some extra fees depending on our volume), and it would require some larger changes on the contract side and also some changes to the front end side.
In the short term, we can very quickly implement something like:
Where is the best asset price: UNI, SUSHI, Quickswap, or Curve? → Then buy asset at the cheapest AMM. (The number of AMMs might be restricted by the gas limit).
In my opinion, if an asset does not have sustainable liquidity on any of those AMMs, then it might not be worth having it in the nest.
you could also just use the 1inch API to find the cheapest price among the options, and then use the cheapest option directly @Fresh_Pizza_of_Bel_A :) you don’t HAVE TO use 1inch’s smart contracts, just because you use their API lol… they definitely want you to, but once the API gives you routing data, you can just find the cheapest 1-hop swap and then just use it
Using their contract is not the issue. In fact I would prefer using their contracts, seeing the bytecode that the API returns.
If we use the API, we are externalizing a substantial chunk of the logic from the contract (determining which tokens to buy, how many and where/how to buy them). That logic would then be executed by our frontend and the 1inch API.
The only thing left for the recipe to do would be lending the tokens and depositing the assets in the nest. That is quite a bit we have to change.
Actually now that I think of it, the fact that we are determining the token amounts to buy on front end side (and not in the same block that we are buying them), means that by the time we are depositing the tokens in the nest, the nest composition will likely have changed and the transaction will fail.
Anyway for it adjust for new compositions?
I think we can…
But then we definitely have to create our own smart contract logic that can read the 1inch API reply and replace information before executing it.
That will definitely be time intensive and we might have to worry that we are hitting gas limits. We might also have to revisit the 1inch ToS, if they forbid this kind of action I would also rather not go that route.
That being said, it would be cool if we can pull it of. It would in general be a cool feature that all nests will benefit from.
In regard to the short term issues with RAI, we might be better off hoping that Uni incentivizes it or reducing the RAI portion of the Nest.
FYI, the API delivers the trading route in the form of a giant ass byte string like this one:
@Jester Based on what @Fresh_Pizza_of_Bel_A said, i would rephrase the proposal to be able to use any AMM or aggregators on Polygon. We shall let the liberty to the dev to find out the best implementation based on their research and faisability.
What do you think ?
I think thats fine, mainly I wanted us in the end to not have to be reliant on one source of liquidity so that we can have a more robust decentralized system for minting. I would like to have a clause where they exhaust the use of aggregators however 1inch or otherwise. He seem to think that it would be a good addition and if it takes time to implement thats fine, of course I dont want to have an entirely new vote incase its not possible lol.
I have edited the PIP. Thank you Jester
Instead of Just Sushiswap might be better language, I also dont want to exclude it haha.