Tanner Moore I Cross chain Swaps and Beyond with 1inch I ETHGlobal Prague 2025

[Music] So this is uh crosschain swaps and beyond. Uh my name is Tanner and I am a developer relations engineer at 1 in. So uh today we're going to do uh we're going to talk about classic swap which is our AMM and PMM aggregation. We're going to talk about 1-in fusion which is our intentbased swaps. And we will also talk about 1-in fusion plus which is our novel implementation of crosschain swaps and then we'll talk about how to integrate these into your project.

So before we get started we'll talk a little bit about uh 1 in as the project. It started as a hackathon project in ETH New York in 2019 and since that day it has grown to over three million users, has over $55 billion in total available liquidity and has processed over 500 billion through our router contracts and currently has around 38% of the aggregation market share which is about double our next closest competitor. So swapping with 1 in. Uh so our classic swap is currently available on 12 different chains. And our fusion and fusion plus modes are available on 10 of those uh chains.

Just Aurora and Clayton are not supported with Fusion and Fusion Plus. And most recently, we also added Fusion support for Solana. So we're finally venturing out past the EVM uh bounds. And uh we'll talk a little bit more about that with the bounties later on in the presentation. Um so let's jump in and talk about classic swap.

This is what most people know us for. Um, if they know about us at all, it will probably be for Classic Swap, otherwise known as our aggregator. And what this does is it sources swap liquidity from all popular protocols. It combines these protocols to optimize the swap output for the user. And then it executes all of those swaps in a single transaction.

So, let's just go through a simple example. Let's say some new user says, "I want to swap my USDC for die on chain." They're going to take their USDC and they'll probably just go to unis swap because that's what people probably tell people about. and it's tried and true and it always has really good liquidity and low slippage and price impact. But let's just pretend that somebody told them, "Okay, you should try an aggregator first, specifically 1 inch."

So they send their uh USDC to the 1- in router and we then do our complicated swap uh calculations to oh thank you our uh complicated swap calculations and likely it'll still actually end up going through unis swap because they have really good liquidity and like I just said they're they're where a lot of people put their swaps through. Um but let's just say they end up doing a really big swap, something that's like past $10, past $100, now we're in like the thousand range and higher. Now you start to see a lot of the benefits um even on these really stable pairs like USDC and die. So we might split that trade and do part of it through Dodo. We might go through curve and put some of it through to tether before finally swapping to tether on sushi swap to die.

And the complexity just keeps going up and up and up as these swaps get bigger to make sure that the best possible output goes to the user. Uh some of you might be thinking, yeah, but this increases the gas cost as well. Um but that actually is also calculated into the final output amount. So we factor that in when we're deciding what routes to take. Um, but let's just pretend we go back to that simple case where they either go to the unis swap router or they go to the one-inch router which then goes to the unis swap pools.

Let's just compare those head-to-head. So, if we do just unis swap v3, we use about 205,000 gas. And if we do the 1-in router that then goes to unis swap v3, it's actually only 175,000 gas. Uh, gas is pretty cheap right now, so this doesn't matter. But you can see that even in these cases, it's still cheaper.

And the reason for that is we skip the unis swap router entirely and we just interface directly with the pools. So we can just keep refining that, keep getting more and more optimized until it beats them. Um because the router is static, it's never going to change. Um so that's our basic aggregator. Uh now let's jump into 1in fusion.

So this is a much more complicated form of swapping. This is where the user submits a swap request with a signature. It starts a Dutch auction that is created for this specific swap. resolvers then asynchronously compete to fill the swap for the user and users are protected by uh from me by design um which is just ways that people extract value out of the more traditional onchain swaps. Uh these are also gasless transactions as well just a lot of little things that slowly make the UX better and better for users.

So I threw a lot of terms at you there. So the first one is well what's a fusion Dutch auction? Uh more generally what is a Dutch auction? And that is just an inverse way of doing auctions where instead of starting at some low price, you start at a very high price and go down slowly until there's just one person that says, "Okay, this price is actually something I'm interested in." So, it just flips the traditional auction model on its head.

Uh, and oh, and for Fusion specifically, that's going to be the token price. Uh, and then you also might be curious, what is a resolver? And those are entities inside of the 1-in fusion system that are watching these Dutch auctions and waiting for their chance to jump in and try to make profit off of doing swap for some user. So here is a simple diagram just kind of showing what it might look like um over time. So the x- axis is uh time and the y- axis is rate.

And you'll see at the top left dot there that is the max price that a token will be sold for. And over time this price will slowly go down to some minimum over the course of the auction. And along this point at some uh some point uh there will be a resolver that jumps in and does the swap for the user. So uh this is let's just walk through a simple kind of step-by-step uh path that a user might take when they're going through this system. So they have 50 USDC and they go to 1inch fusion and they say I would like to trade this for die.

Fusion will quote them at somewhere around 50 die since they're both stable coins and the user will say that's fine. I'm going to sign this transaction and it will go off to the 1-in API. The 1-inch API will then start this Dutch auction. Let's just say it starts for around 3 minutes. Um this is configurable but I think there's a default somewhere around this.

and it will then send this Dutch auction information to all of the resolvers inside of the system um one through whatever n plus1 is. Um as this Dutch auction is going on at the beginning most will probably pass because the auction is going to cost slightly more than the market rate but eventually it'll get to some price ideally around one where people will start being interested and they'll start competing to try to claim the right to actually execute on this uh this swap. uh if two people come in at the same block and try to do this entire swap, one of them will be the one who takes it and that's just whoever pays more gas. But if the combination of total swap volume that they're doing is less than the 50 USDC in this case, then they both can happily do their parts of the swap. It doesn't really matter.

This just repeats until the entire 50 USDC has been swapped. So here's a much more complicated graph of an actual swap that went through Fusion. So in this case, there was 3,700 W ETH that was swapped for USDT. And you can see at the left that uh the slanted line is the line that the tokens were swapped at or auctioned at. And the dotted line going across flat just a little bit under it.

If you can see that is market rate and each of these dots on that slanted line are points at which solvers filled part of this order. So there were something like I think 17 sol uh uh resolutions along this entire curve. And by the time the 3,700 ETH was swapped, it all happened at slightly above market rate. So this is something that's not possible on a traditional AMM or aggregator because this is actually better than market rate was at the time of the swap. So that's kind of the power of these asynchronous swapping mechanisms.

Uh so a question you might be asking is well where do these resolvers actually get the liquidity to do these swaps for the user? And that's kind of the beauty of the fusion system is it's really up to whatever the resolver themselves wants to do. So maybe they're doing something with centralized exchanges. Maybe they're just like a family office who's using their own funds to make these swaps happen. Uh maybe they found some interesting technique that they could use with dexes.

Or maybe they found some arbitrage opportunities uh using different chains. Um and now we can jump into Fusion Plus. And the reason we called it Fusion Plus is because it was just the next evolution of the Fusion system that we had already built. So we asked ourselves, you know, what matters for users with crosschain swaps? And uh we thought, well, one of those is just good swap rates, right?

You want to make sure that there's a a financial reason to be choosing us over our competitors. Uh another one's simple UX. You want something that's just like simple for the user to use and not this complicated thing that needs tutorial. And trustlessness. And maybe users don't care that much about trustlessness, but that's just what 1 in has done so far is we always try to make the most permissionless systems we can.

So this was very important when we were designing the system we used for Fusion Plus. Uh, and that led us to hash time lock contracts. Um, it's kind of a long technical term, but if you are not familiar with them already, they're simply just smart contracts that are going to hold these funds that require some secret s to unlock those funds. And after some amount of time, they can only revert. The funds can only go back to wherever the uh the funds originally came from.

And uh this will become more obvious as we kind of walk through how these work. So you have a user and they have some secret S and they're going to take this secret and they're going to put it through a hashing function. And this hashing function will give them some sort of garbled data that is used to create the contract where they're actually going to put their funds. And if some user wants to come in and take those funds out of the contract, they can't do it. It's impossible until they have access to the original secret that the user hashed to create the contract.

So this contract cannot be interacted with until somebody publishes that secret into the call data of the function call. So let's walk through another example. So a user says I would like to trade 50 USDC on Ethereum for 50 die on base. They sign the transaction once they're happy with the estimated return and they send it off to the 1-in API. The 1-in API then starts another Dutch auction with 50 USDC and 50 D on base.

And again, there are resolvers that are watching this and deciding if they are interested or not in facilitating the swap for the user. And just like before, one of them will eventually say yes. If there's competition, same exact problem as before. Um, if they both are doing less, they can also share that uh swap for the user in that particular block. And let's just keep it simple and say that it is one resolver that took the entire 50 USDC.

So in this case, let's just say it was resolver 2. So Resolver 2 is going to create an escrow contract on Ethereum and they're also going to deposit what we call a safety deposit into this contract and that's just uh some amount of the native gas token that will be given to whoever completes this transaction whether it's succeed or revert that's going to go back to whoever actually makes that call. So they're going to create an escro contract and they're going to do it uh on Ethereum and they're going to do it on base. And the reason for the safety deposit is like financial incentive. We don't want these bunk uh these contracts becoming dead in the water and just people having to like manually go in and try to fix it themselves.

So if it gives somebody a financial incentive to actually complete the thing at the very end, then somebody will jump in even if it's not the original resolver. So after they create both these contracts, they use the permissions that the original user granted to the router contract, the one-inch router contract to transfer those funds to the escro contract. So the user had Ethereum on USC. they gave permission to the 1-inch router and the resolver kind of used those permissions and said, "Okay, I'm going to move their USDC into the official escrow contract. The resolver will then put their tokens that they're swapping for the user on the destination contract."

So in this case, the user has USDC on Ethereum. The resolver has die on base and they've now got both the tokens where they need to be in both contracts on both chains and now the stage is set to actually solidify the transaction. And this is where the relayer service comes into play. So the relayer is watching both of these contracts on chain. So the uh escro contract on Ethereum and the escro contract on base and they're waiting to see that the funds are actually both where they're supposed to be.

Once that looks good, they're going to wait for some sort of like finality period to make sure that these blocks are actually going to stick around. Um since this is Ethereum, I'm guessing it's around two to three blocks. Once that looks good, then they're going to go back to the user and they're going to say, "Hey, everything looks good on the escro contract side. Now it's time to share your secret." the uh user shares their secret with the relayer and the relayer now gives this secret to the resolver to publish and complete the transaction for both sides.

They will also be giving this secret to every other resolver, but they'll have a small window where resolver 2 can be the one to complete this. And this goes back again to saying, "Hey, somebody needs to make sure that the funds end up where they're supposed to. We don't want these things hanging around." Once this secret is published on chain, it's in the call data, so anybody can access it. So that makes it where once one uh contract unlocks the funds, the other one will be unlocked either in the same block or maybe a block later, but it'll always get unlocked without any reversions because the secret to actually unlock those is now public knowledge.

Um, as we kind of alluded to at the beginning, this system is not just limited to the EVM. Uh, this is available for any platform that supports hashtime lock contracts. That means all smart contract platforms and even Bitcoin. Um, I'm not super familiar with the technicals of Bitcoin, but I'm pretty sure Lightning Network uses this technology. So, they have op codes and stuff that actually support this.

Um, so the next questions uh that might be being asked is how do we integrate this stuff actually into their project? Like how do I take the 1-in services, the 1-in ser uh APIs and actually use them in my system? And that's going to be done through two things, the developer portal and 1-in SDKs. So the developer portal is the official hub for integrating 1 in into your projects. Um it's going to give you access to API keys to uh reach all of our APIs.

It's going to give you documentation for all of these APIs swap and then other APIs which we'll talk about in a little bit. And it'll also give you examples. Uh that website is portal.in.dev.

You don't need to worry about writing this down. There will be a QR code at the end and you can also talk to us at our booth if you want access to all the links discussed in this presentation. Um but this is what it looks like. It's just a website with a login page. It has dashboards where you can get your API keys and see your usages and then it also has access to all the documentation as well.

Um uh make sure to use the hackathon signup link that we provide you because that lets you get a free really high RPS API key without having to go through any of the uh normal process of getting of getting our access including uh KYC. Uh so onto the 1in SDKs. Um, we have created multiple SDKs to simplify interacting with our API. So, you're not just writing your own raw REST requests. Um, these are written in Typescript and Golang.

Um, TypeScript is the most TypeScript is the most fully functional at the moment. Golang is shortly behind it and in the future we're going to expand to things like Python and more. Uh, we're just going to try to get this these tools into the hands of as many people as possible. Um, some really important things to note is that if you're making front-end requests to the 1-in API, you have to use a proxy of some sort. Uh so to kind of explain this with some visuals, like if you have a front end and you have some widget on there where you're saying, "Oh, I want to do some sort of swap call to the one uh API from my website that other users are using."

This call specifically will fail. You'll get a corsair. It's kind of confusing and you'll you'll get very lost. Um and the reason for that is if you did it like this, people could just use network sniffers and grab the API key that you're using and then now it just makes it where they can abuse it and use it for all their own projects even though you're the one paying for that access. Um, so instead what you need to use is a small lightweight proxy that then makes the 1-in API call with the proper headers at the proxy level, not at the front uh front end level.

And then you can take that data and do whatever you want with it on the browser wallet or anything like that. Um, so I've created a really lightweight proxy to do this using Verscell. So this is the length. Again, you can get access to this from our docs later, so don't worry about catching this right now. Um, and this is just going to be a super lightweight cloud hosted proxy for all of the 1-in API requests.

Um, this is a quick little snapshot of the readme. And you see that I tried to keep it as verbose as I could. Um, and it's basically just step by step. You go to Verscell, you make a free account, you do a one-click publish of this uh proxy, you set the environment variable, and you're good to go. Here are other uh APIs that we offer.

So, we really focused on swapping, but we do actually a lot more with our APIs. We have things to get token metadata, NFT metadata, uh price for if you want to display some price information to your users on your front end. Um, there's a lot of stuff offered here. So just keep that in mind that uh there's a lot more you can do than just uh using uh uh our swap APIs and uh any of these will qualify for that particular bounty as uh so yeah so let's briefly talk about the bounties as well. So the first one is nonem extensions for our crosschain swap which is fusion plus.

Uh so this is basically uh you do not need to build a UI. You don't need to integrate with our official uh resolvers or anything like that in your system. You just need to create the hash time lock contract section of whatever chain whatever nonvm chain you're integrating with and then have it work with our EVM uh EVM contracts using just a command line script or anything. As long as it settles on chain and works, that'll qualify you for this bounty. Uh the second one is to extend our limit order protocol.

We added this bounty on at the very end, so I wasn't able to actually add it into this presentation. So if you're interested in it, uh you can come talk to us at the booth about it. Uh we also have an orderbook protocol as well. Um and there's a lot of cool stuff you can do with that, but yeah, I didn't get a chance to add it to this particular presentation. And the last one, which I said a moment ago, is to utilize the 1-in APIs just in whatever way you want.

Uh we even have a web 3 uh API that you can use to publish your stuff to the to the memp pool on on whatever chain you're using. Uh and that is everything for me. So thanks guys. [Applause] Any questions? Yes, he asked how to get this presentation.

Uh let me publish that and then share it with anybody who's interested. Right now it's just private, but uh I think I'm happy sharing it. So uh yeah. Yeah. How about that?

I'll add it to the bottom of this particular page. So save this and refresh a little bit later and I'll make it available for people. Any other questions? Fusion plus API. Uh he is asking if the fusion plus API handles batch swaps.

Do you mean like where you're swapping multiple tokens for multiple tokens like a one to many mini to one? at Ethereum and multiple chains. No, it's it's it's one to one on the Oh, well well so we support many chains. We support like 10 chains. Yes.

But in in in an individual swap, yes. One chain to one chain. Yes. Yes. So the question was for their their personal projects, how do they handle the resolver layer since it's not going to be the official resolver?

Is that your question? So in this case, it can be just a super lightweight just orchestrator. So don't think about like integrating with our official resolver set or anything like that. Just manage the funds. So there's a secret being published, you're managing the secret, the secret gets pushed to both uh make uh both contracts and something calls that.

So just think of just getting that information around. It can just be super local. Doesn't need to be anything with with our official stuff. Um so for uh he asked uh does anything work in test net? Uh which thing specifically are you asking about?

If you wanted to integrate crosschain into your project is that what you mean? Yeah. So we are not live on any test net. So unfortunately, you would have to kind of just burn a little bit of money going back and forth there. Um, for the hackathon, we're giving people tokens to make that a little less painless.

For projects outside of this, yeah, it just would be a cost just doing things on chain because we don't have a test net setup or anything for that. I agree actually. Yeah, I I'd like to see that in the future and that's something that we're discussing internally, but no commitment or anything yet. Yeah. Just because of the time the time it would take to engineer it.

Yeah. Okay. Uh are you are are you speaking from the resolver's perspective to fill just to Yeah. Do you mean like as someone who Well, so the resolvers in the system are like it's it's a it's a permissioned set of people. So like just normal projects can't kind of be on the filling side of this.

It's actually like entities that we KYC and kind of treat as businesses. Is that the part you're talking about? Yeah. So let's say Mhm. Mhm.

Oh. Oh. So you're saying like if Oh, are we short on time? Oh, repeat the question. Um, he's asking if uh partial fills are do.

So do you mean like partial fills, can you like enforce those as the user who proposed the order? Yeah. Ah, okay. So he's asking about like how partial fills work in the fusion system? Um, in the case of just normal fusion, like uh partial fills are possible, but as a user, I don't think you really have much control about that.

Like I don't think there's any minimum or maximum partial fill. I think you just kind of hope that across the whole Dutch auction everything gets filled. And if for some reason it doesn't get filled by the end of it, that will still happen. So you could have an order that gets 90% filled or 70% filled, but in most cases it'll be a hundred. But I don't think there's any granularity control you have over like how much of that actually happens.

It's just like as it gets closer to the end of the auction, ideally all of it will get filled. So each partial fill is an onchain transaction. So it just kind of happens as the auction goes on. So if the auction ends and it's not fully filled, then you just didn't swap that last piece. Um I I think in Fusion Plus we might be more strict with like once someone kind of takes it, they do the whole thing.

But Fusion has a lot more flexibility with with like just partial fills. But there's no guarantee it'll it'll all go through, but in most cases it will. And if that doesn't clear, we can talk after this and I can try to understand your question better. Yeah. Okay.

Sure. Uh the question was which nonem chains are we currently live on for plus? The answer is zero. Uh we are trying Salana right now like we're we're researching it. We're looking into it, but it is not officially launched.

And if people wanted to use Salana for the hackathon, that's totally fine. But this is this is kind of a new thing for us. And so we made a bounty out of it to see if anybody want to jump in. Yes. Yes.

Yeah. In in the in the hackathon startup doc, which is pretty big, there'll be links to all of the existing stuff like the solidity contracts as well as some example programs to help you kind of see how the resolvers behave. Yes. What action is used by the scroll contracts? Uh I am not sure on that.

I'll have to get back to that because we need to implement that also on the nonvm uh contract I guess. So yeah that's true easily implementable. Yeah. No that's that's a great point. I I'll have to check.

I don't know. So if you used Fusion Plus without without Salana like only EVM chains, so you're not qualified for the bounty. Uh like 1 in is not qual Oh. Oh, you mean like if you made a project that implemented an EVM chain, it does not qualify for bounty. Is that your question?

I mean if you only do like fusion plus crosschain swaps within the EVM chains because you said your your fusion plus is not supported with Salana yet. Correct. But your b your bounty is focused on non EVM chains. Yes. Yes.

So the bounty in this case would be to do that implementation. Yeah. So hash timelap contracts in a non-solidity language that can interface with with our side the solidity side. Uh that's the main piece and then you can just kind of build some sort of orchestrator to kind of share the secrets, get the secrets uh published and all of that just on a command line. No UI needed or anything.

It's just kind of that that core escrow piece. Yeah. And obviously the demo has to like do it. It has to be on chain at the end of the demo. Yeah.

So you're only in only using solidity then you won't be qualified, right? Yeah. This particular bounty is for nonvm implementations. Yeah. Okay.

Thank you. Yeah. Uh since this needs to be need needs to be on mainet would will it be acceptable using uh um forking the mainet network uh having a local network and doing everything locally? Yes, that's fine. And uh we also are uh we we'll give out onein tokens to people who just want to test on mainet if it's simpler.

So we can give you guys tokens on base just to give you a little bit of like money to actually get the money uh to transactions posting on chain without having to use your own money. Okay. So your choice forkit or we give you some tokens. But this needs to be between mainet and another and another nonvm network, right? Uh EVM to non EVM.

So if you want to do base because there was written specifically mainet I believe in the Oh, okay. Well then that's a that's a mistake. Yeah, just anything EVM. Yeah. Okay.

Okay. I can I'll repeat it. Yeah. Yeah, I f follow up with me on that. I think if you use the promo code in the docs, it'll upgrade you for the weekend.

I think we've covered that edge case. So, try the docs that give you the the the unlimited key and see if it upgrades your your key for the weekend. If not, we can help you get that. Oh, I didn't repeat his question. If you already have a developer portal account, uh how do you get the upgraded version?

And the answer is I think it just works if you follow the flow for the hackathon. If not, uh I can help you with that. Cool. Thanks, guys. [Music]