Blockchain bridges today handle about $20 billion in TVL. They are crucial infrastructure for the realisation of a multi-chain economy. We are joined by Arjun - a researcher from LiFi in today's episode. LiFi offers integrations that help developers make their products multi-chain ready. Arjun breaks down the challenges of running bridges, their business models and how aggregation theory applies to the product category. Listen for context on one of the fastest growing sectors in Web3.
Blockchain bridges today handle about $20 billion in TVL. They are crucial infrastructure for the realisation of a multi-chain economy. We are joined by Arjun - a researcher from LiFi in today's episode. LiFi offers integrations that help developers make their products multi-chain ready. Arjun breaks down the challenges of running bridges, their business models and how aggregation theory applies to the product category. Listen for context on one of the fastest growing sectors in Web3.
Hi, this is the Deco Podcast and I'm your host, saurabh. I am joined by my co-host, joel today, who is a co-founder of Deco. Today, we are thrilled to host our guest, arjun, who is a head of research at Lifehack. He brings a wealth of experience as far as the bridges in crypto are concerned. We will talk about all things bridges, right from what they are to why aggregation makes sense in this space. If you've ever tried to take your assets from one chain to another, you've most likely interacted with some sort of a bridge. Since blockchains do not understand the world outside of them, the process of taking assets or information from one chain to another is complicated. Let's jump into this conversation and pick Arjun's brain and try to understand what happens behind the scenes Before moving on. Deco members or guests appearing on the show may own assets discussed here, and none of what we say is financial advice. With that, let's begin with Arjun's intro.
Speaker 2:Hello, thanks for having me. I am Arjun. I'm head of research at LeFi. I've been working in the crypto space for almost three years now. I've always worked in research and marketing related roles. I started working with the fund house for their research needs we were basically generating crypto assets and then I worked with a digital asset management company based in South Korea. So, yeah, I've been writing long-form research for a long time now and I joined DeFi in October 2021, before all the hype around Brid bridges. So we got a good head start in the niche and, yeah, I'm excited to be here.
Speaker 1:All right, let's start with the basics. Arjun, can you just explain what a bridge exactly is?
Speaker 2:Yeah, so I think, like you mentioned in the introduction as well, blockchain. They exist in silos. They cannot really talk to each other, so bridges were built to overcome this and then, at the core, it's like it's about sending messages or like communicating with a communication between different chains, and the most adopted use case has been token bridges, which is why there's like a lot of confusion around the term bridges as well, and I'm sure we'll get into that.
Speaker 1:Right yeah.
Speaker 2:I mean. So it's like because these chains cannot, kind of you know, read what's happening on the other chain, like, how do you convey to Ethereum that something has happened on Solana, right? So this is where the bridge comes in, saying that, okay, there's a transaction that has taken place on Solana and the state of the chain has changed, so you need to now know about this updated state of the chain and then make changes accordingly.
Speaker 1:So do we want to start with different types of bridges now? I think that makes sense right at this point.
Speaker 2:I mean yeah. So in terms of types of bridges, like I said earlier, we have the token bridges, which are the most popular right, so all your connects hop across target. All of them are token bridges. They are also called liquidity networks and they're basically used to move assets from one chain to another. And then we have something called messaging bridges, and these are the bridges that are, you know, responsible for sending messages across. Now, sometimes there's confusion between these two types, because some of these token bridges are built on top of messaging bridges, so there's there's often confusion. And then we also have, like nft bridges, but they're not seeing as much adoption, so I would say it's very experimental in the nft bridging niche. And then we're also seeing coin bridges coming into the market. So there are very use case specific bridges as well that have come up, like the stablecoin bridges.
Speaker 1:Why is that the case, though? I mean, why do we need use case specific bridges Like can't there be generalized bridges for everything?
Speaker 2:I mean it's kind of the sales and marketing purpose, right, Like you have these messaging bridges that can do everything, but then how do you convey to the user and to the developers that what is a bridge supposed to be used for, like the main use case around it? So when Circle decided to kind of build this on-chain protocol for moving around USDC natively across chains, they didn't actually market it as a stablecoin bridge. But for better understanding, I think we've termed it a stablecoin bridging because it's particular to just USDC as an asset and it doesn't apply to anything else in the ecosystem.
Speaker 1:What do you mean by moving USDC natively?
Speaker 2:So it's because Circle is the stablecoin issuer behind USDC right, so they have permission to mint and burn USDC on other chains. So if you were not using Circle's CFTP, it's likely that you would be using a wrapped version of USDC right. So natively is basically like the original asset as conveyed by the chain, as conveyed by the stablecoin issuers.
Speaker 1:Okay, but is there a way for a user to understand that on the new chain or the destination chain?
Speaker 2:Yeah, so it's like it'll be mentioned as USDC coin. Like there was all this confusion around Circle launching on Arbitrum recently. The existing version that we've all been used to is actually the USDC that has been bridged from Ethereum. And then, because Circle is now launching CCTP on Arbitrum, the agreement between Circle and Arbitrum is that Circle's version of USDC will be the native version on the chain. So there has been a bit of confusion for users, but at the end of the day, it's like if the chain decides what's the native or the original version, everything kind of follows. But it's the initial phases where there's a lot of confusion.
Speaker 1:Okay, I want to ask a generalized question from a developer's perspective. I mean, we can go either from a bridge developer or tap, like whichever you prefer to tackle it first. I mean anything okay. So when a developer decides, okay, I want to build a bridge, what does that process look like? Where does he start?
Speaker 2:and yeah, we just take us through that journey I think first would be deciding what type of bridge you want to build, right. So if, let's say, you want to build a token bridge, you have different options because there are different designs that you can choose. So one is like you can bootstrap liquidity and essentially create like a liquidity network where there is actually no bridging involved. It's just like LPs and users interacting on different teams. So that's one type. And then you can also build a token bridge on top of a messaging bridge. So let's say, you want to build a token bridge on top of layer zero, which is stargate right, but there are other token bridges instead.
Speaker 2:So you it kind of depends on, like, what type of bridge you want to build, and then you will want to like the final details of design mechanics, then chains you want to build, and then you will want to like the final details of design mechanics, then chains you want to support, and then, based on all of these things, you have, like this, design choices of based on, like, the interopter term that was like coined by arjun guptani, founder of connects back in I don't know 2021.
Speaker 2:So it essentially states that when you're designing a bridge, you have to optimize on two characteristics out of three. So the first one is trustlessness, which is basically how secure your bridging solution will be. The second is extensibility, which basically means the ability for the bridge to be supported on different types of blockchains. And then the third one is generalizability. So generalizability is like can the bridge handle messaging or cross-chain data or not? So all of these are design choices and then you kind of go into the details of, based on your principles, how you want to build the bridge, how secure you want it to be, what chains you want it to be on.
Speaker 1:Yeah, I mean Trillium is a good segue, right? I want to understand, like when you are trying to optimize for two. Firstly, I mean, why is it that you can optimize only for two? And second is, how does optimizing for two leads to the third property being compromised?
Speaker 2:yeah. So let's say so. First of all, like the trustlessness trustlessness aspect and the extensibility aspect, all of these are a spectrum right, like there's no one way to do it, even within these categories. Like you can build the more secure bridge or you can build like something less secure and then optimize for the other. So let's say you want to optimize for trustlessness, which is, you want to build the most secure bridge out there. So your goal is to, at the end of the day, rely on the security of the underlying blockchain.
Speaker 2:So one example here is like bridges that use like clients, like IBC optimizes for security, but then the trade-off here is that you cannot easily support other chains outside of, like Cosmos chains with IBC, because it's like harder to build like clients on these chains, right?
Speaker 2:So once you like start optimizing for one factor, and especially when you're optimizing to the extreme, like IBC is one of the most secure bridges because you're building like client, that's when, like the other factors, kind of traded off. So let's say, but if you fall somewhere in the middle of the spectrum, which would be, I would say, in the trustlessness aspect, at least it would be, let's say, you set up a validator, set and have economic incentives to ensure that they do not collude right. So setting up a validator set gives you enough security in the eyes of many and then it also gives you the ability to kind of support different chains pretty easily. So when you compare validator-based bridges to like client-based bridges, like it'll become like much clearer why you can only optimize for one and then why the other is traded off.
Speaker 1:Can you explain what a light, client-based bridge is?
Speaker 2:I mean. So it's like you want to rely as much as possible on the security of that chain, right? So you set up your bridge in a way that the other chain is basically able to read the state of the, like the destination chain is able to read the state of the source chain. So you're not relying on validators to kind of verify transaction but the message has been sent, like the details of the message, but you're just relying on, like, cosmos validators and Ethereum validators, which is the best way to on it, which is like the greatest security you can offer.
Speaker 2:No, so it's not as easy to write smart contracts for this, right, so it's like it was done within the Cosmos ecosystem and then to kind of like that's the whole problem with IBC. We want IBC to expand beyond Cosmos, but it's not so easy to write, like these Lite clients on Ethereum. Or like, write this code for these Lite clients on Ethereum. So, similarly, like, if you want to expand this same concept to other Ethereum chains, it's going to be expensive, it's going to be very complicated. There are only three or four live implementations of these natively verified light client.
Speaker 1:Can we break down verification? I understand that there are different ways of verifying, right? Can you just tell us what we are verifying and different ways of doing it?
Speaker 2:yeah, so you, you're basically verifying the transaction, right? So at the end of the day, with every bridging system like the security of the bridge kind of comes down to who is verifying the transaction in the in the system and then this type of verification can be broken down to who is verifying the transaction in the system. And then this type of verification can be broken down into three types broadly. The first one is the one we talked about now with IPC, which is the natively verified verification. So you're basically using the underlying chain validators and they're highly secure, highly trustless. Users are basically relying on the Cosmos sub-validators for the security of their transactions. And then the second type is externally verified, where these bridging systems are like spinning up their own validator sets. So the security of user fun comes down to the actions of these validators, right? So these are considered less trustless because the users have to rely on a third party and most regions in the ecosystem today are using validators like Womhole, axelak. All of them are using validators to kind of verify transactions.
Speaker 2:And even in this type of validator category there are different ways to ensure security.
Speaker 2:Like some have slashing penalties, some have economic incentives involved. Type of like validators, that category that there are different ways to ensure security, like some have slashing penalties, some have, like economic incentives involved, like there's enough fees being paid out to the validators, like warmhole also uses this concept called proof of authority, which is basically saying that the validators care about this, care about their reputation in the real world, so they will not concede. So yeah, there's a lot of detail in this particular section and most bridges are using external validators and the third type would be locally verified. So this is kind of applicable mostly to the liquidity networks or token bridges, and in this type of verification you're relying on the parties involved in the specific transaction. So you're essentially relying on the LPs acting in good faith, because there's again taking all the incentives involved. So some of the examples of protocols like Connext used to have atomic swaps, like the legacy version of Connext, and then today protocols like ThorChain are using this type of verification and then today, protocols like Thor chain are using this type of verification.
Speaker 1:Right, and are these three different verification types targeted towards specific users? I mean, is there something like okay, this type of application needs this kind of verification?
Speaker 2:Yeah, so I would say the natively verified like it optimizes for security, right? So, again, whatever use case that needs the most security, the best type of verification is this one, because that's a cross-chain governance. You need the message to pass security every now and then. You would prefer having, like, a natively verified bridge, but more often than not, these type of bridges are not available because of the lack of extensibility. Right Like it's hard to build these type of bridges. And there's externally verified bridges because they have their validators in place, they can do all of these things like much faster and cheaper. So that's why it's also like it's also easier for bridge teams to go to market with these type of bridges. Like if you were to build a natively verified bridge, it would take a long time and a lot of like resources to build it out. But externally verified bridges are kind of easier to spin up but they're definitely like very difficult to maintain and like ensure everything is in check. So I would say things like use cases, like pretty much everything that we're seeing these days, right, like yield platforms, nft projects all of these are using externally verified bridges because they need like high frequency messages to be passed and like for a lower cost. Yeah, I mean, like I said, most of the bridges in the ecosystem these days are externally verified bridges, right, and they're seeing billions and billions of dollars of volume. So multi-chain has seen consistently, like for the last one or two years they've done a billion dollars of like monthly volume and then Stargate has also been doing like hundreds of millions of dollars of volume.
Speaker 2:So because mostly all of the bridges are externally verified, I would say the volume that they kind of facilitate is also very, very high. So like they're basically making money as like protocol fees most likely. Then they're paying LPs and then they're also taking a cut the fees, the message, the value capture in terms of messaging bridges is more complicated. Like when it comes to tokens, you can always slap a face on the protocol, but when it comes to messaging, some of these bridges charge for a message but then the value capture is not that evident. I would say so if you put $100,000 as an LP on multichain, you will of course have an interest on it and the users are paying for it. So the user at the end of the day is paying for the LP fees plus the protocol fee to MultiChain for like kind of making this possible, like setting up LPs, enabling them to rebalance across chain, making the service available to you. So MultiChain is paying out LPs and then charging you for this convenience.
Speaker 1:As far as these fees are concerned? Is it like it is a race to the bottom because we are now seeing central bridges come up, or how do you see this model changing in the future?
Speaker 2:I mean so far token bridges. Right, the fees have certainly reduced, but then we still see most of these bridges charge a fee. So like earlier, they were charging a higher premium, I would say, but then the fees are still there today. But for the monetization in terms of aggregators it's much harder Because when users are using aggregators they are already being charged by the bridges, the DEXs. There's gas fees involved, so all these fees add up and then if aggregators also charge a fee, it could get you know, excessive for the user.
Speaker 1:I mean, this definitely is a good segue to talk about aggregators, right? So before getting into their business model and like, yeah, why do we need them? Why are aggregators necessary as far as bridges are concerned?
Speaker 2:Yeah. So I think it all kind of ties up nicely with the interop dilemma, right? So because there are so many ways you can build a bridge and so many different types and flavors of bridges, what we've seen over the last two, three years is that there's no one type of bridge that's kind of superior to the other, right, each bridge type has weird trade-offs and thus they have unique strengths and weaknesses as well. So as an aggregator, you can, I would say, make the most of the strengths of bridges and kind of limit users' exposure to their weaknesses. And then, other than just the access to different bridge types, you're also getting better access to, um, like better access to all these different sources of liquidity. Like, at the end of the day, they're just sources of liquidity, right?
Speaker 2:So if, as a user, all you care about is your transaction being executed, aggregators kind of pull all of these sources of liquidity together and make sure that you get the best way, and some other points would be like. So bridges also are limited in terms of, like, the number of chains they support. Like, most bridges support something like six to ten chain. So once you aggregate all of them, you can pretty much have like improved connectivity across chains and you have all of this available on one interface as an end user and for developers. You can just tap into, let's say, defi's API or SDK and then you get access to all these chains, all these assets, all the different bridges. So it's like, at the end of the day, you have reduced complexity for the builders and the end users.
Speaker 1:So just to check my understanding, does it mean that, let's say, a developer wants to tap into liquidity of several chains, so instead of trying to integrate all those chains, they just plug into leefire, they are sorted yes, so you, as soon as you start building on top of leefire, you get access to like 20 avm chains and then liquidity from 12 bridges, uh, 25 dexes, five dex aggregators.
Speaker 1:So we have a bunch of like these liquidity aggregators, like we're essentially a liquidity aggregating okay, and like what are the similarities or differences between, say, aggregators like one inch who are aggregating spot next market?
Speaker 2:So the similarity would be in the routing algorithm. Right Like at its core. Every aggregator is trying to find the best route to execute a user's transaction, so the routing algorithm is common across aggregators. This algorithm filters different factors like speed, slippage, security, and then it ranks different routes and then recommends the most efficient route. So that's something that's common across AmpliGate.
Speaker 2:And how are they different? The difference would be, I think, because bridges are inherently spread across chains, right? So the difference is maintaining all of these endpoints and and integrations. I would say so more complexity yeah, it's like it.
Speaker 2:The the complexity adds on pretty quickly, like when you're on a single chain, like aggregating all the different texts. It's much easier because, like you're the same developer environment, like the programming language, virtual machine, like everything is the same. But then as soon as you expand your scope of maintenance and integrations to multiple screens, the code complexity, how your backend scales, like everything, increases in complexity.
Speaker 2:So like when we try, like personally when I have tried, so it's not just convenience for the developer, right, it's, it's convenience for the end user as well. Because let's say, I'm an end user and I have assets on six chains and I can't even keep track. So as an aggregator, you kind of provide them this one interface where they can manage all of their assets, move them, yeah, like, move them across chain and then, even when I'm a developer, kind of integrates levi. They are enabling this bridging functionality within their application. So for the end user, it's just a much better user experience rather than having to, like, go out, figure out which bridge to use. Does the bridge support the token I want to bridge? Does the bridge support the chain I want to bridge to? They can do all of this, like within the same application, but they're already comfortable let's say that I'm a user and, like current ux is.
Speaker 1:We all know that it's close to where it more where we want it to be. Let's say that we want a simple interface for a user. They want to say, swap it for some nft on, so dollar right from a single dashboard and you just show them the fee in dollar terms and transaction gets executed with one or two clicks from the user. Like what needs to happen for this to be materialized. Where are the roadblocks at the moment?
Speaker 2:I think so. It's like the specific example that you mentioned, right, which is basically purchasing an NFT from the token that you have. Right, so the building blocks are already there. It's just like we're limited by our own imagination. So the exact flow that you've talked about, right now at Leefive we've built something called the NFT checkout flow, which basically allows users to pay for an nft with any token from, like, any chain right, so the building blocks are there is just limited in this in the sense that I guess it hasn't been adopted as much, and that's also because, like, there's limitation in terms of how fast or how easily we can enable this. So how LeFi enables this right now is through two bridges Connect and Stargate, and then, as soon as more bridges enable this functionality, we'll be able to also have better product processing. So, as soon as all these dominoes start falling in place, which is like, okay, more bridges support this functionality, lefi supports more of these type of bridges. This type of tech gets adopted by nft marketplaces. Then the benefits would would come down to the user.
Speaker 2:So, and I think that, like, the specific flow that you've talked about is also pretty new, right, like the technology has been out for only three or four months. So it just takes time, I would say. And then everyone is pretty comfortable with, like you have to sell them the vision of how your application would change, and many applications are hesitant to make such changes. I mean, it's like too evident. Right like 12 months ago people were hesitant about expanding to different chains, but but now that's a no-brainer, that's like an industry standard. So similarly, right now people are hesitant to make new changes to their application, but then as soon as you start seeing like a MetaMask enabled bridging within the wallet, it becomes like industry standard and then everyone starts adopting it. So it just takes time.
Speaker 1:I also want to understand different sets of complexities that are involved with evm and non-evm chains, and while you're explaining, just please start with what evm is and then, like, build on top of it I mean.
Speaker 2:So I think evm is like this common virtual machine that all of these chains that are popular right now are connected with and that's why building on top of these chains is easier. Like there's like this common dev tooling that everyone can use. So there's like a lot of standards that have been built which makes development and doing anything across all of these chains easier, because they're using this common virtual. Like vm, vm right and then cosmos is built on totally different standards. So like we kind of club all of them as non-evm chains because, like, every set is built on different standards and that's why, like, enabling connectivity between these different sets of changes is much harder.
Speaker 1:Right, and so that's what it is right. So typically we see, let's say, a bridge from Ethereum to Avalanche, which there are plenty of bridges, but if we look at bridges to Solana or Cosmos, there is a limitation in number, as well as, at times, liquidity issues as well.
Speaker 2:Yeah, because both these chains have different consensus mechanisms, programming languages, so it's much harder for teams to have expertise in both these languages and the skills required to build are totally different. So, for example, one of the teams launched support for Solana last week and they've been building connectivity for Solana since week and they've been building for Solana like connectivity for Solana since the last two years. So it takes just a lot of time and it's very complex. Yeah, it's just like the users that these applications serve are on different chains, right, and these applications are also inherently on like. Let's say, most of these applications are on five to six chains, mostly EVM chain. So basically, whenever a product integrates key on like, let's say, most of these applications are on five to six chains, mostly evm chain.
Speaker 2:So basically, whenever a product integrates lefi, they're not really doing anything new, but it's just like they're making the ux simpler. Like the user was already bridging but they would have to go outside the application and then do the whole process of like finding a bridge and like all of those steps. Right now they can just like do all of this while staying in the in the same application. So what benefits our partners are seeing is basically like an improved ux and then, because of that, like more, more volume on the platform. Right, because, like the user is just staying on the same platform.
Speaker 1:Yes, it's like it's making using their product less complex like I want to switch gears a bit here, arjun, your article. It mentions winner takes all tendencies within crypto. Right, and you say that a leader in a particular segment will either become an aggregator in that segment or be challenged by an aggregator. Right, but like, if we take an example of uniswap and one inch like that doesn't seem to be the case, right? So how do you explain this?
Speaker 2:I mean yeah. So I think the reality, like all of us know, aggregators do not dominate any. Any niche in crypto right now right, like you said, even with dex's, uniswap leads over a one inch or right, and and the same is the case for bridges as well. So in the article we mentioned that this, in our opinion, is because of like how only, or like how nascent this, this industry, is. So people use an application, they the application works, they like it and then they like tend to stick to it, right. So generally, let's say, a user comes into the ecosystem, they start with one of the blue chip products, like Uniswap, and it just works every time and then they never go try anything else because they don't feel the need to use different things. And being in this ecosystem, we know that how difficult it can be to just explore and you're exposing yourself to more hacks. So the user just feels more secure sticking to one application and in general, we think that as time goes on, aggregators will also kind of improve their offering and become more complete in the future and then things will play out similar to how they played out in Web2. So in the article as well, we looked at some of the big name aggregators in web2, right, and on average it took them around like 11 years to become successful in their niche. So in crypto as well, it it will take aggregators some time to, you know, eventually come out on top, just like they did in web2. And I think, because crypto moves much faster than than web 2, this period will not be as long, with like 11 years. It'll be something much lower, but yeah, I think it'll. It's just like about users sticking to one platform, and then there are also so many times there are like incentives at play, like especially in the bridging ecosystem. We're seeing this play out right now. So all of these bridges are new and they don't have a token as well, so it's very hard to gauge real volumes on airdrop farming volume. So right now, stargate is dominating on every metric possible because everyone wants to farm the layer 0 airdrop and so when, like after, there's like the layer 0 airdrop, it'll be interesting to see the trend in the audience. I mean, yeah, so I was comparing it to 11 years of Web2. So 5 to 7 is exactly in my time. I mean so, yeah, I think winning mean attracting the most volume. I would say, right, because eventually everything comes down to volume and then the fees generated around volume.
Speaker 2:So I think for a player like LeFi that has two areas to focus on, which is one is the direct-to-businesses, the direct-to-application, and then the B2C side, direct-to-customers that are something like Jumper. So with something like Jumper, right, so with something like Jumper, we want to become this hub for bridging so that we can, you know, own distribution in that sense, like whenever any user thinks of bridging they would come to Jumper and then we would see more volume, more users and then more market adoption of like Dey's tech stack through that, or like market awareness as well, and then that would kind of like the benefits would kind of spiral to the b2b side as well, because we're seeing more and more applications, kind of applications integrate our product and then generate volume for us through through the app, right, like they're attracting more users and volume for us, pretty much. So you, we can scale this I wouldn't say easily, but like scale this on the b2b side by focusing on getting more players to integrate us and then they do do the work of like attracting users for us. Yeah, I mean that that's true for bridges, but like I think, because lefi is an aggregator, like we don't have locked capital, so it's slightly different. But, like I definitely agree, just volume cannot be termed as winning right. And then at leefa as well, we're also exploring different ways of making money. Like I said, from the b2b side, we have the revenue split model and then we're also like trying to charge for other value add features on the on the b2c side where, like, we launched bridge insurance and then we have something called zapping through enabled through contact also, we're making this flow easier and that's why we can charge conveniences.
Speaker 2:So there are different ways and I agree with your point that just volume will not cut it. I mean also it's definitely not hypothetical right as an aggregator, offering a fail-safe is one of the key benefits. So let's say, for example, we have five bridges and then an application that is integrated has access to all of these types. Now if one bridge goes down, the application service is not affected, they can continue serving their users, and then if this application was only using this one bridge that went down, their business would be impacted. So I would go back to the multi-chain example.
Speaker 2:Recently there was so much uncertainty that we ended up being proactive and then we kind of disabled support for multi-chain because there was so much confusion Nobody knew what was going on, and then user funds were at risk.
Speaker 2:The businesses that were building on top of us their user funds were were at risk. Like the businesses that were building on top of us, their users funds were also at risk. So we would easily afford to disable multi-chain because we had 10 other options, but then if the application was only using multi-chain, they could not serve their users in the whole timeframe of the uncertainty Plus, like even now, because multi-chain has also lost trust and support. So people are trying to switch as well. So I'm not exactly sure of the exact percentages, but like, so we've built this out with insurers, right, and work with them to kind of spin up a pool of funds that ensures transactions while they're in flight, basically. So the user is paying a fee for like it's a fraction of what they're busy. So let's say, if you're bridging $100, you're paying $0.3 on the jumper interface and this piece is then split between us and Ninja.
Speaker 1:Can you tell us about your view of the current aggregator landscape and, like I'm sure, like different applications are optimizing for different things, and what those trade-offs are and who the leader is in in what they are trying to champion?
Speaker 2:yeah, I think so. The landscape is, I think, competitive because the scope of who we're competing with is up in the air right. Like we're technically, we're competing with all types of bridges, all aggregators. Uh, because, like we talked about earlier, an application can just integrate a single bridge or a user can just go use a single bridge. So we're competing with all of them, but specifically in terms of bridge aggregators I think two years ago there were like five or six projects that were working on this we're seeing lesser teams actively maintaining all these bridges and integrations and they've not been able to successfully attract users or get adoption for their product.
Speaker 2:And we're also seeing more and more peers shift towards different things in the aggregation landscape. Some are building their own bridge, some are focusing on different types of ecosystems to attract users, but then we kind of position ourselves not just as a bridge aggregator, like we try to look at our tech stack as, like this middleware technology Developers can build any type of application for enabling, you know, like any chain support. So, yeah, I think it's complicated, but then you'll be seeing this shift of focus away from just aggregation towards building, like these niche products, and that's one thing I would say is like. Good in my opinion about unified stack. Stack is that we're focused on just aggregation, like building on top of what these are enabling us do.
Speaker 1:That brings me to kind of the last question that I had what are the top two pressing challenges for LeFi, or for aggregators in general, at the moment?
Speaker 2:Yeah, so I think for LeFi and for bridge aggregators, one of the main challenge is always the maintenance of all these bridges, maintenance of bridges and like doing this across so many different chains. Like whenever a bridge has an update, we have to kind of work down the clock to make sure that this functionality or like this update is now available to all of our users and customers. So maintenance is a full-time job for like 20-odd developers. Like our team is always on top of like this maintenance and just like reliability of a product. That making sure that everything works is very complicated because you're interacting with so many different bridges, decks, chains, right. So maintenance and reliability.
Speaker 2:And then also like maybe this is biased because I am working in research Like there's this research overhead to kind of keep up with this changing landscape, right, like we in the last 10 months we've seen intense app chain account obstruction, layer three shared sequences like to some people these might be just buzzwords, but like they impact our business directly, right. So just trying to figure out what these things mean and how they could change the landscape and like how to position nefi it being proactive in positioning nefi in the in the right place for this changing landscape is is definitely a time all right, thanks a lot for that.
Speaker 1:Do you have anything more for us, something that we did not cover or you would like to talk about?
Speaker 2:I didn't really. Yeah, just use an aggregator. That's the answer. It will help you find the best bridge for your RV.
Speaker 1:Will I get the airdrop if I use the aggregator?
Speaker 2:No comment no-transcript.