CD209: MATTHEW VUK - BARK - BITCOIN PAYMENTS ON ARK

0:32 Happy Bitcoin Monday, freaks. It's your host, Odell, here for another civil dispatch. The show focused on actual Bitcoin and freedom tech discussion. It's Monday morning over here, July 20, sixteen hundred UTC in Bitcoin time. That is block height nine five eight nine one one. Sats per dollar is 1,529. Current Bitcoin price is $65,380 off of the lows. Vibes are not high, but vibes are not low. We're jumping back into that good Bitcoin tech. But before I do, as always, guys, Dispatch is funded by viewers like you, our guest listeners, since we're doing audio only now.

1:23 We have no ads. We have no sponsors. When I have something interesting that I wanna talk about, we have interesting people on, and we discuss, and you guys support the show with Sats with Bitcoin. So thank you guys for supporting the show. The largest Zaps from last week was Keith Sharp with 21,212 Sats. He said awesome rip. Introduced to no good from his 2022 art for tab comp. That was a good series he did. PGS design, zap 10,000. What a career arc. So cool. And then Eric FJ rolls it out with 2,222 stats. He said, great rip gents. World will be a better place as more and more creators follow their inspiration through freedom tech like no good.

2:06 So, guys, I'm doing, like, a little bit of a weave. I guess before that, obviously, bear market. I know Bitcoin. I know that money's tight, guys. If you can't if you can't spare any Bitcoin, sharing it with friends and family is really helpful. Search civil dispatch in your favorite podcast app. All relevant links are stilldispatch.com. Take their phone. Search for civil dispatch. Subscribe. Your family won't know what hit them. They'll just get that sweet, sweet signal. So anyway, freaks, thank you for those who continue to support the show. Anyway, as I was saying, I'm doing a little bit of a weave. You know, we had a technical show two weeks ago. Then last week, had no good on. We talked about art, Bitcoin culture and freedom culture. And I thought that was a lot of fun. Next week, have soap miner coming on and we'll be talking about like Bitcoin or small businesses or local soap purveyor.

2:53 He makes great soap and you can only buy with Bitcoin. But this week, we'll be jumping back into technical stuff. And I have Matthew Vuk here, and he is head of research at Bark, which is the second ARC implementation, and they actually named their company second. How's it going, Matthew? I'm doing very well. Thank you for having me. Is that why the company was named Second? Yeah. There are. That's the short answer. There's two different implementations of ARC. And originally ARC was first proposed by Barak, I believe in 2023. And he did not go on to build an implementation himself, but two different teams emerged from his initial working group.

3:35 He's not involved with Second at all. Right? He's not involved with Second. I believe he has his own project now called Cube that he's working on, which kind of you put the arc in the BitVM. Like a combination of the two. Yeah. I had freeze. If you remember, I had Alex be on cil dispatch '1 82. That's was in October of last year. And so we were talking about ArcLabs, which was is, you know, that other implementation. And then I've had Barak on multiple times. You can go check the archives. He was the destroyer of lightning at one point where he was just taking down the lightning network.

4:15 Interesting character, young kid, Very impressive technically. Anyway, second. So what is it? Why what is bark? Why should we care? Why is it interesting? Hit me. I think the most interesting thing about bark is that you might not even notice that you're using it. So bark is a implementation of arc, which is a Bitcoin layer two. And what it is, is it is the infrastructure that makes the Bitcoin payments happen in your wallets, in your mobile app. And what you can do is you can send and receive Lightning without needing to manage any liquidity, without needing to manage any channels. That's all taken care of through Arc, how it works. Arc is our particular implementation of Arc. So there are two different implementations and they follow a very similar underlying structure of how they work. But we're focused on the payments use case, exclusively sending and receiving Bitcoin on chain, Lightning, and Arc payments.

5:18 So on the Arc payment is, I mean, Lightning has multiple implementations. Are are Arc payments interoperable between Arcade and Bark? So Arc payments are only within the same particular Arc. So you cannot make an Arc payment between Arcade and Bark, but also if you have two different people both running an implementation, like they're both running Bark and there's multiple different Arc servers, you wouldn't be able to send an Arc payment between them. Those would be between Lightning. So it's almost kind of similar to, I mean, it's probably completely different, but all been practiced kind of similar to people that are using like cash humans.

6:01 Right? Where like, if you can do cash, you natively cash, you native payments if you're in the same mint, but if you're going cross mint, then that's where lightning comes comes into into play. Right? Yeah. That's the perfect analogy. Lightning is the connective tissue that connects all of these things together. So you're using lightning to move in between cashew, ARC, etcetera. And when you're using an ARC wallet, you're connected to a particular Arc in the same way that if you were using a cashew wallet, you would be connected to a particular Mint. Got it. So I I mean, that to me is one of the coolest parts about all these, all this new payment tech we're seeing, because historically it was like, okay, like some nerds came up with something and it's technically interesting, but you needed to see basically like a bootstrapping network effect, which is almost impossible to do where, you know, if you only have like two users, then that was you can only pay the other user. Like, there's you couldn't pay people you wanted to pay. Now with Lightning, because pretty much all Bitcoin wallets speak Lightning, these novel new protocols, you don't have to have the bootstrap. Like, I can just I can be the only person that's using a Bark Wallet, and I can pay at a Square merchant. And the Square merchant has no idea that I'm using a Bark Wallet. Right? So now all of a sudden, gets really interesting. Think real it can get really interesting really quickly.

7:26 Exactly. And what we have in the Bark enabled wallets is that we have a unified invoice. So I have a single QR code that somebody can scan or copy that string of text. What you'll see is that if you and the other person are both on the ARC, you're both in the same ARC, then it can send as an ARC payment with zero fees, instant settlement, offline receive, all those benefits. But if only one of the persons is on the Arc, other person is on a Lightning or a Cashew or so on, unless it's a Cashew, a Bark powered Cashew, then you do get these benefits as well. Then it will default to Lightning and the payments will continue as usual. So when somebody integrates Bark and they use that to power their Lightning payments, they get to right off the bat, even if nobody else is making Arc payments with them, they still get a lot of upside on managing liquidity.

8:20 That is help helpful. And then there's a network effect that grows as different ARC enabled wallets begin to communicate with each other. Okay. I have that makes sense. I have a bunch of questions here. First of all, I tested out, I guess, like, two of the first mobile wallets that came out. One was Noah, which I guess is like a little bit, probably a little bit more power user focused. And then the other one was our key our key. I don't know. We'd suck at naming things in the Bitcoin space, which was a cool design focus. It was like one of the most unique wallets I've ever seen. But like to your point, like I opened up the invoice. I just pay with Phoenix wallet. Phoenix has no idea. It's a bark wallet. Doesn't speak bark at all and just sends a lightning payment. Do you think in practice, most payments in these wallets will be lightning to light like, will be lightning payments rather than bark payments, I guess, or arc payments. I don't know. What are we calling them? Are we calling them bark payments or arc payments? I like to call them arc payments because they're intra arc, and we don't need another with all these words that rhyme, it can be kinda confusing. Yeah. Why did you name it Bark?

9:33 It's the Bitcoin Arc. Oh, okay. That makes sense. So it's not a dog reference. Well, it's also a dog reference. Yeah. That's our mascot is Bite the dog. So we have him on there. When you're making payments in the app, are they going to be Arc payments? I think that in a circular economy setting, that's something that can really take off. That if you have people in a particular community or geographic area that are onboarded together, then absolutely you will see a big influx of arc to arc payments. And otherwise Makes sense. Just be a nice Easter egg that comes up to you when you find somebody else as a arc user as well. Is the well, I guess, let's okay. So from the end user point of view, you're just downloading a wallet and just works. You can make make make Bitcoin payments, receive Bitcoin payments.

10:25 It just works. You don't have to you don't have to deal with any of the nitty gritty, and that's awesome. You don't have to deal with managing liquidity. Can it make can these wallets they can do on chain too? They can do lightning or on chain or arc payments. Right? Exactly. So the way that it would work is that you would download a a bark enabled wallet for the first time and you would have zero balance. Right? Like you don't have any money on the app. No Bitcoin whatsoever. And without needing to open up a channel or purchase receiving capacity or use a custodial solution, what you can do is you can just create an invoice, which is the unified invoice, and somebody can send you a payment right away.

11:08 It could be a lightning payment. So you can receive a lightning payment instantly. And what happens is, is that when you receive that Lightning payment, it appears in the storage of your app as a VTXO. A VTXO is a lot like a UTXO on chain. It has very similar properties to it. Like it has a certain amount of SATs associated with it. So when I look into my app on my phone, I'll see, I have one VTXO for a 100,000 SATs, another one for 55,000, another one for 35,000. And then my wallet balance is a sum of them. So just in the same way that if I have an on chain wallets and I want to send payments to people, I know that I'm spending a particular UTXO.

11:54 It's the same way. And what happens is, is that you can take those VTXOs, virtual UTXOs. And what you're doing is you go to the Arc server, who is a coordinator and not a custodian. You might've also heard the term ASP, ARC server, or coordinator. These are all referencing the same thing. And what the ARC server does is it will help you complete the payments on your behalf. So it can take your VTXO and turn that into an outbound Lightning payment for you. Can Who running the Lightning node? The ARC server is. Okay. Yeah. So so the ARC server the ASP is also an LSP. It's both.

12:39 It is managing the Lightning node as well. There's some I wouldn't say it's exactly like an LSP, but it definitely is providing the Lightning service. LSP. It's coordinated. Yeah. That by definition, maybe. Well, it's like a Federment gateway. Are you familiar with the Federment gateway? I know some things about it. But with cashew, so I'm all over the place for weeks. We're going to we're I don't know. Let's have fun with it. With cashew is a is a is single instance mint. Right? So you have a guy who's running the the cashew instance, and that guy is also running a lightning node and he's doing everything for you with Fetement.

13:21 You have a, a multi sig a multi sig of guardians, right? That are running the mints. And so like it requires a threshold of them to steal funds or go down and lose access. Right. Which I think is even the more likely scenario for users that they should be concerned about is just uptime issues rather than someone being actively malicious maybe. And so but that the Lightning provider is separate. Right? It's a separate Lightning provider that technically anyone, I guess, could be they have to be blessed. They have to be blessed by the guardians of the mint to to be allowed to offer that service, but someone has to run a Lightning node for you to speak Lightning.

14:03 So I guess my question is, is that is that specific with bark? Is that like is the is the ASP always the one who's running the lightning node? Are are there multiple could there be multiple lightning nodes that are servicing a what are we calling it? A arc instance? Arc server. Instance. Yeah. Particular Arc server or a a Arc client. So it follows a client server model. So the way that we launched is that we have the Arc server has its lightning node and it's running everything. It runs the lightning in one. It's all built in one and we're optimizing for that experience. So we're controlling both those variables and making sure the payments go through reliably.

14:48 Down the road in the roadmap, we are planning to open it up so that people can attach other Lightning nodes. So right now, so that people can put in, say, right now we have Core Lightning or C Lightning as our Lightning node that the Arc server And then we would go to add on LDK. So the Arc server can have multiple Lightning nodes and that comes into play with different features. So for example, things in the roadmap, like virtual channels, having Lightning inside the Arc as well. We would connect this with things like LDK and then also allow people to use their own swap providers. So if they want to use, make outbound Lightning payments with a different swap provider and not use the one that's run by the Arc server, they can have that option, but that's not currently in our implementation.

15:34 So if I install if I install. I, we might as well just get technical with it because if, if, if you're, if you're not interested in the technical freaks, just go install Arky app. Go to second.tech. What is it? It's second.tech/docs/builtwithbark, and I'll put it in the show notes. And right now, there's it looks like there's five different mobile wallets that they have there. Just go play with the mobile wallet. But now it's just okay. You don't have to listen to the rest if you think it's too technical. The right so if I install if I install Noah, right? I install Noah, I'm connecting to a ASP by second.

16:22 Right? That's correct. Okay. So you guys are running this, this ASP. That's also an LSP. It's running a Lightning node and it's running the ARC server. What is as a user? What is my trust in that server? What is the, is that? What is going on there? You're making atomic swaps for the payments. So when you send and receive the lightning, it's an atomic swap. So you are giving your VTXO over to the server conditionally that the server is completing the lightning payments. Lightning payment fails, I don't give up the VTXO.

17:02 Exactly. Only on the lightning receive, the trust model is is that you are trusting the server to give you the VTXO. And the way that we remedy that is that when you do a Lightning receive, the VTXO that you receive on your device, you are able to immediately do a free refresh and take that VTXO and include it in a round. And then it completely like hits the reset button on the trust and you have absolute unruggable self custody on that money. Okay. And the DEWALLA is doing that automatically?

17:44 Should be. Right. And and best practice, it should the user is not, like, pressing the refresh button. Right. Is that you receive a light. What the way we have it is that VTXOs have a fixed lifespan. So we have intermittent timeout trees that are made on chain. So the Arc server, what it's doing is it's going intermittently on chain and constructing transactions. These are called round transactions. That transaction has a top root tree. The VTXOs are the outputs coming out of the tips of the branch of that tree. So when you hold a VTXO on your device, you are holding the fullness of a pre signed exit path, which you can use to leave.

18:33 When you part, you can take your VTXO that you already have. And every month you're refreshing your funds. When you do a lightning receive, the Arc server is signing that received for you on your behalf and then giving you the VTXO. And then right away, you can do that refresh and anchor yourself into the next tree. We're also looking at ways that we can have another cosigner on the Lightning receive to help improve the trust model. No. Almost like a federation. Yes. I saw Grubel's talking about who's also at Second, former Blockstream.

19:16 He was talking about the intricacies of the way bark works is you can't have like a normal seed backup. And I think that my understanding is it's it's because I I'm constantly getting new VTXOs or the VTXOs are getting are we getting refreshed and they're changing to different VTXOs. And so that there needs to be like some kind of cloud backup mechanism built in so that every time there's a new round or every time I make and receive payments that there needs to be a refreshed cloud backup. Can you explain that to me? It's a little bit hard to conceptualize. Okay. So what happens is, is let's say you're using Noah wallet. Like, let's imagine it from the perspective of the user. You do have a 12 word seed phrase.

19:56 That 12 word seed phrase is you get absolute, coverage on all your on chain funds in that wallet. All the layer one Bitcoin is included in that. What is not included in that seed phrase is that you cannot use the seed phrase alone to restore all of your exit paths. So the VTXOs, it's not just like a leaf. You know, it's not just a pointer at money somewhere else. The VTXO, the technical term in the code would be the Genesis chain. So there's a, when you hold a VTXO it's linking back to a particular on chain transaction.

20:37 And you could see my money really lives in that transaction in that block from like five days ago, that's where my money is living. And if I broadcast this transaction, this VTXO, then I could get that money on chain. Now that is stored locally in your wallet because the Arc server is not a custodian. It's not custodial. It's not trustodial. The Arc server is not keeping those on your behalf. You are just holding them in your own wallet. So there's cloud backup systems. Those are up to this particular implementation of the wallet. So Noah has its way of doing cloud backups.

21:21 RK has one that involves How does do it? How does Noah do it? Noah does real time backups. So when you're using your device and it's connected to the internet, you have you're backing up your Is that just an encrypted backup with, and the seed is the key to that basically? Yeah. The seed would be the key and the backup is of a SQLite database and the contents of that database are your VTXOs. It's all of your off chain money and all of the exit paths. Yeah, so the seed alone cannot retrieve those funds because if the seed is able to retrieve all of those exit paths, it must mean, you know, they're hosted somewhere else. That's not only in your self custody. Somebody else is holding them as well. And the ARC server, we don't have that. Like, that's not the way that the system works.

22:15 Got it. Okay. Well, like to go down this path. So well, first off, VTX oh, so you so an ARC wallet, a Noah, for instance, let's just keep using Noah because I obviously, it seems like each wallet could have slight differences in implementation. With Noah, you mentioned that my Bitcoin on chain transactions are just like native Bitcoin on chain transactions. They're not going through arc in any kind of real way. And I'm holding them as just regular UTXOs, and there I can retrieve them offline from my seat or whatever. Yes. And yes. Yeah. That's correct what you're saying. And if you have VTXOs, you can cooperatively turn them into my UTXOs.

23:02 Yeah. So you can have balance. Yeah. So what I was gonna ask you is, like, in practice, do you think what that looks like is someone that has a larger wallet, like, 90% of their funds are being held on chain, and then they have like a balance that the wallet is is is hopefully gracefully handling that is in VTXOs for on demand payments. Is that how you expect it to look in practice, or is no one gonna use on chain? In practice, the way this is up to the implementation specifics. Like, know bull Bitcoin wallet is really good where they show you two balances. Here's your on chain balance. It's like checking account and your savings account, basically. Right.

23:45 Essentially the way that Noah displays it is as a unified balance. So you do have a single unified balance that you're looking at, and that's the sum of all of the different discrete VTXOs that you have. And you're using this wallet for the purpose. And UTXOs. Right? But the intention of the wallet is to use it for these off chain payments. The intention of the wallet is to use it for lightning, is to use it for instant finality payments. That's why you would have it on your phone next to your other wallet as your daily driver. Yeah. I mean, bull is trying to be kinda like a jack of all trades. Like, you can use it to interact with your cold storage. You can have a balance on liquid. You can have a balance on chain and they kind of show it all to the user, which obviously I think can be very beneficial for power users, but it's hard to imagine like the average user balancing all of that. So that makes sense to me, and that's on a wild implementation detail.

24:45 So then with UTXOs, we have like, how do fees work on on Embark? Like, dude, is there any trade off of having a lot of VTXOs versus having a few VTX? Like, let's say I have a 100,000 sats, but it's a 101,000 versus one large a 100,000 sat VTXO. Does that have a higher fee burden? Is that something that users should even be thinking about? How does that all look? The way that we have it set up is that if you're transacting with other people in the same arc, there's no payment fees for sending and receiving Bitcoin. Okay. We also have it so that lightning receive is free.

25:28 So you don't pay any fees as you're receiving lightning payments. And then when you're making an outbound Lightning payment, that is where you're charged a fee. It's the same fee if it's an outbound Lightning payment or if it's an on chain payments. And the reason why is that that is what creates the liquidity burden on the Arc server. So the Arc server is going and making a payment on your behalf, be it a Lightning payment or an on chain payment, something leaving the system of the Arc itself. And it has to supply that liquidity to complete. Ahead of time too. It has to lock up liquidity ahead of time, basically. Right. That's correct. It has to have the money already on hand. It has to have the outbound sending capacity to send the Lightning payments in order for your outbound payments to complete atomically.

26:18 So that's where the fees are generated. So if you are receiving money into the ARC and you're spending within the same ARC, there's no fees applied to the user. But as you're leaving the ARC, there is. Regarding the quantity of VTXOs. So we do offer VTXO consolidation. And what happens is is that this comes into effect when you have to do the refreshes. So because each individual VTXO has a fixed lifetime. Is that two weeks? Am I correct on that? It's four weeks. Four weeks. Okay. Continue. Yeah. Twenty eight days. So what you would have to do is you would either have you have to come online and manually refresh or you can delegate your refresh over that somebody else can come online on your behalf.

27:05 So for example, with the wallets right now, we have Noah, we have RK, we're doing a delegated refresh so that I I'm a user of this wallet. I I just have to come on one time within the month in order to delegate my refresh to the server. And then the next round can happen without me needing to be online at the time of exact time. Yeah. I don't need to be online at the exact time of the round because I can delegate my refresh. Which is unrealistic with mobile. Right? Like, that's just not a It's very yeah. That's It's a very massive coordination problem. What is the so then but if I don't come on within a month for my wallet to delegate it Yeah. What happens then?

27:51 What happens then is that the ARC server has the ability to sweep your funds and take the money from you. In practice, we allow users to refresh even if they miss the window. This is up to the particular Arc server operator as to how they want to handle that situation. And something about this refresh is that all of these refresh requirements, they go away with a covenant protocol change to Bitcoin. Well, you're not gonna get that. So That's okay. While we're talking about protocol, does Bib one ten break all of this? No. It doesn't. No. And, yeah. And the if you look at how many bytes the transactions are, it's under the 80 byte limit. So we So you are using upreturned?

28:35 No. We're not using up well, the amount of space that the transaction takes on chain is minimum. That's Got it. And so so every month there's act on every twenty eight days, there's an actual on chain transaction that's happening with every participant? Not with every participant. So what happens is is that throughout the day, every hour of the day, there is the possibility for a round transaction to happen. Different people are doing refreshes at different times. So the system is asynchronous. You're not having, the whole system. You're not counting on all users of the system to participate all in the same round together. Can and you could be in a round with one set of people in the previous round. And then as you get to the next round, it's a different set of people that you're with in the next round that you were the previous one. You're not locked.

29:24 Trees are very dynamic. Like I mentioned, there's a taproot tree and you have your VTXO as part of that tree. Every tree that you participate could have a different set of participants in it and the shape could be different as you're moving forward through time. But at the end of that day, there is a Bitcoin transaction that is sent out. There could be multiple in a day. There could be four a day. There could be eight a day. Could be one the same day. No? Are they You can rephrase your question. I'd love to clarify. Is it just is it a rolling twenty eight days? Is it just a like, it could be a if you have enough users, there's a transaction that's there's one of these refresh transactions happening every day? Or is it like a global today is today is July 20. And it's, it's barks refresh day. And, you know, in twenty eight days, there's gonna be another Barq refresh day. Do you not understand what I mean?

30:18 That happens every hour. So every one hour, there's the opportunity for a round to happen. So the ARC service says, hi. Now we're on the hour. I'm now collecting participants. If anybody wants to become a participant in this round, come join right now. And then they come with their old VTXO that they want to refresh. And then they submit that as part of the round and then they move into the next tree. Got it. There could be four in a day. Then who's paying these on chain fees? Isn't couldn't that be prohibitively expensive? Paying the on chain fees. The ARC server is paying the on chain fees.

31:02 And the economic, yeah. Ideally they're getting paid for it through those lightning fees. Exactly. Through outbound fees. So through making outbound lightning payments and making outbound on chain payments, it's collecting fees. And then that should be enough to justify the Yeah. On chain mean, right now we're in this, I mean, I don't know if you're familiar with my history, but one of my worst calls ever was Mempool's will never clear again. And I mean, right now we're in this like beautiful period of, I guess it depends who you ask of incredibly cheap on chain fees, which is when people tend to forget that on chain fees can go up. So that's why I'm just, and I'm I'm a broken person in that regard. So I'm fine with assuming that on chain fees will never go up again. I think that'll probably age poorly, but I'm also not trying to die on the hill. But that's my question. Like, if fees are like a 100 stats per bite, and you're doing transactions all the fucking time, that could get prohibitive. That could get significantly expensive.

32:04 The ARC server would have to Figure out a new list of fees. Or something. Yeah. Well, if on chain fees are that high, that means that there's a lot of demand for payments happening in Bitcoin. So you could imagine probably it's on chain transactions might go up with lightning payments as well. Right. This is speculation. We can't know for sure. Think personally that a high on chain fees are higher, then people might be more likely to use a Bark Wallet because they're trying to save on chain fees in the first place. Absolutely. And people would be much more likely to use Lightning since lightning was a solution to blockchain scaling. The solution. Yeah. Interesting word. Okay. That makes sense to me. Think so then am I in practice, but is there any negative?

32:51 I guess there's a negative to the arc server for me refreshing more often than every twenty eight days, but to the user, it doesn't seem like there's a negative are in a, is it like, is it our wallets? It doesn't know, like hard cap me and that I can't refresh earlier than twenty eight days or am I just refreshing all the time if I'm keep opening my wallet? What we do is that. So there's a twenty eight day lifespan in total within the last two days of that. So days twenty seven and twenty eight, the final two days, there's a forty eight hour window where the refresh is free. So you can refresh for free in that final forty eight hour window.

33:34 If you want to refresh earlier, you have to pay in order to do There's the answer to the on chaffee But if you are already coming online in that window, you could also delegate in that same time. There would have to be some type of reason. Oh, I could delegate on day 14. I don't have to show up on day 27, '28. Exactly. Yes. Got it. Because that would be the negative from the user point of view. It's like, I use my wallet every day, but then I don't use it for the week that matters or something. The user wants to maximize their refreshes and the server wants to minimize it. That's the dynamic.

34:15 Because every time that you participate in a round, it's like clearing the slate. Like you now are completely anchored in a new round fresh tree. It's a position that you want to be in and, you know, nobody can ever take your money of absolute self custody for the lifetime that that tree is there. For those twenty eight days until it refreshes. Yep. Okay. So let's I think this is an interesting way for me to try and understand the trust model better. Arc server goes down. I have a million sats and know a wallet. I don't know when you're gonna come back online. I assume the worst. Everyone's panicking. There's angry tweets going out. What what as a user, what does that look like to me to recover my funds?

35:01 I'll clarify that there's two different situations of the ARC server going down. First of all, there's an ARC server goes down because of a technical issue and it's brought back up online and restored. Right. And that time when the server comes back online, operation can continue as normal. Like nothing happened. Like nothing happened. It's just like we, the ship keeps sailing. The issue is is if ARC server goes offline indefinitely or if it was taken down and it's never gonna come back up. Or it's been three days and I don't know if you're gonna come back online or whatever. That's true. Yeah. That is also valid situation as well. Then what the user would do is that they would take their VTXO, which they have on their device, and they would broadcast that as a transaction on chain.

35:49 What that would do is it would begin to unwind the previous payment tree. So the tree is not just only the tips of the tree where the VTXOs live. There's a root transaction at the bottom of the tree, and then you have node transactions. And then you go up these branches all the way up to a leaf transaction. And the output of that is the VTXO. So you would broadcast your VTXO and it would take multiple Bitcoin transactions for you to receive the final total sum of your money. So there's a couple of case studies that you can some people have made some tweets and we'd like to put out some more content about walking through how this works. Yeah.

36:31 But you're you pay on chain fee to broadcast on chain transaction. And it's not just all at once. There's multiple transactions that you're making because that's the tree unwinding on chain to send you a And now is that fee super high because it's, you know, thousands of people's transactions are a part of it or how does, what does that look like? Well, the fees have been pretty minimal so far. You would have to check. The fee rate is very low right now as well. So it matters. It's nonexistent. It's basically zero. It's like It's not currently, it's a nominal amount. Or something. Yeah. Yeah. It's we're it's still it's another sub one sat vivid summer. Right? It's year two in a row for that. But my under I'm trying to I'm trying to figure out what the fee burden I'm trying to conceptualize in my head what the fee burden looks like versus me sending a single let's say a normal transaction. Right? Yes. I have one input and two outputs.

37:26 Right? There's like probably for the average person that is a very common on chain footprint and fee burden that they would pay. Would this fee be significantly higher than that? I guess it kind of would, right? Or no? I think that this would be a great opportunity to deliver the community a comprehensive. Okay. You are the head of research. I think that the correct answer is to not speculate with you, but give you the solid number. So then from that point of view, I'm just running all over the place. I hope you don't mind. From that point of view, wouldn't I have to do that for each VTXO. Right? Yes. So wouldn't as a user, I'd be strictly better if I just had a single VTXO that was always, like, consolidated just constantly? Like, of having a thou having a 100,000 sat VTXOs, I just had one a 100,000 sat VTXO that I needed to claim on chain.

38:23 Yes. The user wants to maximize their participation in the rounds and the server wants to minimize the number of rounds that happen because of the So the consolidation is happening every twenty eight days is basically a consolidation round? Yeah. The user would consolidate their VTXOs as they participate in a round. So they come to a round and they could submit So many I have, I did 20 And then they get one out. Got it. So that's when the consolidation is happening. That makes sense. Yes. Don't hold all the VTXOs indefinitely. Like I have my NOAA wallets. I looked last week, I had like 15 VTXOs and then I came back and I found, oh, now I only have one for 270,000, sats.

39:06 Now when you consolidate on chain, the big trade off, you get a great cost benefit for the future, but the big trade off is basically privacy. Is that is is is there a privacy trade off there with VTXOs being consolidated in the virtual environment? How does that look? So the ARC server does not keep a particular, say, user ID on you. Right? Like Right. So when you're transacting within the ARC, you get different ARC addresses, and you can practice all of the same address reuse safety practices that you would with on chain Bitcoin. But if you were participating in a round and you could see multiple VTXOs being refreshed into a single one, that could be exposed to the Arc server that those do belong to the same person.

39:56 But doesn't the ARC server already see every transaction that's happening? It does already see every transaction that's happening because it's a cooperative partner on the co signing every cooperative action. If I'm sending money to you, I'm taking my VTXO and I'm making a payment to you. I'm extending one. There's like a the same way that you could follow on chain. You could see here's my UTXO, it goes into a transaction and here's a change output and another one. The same thing is connected. If you look at what it looks like inside the Arc, it really does resemble what you see, say on Mendpool space. Right. And the arc is cosigning all of those cooperative actions.

40:39 So it would be able to know that. Yes. But does it does it, okay. I'm, you know, in a small circular economy where we're like spending natively using bark. I give someone a fresh bark address. They pay me. I get a VTXO. Yes. Then I, I, I don't know. I go do something I don't want them to know about, and I get paid for something else with a different VTXO. Is there a way for the user endpoint, the person who paid me the first time when they consolidate, see those two payments are connected. Is there like a block explorer type of scenario or something like that? No. Even buy No. Those something like We do not have bark scan.

41:28 There is no bark scan. There's nothing like that. It's true that when you're using Arc, the particular Arc server, because they're cosigning the cooperative actions, they can see those transfers. But if I'm sending you a payment and then you continue along your merry way, I'm not gonna be able to follow you and watch all the other people that you did. Right. I'm not gonna be able to look you up in an explorer. Okay. And then the ARC server, when I'm trusting the ARC server with this privacy, does that have to be basically like active surveillance? Is that like almost similar to like a VPN trust model where if they'd have to be logging to be able to do this or is there actually a, do you know what I mean? Like Pat, like the reason that on chain privacy is is, I think, so dangerous or or the lack of on chain privacy is so dangerous is because an attacker can look back on the chain in ten years or whatever. Like, a mistake you make today is there forever. They don't have to be, like, actively surveilling you as part of the of the threat modeling of on chain Bitcoin that makes it so difficult.

42:35 Is is that a similar situation here? Like, is there like literally just always this chain of VTXOs that I cannot, like, think about, like, a blockchain that's being held by the ARC server, or is it in a best case scenario, like, the ARC server is just only keeping the last, I don't know, so many VTXOs? I think this is a good point just to clarify that ARC is a protocol. BART Okay. It like, I can run an ARC server. You can run an ARC server. You know, we can modify the code of the server. Right. The way that a particular server operator could decide to operate can change from ARC to ARC. Right. That's my question, I think. Yeah. So the way like, you could have one ARC server where the person who was operating it is logging in one way and you could have the identical code on another server and the other one is hosting it in a different way.

43:34 Our CTO, Eric De Smits, he made a tweet and he says, if we build this protocol and there's only one ARC server and it's operated by us, we failed. What we're aiming to build here is an open protocol so that people can use this. They can host their own ARC servers for their own communities, and they can use software that is a 100% open source to act as the liquidity manager for the payments. You're right. People are free to just like any open source project. They can fork the project. They can change it. They can monitor this way or that way. But if you examine the protocol itself, no, it does not do that. It does not track this indefinitely. That's what I'm saying. The server would have to be doing like active logs for that purpose kind of. Right?

44:24 Does that make sense or no? I understand what you're saying. Yes. This is the VPN trust model that this VP, that the person who's operating the VPN or the server would have to be actively watching every person and making And putting in a database. Yeah. Yeah. That is outside of what the ARC has by default. But like, it's still yeah. Okay. So that's actually that's a decent privacy model. I agree. Yeah. Okay. Well, I'm glad we agree. That's interesting. Okay. So there okay. So fees on VTXOs are basically fee less. So I, if, if I'm, there's no, I mean, let's, let's put my noster hat on for a second. A lot of noster users, they create a wallet and then like their first payment is pennies, like 21 shots or something.

45:21 If that's the case on an arc enabled wallet, they just received 21 shots. Now, obviously they can't economically come back on chain until the balance gets higher, but there's no negative effect for them on risk. Like their first payments being absolutely tiny. Right? We do not block dust transactions, you know, so you can make tiny arc payments between various different users and we still allow those payments to go through. It would be up to the user to consolidate that and exit on chain. They would have to, they would have to do that, but we don't prevent people from sending each other over ARC a handful of stats. But there's not really a negative to you as the ARC this ARC server operator. Right? Is there really a negative?

46:05 Is there a negative? Well, the DOS vector. Oh, yeah. Let's talk about that. Where is the, what is, what is the DOS vector here? That was actually something I wanted to ask because of the rounds. Like when I hear rounds, I think denial of service. Right. Well, what happens is, is that when you're making arc payments, if I send you an arc payment, I have a VTXO, the payment is actually extending out of my VTXO over to you. So we have my payment goes through something called a checkpoint transaction and you're the recipients. And when you inspect your VTXOs, you can see that your payment really did come from me. We're not doing swaps with a central service. We're not swapping VTXOs back and forth. I'm actually making a direct peer to peer transaction to you.

46:55 Now, if you, every step along the way that you keep doing that, the trade off is, is that yes, these payments are all free, but the weight of the chain is getting heavier. So you can imagine that the VTXOs have this weight to them. So when it comes time to exit a VTXO that has a very large, history of transactions that happened within the last twenty eight days, that will be more expensive to exit because there's more data encoded in it of the full chain of the pre signed transactions. And we do have an upper limit as to how far that can go. So that prevents people from spamming indefinitely.

47:39 You can't just make arc payments that are free back and forth forever. So I have one set payments or whatever. Exactly. There would come a point where I say, no, you have reached the maximum height for this, this lifespan of the tree in this month. So you would have to refresh that VTXO to continue. That's at a height of one month. And you either wait for the twenty eight days or you pay to refresh. You either wait for the twenty eight days or you pay for the refresh. And this is something that's alleviated by LARC, which is the lightning inside of the arc. So you would be able to use channels inside to redenominate the balances without needing to add more links at the end of the chain to make it heavier.

48:19 But that addresses the DOS factor on the server. Yeah. But you still have to, that, even with Lark, I mean, that would be, you're assuming a benevolent user. You're assuming for, because if I was an attacker, I wouldn't use Lark. Right. You say you still wouldn't need to protect against that. Right. If you were an attacker, you would go after the If I was an attacker, I would use like a vibe coded client that was just spamming really small payments. Right? Yep. And that's the benefit of ARC as well is that you can have this client variety of clients as well. Okay. That's interesting. Okay. So what about just tell me to go fuck myself if you don't want to answer this question.

49:03 But you said that for your your for seconds, for the current the current arc instance, the current bark instance or whatever, the one that that second is running the arc server for. If I decide to touch grass for two months and I haven't delegate, I haven't opened the app. I haven't opened the app in forty days. I'm technically past the twenty eight day window of opening the app at least once every twenty eight days, which I think for like 99% of people, they're opening the app once every twenty eight days. It's probably not that realistic. But there's scenarios, there's scenarios where a bear market happens and people are like, I don't believe in Bitcoin anymore. And they just forget the apps installed on their phone. Or maybe I onboard someone who doesn't like Bitcoin yet.

49:47 And you give them a $100 for their wedding or something. And then they forget the app exists. Right? And so you said, I guess it's on a server by server basis, if they're gonna how they're gonna handle that situation. But with you guys, there's like a grace period. What that that that's a completely trusted model past twenty eight days? You're trusting the server to not rug you and to give you the VTXO back. Right. Or to the last thing the VTXO at that point. I'll I'll clarify. I'd like to clarify how that works. Okay. Go. Not not I'll I'll get back to you on that.

50:29 Oh, not not right now. Okay. Not right now. Not right now. Yeah. We won't hold you to The server does give you the ability to return, but I wanna make sure I give you a precise answer as to how that happens. Well, I'm just thinking from like an operator point of view, let's say bark is a massive success, you know, and it's around for a while. Like there's going to be presumably more and more funds that are, I don't know, like a hundred days inactive or two. Is there a way to is is I'm now I'm just thinking out loud. Is there a way to force it on chain? Because the nice thing about on chain is that it's push, not pull. So like, like, it'd be kind of cool if the server could just be like, yo, you've been inactive for a hundred days. I don't care if it's uneconomical to you. I'm just gonna push all your funds to this on chain address that, you know, is backed up by your seed and that that's on you because you just haven't showed up. I like your idea about the on chain because people already have an on chain wallets with BDK if they have an arc wallet.

51:35 Yeah. That's what I'm saying. So you already have an on chain address you can send it to. Yeah. I think that could be a great opt in service for users to use. I'd also like to point out that not all use cases of Bark is just people using it in a regular wallet in an app. For example, we did a project with Tando in Kenya, Africa recently at the Bitcoin plus plus Nairobi, and found that there's this huge market in Africa for these mobile money payment gateways. And they have always online servers that are receiving Bitcoin payments inbound that they have to either use an LSP like Phoenix already in order to receive payments or manage a Lightning node themselves.

52:16 But if they're running a BarkDaemon there, they can start receiving those payments instantly and then pay out the local mobile phone monies to the various different African countries and users there pay bills on demand and, you know, even pay for a coffee at the store, regular payments like you would use at any payment terminal in America. And they don't have to worry about the liveness requirements of Bark. So there are many situations where there is great utility in being able to use this to receive payments, to operate a payment gateway that is not just the traditional model of, you know, here's my Knoll wallet app. I'm sending money to you. There's Mavapay in Africa where you have various different people. One person's in Nigeria, another's in Africa, Senegal, Ivory Coast, and they're all maintaining Bitcoin balances. And then they're settling with each other over Lightning that, well, what they could really do is that they can actually have this all move through the arc gateways.

53:16 And you can even use Cashew to melt a Cashew balance directly into one of these mobile money gateways in Africa. So there's a lot of use cases. There's a lot of really great niche scenarios where this comes in that is not just people having a mobile phone app that they use to buy things that like an end user. Yeah. There's a really important place where this sits at the infrastructure level too. Right. So, I mean, on that note, I saw Cali talking about bark plus cashew. And specifically, I think it was in reference to, like, federating a lightning node using bark so that it wasn't a single lightning node provider. What what benefit from your point of view?

54:04 I mean, I know this is all, like, very, like, bleeding edge and new, and people are, like, thinking about it from, a cashew operator. What advantages do they have using building their cashew mint on top of bark or using bark in addition to their cashew mint versus like just their traditional structure, which is effectively a a Bitcoin powered lightning node? Yeah. So right now cashews, you got the mint in the front and you got the Lightning node in the back. And whether it's a cashew mint, a mobile money gateway in Africa, or a wallet like NOAA RK, these are just modular puzzle pieces. So you unplug the lightning node and you can plug in a cashew mint.

54:48 And what that allows you to do is now the cashew mint is holding VTXOs as its balance of its reserves. And it's issuing liabilities out to people. What's really good about this is that one of my favorite things about cashew is that when you make cashew payments, the Mint is blind to the sender and the recipient. So the Mint doesn't know about the discrete users of its system. It's sending people can send and receive cashew payments. And the Mint knows that it has issued liability, but it doesn't know that Alice sent the money to Bob. It has no conception of that at all. And this composes really nicely together with bark, because when you have a bark powered cashew mint, you can do a proof of reserves scheme as well.

55:36 So what a mint can do is a mint can self spend. So this is an Arc payment. It's not a refresh. So you don't have to worry about the twenty eight day rule. What a Mint can do is it can pay to its own address, which is also its Noster pub key. So a mint has a pub key and you can verify that it's paying out Bitcoin through ARK to itself. So, know, at any given moment, this mint really does have this much money on hand. So when you're holding an e cash token, you know, my token is not it is still possible, that they could rug, you know, they could withdraw the money out. This would compose nicely with the unruggable mints, the proof of liabilities, but these are all just modular puzzle pieces, right? So we could be transacting with cashew, but you know that if I use this cashew mint that is backed by a Bark client instead of a Lightning node, I have absolute cryptographic proof that that mint has at least one BTC inside of it in its reserves. But how do I verify that without Barkscan?

56:44 What you can, what the mint does what the mint does is it voluntarily publishes an attestation. It opts in to sharing this information and you can take that bundle and run it up against the RPC of the ARC server and it will either pass or it's going to fail. And so in this situation, you would assume that the ARC server is being run by someone else though. Exactly. Yeah. The ARC server would not be run by the same person that would be running the the cache and mints. That's how you would make that. So I take the cryptographic proof, go to the ARC server and then the ARC server is like, yeah, the funds are there. Yeah. And that's completely dependent on the mint being transparent.

57:33 So somebody, when they're using a cashew mint, they would say, well, it's my preference that I use one that's transparent about how much money it has on hand. And that way, if people are making payments, you know, that Mint, you can move between Cashew tokens and Arc wallets or Cashew tokens to that particular mobile money gateway, like the Tandem one, the Mavapay one in Nigeria and so on. You could go from a completely blinded balance inside of Cashew to melting out of your mint into that payment gateway without having to pay a fee. That's cool. Yeah. That's pretty awesome. It's all coming together.

58:15 I had one more question on the front. No. I mean, know Cali I'll have I have to have Cali back on the show sometime soon, but he's making he's just I don't know what I'm allowed to publicly I think it's mostly all open source, so probably if you're following his GitHub repo, I don't know. I've had private conversations with him. So I'm not going to talk about what he's building right now. But there's just a lot of different things you can do to improve the trust model for, you know, I think one of the cool parts about cashew in the beginning was, it was just very, very simple, which allowed it to as an open source project to just improve very quickly and roll out very quickly and people implement it very quickly.

58:56 But as a result, it did obviously revolve in a lot of, a lot of trust with the cash you meant operator. But there's different ways you can reduce that trust. And bark seems to be one of the key ways of doing it, at least on the proof of reserve side, and then also interoperability. I know he publicly tweeted about using Ts, so I can definitely say that. But there's other aspects there in terms of reducing trust because the the one of the key issues is is proof of liabilities, like, showing proof. So, like, you can do proof of reserves, but can you do proof of liabilities? No. When you have perfect privacy or technically perfect privacy within your anonymity set and it meant. And then the other piece is exiting, exiting if something something is offline, the infamous unilateral exit. So the, I guess the last piece that I'd like to talk about while I have you, and I also would just love if we touch back at some point in, like, six months a year. I feel like all this is moving really fast, I'm just trying to understand it as as things are going on. So I think that would be very helpful listeners.

1:00:12 But right now, what we're seeing is we're seeing a lot of wallets move to Spark, which is the state chain implementation that at least for the end user offers a lot of similar use cases, I would say to ARC. And it's very confusing that the names rhyme, but in there, both kind of came out around the same time too, but has a a strictly different trust model. But from the from the there's like two different users here. There's like users of end wallets. And then there's people that are are building wallets and managing wallets and maintaining wallets. And from the maintaining of wallets point of view, it seems like a lot of wallet teams have moved to spark because it's relatively easy for them to implement.

1:00:59 So when I'm sure you guys are talking to wallet teams all the time, like when you talk to them, is it much more difficult to implement Arc versus Spark in your like wallet infrastructure? I would say that it's just as easy. And I would say that implementing a unilateral exit on Arc, on Bark comes by default. So it's much easier. I would argue to make an implementation in a wallet that has a full unilateral exit with Bark than with Spark. Got it. I think that for the end user, what they see from their own experience, Bark and Spark, they both live at an infrastructure level.

1:01:48 So you could have a wallet with a user experience that's 90% the same. You know, they're sending and receiving Lightning payments without channels to them. They don't see any difference on their end. But on the infrastructure side, Spark is not an Arc implementation. It's very different under the hood in the way that it operates. It's not the same thing. It just has, it rhymes in the name, but for what the user sees yeah. The what from what the user sees, they're offering a very, very similar niche. They're solving the same pain points. They're competing in the very narrow use case of Bitcoin payments on mobile.

1:02:32 But I would say from like a wallet provider standpoint, there's been a lot of I think a combination of Lightspark, who's obviously like the father of spark and them having a them having a war chest. Right. And intense, not intense, intense is the wrong word, decades of experience in regulatory compliance. You know, David Marcus came from Facebook previously dude is like a tech OG in his own right. In terms of like big tech and has a lot of regulatory compliance background. They're funded by a 16 Z. And then Roy with Breeze did a lot of work on the SDK side.

1:03:15 So that it's like relatively handheld. Like, it's it's hard to like mess it up. Is do you think bark is at that point right now? Like for some like a team that wants to implement it? I mean, Absolutely. Yes. I think so. I think that we have the proof is in the pudding when people can use Noah wallets, they can use our K wallets. They can soon get up and running with the bark powered cashuments. They can see that we're processing the volume of payments. Bark is really easy to integrate. People can vibe code the wallets pretty straightforward. And by default, you don't have to do any extra work as a wallet provider to make sure that the VTXOs, which are required for the unilateral exit are in the absolute self custody of the user. That is like the default behavior that we launched with, even when we were on Signet in our test net. This is not something that came later. It's not something that we promised down the road. It's something we always, always have had. It's part of our system that you hold your VTXOs on your device. And when you move the money from one person to the next, it's a true peer to peer direct payment from one person to the next.

1:04:26 And that is the default behavior of the SDK. You could even use Bark in the in the command line. You know, you could spin up one of those open source wallets. Don't put it don't put don't put your system in an LLM. You know? Yeah. But, was this so then, I mean, on that note, there is a how how hard is it to run a Bark server? Is that is that still incredibly technical? It's not incredibly technical. It requires a little bit more of it it requires a little bit more resources to run one in production. If you wanna do one just to play around with, then it's easy to set up on NICS. You know, you could clone the repo and then say, hey, can you make a little NICS environment for me, like a little virtual computer just in my command line? And you could play around with it. But right now we're onboarding people to the ARC server that's operated by second.

1:05:24 Right. And in the long run, we want to see more people running independent ARC servers. We talk about how ARC and Spark they're here. They're working in a very, very similar use case, but where Arc is really different is that we are not building this just so we can have a short term profitable company here. You know, what we're doing is we're building our project is categorically similar to Lightning itself. You know, we're building payment infrastructure that will last years, decades down the road. Even people will be able to use this in order to manage liquidity for Bitcoin payments. That is the vision. That is what we're supporting. That is what we're here to build.

1:06:05 Yeah. I mean, I don't think you're gonna be short term profitable. So I think you can have to build with one. I mean, I think putting my investor hat on, think it's gonna be hard to make this. I don't know where the monetization and like, if it's protocolized where the monetization happens, I'm not going to put you on the spot. I think it's probably all in, you know, you kind of just go with the flow and figure it out as you go along. But if there's like a 500 different ARC servers and you guys are just running one ARC server and just making money off of Lightning payments, I don't think I don't I don't know if there's a lot of money there. There's gotta be other revenue streams. Let's get to to our service before it gets to 500. Fair enough. The other piece, what's the trade off between and this is one of the reasons it's so hard to grapple with.

1:06:54 If I'm a wallet team and I'm thinking about, okay. I got Spark. I got Bark. Then I got Arcade. What about Arcade? How do I choose between which one to do? I think Arcade is good too. I like Arcade because they're aligned with us in our mission for open source software. I think that their product does what it says it does. I think that Arcade is really good for stablecoins. They are back to Yeah. Grubles hate stablecoins. So can I not use stablecoin? Can I not use USD tokens on Bark? No. You can't. So if you're Bitcoin only, you go with the Bitcoin Arc, which is Bark. And if you wanna use USDT, then you could go with Arcade. That's a Do they already have I'm USDT on not certain. You'd have to talk to them, but I know they have stable coin support and they're doing DeFi. That's their vision. Our vision is not that. That's the other thing. I mean, that's also I think, without putting words in his mouth. I mean, I think it's pretty obvious if you watch this also Lightspark's vision.

1:07:57 I think Flash I think his son's company, that's what they do is they do USD tokens on on spark, and they're like live in the open. So do you not think? I mean, I tend to I ideologically agree with you. I think Bitcoin's the best money. That's interesting though. Is there a technical limitation on why you can't do why couldn't you do tokens on? Because that's not what we're building for. We're building to push Bitcoin painless to its absolute maximum. And that's the vision of our company. That's our company's mission is that all of this work has been done so far to build Bitcoin Lightning. People have used custodial wallets, we're saying, we wanna take this to the masses. We wanna make this production ready that people just use Bitcoin only. Yeah.

1:08:45 Production ready. Shout out. Shout out, Samson. I mean, I figured that people have gotten to this point. They understand that inside joke. You think there'll be wallets out there that have Bark implemented for the Bitcoin side and then implement a different stack for USD tokens? Like, there's nothing to stop that. That's kinda is it like, and it might not it might not be Spark or Arcade. Like, it might be like Tron USD and then Bark. I think there is one that is like that. They have the Bark is siloed entirely for the Bitcoin only. It's the application out of France that's related to the Ozark. It has a name similar to that. And they have other things in their wallet. They have stable coins in there, but the part that is operated by Bitcoin, the Bitcoin is a 100% run by bark.

1:09:40 They have Bitcoin Lightning on chain. That's all the bark. And then you go to a different part of the app and then they have like a USD token or however they're doing it. And the two sit side by side in the same application. Is it listed on your website? I don't know. No. I don't think it is. There's nothing that is Ozarks related in here. Okay. I'll find it. I found them on Twitter. That's kinda interesting to me. I mean, if you do wanna add USD tokens to your wallet, I mean, I think there's a good argument that you would do the one with the best network effect, which is probably as much as I despise Justin Sun Tron USDT on Tron, or, like, if we wanna be like regulatory compliant, American stablecoin purveyors, USDC on base or some shit.

1:10:32 And then you have like a really solid Bitcoin infra for the Bitcoin payment piece. And then from the user point of view, they, I don't know, handle it with swaps or some shit. Bolts can do it. Like the liquid moss. Philosophy. Do one thing and do it well. Make it as as possible. I respect that. Okay. Awesome. Matthew, this was great. Is there anything you wanted to cover that you think we didn't cover? I think we gave a good overview of how the technology worked. I think that I was able to highlight some great projects that we're doing at the infrastructure level too. Like for example, the cash and mints and the African mobile money gateways. So we see bark is not only to power your mobile wallet, but it's also there making payments happen behind the scenes. And we got a taste of the ideology of the Bitcoin arc.

1:11:26 So I think we covered all the bases. I think that that could actually be a good business model, like the B2B SaaS stuff. I don't know. I'm sure you guys are thinking about all this stuff, but what is it like the red hat model or whatever, like enterprise level support, stuff like that. Okay. Awesome. I enjoyed it. I thought it was a great conversation. I I would just reiterate to people. Noah's really cool app to like, they expose a lot of things to the user. So it's a cool way to maybe download Noah. Is it in the app store yet? It's currently still test flights and APK. You gotta go to beta.noahwallet.io. Okay. Noah and then Link in the show notes. Yeah. I'll link it in the show. Well, I'm gonna link your you had Google's Google sent me your built with bark page that just like lists all these, which is great. Perfect. So I'll link that that just links to all the other walls, but Noah's nice because it exposes so much to the user that when you're trying to like understand how all the shit works, it's nice to have it all exposed. But then also I would say you gotta try out Arky, RK, at least just the onboarding flow because it's just a while. I've never seen a wallet like that before. It is the most, I don't know. It's just different. You get like a person in like nice dress, like speaking to you and shit. It's a you gotta experience it to understand it. Just download the wallet. I think it's got some interesting design elements to it that make it very interesting. And but as as per that case, like, I think it's intentionally designed to show the user less stuff

1:13:01 Because it's trying to be for someone that maybe never used Bitcoin before and is trying to use it for the first time. Awesome, Matt, thanks for joining. Any final thoughts for the freaks before we wrap? Arc is the future. Arc is the future. I love it. Straight to the point. Freaks, I hope you enjoyed the show. As I said, next week is SoapMiner. Share with your friends and family. Love y'all. Stay on the StackSets. Peace.