Across Protocol: An Interoperability Protocol Powered by Intents

The DevNTell podcast allows developers and founders to come on the show and showcase all the cool stuff they've been building. In today's episode, I am excited to welcome Brittany Madruga, who's co-founder of Across Protocol. So Across, if you didn't know, is an interoperability protocol powered by intents, providing its users the fastest and lowest-cost interoperability solution without security trade-offs. If you stick around for today's show, you'll learn all about Across at a high level, including the concept of intents, what makes their architecture special, and how they're currently approaching interoperability in the space. All right, let's get into it.

GM GM, welcome to the show, Brittany. I'm excited to have you on here today. GM GM, it's good to be here. That was a fun intro, I love it. Excellent, awesome, awesome. Glad you liked it. Yeah, so really excited to learn all about Across Protocol here. But before we get into the nitty-gritty of it all, would you like to give a brief introduction about yourself in case folks aren't familiar?

Sure, yeah. I am Britt, I am a member of the Across team. Across was built by the team behind UMA Protocol. I don't know if anybody out there listening is familiar with UMA, but UMA is an optimistic oracle. We are always trying to think of good use cases for the oracle. So Across was actually born as a potential use case for UMA's optimistic oracle for using them for a verification mechanism essentially. So we kind of came up with that idea when bridging was brand new, super hot narrative. We were like, hey, I think we have something here, optimistic settlement for a bridging protocol could be pretty cool. And so that's basically how Across was born. We built it and we shipped it. At the time there wasn't really a word to describe intents, but we have had the same architecture essentially since we launched. We've done one major update, but it wasn't a change to the intent side of things. So now that it has a name, it's picking up a lot of traction in the space and just, yeah, pleased to be here and excited to talk about Across.

Excellent, love to hear it. And we got Manny watching today. So he's the big UMA guy. So yeah, I'm sure he appreciated the shout as well. I guess in terms of how you got started in the Web3 space, I'm always curious to hear how folks got their foot in the door in Web3. If you could just speak on that, it would be really cool to hear. Happy to. Yeah, my background actually is completely unrelated. I come from a background in biology. I kind of stumbled in through the YouTube rabbit hole, I guess, where I was like, what is this blockchain technology thing and why don't I know about it? I actually thought it would be kind of cool to think about how it could be used in like a medical setting in terms of custody of your own medical information and that kind of stuff. That was a pipe dream, we're like a long ways out from that being utilized actually. I still think it's very cool, but that's that was like my foot in the door and then I kind of stumbled in through the community door, I guess, into the UMA realm where I met the Risk Labs team and had really good vibes with them and eventually ended up kind of onboarding as a full-time team member there. Excellent, that's quite an interesting background from biology to Web3, but it just proves it's borderless and permissionless. So if you've got the passion for it, there's nothing stopping you from joining the ranks and that's fantastic to hear. Especially when you work in an anon space, like people honestly don't care what your background is, they care what you're actively doing. Correct. And that was like a cool opportunity, I thought. 100%, and like I said, I love hearing stories like this because you always learn something new. So thank you so much for sharing. I guess in the interest of time, we can get going with the content you have today. So I will pull up the slides and yeah, let's get at it.

Awesome. Cool. Awesome. So there were a number of things we could have called this talk, but I went with "The Power of Intents" because it's a hot topic and kind of is a good high-level overview about what Across is and how to build on it basically and also like why you would want to. So we'll dive in. First question: wen retail season?

So the big problem as we scale, the problem used to be cost, right? Everything on L1 was too costly, so let's have L2s. Now we have 100 different flavors of L2s with like 10 new ones coming each week basically and it is very fractional at this point. It doesn't all talk together nicely. So in order for us to get to retail season ever, we need cheap, fast, secure interoperability so that it doesn't really matter which blockchain you're on. You don't necessarily have a notion of which blockchain you're on, you're just existing in the space and it's cheap and it's fast and it's secure.

So to really drive home the point, like the cheap, fast, secure problem isn't a dApp builder's fault, right? People who build dApps shouldn't be expected to understand the core infrastructure settings of all these different L2s to make them talk together nicely. dApp builders should be able to just exist within whichever ecosystem they want to be on while having the ability to reach users across in other ecosystems, right? So this isn't a dApp builder problem, this is a bridge builder problem. Bridges need to be better in the space in order to facilitate this retail season coming someday for dApps.

So a bit about bridges briefly. There are a multitude of different bridge architectures out there, but one kind of underlying theme of a lot of them, especially bridges who support every chain and every chain's mother chain, is bridges often rely on sending messages from blockchain A to blockchain B. You have to kind of wait for finality on blockchain A before you can get a message sent to blockchain B. And the problem with that is that sending messages between chains can either be slow, expensive, or insecure. You can't eliminate all three of those from the equation when you are dabbling with sending messages. And so we think that there's a better way to do this, which is cross-chain intents.

And so a bit about Across before we dive into intents. Previously we were kind of known as like the best fast token bridge. And by fast token bridge, when I say that, I mean it's a way to transfer value from one blockchain to another, meaning you are actually sending tokens, you're not just sending messages. We really focus highly on the value of sending value instead of going the way of sending messages for like some kind of sync state mechanism. So that was kind of like how we were previously branding ourselves. What are we now? We're still that. We're still a really fast token bridge. Our median bridge time right now is four seconds, which is epic. But we're sort of recently rebranded to what we're calling ourselves an interoperability protocol powered by intents. That's quite a mouthful.

So now let's talk about cross-chain intents. So with intents, rather than sending a message from blockchain A to blockchain B, you have this third-party network of solvers or fillers, in our system we call them relayers. They are looking for events that happen on blockchain A. As soon as they see that that happens, they will execute and fulfill that user intent on blockchain B using the capital that they already have on that chain. Assuming that these solvers are good actors and fulfill the intent appropriately after some short validation window, and there's different mechanisms behind that, we settle optimistically. Others use kind of a consensus mechanism, but after this settlement period, solvers get repaid by a core liquidity pool from the bridge essentially. And so the, let's see, before I go, okay, yeah. So one of the main benefits of a system like this is that the solvers are we consider them off-chain actors and it allows them to be very fast. They can see a transaction on blockchain A and decide how quickly they want to compete for the ability to fulfill the user intent on blockchain B. Within our system, like I said, it's quite fast. People see this in under a second and then fill it in under two or three more seconds depending on the origin chain. But it kind of shifts the risk away from both the LPs in the system and the users in the system, it shifts all of the finality risk onto these solvers where there could be a chain reorganization on chain A, for example, and that would hurt the solvers, but that almost never happens. And so by competing on speed, you're giving users the best experience and that they're getting their funds before this universal sense of finality happens. And they are able to do this many hundreds of times per day and kind of like scale their earnings in that way. So that's kind of how we get around this messaging system. There's still some messaging that needs to happen, but that can be batched and take a lot longer rather than doing it on a per-transaction basis. And so we use messaging as a means to repay solvers rather than as a means to facilitate each individual transaction.

So that was kind of kind of high level, maybe a little bit too much on intents. So here is another easy representation of how we see cross-chain intents. There's kind of a cake layer thing going on out there for those who are familiar. Intents are like a cake, right? Where the top layer is the intent layer, that's where you collect user intents and this happens through a dApp, through a front end. This is the dApp layer where they take user inputs, generate some kind of RFQ, and then the next layer here is this solver layer where you'll have solvers who bid using whatever kind of auction mechanism is baked into that dApp. The solver layers can plug in and bid for the right to solve that user intent, whichever solver wins gets that right and does the thing. That happens at scale many hundreds of times and then periodically you will then settle on the settlement layer and that is kind of the like escrow repayment mechanism. So this is the layer that collects user funds and then manages repayments for the solvers after that verification window has passed. So yeah, that's kind of like a high view of the layers of intents and dApp builders can choose to plug into various layers of this. For example, the Across front end, we define intents, we have our own solver layer, and then we use our settlement mechanism underneath the hood. So a dApp builder could, for example, just like link out to Across and offer this intent system that way. They could create their own RFQ but then plug into our relayers and our settlement system or they could just use us for settlement and bring their own solvers and their own RFQ. So it's like a choose your own adventure kind of thing depending on how far down the intents pipeline you really want to go.

I guess I kind of already went through this a little bit on the last slide. I don't love this slide, it's kind of confusing, sorry about that. But it just kind of talks about like the different intensities of intent, if you will, where in some senses you have like defined input, defined output, you're following the navigation that's built into the app, that's what Across bridge is. For Across plus, you have some optionality on input and output, for example, as a user you show up and you have the option to have different origin chains that you want to pull funds from or something like that. Feels a little bit more choose your own adventure, that's this Across plus thing. And then endless optionality on input and output. The middle part is kind of who knows, that's up to solvers to figure out. That's not the project's problem, that's not the user's problem. Whoever can build me the best spaceship to Mars wins my bid and gets to take the fee to do it. That's Across settlement. That's where you kind of like bring your own, you bring your own party to the party and we just have the house essentially. So yeah, just kind of good to keep in mind as as folks are choosing to build that intents do exist on a spectrum and as you're kind of dipping your toes into building with cross-chain intents, you can kind of think about where you're at as a building team right now versus where your users want you to be at. What's the demand for this in your user base?

So with that, let's pivot and talk about cross-chain intents and why we've been focusing so heavily on this. So today's cross-chain UX is quite miserable. Let's say we're going to go make a deposit on Aave because there's some pool that we really love. So first we're going to go to the dApp, we're going to find the pool that we heard about which let's say it's on Optimism, so we're going to go find the Optimism Aave page, find the Optimism pool, great, here's some juicy APY on my USDC, great, connect to my wallet. Oh crap, I need to switch networks because I'm on the wrong chain. I was just doing something on Arbitrum. Then we notice oh shoot, I don't have actually any USDC on Optimism, what do I do? So then I have to, and this is the worst part for all you dApp builders, I have to leave your dApp and go to a bridge. I have to go somewhere else and move my funds. So I go find a bridge, maybe if I'm lucky you guys might provide me with a bridge tab that will direct me to some trusted choice that you guys have a partnership with or something like that. Anyways, I go there, I do the bridge transaction, I initiate that. If we're not using Across, then maybe that takes like two minutes or so, which is a long time to get distracted. I'm for sure going to go start scrolling Twitter, absolutely got distracted. I have no idea what I was doing previously. And then I never actually go back to the dApp. So I never actually go make my deposit on Optimism in Aave to get the juicy APY on my USDC. That's the UX today. Obviously there are some people with better attention spans, they're going to come back, but there's still that gap in time. There's definitely some turnover on users acquired that way. There's loss of opportunity when folks have to to leave your dApp. And that's kind of the downside of these multi-chain deployment instances that dApps are kind of moving to. They want to be on every chain, they're trying to chase their users to every chain, but in doing so you kind of deal with both liquidity fragmentation of your users and of your pools within the protocol.

But what if it could look like this instead? Where this is a simple deposit functionality within a dApp and then you'll see here on this bottom half of the image, a user can see like a list of available source chains for their funds, for their USDC. And as they sort of click about through each of these source chains, then this wallet balance will update. This shows that I've got 280 USDC on Optimism, perfect, love that. I only need to deposit 200 of that and let's just say that this vault is instead on Arbitrum. Great, this is like an in-app native transaction builder that allows me to bridge funds from Optimism over to Arbitrum while I'm checking out as if the funds were already there. So kind of the power of this to reiterate is it provides some in-app flexibility for users but not a crippling level of it where there's user fatigue and too many choices. And it still aggregates all of the decisions into one place, aka no more bridge tabs, no more linking out to other places, none of that stuff. It's just this is where I am, this is what I want to do and here's my view of my full portfolio of this token. And, you know, one of the other beauties of it is like you define what's possible here. You can kind of limit the input chains you want to see, you can depending on your app structure you might have multiple output chains, that's okay, you can define that kind of stuff. Whatever you think the sophistication level of your users is, you can tailor this front-end design to meet your needs.

And so this image right here is kind of a visual representation of the product that we've been calling Across plus. Across plus is essentially just an extension of our core bridge functionality and I kind of wanted to walk through this as like the core example of how you can build on Across. So Across plus, how does it work? You take your protocol action, whether it's a deposit, swap, buy, etc. You turn the first step is that you're going to turn that into a message. Right now this image on the right here is kind of how it looks today. I gave this presentation on a Mode builders call, so I think everything here is Mode denominated. But today you have a dApp, your user only has funds on Mode that they can see to deposit into your smart contract. So whatever that action is, you're going to take that and step one is going to be turn it into a message.

Step two is you're going to I guess this is actually step zero, I probably should have caught that. But one of the key things is you're going to turn your app into a portfolio view kind of thing. So you're going to enable users to see their balance across all of our supported chains. So typically this is just like a parameter configuration in whatever kind of wallet connect you use and it just will support multi-chain view versus single-chain view. So we're going from here where you can only see funds on Mode to here where you can actually see funds on Mode and every other chain that Across supports.

So next from a user perspective is we're going to be able to present them their full portfolio. Then once we have that, the user will get to sort of pick which which source they want things to come from. This user got lucky in the zkSync airdrop, but they are now going to try and hop on over to Mode and see what kind of farming they can do over there. So they're going to they're going to choose zkSync as their source chain. This gets just converted into a parameter that then they'll use in the next step.

When we call the API well, okay. This is more user-oriented than builder-oriented, but so from step one we have a message that we crafted, from step two we collected some other parameters including like source chain token and amount. Um and then what we do is we take that message and we attach it to a bridge transaction and call the Across contracts on the origin chain, in this case zkSync. And it basically says here's a token payload with a message attached. Once that is filled on the origin chain, please sequence through this series of steps until you get this end result of depositing on behalf of this user into this smart contract. And so for the user, it looks like a simple transaction, one transaction, a one-click transaction where they clicked the source chain, they input the amount, and then they expect their funds to arrive in this destination smart contract all in one go. Under the hood, it's the same thing, but just with a bridge transaction when needed.

It's kind of it's kind of just that easy. So the final kind of thoughts I have before I'll demo briefly is every dApp can take a step in the direction of intents depending on kind of what's best for you. If you're an aggregator, you can just plug directly into our API and kind of consider your own front-end logic and all of that. Across is part of a much larger equation there. If you are a dApp with a small team, maybe maybe you're just at the spot where you can do a bridge tab or a link out. Even that, just like providing a trusted and reputable source for bridging to your users can be valuable. From there, if you decide as a team hey, I'm focused on UX, you can try out something like Across plus where you bake it into your transactions and see how how much more capital you can onboard with a mechanism like that. And then finally, if you are just an obsessed with intents team, you can use Across settlements to facilitate some crazy wild outputs with like standard input kind of stuff. So that was a lot of rambling. Now I figured I would do a quick demo both on how we do it and then I'll show you how it looks with Umami, they use Across plus. We still have time for that, are we still on time? Yeah, yeah, we're good for time. Yeah, go for it. Okay, cool.

So I will go ahead and share my screen. Okay, beautiful. Can you see my screen okay? Yes, I can, yep. Okay, excellent. So here's the Across app landing page. And for this demo, I'm going to send some USDC from we'll go from Arbitrum to Optimism. And we'll switch, we'll say USDC amount let's go ahead and send 50, we'll send an even 50. And so you can kind of see down here in this transaction breakdown, um I didn't talk about rewards, but we do have gas rebates that we offer on all OP Stack chains and on Arbitrum right now. So the goal behind that is just to try and get folks into whatever position they want to be for like a net neutral cost as much as possible. But the thing I wanted to highlight here kind of our main value prop on this cross-chain intents model is speed. They're going to quote us five seconds here. Let's see how it does. So I'm going to switch networks real quick to Arbitrum. Confirm my transaction. Quick gas pop-up, confirm. Okay, here goes our timer. Okay, great, and now it's already done.

I'm not sure, did you guys catch that or did it switch screens by any chance? No, no, we caught it. It was less less than the five seconds it quoted, which was pretty sweet. Yeah, yeah. We try to we try to quote on the high end whenever possible. I was expecting it to take at least two seconds, but oh it did total time of two seconds. Cool. So yeah, and that's it. So in that amount of time my deposit initiated on the origin chain, which is this deposit time here, and then it filled in another one second on the destination chain. And again that's all facilitated by these off-chain actors who see my deposit and then immediately fill it and they are incentivized to compete on speed within our system and as you can see that kind of pans out nice nicely. So um that's the quick demo for how we do it with Across.

Now let me present one more tab here. I want to show you how the Umami team has chosen to integrate Across into their UI. Beautiful. We have it up. Okay, excellent. Um and so Umami has a system of vaults. I'm currently up on the page where you can deposit USDC into their vault. And so I am going to go ahead and switch switch wallets here. There we go. Okay, um let's see. I like the ETH market better, so we'll deposit that. And let's just see like okay, so on Arbitrum I've got 27, Ethereum I've got 24, OP I've got quite a lot because I just did that bridge transaction over to Optimism. I don't think I'm going to beat that anywhere else. I don't I don't do as many demos on these other chains. Okay, cool. So I have the most on Optimism, we're going to pull from there. Let's go ahead and do a 50 dollar deposit. Cool. Um and so here's their little preview. You can see their breakdown is similar to ours. Here's their bridge fee, execution cost, that's specific to their protocol. Um it'll show me how much I'm going to receive here. And then now it'll prompt me to switch chains again and we can deposit.

Click a quick confirm in my wallet. Cool. And let's see how long this this takes. I actually haven't used this Umami vault before, so we're discovering this in real time together. Awesome. Awesome. Yeah, I just got a confirmed pop-up on Optimism, so my deposit at least has been initiated. That's a good first step.

And I guess while we're waiting, the UX that you were showing before both in the Across demo and here, is there like a pre-built component people can just like pull in to have this slick UI or are they expected to kind of build it themselves and plug into the back end to enable all of this? Good question. Oh cool, there we go, looks like we have some progress. Sorry. So we don't have any widget functionality as of yet. We're kind of doing some market research to determine if that is actually in demand or if people really prefer to do their own more like custom implementation with this, kind of like how Umami has done here. So right now the only resource that we can offer is the API. But we do sort of like on the other hand is we try to offer some like white glove attention to people who want to integrate with us and try and support bring that like custom integration to life in the best way possible for them.

So widget maybe soon, hopefully. I'd like to see a widget, but we'll see. For now, just like 24 hour support from us. Awesome, awesome to hear. And what about yeah, sorry, go ahead. Oh I was just I was just checking back in on the other screen. It's seems to still be pending, which is not a great look. Maybe I should pick a different project for the for the demo next time. That's the demo effect, it always happens that way. It's alright, it's alright. This is not the first time. Not the first time. Not the first time things like this have happened on the show. That's the nature of live demos.

But a follow-up question I had was what about fiat support? So imagine somebody who doesn't have any crypto to start but they want to start playing around. Do you envision or do you have any native fiat-to-chain support built in in the back end or are you planning to?

Um we don't as of yet. It's something that we occasionally talk about, but fiat on-ramps are starting to add more and more L2s. So um if you need funds on a specific chain, you almost can just like go straight through that fiat on-ramp provider to get to that chain. Now it would be cool to kind of see well, yeah. Maybe for like some of the newer chains it would be kind of cool to see that type of integration where they could um on-ramp onto like Optimism or something like that and then directly plug into the bridge to reach Scroll. I don't know if Scroll has any fiat on-ramps yet. Um but so far no plans in the works just because it's kind of unclear what the market demand for that is and like if that would actually be beneficial for us to beat these fiat on-ramp providers to that if it's like a functionality that they'll add eventually. There might not be a whole lot of like either market demand or a whole lot of value for us to create that kind of integration. Fair enough, fair enough.

In terms of content, do you want to switch back to the slides or do you want to entertain some Q&A from the crowd? Oh yeah, let's switch back. I think so we did some demo, there we go. Um let's definitely do some Q&A, but this is kind of my final slide. Just keep it up in case people want to screenshot it or whatever. But getting started, um if you want to explore the use case a bit more you can book a call directly with me or message me on Telegram, I put my username here. If you're looking for some resources, I linked to our technical docs as well as our Across plus landing page, which is just like the prettier version of that. Um and yeah, happy to answer any questions. Awesome.

Yeah, and we got some good ones from the crowd here. Nik K asks, "How do you see in-dApp fungibility being solved longer term? i.e. bridged USDC via Across is different to the USDC version of the pool."

Hmm, okay. Um yeah, USDC is a particular kind of problem. Um I think one of the cool things with intents is that you can kind of work around the need to build in a native swap mechanism. Right now if you want to have a different flavor of a token, you have to include um and aggregators do this as well, right? So they'll either do like an origin chain swap and then a bridge to whatever token or they'll do a bridge and then destination chain swap to whatever token. Um if you're using um something like Across settlements, you can just specify input token is this, output token is this, um and then the solvers are the ones who sort of like take on that swap risk. They kind of have to price in a a variety of things like one, um once they receive this origin token, are they actually going to go through the pain of swapping it to get back to whatever they were originally using on that fill or are they happy to just receive that input token and then turn around and and use that to solve or fill another another request, something like that? So each individual solver can kind of like choose their rebalancing preferences, I guess if you will, to help facilitate these things. And so ultimately I think for users, this idea of fungibility is going to become almost negligible, I think. One because they're going to always be like a direct peg in value and two because CCTP is pretty prevalent and it is like used by a lot of both protocols and solvers for rebalancing of USDC where needed. So yeah, I think the barrier to entry into different flavors of tokens is going to go down.

Excellent, awesome answer. And great question, Nik. Next question we have here, um I guess this is more of a refresher but Thijs van Boven asks, "So Across is mostly on the solver and settlement layer?"

Yeah, good question. So Across bridge is sort of like our dApp product that uses all three layers, where it's like our RFQ mechanism, our solvers, our settlement. Other people who maybe want to build on top of Across, they would be building it in such a way where it would leverage our solver and settlement mechanism probably, unless they were just going to link out to the bridge, in which case they would be kind of utilizing us at a dApp layer as well. But for the most part, if you if you're tacking on like custom messaging or anything like that, um then you're sort of creating your own RFQ implementation within the dApp, plugging into our solver network, and then leveraging our settlement mechanism.

Excellent, great to hear and great question, Thijs van Boven. Next question, Nik asks, "Also - when BTC bridge which could be considered 'native' BTC, not wrapped?"

That's a good question. Um it is not our next priority. Um we have a couple things in line ahead of that I think. But we did get quite a lot of traction recently at ECC asking the same question essentially. And so it's something that we are cognizant of and thinking about how to how to address. The biggest upcoming expansion for us is going to be continuing to support all OP Superchains, adding support for all of the Arbitrum Orbit chains, and then hopefully in the next three months, knock on wood, we'll be able to support bridging to Solana, which is something that has been a big demand that we have not previously been able to fulfill. So a couple a couple of other big additions before we get to BTC, but hopefully it's worth the wait.

Beauty, beauty. Love the sounds of that. And final question before we wrap up, any plans to launch a wallet with Across built in? Or not on the roadmap?

No, I think um rather than trying to be really good at building a wallet and really good at running a bridge, uh we'll probably leave wallet building to the wallet providers and see how we can best support them as an integrated bridge product. Um and so whatever that looks like, I know like MetaMask has a specific bridge function, that's fine. Um if we're going full intents on this, we actually would rather see less of that and more just like direct transactions that have bridging baked in. But whatever wallet providers kind of want to do, we will support them um in in all of the routes that we can with Across functionality.

Excellent, love the sounds of that. And with that, and great questions everybody. Those were fantastic. With that, unfortunately that brings us to time. But this was an excellent overview of Across. Thank you so much Britt for coming on taking the time out of your day to give us this awesome overview. Yeah, thank you for having me. It was a lot of fun and thanks everyone out there for the questions. Hope to hear from some of you in Telegram. Yeah, definitely. And gang, be sure to scan and reach out to Britt and the team if you have any questions or want to get Across Protocol integrated in your dApp today. Um and with that, just want to wish everybody a very happy Friday. Happy weekend wherever you may be and uh we will catch you on the next episode of DevNTell. All right. Cheers gang. Cheers. Thanks Narb. No problem.