Welche Impulse setzt OER für die Religionsdidaktik? Ein Einblick in die AKRK-Tagung in Leitershofen von 19.-21.9.2024

Vom 19. bis 21. September traf sich die AKRK (Arbeitsgemeinschaft Katholische Religionspädagogik und Katechese) zu ihrer Jahrestagung in Leitershofen bei Augsburg – ein Event, das auch für FOERBICO von besonderem Interesse war. Unter dem übergreifenden Thema „Religionsdidaktik in ihren Spannungsfeldern“ ergaben sich anregende Anknüpfungspunkte, z.B. wie verändern Open Educational Resources die Religionsdidaktik? Wie können KI-generierte OER in der Religionspädagogik eingesetzt werden und was gilt es dabei zu beachten? Welche Antworten und weiterführenden Debatten wir gefunden haben, könnt ihr in diesem Blogbeitrag lesen!

Ark Protocol เส้นทางธุรกรรม Bitcoin นอกเชน ทางเลือกใหม่ที่น่าจับตามอง

Ark Protocol เลเยอร์ 2 โปรโตคอลน้องใหม่ ที่มาพร้อมแนวคิดอย่าง vUTXO และ Covenant ที่ช่วยให้ธุรกรรม Bitcoin รวดเร็ว ปลอดภัย และเป็นส่วนตัวมากขึ้น

Ark, una propuesta para usar Bitcoin en pagos cotidianos

Ark es un protocolo de segunda capa de Bitcoin diseñado para facilitar pagos y micropagos cotidianos de forma eficiente, manteniendo la autocustodia y la resistencia a la censura de Bitcoin.

Spark and Ark: A Look At Our Newest Bitcoin Layer Twos

Bitcoin Magazine Spark and Ark: A Look At Our Newest Bitcoin Layer Twos In my quest to find the best solution for Cake Wallet to offer user-friendly, non-custodial Lightning to our users, I’ve gone deep down the rabbit hole of both Spark and Ark. Both are quite novel approaches to Bitcoin layer two networks, and are designed at their core to be interoperable with the broader Bitcoin network for payments via the Lightning Network. While both can be used “just” for Lightning payments, both networks are positioned to rapidly expand and be used for far more than that over the coming months and years. One thing to keep in mind is that while Spark and Ark on their face seem rather similar, in practice and in implementation they are quite distinct. Why do we need new layer twos? Bitcoin at its core is an incredible tool for freedom, but due to block size constraints, we know that the majority of the world will never be able to make transactions on-chain. Enter Lightning, a solution that allows one on-chain transaction to allow for essentially infinite off-chain transactions, expanding the usefulness of Bitcoin’s base layer and making it possible for more people to transact. While Lightning provided a promising approach to scaling Bitcoin payments, ultimately the realization that its best role is as an interoperability layer and not as a tool for end-users to run themselves has become clear. On-chain requirements, liquidity management, liveness requirements, and other core hurdles make the implementation of user-friendly, self-custodial Lightning next to impossible. This has become apparent as most Lightning wallets and use-cases have opted to use custodial or federated models out of a need to simplify the user experience and the implementation difficulty. The biggest win that Spark and Ark provide to the Bitcoin space out of the gate is providing a much simpler and easier way for the average developer to provide Lightning to their users, while allowing for greatly expanded functionality down the line beyond Lightning payments. Ark, simplified History The concept of Ark was created in May of 2023 by Burak, a Lightning advocate and developer. The driving force behind its creation was the realization that the Lightning network as constructed was not effective as an onboarding tool for the average individual due to inbound liquidity requirements among many other things, and that privacy was often lacking. While Burak invented the protocol itself, two companies – Ark Labs and Second – have stepped in to build the Ark protocol into an end-to-end layer-two network for Bitcoin. While both companies are building around the same open-source Ark protocol, their implementations and objectives are rather dissimilar. As a result, I’ll do my best to distill both below where possible. Terminology Ark: Ark is a protocol for moving Bitcoin transactions off-chain by leveraging multisig and pre-signed transactions between users and the Ark Operator. Anything you can do on Bitcoin, you can do on Ark but faster and with lower fees. Ark Operator: The entity running the centralized Ark server infrastructure and responsible for providing liquidity for user’s VTXOs before expiry. Lightning Gateway: The entity that provides the ability for Ark users to send or receive Lightning payments using trustless atomic swaps of Ark VTXOs. This function can be provided by the same entity as the Ark Operator, but is often distinct to spread out counter-party risk. Virtual Transaction Outputs: Also called “VTXOs”, these are very similar to on-chain UTXOs in nature, but are virtual as they aren’t represented as unique UTXOs on-chain and live entirely off-chain. Users send and receive VTXOs within Ark. Rounds: In order to gain true finality and/or refresh VTXOs, Ark users will need to join rounds, where they work together with other Ark users and the Ark Operator to get new VTXOs in exchange for a fee. Making transactions Ark functions very similarly to on-chain Bitcoin transactions, and inherits many of the same mannerisms while allowing transactions to be near-instant and trust-minimized between Ark participants. The sender works with the Ark Operator to sign the VTXO over to the recipient, or in the case of Ark Labs to create a new, chained VTXO for the recipient. This allows a user-experience similar in many ways to on-chain payments, but with far lower fees and far faster transaction times. When the user wants to send or receive Lightning payments, they can work with a Lightning Gateway to atomically swap VTXOs for Lightning payments as-needed. At the moment no offline receive for Lightning payments in Ark is possible, but it’s likely this will be solved in a similarly trust-minimized way within Ark as it is in Spark. If the user desires finality (i.e. they’ve received a large payment), they can choose to join a round to finalize the payment and gain the same finality assumptions as on-chain Bitcoin. The frequency of this round process will vary by Ark Operator – with estimates ranging from every 10min to every hour – and requires a relatively lengthy coordinated signing process between all users seeking to join the round with the Ark Operator. The round frequency can even vary based on demand, and is not something that has to be set in stone to a single frequency unlike Bitcoin block times. As Ark inherits Bitcoin scripting and the UTXO model directly from on-chain Bitcoin, Ark will likely be extended to support token protocols like Taproot Assets in the future. Trust tradeoffs Ark targets a very trust-minimized approach to scaling Bitcoin, striking something of a middle-ground in terms of usability and tradeoffs between Lightning and Spark. Note that Ark as a protocol is rapidly developing, and some of these tradeoffs will hopefully be solved through the use of novel off-chain methods or after the implementation of covenants in Bitcoin. Lack of out-of-round finality While Spark lacks provable finality, Ark strikes something of a middle ground. For small payments, users can rely on the Ark Operator and previous senders to not collude for security, allowing for instant transfers with no need for collaborative signing rounds. Note that by default, payments within Ark will be “out-of-round” payments that lack true finality, a tradeoff that allows Ark to deliver a good user experience out of the box. That being said, users who do need or want true finality can have it by joining a round and receiving a new VTXO from the Ark Operator. Receivers are essentially in control of their preferred trust model. VTXO expiration As a result of the liquidity requirements to operate an Ark instance, Ark Operators need a way to reclaim liquidity regularly. To allow this liquidity reclamation, Ark VTXOs will expire regularly (i.e. after 30d, with the VTXO expiry being set by each Ark Operator), requiring their owners to either join a round to refresh the VTXO or risk giving up control of their funds entirely to the Ark Operator. While the Ark Operator has strong incentives to merely issue a new VTXO to the owner of the expired one when they come back online, both the Ark Operator and the user will have the ability to spend funds until a new VTXO is issued to the user. To avoid funds expiring, users will be required to refresh their VTXOs within that window either directly or by offloading refresh to a delegate. Alternatively, atomic swaps of an expiring VTXO for one with a longer lifecycle could be done with an entity like Boltz for a fee, but that is not yet implemented. Complex round user experience If you’ve ever used Coinjoin on Bitcoin, you know how tedious and unreliable collaboratively signing a transaction with other Bitcoiners can be. In Ark, those seeking true finality for their VTXOs will need to be available throughout a round signing process until its completion, something that will depend heavily on other participants properly completing the signing process. While this is quite trivial to accomplish for a wallet running on an always-online server, it’s rather complex to reliably perform on mobile platforms, especially iOS where no background execution (and thus no ability to be online at the right time for signing) can be guaranteed for any app. As a result of this complex user experience, Ark Labs have come up with a system that leverages delegated third parties performing the refresh in a trust-minimized way for users, offloading the liveliness requirement to a third party. While this third party has no ability to steal funds, if they are offline for any reason or refuse to refresh a given VTXO, the user will be forced to join a round themselves before the expiry period. To mitigate this risk, users can designate multiple delegates, shifting the trust assumptions for expiry to a 1-of-N assumption, where if any delegate is honest their VTXO will be refreshed properly. Second also have a similarly designed system that enables trustless, non-interactive rounds for users, allowing any number of parties to sign for a user during a round (i.e. the wallet provider and a third-party delegate) where if any of those parties signs properly, the users VTXO is properly refreshed. Note that while these two solutions can refresh expiring VTXOs, they cannot give users true finality without the user actively participating in the round themselves. Lastly, it’s important to call out that the vast majority of complexity with the round process can be entirely mitigated if a simple covenant is deployed in an upgrade to Bitcoin, something that would unlock a vastly improved user experience for Ark. Privacy tradeoffs At its core, Ark inherits Bitcoin’s poor privacy and doesn’t provide any notable privacy improvements as a protocol. That being said, its ability to offload execution off-chain and expand Bitcoin’s functionality allows existing and novel privacy protocols to be built on top of it in the future, with covenants fully unlocking things like private rounds within Ark. In the short-term, Ark Labs have planned to use WabiSabi-like blinded credentials to improve privacy from the operator when users participate in rounds. Transaction visibility While all transactions within Ark don’t need to be published on-chain, providing some loose ephemerality, all transaction details are visible to the Ark Operator and shouldn’t be considered private in the truest sense. Instead, viewing the ephemeral privacy provided by Ark as analogous to the VPN model (offloading visibility into transactions from the Bitcoin blockchain to a trusted third-party) is a useful mental model. It’s unclear at this time if Ark Labs and Second will keep transaction data private or publish it publicly, but as with a VPN users should not rely entirely on a promise to not log for their privacy. Learn more Official docs (Ark Labs): https://docs.arkadeos.com/ Official docs (Second): https://docs.second.tech/ Excellent Ark explainer video from Second: https://www.youtube.com/watch?v=WvwmLv0SgAc “Ark and the train analogy”: https://pakovm.substack.com/p/ark-and-the-train-analogy-a-guide Spark, simplified History The Spark network was launched earlier this year by the folks at Lightspark, a Bitcoin-adjacent company with an interesting history. From UMA (a username system with natively integrated compliance features for their banking partners) to connections with the failed Libra currency, they have an odd track record of building tools that aren’t quite up to par with Bitcoin’s more cypherpunk roots. But, when I put aside their odd track record and focused purely on what Spark the protocol actually is, it presents a rather useful, pragmatic, and powerful tool overall. Spark at its core takes a lot of the useful features of statechains, a novel approach to layer twos on Bitcoin created by Ruben Somsen in 2018. Spark specifically extends statechains with the idea of “leaves”, allowing users to send any amount in a transaction instead of being solely able to transact with whole UTXOs, one of the biggest issues with statechains up to this point. Terminology Spark Entity: the entity running a given Spark instance, i.e. Lightspark, made up of a collection of Spark Operators. As Spark is an open-source protocol, anyone can start their own Spark Entity, but each Spark Entity controls which Spark Operators can join. Spark Operator: each Spark Entity is composed of one or more Spark Operators, each of which are responsible for validating and signing operations of users within the Spark instance, including transfers of funds and tokens, issuance of new tokens, etc. These can be the same entity as the Spark Entity, or (hopefully) distinct in relationship and jurisdiction from the Spark Entity. Currently the two Operators for Spark are Lightspark themselves and Flashnet, but more are slated to be added in the near future. Spark Service Provider: an entity that provides various services to Spark users, including using atomic swaps to trustlessly send and receive Lightning payments on the users behalf. Spark leaves: Spark solves the issues around whole-coin transfer requirements in statechains with the introduction of leaves. These can be thought of similarly to UTXOs within Bitcoin, as they can be freely broken up into any size necessary. Making transactions At its core, Spark functions by allowing users to easily move Bitcoin around the Spark network near-instantly by working in a trust-minimized way with Spark Operators to transfer ownership of individual leaves to another person. There is no need for a blockchain, confirmations, or liveness between sender and receiver, making payments simple and very fast. When a user wants to make a payment on Lightning, they atomically swap a leaf or leaves from their wallet with a Spark Service Provider who then sends the payment trustlessly on their behalf for a fee. To transfer a Spark leaf, the sender co-signs ownership of the leaf over from themselves + Spark Operators to the new owner + Spark Operators. This is done in such a way that if any of the Spark Operators or previous owner honestly deletes their keyshare used in the co-signing operation, the leaf is then solely owned by the recipient and no double-spend is possible. As this operation only requires collaboration between the Spark Operators and sender and not any other Spark users, these signing rounds are very fast and resistant to DoS attacks. Spark also includes a similar 1-of-N trust model to do offline receive for Lightning payments, a key user-experience improvement over standard Lightning wallet usage. This is especially important when using Spark on a mobile wallet, as mobile platforms cannot guarantee background execution or perfect network access 24/7. In addition to regular payments, Spark has extended the idea to include native token support, with the core focus being on stablecoins like USDT and USDC able to be issued and transferred seamlessly within the Spark network. Tokens transfers themselves share a similar trust model to standard transactions on Spark, and retain the ability to unilaterally exit on-chain. Lastly, users in Spark can unilaterally exit on-chain at any time by publishing a pre-signed exit transaction on-chain. While the cost of exiting can vary widely due to variables like leaf depth and on-chain fee rates, likely pricing out smaller amounts, it’s a critical tool to ensure that funds can be retrieved in the event of a malicious or unavailable Spark Entity. Trust tradeoffs Spark makes a very pragmatic set of tradeoffs that compliment the current issues befalling Lightning and Bitcoin usage today. That being said, there are some major differences with Spark compared to on-chain Bitcoin or Lightning usage. I prefer to use the term “trust-minimized” when talking about Spark (and most other layer two networks) as only self-custody of Bitcoin on-chain can truly be viewed as “trustless”. Lack of true finality The core risk to self-sovereignty in Spark is the lack of true finality, where users can never know for sure that their funds cannot be double-spent through collusion between the Spark Operators and a previous spender. Within Spark, finality (knowing that your funds can only be moved with your keys) exists – but is not provable – on the condition that any single Spark Operator deletes their keyshare after signing off on a Spark transaction. On the flip side, if all Spark Operators are malicious and refuse to delete their keyshare and collude with a previous sender of a leaf you own they can double-spend that leaf and effectively steal funds. While in practice I think this 1-of-N trust assumption is reasonable, it obviously falls far short of the regular, on-chain Bitcoin trust assumptions where true finality is a default. It’s also important to note that due to the pseudonymous nature of Spark transactions, the previous sender could be the same entity as the Spark Entity. Potentially centralized token control While transfers of tokens themselves share the 1-of-N trust assumption of regular Spark payments, the tokens themselves can be frozen at any time if the issuer decides to enable this functionality. While this is similar to many centrally controlled stablecoins like USDT (who freeze and confiscate Tether quite often for legal reasons), it’s important to callout and will likely be enabled in many regulated stablecoins like USDC and USDT. 1-of-N offline Lightning receive security While offline Lightning receives are not trust-minimized in the same way standard Lightning payments are, theft of funds would require all Spark Operators to collude to steal a single Lightning payment, something that is disincentivized due to the small size of Lightning payments and the massive reputational risk if caught stealing from users, something that is easy to detect due to the inherent proof of payment in the Lightning network. Privacy tradeoffs Spark itself should not be viewed as a privacy tool, as it inherits core privacy problems from Bitcoin’s base layer and has made some poor design choices initially when it comes to privacy. That being said, Spark’s core technology could be extended to have fantastic privacy with the introduction of blind signing for all transactions, confidential amounts for token transfers, and other privacy technologies that aren’t normally possible within the Bitcoin ecosystem. Transaction visibility While transactions within Spark aren’t published for all time to a blockchain like on-chain transactions, all Spark Operators do get full visibility into transactions. In theory this could provide ephemerality if Spark Operators had a non-logging policy, but in practice all transaction data is currently being published to an explorer by Flashnet, one of the Spark Operators. This means that outside observers can trivially look up Spark addresses and see all transaction details, token balances, and even link Lightning payments to addresses using timing and amount analysis. Note that Spark is working to add the ability for wallet developers to opt-out of this data publishing by marking transactions as private, which then falls back to the same VPN-like trust model as previously described for Ark. If a wallet developer opts to enable this (as I hope they all will!), the Spark Operators will promise not to publish this transaction data publicly, but of course still have the ability to store this data locally if they so choose. Lack of address rotation In its current form, Spark doesn’t support spending funds from multiple distinct Spark addresses in a single transaction. While this is slated to be fixed and already acknowledged as a key shortcoming of Spark, at present it means that most Spark implementations will rely on a single, static address for all transactions, making Spark’s privacy at the moment worse than even on-chain Bitcoin. Combining this address re-use with all amounts being visible means that it would be trivial for an attacker to perform timing + amount heuristics on payments to ascertain which Lightning payments pertain to which Spark addresses. Spark address leaks To complete the trifecta of current privacy problems in Spark, the core SDKs provided by Spark (and used by the most common implementation of Spark in Wallet of Satoshi) by default include the user’s Spark address unnecessarily in BOLT 11 Lightning invoices. This means that anyone can easily decode a provided BOLT 11 invoice and learn every transaction from that user in Spark, thanks to the use of static addresses and all details being published to an explorer as detailed above. Note that this isn’t absolutely necessary, can easily be disabled by wallet developers, and is already removed in the Breez Nodeless SDK that utilizes Spark and is rapidly gaining adoption but is important to callout nonetheless. Learn more Official docs: https://docs.spark.money/home/welcome Bitcoin Layer 2: Statechains: https://bitcoinmagazine.com/technical/bitcoin-layer-2-statechains Conclusion While both Spark and Ark present an exciting new time in the world of Bitcoin usability and scalability, as with all things they come with their own unique sets of tradeoffs. While neither is a perfect solution, it’s exciting that wallet developers finally have two competing and interesting options to solve the implementation of Lightning, native tokens, and other functionality into their wallets and software without the complexity traditionally associated with Lightning. Both Spark and Ark present a pragmatic outcome for scaling Bitcoin, representing a hard but sane path to do things in a way that balances trust-minimization with user-experience and scaling. As both are rapidly evolving protocols, the hope is that the tradeoffs presented by both solutions will be rapidly improved upon and minimized in the coming months and years, providing an even better option that gets non-custodial Bitcoin into the hands of many more people while extending the things that we can build on top of Bitcoin. A special thank you to the folks at Spark, Ark Labs, Second, Breez, Spiral, and Bitcoin QnA for taking the time to provide feedback on this article! It takes a tribe to work out all of the trust assumptions and tradeoffs of these novel systems, and I’m extremely grateful to each for taking out some of their valuable time to help here. This is a guest post by Seth For Privacy Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine. This post Spark and Ark: A Look At Our Newest Bitcoin Layer Twos first appeared on Bitcoin Magazine and is written by Seth For Privacy.

Ark Labs, raccolta $5,2M per portare stablecoin e programmabilità su Bitcoin

Ark Labs Raises $5.2M with Tether to Bring Programmable Finance to Bitcoin

Bitcoin Magazine Ark Labs Raises $5.2M with Tether to Bring Programmable Finance to Bitcoin A startup focused on expanding Bitcoin’s financial capabilities has raised fresh capital as interest grows in building more complex financial tools on the network. Ark Labs announced it secured $5.2 million in a seed funding round led by Tether alongside investors including Ego Death Capital, Epoch VC, Lion26, Sats Ventures and Contribution Capital. Additional participants include Anchorage Digital and angel investors such as Ralph Ho, former vice president of finance at PayPal, according to a note shared with Bitcoin Magazine. The funding coincides with new support for stablecoins and digital assets on Ark Labs’ core infrastructure platform, Arkade. The company said the capital will help expand development and onboard partners building financial applications on top of the system. The round brings Ark Labs’ total institutional funding to more than $7.7 million. Earlier backing came from firms including Draper Associates, Fulgur Ventures and Axiom Capital. Ark Labs is attempting to address a long-running tension within the Bitcoin ecosystem. While Bitcoin is widely regarded as the most liquid and secure digital asset network, many developers have argued that it lacks the native programmability that powers decentralized finance and complex payment systems on other blockchains. According to Marco Argentieri, CEO of Ark Labs, the company’s infrastructure is meant to bridge that gap. “Bitcoin is the most liquid digital asset in the world, but it has lacked the programmable infrastructure that financial applications require,” Argentieri said. “Our partners are building payments, lending, and digital asset solutions on Bitcoin, and Tether’s involvement will help accelerate those efforts.” The Arkade platform functions as an execution layer designed to support financial operations that go beyond simple transfers. In traditional payment systems, features such as transaction authorization, escrow, conditional spending, and payment holds form the backbone of commerce. Ark Labs says its infrastructure aims to bring similar capabilities to Bitcoin-based financial products. Developers building on Arkade are exploring use cases ranging from retail payments and lending markets to cross-network settlement between blockchain systems. ‘Stablecoins were built on bitcoin’ The system also targets a category of emerging applications sometimes referred to as “autonomous commerce,” where software agents execute transactions on behalf of users. These models require strict spending rules and programmable controls to operate safely, features that Ark Labs believes Bitcoin-based infrastructure can support. Tether’s participation signals growing interest in expanding stablecoin activity around Bitcoin’s ecosystem. While stablecoins dominate trading and payments across many blockchains, their presence on Bitcoin has remained limited. “Stablecoins were born on Bitcoin, and expanding access on the Bitcoin network remains a priority for us,” said Paolo Ardoino, CEO of Tether. “Infrastructure that makes it easier to issue, move, and settle stablecoins directly on Bitcoin can support broader access to digital dollars.” For Ark Labs, the next phase centers on scaling the ecosystem around its platform. The company plans to use the new funding to expand its developer relations team, refine product tooling, and support partners building production-grade applications. “Every fintech building digital products faces the same question: whose infrastructure do you depend on?” said Alex Bergeron, head of ecosystem at Ark Labs. “On many networks that infrastructure is controlled by a single company. Our goal is to offer an open alternative built around Bitcoin.” As digital finance infrastructure continues to evolve, Ark Labs is betting that the demand for programmable tools will extend to the industry’s oldest blockchain. Whether developers choose to build there may determine how far that vision goes. This post Ark Labs Raises $5.2M with Tether to Bring Programmable Finance to Bitcoin first appeared on Bitcoin Magazine and is written by Micah Zimmerman.

CD182: ALEX B - ARKADE

Alex is Head of Ecosystem at Ark Labs. We discuss their new bitcoin payments protocol: Arkade. It can be used in combination with the lightning network to make self custody bitcoin usage more

God Defends His Honor

God Makes Himself Known, Part 2 (Phillistines)

Bitcoin Layer 2 Protocol Ark Making Progress

Slowly but surely, the layered stack being built on top of bitcoin matures.

Ark and Spark: The Channel Factories We’ve Been Waiting For

Bitcoin Magazine Ark and Spark: The Channel Factories We’ve Been Waiting For Visions of future technology are often prescient about the broad strokes while flubbing the details. The tablets in “2001: A Space Odyssey” do indeed look like iPads, but you never see the astronauts paying for subscriptions or wasting hours on Candy Crush. Channel factories are one vision that arose early in the history of the Lightning Network to address some challenges that Lightning has faced from the beginning. Despite having grown to become Bitcoin’s most successful layer-2 scaling solution, with instant and low-fee payments, Lightning’s scale is limited by its reliance on payment channels. Although Lightning shifts most transactions off-chain, each payment channel still requires an on-chain transaction to open and (usually) another to close. As adoption grows, pressure on the blockchain grows with it. The need for a more scalable approach to managing channels is clear. Channel factories were supposed to meet this need, but where are they? In 2025, subnetworks are emerging that revive the impetus of channel factories with some new details that vastly increase their potential. They are natively interoperable with Lightning and achieve greater scale by allowing a group of participants to open a shared multisig UTXO and create multiple bilateral channels, which reduces the number of on-chain transactions and improves capital efficiency. Achieving greater scale by reducing complexity, Ark and Spark perform the same function as traditional channel factories with new designs and additional capabilities based on shared UTXOs. Channel Factories 101 Channel factories have been around since the inception of Lightning. A factory is a multiparty contract where multiple users (not just two, as in a Dryja-Poon channel) cooperatively lock funds in a single multisig UTXO. They can open, close and update channels off-chain without updating the blockchain for each operation. Only when participants leave or the factory dissolves is an on-chain transaction needed. Channel factories offer a number of important advantages. By enabling multiple off-chain channels to be spun up from a single on-chain transaction, they dramatically reduce the load on the base chain. Participants can rebalance funds among themselves efficiently without needing to touch the chain at all: New channels can be created on demand inside the factory, with no cost beyond what was already paid at the factory’s creation. The ability to tweak the ratio of channels to on-chain transactions makes channel factories one of the most capital-efficient scaling approaches available for Lightning today. Still, it’s no coincidence that channel factories have largely remained on the drawing board despite their promise. A channel factory generally requires all participants to be online and cooperative to update its state, unless special arrangements or protocols are in place to handle asynchrony. For example, Lightning service providers (LSPs) can’t use channel factories to manage downstream channels with their users because all peers need to be known at the time the factory is created. Without a way to incrementally add peers to an existing factory, the model becomes impractical for nodes whose scalability is built into their business model, as is the case with LSPs. Moreover, handling exits from the factory, especially when participants are unresponsive or malicious, involves complex mechanisms that might require participants to pre-sign a large tree of potential exit transactions covering every possible combination of cooperative and uncooperative behavior. Imagine a five-person factory where one peer goes offline or rogue — each of the remaining peers would need pre-negotiated, pre-signed exit paths for every eventuality. Without automation or covenant support, managing this becomes a combinatorial and operational nightmare. These technical and UX constraints make it hard to deliver a seamless user experience or to scale such systems in production. We’ve seen several proposals to optimize channel factories since 2019, with continuing interest but little production deployment — until now. A Brief History of Channel Factory Proposals One early and very comprehensive proposal for channel factories came from Conrad Burchert, Christian Decker and Roger Wattenhofer in their 2017 paper, “Scalable Funding of Bitcoin Micropayment Channel Networks.” Their design allows a group of participants to lock funds in a single multiparty UTXO and open multiple channels off-chain between pairs of participants. Each state transition (channel open, close or rebalance) requires a complete set of presigned transactions. This ensures that every participant has a cryptographically secure way to exit the factory if needed. However, the Burchert-Decker-Wattenhofer construction has a serious scalability limitation: Any update to the factory state requires every participant to be online and sign off on the change. As the number of participants increases, the number of required signatures and pre-signed exit paths grows exponentially, as do the coordination overhead, the storage burden and the headaches. Efforts to improve on this model have leveraged newer Bitcoin features. Taproot simplifies the structure of exit transactions by allowing their conditions to be encapsulated in a Merkle tree of scripts, with only the spending path revealed at redemption. This reduces both transaction size and privacy leakage. OP_CHECKTEMPLATEVERIFY (OP_CTV), a proposed soft fork, would dramatically streamline factories by enabling precommitted exit paths without the need for exhaustive presigning. With OP_CTV, a factory could commit to a set of exit transactions at the time of creation. Each participant would know that they can unilaterally exit in a well-defined way, reducing both interactivity and operational complexity. Despite such progress, practical deployment has lagged. The barriers to full participant interactivity and complex signing schemes, especially in the absence of OP_CTV, are simply too high. Ark and Spark: Next-Generation Channel Factories Two recent projects, Ark and Spark, reimagine the channel factory with different trade-offs. While neither project explicitly markets itself as a “channel factory,” their architectures effectively realize many of the goals that early channel factory proposals aimed for. Since both are based on a shared UTXO and both are natively compatible with Lightning, Spark and Ark represent modern incarnations of channel factories that leverage today’s tooling and assumptions. At last! Both aim to preserve the benefits of channel factories (reduced chain usage, scalable liquidity allocation) while resolving key weaknesses around liveness, interactivity and exit complexity. Most importantly, both projects take a pragmatic approach to scaling. They work within Bitcoin’s current consensus rules, avoiding the need for soft forks or new opcodes to be useful today. UTXO Sharing Ark introduces a UTXO-sharing model built around the concept of virtual UTXOs (VTXOs). Instead of assigning users individual on-chain outputs, Ark lets them transact off-chain using a shared pool of liquidity managed by an Ark server. Users transact by requesting that a new distribution of VTXOs be included in the next round, when the Ark server creates an “Ark block” aggregating recent user activity and posts a new shared UTXO to the blockchain. So Ark lets users pass VTXOs among themselves and periodically settle the distribution of VTXOs in the shared UTXO via batched anchor transactions on the blockchain. Users can also perform out-of-round transactions, which instantly move VTXOs between users without waiting for the next round of anchor transactions. In this case, the Ark server co-signs the out-of-round payment, which may be compromised if the Ark server and the sender collude to double-spend the VTXO. However, the receiver can decide whether to accept the risk on the basis of the Ark server’s reputation and take the funds immediately, or to wait until the next round. Spark takes a different path to shared UTXOs that builds on the concept of statechains. The fulcrum of Spark’s shared signing protocol is the Spark Operators (SOs), who come together in a consortium called a Spark Entity (SE). When a user joins Spark, they deposit funds into a shared-signature address controlled by themselves and the SE. The SE and the user pre-sign a withdrawal transaction, ensuring that the user can always exit unilaterally. A payment occurs whenever a new withdrawal transaction appears, which creates a new current state. Over time, the history of transactions takes on a tree structure, branching off from the original shared UTXO, and each terminal transaction owned by a user is called a “leaf.” Naturally, after each change, the SOs must delete past keys used for the past owner (i.e., pruning old leaves), and only one of the SOs in the SE must do so for the system to work securely. This allows Spark to offer trust-minimized, self-custodial off-chain payments while keeping the base UTXO unchanged. Like Ark, Spark also introduces some new assumptions about trust. Spark requires at least one SO (or some higher configurable threshold) in the SE to act honestly and delete outdated withdrawal transactions. The result is a “moment-in-time” trust model, in which trust is only required at the time of transfer: The system maintains perfect forward security as long as operators delete their key shares after a transfer. Once the keys are deleted, even a compromised or malicious operator cannot retroactively affect past transactions or steal funds, and a deletion by any SO counts for all the SOs in the SE, distributing responsibility among multiple operators. Lightning Interoperability To interop with Lightning, both Spark and Ark rely on swaps facilitated by LSPs. These LSPs must participate in a given Ark or Spark Entity to act as bridges: They execute Lightning payments on behalf of users in exchange for the assets inside the respective systems — VTXOs in Ark and leaves in Spark. The process is secured by atomicity: The LSP only receives the VTXO or leaf once it can prove that the Lightning payment has been successfully completed by providing a preimage. This allows users to make Lightning payments without operating a Lightning node themselves, and it anchors both systems firmly into the broader Lightning ecosystem. If It Walks Like a Duck… Channel factories increase scale by leveraging shared UTXOs to amplify Lightning’s scalability. By that measure, Ark and Spark are unequivocally channel factories, albeit sporting the latest fashions in VTXO and statechain technology. Given what shared-UTXO models like these are already achieving, we can expect great things from the channel-factory labs in the near future — especially if new opcodes are added to L1. Both Ark and Spark are significant achievements in themselves, but they also both validate Lightning. Without being able to interoperate with other subnetworks — Liquid, Fedimint, Cashu, etc. — these revamped channel factories would be far less valuable. And it’s Lightning that lets them interoperate virtually anywhere bitcoin can go. The emergence of Spark and Ark is not a sign of Lightning’s limits but of its indispensability in today’s Bitcoin economy. Don’t miss your chance to own The Lightning Issue — featuring an exclusive interview with Lightning co-creator Tadge Dryja. It dives deep into Bitcoin’s most powerful scaling layer. Limited run. Only available while supplies last. This piece is an article featured in the latest Print edition of Bitcoin Magazine, The Lightning Issue. We’re sharing it here to show the ideas explored throughout the full issue. This post Ark and Spark: The Channel Factories We’ve Been Waiting For first appeared on Bitcoin Magazine and is written by Roy Sheinfeld.

Bitcoin’s First Major Layer-2 in Nearly a Decade Goes Live With Arkade

Bitcoin Magazine Bitcoin’s First Major Layer-2 in Nearly a Decade Goes Live With Arkade Bitcoin may be the world’s most secure digital asset, but for years its base layer has limited the kinds of financial applications developers could build on it. That changes with the launch of Arkade, the first significant Bitcoin layer-2 solution since the Lightning Network nearly a decade ago. Developed by Ark Labs, the protocol enters public beta with a bold mission: to turn Bitcoin into a programmable financial platform without compromising the security that has made it “digital gold,” according to a note shared with Bitcoin Magazine. Arkade builds on the Ark protocol, first introduced two years ago, which promised a new way to scale Bitcoin while unlocking new applications. The launch also introduces Arkade Assets, a native multi-asset framework designed to bring stablecoins and other tokens to Bitcoin’s execution layer, including planned support for Tether (USDT). For an ecosystem long dominated by Ethereum and other chains when it comes to decentralized finance, this is a notable step toward putting advanced financial tools back on Bitcoin. “The Bitcoin L2 landscape has been full of promises but light on shipping,” said Marco Argentieri, CEO of Ark Labs. “Today’s release marks the beginning of Bitcoin’s evolution as programmable money.” Technical and cultural Bitcoin norms The challenge Ark Labs is addressing is both technical and cultural. Bitcoin’s base layer is intentionally conservative, prioritizing security and censorship resistance over complex programmability. While Lightning offered off-chain payments, other financial applications — lending, trading, or structured derivatives — required workarounds such as wrapped tokens or custodial platforms. Arkade attempts to take a different approach: instead of altering Bitcoin’s consensus rules or creating separate chains, it virtualizes Bitcoin’s UTXO-based transaction system, preserving its security while enabling new capabilities. Developers can now build sophisticated financial applications directly on Bitcoin: lending protocols, trading platforms, smart wallets, and yield products — all without relying on bridges or compromising user control. User assets remain secured by presigned transactions, meaning funds can always be reclaimed on-chain if needed. Arkade’s technical innovations include Virtual Transaction Outputs (VTXOs) for instant off-chain execution, batch settlement to compress thousands of operations into a single Bitcoin transaction, and integration with the Lightning Network through Boltz to facilitate liquidity swaps. Initial launch partners include Breez, BlueWallet, BTCPayServer, and exchanges like BullBitcoin and LayerZ Wallet (builders of BlueWallet), according to the note. Stablecoins on Bitcoin? For the Bitcoin community, the launch signals more than just another protocol. It represents a turning point in the narrative around Bitcoin as money versus Bitcoin as programmable infrastructure. Stablecoins, which have largely migrated to Ethereum and other chains, may find a secure home on Bitcoin. For users, this could mean safer, more efficient ways to manage digital assets and access financial services without leaving the Bitcoin ecosystem. “Arkade isn’t just a product launch; it’s the foundation for the next decade of Bitcoin development,” said Alex Bergeron, Ark Labs’ Ecosystem Lead. “Every major financial application needs a programmable foundation. That’s what we’re building.” This post Bitcoin’s First Major Layer-2 in Nearly a Decade Goes Live With Arkade first appeared on Bitcoin Magazine and is written by Micah Zimmerman.

Bark