1inch 🛠 Powering dApps with 1inch

[Music] this presentation is powering daps with one inch and my name is Tanner and I've been a contributor to 1 inch for about two and a half years now uh working on governance teams back end and now currently developer relations so uh today we're going to talk about the Three 1-in swap protocols that we have and then we're going to talk about integrating these projects in uh these protocols into your project so that's going to be talking about our apis our documentation some example repos as well as integration tips to make it easier for you to do so uh brief summary about one inch we actually started at eth Global um at eth New York in 2019 um we didn't Place very well in the actual rankings but we still grew to become a pretty successful protocol with now almost 3 million users over $300 billion do of total volume processed through our contracts and gave people access to over $55 billion of total available liquidity as well as having 70% of the aggregation market share so first we're going to talk about what it means to swap with 1 in we'll talk about our original aggregation protocol we will then talk about the limit order protocol and then our latest which is 1-in Fusion so today we are currently live on 12 different chains with our aggregator and our limit order protocol and then with our latest 1-in Fusion we're live on nine of those 12 chains and we will continue to expand to more chains as there's more liquidity and more need for swapping so first off the 1-in aggregator this is what people who know who 1 in probably knows this part um it sources swap liquidity from all popular protocols it combines these protocols to optimize the swap output for the user and then then it executes all the swaps in a single transaction um so if we just take a simple example someone who is just trying to do a swap from usdc to die um today on ethereum they're probably going to take their usdc and just go through Unis swap um this is fine Unis swap is a very major player in the space um it's tried and true and people don't have to worry too much about what's going to happen on the other side they they know they can trust it but the UI that 1in offers um is very similar to Unis swap it has the input token the output token and you just click one button and the transaction goes through and you get your output tokens so quite similar so let's just say the same user decides okay I'm going to go through and uh send my tokens to the 1-in router now uh then the 1-in uh platform will do some complex calculations and probably end up just sending the user through Unis swap again um but they're not going to do that in all cases especially in bigger swaps specifically um it might split it out into multiple different dexes in the single transaction so it might put some of that uh transaction through dodo it might convert some of the usdc into tether using curve and then finally take that tether put it through Sushi Swap and come out to die um and it'll do whatever it needs to to get the best output for the user uh some of you might be thinking well yeah that's also going to increase gas cost by quite a bit and that's true but we factor that into our decision- making process as well so if it takes more gas but it gives you more tokens to offset that then that's still the path we're going to take so in the case where uh it does just go through Unis swap um and which is um happen a lot of the time actually through our aggregator you might be wondering well if it's just going to go through Unis swap in the end shouldn't I just be going directly to the Unis swap Router won't that actually save gas and let's just compare those head to-head so if you do a swap through Unis swap with this specific token pair it'll be about 205,000 gas and if you do the exact same swap through one inch which then eventually goes through Unis swap uh you'll actually only spend about 175,000 gas so even in cases where it's an extremely simple swap that just goes through Unis swap it will actually be cheaper through us because we've optimized the logic that goes uh skips the router and goes directly to their pools um next let's talk about one-in limit order so this supports makers and takers like a traditional order book takers pay the gas fees for the transaction which means you know gasless swapping from the user perspective and this removes me opportunities and that's because uh you basically say this is how many tokens I want to get for my Swap and there's really no room to do anything there because if it's less tokens than what you agreed upon when you place the order the transaction is not going to go through so again UI looks very similar to a basic swap there's just two new UI elements one is the rate at which you actually want to swap those tokens for um you can just click set to Market and make it essentially a market order or you can go a little bit higher if you think there's an opportunity to make more money later by setting it at a higher price and then there's also going to be the expiration time so how long you actually want this order to last inside of our system um we default it to some small value you can set it to forever if you want but sometimes people don't want trades executing 6 months later that they totally forgot they placed so it's totally up to you on that um kind of a diagram to show what's going on behind the scenes when you place a limit order in our system um you the maker aka the user um would say Okay I want to sell 50 usdc for 50.1 die uh you will sign that transaction essentially giving our router the permission to swap this usdc for you and then that will go off into the 1-in API um the 1-in API will then feed that order to anybody who wants to listen to it so they have the 50 usdc for the 50.1 die and anybody who wants to listen for this and decide you know is this an order I'm interested in they can they can kind of go through that on their own time and eventually someone will say yes that is something that interests me and they will execute it from their side so they'll pay the gas they'll execute the transaction and you'll get the 50.1 die okay on to 1-in Fusion so the user submits a swap request with a signature just like limit order and this will kick off a Dutch auction that is created for the swap that the user is trying to do and then the resolvers will asynchronously compete to fill this order during the Dutch auction um and again users are protected from me by Design here because at each step along the way of this Dutch auction there is a specific price at which the token needs to be swapped for so there's no room for anything to be taken from the users side uh during during these swaps so uh there were a lot of terms that were listed in the last slide so let's kind of break them down um what is a fusion Dutch auction or more generically what is a Dutch auction and you know in a traditional auction you start at a very low price and over time it goes higher and higher until eventually there's only one bidder left and that's the price that the uh item is sold at in a Dutch auction the price actually start starts at something quite high and it works its way down until some bidder decides okay this is a good enough price for me to actually purchase so a fusion Dutch auction does the same thing but with token prices um and then also what is a resolver these are entities in the uh Fusion system that are all watching these Dutch auctions while they occur and they're the ones that are actually swapping all or part of the order as a Dutch auction slowly reduces the token price from their perspective so here's a really simple diagram of what would happen in a Dutch auction the y- axis is rate and the xaxis is time uh the top left point you there uh you see there is going to be the highest price that the token will be sold for from the user perspective so it'll be something slightly higher than market rate and across the whole Fusion auction it will slowly go lower until some minimum value ideally when uh resolvers are happy to fill it and find their profits in the trade so again the UI is quite simple you have the input and output tokens you have the transaction cost which is zero which is really cool it means you don't need any of the uh Native gas token for whatever chain you're actually doing the swap on um which is going to be really good for mainstream adoption and ease of use for uh for us uh new user specifically and then we have the preset which is going to be like how long this Dutch auction will actually last I think it still defaults to 3 minutes and then it will give you the estimated output as well as the minimum output of the Dutch auction so here's the UI just kind of showing this thing actually happening it's going to show you you know today in your history there's usdc being swapped for die it's going to show you how long the Dutch auction actually has left on it in this case it was 2 minutes and 49 seconds and it's going to give you its estimate for what the actual return will be in this case it's going to be almost exactly as many tokens as you put in because it's going from stable to stable so again we're let's look at what the what's going on with the diagram so we have the user they say I would like to swap 50 usdc for die the fusion system will estimate something around 50 die coming back to them uh the user will sign that transaction and then it will go off into the 1-in API the 1-inch API will then start a Dutch auction um it'll say that hey this user is trying to sell 50 usdc we expect there to be something around 50 die coming back and this auction will last three minutes and all of the resolvers in the system will now be monitoring this Dutch auction and they'll be choosing to either fill it or not fill it as it progresses so during most of the blocks after this auction starts uh most people are going to be passing but eventually the price will get to some point uh in which resolvers now are interested in filling this order either part or all of it and if they both try to fill the entire order uh whoever is earlier in the transaction will get the priority and the other person's transaction will fail but that's not going to happen in all cases because partial fills are allowed so if the first resolver fills uh only a portion of the of the order and the second resolver is also filling part of the order there are many cases where where they will both actually have their transaction succeed so resolvers are competing with each other and also working together to fill the order as efficiently and fast as possible so here is a graph of an actual swap that happened on our system for a massive amount of 3,700 ether and uh it's kind of a noisy graph but the dotted line near the top that's perfectly flat that's the market rate at the time this auction was started and you'll see that the curved line with the dots um uh across it is the actual rate at which the tokens were being sold for so there are uh I think about 17 uh different points along this graph where resolvers jumped in and filled part of the auction uh the first one happened around the 24 second Mark and the last one happened at the 4 minute 48 second Mark so by the 5 minute Mark all 3,700 ether had been swapped for usdt and all slight above market rate um now granted it was only like you know $1 above market rate but that's still pretty cool that's a massive trade that happened all above market rate which just wouldn't happen if you probably went through a uh normal pool um so you might be asking yourself you know where do these resolvers get their liquidity like these entities how are they actually fulfilling these swaps and uh that is kind of the the beauty of the system is it doesn't really matter um all that matters is that the swaps are fulfilled at the specified rate so resolvers might be getting their liquidity from centralized exchanges it might be through personal funds it might just be using you know a DEX like 1 inch behind the scenes to actually do the swap or they might be doing something more sophisticated like cross train swapping um okay so we went over the aggregator limit order and fusion now kind of at a high level um now let's ask the question how do we actually use these in my project and that's where Dev portal comes in so Dev portal is the official hub for integrating 1 in into all of your projects um it provides things like the API keys to access our apis uh documentation for the swap apis as well as many more apis which we'll talk about briefly toward the end um it'll also give you examples as to how to do this um and yeah so the link is portal. onein dodev that's where you'll actually go to see all this thing uh all these things and don't worry about writing any links down uh throughout this presentation at the very end there will be a link to all everything we talk about today so don't worry about catching anything uh mid presentation so if you go go to Dev uh the dev portal website you're going to see a homepage you log in with Google or GitHub um from there you're going to actually just choose what application uh name you want to give your project um it can be anything really it's just like an alias in this case I used test and then after that you'll hit the your dashboard which will have your uh API access key it'll have your requests as well as the rate of the requests that are going through and if you go to the top there'll be a docs page where you can actually see all of the information about the various apis so we click on docs we see on the left now there's a bunch of different apis on the left side to keep things simple we'll just jump in and we'll click on this swap API um that'll give us a drop down with a couple other links and we will go straight to the Swagger documentation so we'll go down click on Swagger and we'll see all the different endpoints that this uh API has to offer so we'll click on the top one find the best quote to swap with onein router and that will bring us to an interactive documentation page based off of uh our Swagger files and so the middle is going to be what chain you want to be on as well as all the query parameters to influence the output of the Swap and on the right will be code Snippets for whatever language you actually want to do these calls in so there's code Snippets for node python curl and go currently so let's go ahead and just fill out some of these parameters we're going to fill in usdc and die as well as a rate of 100 usdc and we'll just click on the try it button right inside of the UI and we get our response um lots of decimals because it's D but that's roughly 100 die coming out on the other side um now also something that's really cool is as you fill out these query parameters the code Snippets update themselves too so in this case we now have a fully functioning call uh to our rest API using nodejs so I'm just going to take that code snippet and I'm going to copy it into uh webstorm over here so we can run it locally copy and paste that here and then add one little bit of extra code to actually make the function call itself and when we run that we'll see at the bottom it's this exact same output well almost the exact same output but we see that the function works not much needed on our side besides actually writing the code to call it um now you can do this with all of our apis just go through the documentation use the rest endpoints fill out the queries um but Fusion is pretty complex so we made an SDK on top of it to abstract that by one layer so here's the link to uh the fusion SDK and it is written in typescript and it simplifies interactions like I just mentioned if you go to that link and you check out the readme there will be examples of how to use the various function calls and try to make it as simple as possible for you there and We additionally have an actual example repo that uses the SDK so if you're using the SDK and it kind of is uh causing some struggles there's actually one that we made that just writes a concrete swap from token a to token B and uh you can check it out that way so this is the link to that one um like I just mentioned it's simplifi it's a simplified version of a use case for the fusion SDK and again this is probably best to use as a reference because it's hard-coded everything so it's not really meant to just be you know parameterized just take a look at it copy it if you need to or just use it as a reference while you're using the fusion SDK uh some important notes about the uh 1-in API requests themselves which can hang people up is um if you're using our aggregator um you can't do it exclusively within a smart contract call um you actually always need to be making a rest call to our API first to get the call data and the reason for that is the way our aggregator works is it's doing a lot of offchain computations like actually a pretty insane amount of offchain computations because it needs to look at all liquidity sources that we track on the chain and then it needs to use your specific input amount to find the correct output amount so all of this obviously can't be done on chain so this this is a step that is required no matter what kind of swap you're doing through our platform on the aggregator so kind of a a diagram to kind of show that happening let's say you have some node.

js backend that's trying to do some sort of scripted swap behind the scenes and you have your smart contract cont ract and somewhere inside of your smart contract you want to make a call to the 1-in AP or the 1-in router to do a swap and it looks something along the flow like this um this will fail or you probably won't even get this far but you know visually this is what this is what the failure would look like um what you actually want to do is your your back end needs to make a call first to the 1-in API with the token input token output and the amount that will get you the call data you need and then you can pass that into to your smart contract will eventually which will eventually make the call to the 1-in router um complexities are also increase by one step if you're going to be doing things from your UI um these need to go through a proxy um if you try to do it without a proxy you're going to run into content security policy uh issues as well as cores issues um so this means using something like Lambda for your proxy or even a simple node.js server that you just run locally next to your project while you're trying to do a proof of concept um we'll go through uh uh we'll reference a simple nodejs program that I wrote to to make that easy as well um so let's say you have some front end you try to make your first request to the 1in API to get the call data for your Swap and this is where that failure would occur so what you actually need to do is have your front end first call out to a proxy layer that proxy layer will then make the call to the 1-inch API and then you can send that information in to your smart contracts um here's the link to the simple proxy that will help you just kind of you know proof of concept easy to get through uh all you do is just pass it uh the end point that you're trying to talk to and it will do the rest of the work behind the scenes uh simple proxy and then again this one also has a very simple readme it's really hard to mess up so don't be scared just just jump in and give it a try um and then lastly um the dev portal has a lot more access to apis than just our swapping platform we have things like spot price um information uh token information uh balances API uh we just launched uh our portfolio API as well so there's a lot more there that can help you a lot in your projects to just simplify the bootstrapping process so you don't have to do things yourself or you don't have to jump around and use a lot of third party providers that all come together to make your project so Dev portal is a great place to start and then it also gives you great access to a really powerful aggregator in the system or swapping tool too uh so yeah that's everything for me thank you guys and uh here is the link uh uh QR code that will give you links to everything I talked about today so that means Dev portal Fusion SDK an example repo using the fusion SDK and then a really simple basic local proxy so use these to build whatever you're going to build now or during the hackathon um and yeah come by our booth if you guys have questions and we'll help you with any technical questions that you have