[Music] So, I'm Matt and I work on the strategic partnerships and developer relations team here at 1. And today we're going to discuss crosschain swaps and beyond. So, a brief overview of what we're going to discuss. We're going to talk about our classic swaps uh which is our AMM and PMM aggregation. We're going to talk about 1inch fusion which is our intentbased swaps and we're going to talk about fusion plus which is our crosschain autonomous swaps and then we're going to talk about how to integrate these into your project.
So, brief little overview for those of you who don't know, 1 in was actually started at a hackathon back in 2019. Um, and since then, it's grown like crazy. We've processed over $750 billion in total volume the last six years. We've seen 25 million uh unique wallets and we have over 180 contributors around the globe contributing to this project. So, it just goes to show that what you build here this weekend can actually blow up and turn into that next big unicorn.
So let's talk about swapping. Right now uh our three swap protocols are available on these 12 chains. And you may notice that these chains are all EVM chains. Um we just launched on Salana with our Fusion and Fusion Plus and this marks the beginning of our branch into the nonVM world which we'll discuss a little bit later. So let's talk about our classic swap.
This is our bread and butter. This is what was built at the original hackathon in 2019. Um, our classic swap sources swap liquidity from all popular protocols which are basically dexes and AMMs like unis swap, sushi swap, kyber. Uh, we currently look at over I think it's around 400 different liquidity sources. Um, and then we'll combine these protocols to optimize the swap output.
And then once they're combined and we have the most optimal route, we'll execute all of these swaps in a single transaction. So let's look at at an example. Uh in this example, we're look at USC to die. So if a user was to swap USC to die, traditionally they would just go through a DEX. Um in this case, UniS swap.
I think right now unis swap has like 50% of the market share. So it's still pretty commonly used. Um but in some cases, there might be a more sophisticated user or user who is more price sensitive and wants the absolute best rates for their trade. And in this case, it could go through an aggregator like 1 inch and then 1 inch will actually route that trade through unis swap in order to return die to the user. Um, if it's a large swap, uh, the pool at unis swap only has so much liquid liquidity.
So a larger swap would actually cause a negative price impact. So in this case, one can actually route it through different dexes and different liquidity sources and split the trade. So it can go through dodo, can send another part of the trade through unis swap. Um, it could also add more complexity and send it through curve. And then we have this cool feature called connector tokens where it could actually swap the USDC through curve into tether and then take that tether, swap it through sushi um, in order to get die back to the user.
Um, and it can do all three of these different routes. Um, and the route can actually get infinitely complex. It can get up to like 50 different routes like this. We've seen some very large trades that have very high levels of complexity. Um, and so you may be wondering, okay, well, it's getting more complex, right?
So, isn't that also going to increase the gas? And you're right, but we also take gas into account as well. And we we're highly optimized for it. Um, so in theory, if you were to do a swap just directly through Uniswap, you'd spend hypothetically around 205,000 gas. Um, with one inch, we've actually out optimized the unis swap router to be more gas efficient.
So if you swap through one inch and then it ends up routing directly through unis swap, you'll actually spend only 175,000 gas. So it's cheaper to swap through one inch and go through unis swap than to go swap directly through unis swap itself. And so that's our classic swap. Uh the next protocol we have is 1 in fusion. And this is our intents.
And with fusion the user submits a swap with a request with a signature. And then after that the Dutch auction is created for the swap which basically is our order book and it's a it's a unique method of price discovery and at a certain point resolvers will asynchronously compete to fill the order. Uh users are protected from me by design because resolvers who fill the order are professionals and they know what they're doing and how to not get frontun and the transactions are also gasless for users because resolver actually takes care of the gas fees. So the gas fees are baked into the rate for the user. Um so you may be wondering like what is a fusion Dutch auction?
Um essentially it's the opposite of a regular auction and a regular auction starts from a low price and gets bid up higher and higher and higher until uh the highest bid um goes to the winner and that's the price for the item. A Dutch auction is the reverse of that. So the price starts at a high point and goes down over time until it becomes profitable enough for a resolver to fill. So now you're probably wondering, okay, what is a resolver? So a resolver is a counterparty that can participate in this system and fill orders um that are placed by the user.
Um they could be a private market maker, it could be an individual, it could be a company, could be an exchange. Um, basically any any entity that wants to participate in a system that has the technical knowledge and the funds. And so here's a rough overview of what the Dutch auction looks like. Um, on the y- axis we have the rate. On the x- axis we have the time.
And as you see that there's a top left dot which represents the starting price. Over time it goes down. Um and you can each different dot is a different price eventually ending up at the lower right hand corner where the price um is finalized and the order is filled. So let's look at an actual example. In this case we have a user who wants to swap 50 USDC to 50 D on Ethereum mainet.
Um they'll sign an order. This order will then go to the 1-inch API and the 1-inch API will then post the transaction to the 1-inch order book where the Dutch auction commences. So, while the Dutch auctions happening, we have different resolvers that are competing to fill this order. Um, there's a set number of resolvers. I think right now it's it's up to 20.
And so, a couple resolvers can pass. Um, they're basically looking at the order to see when it's profitable for them. Each resolver has their own profit strategy. The other resolvers don't know what the other resolvers strategies are. Uh so there's an element of competition here and a race condition to fill the order before other resolvers do.
Um so in this case um we can have two resolvers actually fill an order. The user has a feature where they can enable partial fills. So um if say in this case resolver two sees part of the order is profitable for them, they can say okay I'm going to take part of this order. another resolver says, "Okay, I'm going to take this part of the order." Um, and they can keep chipping away at it until the order is completely full.
So, here is an actual example of a swap that happened. Um, a very large swap for 3700 wrapped Ethereum to USDT. And you can see the line that's decreasing over time is the Dutch auction curve. And the colored dots are the resolvers that are actually filling the order. And those are the fill points.
And as you can see, there's partial fills happening as the resolvers are chipping away the order as it decreases over time. And it's a little bit difficult to see on the screen, but there is a dotted line at the top which represents the spot price. And there's a dotted line at the bottom kind of where the the red line starts to drop dramatically. There's a dotted line there and that represents the market price. And then at the very very bottom where the the steep red line ends is the absolute min return um which is based on the user slippage tolerance.
So essentially the market or or the order starts at spot price um which is a general price that is basically pulled from like the overall market which includes like centralized exchanges uh like coin gecko prices things like that. It's not just strictly onchain pricing. Um and then it goes down to the market rate which is the actual rate you would get if you were to swap directly through an aggregator like on our aggregation protocol or directly through a DEX. Um so in this case you can actually see that this order was completely filled above market rate and the user is actually able to receive more tokens than if they would have just run this trade through a DEX. So that's actually a really cool feature about this is that um it it highly optimizes prices uh for users.
So then the next question is okay well where do the resolvers get the liquidity for this because we're looking at spot prices which could be on or offchain um and you know they're filling things above market rate right well this is the really cool part is that resolvers can source liquidity from literally anywhere they can fill the trade and then they can settle it on the back end however they want. Um so it could be you know they could be sourcing liquidity from a centralized exchange like Binance or Coinbase. Um it could be their own personal funds. It could be a DEX also and it could even be crosschain. So, you know, if it's a order from USDC and they've got the liquidity on Salana, but the user wants tokens on Ethereum, they can go ahead and settle the order on Ethereum and then uh or fill the order on Ethereum and then settle it on the back end on Salana.
Um, and this opens the door to basically the entire world's liquidity. Um, that includes like RWAS which are becoming really popular this year as well. So this is a a really powerful component of this protocol and like it's why I think it's actually going to be the future of DeFi. So it's like a connection into the Trafy world. So this brings us to Fusion Plus which is an addition onto our Fusion protocol which we just went over.
This is the crosschain edition of Fusion. And when we were building this we were asking ourselves so what really matters users for crosschain swaps. Um the first thing that we really thought about was rates because that's that's our bread and butter. We want users to have the best rates possible for swapping across chains. Second, the simple UX.
Um, a lot of existing bridges have a terrible UX. I think the last time I swapped on Albridge, uh, going from Salana to Ethereum mainet, it took like 20 minutes and I lost some money to fees and like price impact. Um, you know, if you if you're trying to swap out of an optimistic rollup back to mainet, it takes seven days. I mean, that's just crazy. That's like Western Union.
Um, which we're all trying to avoid. Um, so we wanted to have a simple UX and then also trustlessness. A lot of existing bridges have a contract where you pull a ton of funds into um, and you have to trust that it's not going to be exploited. We've seen some of the the biggest exploits in our industry have happened from bridges that are pulling funds together. Um, also a lot of users will use centralized exchanges to actually bridge their tokens as well, which is really risky because then they're handing their tokens custody to the exchange and then waiting for the exchange to send it back on a different chain.
So, we needed a trustless system to facilitate this. So, this is where we introduced hash time lock contracts. And this concept has been around for a long time. Um, I think it was even mentioned in the Bitcoin white paper. Um, but it hasn't really been used yet.
Hashtime lock contracts are essentially smart contracts that hold funds and they require some secret s to unlock these funds and they also expire after a set amount of time. So an example of a general hashlock hash time lock contract is a user has a secret and they can create a hash with that secret um and attach it to a contract and if someone else wants to come and withdraw money from that contract they can't because they don't have a secret. So the secret is the key that unlocks the funds out of the contract. That said, the user can share the key with someone else and then that someone else can go unlock the funds. And that's kind of the core concept of our Fusion Plus and how this how this works.
So let's look at an example. We have the user and it's just like a classic Fusion swap. Uh they're swapping 50 USDC to 50 D um from Ethereum to base. The user signs the order. Order gets sent to our API.
The API then posts it to our order book and the Dutch auction commences. The resolvers will then compete to fill the order. In this case, we'll just say one resolver filled the order. By filling an order, we'll actually create the source chain escrow and the destination chain escrow contracts. And when they do this, they also assign a security or safety deposit to the contracts.
And this is a very small deposit about the amount of gas, which is a safety mechanism that allows other resolvers to come in and fill the order if resolver 2 fails through anywhere throughout this process. And so the resolver creates both contracts on both chains. And then they're able to deposit funds from the user's wallet because the user sent submitted an approval into the escro contract. Then they deposit funds from their own wallet into the destination chain contract. And once everything's good, we have a relayer service that looks at all of this and it's looking at both contracts and it's saying, "Okay, is the correct amount of source chain tokens in the source chain escro contract?
Um, is the correct safety deposit allocated? Have the finality locks passed because there's a there's a finality lock on each contract after it's created to prevent uh chain reors. Has every does everything look good? And if it does, then the relayer will then go to the user and ask the user to share the secret. The user shares the secret with the relayer and then the relayer will then share the secret with the resolver.
This allows the resolver to then unlock the funds from both contracts and facilitate the swap. Um there's an exclusivity period where resolver 2 has a brief amount of time to actually facilitate this and use the secret to unlock both escrows. If they fail to do this, the secret then becomes public to all the other resolvers and this allows any other resolver to step in and actually complete the order on behalf of the failed resolver. So, so it's a sort of fallback mechanism. So, the cool thing about this, it's not limited to just EVMS.
Um, we have Salana that we just launched uh two months ago and that's actually the the basis for our biggest bounty which we'll talk about here shortly. So, how do you integrate 1 into your project? Well, we have a developer portal and we also have some 1-in SDKs. with a developer portal. It's our official hub for integrating 1 in into your projects and it'll give you access to the API keys and we have documentation and some examples that you can use to plug and play into your project.
Uh the URL is portal.11.dev. I'll give you a QR code here at the end so that way you can you can scan it. Um here's a quick overview of of our site what it looks like.
You sign up here. Um, on the dashboard, you'll be able to see your API keys, your 24-hour request, and a summary of all your activity. Uh, here's our documentation site. You can see all the different APIs that we have access to. There's some swagger in there that you can play around with also.
And we also have some SDKs that we recommend using, especially with user plus u because there's a lot of call data involved. Um, so we really wanted to help simplify the interaction here. Um, it's written in Typescript and Golang. We're gonna have more languages available here shortly. Um, one thing to note, um, if you are sending an API request from a front end to our API, you'll need to use a proxy and this is basically to prevent your keys from being leaked in the headers.
So, if you're you have your front end and there's a 1in API, you don't want to do it directly. Um, you basically want to have a proxy and then the API and then you can interact with the contracts. And if you don't use a proxy, you're going to get a corores error or some other weird errors also. And it's kind of confusing because the error doesn't really explain much. Um, so yeah, if like you're experiencing errors, it's probably like a five out of 10 chance that you're not using a proxy.
And our superstar devril, Tanner, actually made his own proxy that you guys can use if you go to this repo. Um, this will also be linked in the QR code at the very end, so you don't have to take a picture of it. and it uses Versell. It's cloud hosted. Um basically it's like a free plug-and-play one-click solution.
So you can just use his proxy um to streamline your whole building process. And also worth mentioning are our other APIs. Um we have spot price API, balance API, we also have a portfolio API which you can use to track your users's P&L. Um so you can see how much money they're losing on their uh meme tokens um or making hopefully. So, our bounties are the nonVM extensions for crosschain swap.
Uh, this is $12,000, our largest bounty. We're basically looking for any implementation of Fusion Plus on a list of non EVM chains. If you go to our bounty page, you can see a full list of what we're looking for. We basically just need you to create two escrow contracts. Uh, one on an EVM chain that we support and then one on any non EVM chain.
Um, and we need to actually see a physical transaction that happened of the funds being deposited into the escros and withdrawn um, with a link to the block explorer. The second one is extending our limit order protocol and this is actually pretty cool. You can build some really neat trading strategies like take profits, stop losses, trigger orders. U, we also have pre and post interactions. So you can build some complex transactions like swapping USDC to Ethereum and then depositing that Ethereum into a as collateral.
You can really do some really cool fun things like that. Um and then the third one is our smallest bounty for $1,500. Up to five teams can win $300 here and it's just for usage of any one of our APIs. So you know if you're pulling a wallet balance or checking some token data or looking at NFTTS um that will qualify you for this bounty also. So, thank you guys.
That's pretty much the presentation. Um, again, here's the URL and here's the QR code that has links to our documentation, our dev portal site, and more. And yeah, if you guys have any questions at all, I'll be out back. And yeah, we'll also be at the booth later tonight, so feel free to stop by. And if we're not at the booth tonight, uh, go to the 1-inch Discord um, and ping the lock because he'll be up all night tonight.
Thank you. [Music]
Automatic transcript — names and jargon may be misspelled.