Tanner Moore I Boundless Cross Chain Swaps With 1inch I ETHGlobal Taipei 2025

[Music] Hello everybody. Uh my name is Tanner and this presentation is boundless crosschain swaps with 1 in. And we're going to talk about our latest swapping platform which is called 1inch fusion plus. Um so to talk about 1inch fusion plus sorry excuse me still getting over a sickness so gonna be coughing a little bit. Um, so to talk about Fusion Plus, we it makes a lot of sense to talk about how we got here.

So, first we're going to talk about classic swap, which is what most people probably know 1 in4 and it's our AMM and PMM aggregation. Then we're going to talk about 1-in fusion, which is our intentbased swaps. And then we'll get on to 1in fusion plus, which is our latest crosschain swap implementation. And then we'll talk about integrating that into your projects after that. So, a little bit about 1 in.

We actually started at a hackathon as well. Uh this is back in 2019 at uh ETH New York and since then we've grown from that small project into a quite big project with three million uh total users over three million over 55 billion in total available liquidity. Uh we have processed over $500 billion of volume through our routers and we currently hold somewhere around 38% of the aggregation market share which is a little bit over double of our next closest competitor. So let's talk about swapping with 1 in starting with where you can actually do it. So these are the chains that we have deployed on uh for our classic swap which is our aggregator that most people know us for.

Uh we're on Ethereum many side chains many many L2s and uh some other L1s as well. Fusion and Fusion Plus which is our intentbased and cross uh intentbased swaps and crosschain swaps is on a subset of that but it's still on 10 of the 12 that we've launched on. So we still have pretty good coverage there as well. So let's talk about classic swap. So classic swap sources liquidity from all the popular protocols.

It combines these protocols into one optimized swap output for the user to sign and send to the blockchain and then it executes everything all in one go. So let's go through an example of what that actually looks like. So let's just say an average user says they want to swap USDC to die. They're going to take their USDC and they're probably going to just send it to Uniswap because they're a pretty known protocol. They have really really good liquidity and it just keeps everything very simple for the user.

But let's assume they're a little bit more sophisticated or they want to go a little bit deeper and so they do decide, hey, let's actually send this USDC into 1 in for that swap to die. So then we will run our backend algorithm. We will look across all of the D5 protocols for the best swap rates and we'll probably still send it to unis swap actually because a lot of our volume does go directly to unis swap because again they have huge liquidity and they're just where a lot of people put their money. But if you have a much bigger swap or you are using less common pairs, we might do something that's actually pretty uh cool like maybe split the trade partly through Dodo or maybe go to curve first and swap your USDC to tether and then take that tether and then send it to sushi swap to convert it to die at the very end. So, this is probably something that is much more uh representative of power of an aggregator is just being able to really make sure that no matter what you're trying to do, you get the best output for that swap.

Um, you might be thinking, well, this actually could take a lot more gas to do this because you're talking all these different protocols, but we factor that in as well. So, we'll do whatever gives you the most output for your tokens at the end of the swap. So if we go back to the example we started with, you know, well, if a lot of trades on one inch just go through unis swap anyways, shouldn't I just skip the extra gas of the 1-inch router and just use unis swap directly? Well, let's compare them. So if we do a swap directly on unis swap v3, we'll use around 205,000 gas.

If we go through one in which eventually does go to that same pool on unis swap, we'll actually only use about 175,000 gas. So even in cases like this where it's a very simple swap, it still is cheaper because of the gas optimizations we've done by skipping the unis swap router and going directly to the pools behind the scenes. So on to 1in fusion which is intentbased swapping. So in this scenario they don't actually get the call data and send it to the chain themselves. They're just signing some sort of signature that says hey this is my intent.

This is the token I want to go in and this is the token I want out. a Dutch auction is created on the back end for uh what this swap's actually going to look like over the course of the lifespan of the auction or the the trade. Uh 1-in resolvers will asynchronously compete to fill that auction. And with this new design, users are protected from me by by design because there's no longer uh something for all these snipers to look at in the meool. It's actually a very strictly enforced swap where the resolvers are competing to fill at very specific rates.

So I threw a lot of terms. Oh, also uh it's this is gasless as well. So in the original swapping, the user is posting this transaction on chain. They're setting the gas values with intentbased swapping. Now they're just saying, "Hey, this is what I want to swap."

And they let the uh resolvers, the people on the other side actually do all of that for them. So I threw a lot of terminology there. So let's just kind of go through some of that. I talked about a fusion Dutch auction. Um so what is that?

Or maybe more broadly, what is a Dutch auction? So, in a traditional auction, you start at some low price and you go up slowly over time until there's only one person left who actually wants to pay the highest price for that item. A Dutch auction inverts it where it starts at some arbitrarily high price that probably nobody wants and you slowly move down over time until one person says, "Okay, this is a price that I'm actually interested in." Another term was resolvers. And these in the 1-in system are just entities that are the counterparties for these trades.

So somebody has to fill in this swap for the user. Somebody has to pay the gas. That's what these resolvers are. It's a small entity of people who are just listening for all these trades and they're actually filling them on behalf of the user. So here's a really arbit.

So on the y ais we have rates and on the x-axis we have time. that top uh the dot at the top left is some price for the market rate or slightly above market rate for the token that the user is trying to swap. And over time it will come down to some minimum and that at some point will be when a resolver jumps in and does the swap for the user. So let's actually go through a diagram of what a swap on the fusion system looks like. So a user wants to take their USDC and they want to trade it for die.

The fusion will estimate something around the output of USDC because it's a stable coin swap after all. So they'll tell the user, you're going to get about 50 die for this trade. The user will then sign this transaction and they will send it off to the 1-in API. This 1-inch API will then start this Dutch auction that we talked about earlier and it'll say, "Hey, I have 50 USDC looking to get around 50 die for it at the end. So let's get this done across the span of three minutes."

This auction will then be sent off to all of the resolvers in the system who are monitoring it and keeping track of the live rates at the beginning because the rate will be quite high. It will slowly uh be passed by each resolver each block. But this will come down over time and eventually resolvers will start to compete to say, "Hey, I want to actually fill this swap on behalf of the user." At this point, whoever pays the most gas is the one that's going to win. They're going to get the right to execute this on chain because this auction is happening on chain.

And so whoever's transaction gets in first is going to be the one that actually fulfills the swap. In the case where resolvers don't fill the entire swap, because they're allowed to do partial fills, two resolvers can compete in the auction as long as the total value is not over the the entire amount that the user wants to swap. So here is a complicated diagram of a real fusion swap that happened for 3,700 ether on chain. And all of the green dots you can see across this graph are points at which resolvers jumped in and did partial fills for the user. So across this auction there are 17 different points at which resolvers filled part of this 3,700 Ether swap.

And around the five minute mark of the auction the entire swap was completed. And uh the user actually got the entire swap done above market rate. So even though it was maybe about a dollar or so higher than the market rate, uh the entire swap, which was a very very large one, uh was actually executed more competitively than was physically possible with a traditional AMM. So a question you might be wondering is where do resolvers get the liquidity for these swaps? And that's kind of the beauty of the fusion system is we don't prescribe how these swaps will happen.

We just have the rules of the rates. So they could be getting this liquidity from a centralized exchange. They could be running their own funds as some sort of PMM operation. They could have found something clever with DEX arbitration. Maybe they found something cool with crosschain swaps.

It's really a matter of what they want to do and how they want to get the liquidity. And as long as they follow the rules on our side, everything's good. So that finally gets us to 1-in fusion plus. So when we were building out 1inch fusion plus we had to ask ourselves you know what what actually matters to users for crosschain swaps and that's uh the rates need to be good the UX needs to be simple or they'll go to someone else who can do it more more simply and trustlessness and maybe users don't care that much about trustlessness now but over time I think that'll get more and more important and because we're one inch and we're already a D5 protocol that's probably where we should start. So that eventually landed us on the implementation of hashed time lock contracts.

So in the context of 1 infusion plus you can just think of these as smart contracts that hold funds and they have to follow a couple rules. One of them is they require some secret s to unlock these funds once they're in there. And after some amount of time the uh only operation that can happen is for the uh funds to be reverted and go back to the original source location. So let's look at an arbitrary implementation of what this might look like. The user has some secret s.

This is information that only they know. They then put this secret through a hashed function or hashing function and that's what's used to create this this what we call an escrow contract which is going to be where these funds are held. And if somebody else wants to get the funds out of this contract, it's impossible unless they actually have the secret because that is kind of the the piece that unlocks the funds and it's something that only the user currently has because it's the hash of that secret that is actually stored onchain. So once the uh user on the other side has this secret, once the user has published it uh for somebody else to see, then they can take the funds out. So let's go through an example of this actually in our system.

So a user says, "Hey, I have 50 USDC on Ethereum and I want to get this in die on base." So they will sign this transaction and they will send it to the 1-in API very similar to the fusion system and the 1-in API will then start a Dutch auction just like before. They say, "Okay, I have 50 USDC on Ethereum. I want to swap this for 50 roughly 50 die on base." This will go out to the set of fusion plus resolvers and again they'll pass at the beginning because the rate is extremely high and then over time it will get down to something that they're interested in.

And again just like before they compete and they try to win with uh the higher gas value. Now partial fills are also supported in fusion plus but let's just keep it to a single fill uh to keep this example more simple. So resolver 2 in this case has gotten uh has won and now is going to be competing or has has no longer competing but they're now filling the swap for the user. So the first thing they're going to do is they're going to create an escro contract on the source chain. So in this case it's Ethereum and they're going to create this with two things.

One is the hash value of the secret that was shared by the user when they originally created the order. And the second is a safety deposit and what we what we call a safety deposit. And this is some amount of the native gas token that is sent into this contract to incentivize the funds eventually making it to wherever they need to go. So either that's to the the new owner of the tokens or to the original uh wallet that funded them. But whoever unlocks these funds will earn this native gas token and that will be the financial incentivization for this to not just get stuck there and the user wondering why their funds never left the contract.

So resolver 2 will also make the same escro contract but on base now. So they've created two contracts, one for the source funds and one for the destination funds. So now that they've done this, they're going to use the permissions that were granted to the one in router and they're going to move the uh source funds onto the escro contract on the base chain or the the source chain. And then the resolver will now take their funds on the destination chain and they're going to send that into the escro contract on base. So now the stage is set for this swap to happen.

funds are where they need to be from both the user and the resolver. And now we're move on to the next step and that is the relayer service. So you can think of the relayer service as kind of the oracle in this system that's making sure that everything looks good and the secret can be safely shared and the funds unlocked. So this relayer is watching the escro chain. They're walking on uh sorry the uh escrow contract on the source chain and the escro contract on the destination chain.

And once the funds are in there, they're going to wait for some finality period where we are confident that uh there will be no reverts on the chain. In Ethereum, that's probably two to three blocks. I'm not exactly sure. So 24 to 30 24 to 36 secondsish. And once that looks good, then they reach back out to the user and they say, "Okay, escro contracts are good.

Everything looks ready for you to start sharing the secret." And then they ask the user, "Okay, can you share the secret with us?" Now the user gives the secret to the relayer. The relayer takes the secret and it sends it out to the resolver. In this case, resolver 2 will get it first, but it will also send this secret out to everybody else.

And the reason for that is again, we don't want these funds to get stuck where the user doesn't know what's going on. So resolver 2 will get a short period of exclusivity where they can actually be the one to unlock the funds for everybody and publish that secret. But if for some reason they don't, then any other resolver in the system can do that. And then they can take the safety deposit that was originally invested by the resolver 2. Um and once you actually publish this ha publish this hash uh to the uh either one of these contracts uh sorry not hash secret the secret becomes public and then everybody can unlock the funds in any order they want.

So it's kind of a a game of where once the secret is published then everything unlocks and all the parties get the tokens at the very end. Uh the cool thing about this design is it is not limited to just the EVM. It uh anything that supports hashtime lock contracts will be able to support this system. that includes Bitcoin which has uh uh official op code support for this and it's any other smart contract like Salana. So this cross-chain system will work with all chains as long as they support the underlying technology of hash time lock contracts.

Okay, so now we can ask uh how do I integrate this into my project? Um so there's two things that you're going to need. One is the developer portal and one is the 1in SDKs. So let's quickly talk about the developer portal. So, this is the official hub for integrating 1-inch into your projects, however you're going to do that.

Uh, you're going to get your 1-in API access key from here. You're going to get your documentation for all of our APIs as well. Uh, no, swap APIs and other APIs, which we'll talk about briefly uh toward the end. And we will also have examples there as well. So, this is the website portal.

in.dev. Don't worry about keeping track of any of these links. There will be a link at the very end that aggregates all this for you. Um, this is the portal.

You'll go on here, you sign in with Google or GitHub, and you get your access to your API key. You can see metrics as to how you're using the system. Uh it's all kind of on here. And then as well as links to all of the documentation and uh REST API calls. Uh make sure if you're doing anything for the hackathon uh this weekend to use the hackathon signup link that I will be sharing at the end because that skips the whole onboarding process including KYC and everything else.

Uh the other piece to doing this is going to be the 1-in SDKs. Uh we have multiple SDKs that interact with our APIs and they are written in both Typescript and Golang. Uh for the hackathon because of some recent changes we did, make sure to use TypeScript this time, but Golang usually is functioning as well. Uh the next thing we want to talk about is uh front end frontend requests to the 1-in APIs require a proxy. This trips a lot of people up so it's worth calling out.

If you have some sort of integration with a swap modal and you have one-inch API giving you uh quotes and also executing swaps for users like most DeFi pages look and you try to make a call to the 1-in API directly, this will fail and the reason for that is uh we do not want people linking uh leaking their API keys for other people to sniff with just network tools and then to use outside of the website. So this will get blocked with a corores error. You'll have JavaScript errors. it'll be very confusing and it's basically just saying that you cannot do requests from browser to the 1-in API directly. So to get around that you need to use some kind of proxy something that kind of masks that API key that would normally be accidentally shared with any user that's going onto your website.

Once you have that proxy in place that will eventually talk to the 1-in API and then you can do anything you want after that like smart contract calls with the call data. Uh to do this, to make it as easy as possible, I created a uh project linked here, which will also be linked at the end, so don't worry. And what it is is a cloud hosted proxy for all of your 1-in API requests. So this is just a super lightweight JavaScript proxy that you can deploy to Verscell uh pretty easily. And then instead of talking to the 1-in API directly, you're going to be talking to this proxy.

This is an example of what the readme looks like. It holds your hand through the whole process. Okay, make an a free account on Verscell. import this GitHub project into your versell project, add your API key, and then talk to it. So, it's really simple, takes just a couple minutes, and uh is really this is a really important step if you're going to work with 1 in in any capacity.

Uh like I briefly said earlier, uh there are a lot more APIs that 1in offers than just swapping. Uh we tried to make a whole suite of APIs that would make it as easy as possible for people who want to make DAPs just using a more web two approach. So these are all rest API based things that get a lot of onchain data for you. Uh so briefly we should talk about the bounties as well. So we have fusion plus which is the main one crosschain swapping that's $8,000.

We have portfolio API as a category as well. Um and that's going to be $6,000. Um and this is basically just saying hey go build anything that's kind of a visualization for users portfolio balances wallet performance anything like that. And then the another one is uh the last one is using fusion which is just intent swaps that's not crosschain classic swap or any of the other one inch APIs. There's a lot of them.

There's like nine or 10 I think. And yeah that's everything for me. Uh and yeah here's the link that I talked about. It'll give you basically hackathon information, bounty information, example project information, all of that. And you can talk to me uh at the booth or anybody else from 1 at the booth or after this.

I I can answer all your questions now. But yeah, thanks [Music]