Steven Roose (CEO of Second) rejoins me to explain Bark going live on Bitcoin’s main net.
Timestamps:
(00:00) – Bark mainnet launched on June 9th
(02:01) – Bark and Lightning onboarding
(03:30) – Ark compared to Lightning — replacement or teammate?
(04:15) – User experience with Bark
(05:54) – Developer experience with Bark SDK
(08:04) – Barkd for merchants and services
(08:56) – Dev tooling and VTXO Inspector
(10:40) – What’s the current status of adoption and what’s coming next?
Fees?
(13:25) – Tx type overview
Links:
Stephan Livera links:
- Follow me on X: @stephanlivera
- Subscribe to the podcast
- Subscribe to Substack
Transcript:
Stephan (00:00.492)
Hi everyone, welcome back to Stephan Livera Podcast. Today we’re trying something a little bit different. We’re gonna try a shorter format, faster interviews. We’re gonna call this SLP fast, try to get through things with no fluff. So, right to it. My guest rejoining me today is Steven Roose from Second, which is the they are the creators of Bark. so Stephen, welcome to the show, welcome back, and give us the update. What’s new with Bark? I know you guys just had your mainnet launch on June 9th.
Steven Roose (00:27.768)
Yeah, thank you for having me. we’re very excited to announce that our ARC server is finally publicly available on mainnet.
So it’s been about two years that we’re developing an implementation of the ARC protocol. We call it Bark. It’s a payments SDK using the ARC protocol. We’ve been on Signet for about a year. We have some dev tooling there. And for the last few months, we’ve been running a mainnet server in beta, in beta. And last week we announced this mainnet server to be publicly available. We announced a few integrations. So there’s a few people building wallets on top of the SDK. We have Noah wallet, which is available for iOS.
And Android. It’s built from scratch on RSDK. We also have Christophe from the Bitcoin design community who built RK wallet, which is like an implementation of the design principles that the Bitcoin design team have been creating, also using RSDK. We also announced that Albihub is integrating Bark as one of their new experimental backends for the Albihub wallet. We built our own web wallet that we call Bark.
Bark wallet or Bark Web. We launched this on Umbrell. We’re building also an implementation of this for Start 9. We’re basically packaging the web wallet for these like hosted on your at your home platforms. And we’re also gonna announce a BCP server plugin with like one-click in install configuration to be able to receive lightning payments. So yeah, we’re super excited with all of these integrations. It’s been like a really exciting week for us.
Yeah, excited.
Stephan (02:05.132)
So how does Bark solve Lightning’s onboarding and liquidity problems?
Steven Roose (02:10.101)
Yeah, so the main reason for building this SDK was that we noticed that Lightning, while it’s really good for routing payments, it’s not so good for user experience at the edges. So if you want to have a self-custodial Lightning experience, if you want to run your own like have your own keys, sign your own Bitcoin transactions, it’s it comes with some like
UX hurdles mostly around on-chain transactions to maintain your channels and liquidity. So you need to manage your inbound liquidity if you want to be able to receive, you need to purchase liquidity, which comes with costs. So the ARC protocol makes it possible for users at the edge of the Lightning Network to be able to route Lightning payments without having these like technological burdens, like channels. So ARC is like a currently mostly like a
What we call last mile solution, where users connect to an ARC server, the ARC server functions as their gateway, but the client server ARC protocol is totally trustless. So the user can have full self-custody, they sign all their transactions, they always have an emergency exit available that they can use, whether the server goes offline or becomes malicious. So the user is always in full control of their funds. but you can route lightning payments very easily.
Stephan (03:28.726)
How should Bitcoiners think about ARC compared to Lightning? Is it a replacement or is it a teammate of sorts?
Steven Roose (03:35.34)
Yeah, so like I said, it’s it’s definitely a like complement. So it’s like a last mile solution.
especially initially, maybe in the in the in the future, also routing channels could exist on the ARC if like on-chain fees would go really high. Currently, that’s not really an interesting path. So, we’re mostly focusing on end users who want to have self-custodial lightning, receive send, but don’t want to maintain channels, don’t want to have the on-chain cost of like creating channels, managing their inbound liquidity. So it’s basically a companion for the for the last mile for the users, which can be merchants, which can be like regular users.
Yeah.
Stephan (04:15.404)
So can you give us a quick overview on the user experience? What does it look like for the end user?
Steven Roose (04:20.789)
Yeah, so the end user, like we’re building an SDK, right? So our users are developers, and these developers hopefully will create like amazing wallets for end users. And for an end user,
The experience is is pretty seamless. So you don’t have any setup. You just create a wallet, you write down your twelve words, or whatever your wallet can store those the the the words in like your your phone device or or on your cloud, something like that. So wallets can can choose there, but you basically have your your seed, your your seed phrase, and then you get a a a balance that you can use to both send on-chain payments, lightning payments, receive lightning payments.
And you don’t see like imbound capacity errors, you don’t see channel closures, you don’t see like even the work channel at all. So it’s it’s a pretty it’s an experience pretty close to like the on-chain experience, only that you can do lightning and your payments can be instantaneous and really cheap. the the cost of arc payments are kind of just paying the operator, the the the server to maintain the arc itself, which is almost kind of a fixed cost. So like
The ARG server makes on-chain payments to basically anchor all the users’ funds into the blockchain. And the more users are in the ARG, the lower the cost per user will be for these to exist. Currently, our server is kind of subsidizing this cost while we’re like growing adoption. But eventually like it’ll it will probably just be divided by all the users, and it should be a really, really small cost to have your balance in the ARG.
Stephan (05:54.135)
What is the developer experience like with BARC SDK and what languages does it support?
Steven Roose (06:00.811)
Yeah, so we have three
Big pillars. Obviously, our SDK is written in Rust, so Rust is always gonna get the best developer experience. all our APIs are natively Rust. And then we have what we call Bark D, which is basically a standalone program that runs all the background tasks and maintenance that you need to do, and it gives you a nice HTTP REST interface that you can then just from any system call into to make payments, check your balance, but it will do all the heavy lifting in the background. And then we have language bindings, which are libraries in different
programming languages that also like call into the Rust code and run the background processes in in the in the in the backgrounds. We currently support TypeScript both for the React native and for web. We support Swift, we support Kotlin, we support Dart for Flutter, we even support Python and Go. Basically any of the languages that the Uni FFI framework provides. We did a bit of custom tweaking for each of the languages to make sure that all the like background async working works works nicely. But other other
than that you get like the full API experience in all of those languages.
Stephan (07:08.032)
I see. And so just making sure I’ve got my understanding correct, there’s I guess different parts to this puzzle because you could be using Bark S D K to build an app. And then on the another old o option would be, as we mentioned, Bark D, which is like Bark Daemon, right? You are running this for your online service. And then on your side you’re running the ARC server, which I believe is Captain D, but that’s more like your server that’s managing the refreshing
Steven Roose (07:32.834)
Yes, yes.
Stephan (07:33.278)
And these components. So is that correct, those three kind of pieces to this puzzle? Okay.
Steven Roose (07:38.466)
Yeah, so so we run the ARC server, which which we call Captain D. users who want to integrate don’t have to worry about that at all. They just need to know our endpoints. Obviously, the server is also open source, so anyone can run their own server if they if they’re interested in doing that. and yeah, so you have Bark D, which is kind of like a mini server that can connect to our actual Arc ARC server. This this is definitely useful for systems that are always online. For example, for the BCP server plugin, we use this for the AMR app.
Stephan (08:02.432)
Yeah. So so let’s talk a little bit about Bark D. Can you explain on BARC D for merchants and online services? Explain a little bit about that. What does that look like? How is it helping them to accept ARC payments?
Steven Roose (08:14.795)
Yeah, so it’s a small
Daemon program that has an easy API that you can just ask balance for, you can ask your history of all your payments, you can create invoices, send payments, and the program will be running in the background. So it will make sure that whenever your VTXOs need to be refreshed, because in ARC, VTXOs need to be periodically refreshed, it will do all of that in the background automatically. So you don’t have to do any like special calls for that. And for systems that are always online, this is best definitely the best solution. Some stuff like merchants, BCP servers, umbrellas, systems.
Like that, they can just run the park D, it will do everything for you. And whenever you need to know something, you can just ask it: what’s my balance? What are my transactions? stuff like that.
Stephan (08:56.446)
And I notice you have put out some new dev tools, one of which is the VTXO Inspector. So what is the VTO VTXO inspector?
Steven Roose (09:04.766)
yeah, it’s kinda like a web page where you can visualize some of the internals of the VTXOs.
There’s definitely, if you the deeper you dig into the protocol, the more technical new things come up. we try to hide most of that in our SDK. So if you want to use it, you don’t need to know those things. But some users might be interested in that. Some developers might want to understand how they’re how they want to expose these things. So we created a visualizer for VTXOs, which show you, like, for example, your unilateral exit path or your emergency exit path. It shows all the transactions you’ll have to broadcast. It can show you, for example, how much total virtual bytes or transaction weights.
you have for your VTXO, stuff like that. we also still
Stephan (09:44.227)
Gotcha. And just so I’ve got my understanding correct and for listeners also, the idea is when you o you you can kind of receive these VTXOs, but they’re not on chain until you actually need to hit the chain. I guess that’s the point, right? This is off-chain scaling. So the user can off can onboard into an ARC wallet without actually going on-chain. He has a VTXO. That’s the point what we’re talking about here, right?
Steven Roose (10:04.863)
Exactly, exactly. Yeah, so the whole point is that as long as the ARC server is cooperating with its users, no one has to broadcast Bitcoin transactions except for the server doing it once per hour. So one transaction per hour can basically anchor all the ARC funds into the blockchain. And only when the use when the server disappears or
Is acting in a bad way, the users broadcast the transactions that they have in their local databases to get their funds back on chain. Similar to how when you have a lightning channel, you also have like all your HTLCs that are going on in your Lightning channel and your commitment transactions that you broadcast in the case of your channel peer going offline.
Stephan (10:41.014)
Gotcha. any I mean you mentioned a little bit earlier about some wallets. What’s the current status of adoption and what’s coming next there?
Steven Roose (10:49.291)
Yeah, so we went live last week. some of the integrations that we announced, we’ve been working with for over a year. So these people were also very excited to to go live with us, especially Noah and RK. so yeah, we’re gonna see
Stephan (11:04.29)
Yeah, and R-R K just for listeners, that’s A-R-K-E, yeah? Yeah, just for if you’re listening, you won’t you might not see that. Yeah, go on. Yeah.
Steven Roose (11:07.829)
Yeah, RK with the French accent. Yeah. so yeah, we’re definitely getting very positive feedback from the first week. and we’re gonna see how it will go. we’re gonna launch our BCP server plugin very soon. So we also hope that this can like drive people to more easily onboard merchants into lightning payments.
Yeah, going next, we have a bunch more people interested in integrating. The launch definitely triggered people to take us seriously and and and think about if they can integrate Lightning using Bark. So yeah, we’re super excited that we have a pipeline full of integrations and we’re gonna be announcing them as as as we finish.
Stephan (11:48.888)
Great. And can you explain a little bit on the fees in ARC? As I understand it’s maybe a little bit closer to like a liquidity leasing model. and but the incr important difference is it’s not like in Lightning where it’s per channel, it’s maybe done kind of more at the as a cohort. Can you explain a bit of that?
Steven Roose (12:09.483)
Yeah, so the ARC server sets the the fee policy. The the cost for the ARC server to write your payment is kind of in a non-trivial way, dependent on how old your VTXOs are and all that. So we try to simplify that a bit. So we basically have for each of the outgoing payment types, we have three tiers. So if your VTXO is less than seven days towards expiry, you be you pay point two percent.
If it’s between 14 and 7 days you pay 0.4% and then over 14 days you pay 0.5%. We expect that a user that has several VTXOs, just like a Bitcoin wallet, has several UTXOs because you like at regular intervals receive some. Most users will be able to make some payments in the
In the cheapest category because the wallet automatically picks the cheapest VTXOs to use. So it will always try to get the soonest expiring VTXOs first to get the lowest fee category. But yeah, you can find it all on our on our website. It’s very clearly explained. We have the offboard, we have the like on-chain payment fee, lightning send fee, refresh fee, lightning receives are free, and ARC payments are also free. So if you transact within the ARC, you can get totally free transactions. Receiving lightning is also free.
Stephan (13:21.963)
Yeah, and just to be clear, this is best for payments and hot wallets. This is not like a long-term cold storage thing, right? and a quick overview of the transaction type. So we can take them one at a time. There’s boarding, refresh, and out-of-round transaction. So what is a boarding transaction?
Steven Roose (13:36.514)
Yeah, so boarding is what you use to and to enter into the arc with your existing on-chain funds. So with RSDK, we we generalized, we u abstracted the on-chain wallet. So you can people that already have an on-chain wallet implemented can you basically use this on-chain wallet? Or we support PSBT where you can just
Ask your hardware signing device to onboard some of your funds. So with boarding, we mean getting you some of your on-chain funds into the ARC. And then we have offboarding, which is the other way around, which is basically sending your funds from into the ARC to an on to an on-chain address. you can do this just to send, or you can say offboard all, basically get all my money out of the ARC. that’s one of the one of the types that you have available. And then the R core transactions are out of round, which we now
Stephan (14:17.731)
So that’s the out of round transaction.
Steven Roose (14:18.977)
Protocol like arc transactions or basically the transactions that happen inside the arc so that you don’t need the lightning gateway. Yes, yes.
Stephan (14:23.255)
Gotcha. And this is like an off chain transaction, right? Like I’m sending to you, it doesn’t actually hit the chain. That’s the point.
Steven Roose (14:28.183)
Exactly. It doesn’t hit the chain and you don’t need to use the lightning gateway. So there’s no lightning fee there. So it’s totally free.
Stephan (14:34.659)
Gotcha. And then the refresh, that’s just like this monthly thing or what’s that? you said every hour. Sorry, explain that for me.
Steven Roose (14:39.629)
Yeah.
every hour every user has a chance to refresh their VTXOs, they have to do it only once a month, right? So every month, ev every VTXO expires after a month.
Stephan (14:49.819)
I gotcha. So you’re do so I guess on your side the ARC server is is doing it like once an hour. But let’s say if I’m the end user, I just need to make sure my wallet comes online to do that refresh once a month. Is that right? Yeah. Gotcha.
Steven Roose (14:59.721)
Exactly, exactly. So if you come online about once a month, depending on how many VTXLs you have, but if you come online about once a month you just send the server like, Hey, I want to refresh my VTXOs and the next hour the server will do it for you and and tell you like hey, here is the the new VTXO that you get.
Stephan (15:14.731)
Excellent. Alright, now a very quick summary that I’ve put together just for listeners to take away. So this is self-custodial with keys on the device. You control your funds, you can unilaterally exit. There’s no channel management and very quick onboarding. The VTXO expires every 30 days, so users have to refresh. Otherwise, the ARC server can claim the funds. The refresh is very simple. Bark SDK provides the tools, but wallet builders just sign up for a refresh regularly. There’s a very low on-chain footprint. As you mentioned, one on-chain transaction can support thousands of users. the ARC server provides the liquid
Liquidity, but it’s and it’s leased to users by the server on demand for payments and refreshes. As as we mentioned, there are multiple language SDKs, easy to build wallets, and Bark D is a good one for merchants to consider. And this is designed for active use, best for payments and hot wallets, not long-term cold storage. so yeah, Stephen, thank you for joining today. So, listeners, my guest is Stephen Roos from Second. You can find them over at second.tech. Steven, thanks for joining.
Steven Roose (16:09.656)
Thanks a lot.