Ark vs Spark: Bitcoin L2 Protocol Comparison
Compare Ark and Spark protocols for Bitcoin scaling, analyzing trust models, transaction speed, self-custody, and UX.
Ark vs Spark: Overview
Ark and Spark are two next-generation Layer 2 protocols designed to scale Bitcoin beyond what Lightning channels alone can achieve. Both eliminate the need for users to manage channel liquidity, open payment channels, or stay online to receive funds. They take fundamentally different architectural approaches: Ark uses virtual UTXOs (vTXOs) coordinated by an Ark Service Provider, while Spark uses statechains enhanced with FROST threshold signatures.
The following table provides a high-level comparison across the dimensions that matter most for developers and users evaluating these protocols.
| Feature | Ark | Spark |
|---|---|---|
| Architecture | Virtual UTXOs + ASP coordination | Statechains + FROST threshold signing |
| Trust model | ASP cannot steal; OOR payments trust sender+ASP honesty | 1-of-n operator honesty (key deletion) |
| Transaction speed | OOR: instant; In-round: 10+ min | Instant (sub-second) |
| Unilateral exit | Log₂(n) on-chain transactions | 1-2 on-chain transactions |
| Stablecoin support | Not yet | USDB (live since January 2026) |
| Mainnet status | Public beta (October 2025) | Mainnet beta (April 2025) |
| Lightning interop | Via atomic swaps (Boltz) | Via SSPs (send and receive) |
| Channel management | None required | None required |
| Operator set | Single ASP per user | Distributed (currently 3 operators) |
| Covenant requirement | Works without; benefits from OP_CTV | None |
For a comparison of Ark against the Lightning Network specifically, see our Lightning vs Ark comparison tool.
How Ark Works
Ark was proposed by Burak Keceli in May 2023 as a way to scale Bitcoin by pooling multiple users into shared on-chain UTXOs and issuing virtual UTXOs (vTXOs) that can be transferred off-chain. An Ark Service Provider (ASP) coordinates periodic "rounds" where multiple user transactions are batched into a single on-chain output structured as a Taproot tree.
Each vTXO leaf in the tree encodes a 2-of-2 condition: the user's key and the ASP's key must cooperate to spend, or the user can spend unilaterally after a timelock expires. Connector outputs in each round ensure atomicity: a user's forfeit transaction (surrendering the old vTXO) is only valid if the round transaction confirms on-chain.
Users can also make instant "out-of-round" (OOR) payments between rounds. These are co-signed by the ASP and settle in milliseconds, but carry a weaker trust model because they rely on the assumption that the sender and ASP will not collude to double-spend.
The current implementations use "clArk" (covenant-less Ark), which replaces proposed opcodes like OP_CTV with pre-signed transactions and MuSig2 multi-signatures. This allows Ark to run on Bitcoin today without any soft fork, but requires all vTXO holders in a round to be online during round construction.
How Spark Works
Spark is built on statechains, a concept introduced by Ruben Somsen in 2018, enhanced with a distributed operator set using FROST threshold signatures. Bitcoin is locked into a 2-of-2 multisig output where one key belongs to the user and the other is collectively held by the Spark Operators (SOs) via FROST Distributed Key Generation.
When a transfer occurs, the Bitcoin remains in the same on-chain address. The operators generate new FROST key shares for the recipient and destroy the old shares, so previous owners lose cryptographic access. Spark introduces a "leaf" architecture that allows partial balance transfers: leaves can split and merge instantly for arbitrary-amount payments without any blockchain interaction.
Spark currently operates with three operators: Lightspark, Flashnet, and Breez. Each operator holds a FROST key share, and a threshold must cooperate with the user to authorize any transaction. On-chain, this produces a standard Schnorr signature that reveals nothing about the multi-party structure underneath.
Trust Models Compared
The trust model is the most consequential difference between these two protocols.
Ark's Trust Model
The ASP never takes custody of user funds. Users hold pre-signed transactions that enable unilateral on-chain exit at any time. For in-round transactions where the round confirms on-chain, Ark provides Bitcoin-grade finality: the settlement is as strong as any on-chain transaction.
Out-of-round (OOR) payments introduce a weaker guarantee. The recipient must trust that the sender and ASP will not collude to double-spend the vTXO. As long as either the sender or the ASP is honest, the payment is secure. Chaining multiple OOR payments amplifies this risk, since any sender in the chain could collude with the ASP. Users can eliminate this risk by refreshing vTXOs in a subsequent round.
Spark's Trust Model
Spark operates on a 1-of-n honesty assumption: as long as one single operator in the set behaves honestly and deletes their old key share after a transfer, no previous owner can reclaim the funds. The operators cannot cryptographically prove that key deletion occurred. Finality is real but unprovable: if all operators colluded with a previous sender, they could theoretically reconstruct the old key and double-spend.
This is a meaningful departure from Bitcoin's on-chain mathematical certainty, but it is comparable to the trust assumptions in other widely used systems like Fedimint and some sidechains. The distributed operator set (currently three independent entities) makes collusion harder than in a single-operator model.
Transaction Speed and Finality
Both protocols offer instant off-chain transfers, but the finality guarantees differ significantly.
Ark's OOR payments settle in milliseconds but depend on the sender-ASP honesty assumption described above. For trustless finality, users must wait for the round transaction to confirm on-chain (at least 10 minutes for one block confirmation, with some implementations targeting one-hour round intervals). Full trustless finality requires a two-round process: swapping a vTXO from one confirmed round into a new round, meaning two confirmation cycles.
Spark transfers settle in sub-second time with no on-chain confirmation required. Every transfer has the same finality guarantee (the 1-of-n operator honesty assumption). There is no distinction between "fast but weak" and "slow but strong" settlement modes. Spark-to-Spark transfers currently incur no fees, though Lightspark has indicated a small flat fee will be introduced.
Self-Custody and Unilateral Exit
Both protocols preserve self-custody: users hold the cryptographic keys needed to withdraw their funds to Layer 1 Bitcoin without any counterparty's cooperation.
Ark's unilateral exit requires broadcasting each branch transaction down the Taproot tree from root to the user's specific leaf, waiting for each to confirm, then broadcasting a claim transaction after a relative timelock expires. For a tree containing 1,024 vTXOs, this means approximately 10 sequential on-chain transactions. Small-value vTXOs may be uneconomical to exit during periods of high on-chain fees.
Spark's exit process is simpler. A cooperative exit (where the operators are responsive) requires a single on-chain transaction. A unilateral exit (when operators are unavailable) involves broadcasting a pre-signed branch transaction, waiting for a relative timelock, and then broadcasting the exit transaction: typically two on-chain transactions total.
Ark vTXOs also carry an expiration period (typically 30 days). Users must come online to refresh their vTXOs before expiry or risk losing access. Spark leaves have no such expiration requirement.
Liquidity and Capital Requirements
Ark's ASP faces significant capital requirements. When constructing a round, the ASP must front the entire value of all new vTXOs from its own capital. It recovers this capital only when old vTXOs expire (typically 30 days later) or when users forfeit old vTXOs in subsequent rounds. An ASP serving 10,000 users with average balances of 100,000 sats would need roughly 10 BTC in active liquidity, plus reserves for overlapping round windows. This cost is passed to users as fees.
Spark has no equivalent liquidity requirement for operators. Because transfers work by re-keying existing on-chain UTXOs rather than creating new outputs, the operator set does not need to front capital. Users do not need inbound liquidity to receive payments, which removes one of Lightning's most persistent UX friction points.
Token and Stablecoin Support
Spark natively supports tokens through its BTKN standard, an adaptation of the LRC-20 protocol. The most notable token on Spark is USDB, a regulated, USD-backed stablecoin issued by Brale (a FinCEN-registered Money Services Business). USDB launched on January 21, 2026 and is backed 1:1 by US Treasury bills and cash equivalents with monthly third-party audits.
Ark does not currently support native token issuance. ASP-coordinated rounds are designed around Bitcoin-denominated vTXOs. Adding token support would require extending the protocol's transaction format and tree structure. For users who need dollar-denominated balances on Bitcoin, this is a significant differentiator.
Developer Experience
Both protocols offer SDKs for building applications, though they are at different levels of maturity.
| Dimension | Ark (Arkade) | Spark |
|---|---|---|
| Primary language | Go (server), with TS/Rust SDKs | TypeScript, Kotlin, Swift SDKs |
| Mobile SDKs | FFI bindings (via Second/Bark) | Native Kotlin (Android) + Swift (iOS) |
| Open source | Yes (Arkade + Bark) | Yes (github.com/buildonspark) |
| Self-hosted operator | Yes (run your own ASP) | Not yet (3 fixed operators) |
| Lightning integration | Via Boltz atomic swaps | Native send/receive via SSPs |
| Testnet support | Regtest, testnet3, signet | Regtest, testnet |
| Wallet integrations | Breez, BlueWallet, BTCPayServer, BullBitcoin | Wallet of Satoshi, Breez, Polymarket |
| Production readiness | Alpha/beta (v0.9.x) | Mainnet beta |
Ark offers more flexibility for infrastructure operators who want to run their own ASP. Spark provides a more polished developer experience for application builders who want to integrate payments without managing protocol-level infrastructure. Spark's documentation and SDKs are designed for rapid integration by wallet and application developers.
How Both Solve Lightning's UX Problems
The Lightning Network has well-documented UX challenges: users must open and fund channels, manage channel balances, secure inbound liquidity to receive payments, and stay online to detect fraud. Both Ark and Spark address these issues, but through different mechanisms.
- Channel management: neither protocol requires users to open, close, or rebalance payment channels. Users hold balances (vTXOs in Ark, leaves in Spark) without channel state management.
- Inbound liquidity: Lightning requires a counterparty to commit funds in a channel toward you before you can receive. Neither Ark nor Spark has this requirement.
- Offline receiving: Spark supports receiving payments while offline through SSPs that hold payments conditionally. Ark's OOR payments can target offline users, though round participation requires being online.
- Onboarding: both protocols simplify onboarding compared to Lightning, where new users face the "empty channel" problem. Ark onboarding requires a single on-chain deposit. Spark onboarding requires depositing Bitcoin into a 2-of-2 multisig.
Neither protocol replaces Lightning entirely. Both maintain Lightning interoperability: Ark routes Lightning payments through the ASP, while Spark uses SSPs for atomic swaps between Spark and Lightning. The practical effect is that users of either protocol can pay any Lightning invoice without managing channels or liquidity directly.
When to Choose Ark vs Spark
The right protocol depends on what you prioritize.
Choose Ark if you need to run your own infrastructure. Ark allows anyone to operate an ASP, making it a better fit for businesses that want full control over their payment infrastructure. Ark's in-round transactions also achieve on-chain-grade finality without relying on operator honesty, which matters for high-value settlement use cases.
Choose Spark if you need instant payments, stablecoin support, or the simplest integration path. Spark's sub-second finality, native USDB stablecoin support, and polished SDKs make it the stronger choice for consumer wallets, merchant payments, and applications that need dollar-denominated balances on Bitcoin. Spark's simpler unilateral exit (two on-chain transactions vs. Ark's logarithmic tree traversal) also reduces worst-case recovery costs.
For applications that need both Bitcoin and stablecoin payments with Lightning interoperability, Spark's combination of instant settlement, USDB support, and native Lightning bridging provides the most complete solution today. Explore the Spark developer documentation to get started.
Frequently Asked Questions
Is Ark or Spark more trustless?
Ark's in-round transactions achieve fully trustless finality once the round confirms on-chain, making them equivalent to a regular Bitcoin transaction. Spark relies on a 1-of-n operator honesty assumption: finality is real but depends on at least one operator honestly deleting old key shares. Ark's OOR payments, however, carry a similar trust assumption to Spark (honest sender or honest ASP). In practice, both protocols involve trust tradeoffs depending on which payment mode is used.
Do Ark and Spark require a Bitcoin soft fork?
Neither protocol requires a soft fork to operate today. Ark uses the "clArk" approach with pre-signed transactions and MuSig2 instead of covenants. Spark uses FROST threshold signatures and standard Taproot transactions. That said, Ark would benefit significantly from OP_CTV: it would enable non-interactive vTXO creation, eliminate the requirement for all participants to be online during rounds, and allow automatic vTXO refresh by the server.
Can I use stablecoins on Ark or Spark?
Spark supports USDB, a regulated USD-backed stablecoin that launched in January 2026. USDB enables instant, near-zero-fee dollar payments on Bitcoin without bridging to another chain. Ark does not currently support stablecoins or custom token issuance. For more on Bitcoin-native stablecoins, see our stablecoin comparison tool.
What happens if Ark or Spark operators go offline?
In both protocols, operator downtime halts new off-chain transfers but does not put user funds at risk. Ark users can exit by broadcasting pre-signed transactions through the Taproot tree (requiring multiple sequential on-chain confirmations). Spark users can exit by broadcasting pre-signed branch and exit transactions (typically two on-chain transactions). In both cases, funds remain under user control via self-custody guarantees.
How do Ark and Spark handle privacy?
Ark provides some privacy improvement over on-chain transactions because vTXOs are off-chain, but the ASP sees all transactions it co-signs. Spark faces similar limitations: all operators gain full transaction visibility, and current implementations publish data to public explorers. Both protocols plan to improve privacy. Ark benefits from the fact that round transactions bundle many users into a single on-chain output. Spark has announced plans for blind signing and confidential amounts in future releases.
Can Ark and Spark interoperate with each other?
Not directly. An Ark user cannot send a vTXO to a Spark user or vice versa. However, both protocols interoperate with the Lightning Network, which serves as a common bridging layer. An Ark user can pay a Lightning invoice generated by a Spark user (and the reverse), making the two ecosystems indirectly compatible through Lightning as an intermediary.
Which protocol has more adoption?
Spark has broader adoption as of mid-2026. It launched on mainnet in April 2025, has over 20 integrations including Polymarket and Wallet of Satoshi, and supports a live stablecoin (USDB). Ark's Arkade implementation entered public beta in October 2025 with integrations from Breez, BlueWallet, and BTCPayServer. Ark processed over 1,300 payments at Baltic Honeybadger 2025, demonstrating real-world viability, but its ecosystem is still earlier-stage compared to Spark.
This tool is for informational purposes only and does not constitute financial advice. Protocol details are based on publicly available documentation and may change as both Ark and Spark continue active development. Always verify current specifications in the official documentation before making technical or financial decisions.
Build with Spark
Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.
Read the docs →
