Stephan Livera Podcast—Steven Roose on Ark

CEO Steven Roose gave a comprehensive update on the state of the Ark protocol on the Stephan Livera Podcast, so we're sharing the transcript here for those that prefer those!

Stephan: Hi everyone, you're watching Stephan Livera Podcast brought to you by Bold. For American listeners, go to getbold.to to buy bitcoin now. Rejoining me on the show is Steven Roose. He is the CEO and co-founder of Second BTC, and they're one of the teams working on Ark, which is another L2 for bitcoin other than Lightning. We're going to get into this—obviously there's a bunch of different things you guys have with this signet launch and other things going on. First of all, welcome back to the show.

Steven: Thank you, very excited to be here. Thank you for having us.

Stephan: I know there's a lot of different things happening, so let's try to set the stage for people. This is another L2 for bitcoin. What is the promise here? As I understand, you're trying to use Ark to also make Lightning better. Is that one way to understand it, or are you trying to use Ark as a way for more people to use self-custody bitcoin? Can you elaborate a bit on the high-level vision here?

What is Ark?

Steven: Yeah, sure. 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 Ark is a different second layer protocol that works entirely differently than Lightning, but it's compatible with Lightning as well.

End users who don't want to have a whole Lightning setup can use Ark. 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 Ark is a client-server protocol. The server only is there to help the user make payments, but it's never taking custody of the funds. The Ark protocol is totally self-custodial, but it's basically making it easier for users to make Lightning payments and onchain payments, or just holding your money.

Stephan: Just to summarize for some listeners—obviously some listeners are quite techy and developers and they get all this—but just for the non-developer listeners: The idea is with a lot of bitcoin 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 others out there, or KYC Lightning things like Strike or whatever else.

Again, I'm not criticizing—I obviously want more people to use bitcoin in general—but of course it would be good for more people to have these self-custodial options. What drove them to the custodial options? It's things like having to manage channels or managing the liquidity—how much is on that side of the channel, and what are the fees if I need to go to chain. These are some of the things that if you were to try and do fully self-custodial Lightning, these are the requirements. Can you explain a little bit about why you see Ark alleviating some of those concerns?

What is the Ark approach to self-custody?

Steven: From our perspective, there are 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 onchain transactions.

Currently, we are at a historic low when it comes to onchain transaction fees, but in the past they have been a lot higher, and we anticipate that in the future they might also rise again. Then these interactions with your channels can become very costly.

Second of all, 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. If you don't have inbound liquidity, you cannot receive any payments. It's usually not easy to convince someone to put money locked in a channel only with you. That's why most of the Lightning wallets right now allow you to basically purchase or rent some inbound liquidity where they charge you a fee, and then you can have inbound liquidity.

These are the two main hurdles that you don't have with Ark because you don't need channels. You can always receive without needing specific inbound liquidity because this is all handled by the server. You don't need to create channels or rebalance because all your balance is kept in the Ark totally offchain, and you don't need to manage this liquidity yourself because there are no channels.

Stephan: 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're kind of stuck with one of 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. Who's maintaining that? Any of those three options, you know, has tradeoffs around it. That's the nature of how things are.

What I'm understanding here is Ark can help you in terms of onboarding a new user with a different set of tradeoffs. It's important to understand it's not free—there's no free lunch here—but it's a different set of tradeoffs. Can you explain a little bit about that and why it's better from an onboarding perspective?

Reducing the onboarding hurdle for users with Ark

Steven: The onboarding problem is particularly difficult because if you don't have anything, you don't have channels, and someone (a friend or someone) wants to send you their first payment or your first payment, and you want to receive maybe 10 bucks, 20 bucks, it's really not possible 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.

In Ark, you don't have any of this. You can immediately receive an offchain VTXO—VTXO is basically a unit of money in Ark. So you can immediately receive some offchain money, and there's no need for a setup. You can just open an app that would support Ark, and immediately you can make your first receive.

I think that is mainly why the onboarding 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 onchain funds instantly, which is something that with Lightning is not possible today. 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 10 bucks," and it will immediately show up in their wallet. But that's not really possible with fully self-custodial Lightning.

Stephan: Okay, and now let's just compare this with, you know, people might have heard of or they might be using other approaches—things like Liquid, right? As an example, and I know 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 Ark onboarding with, let's say, an LBTC Liquid style onboarding or an ecash, let's say a Cashu or a Fedimint onboarding? How does Ark compare with those?

How does Ark compare with Liquid & eCash?

Steven: They're all similar in the sense that there's some third party helping you do your bitcoin stuff, right? So it's not like your onchain wallet where there's just a peer-to-peer network. But in both Liquid, Cashu, and Ark, there's some kind of server that is helping you do this.

What differentiates Ark is mostly that the server at no point is in control of any money. So it's totally self-custodial, while in the Cashu case, for example, it's kind of fully custodial. It's fully custodial—the Cashu mint has all the money and it gives you tokens that you can then anonymously and privately use to send Lightning payments and send this Cashu, this e-cash around. But the money in the end is all handled by the Cashu mint.

It's possible to make a Federated cash mint, I imagine, where it's multiple people, but still, the money is controlled by other people. In Liquid, it's also the case—they have a big Federation of 15 different companies that hold the money jointly, like collaboratively, but still it's those people that have the money in their hands. If something goes wrong, it's always possible that the money doesn't end up back into your hands if you would need it.

With Ark, 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 offchain payments and Lightning payments.

Stephan: So in other words, am I understanding it correctly then? The Ark wallet that you are creating—the idea is 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 them manage that. But the point is unilateral exit, right? The idea is if they wanted to go to chain and take those funds onchain, they can do that. That's the difference you're pointing at, right?

Steven: Exactly, exactly. And the server doesn't really help you manage it as much as it helps you set it up in the first place. So your wallet manages all the transactions that it would need to broadcast in case of a unilateral exit, and it manages your VTXOs.

But every time they are about to expire—we can maybe go into the expiration thing later on—but whenever they're about to expire, the coordinator in the server will help you refresh them and create new ones. 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 pay or if you want to transfer them to someone else.

The server is also a Lightning gateway because the VTXOs are not channels, so we use trustless swaps so you can get your VTXO onto the Lightning network in a payment in one go. Currently, the Ark 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. Then the coordinator will help you make Lightning payments, help you refresh your VTXOs, and help you pass on your VTXO to other people.

Stephan: Gotcha. There are a few terms that we should help explain, and maybe some of this terminology has shifted a little. 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. There are a few other terms you mentioned there: ASP, I guess, is like an Ark server, and then the coordinator and the Lightning gateway. I guess the Lightning gateway and the coordinator are the same, right?

If you could explain a little bit about the user and the server and how that interaction works from an Ark perspective?

How does a user interact with an Ark server?

Steven: In Ark, each Ark is like a small bubble. All your interactions will happen within your Ark with your single Ark server. There's not really any crossover to different Arks.

If I'm in a different Ark than you are, we can pay each other through Lightning, and Lightning will be the bridge. Or we can do direct swaps from my Ark to your Ark, but you cannot move the money directly from one Ark to the other. You either have to swap or use Lightning.

So all your interactions as a user will be with a single server. You know the address of the server, your wallet will be configured to talk with that server, and every time you want to do something, you just talk with the server. 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 can always use your unilateral exit and broadcast your transactions to the chain and have your money back.

Stephan: And could you also explain for us at least the current understanding of what's happening in terms of the rounds? As I understand, there are rounds, and I think historically you had this—was it arkoor payment? It was like out of round or maybe you could explain a bit about this because it might have changed from how I'm understanding it.

How do Ark rounds work?

Steven: The protocol definitely changed a lot since it was invented, but we're kind of settling on the way forward and the current way.

The rounds are kind of the core of the protocol because the rounds are when the new VTXOs—we call them virtual UTXOs, the offchain UTXOs—when they're issued. So they are created during rounds. Initially, 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.

A VTXO in Ark has an expiry time. We imagine they 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. In the round, you will tell the server, "Hey, I have these VTXOs that are about to expire, I want new ones in return," and then they have a fresh expiry time.

Rounds would happen something 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.

Then when you want to make payments to other people, we use what we call out-of-round payments, or arkoor for short. What you do then is that you have an existing VTXO, and you just make a transaction on top of this to basically pass it on. It's kind of like an onchain transaction where you have a new transaction that spends this transaction as an input and creates new outputs. It works exactly in the same way, but the difference is that this transaction stays entirely offchain.

So you can make multiple ones of these—kind of like a mini transaction chain offchain—and you don't have to do any rounds for these transactions to confirm. They're instant. This is also how you make Lightning payments. If you make a Lightning payment, you basically make a small arkoor payment that creates an HTLC and creates some change. Then the HTLC goes on the Lightning network, the change becomes your new VTXO, and then at some point the VTXO will expire, and then you use the rounds to refresh it, and you get a fresh VTXO again.

Stephan: I see. So my caveman/layman understanding: let's say I've got an Ark wallet as an end user, and I want to make a Lightning payment. For me, the way it looks would be like I scan and make a Lightning payment like I normally would, but actually what's happening is I'm doing a payment that kind of goes to my Ark server, and my Ark server has the Lightning gateway that actually makes the payment on my behalf, and then I'm getting back a VTXO with the change later? Or how does that work?

Steven: It's not really on your behalf because what happens between you and the server is also an HTLC. It's kind of like the same thing as if we would have a channel—a bit more trustless in that way. It's totally trustless. It's like as if we would have a channel, because in Lightning, HTLCs are built on top of channels, right? But they don't necessarily need to be built on top of channels. It's just a contract, an HTLC contract.

So we just build an HTLC in the Ark, not on a channel, which basically tells the ASP, "Hey, if you can give the preimage, then I can give you the money." Then the ASP can use the Lightning network to get the preimage from the eventual receiver of the payment, and then the money gets unlocked atomically in the Ark and in the Lightning network.

Stephan: I see. So it's actually a stronger level of trust minimization compared to some of the other approaches because of that?

Steven: It's fully trustless—the HTLC is there. If there's no preimage, the money does not go to the ASP at all.

Stephan: I see. That's another thing about Lightning—the idea is there's this preimage, and you need to make sure it gets to the other side before they release...

Steven: Exactly. 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 Ark are a little bit more complicated, so we have to be careful that the timings are right. But that's getting very technically into the weeds.

Stephan: Yeah, we don't have to go to that level of it. So who do you see as the main users of Ark?

Who benefits from Ark?

Steven: We think that just individuals who want to make payments have the most benefit from Ark. We think if you're 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 volume.

But we think any user who just wants to make several payments a day, who just wants to have a mobile app and wants to go to a shop and pay, will have more benefit from using Ark than from trying to set up custodial Lightning.

And the same wallet, the same Ark wallet, can also just make any offchain payments. So even if you would receive your salary in your Ark wallet, you can easily send back to your cold storage. It's kind of a fully working bitcoin wallet that does both onchain and Lightning without much management and headaches.

Stephan: I see. So I guess the way you're explaining it there is it could be like a unified balance you don't have to think about as much. Am I onchain? Am I offchain? It's just kind of "here's my balance, I can just make payments with it" and not really worry too much in the background.

In terms of capacity and things like that, you don't really have to think about that. It's not that "Oh, I need this much inbound capacity" or none of that. Just if I want to make an onchain payment... here's the example: Let's say I want to make an onchain payment out of my VTXO balance, how does that part work? Let's say I've got 1 million sats and I want to make an onchain payment for 0.1 million sats (100,000 sats). How does that work in Ark?

Steven: To make onchain payments, you have to wait for a round. They're not out-of-round—there's no out-of-round onchain payments. What you would do is you would tell the server, "Next round I want to make this onchain payment," and then when the round happens, the server will create an output on the round transaction.

Every round, a new onchain transaction is broadcast that issues all the VTXOs offchain, but it can also create outputs onchain. Then you would pay a little bit of a fee because you pay the onchain fee just for your output, just for your script. Then at the end of the round, the onchain output would be created, and you would either have some of your change in VTXOs, or the change can stay offchain.

Stephan: I see. And so is there any concept here of "you need to add enough fee to get it confirmed," or is that handled by what the server does for you?

Steven: Exactly. As the server, because the round transactions are usually very small—they're usually a few inputs and then two or three outputs—we really overpay fees to make them confirm because this is the essence of our protocol.

For the user, you don't have to worry about replace-by-fee or something like that. The server will make sure the transaction confirms, and they will charge you just the fee for your output. So you don't pay onchain fees for your inputs or for your change; you only pay the onchain fee for the output that you really need.

Stephan: I see. And then I guess the trade-off in one sense is you make your payment onchain and it goes once an hour—you can't make an instant onchain payment. So that's one downside maybe for some listeners or some users that would be annoying for them. But hopefully, over time, as Lightning grows, more and more people would just do Lightning payments anyway, so then this will be less and less of an issue.

While we're on the topic of who is the typical user—are we talking here like a retail user? This is not for high-value, large amounts, right? Or how do you see it?

Steven: The thing that I mostly think Lightning still benefits is high volume—thousands of payments, like stores, online merchants, stuff like that. But the amounts don't really make much of a difference.

Just like you know that onchain, your fee is based on the amount of bytes in your transaction and not based on the amount of money, the same is true in Ark. The fees are 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 Ark, just like in Lightning.

Lightning in the beginning had this "reckless" mode, the wumbo channels, where they tried to discourage users from putting a lot of money in the channels. But I think at this point, Lightning is secure enough that it also works for larger amounts.

Stephan: I see. So it's not actually limited just to coffee payments and small retail—you actually could do multi-thousand, $10,000, $100,000 payments theoretically?

Steven: I think so. I don't see a reason why we wouldn't. Obviously, the more money is in it, the more careful you have to be that you refresh them on time because otherwise, you can get into trouble. But I think either your app provider or your wallet provider will make sure that that happens.

[Ad break: Coin Kite and Cold Card security devices]

Stephan: While we're on the topic of apps and refreshing and so on, one thing people talk about with mobile is that Android and Apple are getting aggressive about battery management, so they don't let you do things in the background. How do you get around that? Because as I understand, the app has to wake up every now and again and sort of do a refresh. How do you manage that?

Ark mobile experience and app management challenges

Steven: That's a very good question, and that's why we're also launching this product now on signet, because we want to start experimenting with this and learning the pains. We are not planning ourselves to release a mobile app, but we are partnering with different app developers who want to integrate Ark and who have the mobile experience but who don't really know how the Ark interactions will work.

So we're trying to tailor our SDK, our wallet, and our platform to be as mobile-friendly 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 as you say, the mobile platforms are not easy to develop on, especially not if you need to do background work, and it's important that you just occasionally wake up and have a chance to refresh your VTXOs.

I think it's going to be an interesting ride and a collaboration between us and different app providers. If there's people building iOS-only or Android-only or cross-platform in different ways, we will have to talk with them, look at the ways they have to wake up the phones of their users so that they can participate in rounds.

What we can do on our side is try to make 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. It's still to be seen how far we can go to make it fully user-friendly depending on the platform.

That's why we launched this test version, because we want to start learning this as soon as possible. Our company's goal is to get payments into the hands of end users, and we know that obviously that will be mobile—people are not making payments from their desktop computers. So we want to get that mobile experience as soon as we can.

Stephan: As I understand, right now, if I think of, let's say, Phoenix wallet, they are using some Google Play thing where they can send a notification and make your phone wake up to take a payment. So I presume it will be something similar to that.

Let's talk a little bit about signet. You've done this signet launch—what's the overview of the signet launch?

Ark's signet launch

Steven: We basically wanted to get our product in the hands of some early adopter users, some first movers who just want to play with it and want to see how it feels like. We especially hope that we will get some app developers excited to start trying to integrate this SDK into their apps.

What we did was we launched our Ark 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 offchain money from our faucet (the faucet is providing offchain and also onchain money if you need it on signet), and then we provided a small store where you could buy some treats for our mascot called Bite.

Basically, we're showcasing that you can also make small payments. It shows you a Lightning invoice, you copy-paste it into your CLI because it's only in the terminal for now, and then you can make some payments from your bark wallet.

We're trying to get users, and mostly developers, to see that this is something that's actually working and that is improving rapidly, and to get them excited to try and integrate this into some of their apps or platforms or wallets in different kinds of ways.

Stephan: In current form, how many people can use Ark 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 tradeoffs of not having like a CTV or things like that, or TXHASH or whatever, is that there's more interactivity. What does that mean in practice for users today?

What are the user limits for Ark?

Steven: That's another reason why we want to get people to test this, because we don't have much real-world usage examples. We have some tests—I can tell you that we have tests where we run up until like 100 participants in each round, but not much further beyond that. Because if you do it all on the same computer, it's also not really a good use case.

So we don't really know—in theory, the limits should be pretty high. The real limitation at this point is: does the user have enough time and bandwidth 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, a bunch of signatures on a bunch of different offchain transactions in preparation for the rounds. On mobile, that means you need to send a lot of cryptographic nonces, then signatures, and all of this needs to be done each round.

Just to make it clear, because some people make this mistake: you don't have to participate in each round. As a user, you only participate in a round if you need something from the round—if you need to refresh some VTXOs or if you need to make an onchain 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 succeeding in participating in these rounds.

The limitation depends on how many users can participate in each round. You only need to participate once every one or two months with your VTXOs. So you can do the math: multiply the number of outputs we could have in a round—I'm imagining something in the limit with the current model would maybe be somewhere around a few thousand per hour—and then multiply that by a whole month or two.

Stephan: So we're talking like 50,000-100,000 users, probably?

Steven: Yeah, and then with CTV we would cut a lot of this interaction. There are also other ways that we're still thinking about that can cut down on a lot of bandwidth and interactions needed when it comes to signing for transactions, which is an essential part of the round that we will always need to do, even with CTV.

But we definitely have to have more real-world usage examples and tests because if we run tests on different servers and such, it's very different than people running on mobile network connections in different continents.

Stephan: I see. Because as you were just saying, it could be a few thousand in each round, and that could mean maybe 50,000 people have an Ark wallet on their phone, but only a few at each time are in a round.

But I guess the other downside to deal with is if these are users who have not done a transaction in a while, then the way phones do their battery management is they'll say something like, "Oh, this app has not been used in a month or two months, therefore, deprioritize it and don't allow it to wake up in the background." So those are things you're dealing with.

Steven: Those are things that we don't have any control over that will depend on the app developers and the platforms that they use.

One thing that's very interesting, I think, is that all these problems in scaling the rounds has to do with the number of users, not the number of payments. So even if users make a really lot of payments, this makes no difference for the limitations on the rounds. I think this is good because we can just scale up our user base and then have them make as many payments as they want. We don't need to limit the amount of payments that you can make.

Stephan: Let's talk about some uses though, because I think it's important to put some practical uses here. As an example, maybe someone who wants to do a non-custodial exchange—maybe they could set up an Ark thing, and their customers who are stacking could get a new VTXO every week. Or let's say they're doing a DCA and they want to buy some every week, they could get new VTXOs until the point that they actually have enough to go onchain, for example.

Practical use cases for Ark in bitcoin transactions; Importance of self-custody in bitcoin

Steven: This is one of the use cases that I mentioned when I was making the case for CTV for Ark. A third party, like an exchange, can actually issue independently using CTV a bunch of VTXOs, and there is no round needed, there is no interaction needed. They can deliver tens of thousands of VTXOs in one single onchain 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.

Again, it's not the amount of payments that matter, it's the amount of users that matter. 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 day, but this doesn't put a limit on the amount of users that we can have because it's only when we do actual rounds that we need to look for that.

If we start to grow and we have too many users and the rounds are too slow or too full, we can always do more rounds. We can say every half hour, every 10 minutes—maybe we'll have one round per block, and then your confirmation time for your onchain payment is going to be the same as a normal onchain payment because there's a round every block.

Doing more frequent rounds increases the onchain cost for the server, but if there are so many users that actually need this space, we can probably pay for that onchain cost. 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 usage to pay for that usage of the chain.

Stephan: Interesting. That could be interesting for people who really want to focus on the "not your keys, not your coins" self-custodial adoption. It could be made a lot easier as opposed to pushing a lot of people into custodial, which is where a lot of people are now, whether we like it or not.

I think it's 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 in the actual day-to-day paying for coffee with Lightning and Ark and whatever.

But this might be an example where Ark could be used to have people stacking in a self-custodial way as opposed to putting all that risk into the exchange and the custodian.

Steven: There's definitely a space for custodial bitcoin as well. I think projects like Fedimint, projects like Cashu, and even just fully custodial things like Wallet of Satoshi, or even banks going into the custodial bitcoin space like Revolut and such—I think they have their place.

But I think it's very important for us as a community that it's possible and has a proper user experience when you want to be fully self-custodial. There will always be people who either need this for political reasons, or people who are targeted by the places they live in, or they just don't want to trust the bank.

There are always going to be risks involved with third parties, and at some point, as the amount of money that you're managing gets too high for you to take that risk—and people have different risk thresholds—we feel it's really important that self-custodial bitcoin stays possible and not just for saving but also for payments.

Because right now, like you say, saving non-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 it just works better.

And I think, as you say, the West 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 struggling to onboard those people who need the payments more than the savings because the payments user experience hasn't been great. I think if we can improve that, we can get them using bitcoin more as a payment system, and eventually, they will use it for savings as well. Because if they receive their payments there, it's where they're going to save.

Stephan: Interesting. I think some of that comes into just getting more people using even Lightning. I've seen a lot of news recently about Breez SDK getting a lot of progress, kind of getting companies on board—and not even crypto companies, but fiat companies that had nothing to do with bitcoin or crypto 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. Then hopefully there's actually more use for that.

But I think we also have to just be honest and look at the fact that recently there's not a lot of use onchain, and there's a lot of people onboarding through ETFs and MSTR and things like this. So that's just kind of where we're at. Of course, I want more people to self-custody, but we have to sort of see that's where it's at for now.

But anyway, enough about that. 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? What's the difference in the approach there?

What is the difference between Second and Ark Labs?

Steven: Well, that's a difficult question because I don't like to speak on behalf of others, but I think I can say that the team at Ark Labs 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 on different things right now.

I think the biggest difference was that they initially launched on Liquid using the Liquid covenants. They have—they're currently also trying to focus on their main efforts, so on that point, we kind of streamlined again.

I don't really know—I cannot 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 platform for people to build apps on top and stuff like that, which I think is also valuable. But I think it's hard to balance those things because if you're focusing on payments, you really want to focus on a very specific thing like low latency, small footprints for mobile, and all that stuff. While if you're focusing on 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 the way that it will go, but that's one of the main differences that I'm seeing today, other than programming language we use, tech that we use—but those are all minor differences.

I think the good thing about Ark is that, unlike Lightning, which is a protocol network where all the implementations need to be completely compatible with each other because they're just exchanging messages and doing stuff cooperatively between different implementations, in Ark, your server is kind of a bubble. So their implementation, our implementation—even though they're both Ark and it's kind of the same protocol—we can make totally different design decisions. We can have totally different implementations. The API protocol between the users and the server can be totally different.

So we don't need to align on too many things. We can experiment in different directions, and we can definitely learn from each other. We have, on both sides, seen the other side make a certain technical decision that we then realized was actually better and also took. So we're definitely learning from each other, and we'll see how it pans out.

Stephan: 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 requirements at the ASP or Ark server would be so high." What's the current thinking there?

What are the liquidity constraints in Ark?

Steven: It kind of ties into what I said in the beginning of the podcast, where we're currently only using rounds for refreshes—to refresh your current, your own VTXO—and not for payments. The liquidity constraints come when users interact with rounds. Actually, the fact that now we're trying to have all the users make their payments offchain, out of round so to speak, in the arkoor payments, there's no liquidity requirement there whatsoever.

So when users do just arkoor payments, it's all fine. And when they enter the rounds, the liquidity constraint has to do with how close the VTXO is to expiring, because we kind of need to bridge the gap until the expiry. It's hard to explain in a few minutes on a podcast, but the fact that users are submitting their expiring VTXOs in a round almost right before they expire really minimizes our liquidity constraints.

So we're kind of optimistic in this current model where most users will feel comfortable enough to hold on to their arkoor VTXOs until they expire and then only refresh a few days before the expiry of the VTXOs, because it really reduces the liquidity constraints from the server point of view.

I think this will be the primary model for most users. The other users that don't like this model and try to refresh their VTXOs more frequently will have to pay their liquidity fee. We still did some number crunching—it isn't that bad. It's probably around what current Lightning apps are charging you, so it's still quite competitive.

So regarding liquidity, we're kind of positive on this note. It was really a big problem when, in this model where it was five rounds, every payment goes through a round, because in that model, the requirement for the server would be incredibly high, and it was really not possible. But the decisions that we made in the design since then have helped us a lot.

Stephan: I see. So basically, that liquidity constraint has come down a lot, or at least the requirement has come down a lot.

Steven: We think 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 Lightning, your liquidity is locked up, tied to a specific user, and they need this liquidity to be able to receive. But if they're not sending or receiving or doing anything, the money is just there stuck.

In Ark, the liquidity is just one single liquidity pool for all users. So it's way easier to more efficiently allocate this liquidity—it's always there, so it's always usable by all users at the same time. So you don't have to decide, "Oh, is this user going to make enough payments? Is it going to be worth it for me to put this amount of money in there, in this channel with him?" We don't have to make those decisions.

[Ad break: Bold bitcoin platform]

Stephan: When it comes to fees, you're talking a little bit about this. Given that you're focusing on the server side and protocol aspects, and the apps are going to be handling the end user apps, does that mean the app guys are going to be the ones charging the fees? Or are you charging a fee at the server level, and the apps are going to charge their own app-level fee? How would that look?

Understanding the cost structures in Ark

Steven: That's a good question. Currently, what we know for sure is the cost basis that we have as a server. Whenever users do rounds, we need to provide liquidity, and this has a cost. We need to make chain transactions, and this has a cost. So there's definitely a cost for us when users do rounds, and this is a function of how much money is in the Ark because the rounds only happen due to expiry. They're basically users continuing to be part of the Ark.

When they make offchain payments, there's not really a big cost for us. We just need to co-sign some transactions. So we can either just make the users pay for our costs, but we feel that users like to pay fees when they transact and not just to have a balance. There's definitely a psychological aspect to that.

But when it comes to how it will work in the apps, those are really still questions that we have to figure out. We will have to charge a certain fee for our server, and the app provider will have to have their users pay those. I don't know how it will work with them also making something on top of that. Those are things that we will figure out once real apps are going to launch on mainnet, and we're going to have a bit of an open question as to what the business models will be.

Stephan: But theoretically, you would charge some kind of liquidity fee and kind of service and protocol fee at your level, and then the app guys are going to have to add something on their level too, and the end user will pay the combined fees.

I'm curious from your perspective—again, it's an open question, we don't know—but do you think those two combined fees that we were just talking about will be less than Lightning, 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?

Steven: I don't know the latest on fee schedules, but when we started the company, 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 1-hour round, 30-day expiry—it would be around 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 trust barriers there, like with the number of days before the expiry you actually go and refresh. I think at the time, half a percent was basically what Phoenix charged on receiving your money anyway. When you receive from onchain into your Phoenix wallet, they would charge you half a percent anyway. So just having a single receive is the same as having your money for a whole year in the Ark.

When it comes to individual payments, our cost base is so low, we can go really competitive, I think. But again, there is a cost base just to have your money in the Ark. So it's definitely not something where people will be holding their entire savings, because it might be cheaper to make a single offchain payment and then hold your money there for 20 years instead of in the Ark.

But I feel we can be really competitive on that front just because our liquidity management is very efficient. We just have to do the math.

Stephan: Interesting. I could probably look it up, but off the top of my head, I think the Phoenix fee, the async fee, I think it's on payments—it's 0.4% of the amount you're sending. So on $1,000 of a payment, it's like $4 worth of transaction fee. But also there's a swap-in fee, so if you take an onchain payment and you want that available in Lightning, I think that's 1% plus the mining fee, something like that. It's in that ballpark.

So I guess it'll depend, but also I think we have to remember what was the purpose of all this—the point was to 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, maybe it's a different 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. Then there were a few people saying, "Oh, why'd you do custodial? Could you have done some other thing?" In this case, would Ark—now again, you just launched on signet, not on mainnet—but hypothetically, if this was available on mainnet, could that have been an option?

The role of custodial solutions for onboarding users; Plans for mainnet launch

Steven: Definitely. That's definitely the kind of target integrator that we have. If you visit our website, it's one of the main talking points that we have—that we want to make it as easy as possible for an app developer to integrate Lightning.

So we want to have a very intuitive and simple SDK where you basically have some API calls from your wallet that holds you a balance that you can both make Lightning payments with and onchain payments with. That's basically the experience that we want to give to the developers.

So any DCA company that wants to have a built-in wallet, any wallet that wants to have a bitcoin wallet with a Lightning wallet combined, can definitely use our SDK or should try to start using our SDK because that's definitely what we're targeting for our product. So something like Orange Pill app is definitely yeah...

Stephan: Gotcha. But I guess for now it's early days because you're in signet. But once you—maybe it's again, you don't know yet—but do you know when you would look to go to mainnet? Are you going to try to go to mainnet in a year, or six months? Do you have an idea, or not yet?

Steven: Personally, I would really like to have mainnet by end of summer or something. But you know how engineering goes—hopefully this year would be really good. But I guess it also depends how things go in signet with people playing around.

Stephan: Definitely want some testing...

Steven: Yeah, exactly. And we definitely want to look for some integrators who are willing to take the first step, be the first mover, and already integrate even though we don't have mainnet yet. Just to see where the pain points are because it makes little sense to launch a mainnet and then realize that our product is not 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 then have our client be flexible enough to actually be an easy-to-integrate product.

Stephan: I think we touched on this a little bit in terms of business models. Like you're going to charge your fee, and the app creators are going to charge their fee. Are you going to be the only type of Ark server for what you're doing, or is the idea that there would be competing other Ark servers doing the same protocol? Can you explain a bit on that?

Is there a possibility of competing Ark servers in the future?

Steven: 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 Ark servers. It's definitely not as easy as setting up a Cashu mint or something like that—it's a bit more involved.

Also, the amount of liquidity you kind of need to service your users in a proper way is going to be a bit high. We don't really imagine that it's a "run the node from your home" kind of product. It's definitely possible for other parties to set up Ark servers, but 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 who knows—if it picks up and people really realize that this is a really good product to integrate for your wallets, maybe some larger parties will also run a server.

Stephan: I see. It's possible that some big exchange, let's say they want to do it, they might be like, "Hey, we'll just run our own Ark server." That could happen.

Steven: And I think from the user experience point of view, I think most app providers, just to make the user experience easier, will pick one server and just have this one as the default. But it's definitely possible that there are apps that let you choose a server, maybe even with a QR code where you can say, "Okay, I want to be part of this server." You scan a QR code, so you get all the details to be part of the server. Those things are possible.

We currently just focus on building our own server and then have the clients communicate with that. But everything is made—everything is ready for other people to run the same server.

Stephan: I see. 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 the nuances of it.

Steven: Exactly. In our benefit, I always think it's not easy to trust a server that someone else has built with millions of your own money. So I think we have an edge over other companies trying to run servers because we wrote the code. We understand kind of where you need to be careful.

So we will always have some kind of benefit in that sense. But who knows—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. That remains to be seen. Currently, we're focusing on having a service that runs and then users that can talk with it.

Stephan: Gotcha. One other question around the liquidity—just because I'm curious as well—as you were mentioning, the cost at least from a liquidity requirement at the Ark server level is if the end user wants to do a refresh of his VTXO well before it expires. Is my understanding correct?

Liquidity management & user fees

If my balance is 1 million sats and I want to refresh it one day before my expiry, that's not a very high liquidity requirement on you, the Ark server. But if I'm a baller and I've got 50 bitcoin or something—some ridiculous amount—and I want to refresh three weeks before my expiry, that places a much higher liquidity requirement. Am I understanding that correctly?

Steven: Liquidity is a simple multiplication. It's like the amount times the number of days or times the time. So if someone has one bitcoin and they're going to refresh one day before expiry, it's like one bitcoin-day that we have as a liquidity cost. If they want to do it one week before, we will have seven bitcoin-days liquidity cost. So it's literally a linear function.

What we will have to do is just charge them a certain fee on the bitcoin-days that they take—that they want us to provide this liquidity. So if you want to refresh earlier, you're going to pay a slightly higher fee. If you're going to refresh later, you're going to pay a slightly smaller fee. I think it can be pretty transparent.

One of the other numbers that we crunched in the beginning was the worst case. Let's say you want to refresh immediately. So you receive an offchain payment, it has still 30 days to go, you want to refresh it immediately over 30 days. I think the cost with some reasonable market rates that we found online was that it would be like 0.1% for the worst case. So it's still doable to pay 0.1% on a payment if you want full self-custodial security.

I think like you just mentioned the numbers from Phoenix—it's kind of still better than Phoenix, even though...

Stephan: I guess some 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?

Steven: It's not like other people can provide liquidity here, definitely not in a trustless way. We, as our company, will not have all this bitcoin to provide this liquidity, so we will also borrow it from liquidity providers. But this is more in a trustful way. There's no way to use the bitcoin blockchain as a contract so you can trustlessly...

We've been doing some thinking. There are certain few tradeoffs that we can make to give liquidity providers a few more guarantees than just fully 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 contracts and agreements that make sure that those things happen.

Stephan: Right, it's the course. I mean, between large businesses and banks and custodians and exchanges and all this—that's a different kettle of fish than the typical "not your keys, not your coins." And which is another reason why I don't imagine that groups of friends will run their own servers, because they would just need a lot of liquidity. The liquidity requirements would just be so high that it just wouldn't be practical.

Steven: Yeah, gotcha.

Stephan: 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 Covenant-less Ark. So just to make it clear for listeners, this is today without protocol change, without a soft fork of bitcoin.

I'm just curious as well to understand a little bit of your view on Ark with CTV or TXHASH or something like this. What would be concretely enabled by this, and what kind of efficiency gains do you see being possible there?

Ark's future with CTV

Steven: That's a good question. The current implementation that we're building is built on what we call co-signing. So the whole transaction tree, instead of being non-interactive, it's co-signed. 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 cannot change anymore if just one of the parties who are participating holds up the contract of the co-signature.

With CTV, you can just remove all of the signatures, all of the messages that need to be passed beforehand to make the signatures, and just immediately, the server can create the whole tree of transactions with all the different VTXOs in its leaves and just send them to the users and say, "Here, this is the tree that we're going to do for this round," and then immediately move on.

So there's definitely, primarily, a lot of efficiency gains. It reduces the protocol from being a three-step to a two-step process. It reduces the amount of data that needs to be passed. Especially on mobile, I think this can be a big benefit.

But then there are also a few things that are just not possible. The main way to think about it is that with clArk, the person who will eventually be the owner of a VTXO needs to be present when the VTXO is created, because otherwise, it's not trustless. Because they need to sign all the transactions that lead up to their VTXO. So if they're not present, it's not possible to create a VTXO for someone else in a trustless way.

There are a few things that would be enabled if it would be possible to create a VTXO for someone else.

One of the things is, as I already said before, some big payout provider like an exchange or a DCA provider, or even a miner—because this is also very interesting, I think, for miners—they cannot just create VTXOs for their users. With CTV, they could do that. They could basically create their own tree of VTXOs because a VTXO is just an onchain contract with a certain template. So anyone can create a VTXO for a certain Ark.

So then, for example, an exchange could just create a whole tree with 10,000 different payouts of different VTXOs, deterministically created using CTV and unfund the output, and suddenly tell the users, "Hey, here you have bunches of VTXOs" without needing the users to be there. I think that's something very powerful.

Another thing is, for example, for Lightning receives—as users might have noticed, it's not something we support right now in our signet. We had some ideas, we were refining the ideas still, and we didn't want to hold up doing this signet launch until we had everything figured out. But we have a version now that we're testing in our tests.

Lightning receive is a little bit more involved to do because, somehow, if your user doesn't have anything in the Ark and you want to receive some Lightning, there needs to be something created for the user in the Ark. With CTV, it would be a little bit easier because then the ASP could just create a VTXO with an HTLC again, but then an incoming HTLC, not an outgoing one. The user just gives the preimage, and from that point on, the user owns the VTXO.

Without CTV, the user would have to somehow be woken up like, "Hey, hey, you're going to receive a Lightning payment," and he needs to enter the next round, be online for maybe half an hour to wait for the round to start, and then do the whole shenanigans of participating in the round to then have their Lightning payment, instead of having just one message signature and done. So for Lightning receives, CTV also is very useful.

And then the last big thing is something that we want to provide as a service: when users forget to refresh their VTXOs before they expire. Your phone goes down, or you don't have internet for a week because you forgot, or like you say on iOS, your app got killed and it didn't manage to just wake up to refresh.

There are going to be cases when users forget to refresh their VTXOs in time, and they're going to expire. Obviously, we as the server don't intend to just take the money and be very happy with it. No, we want the user to have the money back.

What we want to do, and what we can do with CTV, is immediately when it expires, immediately reissue the VTXOs again, so that the users, when they come back online one day too late, will see, "Ah, okay, my money is still here, and it's still in a trustless VTXO." So then there's only this split second where the ASP could have done something bad but didn't.

It's actually also possible for the ASP 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, "Okay, this server has behaved well since its inception, and it has never taken anyone's money." This should give a little bit of a guarantee to users to put a little bit more trust into this server.

But without CTV, this is also not possible to do because you cannot recreate these VTXOs for the user. The user would have to be present for them to be created. So with CTV, we can just always see, "Oh, this VTXO expired; immediately we create them again in the next block." But that's not possible without CTV.

Stephan: I see. So just to clear up, to summarize, you've got this mass payout use, like the exchange/custodian, the trustless Lightning receive, and then also the refreshing case.

Steven: Oh, and one that I forgot—another one is just sending payments in rounds. Currently, we send out of rounds, and we use the rounds for refreshes. This is because the receiver needs to be online, and the sender always needs to be online, and it's kind of annoying to have them both need to be online. So when you do 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 interactivity requirements.

But with CTV, you could also send the VTXO immediately without having to use arkoor to someone else. Arkoor is usually the better option, but if you really want something—I don't know, if you're doing like plus $100K or something like that, you're buying a car or something—you might want to send something in rounds, and that's currently just not possible, while with CTV you could just say, "Hey, I'm sending this VTXO to this person and not myself," and then it would be possible.

Stephan: Interesting. As I'm understanding, the point here is—at least the approach that the Ark 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 TXHASH and so on, these are the efficiency gains we could get."

But the point is to show: at least today, 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 CTV and all these things, right?

Steven: Definitely. We're definitely confident that we can build something that is already a good benefit over lots of the current self-custodial Lightning experiences just with what we have today in bitcoin, in the clArk version, the Covenant-less version.

We're also in a very good position when it comes to covenants because, in theory, any covenant possible would make a difference for us, would make it better for us. So we just want something to happen at some point, and then we will be happy. It's not like we need something very specific.

So we're definitely in the covenant camp, and we're definitely trying to make bitcoin better also on this front, also to enable lots of other things that have nothing to do with Ark. But we're also not too worried or not too time-sensitive because what we're building right now, I think, can be very valuable as well without having the covenants yet.

If this wasn't possible, 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 experience—we don't want to be waiting on the bitcoin protocol to upgrade before we can deliver that.

Stephan: I see. I don't consider myself a technical protocol expert or anything, but from your perspective—you're someone who's really deeply into this—can you explain your thoughts on it? It seems like developers are excited about CTV and CheckSigFromStack. Can you explain a little bit of your perspective on this? Why is this a useful path forward from your perspective, and what do you see being enabled by CTV and CheckSigFromStack?

What is the potential of CTV and CHECKSIGFROMSTACK?

Steven: The people that are following—there's been some noise or some movement around the CTV plus CheckSigFromStack package as a potential software upgrade. It mostly started from some Twitter things going on, and I posted some kind of roadmap that I thought was a good roadmap. Obviously, it was Twitter, so I hadn't thought a whole lot about it. And then people started to be a little bit interested in this.

One of the main points that I found compelling in this is that CTV and CheckSigFromStack are both very simple primitives. They're very technically well specified, and there's not much bikeshedding potential. They're 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. They're both doing a very specific thing.

I think since they're going to be useful into the future anyway, even if we have more complex covenants like CheckContractVerify or TXHASH or stuff like that, or direct introspection, I think having either CTV and CheckSigFromStack are going to be useful anyway. So my point of view was: if we're going to use them in the future anyway, why not already add those while we work out which other things we think are useful?

I mean, any software upgrade that enables covenants in a good way is going to involve multiple moving parts that are a little bit independent from each other. I don't think we need to package everything in one go and say, "Okay, this is everything you need to do the perfect covenants," 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. I just thought CTV and CheckSigFromStack were really good small first building blocks.

Independently, they don't enable everything that we want to enable with full covenants—they don't, they're not magical tools, they're quite simple—but there are still, I think, quite some compelling things that you can do using CTV and CheckSigFromStack. Things like L2 like the Lightning symmetry that people have been talking about for a long time. The Lightning symmetry has gone up and down a little bit among Lightning developers, but I think it's still something that many Lightning developers are very excited about.

All the things I mentioned with Ark you can do, and then there are some smaller optimizations or changes that can be made to things like DLCs, to things like even very primitive vaults or stuff like that.

There's a lot of discussion of "Can we really say CTV can do vaults? 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 move the needle a little bit forward and then see what else we need to make the full vaults, the full coin pools, the full like BitVM-like offchain proving protocols.

I think we're a bit far from having the full covenant package figured out, and I think we have iterated and thought enough about CTV and CheckSigFromStack specifically that we can enable them. We see some value in them, and we can keep them even when we move beyond, even if we move into more elaborate constructions like the full covenants. But it's definitely a difficult topic to talk about.

Stephan: And 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. Do you think the, let's say the naysayer might look at that—I'm not a naysayer myself—but could a naysayer say, "Well, I'm concerned there could be some kind of deep implication. If you create this or you enable this, you're going to enable some other things that they don't want"? I'm curious how you see that or how you think about that.

Steven: Specifically, these two opcodes are so basic, it's really hard to do any cool stuff, basically. That's where the discussion also halts a little bit, because for some people, it's like, "Oh, we can't do enough. What this enables is not enough to convince us that we should do a soft fork." Because a soft fork is not something you just do every day. So some people are like, "Okay, sure, you can improve Ark and do L2, but is this enough to do a soft fork?"

Stephan: Too small to bother...

Steven: Exactly. On this argument, I don't think it would upset any naysayers or people who are afraid of fully recursive covenants or whatever they are called—these more elaborate constructions that covenants can give, things like market makers, things like coin pools. There's nothing like that that's kind of possible in a real way to build with this.

So that's for me one of the compelling arguments—that we can already innovate, even if it's a little bit, on Ark, on Lightning, stuff like that, without having fully figured out as a community what kind of covenants we're scared about when it comes to mempools 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 how to build 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 surprising ways. Like I said, CTV has been around for something like four years (since 2019, I think, so maybe like five years), and only last year someone came up with Ark. 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 3 or 4 years after CTV existed.

So people still have a lot of room to figure out new cool things, and I think if we enable them, people will move the barrier and how far they can think into possible protocols a bit further. So maybe there's going to be something really cool that CheckSigFromStack and CTV enable that we only find out 2 years after it's been activated, but you never know.

Stephan: And 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 DLC or whatever the different forms 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 people using, let's say, clArk, the covenant-less form of Ark, and then maybe after some time of that, then they think, "Okay yeah, let's—we want CTV and CheckSigFromStack." I mean, who knows, right?

So let's close up. If you have any closing thoughts on bringing it back to bitcoin today, what's possible today with Ark—can you spell out for people what are they missing? What is the big takeaway that you think most bitcoiners do not understand about Ark and what it can do for people?

The importance of Ark in bitcoin's ecosystem

Steven: The biggest one is that it exists. 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 approaches, different stacks like the Breez stack that is now based on Liquid or something like that, or the Greenlight stack that also has a different approach. They've tried several of them, and they were not very satisfied because there's always a little bit of hurdles that they don't want their users to need to take on.

With Ark, the user experience is just slightly better than all that, even without covenants or even without whatever. Today on bitcoin, we can have an experience 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 the tutorial and the things up if you go to second.tech, and you can just play with it. We have a little store where you can pay some Lightning payments using Ark. We have a faucet where you can get some Ark coins. And the next step will be making this SDK implementable in mobile wallets or mobile platforms.

Stephan: Excellent. 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 would like—we want more people to use "not your keys, not your coins."

So yeah, let's leave it there. Listeners, check it out—links will be in the show notes. And the website again is second.tech. Steven, thanks for joining me today.

Steven: Awesome, yeah. Thank you for having me.