Spark & Ark: The Next Generation of Layer Two

Everyone happy to be here and discuss the future of Bitcoin. Are you enjoying the conference so far?

​

Great. The topic of this panel today is Bitcoin Layer 2. For many years, Lightning was the only way to scale Bitcoin, so all the Layer 2 discussions were around Lightning, Lightning trade-offs, payment channels, and so on. In the last couple of years, there have been significant improvements in different technologies aimed at scaling Bitcoin. That is the context of this panel. We will talk about Spark and Ark. But before we do that, I want to give everyone an opportunity to introduce themselves.

​

I am Ben Carman. I am a developer at Spiral. For Spark and Ark stuff, at Spiral we have a project called Orange SDK that uses Spark to start out, and once you have enough balance we move you to a real channel. Otherwise, I am excited about Ark as well.

​

You already have a history in Layer 2. You started with Lightning.

​

Yeah, I worked on Lightning for three or four years. Beforehand I did DLCs, and I did some covenant research at Taproot Wizards, but nothing that came to light.

​

My name is Matthew, and I work at Second. We are working on our implementation of the Ark protocol, where we offer users self custody and trustless payments in a way that Spark would not ever be able to do.

​

He is shooting his shot early.

​

There you go. I am Seth For Privacy. I am chief operating officer at Cake Wallet. We deployed self-custodial Lightning about two months ago, using Spark, to over a million people. Super smooth. I have been researching, following, and writing about Spark and Ark since they were first announced, and I am really excited to talk through both today in a way that Ark would never be able to do.

​

Hi everyone, I am Ethan. I am building a company called Flashnet. We build Bitcoin-native markets, and we helped build Spark as a means to fulfill our vision.

​

And I am Roy Sheinfeld. I am the CEO of Breez, and we have been doing Bitcoin Layer 2 for many years now. It is actually the eighth year that I am running Breez. We started with Lightning, different variations of Lightning, and so forth. In the last couple of years, we have really focused on the new last-mile solutions.

​

Matthew, you said that you do not like Spark. But before we get into Spark versus Ark, let us talk about Bitcoin. Why do we need to scale Bitcoin? Why not use Solana?

​

It is a great question. I feel like I am the least Bitcoiner of the group here. I think I am a pragmatic Bitcoiner. The TLDR is that we need to be able to provide users the service they want to buy, and today the Bitcoin services we can offer are not great. Bitcoin on L1 is slow and expensive, though it is not that expensive anymore. Lightning came with a bunch of trust trade-offs, which manifested into compliance and regulatory trade-offs. I think Spark and Ark fulfill a vision of fast, cheap, self-custody Bitcoin that has been missing in the market for a really long time.

​

Is it missing in the market? I am serious about why not use Solana. Why do we need to scale Bitcoin?

​

How many users does Cake have that hold self custody of Bitcoin?

​

Well over a million. But we do not know anything about what they do with it.

​

The beauty of Bitcoin has always been that it is not just the do-everything chain. It is very focused on maintaining decentralization, trying to give you the ability to make really pragmatic trust trade-offs, and have self-sovereignty with your money. Obviously, we could go to Solana. We can scale that way, with parallel scaling by going to another chain and spreading people across different chains. But the critical thing with Bitcoin is coming back to how we find that middle ground of being very pragmatic about what people want, while also doing it in the most trust-minimized, most self-custodial way that we can.

​

You mentioned Lightning, Ethan, and you said there are regulatory trade-offs with Lightning. What did you mean?

​

Most Lightning solutions today are custodial.

​

If you want to host, it is actually the user experience issues of Lightning. You dealt with a lot of user experience issues when you worked on Mutiny. Can you elaborate on the challenges in terms of user interface when it came to providing self-custodial Lightning to end users?

​

Lightning is fantastic. It was a huge UX improvement on normal Bitcoin. You do not have to wait for confirmations, payments are instant now, and they are much cheaper. The problem is that it requires a lot of setup. You have to create a channel, which normally means telling the user, okay, you want to use my app? Start out with at least $100. It is so hard to compete with the normal traditional world, where Cash App pays you to join the app, while now we are saying, you pay us to join an app. It is terrible to do that.

​

From a technical standpoint, I call it the inbound liquidity problem.

​

Yes. You have liquidity issues. Also, Lightning is a complicated protocol. It has onion routing to try to be very private, but running that on a mobile phone can get taxing. You have to keep your channel graph up to date and everything. There are different solutions like trampoline, or in LDK we have gossip syncing, but they are not perfect. It is still a hard problem.

​

That is even a minor UX issue. The biggest challenge is offline receive.

​

Yes, offline receive is basically impossible. Phoenix does something, but it is a hack where you get a push notification and it turns on the phone, but that is not totally reliable. Apple hates us, so it does not always work.

​

We also started with running a full node on a mobile device. Definitely, 100%, the inbound liquidity issue was a challenge. Even with an LSP and other artifacts that we built, it is very challenging to overcome channel management, offline receive, and keeping the graph in sync. Those are challenges that were very hard to overcome. But on top of that, the main reason that Lightning is not the best tool to be used as a last-mile solution is an economic problem. The need to lock liquidity for millions and tens of millions of users does not really scale. From an economic standpoint, Lightning does not really scale as a last-mile solution. Would you agree with that, Matthew?

​

I would agree with that, and I think that is the core value proposition of using Ark. Users are able to use Ark as a Lightning gateway, and then when the next round comes, they are able to anchor all that Lightning they have spent and received into a round transaction, into a timeout tree. This is not present on Spark as well. You can never secure and anchor your money back into the L1 intermittently in the same way.

​

We will get to the technical definition.

​

That is not true.

​

I would love to hear more about that. But we are not doing lawyer-driven development. We are doing what is best for the user so they can keep self custody of their funds, receive Lightning, anchor into the chain, and keep on.

​

There is something very interesting there. It has always been this very Bitcoiner problem, where people building in Bitcoin and deeply involved in the Bitcoin ecosystem want to build things that are the most self-sovereign and the most trustless possible. There is a place for that, and that is absolutely fantastic. But there has always been this view that the trust model is either perfectly trustless Bitcoin on-chain transactions or Solana, and that there is nothing in between, and that anything in between is necessarily Solana. That is almost always the framing that is presented when we talk about that, or even more CBDC.

​

If you are using Lightning, and if you are using self-custodial Lightning, which hopefully you are, you are also not using a trustless solution. If you are using Phoenix, you are trusting Phoenix, especially when you open the channel, to not steal funds before the channel confirms. You are trusting Phoenix not to force close with a bad channel state when you do not open your app for a long period of time. There are always trust trade-offs with everything except on-chain Bitcoin where you are using your own node. Anything beyond that, you do have trust trade-offs. It is a sliding scale. I think we have to be very pragmatic when we build these solutions and talk about them. Where do we find the best middle ground, where maybe we call something trust-minimized, but it is much more useful for real people, and we can actually provide much more freedom that way than if we go with something that is a little more trust-minimized but much harder to use?

​

Let us define trust, because I think that is a very complicated topic. There are three pillars when we talk about trust. We talk about custody: can this solution steal my funds? We talk about control, or censorship resistance: can the solution block me from doing something? And we talk about privacy. You mentioned Phoenix. From a privacy standpoint, Phoenix uses trampoline payments, and they know the destination of the payment. When we talk about a trust-minimized solution, it is a combination of these three pillars. Is there something I am missing?

​

One thing that is critically important when it comes to trust on Bitcoin Layer 2s is that you are able to perform a unilateral exit, that you are able to bring your money back on chain without the permission of the counterparty. This is something Ark can do. I have seen Spark make the claim that they can do it, but I have never seen that claim substantiated.

​

I think you are completely misunderstanding Spark and you do not know what you are talking about. But put that aside. Let us give the audience a chance to understand what we are talking about. Let us do an ELI5 explanation of Ark and Spark. Who wants to do the Spark side?

​

I can jump into Spark. Spark essentially is a statechain system. It is a system where you move transactions off chain and actually transfer UTXOs, or leaves specifically in Spark, between users off chain without having to move funds on chain to make that transfer possible. It does this by having a Spark entity, which is the entity that sets up everything, and then separate Spark operators.

​

To move funds within Spark, you and all Spark operators sign the transaction together, and you move ownership of the funds to the new person that you are paying. It is really that simple. To make Lightning payments within Spark, you do an atomic swap with a Lightning service provider. Again, you sign over a Spark leaf, you give it to a Lightning service provider, and they make the payment on your behalf, or vice versa.

​

It feels much like using on-chain Bitcoin. It is not as trust-minimized as using on-chain Bitcoin. The one major trust assumption that I will be very transparent about is that if all Spark operators, which include multiple operators and the main Spark entity right now, and a previous sender collude and work together, they can publish a previous transaction state and double spend funds. That being said, if any Spark operator is honest, or if the previous senders are honest, no one has the ability to steal funds at all. At any time, you can unilaterally exit back onto Bitcoin without the permission of any Spark operator or Spark entity. That is the TLDR.

​

I agree with your description of Spark. I think that is accurate. But I would point out that for the Spark operators, you mentioned there are multiple. I believe there are only two.

​

There are three.

​

Okay. Well, two or three of them are operated by a father and son team.

​

That is why the third is very important, because if anyone is honest, there is no ability to steal funds.

​

Just to clarify, there are three operators right now. One is Lightspark itself. The second is Flashnet, which Ethan is running. Where is the Holy Spirit? Who is the third one?

​

That would be you.

​

How convenient.

​

Can you explain Ark to the audience?

​

I think Ark and Spark have some things in common. For example, we both use a tree, and we are both using leaves. But the critical difference is that in Ark we do not have just one tree. There are many timeout trees. As you hold your money in Ark over time, you are participating in continuous rounds. Every time the next round comes, your money is anchored onto the Layer 1 Bitcoin, and your trust is completely refreshed.

​

That depends on the Ark implementation, correct?

​

Does it?

​

Yes.

​

How?

​

If there is even a round.

​

The timing of when to do a round is defined by the Ark operator, yes. But by definition, another round must occur. Otherwise it would not be an Ark. The definition of Ark is that the vTXO has a limited lifespan, and then it will come back, forfeit the vTXO, receive a refreshed one, and the trust will be reset. The user has absolute ownership that cannot be pried away from them.

​

The two caveats I will mention, and the two trust assumptions that were not mentioned there, are often overlooked or misunderstood. I say this as someone who loves both Ark and Spark and has researched and looked at both of them for years. Both are very interesting. I love that both are competing and building open protocols that can make Bitcoin better.

​

The first caveat with Ark is expiry. Essentially, if you, or someone you delegate the ability to join a round to, do not come online in time, the money that you have expires and the Ark operator can unilaterally sweep those funds. Whether they do that is up to them. Obviously, they have an obligation not to do that, or no one would trust them with funds, but they have the ability to move funds if you do not come online.

​

The solution is that you can trust someone else to do that refresh for you, or you can come online yourself. Mobile users generally are not going to come online themselves, so you are going to be trusting a delegate, someone like your wallet provider, to hopefully do that refresh for you. They cannot steal funds if they do the refresh for you; your funds are safe. But if they do not do the refresh, your funds could be stolen.

​

Correct me if I am wrong. If you delegate the signing to a third party, let us say Cake Wallet, you need to be online in the time period of a round in order to provide the delegation, right?

​

It depends specifically. I would also point out that you can delegate to yourself. You do not need to delegate to a third party. If you are a sovereign runner at home, you can run your own.

​

How many Ark users are actually going to be sovereign runners?

​

You can run a Lightning node this way. I think there is a large community of sovereign node runners out there.

​

The goal here is to scale Bitcoin for non-custodial users worldwide. The core issue before Ark and Spark was that Lightning was too much of a pain to run for most people. If the solution to a hard problem is that we have another hard problem for you, it is not really a great solution. It is easier to run a delegate, but you are still talking about what percentage of people in the world are going to self-host anything.

​

I am okay with Spark and Ark. I am trying to reframe the discussion. It is okay to support Ark. It is okay to support Spark. But let us be honest about the trade-offs that each has. Ark has a liveness issue. You can admit that it is more challenging in usability.

​

In the most non-optimistic trust scenario of Ark, where you are delegating this and doing that, you are still at the same place you are with Spark.

​

Yes, and yet it is more complex at the same time. The tricky thing is when you actually boil down into the details of how the user will use this solution, there is not much difference in terms of trust between them. In some situations, Spark can be slightly better because there is no expiry. In some situations, if you are more hardcore, Ark can be better.

​

The more important issue is what solution users can actually use, what will be useful for people, and what will provide freedom. The exciting thing is that both can, but they are competing in different ways. We need to figure out what the most useful case for Ark is, what the most useful case for Spark is, and find the way that people win. The goal is that people win because of the tools we are building, not that we have little fights over the trust trade-off details when they are actually quite similar in the way real users will use them at the end of the day.

​

I do not think these are just little details. Bitcoin Magazine just reported that your company was invested in by the chairman of the Federal Reserve.

​

Not directly.

​

Enough with this virtue signaling. You are trusting an LP in a fund that invested in us. We had no idea until the news broke.

​

Why go that path? Let us talk technical.

​

The reason I go that path is because Bitcoin is ideological, and people use Bitcoin for ideological reasons. If people do not care about the values of Bitcoin, they can use fiat.

​

I disagree with that statement. Maybe you use Bitcoin because of ideology. Most users do not use Bitcoin because of ideology. The vast majority of Bitcoin users do not use Bitcoin for ideological purposes.

​

They need a tool, and Bitcoin is that tool, and they use it.

​

You can get a perfect example of this in the fact that most people around the world who need a tool for freedom right now that is not their fiat currency do not use Bitcoin because they are not ideologically motivated. They use stablecoins. They use other things.

​

They are on Tron.

​

Unfortunately. That is not where we should be, but I think there is a responsibility for us as builders.

​

It is orders of magnitude more. It is not even close. The usage of stablecoins versus Bitcoin as a medium of exchange is much larger, and we all want people to use Bitcoin as a medium of exchange.

​

If that is the case, why do we not just use custodial? That is the best UX by far.

​

Because we cannot. That is a great question. People used Wallet of Satoshi until Wallet of Satoshi was shut down because of regulation. Do you want to run a regulated company?

​

No. But then it is just legal arbitrage here. The entire crypto space is regulatory arbitrage.

​

I hope we develop things that are not lawyer-focused and are more Bitcoin-focused.

​

The ideology is important for us as builders. I think it is our responsibility. We are ideologically motivated. We would not be on this stage if we were not.

​

I am technically motivated to provide the most trustless solution possible.

​

Exactly. But that is an ideology.

​

I think there is utility behind the ideology, and the utility is providing a global currency that is lasting. I do not think there is a better tool to do that other than Bitcoin. That is why I do Bitcoin.

​

Ideology does matter to integrators and wallet providers. I saw a post this morning that BlueWallet is no longer going to be integrating Spark because they are unhappy with the trust assumptions and custody model.

​

They were never going to implement Spark.

​

How many wallets have implemented Ark?

​

We have a handful, and you can go into the open source stage and try it out today on mainnet.

​

What is your take as an outside builder on Ark?

​

My hard take is that the existence of Spark is a failure of the Bitcoin protocol, because we could have Ark where all the solutions are solved if we had covenants. The problem is we do not have that. Spark is the interim solution. We cannot get updates to the Bitcoin protocol to make self custody scalable, so we introduce trust assumptions to solve that, and it works today. It is a good stopgap, but it is really just a failure of the Bitcoin protocol to allow scalable self custody.

​

Which opcode do you want in the Bitcoin protocol?

​

I will take any covenant. CHECKTEMPLATEVERIFY, OP_CHECKSIGFROMSTACK, anything.

​

Which software do you run, Knots or Core?

​

I run Libbitcoin Relay.

​

Let us talk about trade-offs, because there are always trade-offs. Even if we accept the premise that Ark is closer to on-chain, there is a cost associated with that. I like to examine things from a trust standpoint, with control, privacy, and custody, but also from an economic standpoint. Can you share some things about the economics of running an Ark service provider?

​

The Ark server will front liquidity. They will have money that they load up into the Ark server, and then users will come and make transactions.

​

For the audience to understand, you need to front every vTXO with liquidity.

​

Yes. The amount of money being used in the Ark, the amount of money that is in these on-chain round transactions, the Ark server will have to hold on to that amount of money themselves.

​

Is there a cap to how many users can use Ark in this way? How many LPs do you have lining up to put money behind it?

​

You do not need to do it for every payment. At Spiral, one of my coworkers is working on putting Lightning channels in a vTXO. Then you just have to front liquidity for a single channel open, but then you can make infinite payments from there. Then you have Arcade, where they are basically doing Spark upside down, doing Ark with a statechain inside for payments. That is how they are getting around it. You do not have to front every single payment ever. You take other traditional Bitcoin scaling things and put them on top of Ark.

​

But if there are $2 million of user deposits into Ark in one way or another, Ark would have to front $2 million as well. Is that correct?

​

Yes.

​

That seems like a pretty big scaling limitation.

​

There are a lot of Bitcoin treasury companies.

​

They are getting fees for this. It is not a zero-win strategy.

​

Ark service provider, is that the next phase?

​

We will see. We will be running the Second Ark service provider.

​

And that has implications for cost and fees, right?

​

Yes. Users are paying fees to the Ark server in order to route their payments over Lightning, and the Ark service provider makes money from that.

​

Who is running the Lightning component at Second?

​

We have the Ark server, and then we also have Lightning nodes that are connected to the Ark server, which we also run. But anybody is able to spin up the software and run it themselves. We are here at the open source stage. Our software is 100% open source. Anybody can see the full source code and run an Ark server themselves.

​

One thing I want to call out that has not been mentioned yet is that Ark and Spark are interoperable because of Lightning. One of the really beautiful things about this is that both are open protocols. Anyone could run a Spark entity. Technically, anyone could run an Ark service provider. But as a user, if you are a Spark user or an Ark user, you do not even need to know which you are. You can pay each other because of Lightning.

​

That is one of the beautiful things. Lightning as a solution that you actually run channels for was never going to work as the last mile. It was not scalable. Finally, we are pivoting to Lightning as a fantastic interoperability layer, where anyone using any of these solutions can make those payments and have all of the benefits of Lightning without having to worry about which underlying thing they are running. That is a big distinction to keep in mind.

​

I agree. I just disagree on the scaling. Lightning does scale for high-frequency channels. Not for making three payments a month. Again, that is because of the economic model. You need a high-frequency channel to make Lightning work.

​

There are two things we are trying to scale. Lightning scales payments. We are no longer restricted to seven transactions per second, but it does not scale ownership. You still need one UTXO per person, so that is expensive on chain and expensive liquidity-wise. If we try to give every single person that, it is like 300 gigabytes of chain space. It is never going to happen in a reasonable time. Ark and Spark scale that by creating these trees, where instead of one user, one UTXO, you have a million users.

​

From a Lightning standpoint, how do you deal with offline receive?

​

For our Ark, you would come online to receive.

​

So you have the same liveness requirement in your current iteration.

​

Yes, we do.

​

In theory, you could do the same thing for offline receive in Ark that is done in Spark.

​

Is Ark going to the federated model, the one-out-of-N model? Is that something you are planning to do?

​

We have no statement about that.

​

What does that mean?

​

I cannot elaborate on any plans about that. I do not have an answer.

​

I think we need to understand there are two main Ark implementations. One is by Second, and the other is by Ark Labs called Arcade. I like the Arcade approach of doing an offline execution engine. You can run different scripts offline and implement financial solutions that can be implemented on top of on-chain. Is this something you are offering as well?

​

No. We are not planning to do anything like custom scripts or having a VM. Our priority is doing payments: Lightning payments, on-chain payments, Ark payments. That is our core competency. Do one thing and do it well. That is the purpose of our protocol. We are not here to do DeFi. We are not here to integrate stablecoins. That is not our mission.

​

It is important to highlight that the Arcade version of the custom scripts requires trusting the signer on their behalf. It is not that they enable new opcodes for free. The new opcodes work under the same Arcade trust model, because they use statechains and have the trusted signer anyway.

​

One thing I really like about Second is that you have chosen to be laser-focused on payments. The low-hanging fruit and the thing we need to solve first is payments that scale. That is what is preventing a lot of people from using Bitcoin, especially in a self-custodial way. Obviously, we can scale Bitcoin payments by using a database and Wallet of Satoshi, and that is scalable if you want to call that scaling. But the biggest issue is that we need a way to scale the self-custodial side of payments, get that done, and then we can worry about more complex things down the line.

​

Can I challenge that? Can we do that without stablecoins?

​

That depends on the target audience. I think there is an unfortunate necessity to temporarily serve stablecoins. Ideologically, I hope they go away and we have people actually using something that is more decentralized and more trustless. The hard thing with most stablecoins, not all but most, is that even if you have self custody, it does not matter because Tether can just say your USDT does not work anymore. You can have the keys, that is fine, but you cannot actually move them.

​

There is a website that tracks this, and there are hundreds upon hundreds of millions of dollars of Tether that get frozen every year because it is a completely centrally controlled token, even if it is on something else. I want to solve the Bitcoin side, but right now people need and use stablecoins. So we need to serve that as well and give them easy ramps back into Bitcoin, especially as we see the crackdowns and as we see Tether freeze funds. People will start to figure out, okay, I need something that cannot happen to. My neighbor just had all their funds frozen, or a friend in Venezuela got caught up in a Tether freezing situation. We need something that will work no matter what, and then they will shift into Bitcoin.

​

I think there is a lot of responsibility for us to get access to stablecoins in self-custodial wallets as close to Bitcoin as possible, so they can flow into Bitcoin when the rubber meets the road.

​

That is a good segue to you, Ethan. You decided to focus your time and energy on exactly that bridging between Bitcoin and stablecoins.

​

A quick TLDR is that Bitcoin-native markets, our focus today, is very much spot Bitcoin to stablecoins. We do a lot of cross-chain stuff. We power deposits, withdrawals, and native swaps on Spark. For us, the core mission is how we scale Bitcoin for everyone via Spark, but also create this one global pool of liquidity for Bitcoin itself. Bitcoin trades a ridiculous amount every year, more than the entire rest of crypto combined, but it is the only asset that still trades completely on centralized exchanges for the most part. We are trying to change that for retail.

​

The underlying discussion here, which may be a topic for another panel, is how you do stablecoin-to-Bitcoin bridging. Do you do that in a DEX on a client, or do you do that natively in Lightning? That is an interesting thing.

​

We are out of time. Let us do a last round of asking what you are excited about, what you are working on, and what you expect to deliver in the next 12 months.

​

I am hoping we get CTV so we do not have to have these arguments anymore.

​

In the next 12 months?

​

Sure.

​

I am excited to have Second's Ark on mainnet now, running real-world Lightning payments, and I invite Seth to come with me and transact over Lightning together.

​

Let us do it.

​

For me, like I mentioned before, I am really excited that there are now practical solutions to scaling payments and potentially doing other things like stablecoins within Bitcoin. We can have a competition of open protocols, and the user ultimately wins. That is one of the best parts of freedom tech and open source. We as builders have to compete for you, and you always win. Over the next 12 months, now that these technologies are actually out, Spark is deployed to a ton of people and Ark is just getting started. As users use them, we will have great competition that drives better products and better tools that push more toward trust minimization and self custody.

​

I am excited to continue scaling Spark and bringing more people to Bitcoin, getting them transacting every day.

​

I think the future is not a monolithic future. I do not think we are going to centralize on a single stack. I think we will have multiple networks. The thing I am excited about is seeing Lightning act as the common language between these different subnetworks.

​

Thank you so much for your honesty and participation. You should use Ark, Spark, Lightning, whatever you can, in order to use Bitcoin as a medium of exchange.