Spark & Ark The Next Generation of Layer Two | Bitcoin 2026

Hi everyone. Happy to be here and discuss the future of Bitcoin. Are you enjoying the conference so far? >> Great. So the topic of this panel today is layer Bitcoin layer 2. For many many years, lightning was the only way to scale Bitcoin. So all the layer 2 discussions were around lightning and lightning tradeoffs, payment channels etc. And in the last couple of years there were significant improvement in the different technologies that are aimed to scale bitcoin and specifically and that's kind of the context of this panel. We'll talk about spark and arc. But before we do that I want to give you an opportunity to introduce yourself. So we'll start with Ben. Um, I'm Ben or Ben the Carman. I'm a developer at Spiral. I guess for Spark and Arc stuff, what I've done is at Spiral, we have a project called Orange SDK that uses Liz's Spark to start out and then once you have enough balance, we move you to a real channel. But, um, otherwise otherwise excited about Arc as well. So, >> but Ben, you already you have a history in layer 2 and you started with Lightning. >> Yeah. Yeah, I worked on Lightning for maybe three, four years. Um, otherwise did DLC's beforehand. I did I guess I did some covenant research at Tapper Wizards, but nothing that came to light. >> Matthew, >> thank you. My name is Matthew and I work at Second. We're working on our implementation of the ARC protocol where we offer users self-custody trustless payments in a way that Spark would not ever be able to do. >> Oo, okay. >> He's shooting his shot early. Yeah. >> Well, there you go. Uh, I'm Seth for privacy. Uh I'm chief operating officer at Cakewallet. Uh we deployed self-custodial lightning uh about two months ago using Spark to over a million people. Super smooth. I have been researching, following, writing about Spark and Arc for uh well since they were first announced and really really excited to talk through both today >> in a way that ARC would never be able to do. >> Ethan. >> Uh hi everyone. I'm Ethan. I'm building a company called Flashnet. We build Bitcoin native markets and we helped build Spark as a means to be able to fulfill our vision. >> And I'm Roy Shinfeld. I I'm I I'm the CEO of Breeze and we do Bitcoin layer 2 for many many years now. It's actually the eighth year that I'm running Breeze. We started with Lightning, different variations of Lightning, LSPs and and so forth. And in the last couple of year really focused on kind of the new last mile solutions. Erh, so Matthew, you said that uh you don't like Spark, but before we get into kind of Spark versus ARC, let's talk about Bitcoin. Like why do we need to scale Bitcoin? Why not use Solana? >> It's a great question. I don't know. I I I feel like I'm the the least Bitcoiner of the group here. I I think I'm a pragmatic Bitcoiner. Um I think that TLDDR is we need to be able to provide the users the service that they want to buy. And today the the Bitcoin services we can offer are not great. Um I mean Bitcoin on L1 slow and expensive. It's not that expensive anymore. Um and then Lightning came with a bunch of you know trust trade-offs which kind of manifested into compliance and regulatory trade-offs. Um so I think Spark and Arc kind of fulfill a vision of fast cheap self-custody Bitcoin. Um that has been missing in the market for a really really long time. >> Is it missing in the market? I'm I'm serious about like why not use Solana? Why do we need to scale Bitcoin? >> How many users? >> It's a serious question. >> How many users does Cake have uh that holds self-custody of Bitcoin? >> Well over a million, but we don't know we don't know anything about what they do with it. I I think the like the beauty of Bitcoin has always been >> it is not just the the do everything chain. It's very focused on maintaining decentralization, trying to give you the ability to to make really pragmatic trust trade-offs and and have self- sovereignty with your money. Obviously, we could go to Salana. We can scale that way, parallel scaling of just go to another chain and spread out people across different chains. But the the critical thing always with Bitcoin is coming back to how do we find that that middle ground of being very pragmatic about what people want, but also do it in the most trust minimized uh most self-custodial way that we can and finding where the kind of the the middle point is there. uh you talked about lightning Ethan and you said there are regulatory trade-offs with lightning. >> Most most lightning solutions today are custodial. >> So I mean if if you if you want to host >> so it's actually kind of the user experience issues of lightning and and Ben you dealt with a lot of user experience issues when you worked on mutiny. Can you elaborate on kind of the challenges in terms of user interface when it came to kind of providing self-custodial lightning to end users? Yeah, I mean uh like lightning's fantastic. It basically like made it to now. Um it's like a huge um UX improvement on normal Bitcoin. You have to like wait for confirmations and you know payments are instant now and uh much cheaper. Problem is though it requires a lot of setup. You have to like create a channel which normally means okay user you want to use my app start out with $100 at least. And it's like it's so hard to compete with where like in normal traditional world it's like Cash App pays you to join the app versus now we're like you pay us to join an app. So it's like terrible to do that. And um >> from a technical standpoint I call it the inbound liquidity problem. >> Yes. Yes. So you have the liquidity issues and then as well it's like lightning has all these um you know it's a complicated protocol. It's got all these onion routings. Try to be very private but running that on a mobile phone can get taxing. You have to like keep your channel graph up to date and everything. So there are different solutions like trampoline or like an in LDK we have RGS but they're not perfect. So it's still a hard problem to have. >> And that's even a minor UX solution. Kind of the biggest challenge is offline receive. >> Yes. Offline receive is basically impossible. I mean Fenix kind of does something, but they're like hacking where you like get a push notification, it turns on the phone, but that's not totally reliable and you know, Apple hates us so you know it doesn't always work. But yeah. >> Yeah. So we started also with kind of running a full node on a mobile device. Definitely 100% kind of the inbound liquidity issue even with LSPs and other artifacts that we've built it's very challenging to overcome channel management offline receive keeping the graph in sync that's our challenges that were very hard to overcome but I think on top of that like the main reason that lightning does is not kind of the best tool to be used as the last mile solution is an economical problem >> like the the the need to lock liquidity for millions and tens of millions of users that as itself doesn't really scale. So the lightning from an econom from an economical standpoint doesn't really scale as a last mile solution. Would would you agree with that Matthew? >> Yeah, I mean running Oh, sorry. Go ahead. Uh, I would agree with that and I think that's the core value proposition of using ARC and users are able to use ARC as a lightning gateway and then when the next round comes they're able to anchor all that lightning that they've spent and received into a round transaction into a timeout tree. This is not present on Spark as well. You know, you can never secure and anchor your money back into the L1 intermittently in the same way. >> Sorry. Okay, we'll get to kind of the technical definitions, but that's that's not true. Okay, I'll let you refute it. Uh, I'd love to hear more about that. But we're not doing lawyer driven development. We're doing what is best for the user so that they can keep self- custody of their funds, receive lightning, anchor it into the chain, and keep on transacting. >> I think there's something I think there's something very interesting there though because it's it's always been this very Bitcoiner problem where people building in Bitcoin and deeply involved in the Bitcoin ecosystem. We want to build things that are the most self-s sovereign, the most trustless possible. And there there is a place for that and that is absolutely fantastic. But I think there's always been this view that the the trust model is either perfectly trustless Bitcoin onchain transactions or Salana and that there is nothing in between and that anything in between is necessarily Salana. And that is almost always the framing that's actually presented when we talk about this >> or even more CBDC. >> Yeah. I mean you you name it. That's kind of the view there. And yet even when you approach like when you're using lightning if you are using self-custodial lightning most of you probably are not unfortunately hopefully you are uh if you if you are also not using a trustless solution if you're using Phoenix you're trusting Phoenix especially when you open the channel to not steal funds before the channel confirms you're trusting Phoenix not to force close with a bad channel state when you don't open your app for a long period of time there are always trust trade-offs with everything except for onchain Bitcoin where you're using your own node. Anything beyond that, you do have trust trade-offs. And it's the sliding scale. And I think we have to be very pragmatic when we are building these solutions and talking about them of where do we find the the best middle ground where maybe we we call something trust minimized, but it's much more useful for real people and we can actually provide much more freedom that way than if we go something that's a little bit more trust minimized, but much harder to use. >> But set, let's define trust because I think that's a very complicated topic. So we need to define what trust means. Allow me to offer a definition and then kind of see I want to see if you guys agree. I think there are three parts when we we three pillars that when we talk about trust we actually talk about custody. >> Can this solution steal my funds? We talk about control censorship resistant. Can the solution block me from doing something? And we're talking about privacy and you mentioned Phoenix also from a privacy standpoint. Fenix uses trampoline in payment. They know the destination of the payment. So I think when we talk about the trust minimize solution, it's a combination of these three pillars. >> Yeah. >> Is there something I'm missing? >> No. I would point out uh one thing that's really critically important when it comes to trust on Bitcoin layer 2s is that you're able to perform the unilateral exits that you're able to bring your money back on chain uh without the permission of the counterparty. And this is something art can do. I've seen Spark make the claim that they can do it, but I've never seen that claim substantiated. I I I want to get in like I'm not trying to avoid I think you're completely misunderstand Spark and you don't know what you're talking about but but uh to put that aside let's give the audience a chance to understand what we're talking about even so let's do a one a very uh le five kind of an explanation on arc and spark so who wants to do the spark side >> I can I can jump into spark yeah I can quickly explain that um so spark essentially is a a state chain system. It's a system where you move transactions offchain and you actually transfer UTXOs or BTXOs or leafs specifically in Spark between users offchain without actually having to move funds onchain to make that transfer possible. Uh it does this by having a Spark entity which is the the the entity that sets up everything. And then there are separate Spark operators to move funds within Spark. you and all Spark operators sign the transaction together uh and you move the funds, the ownership of the funds to the new person that you're paying. Um it's really that simple to make lightning payments within Spark. What you do is you do an atomic swap with a lightning service provider where again you sign over a sparkle leaf, you give it to a lightning service provider, they make the payment on your behalf or vice versa. It feels much like using onchain bitcoin. It is not as trust minimized as using onchain bitcoin. And the one major trust assumption that I will just be very transparent about is that if all Spark operators, which there are multiple in the main Spark entity right now, and a previous sender collude and work together, they can publish a previous uh transaction state and double spend funds. That being said, if any Spark operator is honest or if the previous senders are honest, uh no one has the ability to steal funds at all. and at any time you can unilaterally exit back onto Bitcoin without the permission of any Spark chain operator, Spark entity, anything like that. Um, so that's really the I think the TLDDR there. >> I agree with uh your description of Spark. I think that that's accurate, but I would point out for the Spark operators, you mentioned there's multiple I believe there's only two. >> There's three. >> There's three. Okay. Well, two or three of them are oper operated by a father and son uh team. That's why the third is very important because if anyone is honest >> there is no ability to steal funds. >> So just to clarify there are three operators right now. One is light spark itself. Secondly is flashnet. Ethan is running that's the sun. >> Where's the holy spirit? I >> who was the third one. >> Oh it's you. Oh how convenient. And and can you explain arc to the audience? >> Yeah. Um I think that arc and spark have some things in common like for example we both use a tree. We're both using leaves. The leaves of the vtxos but the critical difference is that we don't have just one tree. There are many timeout trees. And as you hold your money in the ark uh over time you're participating in continuous rounds and every time the next round comes your money is reanchored onto the layer 1 bitcoin and your tres is completely refreshed. >> Well that depends on the arc implementation correct >> does it? >> Yes. How >> if there >> I think that's universal arcs. >> There's even a round. >> Maybe Ben can chime in. >> If there's never >> No, I'm asking you, Matthew. Like the the the the time of when to do a round that's defined by the spark by the arc operator. >> Yes. But by definition, another round must occur. >> They they will have to happen. It must happen. Otherwise, it would not be an arc. That's the definition of an ARC is that the VTXO has a limited lifespan >> and then it will come back. It will forfeit the VTXO, receive a refreshed one. The trust will be reset. The user has absolute ownership that cannot be pried away from them. >> And so the two caveats I'll mention though and the two trust assumptions that were not mentioned there. And I say this as someone who absolutely loves both ARC and Spark and has researched and looked at both of them for years. Very very interesting. I love that both are competing and building open protocols that can make Bitcoin better. The two caveats with ARC though that are often overlooked or misunderstood is one you mentioned VTXO expiry. Essentially what that means is if you don't come online or someone you delegate the ability to join around for you doesn't come online in time. The money that you have expires and the ARC operator can unilaterally sweep those funds. Whether or not they do is up to them. Obviously, they have a an obligation to not do that or else obviously no one would trust them with funds, but they have the sole ability to move funds if you don't come online. The solution to that is you can trust someone else to do that refresh for you or you can come online yourself. Mobile users generally are not going to come online themselves. So, you're going to be trusting a delegate, someone uh like your wallet provider to hopefully do that refresh for you. They can't steal funds. If they do the refresh for you, your funds are SAFEU. Uh if they don't do the refresh, your funds could be stolen. >> But, uh correct me if I'm wrong, Seth. uh using a delegate if you delegate kind of the signing to a third party let's say cake wallet >> so one you need to be also online in the kind of the time period of around in order to refresh >> to provide the delegation right Matthew >> it depends specifically >> I'd also point out that you can also delegate to yourself you don't need to delegate to a third party if you're a sovereign road runner at home you can run >> how many how many users are actually going to be sovereign >> you can run a lightning node as well >> I think there's a large community of sovereign node runners out there. >> But the the the the goal here is to scale Bitcoin for non-custodial users worldwide, the the core issue that we had before Arc and Spark was that Lightning was too much of a pain in the ass to run for most people. Like if if if the solution to a hard problem is okay, we have another hard problem for you, it's not really a great solution, right? >> It is easier to run a delegate, but again, you're talking what is the what is the percentage of people in the world who are going to self-host anything? I'm okay with shielding Spark and Arc, but just to I'm trying kind of to refrain to reframe the the discussion. It's okay to shield Arc. It's okay to shield Spark, but let's be honest about the trade-offs that each have and ARC has a liveless issue. You you can admit that that that's more challenging. >> Yeah. in the most um nonoptimistic trust scenario of ARC where we're saying, "Oh, you're delegating this, you're doing that." You're still at the same place you are with Spark. >> Yeah. And yet it's more complex at the same time. I I think the the tricky thing is when you actually boil down into the details of how will a user actually use this solution, there's not much difference in terms of trust between them. In some situations, Spark can be slightly better because operators and there's no expiry in some situations. If you're more hardcore, ARC can be I think the the more important issue though is what is a solution that users can actually use, what will be useful for people and what will provide freedom. And I think the really exciting thing is both can >> or they're competing in different ways and we need to figure out what is the what is the most useful case for ARC? what's the most useful case for Spark and find just the the way that people win. Like the the goal is that people win because the tools that we're building, not that we have little fights over the the the little trust trade-off details when they're actually quite similar in the way real users will actually use them at the end of the day. >> I I don't think that these are just like little details like I know that Bitcoin magazine just reported that Ethan, your company was invested in by the chairman of the Federal Reserve. >> Oh, directly. >> But enough with this virtue signaling. think that is a big deal. Whatever you're trusting, you're trusting a bank. >> It's an LP in a fund that invested in us. We had no idea until the fucking news broke. It's not like a >> But but why why go that path? Let's talk technical. Let's talk >> The reason I go that path is because Bitcoin is ideological and people use Bitcoin for ideological reasons. If people don't care about the values of Bitcoin, they can use fiats. >> We're here to build. >> You want to talk about the utility of I disagree with that statement at all. Like you maybe you use Bitcoin because of ideology. Most users don't use Bitcoin because of ideology. >> Yeah. Like the vast vast majority of Bitcoin users do not use Bitcoin for ideological purposes. >> Okay. Well, they need they need a tool and Bitcoin is that tool and they use it. But I think you can you can get a perfect example of this in the fact that most people around the world who need a tool for freedom right now that's not their fiat currency, they don't use Bitcoin because they're not ideologically motivated. They use stable coins. They use other things. >> Use Tether on Tron. >> Yeah. Unfortunately, that's that is not the place that we should be. But I think there's a responsibility for us as builders >> the order of magnitude more like not it's not even close like the the the usage of stable coins versus Bitcoin as a medium of exchange and we all want people to use Bitcoin as a medium of exchange. >> Yeah. >> And if that's the case, why don't we just use custodial then? Like that's the best UX by far >> because we can't. That's that's a great question. Like people used Wallet of Satoshi until Wallet of Satoshi was shut down because of regulation. Do you want to run a regulated company? >> No. I mean like but then it's just like legal arbitrage here. Like then it's like >> the entire crypto space is regulatory arbitrage. Sorry to >> I would hope we develop things that are like not lawyer focused and more you know like Bitcoin focused. >> The ideology is important for us as builders. I think it's our responsibility like we are ideologically motivated. We would not be on this stage if we weren't. I don't think >> I'm technically motivated to provide the most trustless solution possible. >> Exactly. But that's an ideology. That really is an ideology I think and the the beauty of that is that we have a motivation to build something that is self-custodial because we think it's the best tool for people long term of what freedom it provides. >> Exactly. That's because it's lasting not because of like ideology. I think it's very pragmatic. I think there is a utility behind the ideology and the the the utility is providing a global currency that is lasting. >> Yeah. >> And I don't think there's a better tool to do that other than Bitcoin. That's why I do Bitcoin. >> Yeah. >> Well, ideology doesn't only matter to the end user. I think it also matters to the integrators and the wallet providers. Like I saw a tweet this morning that Blue Wallet is no longer going to be integrating Spark because they're unhappy with what the trust assumptions are and the custody model. So if you're making business partnerships, >> they never try to integrate Spark. >> Never going to implement Spark. I mean, I ask you this, how many how many wallets have implemented ARC? >> Uh we have a handful and you can go into the open source stage and try it out today on mainnet. I mean >> and what's your take as a as an outside builder on art in Spark? Let's get your perspective. >> I mean uh my hot take is like really the existence of Spark is a failure of the Bitcoin protocol because like we could have ARC where it's like all the solutions solved if we had covenants but the problem is we don't have that. So Spark is like the interim solution there of like well we can't get updates to the Bitcoin protocol to make self custody scalable so we'll use you know we'll introduce trust assumptions to solve that. And um I mean it works today and it's you know a good stop gap but it's really just a failure of the Bitcoin protocol to actually allow scaling uh self- custody. >> So which op code do you want in the Bitcoin protocol? >> I mean I'll take any covenant hash CTV template hash >> and which uh which uh software do you you run notes or bitcoin core? >> I run liver relay. >> Ah nice nice >> cool. Erh, let's talk about trade-offs because there's always trade-offs. Even if even if we accept kind of the premise that ARC is more closer to onchain, there is a cost associated with that. And I like to examine things from a trust standpoint, control privacy, control privacy and custody, but also from an economical standpoint. So can you share the economics some some thing about the economic of running an ARC service provider? >> Uh well the ARC server will front the liquidity. They will have money that they load up into the ARC server and then users will come and they will make transactions and uh >> from an economical standpoint for the audience to understand you need to front every VTXO with liquidity. >> Yes. the amount of money that's being used in the ARC, the amount of money that is in these onchain round transactions, uh the ARC server will have to hold on to that amount of money themselves. >> Is there is there like a a cap I guess to how many users can actually use ARC in this in this way? Like h how many LPS do you have lining up to put money behind? >> Well, you don't need to do it for every payment. Like um at Spiral, we have a one of my co-workers, Instagibs, is working on basically putting lightning channels in a VTXO. So then it's like you just have to front liquidity to of these single channel open but you can make you know as infinite payments from there and then you have like uh arcade like they're doing basically it's like spark upside down where they're doing arc with the state chain inside for payments. So that's how they're getting around it. So you wouldn't have to like front every single payment ever. There's you know you just take other traditional Bitcoin scaling things and put it on top of ARC. But so if there's like $2 million of user deposits into ARC in one way or another, ARC would have to front $2 million as well. Is that correct to say? >> Yes. >> Yeah. Yeah. >> I mean that seems like a pretty big scaling limitation. >> Well, there's a lot of Bitcoin treasury companies. >> Have you have they're getting fees for this. It's not like zero >> win strategy arc service provider. Is that the is that the next phase? >> We'll see. will we'll be running the second ARC service provider >> and and that has to have an implication about the cost and the fees, right? >> Yes. The users are paying fees uh to the arc server in order to route their payments over lightning and then those fees can uh the arc service provider makes money from that. >> And who's running the lightning component in in in second? Are you running the the >> ARC? We have uh we have the arc server and then we also have uh lightning nodes that are connected to the arc server which we also run but anybody is able to spin up the software and run it themselves. We're here at the open source stage. Our software is 100% open source. Anybody can see the full source code and run an arc server themselves. >> Welcome to predict the world is a market. Everything is a market. Every headline moves the line. Every moment is your market. Call the moves. Bet on your instinct, your prediction, your edge. Dual bits. Predict where everything is a market. >> One thing I want to call out too that hasn't been mentioned yet is Arc and Spark are interoperable because of Lightning. So, one of the really beautiful things about this, both are open protocols. Anyone could run a Spark entity. Technically, anyone could run an ARC service provider, but the beauty is you as a user, if you're a Spark user, if you're an ARC user, you don't even need to know which you are. You can pay each other because of Lightning. And that's one of the beautiful things that you mentioned earlier, like Lightning as a ser as a solution that you actually run channels for. That was never going to work. That was not scalable. Finally, we're pivoting to Lightning is a fantastic interoperability layer where now anyone who's using any of these solutions can make those payments and have all of the benefits of Lightning without having to worry about which underlying thing that they're running. And that's a that is a big distinction just to kind of keep in mind for you. >> Oh, I I agree. I just kind of I disagree on the scaling. Lightning doesn't scale. It does scale for high frequency channels. >> Yeah. Not for not for me opening the last and making three payments a month. Like that doesn't scale. And again, that's because of the economical model. Like you need a high frequency channel to make lightning. >> Yeah. Well, I think there's two things like we're trying to scale. Like lightning scales payments. We're now like we're no longer restricted to seven uh seven transactions per second, >> but it doesn't scale ownership still. You need one UTXO per person. So that's expensive onchain, expensive liquidity wise. And it's just like, you know, if we try to give every single person a UTXO, it's like 300 gigabytes of like chain space. it's like never going to happen in a reasonable time. So like Arc and Spark lets us scale that UTXO by creating these trees where instead of one UTXO one user, it's one UTXO like a million users. >> From a lightning standpoint, how do you deal with offline receive? >> Uh you don't arc >> arc >> arc. Uh you would come online to receive this. >> So you have the same liveless requirement. Uh I believe as our current iteration yes we do. I >> I think in theory you could do the same thing for offline receive and arc that is done in sparked. So the question whether arc is going to the federated model like to the one out of n model is that something that you guys are planning to do? >> Uh we have no statement about that. No. >> What does I lawyer? I don't know. I don't know. I don't have like where where are we like you're in the wrong stage Matthew. Like it's there. No. But it's got something that you guys >> I can't elaborate on any plans about that. I don't know about any plans for that. I don't >> Okay. >> Answer. Yeah. >> Okay. Copy that. >> Uh so and and and I I again I think we need to understand like there are two main art implementation. One is by second and the other one is by Arlabs called arcade. I kind of like the arcade approach of doing an offline execution engine like you can run different scripts offline and and and implement financial solutions that can't be implemented on top of uh onchain. Is this something you guys are offering as well? >> No, we're not we're not planning to do anything like custom script or having a VM. uh our one priority is doing payments, lightning payments, onchain, arc payments. Uh that's our core competency. Do one thing and do it well. And that's the purpose of our protocol. We're not here to do DeFi. We're not here to integrate stable coins. It's not what our mission is. >> I think it's important to highlight too like the arcade version of that like all the custom scripts is it requires trusting the signer on their behalf. So it's not like they just enable new op codes and they're for free. It's like the new op codes work. >> Yeah. It's the same arcade trust model, right? >> Well, because they use state chains that has the trusted signer anyways. So, yeah. >> Yeah. Yeah. I think the like that's one thing that I really like about second that y'all have chosen to be laser focused on payments because I think the lowhanging fruit and the thing that we need to solve first is payments that scale. Like that is the the thing that is preventing a lot of people from using Bitcoin, especially in a self-custodial way. Obviously, we can scale Bitcoin payments by just using a database and using W of Satoshi and like that is scalable, if you want to call that scaling, but I think that's been the biggest issue is we need a way to be able to scale the self-custodial side of that, >> get that done and then we can worry about if we want to do more complex things down the line. I think that that will that will kind of play out. >> Can I challenge that >> fire away? >> Can we do that without stable coins? >> I mean, again, that depends on the target audience. I I think that there is a an unfortunate necessity to temporarily serve stable coins. I'm I'm definitely ideologically I I hope that they go away and we we have people actually using something that is more decentralized and more trustless because the hard thing with stable coins, most of them, not all of them, but most of them even if you have self-custody, it doesn't matter because Tether can just say your USDT doesn't work anymore. Uh, you can have the keys, that's fine, but you can't actually move them on essentially every chain. >> That happened like last week or something with Iran. >> There's a fantastic website, I can't remember what it's what it is off the top of my head, but there's a website that tracks that. And there's I mean there's there's hundreds upon hundreds of millions of dollars of Tether that get frozen every year because it's it's a completely centrally controlled token even if it's on something else. And I think that's the the hard part is I I want to solve the Bitcoin side, but right now people need and use stable coins. And so we need to serve that as well and give them easy ramps back into Bitcoin. Especially as we see the crackdowns, as we see Tether uh freeze funds, people will start to figure out, okay, I need something that that can't happen to. Like my neighbor just had all their funds frozen or that friend in Venezuela, they they got caught up in this Tether $180 million freezing situation. We need something that will work no matter what. And then they'll shift into Bitcoin. And so I think there's a lot of responsibility for us to get access to stable coins and self-custodial wallets as close to Bitcoin as possible so that they can flow into Bitcoin when the rubber meets the road. >> So it's a good segue to you Ethan Flashet. >> You decided to focus your time and energy on exactly that. >> Yeah. >> Bridging between Bitcoin and stable coins. Can you >> say what you're doing? >> Flashnet. A quick TLDDR is a Bitcoin native markets. Our focus today is very much spot Bitcoin to stable coins. Uh we do a lot of crosschain stuff. We power deposits, withdrawals, uh and then just native swaps on Spark. Uh for us, the core mission is just how do we how do we one scale Bitcoin for everyone via Spark, uh but also create this one global pool of liquidity uh for Bitcoin itself. Um Bitcoin trades a a ridiculous amount every year, more than the entire rest of crypto combined. uh but it's the only asset that still trades completely on centralized exchanges for the most part. Um so trying to change that for for retail. >> I think the underlying discussion here which is kind of maybe it's a topic for another panel is how do you do stable coin to Bitcoin bridging? Do you do that in a in a DEX on a client or do you do that natively in Lightning? And that's a that's a that's an interesting >> different opinions about this. Uh so we're out of time. Maybe let's do a last round of uh asking you guys what are you excited about? What are you working on? Like what are you expecting to deliver in the next 12 months? >> I'm hoping we get CTV so we don't have to have these arguments anymore. >> In the next >> in the next 12 months and sure I'll take. >> Okay. I'm excited to have Second's Arc on mainet now running real world lightning payments and I invite Seth to come with me and transact over Lightning together. >> Yeah, let's do it. Let's do it. >> Yeah, I mean I think for me, like I mentioned before, I'm really excited that there are now practical solutions to scaling payments to potentially doing other things like stable coins within Bitcoin and we can have a competition of open protocols and the the user ultimately wins. That's one of the best parts of Freedom Tech, the best parts of open source is we as the builder have to compete for you and you always win. And that's one thing that's really important here. So I think the next 12 months now that these these technologies are actually out, Spark is deployed to a ton of people. Arc is just getting started, just starting to get rolling. As users use that, we'll have great competition that'll drive better products, better tools that push more towards trust minimization and self-custody. >> Amen. >> Yeah. uh excited to continue scaling Spark and bringing more people to Bitcoin uh get them transacting every day. >> I think the future also is not a monolytic future. I don't think we're going to kind of centralize on a on a single stack. I think we'll have multiple network and the the the thing that I'm excited about is what you said set seeing lightning act as the common language between these different subn networks. Thank you so much for honest, for your honesty, for participation and you guys should use art, spark, lightning, whatever you can in order to use Bitcoin as a medium of exchange. Every year, this community comes together to celebrate, to debate, to build what comes next. And every year the stage gets bigger. Sound money center stage. So where do you go to celebrate the next chapter in Bitcoin history? You come home. Nashville. July 2027.