Cross chain Swaps and Beyond with 1inch I Tanner Moore

[Music] My name is Tanner and this presentation is crosschain swaps and beyond with 1 in. Uh I am a developer relations engineer at 1 in. And let's get started. So today we're going to be talking about classic swap which is what most people probably know 1 in for which is our AMM and PMM aggregation. We're going to talk about 1in fusion which is our intentbased swaps and we're going to move on to 1 in fusion plus which is crosschain swaps and then we're going to talk about integrating these into your projects.

So a quick little blurb about 1 in as a project and its origin story. We started as a hackathon project in ETH New York in 2019 and since then we have grown to over 3 million users over $55 billion in total available liquidity. We have processed over $500 billion in volume through our routers and we currently hold around 38% of the aggregation market share and that's about double our next closest competitor. So it's still a very strong position in the market. So let's jump in and talk about swapping with 1 in.

So here are all the chains that we currently support. Um there's 12 of them. Uh this is supported for both our aggregation as well as our intent swaps and crosschain swaps. There is one exception to this being that these uh these 12 are EVM based chains. And we have also recently launched on Solana which is our first jump into nonem swapping through 1 in.

Only on uh Salana is fusion. There's not aggregation or crosschain but uh hopefully that will be coming in the future. Uh right now this is all we have and we're going to talk about more non-EVM implementations a little bit later uh in relation to the hackathon. So let's start with classic swap. Again this is our aggregation.

This is what people most know one in for. So it's uh aggregation of onchain swaps. So we source liquidity from all popular protocols. We combine these protocols to optimize a swap output for the user and we execute all of these swaps in a single transaction. So, let's go through an example.

Let's say that some new user comes into Ethereum and they want to swap USDC to die. They will likely take their USDC and put it directly into unis swap and get their die. And that's fine. That's what most people do anyways for a lot of their swaps and I still think they hold something like 50% of uh the deck's market share. So, this is what most users will do.

But, let's just pretend they are a little bit more sophisticated or their friends are more sophisticated and they say, "Oh, you should use an aggregator like 1 in." Their USDC will then go into the 1-in system. It will then use our complicated pathf finding algorithm to find the best place for that USDC to be swapped to die and likely still choose unis swap because just a lot of trades really do actually go through unis swap. But let's pretend that maybe they have a very very large amount of USDC or they're doing some uh token pair that isn't so common like stable to stable. Now you get to see the benefits of our aggregator which would be maybe splitting some of the trade to go through dodo.

Maybe it does a intermediary swap to tether through curve and then take that tether and put it through sushi swap and eventually get to the die for the user. So we this will get as complicated as it needs to be to give the user the best rate. Um you might be thinking yeah the gas cost will also go up as you add more complexity but we factor this in as well. So we're going to do what has the best total output for you. So if that means adding more complexity because gas is cheap or if that means using a single provider because gas is really expensive we will take that into account when we are making that decision.

So let's go back to the simple example of going through unis swap for a simple die transfer or USDC to die swap. Um let's compare these head-to-head and actually look at the uh gas efficiency of these. So if you just go through unis swap directly you'll use about 205,000 gas on unis swap v3 and if you do uh the same swap but go through 1 in first you actually only use about 175,000 gas. So even in cases where you're doing the most common use case uh for swaps, it actually is still cheaper because we knew that uh we could actually out optimize the uh unis swap router and save gas there. So even in these common use cases, totally worth trying this.

Um in the end, aggregation uh will probably be how most token swaps happen. So let's jump on to 1in fusion. So in this system, a user submits a swap request with a signature. A Dutch auction is created for the swap. Resolvers asynchronously compete to fill that swap.

Users are protected from uh from me by design. And finally, it is a gasless transaction for users. Uh so there's a lot in there. So let's break down some of what we just talked about in that slide. Uh so what is a fusion Dutch auction?

Or more broadly, what is a Dutch auction? Uh in a traditional auction, you start at some low price and you go up until there are no more biders left and that's the final price that is used to sell an item. In a Dutch auction, the opposite is used where you have a very high price or maybe something slightly above what they think the market rate is and that will go down slowly over time until a single person says, "Okay, I'm interested in that price and then that is the end of the auction." So, it kind of inverts the traditional auction model to uh come up with new approaches to selling things. Uh the next one is uh what is a resolver?

These are counterparties inside of the 1-in fusion system that are going to be the people actually doing the trades. So in this system, it isn't just uh&m swaps with you posting transactions on chain. It's signatures and counterparties trying to give you the best rate they possibly can by competing with each other. So let's look at a really simple chart here. This is like what a Dutch auction kind of uh theoretically looks like.

You have time on the x- axis and rate on the y- axis. And that first dot at the very top left is going to be the maximum price that the user can get for a swap. And it will slowly inch down over time until it gets to some minimum price. And along this curve, ideally a counterparty picks this up and finishes the swap for the user or does the swap for the user. So let's go through a diagram and actually talk about what's going on here.

So a user says, okay, I would like to swap 50 USDC for die in the fusion system. uh we will estimate somewhere around 50 die because it's a stable uh stable coin to stable coin transfer. The user will then sign this transaction and they will send it off to the 1-in API. The 1-in API will then post this transaction into the internal fusion system and it will start the auction. So let's say this is a three-minute fusion auction in this case.

This information will then be propagated to all of the resolvers in the system who are trying to watch and see what's going on. And every block each of them will decide, hey, do I want to fill this or do I not want to fill this in most cases early on it will be a pass because it's going to slide at uh start at either market rate or just above market rate. But eventually there will be resolvers that say okay at this rate I can take this swap and actually make profit from it in some way. Now at this point in time since these are actually done on chain this can be a competing situation where two resolvers say they want to fill this auction at the exact same moment. And in this case it's just a gas war.

It's just who pays the most for the auction. But there's also the option to do partial fills. And if you do a partial fill, there are scenarios where both resolvers can actually fill this auction as long as they don't go over the total 50 USDC amount. This will repeat until all of the USDC has been swapped. So here's a much more complicated chart showing uh a real swap that happened in the system.

This was 3,700 W for USDT. And the curved line at the top kind of slanting down is the price where the fills were happening. And the dotted line that's straight across in the middle is the market rate. Each of those dots along the top is where a resolver came in and did a partial fill of this massive swap. And by about the 4 minute and 48 second mark, all of the partial fills had completed and the whole swap executed at slightly above market rate.

So this is a massive swap and uh something that probably no aggregator could ever do because you're actually beating the market with this approach. And this is why long-term intent swaps will probably be the way that most swapping happens and will have maybe a niche market, but intents will kind of be where people move to long term. Okay. The uh question you might be wondering is where are these resolver getting this liquidity to do these uh swaps for users? And the way we designed the system is that's really up to these counterparties.

Maybe they have uh some sort of connection with a sex. Maybe they have a uh personal funds that they're using. Maybe they have found some arbitrage opportunities in a DEX or maybe they're doing something clever with crosschain. It's really up to these resolvers on how they would like to uh get this liquidity to execute these trades for users. Okay, on to Fusion Plus.

So, when we were building Fusion Plus, we tried to ask ourselves what matters for users when it comes to crosschain. Um, we know that we need good swap rates because people are going to go to wherever they can get the most efficient trades. And we know that people also really like simple UX. And the last one that we thought was really important was to try to make a system that's as trustless as possible, right? Because bridges are kind of complex sometimes and they don't have the best UX.

So, we really wanted to make sure that the design itself was going to actually be cryptographically secure, not uh not try to come up with maybe an incentivization to be honest, but actually like build it into the uh protocol and design itself. And what we ended up landing on was hashed time lock contracts. Hashim lock contracts are simply smart contracts that hold funds and they require some secret s to unlock the funds and after a certain amount of time they'll expire if that secret is not provided to them. So you either provide the secret and unlock the funds to the final destination or they expire and the funds can only go back to where they came from originally. So let's look at another example.

So we have uh a user here and they have some secret s and only they know this secret s they will hash this secret and they will create one of these escro contracts uh using the hash of the secret. So it's not the actual key it is a hash of the key. If someone else goes to this contract and they try to get the uh funds out of this let's say in this case it's ether uh they can't do it. The the transaction will not succeed. But once the user shares this secret s with somebody else they can interact with this contract.

the contract will run the same hash validate that it is the correct secret key to get access to the funds and then those funds are unlocked. So that's the core design around how uh our crosschain swaps actually work. So let's go through another example similar to fusion. You say I have 50 USDC on Ethereum and I would like to swap it to 50 die uh on base. You sign a transaction.

You send that off to the 1-in API. The 1-inch API then starts a Dutch auction. It says, "Hey, there's 50 uh USDC. We would like to swap it to die." And they send all of this uh information out to the resolvers.

Just like before, same thing happens. People are competing to see who actually gets a chance to fill it. So, let's just keep it simple and say that one resolver took the entire uh auction. And now we get into kind of the execution phase of of this swap. So Resolver 2 has now kind of claimed rights onto this swap and they will start building out these escro contracts that we talked about earlier.

So they will build an escro contract on Ethereum and they will deposit uh uh what we call a safety deposit and this is a financial incentivization to make sure that the funds get released at the end whether that's releasing to the uh resolver 2 in this case or releasing back to the user. We just want to make sure that the funds don't get trapped in the contract. So to kind of create this whole uh contract at the very beginning, you need to put in the safety deposit so that it makes sure something uh happens at the very end. They will also create the escro contract on the destination chain in this case base. They will then use the permission that the user had originally granted to the Ethereum router or to the 1-in router and they'll move that USDC over to the escro contract on the source chain and then resolver 2 will then fund the uh escro contract on the destination chain.

So at this point now we have 50 USDC in the Ethereum escro contract, 50 die in the base escro contract and the next phase of this swap can actually happen. And that comes in uh now comes in the relayer. So the relayer is a service that is watching both of these escrow contracts. So they're watching the source chain, they're watching the destination chain, and they're waiting to see that everything is where it's supposed to be. Once they see that the funds, the correct amount of funds are on both of these contracts, it waits a small amount of time to make sure that there is no chance for a reorg or anything like that.

And after that period goes through, then they basically announce to the rest of the system, hey, everything looks good. It's time for the user to release their secret so we can complete the swap. So at this point, the secret is finally released from the user. At this point, it has never left their computer. It is just sitting there waiting to hear the message that the auction is uh that the esro contracts are properly funded.

They send this information to the relayer. The relayer then broadcasts this secret out to the resolver uh as well as every other resolver, even the ones that were not part of this auction at all. And the reason for that is again what we talked about earlier where we want to make sure these funds don't get trapped. So resolver 2 in this case since they were the one who claimed the auction will have a small amount of time where they can be the ones to release the funds and they will get the safety deposit that they had originally deposited into these contracts. If they do not do it do it during that exclusivity period they will then uh lose those rights and anybody can do it.

So resolver one resolver N plus1 anybody who wants to finish off this transaction will then be able to claim the safety deposit and this design is not limited to just the EVM. Uh that's what we talked about earlier with kind of starting to look into Salana and that's what we're actually focusing on with this hackathon is we want people to build this system but for chains outside of the EVM space. So sui apttodos anything like that anything you guys are comfortable with this is something that can be done today using our official escrow contracts uh and that design and it can it can work already. So this is something we want people to build. Okay.

So on to the next section of how do I actually integrate 1 in into my product uh project generally. So the way you actually interact with 1 in is through the developer portal and the developer portal also has pairing uh SDKs to make this as easy as possible. So let's talk about the developer portal. This is the official hub for integrating 1in into your projects. You This is where you're going to get your 1-in API access key.

So you can talk to all of our REST APIs. This is going to be where you get documentation for all of the APIs, well swap APIs and other APIs, as well as examples. You go to this website, portal.wind.dev, to get started.

Don't worry about writing any of these down. There will be a QR code at the end that will link you to all of this stuff. And we'll just take a quick look at what the website looks like. You get here, you sign up, you get access to a dashboard, which I think it's a little blurry, but this is the dashboard where you can see uh all of your uh API keys, requests, summaries of what you were doing, as well as get access to all the documentation. So, this is Swagger documentation for all of our various REST APIs so you can figure out what you uh uh need to do to interact with our system.

Okay, let's talk about the one uh 1in SDKs briefly. So we have multiple SDKs that simplify the interactions with our APIs. For most of our APIs, it's pretty straightforward. Like you don't need an SDK, but for swapping with things like Fusion, there is actually a ton of call data that's generated and it just it would be really hard to do this without the SDK. So I would consider this critical infrastructure if you want to integrate with our uh Fusion system at all.

These are written in Typescript and Golang currently, but they're going to expand to uh more languages in the future. And uh when you are building uh with the 1-inch API, it's very very important to know that when you make requests from the front end, you have to use a proxy. If you don't use a proxy, you'll get a lot of confusing errors and uh it might not be very clear what's you need, what's actually going wrong, but let's talk about it briefly. So if you have a front end and you say, "Okay, I would like to call out to the 1in rest APIs." This will just straight up fail.

uh you'll get a corores error I believe and uh it's not like it doesn't really explain what's going on but it's basically saying we don't want you leaking your API key to whoever is connecting to your website. So if a user's on your website and they are making a request to the 1-in API raw they'll also see in the headers your uh API key. So a proxy is going to be how you uh protect that. So what you actually want to do is front-end request goes through a proxy proxy then attaches your uh authorization token and then that's what eventually will be sent to the one API and then obviously the smart contracts from there. So I created a really small repo just to make this simple for hackers who want to actually use our APIs without figuring out how proxies work in case you aren't familiar with that.

Um this is a cloud hosted proxy and it'll work with all of our 1-inch APIs. Again, don't worry about the links because you'll get them at the end, but feel free to take pictures. Um, it has a nice read me. It uses Versell. Uh, you have a free tier on there.

It's it's completely free. It's as close to a one-click setup as a proxy could be. So, this is the way you want to do it if you're using our APIs at all. Um, and then lastly, we will quickly talk about just the more general API suite we have. So, you can get token price data, wallet balance data, uh, even NFT data.

Uh um there's a lot of infrastructure that we built out that we publish through our REST APIs. So uh if you're doing anything at this hackathon and you want to just get data that's not being pulled from an RPC directly, um we have probably a good chance of offering that data for you. So that's something else to to uh to be aware of. Okay, last let's talk quickly about the bounties. So uh as I discussed earlier, nonem extensions for 1inch crosschain swap, which is fusion plus that has $12,000.

The top three projects will get their share of that. We are also asking to uh for people to build on limit order protocol. We didn't talk about that in this presentation but come to the booth if you're interested in order books claws or limit orders in general and we can talk to you about what we have built and what are some ideas that you guys could build on top of that. We've already heard some cool ideas from people coming by the booth today. And the last one is to utilize the 1-in APIs and that is for uh $1,500.

Uh so yeah, that is everything for me. Uh not portal.dev. Yes, this is the QR code. This is a link to hackathon.

inish. community which is kind of the hub for accessing everything to do with the hackathon this weekend. Um this will also give you an API key so you can get unlimited access to our APIs. So if you're doing anything with uh 1 in this hackathon, start here. Get your API key through the uh the flow that we've put up for the hackathon.

And yeah, thanks guys. Any questions? I think we have time for like one if anybody has a question.

Yes.

You you had this chart where somebody sold like a 1500 ETH.

Yes.

Above the market price.

Yes.

Over the course of about four four hours.

Uh four minutes. Four about between four and five minutes. Yes.

Okay. Already better. Um um so you're saying that resolvers find ways to make money somewhere somehow and that's how they c could you maybe elaborate on that like how how does it how it's it's it seems like magic. Oh, uh I have never done it myself, but you can think of things like maybe uh there's a price discrepancy between two centralized exchanges or two decentralized exchanges and they found something that's, you know, a unique way maybe with uh I don't I'm not I'm not one of those resolvers, so I don't know how they do it exactly, but uh arbitrage would be a good example of where people find ways to inch out a little bit of money. I mean, some of these resolvers will do a very large swap and they'll make like $5, but that's still $5, right?

And then once you get to the volume that we've processed, which at this point is around 500 billion, like you can see how even a couple, you know, basis points that you're making on these swaps, even if it's just pennies, it will really add up over time. So that's my best answer for you right now, but uh uh I I I don't know exactly all the creative ways that people do it. Uh but I just know kind of high level. Oh,

um hi. Um I I can explain a little bit more deeply. So the thing is, um especially for higher amounts, we can organize more uh because we uh let market makers to compete between each each other and we try to sell on a spot price. So when you exchange uh especially bigger amounts you face a price impact. So you you get actually not not at the rate of spot price you get actually on a versal rate because liquidity is limited and uh especially liquidity is very fragmented.

uh you have on base less liquidity for for example ETH USDC pair on Ethereum you have better liquidity if someone swap on base then arbitrage traders potentially will arbitrage market makers will arbitrage from Ethereum blockchain into base um they they don't do it like in in in in this time they have balances on different blockchains they uh maybe buy your Ethereum or or sell Ethereum to you and do the the reverse trade on the other platform it can be like other blockchain or it can be centralized exchange that's why um kind of we can organize more so and uh the Dutch auction gives the opportunity to to to sell the user to the market makers over time uh for small amounts the settlement is in a first or second block yeah um for bigger amounts it can go over minutes um but it generates more we have real world example I don't know what did you did you Oh, I came a little bit late. Um, rule example 12 million uh USDT to Ethereum. This guy who who did exchange on one H got 200,000 was more. So this is like a new 911 Turbo. Well, they they got free because of using our so yeah arbitrage opportunity is always there.

Um some market makers also have uh things uh like okay I need now to sell for a customer a lot of Ethereum. Yeah. So, and they um do they have do they have the chart? Uh did you show the chart?

You you're talking about a gigantic uh the 3,700.

Yeah.

Just keep going back.

It's a way longer than

so uh when market makers compete uh they they settle uh in my presentation I have another normally but but yeah you need to check. Um so you see the the the first point in this in this chart is um is the spot price. Um middle here. Yeah. Not in the middle almost.

Um this is the market rate. The difference between the spot price and the market rate is the price impact. What the what the user see. U the market rate you get when you do classic swap. So not intent by swap.

Plastic swap is when you ask an aggregator to provide call data with uh the complex path how to exchange one asset against another um and you do the transaction by yourself. So you face this price impact immediately when you do the transaction by yourself and we can reduce it. Uh yeah this the spot price is actually yeah it's what you see on the centralized exchanges but you have always a spread in the centralized exchanges. Yeah and the spot price is like um yeah the last traded uh price um but it's you know the liquidity is very thin. Yeah.

And

so am I correct that the seller here got the price somewhere between the

spot price and the market rate? the the the the fast market price, the spot price on centralized kind of and the market price on the blockchain if they do it this trade just in a normal manner. So they they're like in between. So they're not actually beating the market uh but they are losing less than they would if they did this on chain naturally. Is this is this correct?

It's it's like that like if you if you think if you think Can you guys do this like this?

Oh, okay. We are okay. All right. Yeah, we can discuss afterwards. So, um like under under the hood, we we just try to reduce the price impact when someone exchange assets especially for bigger amounts.

We we pull the liquidity from everywhere like like that.

All right. Thanks, guys. [Music]