{
  "episodeId": "SLP645",
  "speakers": {
    "stephan": {
      "name": "Stephan Livera",
      "role": "host",
      "tag": "STEPHAN"
    },
    "steven_roose": {
      "name": "Steven Roose",
      "role": "guest",
      "tag": "STEVEN"
    }
  },
  "segments": [
    {
      "speaker": "stephan",
      "time": "00:12",
      "start": 11.75,
      "text": "Hi everyone, you're watching Stephan Livera podcast brought to you by Bold. For American listeners, go to getbold.io to buy Bitcoin. Now, rejoining me on the show is Steven Roose. He is the CEO, and co-founder of 2BTC, and they're at one of the teams working on ARC, which is another El- L2 for Bitcoin, other than Lightning, and we're gonna get into this, obviously there's a bunch of different things. You guys have this Signet launch, and you have, you know, a bunch of things going on, but, yeah, first of all, welcome back to the show. Thank you. Very excited to be here. Thank you for having us. Yeah. So I know there's a lot of different things happening. So let's try to, I guess, set the stage for people. This is another L2 for Bitcoin. What is the promise here? And as I understand, you're trying to use ARC to also make Lightning better. Is that kind of one way to understand it, or are you, you're trying to use ARC as a way for more people to use self-custody Bitcoin? So can you elaborate a bit on the high-level vision here? yeah,"
    },
    {
      "speaker": "steven_roose",
      "time": "01:15",
      "start": 75.04,
      "text": "sure. Yeah, so, we think Lightning is great, for people that do really high volumes, but we noticed that end users like individuals who just want to make occasional payments are really struggling with, a self-custodial Lightning setup. So ARC is a, a different second layer protocol that works entirely differently than Lightning, but it's, it's compatible with Lightning as well. So, so end, end users who, who don't want to have a whole Lightning setup, they can use ARC, they can still pay Lightning invoices and pay anyone who's on the Lightning network, but they don't have to manage their own channels, they don't have to manage, the infrastructure that is needed to run Lightning, because ARC is a client-server protocol, so it relies on some server, but the server only- Is there to, to help the user make its payments, but it's never taking custody of the funds. So the, the, the ARC protocol is totally self-custodial, but it's basically making it easier for users, to make Lightning payments and, also on-chain payments or just holding, holding your money."
    },
    {
      "speaker": "stephan",
      "time": "02:19",
      "start": 138.61,
      "text": "I see. Yeah. And just to summarize, I guess just for some listeners, obviously some listeners are quite techie and developers and they get all this, but just for the non-developer listeners, the idea is with a lot of, Bitcoin You know, payment apps, what's happened is some of the complexities of Lightning have driven and pushed a lot of people to use custodial Lightning apps, things like Wallet of Satoshi or, you know, others out there or KYC Lightning, you know, things like Strike or whatever else. And again, I'm not criticizing, obviously, I want more people to use Bitcoin in general, but of course, it would be good for more people to have these self-custodial options. And what was it that drove them to that? It's these, as you mentioned, things like having to manage our Having to manage, the liquidity, the, how much is on that side of the channel and what are the fees if I need to go to chain. And so I guess these are some of the things that, you know, if you were to try and do fully self-custodial lightning These are the requirements. So can you explain a little bit about why you see ARC alleviating some of those concerns?"
    },
    {
      "speaker": "steven_roose",
      "time": "03:25",
      "start": 205.19,
      "text": "Yeah. So from, from, from our perspective, there's two main big hurdles for having self-custodial lightning. One is that you need to manage your channels, right? So you need to create them and occasionally close them or refund them or rebalance them, and any of these interactions, require on-chain transactions. So currently we are at an, a historic low when it comes to Blockchain transaction fees, but in the past they have been a lot higher, and we anticipate that in the future they might also rise again, and they-- and then these interactions with your channels can become very costly. and second of that, and second of all is that on Lightning, because your payments flow over channels, to receive payments, you need to have a channel with someone who has some money in this channel with you, which is called your inbound liquidity. And if you don't have inbound liquidity, you can't receive any payments. And it's usually not easy to convince someone to put money locked in a channel only with you, so that's why most of the Lightning wallets right now, they allow you to basically purchase or rent some inbound liquidity, where they charge you a fee, and then you can and these are the two, main hurdles that, that you don't have with ARC because you don't need channels, you can, you can always receive without needing specific inbound liquidity because this is all handled by the server, and you don't need to create channels, or rebalance because all your, all your balance is kept in the ARC, totally off, off-chain, and you don't, need to manage this liquidity, yourself because there are no channels."
    },
    {
      "speaker": "stephan",
      "time": "04:51",
      "start": 290.98,
      "text": "Yeah, and so understood in another way or in a similar way, it's about onboarding, right? Because what we're talking about here is for a new person when they come in and they start up a Bitcoin Lightning wallet They, they're kind of stuck with one of, with a few hard choices. It's either do everything manually yourself, have enough Bitcoin to manually do the channels, or pay to rent a channel, or push that cost and complexity onto the LSP and the lightning wallet person, like who's maintaining that. And e- any of those three options, you know, it has trade-offs around it. That's, you know, that's the nature of how things are. and so what I'm understanding here is ARC- Can help you in terms of onboarding a new user with a different set of trade-offs, right? It's, it's important to understand it's not like, it's not free, there's no free lunch here, but it's a different set of trade-offs. So can you explain a little bit about that and why it's better from an onboarding perspective? Yeah. So the,"
    },
    {
      "speaker": "steven_roose",
      "time": "05:54",
      "start": 353.75,
      "text": "like, yeah, the onboarding problem is particularly difficult, right? Because if you don't have anything, you don't have channels, you don't have anything. You want someone, some friend or someone wants to send you their first payment or your first payment, and you want to receive maybe ten bucks, twenty bucks. It's really not possible in, in Lightning to do this because a channel will often cost you a few bucks and then you need to wait for it and all this. So in, in, in, in ARC, you don't have any of this. You can immediately receive an off-chain VTXO. a VTXO is basically a unit of money in, in ARC. So you can immediately receive some off-chain money and there's no need for a setup, so you can just open an app that would support ARC and immediately you can make your first receive."
    },
    {
      "speaker": "steven_roose",
      "time": "06:37",
      "start": 397.02,
      "text": "I, I, yeah Experience, we will talk about our Signet launch later, but we wanted to specifically show that you can just set up your wallet, go to our faucet, and receive some unchained funds i-instantly. Which is something that with Lightning is not possible today, and that's why most people are going to recommend custodial or semi-custodial Lightning solutions where, you can tell someone, \"Hey, install this app, and I can immediately send you ten bucks, and it will immediately show up in their, in their wallet.\" but that's not really possible with fully self-custodial Lightning."
    },
    {
      "speaker": "stephan",
      "time": "07:08",
      "start": 427.96,
      "text": "Yeah. Okay. And so now let's just compare this with, you know, people might have heard of, or they might be using other approaches, things like like Liquid, right? So as an example, I don't know you were, you used to be working on Liquid stuff over at Blockstream previously to this, so obviously you're very familiar with that, and then there are others who might talk about, let's say, Cashu or Fedimint, using an eCash style approach. So how would you contrast an ARC onboarding with, let's say, a LBTC Liquid style onboarding or an, an eCash, let's say, a Cashu or a Fedimint or, Others, ARC compare with those?"
    },
    {
      "speaker": "steven_roose",
      "time": "07:49",
      "start": 469.35,
      "text": "Yeah, so it's they're, they're all three similar in the sense that there's some third party helping you do your Bitcoin stuff, right? So it's not like your on-chain wallet where there's just a peer-to-peer network, but in both Liquid, Cashu, and ARC, there's some kind of server that is, that is helping you do this. But what, what differentiates, ARC is mostly that The server at no point is, is, is in control of any money. So, so it's totally fu- self-custodial. While in the Cashu case, for example, it's kind of fully custodial. You- It's fully custodial. The Cashu, the, the, the Cashu Mint has all the money, and it gives you tokens that you can then anonymously and privately use to, to send Lightning payments and send this Cashu, this e-Cash around. But the money in the end is all handled by, by the Cashu Mint. It's possible to make federated Cashu Mint, I imagine, where it's multiple people, but still the money isn't controlled by other people. In, in, in Liquid, it's, it's also the case, they have a"
    },
    {
      "speaker": "steven_roose",
      "time": "08:53",
      "start": 533.29,
      "text": "jointly, like, collaboratively, but still, it's those people that, that have the money in, in, in, in their hands, and if something goes wrong, it's always possible that the money doesn't end up back in, into your hands if you, if you would need it. So with, with, with ARC, the user is always fully in control of their money and the server is only there to help coordinate what we call rounds or to help you make, off-chain payments and lightning payments."
    },
    {
      "speaker": "stephan",
      "time": "09:20",
      "start": 560.43,
      "text": "Yeah. So in other words, am I understanding it correctly then, the ARC wallet that you are, you know, creating and the idea-- the user has their own private keys basically, and they hold the private keys to a vTXO that's being helped, like the server helps manage that, but at the point is unilateral exit, right? The idea is if they wanted to go to chain and take those funds on chain, they can do that. That's the difference you're pointing out,"
    },
    {
      "speaker": "steven_roose",
      "time": "09:47",
      "start": 586.89,
      "text": "right? Exactly, exactly. And the, the server doesn't really help you manage it as, as much as it helps you set it up in the first place, right? So, so your wallet manages all the transactions that it needs, that it would need to broadcast in case of a unilateral exit, and it manages your VTXOs. But every time they are about to ex-expire, we can maybe go into the expiration thing later on, but whenever they're about to ex-expire, the, the, the coordinator in the server will help you like refresh And as soon as they are created, you don't need the server anymore because they are there and they're always yours. You only need the server if you want to, if you want to pay or if you want to transfer them to someone else. the server is also a lightning gateway because like, The VTXOs aren't channels, right? So you, you, we use a trustless swap so you can get your VTXOs onto the Lightning Network and in a payment in, in, in one go. so the currently the, the ARC server will also be the Lightning gateway. In theory, there can be third-party Lightning gateways as well, but, currently it's the same party. And then the, the coordinator will help you make Lightning payments, will help you refresh your VTXOs, and will help you, pass on your VTXOs to"
    },
    {
      "speaker": "stephan",
      "time": "10:55",
      "start": 654.73,
      "text": "Okay, gotcha. So there's a few terms that we should help explain, and maybe some of this, the terminology has shifted a little because in past discussions on ARK, people might have heard the term ASP, ARK service provider, and I guess that was meant to be kind of parallel to Lightning service provider, which people understand from the Lightning world, and there's a few other terms you mentioned there. So ASP, I guess, is like an ARK server, and then the coordinator, and then the Lightning gateway, and I guess the Lightning gateway, the server and the coordinator,"
    },
    {
      "speaker": "steven_roose",
      "time": "11:24",
      "start": 684.19,
      "text": "they"
    },
    {
      "speaker": "stephan",
      "time": "11:25",
      "start": 685.09,
      "text": "The same, it's just, yeah, yeah. Yeah. So if you could just explain a little bit about, you know, the, the, the user and the server and how, how does that interaction work from an ARC perspective? Yeah. So,"
    },
    {
      "speaker": "steven_roose",
      "time": "11:40",
      "start": 700.01,
      "text": "so in, in, in ARC, each ARC is, is like a, a small bubble, right? all your interactions will happen within your ARC with your single ARC server. and there's not really any crossover to, to different arcs. So if, if, if I'm in a different arc than you are, we can pay each other through Lightning, and Lightning will be the bridge, or we can do direct swaps from my arc to your arc, but we, like, you can't move the money directly from one arc to the other. Like, you either have to swap or use Lightning, something like that. So all your interactions as a, as a user, all your interactions will be with a single server. So you know the address of the server,"
    },
    {
      "speaker": "steven_roose",
      "time": "12:19",
      "start": 739.26,
      "text": "You want to do something, you just talk with the server, and the server helps you do all your interactions, and the protocol guarantees that if the server disappears or starts to act out in a bad way, you always can like use your unilateral exit and, and broadcast your transactions to the chain and have your money back."
    },
    {
      "speaker": "stephan",
      "time": "12:36",
      "start": 755.98,
      "text": "Yeah. Okay. And could you also explain for us at least the current understanding of what's happening in terms of the rounds, right? So as I understand, there are rounds, and, you know, I, I think historically you had this, was it Arco pay- Payment, it was like a out of round, or maybe you could explain a bit about this, 'cause it might have changed in, how I'm seeing, how I'm understanding it. Yeah, yeah, yeah."
    },
    {
      "speaker": "steven_roose",
      "time": "12:57",
      "start": 777.29,
      "text": "Yeah, I mean, the, the protocol definitely changed a lot since it was invented, but we're kind of settling on, on the way forward and the, and the current way. So like, the, the, the rounds are kind of the core of the protocol, because the rounds are when the new VTXOs, like we call the virtual UTXOs,"
    },
    {
      "speaker": "steven_roose",
      "time": "13:20",
      "start": 800.22,
      "text": "We envisioned that you would use the rounds also to pass on vTXOs to other people, but currently we only use the rounds for your own vTXOs to be refreshed when they are about to expire. So a vTXO in ARC has an expiry time. We, we imagined there would be something in the order of one or two months. So every one or two months, you would have to refresh your vTXOs, and you use the round to do that. So in the round, you will tell the server, \"Hey, I have these vTXOs that are about to expire, I want"
    },
    {
      "speaker": "steven_roose",
      "time": "13:49",
      "start": 829.24,
      "text": "About every hour, but your wallet will probably be participating in these rounds in the background without you really noticing that this is happening, because the money just goes back into your wallet, it gets a new expiry time, and you don't really notice this much. And then when you want to make payments to other people, we call what, we use what we call out-of-round payments or OOR for short. and what you do then is that you have an existing VTXO and you just make a transaction on top of this to basically pass on. So it's, it's kind of like an on-chain transaction where you have a new transaction that spends This transaction as an input and create new outputs. So it works exactly in, in the same way, but the, the difference is that this transaction stays entirely off-chain, so you can make multiple ones of these, kind of like a mini transaction chain off-chain. and you don't have to do any rounds or, or something like that for these transactions to confirm, so they can, they're, they're instant, right? And this is also how you make lightning payments. So if you make a lightning payment, you basically make a small or core payment that creates an HLC and creates some change, and then the HLC goes on the lightning network, and then, the, the change becomes your new VTXO, and then at some point the VTXO will, will expire, and then you use the rounds to refresh it, and you"
    },
    {
      "speaker": "stephan",
      "time": "15:06",
      "start": 906.2,
      "text": "you know, caveman 80 IQ understanding. So let's say I've got, you know, I'm an end user, I've got an ARC wallet, and I wanna make a lightning payment for me, the way it looks to me would be like I scan and make a lightning payment like I normally would, but actually what's happening is I'm doing like a payment that kind of goes to, let's say, the arc, my arc server, and my arc server has the lightning gateway that actually makes the payment on my behalf, and then I'm getting back a vTxA with the change later, or how does that work? It's, it's not"
    },
    {
      "speaker": "steven_roose",
      "time": "15:36",
      "start": 936.2,
      "text": "really on your behalf because what happened between you and the server is also an HLC. It's kind of like the same thing as if we would have a channel. It's a bit more trustless in that way,"
    },
    {
      "speaker": "stephan",
      "time": "15:44",
      "start": 944.16,
      "text": "okay?"
    },
    {
      "speaker": "steven_roose",
      "time": "15:45",
      "start": 944.58,
      "text": "Yeah, yeah, it's, it's totally trust But they don't necessarily need to build on top of channels, like it's just a, a contract, an HLC contract. So we just built an HLC in the ARC, not on a channel, which basically tells the ASP, like, hey, if you can give the prematch, then I can give you the money, and an ASP can, can use the Lightning Network to get the prematch from the eventual receiver of the payment, and then the money gets, unlocked atomically in the ARC and in the Lightning Network, right? So I see."
    },
    {
      "speaker": "stephan",
      "time": "16:16",
      "start": 976.33,
      "text": "So it's actually a stronger level Trust minimization, compared to kind of some of the other approaches, because of"
    },
    {
      "speaker": "steven_roose",
      "time": "16:26",
      "start": 985.98,
      "text": "that. Because, yeah, it's, it's like, it's, it's fully non-custodial, like the HLC is there. If the, if there's no premage, the money doesn't go to the ASP at, at all."
    },
    {
      "speaker": "stephan",
      "time": "16:34",
      "start": 994.29,
      "text": "Right, I see. Yeah. Right, because that's another thing about Lightning is the idea is there's this pre-image and you need to, you, you have to make sure it gets to the other side before they release, you know, okay. So"
    },
    {
      "speaker": "steven_roose",
      "time": "16:44",
      "start": 1004.1,
      "text": "exactly, yeah. So like the timings are a little bit more tricky than, in, Lightning, because in Lightning every channel is kind of the same, so you just have different timeouts that you stagger, but then the timings inside the arc are a little bit more complicated, so we, we have to be careful that the timings are right"
    },
    {
      "speaker": "stephan",
      "time": "17:06",
      "start": 1026.09,
      "text": "so who do you see as the main users of ARC?"
    },
    {
      "speaker": "steven_roose",
      "time": "17:13",
      "start": 1032.58,
      "text": "yeah, so we think that just individuals who wanna make payments have the most benefit from ARC. we think if you're like a, like a really big shop that receives thousands of payments per month, you're probably better off setting up a Lightning infrastructure or paying someone to do it because Lightning is really good for this high, high volume. But we think any user who just wants to make several payments a day, who just wants to have a, a mobile app and wants to go to Go shop and pay, we'll have, we'll have more benefit from using ARK than from trying to set up custodial lightning, and, and, the same wallet, the same ARK wallet can also just make any off-chain payment, so even if you would receive your salary in your ARK wallet, you can easily send back to your, to your cold storage, So yeah, it's, it's kind of a fully, a fully working Bitcoin wallet that is both on-chain and Lightning without, without much, management and headaches."
    },
    {
      "speaker": "stephan",
      "time": "18:02",
      "start": 1082.02,
      "text": "I see. So I guess the way you're explaining it there is it, it could be like a unified balance. You don't have to think about as much, am I on-chain, am I off-chain? It's just kind of, here's my ut- here's my balance, I can just make payments with, and not really worry too much in the background. So in terms of- Capacity and things like that, you don't really have to think about that, like it's not that, oh, I need this much inbound capacity or none of that. It's, or I just, if I wanna make an on-chain-- Okay, here's the other example. So let's say I wanna make an on-chain payment out of my vTXO balance. How does that part, like, let's say I want to-- Okay, just silly, let's say I've got, you know, one million sats and I wanna make an on-chain payment for point one You know, million sats or, you know, a hundred thousand sats."
    },
    {
      "speaker": "stephan",
      "time": "18:49",
      "start": 1128.68,
      "text": "how does that work in ARC?"
    },
    {
      "speaker": "steven_roose",
      "time": "18:51",
      "start": 1131.28,
      "text": "yeah, so to make on-chain payments, you have to wait for a, a round, right? So they, they are not out of round, there's no out of round on-chain payments. So what you would do is you would tell the server like, \"Next round, I wanna make this on-chain payment.\" And then when the round happens, the server will create an outputs on the, on the round transaction. Every round, a new on-chain transaction But it can also create outputs, on chain. And then you would pay, a little bit of a fee because you, you pay the on-chain fee just for your output, right? So just for your script. And then, Then in the end of the round, the, the, the on-chain output would be created, and you would either have some of your change in vDXOs or the vDXOs, or the change can stay off-chain,"
    },
    {
      "speaker": "stephan",
      "time": "19:36",
      "start": 1176.34,
      "text": "I see. And so, is there any concept here of like, you need to add enough fee to get it confirmed kind of thing, or is it more just like that's handled by the arch? That's what the server"
    },
    {
      "speaker": "steven_roose",
      "time": "19:47",
      "start": 1187.26,
      "text": "does for you exactly, yeah. And as the, as, as, as a server, because we-- the, the round transactions are usually very small, they're usually a few inputs and then two or three outputs, we, like, we really overpay fees to like make them confirm, because this is like the essence of our, of our, of our protocol. So for the user, you don't have to worry about replaced by fee or, or something like that. The, the server will make sure the transaction confirms, and, and they will charge you just a fee for your output, so you don't pay on-chain"
    },
    {
      "speaker": "stephan",
      "time": "20:20",
      "start": 1220.04,
      "text": "I see. And then, so I guess the trade-off in one sense is you make your payment on chain and it goes once an hour, you can't sort of make an instant on-chain payment. So that's one downside. Maybe for some listeners or some users that would be, you know, annoying for them or whatever, but hopefully over time, as, you know, as Lightning grows, more and more people will just do Lightning payments anyway, so then this will be less and less of an issue. so While we're on the topic of what-- who is the typical user? Are we talking here, like, as I'm understanding, this is like retail user, right? Like, this isn't for high level- large amounts, right? Or, well, how do you see it?"
    },
    {
      "speaker": "steven_roose",
      "time": "21:02",
      "start": 1262.0,
      "text": "The, the thing that I, that I mostly think Lightning still benefits is high volume, right? So like thousands of payments, like stores, like online merchants, stuff like that. But the amounts don't, don't, don't really make much of a difference. Just like, like you know that on chain, your fees is based on the amount of bytes in your transaction and not about, not, not, not based on the amount of money. The same in, in ARC, you can have-- Well, in ARC A little bit more tricky because they are in some ways a bit based on the amounts, but it doesn't make it less feasible to have larger amounts in, in, in, in ARC, just like in Lightning. Lightning could work in the beginning, there was this reckless mode, the Wumbo channels, where they tried to discourage users to put a lot of money in the channels, but I think at this point, Lightning is, is secure enough that it also works for larger amounts. I see."
    },
    {
      "speaker": "stephan",
      "time": "21:49",
      "start": 1309.09,
      "text": "Okay, so yeah, so it's not actually limited just to like coffee payments and retail, sort of small retail, it's actually, you actually could do multi-thousand dollar, ten thousand dollar, hundred thousand dollar payments theoretically."
    },
    {
      "speaker": "steven_roose",
      "time": "22:02",
      "start": 1322.44,
      "text": "Yeah, I think so. I don't see a reason why you-- why we wouldn't. I mean, obviously, the more money is in it, the more careful you have to be that you, you refresh them on time, because otherwise you can get into, into trouble. But I think your, either your app provider or your wallet provider will, will make sure that, that that happens and, and you will get those guarantees."
    },
    {
      "speaker": "stephan",
      "time": "22:24",
      "start": 1343.6,
      "text": "Back to the show in a moment. This show brought to you by CoinKite dot com, the creators of the best Bitcoin hardware security devices such as the Coldcard Mark IV and the new Coldcard Q. Now, we use Bitcoin hardware security devices to keep our keys offline, our private keys offline. Now, the way these work is you can do that setup, write down your twelve or twenty-four words on the seed word cards and keep that secure. Now, you can use this device to interact with the Bitcoin network work using software such as Sparrow Wallet, Electrum, or Vector Desktop or Nunchuk as a few examples. Now, you have a range of security features that you can use with these devices such as passphrase, you can use seed x or my favorite is multi-signature. Now, if you're starting in a basic way, just start with the device and the USB-C cable, plug it directly to the computer and use it that way, and then later improve your setup. But I believe these devices are great at helping secure your coins. Especially as you start to migrate up into multi-signature security, but don't be disheartened or don't be, scared away. They are accessible, and I think you actually do learn about Bitcoin in the process. So to get yours, go to coinkite dot com, use code Livera to get a discount on your cold card. This episode brought to you by Galloy. They are building banking software for the Bitcoin age. So if you are with a bank, a fintech, or a startup looking to offer some kind of Bitcoin product, whether that is a Bitcoin collateralized loan Deposit accounts or payments, Galloy can help you. Their latest product is called LANA. It is a loans management platform, and you can use this to come to market quickly and offer a loans or Bitcoin collateralized lending product for your customers. Now, Galloy have a lot of experience in the space. They started with Blink Wallet in twenty twenty, and they've since grown this to become a community favorite over time, and so they have a lot of experience making things work in a secure, reliable, and scalable way. So if you need assistance coming to To market quickly with a Bitcoin banking product such as lending or deposits or payments, talk to the team at Galloy. You can email them, the email is biz at galloy dot io, or go to the website galloy dot io. And now back to the show. Okay. And then while we're on the topic of apps and refreshing and so on, I mean, one thing people talk about with mobile is, that, a lot of the, let's say, Android and Apple are getting aggressive about battery management, so they don't let you do things in the background, this kind How do you get around that in terms of, 'cause periodically, as I understand, I guess the app has to wake up every now and again and sort of do a refresh. How do you manage that?"
    },
    {
      "speaker": "steven_roose",
      "time": "25:06",
      "start": 1505.59,
      "text": "yeah, that's a very good question, and, that's why we're, we're also launching this, launching this product now on, on, on Signet because we want to start experimenting with this and learning the pains, right? We are, we are not planning ourselves to, to release a mobile app, but we, we are, partnering with different app developers who want to integrate ARC and who have the mobile experience, but who don't really know how the ARC interactions will work. So we're trying to tailor our, our, our SDK, our our, our wallet and our platform to be as mobile friendly as, as possible, we have a lot of changes that we have in mind to reduce the different latencies that are there when people have to wake up. But yeah, as, as you say, the mobile platforms aren't easy to develop on, especially not if you need to do background work, and it's important that, that you just occasionally wake up and have a, a chance to refresh your vTXOs. I think it's, it's going to be an interesting ride and a collaboration between us and different app providers. Like if there's people building iOS only or Android only or, or, or cross-platform in different ways, we will have to talk with them, look at the ways that they have that, for example, they can wake up the phones of their users so that they can, participate in rounds. Yeah. So we're-- what, what we can do on our side is try to make the, the SDK as low footprint, low cost as possible when it comes to CPU usage, time needs, bandwidth and stuff like that. But eventually, it will be the app developers who need to understand the processes and what the limitations are, and it's still to be seen How far we can go to make it, fully user friendly, depending on, on the platform. But yeah, that's, that's why we launched this test version because we want to start learning this as soon as possible, because like our, our company's goal is to, is to get payments into the hands of, of end users, and we know that obviously that will be mobile, like people aren't making payments from their desktop computers. So, yeah, we want to get that mobile experience as soon as we can."
    },
    {
      "speaker": "stephan",
      "time": "27:02",
      "start": 1622.27,
      "text": "Yeah. And as I understand right now, if I think of, let They are using, I think there's some Google Play thing where they can send a notification and make your phone wake up to take a payment, as an example. So I presume it'll be something similar to that. so let's talk a little bit about Signet. So you've done this Signet launch, what's the-- you know, what is this? Give us an overview of the Signet launch."
    },
    {
      "speaker": "steven_roose",
      "time": "27:27",
      "start": 1647.21,
      "text": "Yeah, so we basically wanted to get our product in the hands of some early adopter users, some first movers who just wanna play with it and wanna see how it, how it feels like. we especially hope that we will get some app developers excited to start trying to integrate, this, this SDK into their apps. So basically what we did was we, we launched our, our ARC server and our client called BARK, and we created a server that is active on Signet right now. We created a little faucet and a- Tutorial so that users could install Bark, the client, create a wallet, receive some, off-chain money from our faucet. The faucet is providing off-chain and also on-chain money if you need on the, on the Signet. And then we provided a small store where you could, buy some treats for our mascot called Byte, basically to showcase that, that you can also make small payments. It shows you a Lightning invoice, you, you copy-paste it into your CLI because it's, it's only in the terminal for now, and then you can, you can make some We're trying from the, for users and mostly developers to, to see that this is something that's actually working and that is improving rapidly, and, and to get them excited to try and integrate this, into some of their apps or platforms or, or wallets, in different kinds of ways."
    },
    {
      "speaker": "stephan",
      "time": "28:44",
      "start": 1724.29,
      "text": "So in current form, how many people can use ARC before you start to hit some kind of usability limits? as I understand, this is early days, so I guess you're still figuring this out, but as I understand, one of the trade-offs of not having like a CTV or things like that or T x hash or whatever is that there's more interactivity. So what does that mean in practice for users today?"
    },
    {
      "speaker": "steven_roose",
      "time": "29:10",
      "start": 1749.9,
      "text": "yeah, so that's another reason why we want to get people to test this is because we don't have much real-world usage examples. We have some tests, I can, I can, I can tell you that we have tests where we run up until like hundred participants in each round, but not much farther beyond that because, I don't know, it's just hard to-- if you do it all on the same computer, it's also not really a good, a use case. So like, we don't really know. Like in, in theory, the limit should be pretty high"
    },
    {
      "speaker": "steven_roose",
      "time": "29:39",
      "start": 1778.94,
      "text": "To participate, because the interactivity means that there's a lot of data flying around, without CTV, for example, all the participants need to create a bunch of transactions on a bunch of different, a bunch of signatures, I mean, on a bunch of different off-chain, transactions in preparation for the round. And, yeah, on mobile, that, that means you need to send a lot of, what I call like cryptographic nonsense, then signatures. And all of this needs to be done each round, for-- Well, just, just to make it clear, because some people make this mistake, you don't have to participate in each round, right? As a user, you only participate in a round if you need something from the round. If you need to refresh some VTX or if you make a, if you need to make an on-chain payment. But still, if you're on a mobile phone and you need to refresh, we want to make sure that you have the highest chances possible of, of, of succeeding in participating in"
    },
    {
      "speaker": "steven_roose",
      "time": "30:29",
      "start": 1829.16,
      "text": "Yeah, the, the limitation depends on how many users can participate in each rounds. You only need to participate once every one or two months with your VTXOs. So, yeah, you can do the math, multiply the number of upwards we could have in a round I'm imagining something in the limit, the limit with the current model would maybe somewhere be around a few thousand per hour, and then multiply that by A whole month or two, and that's all right. So we're talking, we're talking like"
    },
    {
      "speaker": "stephan",
      "time": "30:59",
      "start": 1858.61,
      "text": "fifty thousand, hundred thousand, e-- like well"
    },
    {
      "speaker": "steven_roose",
      "time": "31:01",
      "start": 1860.92,
      "text": "more than that. Users probably, yeah, yeah. And then, and then with CTV we would, we would cut, sorry, sorry to interrupt. With CTV we would cut a lot of this interaction. there's also other ways that we're still thinking about that we can cut down on a lot of bandwidth and interactions needed, when it comes to signing four hundred transactions, which is an essential part of the round that we will always need to do, even with CTV. but yeah, I mean, we definitely have to have more real-world usage examples and tests because if we run tests on different servers and stuff like that, it's very different than people running on mobile network connections and, yeah, and in different continents."
    },
    {
      "speaker": "stephan",
      "time": "31:39",
      "start": 1899.14,
      "text": "Yeah, I see. Because, yeah, as, as you were just saying, like it could be a few thousand in each round, and, you know, that could mean maybe fifty thousand people have an ARC wallet on their phone, but only a few at each time are in a round, so something like that. Exactly. Yeah. But I guess the other downside or the kind of the difficulty to deal with is if, you know, these are users who haven't done a transaction in a while, then, you know, some of the phones, like the way they do their battery management, is they'll say something like, \"Oh, this app hasn't been used in...\" A month or two months, they therefore deprioritize it and don't allow it to wake up in the background, and so you're kind of-- Those are things-- You're dealing with that aspect. Those"
    },
    {
      "speaker": "steven_roose",
      "time": "32:21",
      "start": 1941.03,
      "text": "are things that we don't have any control over, that will depend on the app developers and the platforms that they use. Like one thing that's very interesting, I think, about Ark is that all these problems in, in scaling the, the rounds has to do with the number of users, not the number of payments, right? So like even if users make a really lot of payments, this makes"
    },
    {
      "speaker": "steven_roose",
      "time": "32:42",
      "start": 1962.37,
      "text": "Just scale up our user base and then have them make as many payments as they want. We don't, we don't ever need to limit the amount of payments that you can make. but yeah, like, like"
    },
    {
      "speaker": "stephan",
      "time": "32:51",
      "start": 1971.32,
      "text": "let's talk about some uses though, because I think it's important to sort of put some- Practical uses here. So as an example, I mean, may, maybe someone who wants to do a non-custodial exchange, maybe they could set up like an ARC thing and their customers who are stacking- Could get a new vTXO every week or what? Let's say they're doing like a DCA and they wanna buy some every week, they could get new vTXOs until the point that they actually have enough to go on chain."
    },
    {
      "speaker": "steven_roose",
      "time": "33:23",
      "start": 2002.98,
      "text": "For example, yeah. So, I mean, this is one of the, actually the use cases that I mentioned when I was making the case for CTV for Ark is because a third party who is, like an exchange, can actually issue independently using CTV a bunch of vTXOs, and there is no round needed, there is no interaction needed, and they can deliver tens of thousands of vTXOs in one single on-chain output, and they can do this every hour when they have a lot of usage or a small DCA provider can do this every day, and Those are like, like again, it's, it's not the amount of payments that matter, it's the amount of users that matter. So this, this one can actually deliver a whole bunch of payments in a single output. They can do it every hour, they can do it every, every, every, every day, but this doesn't put a limit on the amount of users that we can have, because that's only when we do actual rounds, that, that we need to look for that. And if we start to, to grow and we have too many users and the rounds are too One round per block, and then your confirmation time for your on-chain payment is going to be the same as a normal on-chain payment because there's a round every block. It, like doing f-fre-frequent rounds increases the on-chain cost for the, for the server, but if there's so many users that actually need this space, we can probably pay for that on-chain cost, right? So I think as we grow and we hit limits when it comes to rounds, we can just have more frequent rounds, and then we will have the, the usage to pay for that"
    },
    {
      "speaker": "stephan",
      "time": "34:50",
      "start": 2089.97,
      "text": "usage on the, of the, of the chain. The chain, yeah, interesting. And so that could be interesting for people who really wanna focus on the, you know, not your keys, not your coins, get more self-custodial adoption. could it be made a lot easier as opposed to pushing a lot of people into custodial, which is where a lot of people are now, you know, whether Also fair to say, it's probably also that a lot of, let's say, westerners don't have a payments problem today, they have a savings problem, so they're more interested in the hodling and stacking use cases than they are the actual day-to-day paying for coffee with, you know, whatever, lightning and Ark and whatever. but this might be an example where ARC could be used to have people stacking in a self-gestational way, as opposed to a, you know, putting it all, putting all that risk into the exchange and the custodian."
    },
    {
      "speaker": "steven_roose",
      "time": "35:44",
      "start": 2143.7,
      "text": "Yeah, I mean, there's definitely a space for custodial Bitcoin as well, I think. I, I think projects like, like FedMe and projects like Cashu and even just fully custodial things like, like Wallet of Satoshi or even banks going into the custodial Bitcoin space, like Revolut and stuff like that, I think they have their, their place. But I think it's very important for us as a community that it's possible and it's, it's, it's also like- Some in, in some form have a proper user experience when you want to be fully self-custodial, because there's always gonna be people who either need this for political reasons or people who want this because they are, they are targeted or they are focused on by the, the places that they live in, or they, they just, they just don't want to trust the bank. there's, there's always gonna be Risks involved with third parties, and at some point, it's the amount of money that you're managing is gonna be too high for you to take that risk, and people have different risk thresholds. So yeah, we, we feel it's really important that self-custodial Bitcoin stays possible and not just for saving, but also for, for payments, because right now, like you say, saving non-self-custodially is very good in Bitcoin, but once you want to make payments, most people move into something that is either semi-custodial or fully custodial, because that's just, it Yeah, you say the, the, the, the West, so to speak, has not much of a payments problem, but more of a savings problem, and that's why Bitcoin works for them quite well. But I think we're, we're struggling to onboard those people who need the payments more than the savings, because just the payments user experience hasn't been, hasn't been great. and I think if we can improve that, we can get them using Bitcoin more as like a payment system, and eventually they will use it for savings as well, because if they receive their payments there, it's"
    },
    {
      "speaker": "stephan",
      "time": "37:24",
      "start": 2243.75,
      "text": "Interesting, yeah. and I think some of that comes into just getting more people using even Lightning, right? And I, I know there are, you know, I've seen a lot of news recently, people like Breeze, Breeze SDK has been getting a lot of progress, kind of getting companies on board, and not even like crypto companies, like fiat, like fiat companies that had nothing to do with Bitcoin or crypto, they are starting to take on Lightning payments. So the more of them there are, the easier it is hypothetically to make or take Lightning payments than it- Kind of hopefully there's actually more, use for that, but I think w-we also have to just be honest and look at, well, recently there's not a lot of use on chain and there's a lot of, probably a lot of people are onboarding through ETFs and MSTR and things like this, so that's just kind of where we are, we're at. of course, I want more people to self-custody, but we have to sort of see that's, that's where it's at for now. but anyway"
    },
    {
      "speaker": "stephan",
      "time": "38:25",
      "start": 2304.87,
      "text": "So maybe you can help explain for people, I think listeners will have this question, can you contrast between what you're doing and Ark Labs, like what's the difference in the approach there?"
    },
    {
      "speaker": "steven_roose",
      "time": "38:37",
      "start": 2316.89,
      "text": "well, it's a difficult question because I don't like to speak on behalf of others, but, I think it's-- I, I think I can say that, the team at Ark Labs and Ar- and myself personally, we used to work together in the beginning when we were still very much in the contemplating phase, and then at some point we just decided to part ways and we're focusing, I think, on different things right now. I think the biggest difference was that they initially launched, on Liquid using the Liquid governance. They have-- they're currently also trying I don't really know. I can't really speak for their focus. We are very much focusing on retail payments. from the communication I hear from Ark Labs, I feel that they're more focusing on Ark as a, as a platform for people to build apps on top and, and stuff like that, which I think is also, valuable. But I think it's hard to balance those things because if you're, if you're focusing on payments, you really want to focus on a very specific thing like low latency, small, footprints for like mobile and all that stuff"
    },
    {
      "speaker": "steven_roose",
      "time": "39:36",
      "start": 2375.87,
      "text": "Platforms, you want flexibility, you want different scripting methods, different contracts that can be built and stuff like that. I don't know if that, is that, if that's the way that it will go, but, that's like one of the main differences that I'm seeing today. Other than programming language we use, tech stack that we use, but those are all minor differences. I think the good thing about ARC is that unlike Lightning, which is a peer-to-peer network and all the implementations need to be completely compatible with each other because, they're just exchanging messages and, and doing stuff, cooperatively between different implementations, is that in ARC, like your server is, is kind of a bubble, right? So their implementation, our implementation, even though they're both ARC and it's kind of the same protocol, we can make totally different designs Decisions, we can have totally different implementations, like the, the, the API protocol between the users and the server can be totally different. So we don't, we don't need to align on too many things. We can experiment in different directions, and we can definitely learn from each other, like we have, we have, we have both on both sides seen the other side make a certain technical decision that we then realized was actually better and also took. so yeah, we're definitely learning from, from each other, and we'll see how it pans out."
    },
    {
      "speaker": "stephan",
      "time": "40:48",
      "start": 2448.14,
      "text": "on the liquidity constraints question, because this was another thing in the early days of Ark, a lot of people were saying, \"Oh, no, you won't be able to do it because the liquidity would be, the requirement at the ASP or Ark server now would be so high.\" What's the current thinking there?"
    },
    {
      "speaker": "steven_roose",
      "time": "41:06",
      "start": 2465.99,
      "text": "Yeah, so it kind of pends into what I said, in the beginning of the, of the podcast, where we're currently only using Rounds for refreshes to refresh your current, your own VTXOs and not for, for payments, and the liquidity constraints come when users interact with Rounds, right? So actually, the fact that, that now we're trying to have all the users use, make their payments, off-chain, out of Rounds, so to speak, in, in the R-Core payments, there's no liquidity, requirement there whatsoever. So So when users do just orca, or core payments, it's all fine, and when they enter the rounds, the liquidity constraint has to do with how close the vDXO is to expiring, because we kind of need to bridge the gap until the expiry. it's, it's hard to explain in, in a few minutes on a, on a podcast, but the fact that users are submitting their expiring vDXOs in a round Almost right before they expire, it really minimizes our liquidity constraints. So we're kind of optimistic in this current model where most users will feel comfortable enough to hold onto their, our core VTXOs until they expire, and then only refresh like a few days before the expiry of their VTXOs, because it really reduces the liquidity constraints from, from the server point of view. And yeah, I mean, I, I think this will be the primary model for most users. the other users that don't like this, this, this, this model and try- to refresh their VTXs more frequently, they will have to like pay their liquidity fee. We still did some, some number crunching, it, it isn't that bad, it's, it's, it's probably around What current Lightning, apps are, are charging you? So it's still, it's still quite competitive. yeah. So liquidity, we're kind of positive on, on this note. Like it was really a big problem when in this model where it was five second rounds, every payment goes through a round, because in that model, like the liquidity requirement for the server, which is Incred- be incredibly high, and it was really not possible, but, but the decisions that we made in the design since then have, have helped"
    },
    {
      "speaker": "stephan",
      "time": "43:06",
      "start": 2586.07,
      "text": "us a lot. I see. So basically that liquidity constraint has come down a lot, or at least the requirement has come down a lot. Yeah. I see. we, we"
    },
    {
      "speaker": "steven_roose",
      "time": "43:14",
      "start": 2593.77,
      "text": "think it's, it's a lot more efficient when it comes to liquidity needed by the server compared to liquidity or money that the users have than, for example, Lightning, because in, in Lightning, your liquidity is locked up, tied to a specific user,"
    },
    {
      "speaker": "steven_roose",
      "time": "43:29",
      "start": 2609.26,
      "text": "But if he's not sending or, or receiving or doing anything, the money is just there, stuck. And in our case, the liquidity is just, it's one single liquidity pool for all users, so it's way more easy, it's way easier to more efficiently allocate this liquidity, like it's, it's always there, so it's always used, usable by all users at the same time. So you don't have to decide like, oh, is this user gonna make enough payments? Is it gonna be worth it for me to put this amount of money in there, in this channel"
    },
    {
      "speaker": "stephan",
      "time": "43:57",
      "start": 2636.95,
      "text": "The lead sponsor of this show is Bold, the best place to buy, sell, and save Bitcoin. For listeners in the US, Bold lets you secure your financial future with complete peace of mind by integrating a low fee Bitcoin only brokerage with next gen multisig vaults. With Bold, you can smash buy Bitcoin or set a DCA plan for only 0.99% fees and seamlessly deposit the Bitcoin direct to your Bold Vault. The Bold Vault is a 2 of 3 collaborative multisig where you hold 2 keys and Bold holds 1 as a re- Back up, protecting against loss or theft. You can use Trezor, Ledger or Coldcard hardware wallets to spin up a Bold Vault in just a few minutes, and the Bold Vault is the only collaborative custody vault available with zero monthly fees. They're also offering zero fees on your first ten thousand dollars of Bitcoin buys and twenty five dollars of free Bitcoin when you buy a hundred dollars of Bitcoin or more. Try Bold today and upgrade your stacking experience over at getbold dot io. And now back to the show. So when it comes to fees, you were talking a little bit about this. Given that you're focusing on the server side and let's say protocol aspects, and the apps are gonna be handling, let's say, the end user apps, does that mean the app guys are gonna be the ones charging the fees, or are you charging a fee at the server level and the apps are gonna charge their own app level fee? How does that, how would that look?"
    },
    {
      "speaker": "steven_roose",
      "time": "45:15",
      "start": 2715.04,
      "text": "That's a good question. like currently what we, what we can know for sure is, is the cost basis that we have as a server, as a server, right? So whenever users do runs, we need to provide liquidity and this has a cost, we need to make unchain transactions and this has a cost. So there's a, there's definitely a cost A cost for us when users do rounds, and this is a function of how much money is in the arc, right? Because the rounds only happen to expire, so they're basically users continuing to be part of the arc. And when they make on-off chain payments, there's not really a big cost for us, we just need to cross sign some transactions, so We can either just like make the users pay for our, our costs, but we feel that users like to pay fees when they transact and not just to have a balance, right? So this, it, there's definitely a psychological aspect of that. But then when it comes to how it will work in the apps, those are really still questions that, that we have to figure out. Like we will have to charge a certain fee for our, for our server, and the, the app provider will have to like have their users pay those, and I don't know how they, how it will work with So making something on top of that or something like that, those are, I think, things that we will figure out once real apps are gonna launch on mainnet and, and, and we're gonna like have a bit of an open question as to"
    },
    {
      "speaker": "stephan",
      "time": "46:31",
      "start": 2791.33,
      "text": "what What the business models will be, but theoretically, you would charge some kind of liquidity fee and kind of service and protocol fee, let's say at your level, and then the app guys are gonna have to add something on their level too, and the u- the end user will pay, let's say, the combined of those fees. and so I'm curious from your perspective, now again, again, it's an open question, we don't know, but do you think That fee, like th-those two combined fees we were just talking about, that will be less than a Lightning, you know, like a Phoenix user or a Zeus user, this kind of thing? Or it'll be in the same ballpark or less? What do you think?"
    },
    {
      "speaker": "steven_roose",
      "time": "47:18",
      "start": 2838.31,
      "text": "I don't know the latest on fee schedules, but when we did-- when we started the company, we were, we were crunching some numbers, trying to do some math, and what we came up with was that just to hold money in the Ark continuously with the parameters that we chose at the time, like one hour round, thirty-day, thirty-day expiry, it would be around like half a percent of your money that you would have to pay every year to keep the money in the Ark securely. we set some pretty conservative, like, trust barriers there, like with number of days before the expiry you actually go, and refresh. And I think at the time, a half a percent was basically what Phoenix charged on receiving your money anyway, like when you receive from Unchain into your Phoenix wallet, they would charge you half a percent anyway, so that's like Yeah, like just having a single receive is the same as having your money for a whole year in the ARC. When it comes to individual payments, our cost base is so low, we can go really competitive, I think. But again, like there is a cost base just to have your money in the ARC, so like it's definitely not something where people will be holding their entire savings because it's maybe cheaper to make a single off-chain payment and then hold your money there for twenty years, instead of in the ARC. But I feel, I feel we can be really competitive, on that Payment is, is very efficient. and then, yeah, we just, we just have to do"
    },
    {
      "speaker": "stephan",
      "time": "48:39",
      "start": 2919.05,
      "text": "the math. Interesting. Yeah. And I, I, I, I could probably look it up, but as, off the top of my head, I think the Phoenix fee, the Async fee, I think it's on payments, it's zero point four percent of the amount you're making. So, on a thousand dollars of a payment, it's like four dollars worth of transaction fee. But also, there's a swap in fee, right? So if you take an on-chain payment"
    },
    {
      "speaker": "stephan",
      "time": "49:04",
      "start": 2944.05,
      "text": "Something like that. It's in that ballpark. So, yeah, I guess it'll, it'll depend, you know, but also I think we have to remember what was the purpose of all this. The point was make it easy to onboard and If this is easy to get people onboarded, then maybe people are okay to pay a different fee, whether that's a bit more or a bit less, I don't know. It's maybe it's a different, user, user experience. I think One thing that was kind of topical was, I don't know if you have an opinion on this, but Orange Pill App, they're an app, for kind of meeting, and they recently launched a custodial lightning wallet, and then there were a few people sort of saying, \"Oh, why'd you do custodial? Like, could you have done some other thing?\" In this case, would ARC, you know, now again, you just launched on Signet, not in Mainnet, but hypothetically if this, if Bark was available on Mainnet, could that have been an option?"
    },
    {
      "speaker": "steven_roose",
      "time": "50:01",
      "start": 3001.25,
      "text": "Yeah, definitely. Like that's, that's definitely the, the kind of target integrator that we have. like if you visit our, our, our, our website, it's one of the main talking points that we have is that we want to make it as easy as possible for an app developer to integrate, Lightning, right? So we want to have a very intuitive and simple SDK where you basically have some API calls from your wallet that hold you a balance that you can both make Lightning payments with and on-chain payments with, and that's basically the experience that we want to give to so yeah, any, any DCA company that wants to have a built-in wallet, any like smaller scale or even bigger scale like just wallet that wants to have a Bitcoin wallet with a Lightning wallet combined, can definitely use our SDK or, or should try to start using our SDK because that's definitely what we're targeting, for the, for our product So something like Orange Peel app is definitely, yeah."
    },
    {
      "speaker": "stephan",
      "time": "50:55",
      "start": 3054.89,
      "text": "Gotcha. And, but I guess for now it's early days because you're in Signet, but once, let's say, you-- Do you have a- Maybe it's again, you don't know yet, but do you know like when you would look to-- Are you gonna be like, going to try to go to mainnet in a year or six months or do you have an idea or not yet?"
    },
    {
      "speaker": "steven_roose",
      "time": "51:12",
      "start": 3072.13,
      "text": "personally, I would really like to have mainnet like by end of summer or something, but you know how engineering goes. Hopefully this year would be really good, yeah,"
    },
    {
      "speaker": "stephan",
      "time": "51:24",
      "start": 3083.95,
      "text": "but I guess it also depends how things go in SigNet with people playing around with, with play, with, let's say, play money, let's say."
    },
    {
      "speaker": "steven_roose",
      "time": "51:31",
      "start": 3091.38,
      "text": "Yeah, yeah, exactly. And we definitely want to look for some integrators who are willing to like take the first step, be the first mover and already integrate, even though we don't have mainnet yet, just to see where the paypoints are, because we don't like it makes little sense to launch a mainnet and then realize that our product isn't really easy to integrate with on mobile just because of the mobile challenges. So we want to learn first and, at the same time, make our server more robust because the server still also has a lot of work to do. And Well enough to actually be an easy to integrate product. Sure."
    },
    {
      "speaker": "stephan",
      "time": "52:07",
      "start": 3126.65,
      "text": "so yeah, I think we, we touched on this a little bit, in terms of business models, like you're gonna charge your fee and let's say the app creators are gonna charge their fee. Are you gonna be the only type of archiver for your, what you're doing, or is the idea that there would be competing other archivers doing the same protocol? Like, can you explain a bit on that?"
    },
    {
      "speaker": "steven_roose",
      "time": "52:31",
      "start": 3151.12,
      "text": "all our code is fully open source. we don't have heard of much interest from other parties for now who want to set up, ARC servers. It's definitely not as easy as setting, setting up a cash UMT or something like that. it's a bit more involved, so we don't, we don't really imagine also the liquidity like Amount of liquidity you kind of need to service your users in a, in a proper way, it's gonna be a bit high. We don't really imagine that it's like a run and out from your home kind of product. It's definitely possible for other users, for other people to, like parties, to set up ARC servers, but we don't really- We don't really have a lot of interest in that for now. I think we will probably be one of the first or the first, right? Because it's our own software, it's our own product, so we'll probably be the first, and maybe for a long time we'll be the only, Ark server providing this service. But we never know if it, if it picks up and people really realize that this is, that this is a really good product to integrate for your, for your wallets, maybe some, some larger parties will say, \"Well, also run"
    },
    {
      "speaker": "stephan",
      "time": "53:35",
      "start": 3215.07,
      "text": "a server.\" I see. Yeah, well, like it's possible that, you know, some big exchange, let's say they wanna do it, they might be like, \"Hey, we'll just run our own ARK server.\" You know, that could happen, right? But, and, and, and I,"
    },
    {
      "speaker": "steven_roose",
      "time": "53:47",
      "start": 3227.48,
      "text": "and I think from the user experience point of view, I think most app providers, just to make the user experience easier, will, will pick one server and just have this one the default. But it's definitely possible that there's apps that let you choose a server, maybe even with a QR code where you can say, \"Okay, I wanna be part of this server,\" you just scan a QR code so you get all the details to be part of the server. yeah, those things are possible. We currently just focus on building our own server and then have the clients communicate with that, but But yeah, everything is, is the, the way it's, it's made, everything is ready for, for other people to run the same server. I see, yeah,"
    },
    {
      "speaker": "stephan",
      "time": "54:25",
      "start": 3265.38,
      "text": "but I mean, presumably this is sort of very cutting edge, bleeding edge sort of stuff, so you kind of need to be someone who really intimately understands it, so it's probably not that easy for just another developer to kind of pick it up and run their own thing. They would really have to understand sort of the nuances of the, exactly. In,"
    },
    {
      "speaker": "steven_roose",
      "time": "54:41",
      "start": 3280.79,
      "text": "in our, in our benefit, I always think It's not easy to trust a, a server that someone else has built with like millions of your own money, right? So like, I think we have, we have an edge over other companies trying to run servers is that we wrote the code, we understand kind of where, where you need to be careful. so we will always have some kind of benefit, in that sense, but who knows if this, if this product matures a lot, maybe there will be others, maybe they will talk to us to have a support contract or something like that, There's definitely to be seen. Currently, we're focusing on having a service that runs and then users that, that can talk with it. Gotcha."
    },
    {
      "speaker": "stephan",
      "time": "55:19",
      "start": 3319.48,
      "text": "Yeah. One other question around the liquidity, just because I'm just curious as well, as you were mentioning the cost- At least from a liquidity requirement at the ARK server level, is if the, let's say the end user wants to do a refresh of his VTXO well before it expires. Is that, am I understand? So let me say, I guess to put it into context, let's say if my balance is one million Sats and I wanna refresh it one day before my expiry, that's not a very much, very high liquidity requirement on you, the ARK server, but if I, if, let's say I'm a baller and I've got- You know, I don't know, fifty Bitcoin or something, some ridiculous, you know, amount, then that would place a mat-- and I wanna refresh, you know, three weeks before my expiry, that places a much higher liquidity. Is that, am I understanding that correctly? Or can you explain that? Yeah, yeah. So liquidity"
    },
    {
      "speaker": "steven_roose",
      "time": "56:15",
      "start": 3375.09,
      "text": "is, is a simple multiplication. It's like the amount times the number of days, or times the time, right? So if someone has one Bitcoin and they're gonna refresh one day before ex-expire, it's like one Bitcoin day that we have a liquidity cost Do it one week before, we will have seven Bitcoin days liquidity cost. So it's like literally a linear function. and what we will have to do is, is just charge them a certain interest rate on the, on the day, the Bitcoin days that they take, that they want to, that they want us to provide this liquidity. So if you wanna refresh earlier, you're gonna pay a slightly higher fee. If you're gonna refresh later, you're gonna pay a slightly smaller fee. I think it can be pretty transparent, But also like the, the worst case, so one of the other numbers that we crunched in, in the, in the beginning was the worst case, let's say you wanna refresh immediately, right? So you receive an off-chain payment, it has still thirty days to go, you wanna refresh it immediately over thirty days, I think the cost with some reasonable market rates for interest that we charge, that we found online, was that it would be like point one percent for like the worst case. So it's still, it's still doable to pay one point one percent on a payment if you want full I think, like you just mentioned the numbers from Phoenix, it's kind of still better than, than Phoenix. even though I guess some"
    },
    {
      "speaker": "stephan",
      "time": "57:29",
      "start": 3449.23,
      "text": "listeners might also be curious, is there any way to be a liquidity provider here, or is that more like it's centrally managed by your company per se, not like the-- Yeah, it's-- Like, it's not, it's not like other people can provide liquidity here."
    },
    {
      "speaker": "steven_roose",
      "time": "57:43",
      "start": 3463.35,
      "text": "Definitely not in a trustless way. I mean, I mean, we will, we will not have, like, as our company will not have all this Bitcoin to, to provide this liquidity, so we will also like borrow it from liquidity providers, but this is, this is more in a trust-- in a trustful way, like there's no way to use the Bitcoin blockchain as contract so you can trustlessly- We've been doing some thinking. There's some, there's a certain few trade-offs that we can make to give liquidity providers a few more guarantees than just fully trust blindly trusting us, but it's a bit hard to do. It's never fully waterproof, so I think it's better to have just Like contracts and agreements that, that make sure that, that, that, that we-- I mean, those things happen, right? yeah, of course. I mean, between large businesses"
    },
    {
      "speaker": "stephan",
      "time": "58:23",
      "start": 3503.09,
      "text": "and banks and custodians and exchanges and all this, that's a different kettle of fish than, you know, the typical \"not your keys, not your coins,\""
    },
    {
      "speaker": "steven_roose",
      "time": "58:31",
      "start": 3511.12,
      "text": "which is another reason why I, I don't imagine that like- Groups of friends will run their own servers because they would just need a lot of liquidity, like the liquidity requirements would just"
    },
    {
      "speaker": "stephan",
      "time": "58:40",
      "start": 3520.11,
      "text": "be so high that it just wouldn't be practical, yeah? Gotcha. Okay, so just to be clear, we've spoken about, I guess, effectively what we've spoken about today is known as Clark, right? Like covenantless ark. So as in, just to make it clear for listeners, this is today without protocol change, without a soft fork of Bitcoin, this kind of aspect of it. So I'm just curious as well to understand a little bit of your view on ARC with CTV or TX hash or something like this. What would be concretely enabled by this, and what kind of, let's say, efficiency gains do you see being possible there?"
    },
    {
      "speaker": "steven_roose",
      "time": "59:21",
      "start": 3561.22,
      "text": "yeah, that's a, that's a good question. So yeah, so the current, the current implementation that we're building is built on like, we call it co-signing, right? So like the whole transaction tree, instead of being non-interactive, it's, it's co-signed. So all the, all the users who are part of the tree need to put some signatures there, and all the transactions have signatures on them, and then they can't change anymore if, if either, if just one of the parties who are participating hold up the contract of the, of the co-sign Beforehand to make the signatures, and just immediately the server can create the whole tree of transactions with all the different v-digos in its leaves, and just send them to the user and say, \"Here, this is the tree that we're gonna do for this round,\" and then, immediately move on. So there's definitely primarily a lot of, efficiency gains, right? It, it, it, it reduces the protocol from being a three-step to a two-step process. it, it, it reduces the num-the number of data, the amount of data that needs to be passed, especially on mobile, I, I think this can be a big, a big benefit. But then there's also a few things that are just not possible, right? So the main way to think about it is that with Clark The person who will eventually be the owner of a vTXO need to be present when the vTXO is created, because otherwise it's not trustless, because he needs to sign all the transactions that lead up to his vTXO. So if he's not present, it's not possible to, to create a vTXO for someone else, right? In a, in a, in a trustless way. And there's a few things that, that would be enabled if it would be possible to create a vTXO for someone else. one of the things is, like I already"
    },
    {
      "speaker": "steven_roose",
      "time": "01:00:58",
      "start": 3658.68,
      "text": "Or a DCA, or even a miner, because this is also very interesting, I think, for, for, for miners. It's, they, they can't just create vTXOs for, for their users, and with CTV, they could do that. They could basically create their own tree of vTXOs, because a vTXO is just an on-chain contract with a certain template, so anyone can create a vTXO for a certain arc. so then, for example, an exchange could just create a whole tree with the ten thousand different payouts of different vTXOs. Deterministically created using CTV and then fund the output and suddenly tell the users like, \"Hey, here, you have, you have batches of BTCOS without needing the users to be there.\" And I think that's, that's something very powerful. Another thing is, for example, for Lightning receive, Lightning receives, as you, as users might have noticed, is, is not something we support right now in our Signet. We were We had some ideas, we were refining the ideas still, and we didn't want, we didn't want to hold up doing this, this Signet launch until we had everything, figured out. But we have a version now that we're testing in, red tests. But Lightning Receive is a little bit more involved to do because somehow if your user doesn't have- anything in the arc, and you want to receive some lightning, there needs to be something created for the user, in, in, in the arc. And with CTV, it would be a little bit easier because then the ASP could just create a VTXO within HLC again, right? But then an incoming HLC, not an outgoing one, and the user just gives the prematch, and from that point on, the user owns the VTXO. and without a CTV, the user would have to somehow be woken up like, \"Hey, hey, you're gonna receive a, an Lightning payment,\" and then he needs to enter the next round, be online for like maybe half an hour to wait for the round to start, and then do the whole shenanigans of like participating in the round to then have their Lightning payments instead of having just one message signature and done. So for Lightning receives, CTV also is, is very useful. And then the last big thing that is, is something that we want to provide as a service is that when users forget to refresh their VTXOs before they expire, right? So, you know, your phone goes down or you don't have internet for a week because you forgot or something, or, or like you say, on iOS, your phone, your app got killed and it didn't manage to just wake up to refresh. So there'll be-- there's gonna be cases when users forget to refresh their VTXOs in time and they're gonna expire. Obviously, we, as the server, we don't intend to just No, we, we want the user to have the money back. So what we want to do and what we can do with CTV is we can immediately, when it expires, immediately reissue the VTXOs again, so that the users, when they come back online one day too late, they will see, okay, my money is still here and it's still in a trustless VTXO. So then there's only this like split second where the ASP could have done something bad but didn't. And it's actually also possible for the SP to continuously cryptographically prove, like, \"Hey, we didn't take any money, we didn't take any money, we didn't take any money.\" So someone who's monitoring the server can basically guarantee, like, \"Okay, this server has well behaved since its inception, and it has never taken anyone's money.\" And this should give a little bit of a guarantee to users to, like, to, like, put a little bit more trust in, into this server, right? but without CTV, this is also not, not possible to do"
    },
    {
      "speaker": "steven_roose",
      "time": "01:04:14",
      "start": 3854.19,
      "text": "would have to be present for them to be created. So with CTV, we can just always see like, \"Oh, these VTXs expired,\" immediately recreate them again in the next block, but that's not possible without CTV. I see. Yeah, so just to, just to be clear,"
    },
    {
      "speaker": "stephan",
      "time": "01:04:27",
      "start": 3867.97,
      "text": "like, yeah. So yeah, so as you, so, so I guess to summarize, you got this mass payout use, like the exchange custodian, the trustless lightning receive, and then also the refreshing case. Oh,"
    },
    {
      "speaker": "steven_roose",
      "time": "01:04:39",
      "start": 3879.04,
      "text": "and one that I forgot. And another one is just sending payments in rounds, right? So like I said, we're currently we, we send out of rounds and we use the rounds for refreshes. And why is this? Because the receiver needs to be online and the sender always needs to be online A refresh, the receiver and the sender is the same person, and since the sender has to be online anyway, he's also the receiver, so it doesn't add any requirements, any interactivity requirements. But with CTV, you could also send the VTX immediately without having to use Arqur to someone else. Arqur is usually the better option, but if you really want something, I don't know, if you're doing like plus hundred k US dollars or something like that, you're buying a car or something, you may, you might want to send something in rounds, and that's while with CTV, you could just say, \"Hey, I'm, I'm sending this, this 50x to this person and not myself,\" and then it, it would be possible."
    },
    {
      "speaker": "stephan",
      "time": "01:05:33",
      "start": 3933.92,
      "text": "Interesting, yeah. So, and as I'm understanding, the point here is At least the approach that, let's say the ARK, you know, teams, both yourself and the other ARK Labs team, are taking is more like, \"Let's build with what we have today,\" but I guess you're also- Separately, trying to explain and show, well, if we had CTV or TX hash and, and so on, that these are the efficiency gains we could get. But the point is to show at least Today, k- and can there be users? Can there be, some kind of efficiency or at least some kind of onboarding use case even with CLARK as it exists today before adding like the CTV and all these things, right?"
    },
    {
      "speaker": "steven_roose",
      "time": "01:06:19",
      "start": 3979.34,
      "text": "Yeah, yeah, yeah, definitely. Like, we're definitely confident that we can build something that is already like a good benefit over like lots of the current light, self-custodial lightning experiences just with, with what we have today in Bitcoin, in the clorak version, right? The covenant-less version. and we're also in a very good position when it comes to covenants because in theory, any covenant possible would make, would make a difference for us, would make it better for us. So like We just want something to happen at, at some point, and then we will be happy. It's not like we need something very specific. So, yeah, well, we're definitely in the covenant camp, and we're definitely trying to make Bitcoin better also on this front, also to enable a lot of other things that have nothing to do with ARC. But yeah, we're also not too worried, or not too like time sensitive because what we're building right now, I think, can be very valuable as well without having the covenants yet. So, and, and I think if we-- if, if this wasn't possible, we wouldn't, we wouldn't be building it today because it's a lot of work. As you can see, we've been six months in or even more, and we still have some work to do. but of course, we want to deliver user ex-ex-experience, and we don't want"
    },
    {
      "speaker": "stephan",
      "time": "01:07:32",
      "start": 4052.26,
      "text": "and so I, you know, I don't consider myself a technical protocol expert or anything, but from your perspective, you know, you're someone who's really deeply into this, can you explain your thoughts on? It seems like developers are excited about CTV and Trezor and Stack. Can you explain a little bit of your perspective on this, like? Why, what's, you know, why, why is this a useful path forward, from your perspective? And, what do you, you know, what do you see being enabled, by CTV and Trezor from Stack?"
    },
    {
      "speaker": "steven_roose",
      "time": "01:08:07",
      "start": 4087.72,
      "text": "yeah, so this, yeah, so the people that are following, there's been some noise or some movement around the CTV plus Check Stick from Stack package as like a, a potential software up, up, upgrade. it mostly started from some, some Twitter things going on and, and I posted some kind of roadmap that I thought was a, a good roadmap. Obviously, it was Twitter, so it wasn't like I thought a whole lot about it. and then they start-- people started to be like a little bit interested in this. And one of the main points that- That I found compelling in this is that CTV and CheckSigFromStack are both very simple primitives, like they're very technically very well, well specified, and there's not much bike shedding potential, and they're all, like, they're all, all, several years old. CTV has been proposed maybe like four or five years ago, quite some time ago, and CheckSigFromStack has been in liquid since seven years ago, and they're both like doing a very specific thing. So I think since they're Going to be useful into the future anyway, even if we have more complex governance like, C-check contract verify or TX hash or, or stuff like that or direct introspection, I think having either C-CtV and check sig from sig are gonna be useful anyway. So my point of view was, if we're gonna use them in the future anyway, why not already add those while we work out which other things we think are useful, right? I mean, any Any software upgrade that enables governance in a good way is gonna involve multiple moving parts that are a little bit independent from each other. And I, I don't think we need to package everything in one go and like, okay, this is everything you need to do the perfect governance and then do it in one go. I think it makes sense to first start with some smaller building blocks and then see which other building blocks we want to build on top of that. and I just thought CTV and Trezor from Stack were really good small first building blocks. independently, they don't enable everything that we want to enable, like with full covenants, right? They don't-- they're not magical tools, they're quite simple, but there's still, I think, quite some compelling things that you can do using CTV and Trezor from Stack, things like L2, like the Lightning symmetry that people have been talking about for a long time. The interest in symmetry has been gone up and down a little bit a- among Which we're very excited about, the all the things I mentioned with ARC you can do, and then there's some, some smaller optimizations or, or changes that can be made to things like DLCs, to things like Even very primitive faults or stuff like that, there's a lot of discussion of, can we really say CTV can do faults? Can we really say CTV can do X or Y? And it's like, yeah, maybe not the way we really want this to be done, but we can already like move the needle a little bit forward and then see what else we need to make the full, the full faults, the full coin pools, the full, like Bithumb like off-chain, like proving protocols, like Yeah, I think, I think we're a bit far from having the full covenant pa-package figured out, and I think we have iterated and thought enough about CTV and cheque cheque from Slack specifically that we can enable them, we see some value in them, and we can keep them, even when we move beyond, like, even if we move into more elaborate constructions like the full covenants. But yeah, I mean, it's definitely a, a difficult"
    },
    {
      "speaker": "stephan",
      "time": "01:11:30",
      "start": 4290.04,
      "text": "topic to talk about. Sure. Yeah. And I, I get the sense, or at least from what I'm seeing, some developers are saying is that these are Small changes that are relatively well understood. So exactly, do you think-- I guess the, let's say the \"quote-unquote\" ossifier might Look at that. Now, I'm not an ossifier myself, but could an ossifier say, \"Well, could there be some kind of deep implication of you create this or you enable this, you're gonna, you're gonna, you're gonna enable some other things that they don't want?\" I, I'm not quite like, I'm curious how you see that or how you think about that."
    },
    {
      "speaker": "steven_roose",
      "time": "01:12:10",
      "start": 4330.47,
      "text": "I mean, specifically these two opcodes are so basic, it's really hard to do any like cool stuff basically. I mean, and that's, that's, that's where the discussion also halts a little bit because for some people it's like Oh, we can't do enough. Like, what you-- what this enables isn't enough to, to convince us that we should do a soft fork, because a soft fork isn't something you just do every day. So some people are like, \"Okay, sure, you can improve R and do L2, but like, is this, is this enough to do a soft fork?\" So like, I think it's not enough, yeah. Exactly. So on, on this, on this argument, I think, I don't think it would upset any ossifigers or people who are afraid of fully"
    },
    {
      "speaker": "steven_roose",
      "time": "01:12:50",
      "start": 4370.85,
      "text": "Elaborate constructions that, that, that Covenants can give, things like market makers, kin, things like coin pools, things like, like that. there's nothing like that that's kind of possible in a real way to build with this. So, yeah, I think that's, that's for me one of the compelling arguments so that we can already innovate, even if it's a little bit on ARC, on Lightning, stuff like that, without having fully figured out as a community. What kind of covenants are we scared about when it comes to MEV or something like that? What kind of covenants do we really want to build? Which ones do we not want to build? How do we want to build them? Because we still have several different proposals on, on how to build, like Good covenants in a good developer friendly way and in a network safe way. So while we still figure those things out, I think those two are tools that can be used in, in, in surprising ways. Like, like I said, CTV's been around for like something like four years, and only last year, maybe"
    },
    {
      "speaker": "stephan",
      "time": "01:13:46",
      "start": 4426.66,
      "text": "since twenty nineteen, I think, so maybe like five or six"
    },
    {
      "speaker": "steven_roose",
      "time": "01:13:49",
      "start": 4429.35,
      "text": "years, that's fine, yeah, yeah. For, for a long time, and only last year, someone came up with ARK, right? I mean, ARK is something that was actually entirely built on CTV. We kind of made tweaks to not need CTV in the end, but it was totally built on CTV, and this was three years or four years after CTV was existed. Barrier and how far they can think into possible protocols a bit further. So maybe there's gonna be something really cool that XEC from Stack and CTV enabled that we only find out two years after it's been, it's been activated, but, but you never know. Yeah."
    },
    {
      "speaker": "stephan",
      "time": "01:14:26",
      "start": 4466.73,
      "text": "Yeah, and I mean, I, I think it would be, it sounds like, from what I've heard from developers, it sounds like it would really get us more efficiency, whether that's Lightning and Lightning symmetry or L2 or Dark or whatever the different forms of, you know, people are talking about with that or on the Ark side, the improvements you've mentioned there, but, I guess, it'll take some time and maybe people have to sort of see some, see some people using, let's say, Clark, the covenantless form of Ark, and then maybe after some time of that, then they think, okay, yeah, let's We want CTV and Czech Sig from SAC, I mean, who knows, right? so let's, I guess, let's close up and if you have any closing thoughts on, you know, bringing it back to Bitcoin today, what's possible today with ARC, can you spell out for people what are they missing? What is, what is the big takeaway that you think most Bitcoiners don't understand about ARC and what it can do for people?"
    },
    {
      "speaker": "steven_roose",
      "time": "01:15:22",
      "start": 4522.46,
      "text": "I mean, the biggest one is that it, it exists, right? I mean, we're actually building it, we're targeting for mainnet, and currently you can try it out on Signet. So like, go try it out because it's actually a thing. It's actually making Lightning payments possible without all the headaches that traditionally came with Lightning. We've talked with several wallet developers who have tried to integrate Lightning. They have tried different, different approaches, different like stacks, like the, the Breeze stack that is now based on Liquid or something like that, or then the, the Greenlight stack And they've tried several of them and they weren't very satisfied because it's-- there's always a little bit of hurdles that they don't want their users to need to take on. and with, with, with Ark, the user experience is just slightly better than all that, even, even without covenants or even without whatever today on Bitcoin, we can have an experience that is, that is better than what we have today. It's way easier for developers to actually give this experience to their users. so yeah, try it. We have, we have the, the, the tutorial and the things up if you go to second dot tech, and you can just play with it. We have a little store where you can pay some Lightning payments using ARC, we have a faucet where you can get some ARC, coins. And the next step will be making this SDK implementable in mobile wallets or, yeah, mobile platforms."
    },
    {
      "speaker": "stephan",
      "time": "01:16:41",
      "start": 4601.57,
      "text": "Excellent. Well, yeah, let's see, maybe, this will be a good way to onboard people where those people would have otherwise been custodial. So I think that's something that, let's say, most of us who are ideological Bitcoiners, we would like that. We want more people to, you know, not your keys, not your coins. so, yeah, let's leave it there. Listeners, check it out. Links will be in the Is second dot tech, and Steven, thanks for joining me today."
    },
    {
      "speaker": "steven_roose",
      "time": "01:17:06",
      "start": 4626.01,
      "text": "Awesome, yeah, thank you for having me."
    }
  ]
}