In this episode, Kevin Hurley, CTO and co-founder of Lightspark, discusses the Layer 2 solution called Spark, which aims to enhance Bitcoin’s scalability and user experience. He shares insights from his journey transitioning from the Libra project to building on Bitcoin, addressing challenges faced with the Lightning Network, and the unique features of Spark, including its architecture, user experience, and future developments. The conversation also touches on trust, privacy, tokenization, and the importance of community engagement in the Spark ecosystem.

Takeaways:

🔸Spark aims to provide a scalable and user-friendly Layer 2 solution for Bitcoin.

🔸The transition from Libra to Bitcoin was driven by the need for a decentralized settlement layer.

🔸Challenges with the Lightning Network include inbound liquidity and complexity for users.

🔸Spark simplifies the user experience by abstracting away complexities of the Lightning Network.

🔸Unilateral exits in Spark allow users to retrieve funds without operator involvement.

🔸The architecture of Spark is designed to support high transaction throughput and scalability.

🔸Privacy features are being developed to enhance user confidentiality in Spark transactions.

🔸Tokenization on Spark allows for the creation and transfer of assets efficiently.

🔸The Spark ecosystem encourages community involvement and developer contributions.

🔸Future developments will focus on programmability and advanced financial functionalities.

Timestamps:

(00:00) – Intro

(01:01) – Kevin’s journey from Libra to Bitcoin

(04:28) – Why the need for another L2?

(07:49) – What is @spark?; How is it beneficial for the end user? 

(12:09) – Spark’s technical framework

(20:40) – Cooperative exits vs. Unilateral exits

(26:17) – Sponsor

(27:10) – Trust & privacy considerations in Spark

(29:16) – Enhancing privacy in transactions

(34:48) – Developer experience & tooling 

(36:37) – What is Spark’s token protocol (BTKN)? 

(39:11) – Stablecoin support on BTKN? 

(41:13) – Kevin’s views on programmability with Spark

(43:35) – How is Spark different from other Layer 2 solutions? 

(46:06) – What are Universal Money Addresses?; UMA for Cross-border transactions

(49:14) – Corporate chains vs. Neutral settlement layers

(52:15) – Can an individual spin up their own Spark operator? 

(53:24) – Could 100 million people be using Spark?

(55:00) – How can one contribute to Spark?

Links: 

• https://x.com/kphur 
• https://x.com/spark 
• https://x.com/umastandard 
• https://www.spark.money/ 
• https://www.lightspark.com/news/lightspark/lightspark-acquires-striga 
• https://www.lightspark.com/news/lightspark/introducing-lightspark-grid 
• https://x.com/lightspark/status/1981360175861944621 
• https://bitcoinmagazine.com/technical/spark-and-ark-a-look-at-our-newest-bitcoin-layer-twos 

Sponsor:

• CoinKite.com (code LIVERA)

Stephan Livera links:

• Follow me on X: @stephanlivera
• Subscribe to the podcast
• Subscribe to Substack

Transcript:

Stephan Livera (00:00)
Hi everyone and welcome back to Stephan Livera podcast. We’re going to be talking about one of the new L2s on the block. It’s called Spark and joining me from the company called Light Spark is Kevin Hurley. He’s the CTO and co-founder. Kevin, welcome to the show today.

Kevin Hurley (00:14)
Thank you, happy to be here.

Stephan Livera (00:16)
So Kevin, I know you have a history where you came from, let’s say Facebook and Meta and the Libra DM world, and then obviously you came to Light Spark along with David Marcus, and you are working on both the Lightning Network and also this new L2 called Spark. So can you maybe give us a little bit, it’d be great if we could start on a little bit of, you know, how you came to ⁓ the Lightning aspect of it, and then into why you got interested in this idea of having a new L2.

called Spark.

Kevin Hurley (00:47)
Absolutely. as you mentioned, a lot of us came from the Libre DM where we were trying to modernize how money moves. We go from these legacy payment trails that take days to settle, don’t work during non-business hours or during bank holidays. They want to move to something that you can move money natively on the internet, just like you move data packets from point A to point B. We were trying to do that with

a new blockchain at Metta that we called Libra or DM, got into some regulatory hurdles where Congress and others in the government didn’t really want us launching a new blockchain. And we kind of came to the realization that to do something at this scale where you have a global settlement asset and a global settlement network, you really needed something that was credibly neutral and truly decentralized.

And if you look at the landscape of what exists today, the only thing that really meets that criteria is Bitcoin. I mean, it has no single leader without sized influence, ⁓ nothing like Vitalik and Ethereum where you could potentially kidnap him or force him to do things that would potentially cause transactions to get rolled back. ⁓ There’s no one like that on Bitcoin. And if you want to build a global settlement layer,

If I’m PayPal, I’m not going to build on Stripe’s network. If I’m Stripe, I’m not going to build on Adyen’s network. You need something that really is neutral and decentralized. And that is where Bitcoin comes in. So we kind of took those learnings that we had from the Libra DM days and decided that we needed to build something that really met those criteria. And that’s where we came to Bitcoin. We looked into Bitcoin and Lightning before when we were at Libra and DM and just didn’t feel like it was quite to the place that we needed it to be.

Then four or five years later, ⁓ after we had tried LibreDM, think things had advanced to a point where we felt like now it was worth trying to build a company on top of that. And when you’re trying to build something on top of Bitcoin that is truly scalable and instant payments, low cost, Lightning was really the only option at the time that made much sense. So we decided to start building on top of Lightning. We built out… ⁓

a system to really try to make lightning much easier and more intuitive to use. If you talk to lot of companies in this space, you find that it’s a pretty common refrain that lightning is just too complex, they are worried about channels closing, getting inbound liquidity, being able to route transactions successfully. So our first step was let’s abstract all that, make it just incredibly simple and intuitive for anyone to be able to integrate to the lightning network.

and have extremely high reliability and success rates. So it’s kind of the first product we built. ⁓ We called it Connect, which was really an abstraction to make it super easy and intuitive to build on the Lightning network. From there, we had good success. We had Coinbase, for example, we power all of their Lightning traffic. ⁓ We have many others, Zappo, others big customers that we power their Lightning traffic. But we just found that there were some key shortcomings in Lightning that

we kind of banged our head on over and over and really got frustrated that we felt like we couldn’t solve well. And then I don’t think really anyone has been able to solve super well. And that’s what led us to wanting to do something new that could solve those problems. ⁓ Some of those key problems were really doing self custody at scale. If you look at lightning today, if you want to onboard a billion users tomorrow, you’re going to have a pretty hard time doing that. Not only with layer one costs and the time to actually fill.

fill enough blocks to actually create enough channels. ⁓ That’s a huge burden. But then even just economically, it’s not super viable. Let’s say I have a billion users. I want to have $100 of inbound liquidity for each of them. You’re already looking at $100 billion just sitting there idly, ⁓ which obviously starts to be pretty problematic when you want to onboard the world to Lightning. But again, Lightning works super well for custodian solutions, but we wanted something that could actually scale out for self-custody. ⁓

And we had some key criteria of things that we thought really mattered to us. And one was what I mentioned there, self-custody at scale. We wanted to do something that was really economically viable, that you weren’t locking up tons of money in liquidity. ⁓ And you could actually kind of share that liquidity, have something that works really well economically. We wanted to have something that was extremely trust-minimized, ⁓ as trust-minimized as we could possibly do.

We want stable coin support because we are starting to see that there is a significant amount of interest in stable coins, ⁓ some real product market fit on stable coins. ⁓ And we didn’t feel that tapered assets and some of those other solutions were going to be the ones that would meet the things that would be required for scaling out to users at scale. And we can dive into that if you’re of interest, but I think that there are…

are things that just weren’t going to be super viable there. We also wanted to be able to dynamically onboard users. didn’t want to, for example, pre-create channels and things like that, like is enlightening. On the instant settlement purpose built for payments, unilateral exit where users can leave at any point. I think that’s a key difference between what we have and a lot of the other L2s out there. We felt like if Spark operators disappeared, if Spark went off the…

off the grid and completely disappeared, users should be able to get their money back to layer one at any point. these are some of the key criteria of things that we felt were really important.

Stephan Livera (06:35)
Yeah, so as you said, it sounds to me like lightning network, though you obviously are still working with that and powering it for other people. Maybe you’re seeing it more like it’s a B2B. It works well in a B2B context and maybe not for the let’s say the end customer consumer retail at scale. I think that’s probably that’s probably one way to put it.

Kevin Hurley (06:55)
Yeah, I mean it works super

well for custodian to custodian. ⁓ If you have large nodes, you can give inbound liquidity to those fairly easily. You can build out a framework of the network where you can make sure that transactions are going to be extremely reliable. But if you wanted to onboard billions of users, it’s just not going to scale well.

Stephan Livera (07:15)
I see. Yeah, and so then let’s talk a little bit about, so as you mentioned, and a lot of the listeners of this show are kind of generally more technical or they’ve been around for a while, so they’re familiar with some of these problems or concepts, right? Like you mentioned, the inbound liquidity aspect of it, there’s a liveness requirement in Lightning, some of these different trade-offs that can make it difficult to do at scale with a nice user experience.

⁓ And so you landed on this idea of Spark, which is a form of state chain. But can you walk us through your thinking how you got to Spark? Because there were other different ideas out there at the time. What was it that led you to this?

Kevin Hurley (07:57)
So we kind of looked at the landscape of solutions and frankly just didn’t feel super comfortable with the trade-offs that a lot of them chose. ⁓ What mattered to us was something that had as minimal trust as possible but as good of a UX as possible. And we wanted something that was really simple to integrate to, really simple to build on to, something you didn’t need to worry about, ⁓ if I don’t come online in X number of days, I’ll lose my funds, or have the possibility of

a federated multi-sig where they fully have control of your funds. We wanted something that we could have strike the right balance between trust minimization and best user experience. I think talking to our partners and the folks that are onboarding to it, they feel like we have struck the right balance there. I think it’s going to be different for everyone. think different people will probably choose different solutions. But I think for us, was trust minimization and easy UX.

Stephan Livera (08:56)
And so ⁓ can you offer us just, I guess, before we get into more the technical aspects of how Spark works, just offer an idea of what it looks like for the end user. from their perspective, what does it look like? And then we can dive into more like actually what are the technicals underlying?

Kevin Hurley (09:15)
So from a user perspective, ⁓ you deposit money into a Bitcoin layer one address and then your funds are available to use on layer one, Spark or Lightning. You get access to Lightning without any of the headaches of Lightning. ⁓ You have offline receive, you don’t need to establish inbound liquidity. But that was something that was really key to us because obviously we care a lot about Lightning, we have a lot of customers on Lightning. We want users on Spark to be natively interoperable with anyone.

and no one on either side have to know whether you’re on Spark or Lightning. So a Coinbase user can send to a user on Spark and vice versa. Just use a Lightning invoice and neither side knows anything about where the other side is located. So from a user, the experience should be you can do instant payments. It’s extremely cheap. mean, right now it’s free to do Spark Spark transfers. ⁓ And you can send between anything that you want to, whether it’s Layer 1, Lightning, or Spark.

Stephan Livera (10:14)
I see, yeah. And so I presume then what you’re saying really aligns with what some other people in the ecosystem have been saying around this idea is like Roy from Breeze where he talks about this idea of lightning is kind of the interoperability layer. And so even though there’s different, you know, layers or platforms or things out there, whether it’s lightning itself, liquid in arc and cashew and sediment and whatever else is out there, or some maybe some ZK roll up thing, at the end of the day, what people are, let’s say scanning and paying.

is the lightning QR because that’s kind of where people are talking to each other in a sense.

Kevin Hurley (10:50)
Yeah, I think it’s kind of interesting because I think Bitcoin has gone maybe the opposite direction that a lot of other chains have gone. There is Lightning Network, which was created and is a fantastic solution for being an interoperability layer. And it kind of was created before all these new solutions were created. If look at some of the other chains, they have all these L2s and now they need to find something that will glue them together well. So it’s a little bit of kind of the opposite direction there.

Where on Bitcoin we have something that can glue these together really well in Lightning. ⁓ And now we’re building out a lot of these layer 2s that can do the things that Lightning maybe doesn’t do super well. But we already have the solution to glue them together and that is kind of what you’re seeing with ARK, Spark, some BitVM solutions and many others that now Lightning is that interoperability layer.

Stephan Livera (11:40)
Okay, so let’s dive a little bit into the actual Spark construction. Maybe talk us through a little bit ⁓ this state chain idea, but it’s sort of like a modified state chain, as I understand. Like I know there was an earlier form of state chain called Mercury layer, but you’ve taken some slightly different decisions. Can you just walk us through at a high level, what is this system?

Kevin Hurley (12:02)
Yeah, so I can give you a sort of technical, but I’ll try to keep it somewhat high level, overview of how state chains work and then what variations we made to it. So when you think of a private key, just think of it as a big random number. So I’m Alice. I have a private key of some big random number of, let’s say, 200. Then there are entities that we call state chain operators. So you have multiple state chain operators.

grouping of them together we just call a state chain entity or SE. And that’s just the three or four or five or whatever state chain operators grouped together as an entity we’ll call the state chain entity. So they all generate their own private keys as well. So let’s take the summation of all the private keys of each SO and say the state chain entity as a whole has a large number of 500. So now we take Alice’s private key, we take the state chain entity’s private key, it sums up to 700.

So Alice can now deposit funds into a UTXO encumbered by a condition that says you can spend it if you have the summation of the private keys of 700 and are able to sign something with that. So now you have funds that are in this state chain. When Alice wants to transfer it to Bob, let’s say his private key is a value of 100. So you still need to be able to spend something using the same

summation of private keys that you had before because that’s what’s encumbering the UTXO. So you take the difference basically between Alice’s and Bob’s private key, which is difference of 100 for 200 to 100, and now you need to tweak the keys of the operators such that they will match the same thing in the summation that they had with Alice. So you tweak those by 100, which means that their summation is now 600.

So you have the 600 plus 100 still sums up to 700. And you’re now able to sign something with the combination of the state chain operators plus the new person Bob. And the job of the operators is really to tweak their keys and forget the old keys. So as long as one of them forgets the old keys, they can no longer sum up to the value that they had with Alice. So they tweak their keys, each tweak it by a little bit different amount such that now

If as long as one of them forgets it, they can’t sum up because they don’t have the keys to sum up to 500 anymore. So if they were to try to collude with Alice, they can’t do anything because they don’t have the keys to sum to the right value. And their job is really to do that and then to sign things. We think of it like a ⁓ one-of-n-trust model because as long as one of them forgets it, it’s OK. ⁓ But it’s actually a little bit better than that because it’s really an ephemeral or point-in-time trust model where

They just need to be honest during that one moment in time where you’re doing the transfer. And by acting honestly, that means that they forget the key. So as long as one of them forgets the key at that moment in time, they get hacked later, they become malicious later, doesn’t matter because they don’t have the key. So there’s nothing they can do. And your attack model would be all of them are malicious and they don’t forget the key and then they later collude with Alice so they can sign something that still sums up to that 700 value.

⁓ But as long as one of them forgets it and acts honestly at the moment in time, you’re good. That doesn’t matter in the future because they don’t have the key material to be able to do that. So you’ll notice like we actually want the ability to sign something so that when Alice deposits money she can can leave. When Bob deposits money he has something signed that he can leave. So what you typically do in a state chain is you sign something with a time lock. So you say okay Alice deposits this money before she deposits it will

Collaboratively sign something that says she can have her money back after let’s say a thousand bucks When she transfers to Bob you sign something similar, but with a smaller time lock So let’s say we say Bob can now leave after 900 blocks and we sign this transaction that gives the funds to Bob the problem here with typical state chains is what you’re doing is you’re transferring a whole UTXO and you have an absolute time bomb here because you keep decrementing this down and

It’s relative to the deposit transaction. So Bob would have had to leave within 900 blocks or else he runs the risk of Alice being able to leave before he can. ⁓ So those are some of the key problems of state chains that we didn’t like and that we wanted to solve. So what we do is we actually break it down into a tree. So you deposit it, we break it down into a tree of different transactions that are all under this root transaction.

⁓ And because of that you can break it down into any amount that you want to so you can transfer small denominations large denominations You don’t have to transfer whole UTXOs Also we do some some interesting things that you can re-aggregate those back up so you don’t have to have Exiting with 20 transactions you can exit with one transaction because you can re-aggregate those those ⁓ leaves into kind of linearly aggregatable transactions ⁓ at the top node

We also remove the absolute time bombs because ⁓ you’re able to, the relative time bombs because you’re actually able to have this tree structure where it’s not relative to the root transaction, but it’s actually relative to the very end of the tree at the base of the tree and the leaves. ⁓ So because that, you can effectively have the leaves live forever and you can break it into any amount that you want to. So we kind of took some of the core limitations of typical state chains and kind of got rid of them.

made it so that you have any denomination you can transfer for free forever. You can keep transferring over and over and make it so that it’s much more user friendly.

Stephan Livera (18:02)
Okay, so let me just make sure I’ve understood you. So the idea is in the spark context, let’s say you generate or let’s say I generate a spark address and you can send some UTXO to me. And then what I’ve got is and you let’s say you signed with the spark ⁓ operator to sign and send that to me. And then what I’ve got for my ability to unilateral exit is this ⁓ leaf in the tree.

which is a valid Bitcoin transaction on chain if it were broadcast, but obviously we keep it off chain because the whole point is we wanna stay off chain for the scaling benefit. And then I guess the other, as you mentioned, there’s this concept where in the kind of in some of the other state chain models, it was like set bill sizes, right? It was like 1BTC or 0.1BTC or this kind of thing. Whereas in this Spark model, as understand it can split down and go into pieces.

Have I got you right there so far?

Kevin Hurley (19:02)
Yep, exactly. And one key thing that you mentioned there, I think that we should highlight is the unilateral exit portion because that was something that was really important to us. ⁓ These are all pre-signed transactions that are valid layer one transactions. You could publish at any point. You effectively publish the branch that you’re going down to your leaf. And that means that without involvement from anyone else, you’re able to exit to layer one. So if all the Spark operators disappeared or they decided to

I’m not going to sign with you because I don’t like you anymore. You can still exit to layer one and have your funds yourself. ⁓ And that was something that we didn’t want the ability to censor people. Like we don’t want someone to be able to come to us and say, ⁓ Stephen shouldn’t be able to have his funds anymore. We don’t want you to let him exit. And that’s a big difference between us and a lot of things like federated side chains, for example, where

you actually kind of have to have permission to exit because they have the full keys, they have the ability to sign whether you can exit or not. With this, you have the pre-signed transactions and you can exit yourself at any point.

Stephan Livera (20:10)
I and so then I guess on the downside of that some of the trade-offs here is because there’s this tree structure one thing that I’ve heard or You correct me if I’m wrong here but is it that there’s there is potentially a larger exit cost because you might be having to ⁓ Put more things on chain in order to actually make your exit. Is that is that correct?

Kevin Hurley (20:32)
It is to a degree. ⁓ For unilateral exits, that is true. ⁓ Which is why we have a couple ways of exiting. So you can exit unilaterally, which is kind of, I would think of it as kind of like a worst case solution. If you can’t exit otherwise, you can unilaterally exit. But in a typical case, you’re going to do what we call a cooperative exit, which is effectively doing an atomic swap with an SSP. So an SSP is a Spark Service Provider. Their job is to facilitate efficient transfers.

So typically like on off ramp types of things.

Stephan Livera (21:04)
And as I understand, this is like loosely analogous to an LSP in Lightning.

Kevin Hurley (21:08)
Loosely, yeah. So in the exit flow, we have what we call cooperative exits. So you’ll do an atomic swap of your leaves for a layer one transaction from the SSP. So let’s say I want to exit 5BTC. I will swap my leaves to the SSP and they will send ⁓ a layer one transaction to me of the amount that I swapped. It’s an atomic swap, so it’s not like you ever lose control of your funds, either both

The L1 transaction and the leaf swap succeed or they both fail. ⁓ But it means that you use just a single layer one transaction and you can swap whatever denomination you want to. So that’s like the typical case that you would do because it’s much cheaper, much more efficient. You don’t have to wait any time for it to happen because you just send it to them and it’s an immediate transaction on layer one as soon as the next block happens. That’s your typical exit case. ⁓

If you were to do a unilateral exit, you do have to publish the branch, which will be less efficient, but it gives you kind of an escape patch such that you can leave at any point without involvement with anyone else.

Stephan Livera (22:14)
Okay, so just walking it through again, so let’s say I’m the end user. I’m just the retail I’m the guy with you know a wallet on my phone the idea is I can send and receive inside of spark and If I need to make a lightning payment I you know I scan a lightning QR and I make a payment just like I would with a lightning wallet and then actually in the background what’s going on is the SSP is the one sort of making that lightning or helping facilitate me making that lightning payment by me swapping some of my spark

I guess coins for you know for the SSP to make that lightning payment out and then as you said There’s a cooperative closed process and then the unilateral process and so the unilateral exit is the more expensive one But obviously that’s more like the last resort and in the general case we’re gonna we’re gonna be operating in the cooperative ⁓ context ⁓ and then just in terms of understanding the other actors in this ecosystem, so we’ve spoken about this concept of okay, you’ve got the So is it the spark entity is the broader?

idea or broader, I guess, amalgamation of these concepts and then the Spark operators are inside of that. You say, and I understand there’s two there.

Kevin Hurley (23:23)
So the Spark operators, that’s what we talked about with where their job is to tweak keys, sign things, and forget keys. ⁓ Spark entity is really just a virtual concept of the grouping of all the operators. ⁓ It’s not like an actual entity. It is just the virtual grouping, kind of like you can imagine like a mental grouping of, okay, we have all these operators. This is just the name that we call the grouping of them. ⁓ Then you have the SSP whose job is to facilitate

⁓ more efficient transactions and kind of act as the edge point between Lightning and ⁓ Spark. ⁓ And then to your question of like how many operators there are, currently there are two operators. We are about to announce ⁓ a third one that will be added ⁓ and we expect that there will be many, many more in the future. We kind of want to get things to, we’re iterating really quickly right now. We want to get things really stable and make it so that we can do

upgrades really easily. ⁓ So we’re being a little bit slow with adding new operators, but we’re going to be adding a third one very soon here. ⁓ And then we’ll hopefully be adding many more in the near future.

Stephan Livera (24:35)
I see. And so then when those extra Spark operators get added to, as I said, this virtual concept of the Spark entity, ⁓ does that introduce like more latency or like, you do you need everyone to sign or is it only one of them who has to sign? ⁓ Because as I recall, you said it’s a one of N honesty, trust model, right?

Kevin Hurley (24:57)
Yeah, so there’s trade-offs you can make. So it’s built such that it can support a threshold that obviously changes the trust assumption a little bit because when you have a threshold, that means that there are more honest actors than one. But it makes it so that liveliness is a little bit better. Typically, a user could select how many operators they want to use for a transaction and kind of select where they want to be on that trust versus ⁓

versus latency equation. So when it’s still small and there’s not very many operators, you typically would do all n of them. As the network expands to more, let’s say there’s 30 operators, maybe you might do 27 out of 30 or 25 out of 30. And that changes kind of the liveliness versus trust assumptions.

Stephan Livera (25:49)
Okay. ⁓ And so the other, one of the, like, obviously there’s been a lot of, you know, criticisms and ideas flowing back and forth. One of the things I’ve seen people say online about this is it’s quote unquote, trustodial, right? And I think now to be fair, you know, you’ve got to understand the good and the bad is how, what kind of balance should people be keeping in this kind of, in a spark wallet? Like is the idea that this is like day to day spending money or that should they be storing like a decent amount in?

a Spark wallet or at what point is the idea, you know, they should be shifting that to like, you know, self custody or some more secure like offline setup. Can you just outline a bit of your thoughts on this on this question of so called trustodial?

Kevin Hurley (26:33)
Yeah, mean, our goal has always been to be as trust-minimized as possible. ⁓ I think if you compare it to basically any other solution out there, especially if you look at like the ETHL2s or any other L2s out there, I think you’d find that our trust properties are very appealing compared to any of those. ⁓ We obviously want to do as trust-minimized as possible forever. I think we have some ideas on continuing to make it so that there’s less and less trust involved.

For example running some things in teas where you have trusted execution environments where you can prove that certain things are happening Having more operators all those things start to make it so that the trust model is even better ⁓ But I think when you look at the the landscape of things we are About as good as you’re going to get without having it be completely trustless ⁓ And I think that because of that People should I mean make your own calls

But I think that the the trust model is pretty strong and we don’t feel like there’s a huge reason why you You shouldn’t keep a reasonable balance on it ⁓ I think everyone should Should make their own assumptions on what they want and how much they want to trust but ⁓ I think the trust model is quite strong here

Stephan Livera (27:56)
Yeah. And then the other big criticism I’ve seen online is around the privacy aspects. And I’m sure ⁓ you’ve seen ⁓ the discussion around this. I think one or two developers were kind of poking around and they found that all the transactions were ⁓ posted publicly and that people could, if they had one of your invoices or your single Spark address, that this would be enough to kind of dox your entire transaction history. So what’s the thinking around this?

And to be fair to you, I understand there is also some ideas on what to improve there. So maybe you can just outline a bit of your thinking on that.

Kevin Hurley (28:32)
Yeah, so if you look at it today, it’s essentially equivalent to Bitcoin layer one, where transactions are publicly visible. The big difference, I guess, is that we don’t yet have dynamic addresses, but that’s coming out very soon, where you’ll be able to generate a new address for each transaction. But generally, it’s pretty equivalent to Bitcoin layer one, where everything’s visible. We are soon, actually this week probably,

maybe next week, but probably this week, we will have the ability for users to flag that they don’t want their accounts to be publicly indexable, ⁓ and you won’t be able to publicly see what’s happening under an account. That being said, the operators still have visibility into things. And that was a big consideration of why we didn’t originally do something where it wasn’t publicly indexable, because we felt like we want something that really feels honest. ⁓

And if anyone can see the data, we don’t want to say that it’s private. And I think we got some pushback on that and folks felt like, it be equivalent to Venmo, for example, where Venmo or PayPal knows the transactions, but publicly it doesn’t. So we decided that we will do the same thing, ⁓ where for this next week or so, you’ll be able to flag that you don’t want it to be publicly indexable.

⁓ But we actually want to go much further than that because we feel like something that is more truly private is actually really important. ⁓ Where even the operators don’t know your balances or any transaction information about that. So what’s coming up after that is for tokens we’ll have confidential transactions. Where you won’t be able to see the amounts of transactions at all. ⁓ And then from there we want to have kind of a more holistic policy around privacy where you’re able to do

For example, one thing we’ve been exploring is kind of a deferred pay join type of solution where ⁓ you can do pay join solutions that you don’t actually have to do it live. You don’t have to have both users active. Kind of a more advanced pay join type of thing where you can’t actually necessarily know the amounts very well. You can’t really know who is involved in transactions. And I think we’ll probably go even beyond that. But we want to make sure that we’re doing something that actually

gives real privacy to users and isn’t just a fake kind of seems like privacy but isn’t actually privacy.

Stephan Livera (30:59)
Interesting and so you mentioned the pay join concept is that for on-chain transfers or are we talking spark to spark? Transfers or how would that pay join concept apply? Okay

Kevin Hurley (31:06)
spark to spark. It will be spark to spark transfers. ⁓ But

mean, like realistically, everything that you’re doing is assigned.

Stephan Livera (31:13)
seen by

the Spark operators, right? In that case.

Kevin Hurley (31:16)
Yeah, it is. But if you’re doing like a true pay join, then you wouldn’t actually be able to see like who is doing what necessarily. Like you wouldn’t know how many Sats were transferred from each user because it’s kind of mixed together in a way that you don’t necessarily see it. ⁓ And that’s just one of the avenues we’re exploring. I don’t know if that’ll be the end solution that we go with or not, but I think the key point is that we actually really want to have a true privacy solution ⁓ and something that really will

make it so that no one’s able to see what’s happening.

Stephan Livera (31:49)
Yeah, interesting. I mean, to be fair, I know there are other, you know, projects that kind of came out first saying this is, you know, it’s going to be a bit less private than what we would like and it’s going to future, it’s going to evolve into something more private. I know even with Phoenix, which is the one on lightning wallet by the team at async, I think it was a similar kind of thing for them where they said, yeah, obviously async is the lightning routing node. So obviously they know your payments, but eventually the idea is that they would have like trampoline routing and some other concepts.

that help on that side of it. ⁓ And then I think one other thing around, I guess, state chain security model, think, obviously you’ll be more familiar with this than I am, but I understand that there’s a, I guess it depends on the design, but one concept I’ve seen from state chain designs is this idea of having like an attestation that you’re on the correct state chain, because I mean, theoretically, the state chain could like create like a fake chain ⁓ that the end user might not actually know.

So is there anything on that side of things just so that they know that they’re on kind of the correct true chain and not like a fake chain?

Kevin Hurley (32:55)
I think we will likely be doing some type of attestations in the future. ⁓ It doesn’t fundamentally really change the trust assumptions too much. mean, you still have like that one event point in time trust model. It maybe alleviates some of the worries, but I don’t think it’s an end all solution. ⁓ So we really wanted to get to a place where we felt like we had a lot of the core functionality really solid. ⁓

where we had things super reliable and stable before we kind of go to some of the more advanced functionality. there’s a lot that we’re exploring that will kind of continue to advance the trustlessness.

Stephan Livera (33:31)
Great, because a lot of listeners of the show are themselves developers, builders in the space, can you outline a little bit on what’s the experience like there? I know you have a software development kit to help people, like a wallet development kit to help make wallets, and I understand some of the early people doing this, obviously Wallet of Satoshi, one of the world’s biggest ⁓ lightning wallets, and I believe you’ve got Blitz and of course Breeze. ⁓ So can you just talk to us a little bit on the…

developer, builder side of this, what’s the tooling, what have you got available for them?

Kevin Hurley (34:03)
Yeah, I mean a big focus of what we were doing is to try to abstract away as much complexity as possible and make it so that you can integrate in just as few lines of code as possible. ⁓ I think we’ve struck that balance fairly well. There’s still obviously more room to go, but that was a big thing for us was to make it so that it’s not difficult to integrate with. If you look at a lot of other solutions, they are quite complex and it’s really hard to actually integrate and do really well.

and have a good user experience. So for us, that was a big focus of what we were trying to do. And I think if you look at a lot of the partners we have, the ones that you mentioned, also, I mean, we have like Tether doing WDK, we have Luminex, X-verse, a bunch of others. And then companies building on top of that to make it simple to create wallets. So like a privies of the world, like Braille who are doing stablecoin issuance and making it easy to do stablecoin issuance.

⁓ We have a lot of partners that we’ve specifically chosen because they care about the UX and because they care about making it easier for others to build on top of the network.

Stephan Livera (35:11)
Yeah. Now I know you also have a token ⁓ protocol. I believe it’s called BTKN and you have this concept just from my notes. I think you’ve got TTXOs and you can make assets. So can you just talk us through a little bit of that? Like what’s the process there? How are the assets issued, transferred, deleted?

Kevin Hurley (35:30)
Yeah, so you can think of it kind of like a protocol that lives on top of Bitcoin UTXOs. And it actually, it’s a very efficient protocol because it actually just looks like transferring from one key to another. And the way that happens is effectively tweaking the key with some metadata on top of it. So you can think of it like a JSON blob that says, okay, here’s token, Kevin coin, there’s a hundred of them, we serialize it and hash it and then we tweak a key based on that. ⁓

And you can kind of trace the provenance of transactions throughout the system to ensure they go back to the original issuer, no coins were created or destroyed along the path. And because of that, if you ever were to put it on layer one, it just looks like Schnorr signature ⁓ and key-to-key transactions. There’s not like sticking a bunch of data into opreturns or anything like that. It just looks like a normal transaction. So it’s highly efficient from a layer one standpoint.

And then if you look at how we do it on Spark, it is you can issue a coin instantly. You’re able to create this coin. You’re able to transfer it instantly. Right now it’s currently free to create coins, free to transfer coins. ⁓ We’re adding layer one exit ability right now for tokens. You can’t go to layer one, but that’s soon to change and you’ll be able to unilaterally exit to layer one. Your tokens can exist on layer one and Spark simultaneously. ⁓ So you have this ability to kind of

do things on Bitcoin that maybe weren’t easy or weren’t really possible before because you can now issue instantly, transfer coins instantly, whether that’s stables or meme coins or NFTs or anything like that, you’re able to create these tokens natively on Spark and have them move to layer one and back and forth.

Stephan Livera (37:17)
And so as I’m under standing you then This is a product of this BTK and protocol it can work both just kind of on layer one Bitcoin and also in kind of in a lifted into spark off-chain kind of context, right? Okay, and then I Presume now, I mean people use it for all kinds of different things obviously

Kevin Hurley (37:34)
Yep, exactly.

Stephan Livera (37:43)
Many of us have Bitcoin maxis, but I also appreciate that there are people out there who want stablecoins or maybe for some users, it’s like a helping smooth their on-ramping pathway. So for example, if you’re a merchant, maybe you’re not comfortable taking the full volatility of Bitcoin or maybe you’ve got bills to pay. Maybe you want to take some of your payment in Bitcoin denominated terms and some of that into some kind of a stablecoin. ⁓ And so can you talk us through like what would the stablecoin support look like on

BTKN.

Kevin Hurley (38:15)
Yeah, I mean we have some really big partners that are coming on board that are issuing some of the major stable coins. Right now we have USDB which is issued by Braille, but there’s many others that are going to be coming on board as well. And like you mentioned, are a lot of folks that want to what are effectively US dollar denominated bank accounts ⁓ by holding a stable coin. So if I’m in a country that has a really volatile currency, I might want to hold

what’s effectively a US dollar-denominated bank account. And I can’t do that because I can’t open a US bank account if I’m in another country. But I can effectively do that by holding a stable coin that’s a US stable coin. So there’s a real product market fit where customers want to be able to do that. And I think to be able to do that on Bitcoin, which is, ⁓ like the most neutral chain that you’re going to have, most decentralized chain you’re going to have, is something that is a key differentiator between

Bitcoin and the other chain and being able to hold these assets natively on Bitcoin is actually really valuable. ⁓ You also have so much liquidity on Bitcoin that it makes it really useful for going between Bitcoin and stable assets. if users want to be able to get loans against their Bitcoin or hold something that they are able to now have merchants that can accept both Bitcoin and stable coins on the same network, it’s really useful to have the best network able to support this well.

have it lifted onto Spark so that you aren’t actually necessarily waiting for the block time in layer one or or congesting layer one you’re able to do it in a way that actually is still native Bitcoin ⁓ but more efficient.

Stephan Livera (39:54)
Any comments on more advanced scripting and smart contracting capabilities? So as an example, as you touched on this lending example, right? There’s so much interest in lending. mean, if you look at the last, this year, I would say there’s been a huge pickup in the interest, both on the borrowing side of the house and on the capital provider side of house interest in lending. Now in the BTKN context and Spark, is there going to be some way to achieve that?

using like the protocol or is it going to be more like you would use some kind of you know, TradFi style platform, but you can withdraw the stable coin into your Spark wallet. Is that, do you understand what I’m asking? Can you explain a bit there?

Kevin Hurley (40:36)
Yeah,

so we have plans to add some level of programmability, but obviously that would change the trust assumption for things that are using that level of programmability. We want to kind of keep the base trust assumption that you can hold your coins on Spark. Trust assumption is what I talked about before. If you want to do some level of programmability, since you can’t really settle that to Bitcoin layer one with natively signed transactions easily, ⁓ it would change the trust assumption slightly.

But we do expect that we’re going to add some level of programmability. ⁓ Now what form that takes, we’re not quite ready to announce yet, but I think we’re going to do something that will probably be a little bit different than what others have done, ⁓ just because we feel like there’s some new avenues to approach it in that I think will be really appealing. But we’re still early in explorations on it. But we do want to have some level of programmability.

Stephan Livera (41:27)
I see

and so then as you I guess implying also that that may Have functionality like lending or maybe some kind of decks functionality where people are swapping Whatever stable coin for Bitcoin and this kind of thing I guess these are some of the ideas

Kevin Hurley (41:42)
Yeah, for sure. And

I think a big part of it kind of goes back to our core principles that we talked about before of making it really user-friendly and developer-friendly. ⁓ And whatever we do, I think, will be focused heavily around that, such that you aren’t exposed to as much of the complexity as you might be previously or on other solutions. ⁓ But it’s a really intuitive experience.

Stephan Livera (42:08)
Now we’ve touched on it through the conversation around comparisons with other Bitcoin L2s, whether that’s Lightning and Liquid and ARK and eCash. ⁓ So I guess if you had to just kind of put it concretely or in simple terms, where do you see Spark differentiating from those? Is it kind of the UX side of it or is it maybe the cost efficiency or where do see it competing?

Kevin Hurley (42:33)
I mean, each option chooses a different mix of what’s important. ⁓ For us, was really payments focused, be able to support payments of scale, self-custody of scale, be able to have as minimal trust as possible without having to have new opcodes and waiting around for years hoping that a new opcode will exist, and then have the best user experience where they can receive funds offline, they can have interactions directly with Lightning, with Layer 1.

⁓ And it’s something that is super easy for them to use and they don’t have to have a case where they might lose their money after a certain number of days or have someone else that has full control of their money ⁓ that they can always exit. ⁓ So those were kind of the things that really mattered to us. But it’s different between every solution. ⁓ A lot of them don’t necessarily care about unilateral exit or ⁓ maybe take different assumptions on what’s important and for us

I think we’ve struck the right balance. lot of our partners and users have really loved the balance that we’ve chosen and have felt that minimal trust and best user experience are the key things that actually really matter.

Stephan Livera (43:40)
Yeah, and just if you could clarify one concept there around refreshing so I guess there you’re referring to more like the arc context where maybe the user has to refresh ⁓ with combined with like the arc server or operator whereas as I’m understanding in the spark context There’s not that same idea You don’t have to like your wallet doesn’t your spark wallet doesn’t have to come back online once every month to do a refresh

Kevin Hurley (44:06)
Yep, that was something that we weren’t super comfortable with ⁓ and something I think just from a user standpoint didn’t feel great ⁓ that users had to come online at a specific time and get in and around for example and wait for the round to complete so they could feel like their funds were going to be safe. I know there’s been some advancements on that and third parties that can try to watch for that some of that for you but it just didn’t feel great to us. ⁓

And it was something that was really important for us that the users could feel secure with their funds and not have to come online frequently to feel that security.

Stephan Livera (44:43)
Yeah. Kind of more over in the lightning world. I know this is something that came out of light spark, which is the UMA. So could you explain a little bit about that and how does that contrast or differ from other concepts or maybe maybe they’re not competing, but things like in the Bitcoin or lightning context, you’ll see developers talking about things like bolt 12 and bit three 53 for human readable names. And as I’m understanding, UMA is kind of more

similar to like a lightning address or kind LN URL based. Can you just outline a bit there on UMA?

Kevin Hurley (45:19)
Yeah, so I mean it’s an open source protocol, universal money addresses, which is built on top of lightning addresses and LNURL. ⁓ The real purpose of it is to kind of expand the users and customers that can use Bitcoin as a settlement asset. ⁓ And that means being able to go from fiat to fiat where Bitcoin lightning glues these things together, or go from like any other crypto or Bitcoin ⁓ to Bitcoin or any other crypto.

And being able to kind of do anything to anything that’s glued together with Bitcoin and lightning Because again, like we feel like Bitcoin is the best settlement asset But we want to be able to support whatever customers want and to be able to do that Through Bitcoin because we feel like it’s so important for things to go through Bitcoin So when you look at let’s say so fi who is onboarding to it right now transferring to new bank

They can now go from any currency, any other currency, let’s say US dollar to Brazilian reales, and that’s glued together with Bitcoin Lightning. So you get the benefits of instant settlement, extremely low fees, and you’re able to go cross-border anywhere to anywhere from instant bank rails to instant bank rails without going through Swift and taking three to five business days. You now have the advantage of Bitcoin Lightning, but you can still use the rails that you want to use as well.

I think that that kind of expands the users that might be willing to use Bitcoin and the companies that might be willing to use Bitcoin because they can fit into their existing paradigms really well. ⁓ I don’t think it necessarily competes with a lot of the other things because it’s a very different solution. ⁓ But it’s built to kind of facilitate big institution to big institution and in the future also going from big institution to self-custody wallet.

⁓ and be able to do any currency on the other currency.

Stephan Livera (47:15)
Yeah, interesting. And so yeah, as you said, the kind of bolt 12 bit 353 idea, as I understand it is more, let’s say lightning native and Bitcoin denominated only, whereas the UMA concept, as I’m understanding you, you can do other currencies and then that can be handy for some of these neo banks and even crypto exchanges and people like that who might want to give you effectively what looks like an email address, but actually the user can take his Bitcoin payments there or he can take his maybe in the future his tether payments or some kind of stablecoin payment or something like this.

⁓ And that can be received into the wallet in a more let’s say seamless way is how I’m understanding that ⁓ And now one other area I believe I’ve seen David Marcus talk about this idea and of course you’ve mentioned this as well around corp chains, right? And the reason I’m asking this is there’s been a lot of noise recently from some of the stable coin issuers not tether but I think some of the others like circle and I think Robin Hood basically, they all want to do their own chain and It seems to me now

Kevin Hurley (47:51)
Yep, exactly.

Stephan Livera (48:14)
If you’ve been around in the Bitcoin and in this industry for a little while, you’ve seen like 10 or 11 years ago, there was this whole R3 blockchain technology. It sort of feels like we’re redoing all that again. What’s your take on all these people who want to do their own chain?

Kevin Hurley (48:32)
You know, I get why they maybe want to. They have full control of it. But I don’t think that that is likely to be the winning solution. ⁓ If I’m PayPal, I’m not going to build on Stripe’s chain. If I’m Stripe, I’m not going to build on Adian’s chain or any other company’s chain that competes with me. And that’s kind of why we have landed on it needing to be a neutral settlement layer in the middle. ⁓ And we feel like Bitcoin is the best neutral settlement layer.

And I think that they’re going to continue, they’re going to do their thing, but I just don’t see how a competitor builds on your chain without it being something that really is credibly neutral in the middle. And I think Bitcoin is the only thing that’s really credibly neutral. So that’s why we feel like it’s the right solution to be the real global settlement layer.

Stephan Livera (49:23)
Yeah, there’s perhaps some parallels with the internet and how companies wanted to do their own private intranet instead of building on the public internet to sell products and obviously get make a name for themselves and so on. Although I guess if I had to now obviously I’m a maxi so I’m with you on that but if I had to steal man is the case then that all but we’re just going to do a lot of cross chain swapping is what would you say to that this idea that well yeah they can just have their own change but there’ll just be a ton of atomic swapping going on.

Or do you think that’s just going to be more costly or just less efficient?

Kevin Hurley (49:56)
I mean, it’s certainly possible. think that you probably do. Well, I mean, I don’t think that realistically that’s going to be the right long-term solution. ⁓ I think if you have a single settlement layer, it’s going to be much better than having 50 settlement layers. I mean, I think your analogy is really good with the internet. Like AOL tried to make their own kind of walled garden. Other companies tried to make their own walled garden. And really, neutrality ended up winning out the day.

Having something that everyone connects to that really is credibly neutral made a lot of sense and Though the walled gardens kind of crumbled and ended up going towards towards that in the end of the day I’m sure it’ll probably follow a pretty similar pattern here where They build out the AOLs of the world in these corp chains and then eventually everyone realizes that that’s not what we actually want We want something that is just a single layer that everyone can connect into

Stephan Livera (50:53)
I see. ⁓ Now on the concept of state chains and spark in general, is it possible for somebody else to kind of spin up their own, you know, their own spark operator, their own spark entity that’s like distinct from the one that you are operating at spark or not?

Kevin Hurley (51:14)
Yeah, I mean,

it’s an open, it’s all open source. ⁓ So anyone can run whatever they want to. ⁓ I think that it’s good because it actually holds us accountable and ensures that we are acting in the best interests of anyone that might be using the network. ⁓ I mean, just like anyone could run another version of Bitcoin or another version of Lightning. ⁓ You could obviously do that. And I think it’s good to have that as something to keep everyone in.

honest and accountable. ⁓ That if we start doing things that are not in the best interest of the network, someone should go ahead and run a competing one. ⁓ And I think that actually is good for competition-wise and it’s good for keeping us honest.

Stephan Livera (51:58)
Now, I guess going back to what you were saying at the top ⁓ of this episode, I think one idea you were talking about was this idea of hitting a certain level of scale, right? That you need certain things in order to hit that kind of multi-hundred million or billions of users level of scale. just curious, if you look at Spark as it exists today, can it go to like a hundred million? Could there be a hundred million users on Spark?

Kevin Hurley (52:27)
I mean the way that it was constructed is such that it can scale extremely well. It’s not like a block based system. It’s a DAG, a directed acyclic graph so that you can actually shard it pretty well. You can make it into so that multiple machines are running things because you don’t have to wait for blocks. You don’t have to fit it into a certain block size. The way it was built and constructed is such that it

is theoretically scalable to extremely, extremely high amounts. If you look at it today, it’s not yet completely there. I think when we tested token transactions, you could do like a couple hundred transactions a second, ⁓ which is like relatively equivalent to I think what PayPal generally does right now anyway. ⁓ But we still have work to go. ⁓ If you want to be able to support spikes of several thousand CPS, I think we’ll get there.

It’s just a matter of we need to spend a little bit more time focused on that. ⁓ But I think that it is constructed in a way that is intentionally built to be able to support billions and billions of users. ⁓

Stephan Livera (53:36)
Okay, so

you have a pathway to being able to go there. Okay, so I guess last question just where can you know, what are you looking for in terms of community or builders developers? ⁓ What are you looking to see from them just people who want to build in here build Build something with spark and I guess maybe maybe you can just outline a bit about you know Where are the where is the best place that I need to go if they want to like figure out how these things work and what to do with it?

Kevin Hurley (53:40)
Yeah, exactly.

Yeah, go to our website spark.money. ⁓ have email addresses on there to get in touch. You can ping me on Twitter. ⁓ Reach out to us through any of those avenues. We always are happy to chat. We are really developer focused. We want to make sure that what we’re doing is incredibly easy for anyone to build on top of and to onboard to. So if you notice anything, please let us know. Our repos are open source, so submit.

PRs, submit issues of things that aren’t working well. ⁓ We want to make sure that we are doing right by the community and we want as much involvement as possible. We want as much collaboration as possible. anything that you see that you would like, submit PRs, ⁓ open up issues, let us know how we can improve. ⁓ We want as much developer interest as possible and we want as much developer involvement as possible.

Stephan Livera (54:59)
Excellent. Okay, well, there we go. So bit of an overview of Spark. So thank you very much, Kevin, for joining us and helping explain this for the listeners.

Kevin Hurley (55:08)
Thank you.