Ark users are always in control of their bitcoin. They can perform an emergency exit to get back on-chain whenever they need to. But Bark is a client-server system, and users depend on the server to make payments and refresh their VTXOs before expiry. Careful engineering, rigorous code review, and thorough testing go a long way, but we wanted to go further, so we've started fuzzing Bark.

Sniper vs. shotgun

Traditional testing is targeted: you write tests for bugs you can anticipate. Fuzzing casts a wider net, using different strategies to generate semi-random inputs that surface bugs you'd never think to look for.

VTXO roundtrip: deserialize, serialize, repeat

We use Honggfuzz, a coverage-guided fuzzer that instruments the binary and systematically explores code paths. We built two helper scripts around it: fuzz.sh to run targets, and debug.sh to analyze crashes when they're found.

Our first fuzz target is a VTXO roundtrip test. Feed generated inputs into the VTXO deserializer, and if it parses successfully, re-serialize and deserialize again, then check the results match. Any crash, memory issue, assertion failure, or resource exhaustion at any step is a bug.

fn do_test(data: &[u8]) {
    let result: Result<Vtxo<ServerVtxoPolicy>, ProtocolDecodingError> =
        Vtxo::deserialize(&mut data.as_ref());

    if let Ok(vtxo) = result {
        let serialized = vtxo.serialize();

        let vtxo2: Vtxo<ServerVtxoPolicy> =
            Vtxo::deserialize(&mut serialized.as_slice())
                .expect("re-serialization should succeed");

        let serialized2 = vtxo2.serialize();
        assert_eq!(
            serialized, serialized2,
            "serialization should be deterministic"
        );
    }
}

Unchecked allocation crashes the decoder

It paid off quickly. Fuzzing found a bug where a malformed VTXO could claim an arbitrary vector length during deserialization. The decoder would call Vec::with_capacity with whatever size the input specified, causing a capacity overflow panic. A single crafted request could have brought down the server.

Stable Rust doesn't yet offer try_with_capacity to handle this natively, so we added an explicit check. We introduced a MAX_VEC_SIZE of 4 MB (borrowing rust-bitcoin's approach) and a guard that runs before every vector allocation during decoding:

pub const MAX_VEC_SIZE: usize = 4_000_000;

impl OversizedVectorError {
    pub fn check<T>(requested: usize) -> Result<(), Self> {
        let max = MAX_VEC_SIZE / mem::size_of::<T>();
        if requested > max {
            Err(Self { requested, max })
        } else {
            Ok(())
        }
    }
}

The decoder now returns a clean error instead of panicking. Without fuzzing, this would have gone unnoticed until someone exploited it.

Continuous fuzzing and public test vectors

We have a fuzzer running around the clock and we're setting up a workflow to routinely push minimized corpora to our bark-qa repo, which also holds test vectors used throughout Bark's development.

More targets are on the way: dedicated serialization/deserialization targets for every protocol message type, then "getter" targets that fuzz method calls on deserialized types to catch errors beyond encoding.

Your bitcoins are safe by protocol design. We're making sure the infrastructure is just as solid.

Follow us on X or sign up to our newsletter to keep up with Bark development.

hArk (hash-lock Ark), first described in a Delving Bitcoin post, and shipped in v0.1.0-beta.6 is an update to our implementation of the Ark protocol that fundamentally changes how rounds are constructed. Forfeits are now dependent on hash-locks instead of connectors, and are signed after the round's funding transaction is broadcast, not before.

hArk makes it much easier to develop mobile apps on Bark by enabling delegated refreshes, required because mobile devices can't be reliably woken up to participate in the round signing process. Delegated refreshes come with some security trade-offs compared to standard self-signed refreshes, but don't worry, self-signed refreshes remain the default trust model, it's still the same protocol.

In all honesty, we hesitated implementing hArk because we knew this would delay our mainnet launch. But it was always going to be necessary, and retrofitting a new round model after users and integrators had already built on the old one would have been far more painful than launching with it. Now that it's in, we're glad we did—we want Bark to be mobile-friendly from day one.

How rounds worked: forfeit, then broadcast

In the Ark protocol, users must periodically refresh their Ark balances, forfeiting old VTXOs and receiving new ones in a single atomic operation.

In classic Ark, the round followed this sequence:

1. Submit request: Users tell the server which VTXOs they want to refresh.
2. Tree construction and cosigning: The server builds a funding transaction and a transaction tree containing all new VTXOs. Users cosign the tree.
3. Forfeit signing: Users sign forfeits for their old VTXOs.
4. Broadcast: The server broadcasts the funding transaction.

Forfeits were made conditional through connectors, dust-valued outputs from the funding transaction that the forfeit consumed as an input. If the funding transaction wasn't on-chain, the connector didn't exist, and the forfeit couldn't be spent. But this conditionality only worked in one direction: the forfeit depended on the funding transaction, but nothing made the new VTXOs depend on the forfeit. So the server had to collect every forfeit signature before broadcasting.

This model worked fine for always-on desktop clients, but mobile operating systems, particularly iOS, can struggle to reliably wake devices to participate in the interactive round process. To make mobile apps viable, we needed a way for mobile apps to refresh without users having to participate in the interactive round process. The only way to solve this without covenants was for a set of distributed cosigners to sign refreshes on users' behalf, for them to claim later (a "delegated refresh", more on this later). But with forfeits baked into the interactive round, this wasn't possible—forfeit signatures require the user's private key, and sharing that with third-party cosigners is a non-starter. We needed to get the forfeit step out of the round entirely and make it asynchronous.

How rounds work now: broadcast, then forfeit

Connectors weren't going to cut it, so we went back to the drawing board and landed on hash-lock preimages—the same cryptographic mechanism already proven in the Lightning Network. Hash-locks gave us the two-way conditionality we were missing: new VTXOs depend on forfeits and forfeits depend on new VTXOs, allowing us to move the forfeit step out of the interactive round entirely.

In hArk (hash-lock Ark), steps 3 and 4 are swapped, and step 4 can be performed outside the round window:

1. Submit request: Users tell the server which VTXOs they want to refresh.
2. Tree construction and cosigning: The server builds a funding transaction and a transaction tree containing all new VTXOs. Users cosign the tree.
3. Broadcast: The server broadcasts the funding transaction.
4. Forfeit signing: Users sign forfeits for their old VTXOs at their convenience. The server reveals a preimage after receiving each user's forfeit signature.

With the forfeit step decoupled from the round, delegated refreshes became possible. Cosigners can now pre-sign a mobile user's branch of the tree during the round, and the user's wallet collects the signed transactions later when it's next active—no need to wake the device during the round itself. We'll cover the mechanics of delegated refreshes in detail below.

Another valuable byproduct was a reduction in the DoS surface of rounds—one user's failure to sign their forfeit no longer stalls everyone else, making rounds that bit more reliable for wallet developers and users.

How hash-lock forfeits work

The two-way dependency works through a single secret: the exit transaction of each VTXO in the transaction tree is locked behind a preimage p that only the server knows, and the server only reveals p after receiving a signed forfeit. The server can safely broadcast first because users can't access their new VTXOs without p. When a user signs their forfeit, the server reveals p, which simultaneously activates the user's new VTXO and gives the server the ability to claim the old one.

The forfeit is a two-step process:

1. The user signs a forfeit transaction that moves their old VTXO into a forfeit output, locked by the preimage on one spend path and timeout on the other.
2. The server now holds a signed forfeit transaction. If the user ever tries to unilaterally exit the old VTXO on-chain, the server can broadcast the forfeit and claim the funds by revealing the preimage.

If the server refuses to reveal p, the user's bitcoin is still safe. They can initiate an exit of their old VTXO on-chain, and one of two things happens:

• The server does nothing, and the user reclaims their bitcoin after the timeout delta.
• The server broadcasts the forfeit claim, which reveals p on-chain. The user then uses that p to activate their new VTXO from the tree leaf.

Either way, the user cannot lose bitcoin.

Delegated refreshes: a new mode for mobile

By default, refreshes in hArk are still self-signed: you cosign every transaction in your branch of the tree yourself. These pre-signed branch transactions form your unilateral exit path—if you ever need to bring your VTXO on-chain without the server's cooperation, you broadcast this chain of transactions from the tree root down to your leaf. This is the strongest security model—you trust no one—but it requires being online during the round to cosign. For mobile operating systems that can't reliably wake to participate, hArk introduces delegated refreshes.

In delegated mode, a set of cosigners pre-sign the user's branch transactions during the round instead. When the user's wallet is next active, it collects the fully-signed branch transactions from the server—giving the user the same unilateral exit path as in self-signed mode—and completes the forfeit of their old VTXO. The server then reveals the preimage, activating the new VTXO in the tree.

All cosigners would need to collude to compromise a user's VTXO, and the larger the cosigner set, the harder this becomes. As an additional safeguard, cosigners automatically delete signing keys after each round, providing forward security: if a cosigner is operating correctly during the round but compromised later, the key deletion ensures that VTXOs from that round remain secure. As long as at least one cosigner's software is operating correctly during the round, collusion is impossible.

The two refresh modes aren't mutually exclusive. Any wallet app could offer both, using whichever is appropriate based on connectivity. Or a wallet installed on multiple devices could have a desktop handle all refreshes, with the mobile app's delegated refreshes reserved only as a failsafe. And users who delegate a refresh can always self-sign a refresh later, returning to the fully trustless model.

However, be aware that currently, the only cosigner is the server itself. Releasing cosigning software that enables other entities to participate is a top priority for us after mainnet launch.

A stepping stone to covenants

Most of the existing bitcoin covenant proposals would enable us to enforce Ark's tree structure without the need for pre-signed transactions. Users would get the best of both worlds: the trustlessness of self-signed refreshes with the asynchronous convenience of delegated ones. They'd still need to come online regularly to complete forfeits, but they wouldn't need to be responsive at the moment of the round.

The beauty of hArk's design is that it maps almost directly onto a covenant-based Ark. The hash-lock forfeit mechanism, the tree structure, and the round flow would all remain the same. So if we ever get covenants on bitcoin (a man can dream) the transition from hArk should be smooth, with minimal disruption to existing integrators and users.

Available now in Bark

hArk is implemented today in Bark—try it on signet. And get signed up to our newsletter to be the first to hear about more Second updates.

We've redesigned how Bark wallets receive updates from the Ark server. The new unified mailbox gives developers a single, efficient feed for all wallet notifications—Lightning payments, Ark payments, and refreshes—instead of requiring separate queries for each address. This simplifies app integrations and scales to high transaction volumes without adding latency.

The sync problem

Most bitcoin wallets rely on Electrum or Esplora to monitor on-chain activity. These backends work by querying each address individually to check for new transactions, balance changes, and payment confirmations. For on-chain bitcoin, this approach works well enough because most users don't generate that many addresses or transactions.

Ark changes this equation. The protocol is designed for frequent, low-cost payments across Ark, Lightning, and on-chain, which means wallets need to track a higher volume of activity. On top of payments, wallets also need to monitor refreshes (both standard and delegated) and other state changes. Each of these creates notifications that the wallet needs to receive.

If a wallet queried each address individually—the traditional approach—sync times would grow with every new address. A wallet with thousands of addresses would need thousands of requests just to check for updates. For developers building on Ark, this creates two problems: latency that degrades the user experience, and complexity from having to aggregate multiple notification streams into a coherent wallet state.

One endpoint for everything

The unified mailbox consolidates all notifications into a single feed. Instead of querying each address, the wallet makes one request to its mailbox and receives everything: incoming Ark payments, Lightning preimages, BOLT-12 offers, and refresh completions. This scales from one address to thousands with no additional overhead.

The wallet stores a checkpoint locally, so subsequent syncs only fetch what's new since the last check:

let mailbox_req = MailboxRequest {
    unblinded_id: mailbox_id.to_vec(),
    authorization: None,
    checkpoint,
};
let messages = mailbox_client.read_mailbox(mailbox_req).await?;

(Auth coming soon!)

If you've already processed messages up to checkpoint 42, your next request starts at 43. This makes incremental sync efficient regardless of how much activity the wallet has seen historically.

Privacy and blinding

Each Ark address a wallet generates includes delivery information that tells senders where to post payments. This delivery information contains a "blinded" mailbox ID—a cryptographic transformation of the wallet's actual mailbox identifier.

The blinding uses the VTXO keypair specific to each address, which means every address produces a different blinded ID even though they all route to the same underlying mailbox. When a sender pays to an address, their wallet extracts this blinded ID and posts the VTXO to the server. The server then unblinds it to route the notification to the correct mailbox.

let blinded_id = mailbox_id.to_blinded(server_pubkey, &vtxo_keypair);

This design creates a privacy trade-off that wallet implementations can choose:

• Fast sync (Bark's default): One mailbox per wallet. Senders only see different blinded IDs for each address, so they cannot tell that two addresses belong to the same person. The server, however, can unblind and link all your addresses internally.
• Maximum privacy: The protocol supports using a different mailbox keypair for every address. This prevents even the server from linking your activity, at the cost of slower sync since each mailbox must be queried separately.

Real-time notifications

Beyond checkpoint-based polling, the mailbox supports subscriptions that push notifications to the wallet the moment they arrive:

let stream = mailbox_client.subscribe_mailbox(mailbox_req).await?;

This is particularly important for mobile wallets, where a responsive payment experience depends on immediate feedback. When a payment arrives or a refresh completes, the wallet knows instantly rather than waiting for the next poll interval.

For Lightning receive, real-time notifications become critical. When an incoming Lightning payment targets your wallet, the mailbox notifies you so your wallet can wake up, request the HTLCs, and reveal the preimage to claim the funds. Unlike Ark payments, Lightning has timeouts—if your wallet doesn't respond before the HTLC expires, the payment fails. Polling intervals aren't reliable enough for this; you need the push.

Mobile devices can't maintain persistent WebSocket connections because the OS kills background processes to save battery. To solve this, you can authorize a third party—such as your wallet provider's notification service—to watch your mailbox on your behalf:

let expiry = chrono::Local::now() + Duration::from_secs(3600);
let authorization = MailboxAuthorization::new(&mailbox_keypair, expiry);

The authorization has an expiry you control. The third party can monitor for incoming payments and send push notifications to wake your app, but only for the duration you've permitted.

The unified mailbox is available now in Bark. See merge request !1412 for implementation details.

We're funding a year-long grant for Beulah Evanjalin to implement nested MuSig in libsecp256k1-zkp. This is a joint effort between Beulah, Second, and Vora, with Jesse Posner providing weekly mentorship throughout the project.

Nested MuSig is a key dependency for us improving the security of Ark server funds, but the implementation will be open source and it’ll support many other great use-cases for the wider ecosystem. For instance, Vora needs it to support their cold storage-to-Lightning payments.

Improving Bark security with nested MuSig

In Bark, our implementation of the Ark protocol, an Ark server holds a single master key to cosign transactions in the protocol. To improve security, we’d prefer to distribute the key with multisig, but Bark’s use of pre-signed transaction trees makes that impossible with current MuSig implementations. 

What we need is nested MuSig—a way to nest multiple sub-keys under one MuSig key.

That capability doesn't exist in the libsecp library yet—bitcoin’s most secure, well-reviewed, and trusted cryptographic library—and requires some serious expertise to get done. 

Deep cryptography requires deep expertise

With impeccable timing, Jesse Posner, founder of Vora, approached us with a proposal. He'd been working on nested MuSig security proofs with Nadav Kohen, who recently joined Chaincode Labs, and he had a candidate who could do the implementation: Beulah Evanjalin, an open-source developer he'd been mentoring for several months.

Vora needs nested MuSig for their Lightning implementation too, so this work would serve both projects. Jesse offered to provide weekly mentorship throughout the grant. We'd provide the majority of funding. Beulah would build the implementation. It sounded like a great team up and we agreed!

Beulah's work in secp256k1-zkp

Beulah is already contributing to secp256k1-zkp, which is exactly where this implementation needs to live. She recently completed Chaincode Labs' secp256k1 workshop in Portugal, where she met the libsecp contributors and maintainers. She's active in the #secp256k1 IRC channel and has relevant PRs merged into the codebase.

Jesse has built a Python proof-of-concept implementation that demonstrates the approach, and he's working on the security proofs with Nadav. Beulah will take that foundation and turn it into production-ready code that any bitcoin project can use.

A new tool for L2s

Once this implementation is complete and integrated into Bark, the server's signing key will be distributed across multiple cosigning servers in different physical locations, providing a significant improvement in security. Although, from a user's perspective, nothing really changes—they’ll still interact with the Ark protocol the same way.

Some of the other ways we anticipate nested MuSig is going to make things better for bitcoin developers and users include: 

• Stronger and more resilient L2 coordinators: Operators can spread their signing authority across multiple machines or organizations, reducing single-point-of-failure risk without changing how users interact with the system.
• Better uptime and censorship resistance: If one cosigning server goes offline or faces local pressure, the remaining cosigners can still produce signatures. Threshold signing gives L2s a more robust operational backbone.
• Standardized on-chain footprint for operators: Traditional multisig reveals its structure on-chain (observers can see how many signers are required and identify patterns that expose coordinator infrastructure), but with nested MuSig, keys look like ordinary singlesig Taproot outputs on-chain. That means Ark servers, Lightning operators, and other layer two entities can enforce distributed security policies internally while keeping the details of those policies off the blockchain.

This work also lays the groundwork for future Ark optimizations. Nested MuSig with multiple levels could reduce VTXO sizes and cut down the number of public keys and nonces needed when cosigning large transaction trees—but that's a project for later.

Track the work

You can follow Beulah's updates on X and track her contributions to secp256k1-zkp on GitHub. Of course, we'll also be sharing the occasional update from our official account!

As we continue developing the Ark protocol, understanding liquidity costs has become essential. Our previous research into bitcoin yield products revealed that Lightning liquidity leasing offers some of the most attractive self-custodial yields in bitcoin—typically 1-4% APR while maintaining custody of your funds.

To inform our fee structure for the Ark protocol, we want to dig deeper into the mechanics of bitcoin liquidity pricing. Since Ark servers must deploy their own bitcoin treasury to enable Lightning payments, refreshes, and offboards, understanding the true cost of liquidity deployment directly impacts what we'll need to charge users.

Amboss Magma emerged as the obvious place to look: it's the most mature and liquid market for Lightning liquidity. It handles a large share of all completed public bitcoin liquidity lease orders. The rates being paid there may be the best representation we have of the real opportunity cost and risk premium for locking up bitcoin to facilitate payments.

What is Amboss Magma?

Amboss Magma operates as a peer-to-peer marketplace where Lightning users can buy and sell channel liquidity. Lightning nodes that need inbound liquidity to receive Lightning payments can purchase it from liquidity providers who earn yield by temporarily locking up their bitcoin in channels.

A few key terms for understanding the marketplace:

• PPM (parts per million): The fee rate per satoshi, where 10,000 PPM equals 1%. Since there are 100 million satoshis in one bitcoin, this provides a precise way to price small amounts. Imagine them like basis points, but even smaller!
• Channel capacity: The total value of a Lightning channel, denominated in satoshis.
• APR (Annual percentage rate): Annualized returns calculated from lease terms, often extrapolated from shorter durations since most leases aren't exactly 365 days.
• LINER: Amboss's benchmark rate tracking system that monitors yield curves over time.

Our analysis

We built our dataset directly from the Amboss Magma API, using both active listings of unfilled offers and historical records of completed Lightning channel purchases. To ensure the data reflected realistic market activity, we removed outliers with high rates. This excluded two categories:

1. Filled orders above 20% APR, which were rate and not representative of typical usage, and,
2. Unfilled listings where lessors asking for unrealistically high APRs but never secured completed orders.

The data reveals several fascinating patterns about how bitcoin liquidity gets priced.

Size matters: Channel fee premiums

There are economies of scale when it comes to leasing liquidity. Small channels reflect higher PPM rates.

For example, it is more expensive on a per-satoshi basis to open a 0.5 million sat channel than a 1.0 million sat channel, even though the total up front cost can be lower.

The following chart shows fixed-size Lightning channels listed for sale on Amboss Magma in July 2025. The sample includes channels of 0.5, 1.0, 2.5, and 5.0 million sats each. At a Bitcoin price of $120,000 USD, a 0.5M sat channel corresponds to $600, while a 1.0M sat channel corresponds to $1,200.

The highlighted yellow area shows how smaller channels command a premium in fee rates. In particular, channels below 1.0M sats ($1,200 USD) are priced disproportionately higher relative to their size. By contrast, channels above this threshold exhibit a more consistent and predictable relationship, closely following the linear trend line without significant deviations.

This happens for three reasons:

• Fixed costs: Amboss charges a flat 500 PPM fee on every order, which represents a larger percentage of smaller transactions.

• Setup overhead: Opening any Lightning channel requires on-chain transaction fees and operational overhead, regardless of size.

• Supply and demand: Small channels are popular with newcomers testing Lightning or users seeking cheap inbound liquidity rebalancing. High demand combined with thin supply (node operators prefer opening larger channels for the same on-chain cost) creates pricing power for sellers.

In summary, the data makes it clear that smaller Lightning channels come at a disproportional premium price, driven by structural costs and market dynamics. For participants, this means the most “affordable” entry point is not necessarily the cheapest channel size, but rather the one that balances cost efficiency with intended use. Above 1.0M sats, pricing normalizes and reflects a more rational, linear relationship, suggesting that economies of scale dominate once fixed costs are absorbed.

Liquidity offers: A tale of two markets

In this section, we analyze a selection of open liquidity offers on Amboss Magma. These represent the active listings currently available in the marketplace, rather than completed orders.

Two clear market segments emerge:

• High-premium small channels: Channels under 1 BTC capacity show the highest APRs, often exceeding 4%. These higher APRs don’t actually translate into greater yields for providers, however, since much of what customers pay goes toward covering miner fees to post the on-chain transaction. Structurally, Lightning has many participants operating at small sizes, so demand is concentrated in this sub-$10,000 USD range. With high demand and thin supply (most node operators prefer to lease larger channels for the same on-chain cost), sellers can command premium pricing.

• Efficient large channels: Channels above 1 BTC capacity cluster around 2.6% APR, which reflects the mature market rate for deploying substantial liquidity. This segment shows a diminishing premium pattern, with rates stabilizing and closely following the market average.

The median APR across all listings aligns with the mean, around 2.6%, confirming that this is the market consensus for Lightning liquidity. Amboss has reported historical returns between 1–4%, and the midpoint of that range (≈2.5%) is nearly identical to what our analysis of open offers reveals. While users can technically earn up to ~4.24% by selling liquidity in smaller chunks, the more stable long-tail result converges on the 2.5–2.6% range.

In short, the premium zone exists below 1 BTC, where APRs regularly exceed 4%. Beyond that threshold, liquidity pricing flattens, with offers in the greater than 1 BTC converging around 2.6%—a rate that matches both Amboss’s reported rates and our broader research into bitcoin yield markets.

Network effects on pricing

The correlation between on-chain feerates and Amboss APRs reveals another important dynamic. When bitcoin network fees spike, APRs for smaller channels increase much more dramatically than for larger ones.

This makes economic sense: fixed on-chain fees represent a much larger share of the total cost for small channels. The underlying yield earned by liquidity providers doesn’t actually rise—what changes is the cost burden on buyers, with higher transaction fees being passed on.

Comparing alternatives

To validate Amboss’s position as the dominant liquidity marketplace, we examined Core Lightning’s liquidity ads feature. At first glance, the economics appear attractive—rates that could theoretically annualize to 40% APR. In practice, though, the story is quite different.

Liquidity ads typically offer 4-day lease periods at about 0.44% per lease. But the market suffers from extremely low activity, with fulfillment sporadic at best. These advertised rates are supply-side intentions, not actual executed trades, which makes realized returns highly uncertain.

This contrast reinforces Amboss Magma’s role as the most reliable source of market data—because it’s where liquidity trades actually happen at scale.

What this means for the Ark protocol

Amboss Magma is emerging as the benchmark rate for Lightning liquidity leasing. The marketplace is steadily maturing into a stable, efficient and transparent mechanism for pricing the cost of locking up bitcoin to support payments.

Our research highlights two crucial dynamics:

1. Economies of scale dominate: channel sizes above ~$1,200 (1.0M sats at $120k BTC) converge around predictable rates near 2.6% APR.
2. Smaller channels show persistent inefficiencies. In this range, buyers routinely face disproportionately high premiums, paying much more per satoshi for liquidity. Addressing this imbalance presents a key opportunity: enabling users with smaller balances to maintain self-custody without being penalized by excessive fee structures.

For Ark, these insights are foundational. This research provides crucial background for us defining Ark fee structures. Understanding the true cost of liquidity deployment is going to help us ensure that Ark offers competitive rates while maintaining sustainable economic incentives for a bitcoin payment technology.

Most importantly, the data validates that Lightning is consistently generating sufficient utility for users to support market-competitive yield rates across a range of market conditions and payment sizes. The utility of bitcoin payments is real, and great news for Ark!

As we continue the study of Ark’s liquidity requirements, we must come to an understanding on how to price liquidity. Many user operations on Ark require an Ark server to lock up bitcoin (e.g., refreshes, Lightning payments, and offboards), which has an inevitable cost of capital associated with it.

To inform our liquidity pricing plans, we decided to embark on an examination of a wide spectrum of bitcoin yield products, to see what we could learn about the prevailing market rates for bitcoin yield—what the range is, what drives higher/lower rates, and where Ark might fit.

Below are our findings!

Categories of bitcoin yield

In our research, we identified four broad categories of services offering bitcoin yield. These are:

1. Exchange savings: Users give up custody of their bitcoins to a retail crypto exchange. They usually “one-click” earn a low rate on their bitcoin.
2. DeFi: Users drop wrapped BTC into on-chain vaults and apps for a yield. Less human custodial risk, but more smart contract risk.
3. Funds: Bitcoin-denominated, structured financial instruments for accredited investors and institutions.
4. Lightning liquidity: The market for Lightning channel liquidity leasing, where users earn a yield for leasing out inbound liquidity to other users.

We decided to exclude the most degenerate of DeFi products, of which there are many, so if you think something is missing here, that's probably why!

Note that inclusion in our research below does not indicate endorsement!

Summary of results

This chart is a violin plot of APR paid in bitcoin across all the services included in our survey. The results are broken down by category.

Each coloured “violin” shows the distribution of observed APRs for a category: where the shape is wider, more products cluster around that rate of return.

Note how at the top the “exchange savings” category offers many products in a sub-1% range, and only a single outlier sits at the 3-4% range. Similarly we can spot Zest Protocol as an outlier in the DeFi category, as we know it is a “boosted” product that was recently launched and is able to subsidize its yield offerings.

* To help make comparisons more straightforward, we've normalized any rates advertized in APY to the slightly lower APR rate.
** Some outliers claiming yields up to 4%

An important distinction to highlight is that the yield services in the exchange and funds categories require investors to give up custody of their bitcoin, but those in the DeFi and Lightning categories do not (okay, so perhaps debatable with some DeFi services!).

This is offset by the convenience for retail and institutional investors when using the centralized exchange and fund services respectively. These products are accessible—no technical knowledge required.

On the other hand, using DeFi and Lightning requires time, effort, and technical capability beyond what is expected of the average investor. The products of these two categories fill a similar band in both market segment and APR bitcoin yield.

Let's take a closer look at the bitcoin yield in each category.

Exchange savings

The exchange savings category encompasses products offered by retail crypto exchanges to the mass market. Users typically purchase bitcoin and hold it custodially on the exchange, where users can simply click "earn" and lock up their holdings in exchange for yield. Beyond retail crypto exchanges with "earn" tabs offering one-click bitcoin yield generation, some platforms extend into yield products and other neobank services.

There's a pretty wide range of mechanisms that exchanges use to finance their retail bitcoin-yield offers. Some, such as Binance, lend customer BTC to on-platform margin or loan desks; the borrowers' interest funds the advertised APRs.

Platforms also route BTC (or stable-coins raised against it) into on-chain staking or liquidity programs and collect protocol rewards before passing a fraction to depositors; Binance's "On-chain Yields" documents this flow.

Newer services, such as Kraken's Babylon integration, lock bitcoin in native-chain smart contracts that help secure proof-of-stake networks and pay rewards in a separate token rather than by lending the coins out. Some exchanges, notably Crypto.com, emphasise that they conduct any such activity on their own balance sheet and "do not lend to third parties".

The majority of these products offer yields below 1% APR. Rates remain low because the supply of retail users is large, who often leave their bitcoin idle on exchanges. The yield offered by these services functions more as a "retention hook" than an investment product, raising retail users' switching costs and nudging casual holders to keep their bitcoin parked on the exchange rather than self-custodying.

However, some platforms claim higher yield rates, such as Crypto.com, Bybit, and Nexo. For example, Bybit's 2.30% yield might look enticing, but it's important to be aware that after a February 2025 hack drained approximately $1.4 billion in ETH, the platform raised rates to prevent customer withdrawals and attract new users to compensate for lost liquidity. The rate could be subsidized to regain trust rather than reflect a genuinely stronger offering. Crypto.com's rates may also look high on first glance, but on closer inspection (see chart below), you'll see that most users fall into the "flexible term" category, which provides only a 0.25% APR bitcoin yield. The higher rates are only achieved through limited-time offers and fixed-term lending contracts at 1-month and 3-month intervals.

In short, this category offers the lowest yield of any category in our survey, while exposing users to a variety of counterparty risks.

DeFi's bitcoin yield

The bitcoin DeFi yield products we surveyed use custodial "wrapped bitcoin" (like WBTC, cbBTC, or sBTC) instead of native bitcoin. Users log into crypto DeFi apps, connect their wallets, then lock up wrapped bitcoin tokens into liquidity pools or lending/borrowing platforms. Many protocols will insist on users to deposit bitcoin together with a stablecoin.

In this category, custody is distributed across multiple entities through multisig and smart contracts, so you reduce the risk of a single counterparty with unilateral control (like exchange savings and funds). But instead, you're exposed to a new "smart contract risk", where a bug, oracle glitch, or bridge exploit can drain the vault and the wrapped bitcoin is gone for good. DeFi protocols can be very complex and face unknown vulnerabilities. Over just the last five years, exploits have erased over 2,200 bitcoin in total (over $250 million in value)—including incidents like BadgerDAO's $120M hack and address poisoning attacks worth $68M.

Another risk in DeFi—you can become the yield, through impermanent loss (where price movements between paired assets leave you worse off than simply holding bitcoin) or liquidation. These products aren't minting value out of thin air, but rather siphoning it from traders on the other side of the pool or other liquidity providers caught off-guard. The game is typically zero-sum, and one person's APR yield is another's slippage or liquidation penalty.

As total value locked (TVL) rises in a particular DeFi product or pool, more capital is competing for the same demand so the yield per unit falls. This is the case for applications such as Aave that grow to billions in TVL, and the yield percentage APR trends lower. Zest Protocol, a Stacks-based lending market, stands out as the outlier in the DeFi category with rates up to 3%. We'd assume this is because its pool is still small and subsidized—headline rates are padded by a questionable "STX token boost".

Bitcoin yield funds

The funds category is defined by institutional products sold to accredited investors often through licensed securities venues. These products are tightly regulated, open only to accredited investors.

This is arguably the most diverse category, with yields generated from a wide variety of activities such as electricity arbitrage, lending, and market making activities. For example, mining backed notes (such as the Blockstream Mining Note) allow customers to swap their bitcoin for a slice of bitcoin hashrate, with users earning yield from block rewards and transaction fees. The Coinbase Bitcoin Yield Fund (CBYF) generates yield from basis trading and arbitrage.

The premium 5-6% yields offered by products in this category are arguably a product of sophisticated strategies and asymmetric opportunities. Most of these products concentrate their risk in a single specialist strategy. While the broad investment strategy and targeted returns are disclosed publicly, the details of subscription terms and risk disclosures are provided confidentially to accredited investors only (typically under NDA). The purchasers of these financial instruments are typically exposed to a variety of ideosyncratic risks, for example with mining: variable blockspace demand and infrastructure risks.

If these strategies don't work out and the fund does not make the yields, then there is no payout to the investors. There is no guarantee that you will maintain your initial investment, just like any security.

Leasing Lightning liquidity

While individual users can earn yield from routing fees on Lightning, we've focused on liquidity leasing only. Currently, there are no services that offer yield from routing fees, but there are a handful that support the earning of yield for liquidity leasing.

Leasing Lightning liquidity is also the closest analogue to liquidity on the Ark protocol, making it the most relevant bitcoin yield category to us!

In this category, users lock up bitcoin in channels to supply inbound liquidity for others who need to receive bitcoin payments over Lightning. These services operate as marketplaces that match liquidity suppliers with those who need it, rather than taking custody and deploying the bitcoin themselves. Liquidity suppliers retain custody of their bitcoin throughout—they simply can't use it for other purposes while it's locked up. The liquidity is typically provided on a fixed-term basis, with the expectation that channels will be closed and remaining bitcoin returned to the liquidity supplier when the term ends (though this doesn't always happen).

This is still a fledgling category, with only a few operators. The last four years of data indicate Amboss Magma yields between 1-4% APR, and we went with 2.6% as the average rate for our charts. Higher yields tend to be for smaller amounts and shorter periods, and the lower yields were for larger amounts on longer periods. Given that Amboss Magma stands out as the only well-established Lightning liquidity market with market makers, a full order book, and web interface, we'll be diving deeper into the dynamics of the Amboss marketplace in a dedicated article soon!

The above chart shows the current open offers on Amboss Marketplaces to sell Lightning liquidity, having removed three outliers in the 25% and up range. This is how we observe the 2.6% median value of an open offer, which is right in the midpoint of the advertised 1-4% APR range. The offers with the greatest variability show the highest rates, and represent offers of a smaller relative bitcoin size.

Lightning Pool is another non-custodial marketplace for leasing Lightning channel capacity through auctions, designed for advanced users. At the time of writing, we queried an lnd node to return a list of confirmed orders within the last two weeks. There were only two orders in this time—both sold for a 2.53% fee to borrow sats for a 14-day period. Annualizing that rate over a year would be equivalent to a yield of about 66.2% APR - with no compounding of yield. However, the volume of completed orders appear to be very low.

Core Lightning's liquidity ads are a decentralized marketplace feature built into the Lightning protocol itself. At the time of writing, we found 35 open offers on the supply side, with fees ranging from 0.10-1.20% for lease periods of approximately four days. The period-adjusted median rate is 0.44%, which would correspond to 40.2% APR if orders were continuously filled. However, the market has low volume—those advertised terms lack enough demand to convert to continuous leases, significantly reducing actual yield. These figures represent supply-side intent to sell, without guaranteed matches. While the headline economics look attractive on paper, sporadic fills mean actual returns are uncertain.

While it's clearly still a maturing category, it's exciting to see such high yields being achieved in Lightning liquidity leasing. Bitcoin-denominated yield is not easy to achieve, and these yields demonstrate the users are getting sufficient utility from Lightning payments to cover the prevailing opportunity costs for liquidity suppliers. Lightning yield is especially attractive because you don't have to give up custody—you're just putting your bitcoin into a simple, battle-tested script!

What drives bitcoin yield rates

Embarking on this research, we didn't realize the level of complexity in bitcoin yield products. Multiple competing factors affect the rates being achieved. Convenience is critical—easier solutions attract more participants, driving yields down, while solutions requiring technical expertise attract fewer participants, creating higher yields (when demand exists!).

Risk and reward follow the expected pattern—higher-risk strategies must offer higher yields, while perceived lower-risk options offer less. Custody is a key component of risk. Self-custodial solutions should theoretically offer lower yields since they're arguably less risky than handing bitcoin to third parties. In reality, exchange savings products offer very low rates despite massive custody risk—they overcome this through convenience and targeting users who wouldn't self-custody anyway.

Michael Saylor has, at least once, claimed there should be a 5% risk-free rate in bitcoin, but our research shows there's no such thing as truly risk-free—even self-custodial solutions face risks like node hacks, key compromises, or protocol vulnerabilities. Nothing that looks sustainable is offering anything close to 5%.

Implications for the Ark protocol

This survey demonstrates consensus forming on the opportunity cost of deploying bitcoin capital—roughly 1-4% annually. We'll use these findings to inform how we price liquidity in the Ark protocol, which will affect the cost of Lightning payments, refreshes, and offboards.

Another consideration is that while Ark servers will likely start by deploying their own bitcoin treasury for liquidity, as adoption grows, they may need to source bitcoin from third parties. This could lead to additional yield demands to cover the increased custodial risk.

As with anything in bitcoin, things will continue to change fast and we'll continue to review.

We finally have some research into Ark liquidity requirements that we're ready to share!

To explore this topic, we simulated real-world usage for bitcoin users sending Lightning payments. While Ark users can also send payments directly over the Ark protocol, we expect that initially, users will be mostly using Ark as a Lightning gateway, at least until Ark builds up some momentum. So that's where we started!

To put things into perspective, we'll compare these requirements to those of a Lightning Service Provider (LSP).

Let's dive in.

What drives liquidity requirements?

Before we "run the numbers", let's cover a quick primer on the mechanics of liquidity on both Lightning and Ark.

LSP liquidity

These days, a typical user uses Lightning through an LSP and the user has a single channel with their LSP.

A payment channel between a user and the LSP is shown below. The channel has a capacity of 1 BTC, the user has a balance of 0.4 BTC and the service provider has a balance of 0.6 BTC.

The 0.6 BTC in the channel is owned and provided by the LSP. The LSP can only use this money to serve that specific user and might expect a return for locking in the money. Note that the amount of bitcoin an LSP needs to provide doesn't depend on transaction volume, but solely on the channel balance.

An LSP can optimize liquidity efficiency by regularly adjusting the channel capacity for each user. However, each time the channel capacity is adjusted/spliced, the LSP pays fees for an on-chain transaction. Another option is to close channels to inactive users who don't generate sufficient revenue.

Ark server liquidity

A typical bitcoin wallet manages UTXOs ("unspent transaction outputs"). An Ark wallet manages VTXOs ("virtual transaction outputs"), which are the outputs of normal bitcoin transactions that haven't been broadcast yet.

An Ark server must use its own bitcoin to enable the following actions:

• VTXO refresh: Ark servers must provide liquidity when creating new VTXOs during refreshes in rounds, as they will only claim forfeited bitcoin from expired VTXOs after the vtxo_expiry_delta period (typically 28 days after the inception of the VTXO).
• Paying over Lightning: When users make Lightning payments by giving up their VTXOs, the server covers the payment amount until VTXO expiry.
• Off-boarding (on-chain sends): Servers provide immediate on-chain bitcoin when users off-board their VTXOs, but only access the forfeited VTXOs after expiry.

The following actions don't impose any liquidity requirements on the server:

• Internal Ark payments: Ark payments between users of the same server occur out-of-round and don't require liquidity.
• Boarding: Users board the Ark with their own funds.
• Unilateral exit: Users broadcast their VTXOs independently without server involvement.

The main lever for an Ark server that wants to optimize liquidity efficiency is fees. The server will ask a lower fee when a user performs refreshes, off-boards, or Lightning spends from a VTXO that is soon to expire and a higher fee for a VTXO that expires later. This incentivises users to always use their oldest VTXOs.

Do Ark servers or LSPs require more liquidity for Lightning?

If you hoped for a straight answer, you are out of luck. The truth is, it depends... The liquidity mechanics of an Ark server and an LSP are wildly different.

To compare the two, we have simulated two common modes of bitcoin user behaviour:

• Infrequent top-up, gradual spending: User funds their wallet infrequently from cold storage and gradually spends their balance using Lightning.
• Regular DCA stacker: User buys bitcoin for a fixed amount of dollars every month. Moves funds to cold-storage at the end of the year.

Simulations assumptions on parameters and user behavior

For all simulations, we've assumed:

• All outgoing payments sent over Lightning. For Ark, this provides a worst-case estimation for liquidity burden (overestimating required capital), as Lightning payments require immediate liquidity while internal Ark payments don't. In practice, users will likely make some or most payments directly through Ark. Also, once Ark supports virtual Lightning channels, this model will change entirely.

For LSP simulations, we've assumed:

• No channel capacity adjustments: The LSP does not adjust the user's channel capacity throughout the year.

For Ark simulations, we've assumed:

• VTXO expiry time of 28 days: A server-configured parameter balancing cost and convenience.
• Each received VTXO expires 14 days after receipt: This represents the average VTXO age, as the user will accumulate both newer and older VTXOs over time, resulting in an average lifespan halfway through the 28-day period.
• User refreshes all VTXOs two days before expiry: This would be configured by the user and automated by their wallet app. Two days gives them ample time to re-attempt refreshes in case something goes wrong with the first attempt.

User profile: Infrequent top-up, gradual spending

This scenario considers a user that periodically funds their wallet and spends gradually using Lightning over a period of one year.

We'll compare LSP and Ark server liquidity requirements for a user that:

• Tops up once a week
• Tops up once a month
• Tops up once a quarter

The total liquidity burden is shown as a blue area in the LSP simulations, and a yellow area in the Ark server simulations. We call this satoshi days (sat-days). One sat tied up for 10 days, or 10 sats tied up for one day, both equal 10 sat-days—the same cost to the server.

If we divide sat-days by the total payment volume we can get the liquidity duration in days. This is the average duration an LSP or Ark server needs to lock up an equivalent amount of sats for each sat spent.

Top up every week

LSP

Ark server

Result

LSP 2.485x times more efficient.

Top up every month

This scenario most closely resembles the typical once-a-month salary and daily spending on life expenses.

LSP

Ark server

Result

Roughly similar (LSP is 1.046x more efficient).

Top up every quarter

LSP

Ark server

Result

Ark server is 3.73x times more efficient.

User profile: Regular DCA stacker

This user aims to accumulate bitcoin and hodl long-term. They buy 100 USD of bitcoin on a biweekly basis. At the end of the year the user drains their wallet and sends all funds to cold-storage.

LSP

Ark server

Ark is 6.65x more efficient in the above scenario.

Summary

Key observations

Balances vs. payment volume

An LSP's liquidity requirements are driven primarily by changes in users' balances, whereas Ark server liquidity requirements are driven by payment volume.

LSPs face greater variability of liquidity duration than Ark servers

The liquidity duration is 4 to 64 days for the LSP and 10 to 17 days for the Ark server. Individual users can exert significantly different liquidity pressures on an LSP.

LSPs need to be much better than Ark servers at predicting user behavior

An LSP must assign an inbound channel capacity to each user, but it can't know in advance how much a user will (net) receive via the channel. It can adjust the channel capacity throughout the year but every adjustment will require a costly on-chain transaction.

In some cases the LSP might be very efficient but in some cases the LSP might allocate a lot of liquidity that will never be used. Poor predictions can result in poor efficiency. Any costs associated with inefficiency will ultimately need to be borne by the LSP's users.

An Ark server doesn't need to play a guessing game. It simply allocates the exact amount of liquidity required at the time of a Lightning spend.

Funding frequency is a key factor in Ark liquidity efficiency

We learned that liquidity efficiency is heavily determined by how frequently the user funds their wallet. An Ark server is most efficient when users top up less frequently than the vtxo_expiry_delta period.

For example, in the monthly top-up simulation, the spike on day 12 to 14 of every month is caused by a refresh of all the VTXOs that have been received in the beginning of the month which are close to expiry.

However, even with a user freqently depositing to their wallet, note that the Ark server's liquidity burden is still consistently reasonable.

Conclusion: Ark can enhance liquidity efficiency for users making infrequent Lightning payments

Based on our simulations, if you're the kind of user that's spending bitcoin over Lightning daily, and receiving payments every week or more, then you're likely to be spending less on liquidity than if you used Ark.

But if you're making less-frequent payments, and only receiving bitcoin each month (e.g., a monthly salary or bitcoin purchase), then using Ark with a Lightning gateway should offer significant savings.

If you're a DCA bitcoin stacker, you absolutely-definitely should be using Ark, with liquidity costs being a small fraction of what it would cost to use an LSP.

And remember, the simulations for Ark assumed the user made only payments over Lightning. It is a conservative, "worst-case" scenario—payments from Ark to Lightning require immediate liquidity, but payments over Ark do not.

At the very least, we hope the simulations demonstrate that the liquidity requirements for Ark are not excessive. That's one common misconception that we're keen to head off!

Follow for more research

We've got more liquidity research to come—it's essential for both our users to understand what to expect from the Ark protocol, and for us as we optimize liquidity. Ark has a lot of parameters we can tweak and any efficiency gains will translate into lower costs for our users!

Make sure you follow us on X or sign up to our newsletter to keep up with the research!

Last weekend at OP_NEXT, we unveiled Erk—a novel variation of the Ark protocol that completely removes the need for user interactivity in rounds. This addresses one of Ark's key limitations: the requirement for users to come online before their VTXOs expire.

The innovation behind Erk

Erk (named after our CTO Erik who conceived the protocol!) introduces "refund transactions" with rebindable signatures, allowing users to provide signatures in advance that can be applied to future outputs. The server can then safely refresh VTXOs without requiring users to be online for each round.

refund tx:
| inputs             |        outputs | 
+====================+================+
| old exit tx for A  | exit policy A' | 
+--------------------+----------------+
| new exit tx for A' |              S | 
+--------------------+----------------+

Another powerful feature of Erk is "perpetual offline refresh"—users can bulk pre-sign future refreshes in sequence. With watchtowers monitoring the protocol, a user could remain offline indefinitely while their funds stay secure.

Beyond Erk: hArk

We've also developed "hArk"—which works alongside Erk. While Erk excels at single-input refreshes, hArk is optimized for consolidating multiple inputs into a single output through a clever secret-revealing mechanism.

Like Erk, hArk also requires CTV (but doesn't rely on CSFS).

What this means for Ark

These innovations build on recent improvements to our Ark implementation, including making arkoor the standard for payments and benefiting from Bitcoin Core's package relay update.

While these improvements require CTV, we continue to work toward launching Ark on bitcoin as it is now—there's still a lot of great scaling benefits users can enjoy without these enhancements!

For the full technical breakdown of how Erk and hArk leverage CTV and CSFS, check out our detailed post on the Delving Bitcoin forum.

CEO Steven Roose gave a comprehensive update on the state of the Ark protocol on the Stephan Livera Podcast, so we're sharing the transcript here for those that prefer those!

Stephan: Hi everyone, you're watching Stephan Livera Podcast brought to you by Bold. For American listeners, go to getbold.to to buy bitcoin now. Rejoining me on the show is Steven Roose. He is the CEO and co-founder of Second BTC, and they're one of the teams working on Ark, which is another L2 for bitcoin other than Lightning. We're going to get into this—obviously there's a bunch of different things you guys have with this signet launch and other things going on. First of all, welcome back to the show.

Steven: Thank you, very excited to be here. Thank you for having us.

Stephan: I know there's a lot of different things happening, so let's try to set the stage for people. This is another L2 for bitcoin. What is the promise here? As I understand, you're trying to use Ark to also make Lightning better. Is that one way to understand it, or are you trying to use Ark as a way for more people to use self-custody bitcoin? Can you elaborate a bit on the high-level vision here?

What is Ark?

Steven: Yeah, sure. We think Lightning is great for people that do really high volumes, but we noticed that end users—like individuals who just want to make occasional payments—are really struggling with a self-custodial Lightning setup. So Ark is a different second layer protocol that works entirely differently than Lightning, but it's compatible with Lightning as well.

End users who don't want to have a whole Lightning setup can use Ark. They can still pay Lightning invoices and pay anyone who's on the Lightning network, but they don't have to manage their own channels. They don't have to manage the infrastructure that is needed to run Lightning because Ark is a client-server protocol. The server only is there to help the user make payments, but it's never taking custody of the funds. The Ark protocol is totally self-custodial, but it's basically making it easier for users to make Lightning payments and onchain payments, or just holding your money.

Stephan: Just to summarize for some listeners—obviously some listeners are quite techy and developers and they get all this—but just for the non-developer listeners: The idea is with a lot of bitcoin payment apps, what's happened is some of the complexities of Lightning have driven and pushed a lot of people to use custodial Lightning apps, things like Wallet of Satoshi or others out there, or KYC Lightning things like Strike or whatever else.

Again, I'm not criticizing—I obviously want more people to use bitcoin in general—but of course it would be good for more people to have these self-custodial options. What drove them to the custodial options? It's things like having to manage channels or managing the liquidity—how much is on that side of the channel, and what are the fees if I need to go to chain. These are some of the things that if you were to try and do fully self-custodial Lightning, these are the requirements. Can you explain a little bit about why you see Ark alleviating some of those concerns?

What is the Ark approach to self-custody?

Steven: From our perspective, there are two main big hurdles for having self-custodial Lightning. One is that you need to manage your channels, right? So you need to create them and occasionally close them or refund them or rebalance them, and any of these interactions require onchain transactions.

Currently, we are at a historic low when it comes to onchain transaction fees, but in the past they have been a lot higher, and we anticipate that in the future they might also rise again. Then these interactions with your channels can become very costly.

Second of all, on Lightning, because your payments flow over channels, to receive payments you need to have a channel with someone who has some money in this channel with you, which is called your inbound liquidity. If you don't have inbound liquidity, you cannot receive any payments. It's usually not easy to convince someone to put money locked in a channel only with you. That's why most of the Lightning wallets right now allow you to basically purchase or rent some inbound liquidity where they charge you a fee, and then you can have inbound liquidity.

These are the two main hurdles that you don't have with Ark because you don't need channels. You can always receive without needing specific inbound liquidity because this is all handled by the server. You don't need to create channels or rebalance because all your balance is kept in the Ark totally offchain, and you don't need to manage this liquidity yourself because there are no channels.

Stephan: Understood. In another way, or in a similar way, it's about onboarding, right? Because what we're talking about here is: for a new person when they come in and they start up a bitcoin Lightning wallet, they're kind of stuck with one of a few hard choices. It's either do everything manually yourself, have enough bitcoin to manually do the channels, or pay to rent a channel, or push that cost and complexity onto the LSP and the Lightning wallet person. Who's maintaining that? Any of those three options, you know, has tradeoffs around it. That's the nature of how things are.

What I'm understanding here is Ark can help you in terms of onboarding a new user with a different set of tradeoffs. It's important to understand it's not free—there's no free lunch here—but it's a different set of tradeoffs. Can you explain a little bit about that and why it's better from an onboarding perspective?

Reducing the onboarding hurdle for users with Ark

Steven: The onboarding problem is particularly difficult because if you don't have anything, you don't have channels, and someone (a friend or someone) wants to send you their first payment or your first payment, and you want to receive maybe 10 bucks, 20 bucks, it's really not possible in Lightning to do this because a channel will often cost you a few bucks, and then you need to wait for it and all this.

In Ark, you don't have any of this. You can immediately receive an offchain VTXO—VTXO is basically a unit of money in Ark. So you can immediately receive some offchain money, and there's no need for a setup. You can just open an app that would support Ark, and immediately you can make your first receive.

I think that is mainly why the onboarding experience—we will talk about our signet launch later—but we wanted to specifically show that you can just set up your wallet, go to our faucet, and receive some onchain funds instantly, which is something that with Lightning is not possible today. That's why most people are going to recommend custodial or semi-custodial Lightning solutions where you can tell someone, "Hey, install this app and I can immediately send you 10 bucks," and it will immediately show up in their wallet. But that's not really possible with fully self-custodial Lightning.

Stephan: Okay, and now let's just compare this with, you know, people might have heard of or they might be using other approaches—things like Liquid, right? As an example, and I know you used to be working on Liquid stuff over at Blockstream previously to this, so obviously you're very familiar with that. And then there are others who might talk about, let's say, Cashu or Fedimint using an ecash style approach. So how would you contrast an Ark onboarding with, let's say, an LBTC Liquid style onboarding or an ecash, let's say a Cashu or a Fedimint onboarding? How does Ark compare with those?

How does Ark compare with Liquid & eCash?

Steven: They're all similar in the sense that there's some third party helping you do your bitcoin stuff, right? So it's not like your onchain wallet where there's just a peer-to-peer network. But in both Liquid, Cashu, and Ark, there's some kind of server that is helping you do this.

What differentiates Ark is mostly that the server at no point is in control of any money. So it's totally self-custodial, while in the Cashu case, for example, it's kind of fully custodial. It's fully custodial—the Cashu mint has all the money and it gives you tokens that you can then anonymously and privately use to send Lightning payments and send this Cashu, this e-cash around. But the money in the end is all handled by the Cashu mint.

It's possible to make a Federated cash mint, I imagine, where it's multiple people, but still, the money is controlled by other people. In Liquid, it's also the case—they have a big Federation of 15 different companies that hold the money jointly, like collaboratively, but still it's those people that have the money in their hands. If something goes wrong, it's always possible that the money doesn't end up back into your hands if you would need it.

With Ark, the user is always fully in control of their money, and the server is only there to help coordinate what we call rounds or to help you make offchain payments and Lightning payments.

Stephan: So in other words, am I understanding it correctly then? The Ark wallet that you are creating—the idea is the user has their own private keys basically, and they hold the private keys to a VTXO that's being helped—like the server helps them manage that. But the point is unilateral exit, right? The idea is if they wanted to go to chain and take those funds onchain, they can do that. That's the difference you're pointing at, right?

Steven: Exactly, exactly. And the server doesn't really help you manage it as much as it helps you set it up in the first place. So your wallet manages all the transactions that it would need to broadcast in case of a unilateral exit, and it manages your VTXOs.

But every time they are about to expire—we can maybe go into the expiration thing later on—but whenever they're about to expire, the coordinator in the server will help you refresh them and create new ones. As soon as they are created, you don't need the server anymore because they are there and they're always yours. You only need the server if you want to pay or if you want to transfer them to someone else.

The server is also a Lightning gateway because the VTXOs are not channels, so we use trustless swaps so you can get your VTXO onto the Lightning network in a payment in one go. Currently, the Ark server will also be the Lightning gateway. In theory, there can be third-party Lightning gateways as well, but currently, it's the same party. Then the coordinator will help you make Lightning payments, help you refresh your VTXOs, and help you pass on your VTXO to other people.

Stephan: Gotcha. There are a few terms that we should help explain, and maybe some of this terminology has shifted a little. In past discussions on Ark, people might have heard the term ASP—Ark service provider—and I guess that was meant to be kind of parallel to Lightning service provider, which people understand from the Lightning world. There are a few other terms you mentioned there: ASP, I guess, is like an Ark server, and then the coordinator and the Lightning gateway. I guess the Lightning gateway and the coordinator are the same, right?

If you could explain a little bit about the user and the server and how that interaction works from an Ark perspective?

How does a user interact with an Ark server?

Steven: In Ark, each Ark is like a small bubble. All your interactions will happen within your Ark with your single Ark server. There's not really any crossover to different Arks.

If I'm in a different Ark than you are, we can pay each other through Lightning, and Lightning will be the bridge. Or we can do direct swaps from my Ark to your Ark, but you cannot move the money directly from one Ark to the other. You either have to swap or use Lightning.

So all your interactions as a user will be with a single server. You know the address of the server, your wallet will be configured to talk with that server, and every time you want to do something, you just talk with the server. The server helps you do all your interactions, and the protocol guarantees that if the server disappears or starts to act out in a bad way, you can always use your unilateral exit and broadcast your transactions to the chain and have your money back.

Stephan: And could you also explain for us at least the current understanding of what's happening in terms of the rounds? As I understand, there are rounds, and I think historically you had this—was it arkoor payment? It was like out of round or maybe you could explain a bit about this because it might have changed from how I'm understanding it.

How do Ark rounds work?

Steven: The protocol definitely changed a lot since it was invented, but we're kind of settling on the way forward and the current way.

The rounds are kind of the core of the protocol because the rounds are when the new VTXOs—we call them virtual UTXOs, the offchain UTXOs—when they're issued. So they are created during rounds. Initially, we envisioned that you would use the rounds also to pass on VTXOs to other people, but currently, we only use the rounds for your own VTXOs to be refreshed when they are about to expire.

A VTXO in Ark has an expiry time. We imagine they would be something in the order of one or two months. So every one or two months, you would have to refresh your VTXOs, and you use the round to do that. In the round, you will tell the server, "Hey, I have these VTXOs that are about to expire, I want new ones in return," and then they have a fresh expiry time.

Rounds would happen something about every hour, but your wallet will probably be participating in these rounds in the background without you really noticing that this is happening because the money just goes back into your wallet, it gets a new expiry time, and you don't really notice this much.

Then when you want to make payments to other people, we use what we call out-of-round payments, or arkoor for short. What you do then is that you have an existing VTXO, and you just make a transaction on top of this to basically pass it on. It's kind of like an onchain transaction where you have a new transaction that spends this transaction as an input and creates new outputs. It works exactly in the same way, but the difference is that this transaction stays entirely offchain.

So you can make multiple ones of these—kind of like a mini transaction chain offchain—and you don't have to do any rounds for these transactions to confirm. They're instant. This is also how you make Lightning payments. If you make a Lightning payment, you basically make a small arkoor payment that creates an HTLC and creates some change. Then the HTLC goes on the Lightning network, the change becomes your new VTXO, and then at some point the VTXO will expire, and then you use the rounds to refresh it, and you get a fresh VTXO again.

Stephan: I see. So my caveman/layman understanding: let's say I've got an Ark wallet as an end user, and I want to make a Lightning payment. For me, the way it looks would be like I scan and make a Lightning payment like I normally would, but actually what's happening is I'm doing a payment that kind of goes to my Ark server, and my Ark server has the Lightning gateway that actually makes the payment on my behalf, and then I'm getting back a VTXO with the change later? Or how does that work?

Steven: It's not really on your behalf because what happens between you and the server is also an HTLC. It's kind of like the same thing as if we would have a channel—a bit more trustless in that way. It's totally trustless. It's like as if we would have a channel, because in Lightning, HTLCs are built on top of channels, right? But they don't necessarily need to be built on top of channels. It's just a contract, an HTLC contract.

So we just build an HTLC in the Ark, not on a channel, which basically tells the ASP, "Hey, if you can give the preimage, then I can give you the money." Then the ASP can use the Lightning network to get the preimage from the eventual receiver of the payment, and then the money gets unlocked atomically in the Ark and in the Lightning network.

Stephan: I see. So it's actually a stronger level of trust minimization compared to some of the other approaches because of that?

Steven: It's fully trustless—the HTLC is there. If there's no preimage, the money does not go to the ASP at all.

Stephan: I see. That's another thing about Lightning—the idea is there's this preimage, and you need to make sure it gets to the other side before they release...

Steven: Exactly. The timings are a little bit more tricky than in Lightning because in Lightning, every channel is kind of the same, so you just have different timeouts that you stagger. But then the timings inside the Ark are a little bit more complicated, so we have to be careful that the timings are right. But that's getting very technically into the weeds.

Stephan: Yeah, we don't have to go to that level of it. So who do you see as the main users of Ark?

Who benefits from Ark?

Steven: We think that just individuals who want to make payments have the most benefit from Ark. We think if you're like a really big shop that receives thousands of payments per month, you're probably better off setting up a Lightning infrastructure or paying someone to do it because Lightning is really good for this high volume.

But we think any user who just wants to make several payments a day, who just wants to have a mobile app and wants to go to a shop and pay, will have more benefit from using Ark than from trying to set up custodial Lightning.

And the same wallet, the same Ark wallet, can also just make any offchain payments. So even if you would receive your salary in your Ark wallet, you can easily send back to your cold storage. It's kind of a fully working bitcoin wallet that does both onchain and Lightning without much management and headaches.

Stephan: I see. So I guess the way you're explaining it there is it could be like a unified balance you don't have to think about as much. Am I onchain? Am I offchain? It's just kind of "here's my balance, I can just make payments with it" and not really worry too much in the background.

In terms of capacity and things like that, you don't really have to think about that. It's not that "Oh, I need this much inbound capacity" or none of that. Just if I want to make an onchain payment... here's the example: Let's say I want to make an onchain payment out of my VTXO balance, how does that part work? Let's say I've got 1 million sats and I want to make an onchain payment for 0.1 million sats (100,000 sats). How does that work in Ark?

Steven: To make onchain payments, you have to wait for a round. They're not out-of-round—there's no out-of-round onchain payments. What you would do is you would tell the server, "Next round I want to make this onchain payment," and then when the round happens, the server will create an output on the round transaction.

Every round, a new onchain transaction is broadcast that issues all the VTXOs offchain, but it can also create outputs onchain. Then you would pay a little bit of a fee because you pay the onchain fee just for your output, just for your script. Then at the end of the round, the onchain output would be created, and you would either have some of your change in VTXOs, or the change can stay offchain.

Stephan: I see. And so is there any concept here of "you need to add enough fee to get it confirmed," or is that handled by what the server does for you?

Steven: Exactly. As the server, because the round transactions are usually very small—they're usually a few inputs and then two or three outputs—we really overpay fees to make them confirm because this is the essence of our protocol.

For the user, you don't have to worry about replace-by-fee or something like that. The server will make sure the transaction confirms, and they will charge you just the fee for your output. So you don't pay onchain fees for your inputs or for your change; you only pay the onchain fee for the output that you really need.

Stephan: I see. And then I guess the trade-off in one sense is you make your payment onchain and it goes once an hour—you can't make an instant onchain payment. So that's one downside maybe for some listeners or some users that would be annoying for them. But hopefully, over time, as Lightning grows, more and more people would just do Lightning payments anyway, so then this will be less and less of an issue.

While we're on the topic of who is the typical user—are we talking here like a retail user? This is not for high-value, large amounts, right? Or how do you see it?

Steven: The thing that I mostly think Lightning still benefits is high volume—thousands of payments, like stores, online merchants, stuff like that. But the amounts don't really make much of a difference.

Just like you know that onchain, your fee is based on the amount of bytes in your transaction and not based on the amount of money, the same is true in Ark. The fees are a little bit more tricky because they are in some ways a bit based on the amounts, but it doesn't make it less feasible to have larger amounts in Ark, just like in Lightning.

Lightning in the beginning had this "reckless" mode, the wumbo channels, where they tried to discourage users from putting a lot of money in the channels. But I think at this point, Lightning is secure enough that it also works for larger amounts.

Stephan: I see. So it's not actually limited just to coffee payments and small retail—you actually could do multi-thousand, $10,000, $100,000 payments theoretically?

Steven: I think so. I don't see a reason why we wouldn't. Obviously, the more money is in it, the more careful you have to be that you refresh them on time because otherwise, you can get into trouble. But I think either your app provider or your wallet provider will make sure that that happens.

[Ad break: Coin Kite and Cold Card security devices]

Stephan: While we're on the topic of apps and refreshing and so on, one thing people talk about with mobile is that Android and Apple are getting aggressive about battery management, so they don't let you do things in the background. How do you get around that? Because as I understand, the app has to wake up every now and again and sort of do a refresh. How do you manage that?

Ark mobile experience and app management challenges

Steven: That's a very good question, and that's why we're also launching this product now on signet, because we want to start experimenting with this and learning the pains. We are not planning ourselves to release a mobile app, but we are partnering with different app developers who want to integrate Ark and who have the mobile experience but who don't really know how the Ark interactions will work.

So we're trying to tailor our SDK, our wallet, and our platform to be as mobile-friendly as possible. We have a lot of changes that we have in mind to reduce the different latencies that are there when people have to wake up. But as you say, the mobile platforms are not easy to develop on, especially not if you need to do background work, and it's important that you just occasionally wake up and have a chance to refresh your VTXOs.

I think it's going to be an interesting ride and a collaboration between us and different app providers. If there's people building iOS-only or Android-only or cross-platform in different ways, we will have to talk with them, look at the ways they have to wake up the phones of their users so that they can participate in rounds.

What we can do on our side is try to make the SDK as low-footprint, low-cost as possible when it comes to CPU usage, time needs, bandwidth, and stuff like that. But eventually, it will be the app developers who need to understand the processes and what the limitations are. It's still to be seen how far we can go to make it fully user-friendly depending on the platform.

That's why we launched this test version, because we want to start learning this as soon as possible. Our company's goal is to get payments into the hands of end users, and we know that obviously that will be mobile—people are not making payments from their desktop computers. So we want to get that mobile experience as soon as we can.

Stephan: As I understand, right now, if I think of, let's say, Phoenix wallet, they are using some Google Play thing where they can send a notification and make your phone wake up to take a payment. So I presume it will be something similar to that.

Let's talk a little bit about signet. You've done this signet launch—what's the overview of the signet launch?

Ark's signet launch

Steven: We basically wanted to get our product in the hands of some early adopter users, some first movers who just want to play with it and want to see how it feels like. We especially hope that we will get some app developers excited to start trying to integrate this SDK into their apps.

What we did was we launched our Ark server and our client called bark, and we created a server that is active on signet right now. We created a little faucet and a tutorial so that users could install bark (the client), create a wallet, receive some offchain money from our faucet (the faucet is providing offchain and also onchain money if you need it on signet), and then we provided a small store where you could buy some treats for our mascot called Bite.

Basically, we're showcasing that you can also make small payments. It shows you a Lightning invoice, you copy-paste it into your CLI because it's only in the terminal for now, and then you can make some payments from your bark wallet.

We're trying to get users, and mostly developers, to see that this is something that's actually working and that is improving rapidly, and to get them excited to try and integrate this into some of their apps or platforms or wallets in different kinds of ways.

Stephan: In current form, how many people can use Ark before you start to hit some kind of usability limits? As I understand, this is early days so I guess you're still figuring this out, but as I understand, one of the tradeoffs of not having like a CTV or things like that, or TXHASH or whatever, is that there's more interactivity. What does that mean in practice for users today?

What are the user limits for Ark?

Steven: That's another reason why we want to get people to test this, because we don't have much real-world usage examples. We have some tests—I can tell you that we have tests where we run up until like 100 participants in each round, but not much further beyond that. Because if you do it all on the same computer, it's also not really a good use case.

So we don't really know—in theory, the limits should be pretty high. The real limitation at this point is: does the user have enough time and bandwidth to participate? Because the interactivity means that there's a lot of data flying around.

Without CTV, for example, all the participants need to create a bunch of transactions, a bunch of signatures on a bunch of different offchain transactions in preparation for the rounds. On mobile, that means you need to send a lot of cryptographic nonces, then signatures, and all of this needs to be done each round.

Just to make it clear, because some people make this mistake: you don't have to participate in each round. As a user, you only participate in a round if you need something from the round—if you need to refresh some VTXOs or if you need to make an onchain payment.

But still, if you're on a mobile phone and you need to refresh, we want to make sure that you have the highest chances possible of succeeding in participating in these rounds.

The limitation depends on how many users can participate in each round. You only need to participate once every one or two months with your VTXOs. So you can do the math: multiply the number of outputs we could have in a round—I'm imagining something in the limit with the current model would maybe be somewhere around a few thousand per hour—and then multiply that by a whole month or two.

Stephan: So we're talking like 50,000-100,000 users, probably?

Steven: Yeah, and then with CTV we would cut a lot of this interaction. There are also other ways that we're still thinking about that can cut down on a lot of bandwidth and interactions needed when it comes to signing for transactions, which is an essential part of the round that we will always need to do, even with CTV.

But we definitely have to have more real-world usage examples and tests because if we run tests on different servers and such, it's very different than people running on mobile network connections in different continents.

Stephan: I see. Because as you were just saying, it could be a few thousand in each round, and that could mean maybe 50,000 people have an Ark wallet on their phone, but only a few at each time are in a round.

But I guess the other downside to deal with is if these are users who have not done a transaction in a while, then the way phones do their battery management is they'll say something like, "Oh, this app has not been used in a month or two months, therefore, deprioritize it and don't allow it to wake up in the background." So those are things you're dealing with.

Steven: Those are things that we don't have any control over that will depend on the app developers and the platforms that they use.

One thing that's very interesting, I think, is that all these problems in scaling the rounds has to do with the number of users, not the number of payments. So even if users make a really lot of payments, this makes no difference for the limitations on the rounds. I think this is good because we can just scale up our user base and then have them make as many payments as they want. We don't need to limit the amount of payments that you can make.

Stephan: Let's talk about some uses though, because I think it's important to put some practical uses here. As an example, maybe someone who wants to do a non-custodial exchange—maybe they could set up an Ark thing, and their customers who are stacking could get a new VTXO every week. Or let's say they're doing a DCA and they want to buy some every week, they could get new VTXOs until the point that they actually have enough to go onchain, for example.

Practical use cases for Ark in bitcoin transactions; Importance of self-custody in bitcoin

Steven: This is one of the use cases that I mentioned when I was making the case for CTV for Ark. A third party, like an exchange, can actually issue independently using CTV a bunch of VTXOs, and there is no round needed, there is no interaction needed. They can deliver tens of thousands of VTXOs in one single onchain output, and they can do this every hour when they have a lot of usage. Or a small DCA provider can do this every day.

Again, it's not the amount of payments that matter, it's the amount of users that matter. This one can actually deliver a whole bunch of payments in a single output. They can do it every hour, they can do it every day, but this doesn't put a limit on the amount of users that we can have because it's only when we do actual rounds that we need to look for that.

If we start to grow and we have too many users and the rounds are too slow or too full, we can always do more rounds. We can say every half hour, every 10 minutes—maybe we'll have one round per block, and then your confirmation time for your onchain payment is going to be the same as a normal onchain payment because there's a round every block.

Doing more frequent rounds increases the onchain cost for the server, but if there are so many users that actually need this space, we can probably pay for that onchain cost. So I think as we grow and we hit limits when it comes to rounds, we can just have more frequent rounds, and then we will have the usage to pay for that usage of the chain.

Stephan: Interesting. That could be interesting for people who really want to focus on the "not your keys, not your coins" self-custodial adoption. It could be made a lot easier as opposed to pushing a lot of people into custodial, which is where a lot of people are now, whether we like it or not.

I think it's also fair to say it's probably also that a lot of, let's say, Westerners don't have a payments problem today—they have a savings problem. So they're more interested in the hodling and stacking use cases than they are in the actual day-to-day paying for coffee with Lightning and Ark and whatever.

But this might be an example where Ark could be used to have people stacking in a self-custodial way as opposed to putting all that risk into the exchange and the custodian.

Steven: There's definitely a space for custodial bitcoin as well. I think projects like Fedimint, projects like Cashu, and even just fully custodial things like Wallet of Satoshi, or even banks going into the custodial bitcoin space like Revolut and such—I think they have their place.

But I think it's very important for us as a community that it's possible and has a proper user experience when you want to be fully self-custodial. There will always be people who either need this for political reasons, or people who are targeted by the places they live in, or they just don't want to trust the bank.

There are always going to be risks involved with third parties, and at some point, as the amount of money that you're managing gets too high for you to take that risk—and people have different risk thresholds—we feel it's really important that self-custodial bitcoin stays possible and not just for saving but also for payments.

Because right now, like you say, saving non-custodially is very good in bitcoin, but once you want to make payments, most people move into something that is either semi-custodial or fully custodial because it just works better.

And I think, as you say, the West has not much of a payments problem but more of a savings problem, and that's why bitcoin works for them quite well. But I think we're struggling to onboard those people who need the payments more than the savings because the payments user experience hasn't been great. I think if we can improve that, we can get them using bitcoin more as a payment system, and eventually, they will use it for savings as well. Because if they receive their payments there, it's where they're going to save.

Stephan: Interesting. I think some of that comes into just getting more people using even Lightning. I've seen a lot of news recently about Breez SDK getting a lot of progress, kind of getting companies on board—and not even crypto companies, but fiat companies that had nothing to do with bitcoin or crypto are starting to take on Lightning payments. So the more of them there are, the easier it is hypothetically to make or take Lightning payments. Then hopefully there's actually more use for that.

But I think we also have to just be honest and look at the fact that recently there's not a lot of use onchain, and there's a lot of people onboarding through ETFs and MSTR and things like this. So that's just kind of where we're at. Of course, I want more people to self-custody, but we have to sort of see that's where it's at for now.

But anyway, enough about that. Maybe you can help explain for people—I think listeners will have this question—can you contrast between what you're doing and Ark Labs? What's the difference in the approach there?

What is the difference between Second and Ark Labs?

Steven: Well, that's a difficult question because I don't like to speak on behalf of others, but I think I can say that the team at Ark Labs and myself personally—we used to work together in the beginning when we were still very much in the contemplating phase, and then at some point, we just decided to part ways, and we're focusing on different things right now.

I think the biggest difference was that they initially launched on Liquid using the Liquid covenants. They have—they're currently also trying to focus on their main efforts, so on that point, we kind of streamlined again.

I don't really know—I cannot really speak for their focus. We are very much focusing on retail payments. From the communication I hear from Ark Labs, I feel that they're more focusing on Ark as a platform for people to build apps on top and stuff like that, which I think is also valuable. But I think it's hard to balance those things because if you're focusing on payments, you really want to focus on a very specific thing like low latency, small footprints for mobile, and all that stuff. While if you're focusing on platforms, you want flexibility, you want different scripting methods, different contracts that can be built, and stuff like that.

I don't know if that is the way that it will go, but that's one of the main differences that I'm seeing today, other than programming language we use, tech that we use—but those are all minor differences.

I think the good thing about Ark is that, unlike Lightning, which is a protocol network where all the implementations need to be completely compatible with each other because they're just exchanging messages and doing stuff cooperatively between different implementations, in Ark, your server is kind of a bubble. So their implementation, our implementation—even though they're both Ark and it's kind of the same protocol—we can make totally different design decisions. We can have totally different implementations. The API protocol between the users and the server can be totally different.

So we don't need to align on too many things. We can experiment in different directions, and we can definitely learn from each other. We have, on both sides, seen the other side make a certain technical decision that we then realized was actually better and also took. So we're definitely learning from each other, and we'll see how it pans out.

Stephan: On the liquidity constraints question, because this was another thing—in the early days of Ark, a lot of people were saying, "Oh no, you won't be able to do it because the liquidity requirements at the ASP or Ark server would be so high." What's the current thinking there?

What are the liquidity constraints in Ark?

Steven: It kind of ties into what I said in the beginning of the podcast, where we're currently only using rounds for refreshes—to refresh your current, your own VTXO—and not for payments. The liquidity constraints come when users interact with rounds. Actually, the fact that now we're trying to have all the users make their payments offchain, out of round so to speak, in the arkoor payments, there's no liquidity requirement there whatsoever.

So when users do just arkoor payments, it's all fine. And when they enter the rounds, the liquidity constraint has to do with how close the VTXO is to expiring, because we kind of need to bridge the gap until the expiry. It's hard to explain in a few minutes on a podcast, but the fact that users are submitting their expiring VTXOs in a round almost right before they expire really minimizes our liquidity constraints.

So we're kind of optimistic in this current model where most users will feel comfortable enough to hold on to their arkoor VTXOs until they expire and then only refresh a few days before the expiry of the VTXOs, because it really reduces the liquidity constraints from the server point of view.

I think this will be the primary model for most users. The other users that don't like this model and try to refresh their VTXOs more frequently will have to pay their liquidity fee. We still did some number crunching—it isn't that bad. It's probably around what current Lightning apps are charging you, so it's still quite competitive.

So regarding liquidity, we're kind of positive on this note. It was really a big problem when, in this model where it was five rounds, every payment goes through a round, because in that model, the requirement for the server would be incredibly high, and it was really not possible. But the decisions that we made in the design since then have helped us a lot.

Stephan: I see. So basically, that liquidity constraint has come down a lot, or at least the requirement has come down a lot.

Steven: We think it's a lot more efficient when it comes to liquidity needed by the server compared to liquidity or money that the users have than, for example, Lightning. Because in Lightning, your liquidity is locked up, tied to a specific user, and they need this liquidity to be able to receive. But if they're not sending or receiving or doing anything, the money is just there stuck.

In Ark, the liquidity is just one single liquidity pool for all users. So it's way easier to more efficiently allocate this liquidity—it's always there, so it's always usable by all users at the same time. So you don't have to decide, "Oh, is this user going to make enough payments? Is it going to be worth it for me to put this amount of money in there, in this channel with him?" We don't have to make those decisions.

[Ad break: Bold bitcoin platform]

Stephan: When it comes to fees, you're talking a little bit about this. Given that you're focusing on the server side and protocol aspects, and the apps are going to be handling the end user apps, does that mean the app guys are going to be the ones charging the fees? Or are you charging a fee at the server level, and the apps are going to charge their own app-level fee? How would that look?

Understanding the cost structures in Ark

Steven: That's a good question. Currently, what we know for sure is the cost basis that we have as a server. Whenever users do rounds, we need to provide liquidity, and this has a cost. We need to make chain transactions, and this has a cost. So there's definitely a cost for us when users do rounds, and this is a function of how much money is in the Ark because the rounds only happen due to expiry. They're basically users continuing to be part of the Ark.

When they make offchain payments, there's not really a big cost for us. We just need to co-sign some transactions. So we can either just make the users pay for our costs, but we feel that users like to pay fees when they transact and not just to have a balance. There's definitely a psychological aspect to that.

But when it comes to how it will work in the apps, those are really still questions that we have to figure out. We will have to charge a certain fee for our server, and the app provider will have to have their users pay those. I don't know how it will work with them also making something on top of that. Those are things that we will figure out once real apps are going to launch on mainnet, and we're going to have a bit of an open question as to what the business models will be.

Stephan: But theoretically, you would charge some kind of liquidity fee and kind of service and protocol fee at your level, and then the app guys are going to have to add something on their level too, and the end user will pay the combined fees.

I'm curious from your perspective—again, it's an open question, we don't know—but do you think those two combined fees that we were just talking about will be less than Lightning, like a Phoenix user or a Zeus user, this kind of thing? Or it'll be in the same ballpark, or less? What do you think?

Steven: I don't know the latest on fee schedules, but when we started the company, we were crunching some numbers, trying to do some math, and what we came up with was that just to hold money in the Ark continuously with the parameters that we chose at the time—like 1-hour round, 30-day expiry—it would be around half a percent of your money that you would have to pay every year to keep the money in the Ark securely.

We set some pretty conservative trust barriers there, like with the number of days before the expiry you actually go and refresh. I think at the time, half a percent was basically what Phoenix charged on receiving your money anyway. When you receive from onchain into your Phoenix wallet, they would charge you half a percent anyway. So just having a single receive is the same as having your money for a whole year in the Ark.

When it comes to individual payments, our cost base is so low, we can go really competitive, I think. But again, there is a cost base just to have your money in the Ark. So it's definitely not something where people will be holding their entire savings, because it might be cheaper to make a single offchain payment and then hold your money there for 20 years instead of in the Ark.

But I feel we can be really competitive on that front just because our liquidity management is very efficient. We just have to do the math.

Stephan: Interesting. I could probably look it up, but off the top of my head, I think the Phoenix fee, the async fee, I think it's on payments—it's 0.4% of the amount you're sending. So on $1,000 of a payment, it's like $4 worth of transaction fee. But also there's a swap-in fee, so if you take an onchain payment and you want that available in Lightning, I think that's 1% plus the mining fee, something like that. It's in that ballpark.

So I guess it'll depend, but also I think we have to remember what was the purpose of all this—the point was to make it easy to onboard. And if this is easy to get people onboarded, then maybe people are okay to pay a different fee, whether that's a bit more or a bit less. I don't know, maybe it's a different user experience.

I think one thing that was kind of topical was—I don't know if you have an opinion on this—but Orange Pill app, they're an app for kind of meeting, and they recently launched a custodial Lightning wallet. Then there were a few people saying, "Oh, why'd you do custodial? Could you have done some other thing?" In this case, would Ark—now again, you just launched on signet, not on mainnet—but hypothetically, if this was available on mainnet, could that have been an option?

The role of custodial solutions for onboarding users; Plans for mainnet launch

Steven: Definitely. That's definitely the kind of target integrator that we have. If you visit our website, it's one of the main talking points that we have—that we want to make it as easy as possible for an app developer to integrate Lightning.

So we want to have a very intuitive and simple SDK where you basically have some API calls from your wallet that holds you a balance that you can both make Lightning payments with and onchain payments with. That's basically the experience that we want to give to the developers.

So any DCA company that wants to have a built-in wallet, any wallet that wants to have a bitcoin wallet with a Lightning wallet combined, can definitely use our SDK or should try to start using our SDK because that's definitely what we're targeting for our product. So something like Orange Pill app is definitely yeah...

Stephan: Gotcha. But I guess for now it's early days because you're in signet. But once you—maybe it's again, you don't know yet—but do you know when you would look to go to mainnet? Are you going to try to go to mainnet in a year, or six months? Do you have an idea, or not yet?

Steven: Personally, I would really like to have mainnet by end of summer or something. But you know how engineering goes—hopefully this year would be really good. But I guess it also depends how things go in signet with people playing around.

Stephan: Definitely want some testing...

Steven: Yeah, exactly. And we definitely want to look for some integrators who are willing to take the first step, be the first mover, and already integrate even though we don't have mainnet yet. Just to see where the pain points are because it makes little sense to launch a mainnet and then realize that our product is not really easy to integrate with on mobile, just because of the mobile challenges.

So we want to learn first and, at the same time, make our server more robust, because the server still also has a lot of work to do. And then have our client be flexible enough to actually be an easy-to-integrate product.

Stephan: I think we touched on this a little bit in terms of business models. Like you're going to charge your fee, and the app creators are going to charge their fee. Are you going to be the only type of Ark server for what you're doing, or is the idea that there would be competing other Ark servers doing the same protocol? Can you explain a bit on that?

Is there a possibility of competing Ark servers in the future?

Steven: All our code is fully open source. We don't have heard of much interest from other parties for now who want to set up Ark servers. It's definitely not as easy as setting up a Cashu mint or something like that—it's a bit more involved.

Also, the amount of liquidity you kind of need to service your users in a proper way is going to be a bit high. We don't really imagine that it's a "run the node from your home" kind of product. It's definitely possible for other parties to set up Ark servers, but we don't really have a lot of interest in that for now.

I think we will probably be one of the first or the first, right? Because it's our own software, it's our own product. So we'll probably be the first, and maybe for a long time, we'll be the only Ark server providing this service. But who knows—if it picks up and people really realize that this is a really good product to integrate for your wallets, maybe some larger parties will also run a server.

Stephan: I see. It's possible that some big exchange, let's say they want to do it, they might be like, "Hey, we'll just run our own Ark server." That could happen.

Steven: And I think from the user experience point of view, I think most app providers, just to make the user experience easier, will pick one server and just have this one as the default. But it's definitely possible that there are apps that let you choose a server, maybe even with a QR code where you can say, "Okay, I want to be part of this server." You scan a QR code, so you get all the details to be part of the server. Those things are possible.

We currently just focus on building our own server and then have the clients communicate with that. But everything is made—everything is ready for other people to run the same server.

Stephan: I see. But I mean, presumably, this is sort of very cutting edge, bleeding edge sort of stuff, so you kind of need to be someone who really intimately understands it. So it's probably not that easy for just another developer to kind of pick it up and run their own thing. They would really have to understand the nuances of it.

Steven: Exactly. In our benefit, I always think it's not easy to trust a server that someone else has built with millions of your own money. So I think we have an edge over other companies trying to run servers because we wrote the code. We understand kind of where you need to be careful.

So we will always have some kind of benefit in that sense. But who knows—if this product matures a lot, maybe there will be others. Maybe they will talk to us to have a support contract or something like that. That remains to be seen. Currently, we're focusing on having a service that runs and then users that can talk with it.

Stephan: Gotcha. One other question around the liquidity—just because I'm curious as well—as you were mentioning, the cost at least from a liquidity requirement at the Ark server level is if the end user wants to do a refresh of his VTXO well before it expires. Is my understanding correct?

Liquidity management & user fees

If my balance is 1 million sats and I want to refresh it one day before my expiry, that's not a very high liquidity requirement on you, the Ark server. But if I'm a baller and I've got 50 bitcoin or something—some ridiculous amount—and I want to refresh three weeks before my expiry, that places a much higher liquidity requirement. Am I understanding that correctly?

Steven: Liquidity is a simple multiplication. It's like the amount times the number of days or times the time. So if someone has one bitcoin and they're going to refresh one day before expiry, it's like one bitcoin-day that we have as a liquidity cost. If they want to do it one week before, we will have seven bitcoin-days liquidity cost. So it's literally a linear function.

What we will have to do is just charge them a certain fee on the bitcoin-days that they take—that they want us to provide this liquidity. So if you want to refresh earlier, you're going to pay a slightly higher fee. If you're going to refresh later, you're going to pay a slightly smaller fee. I think it can be pretty transparent.

One of the other numbers that we crunched in the beginning was the worst case. Let's say you want to refresh immediately. So you receive an offchain payment, it has still 30 days to go, you want to refresh it immediately over 30 days. I think the cost with some reasonable market rates that we found online was that it would be like 0.1% for the worst case. So it's still doable to pay 0.1% on a payment if you want full self-custodial security.

I think like you just mentioned the numbers from Phoenix—it's kind of still better than Phoenix, even though...

Stephan: I guess some listeners might also be curious: is there any way to be a liquidity provider here, or is that more like it's centrally managed by your company?

Steven: It's not like other people can provide liquidity here, definitely not in a trustless way. We, as our company, will not have all this bitcoin to provide this liquidity, so we will also borrow it from liquidity providers. But this is more in a trustful way. There's no way to use the bitcoin blockchain as a contract so you can trustlessly...

We've been doing some thinking. There are certain few tradeoffs that we can make to give liquidity providers a few more guarantees than just fully blindly trusting us, but it's a bit hard to do. It's never fully waterproof. So I think it's better to have just contracts and agreements that make sure that those things happen.

Stephan: Right, it's the course. I mean, between large businesses and banks and custodians and exchanges and all this—that's a different kettle of fish than the typical "not your keys, not your coins." And which is another reason why I don't imagine that groups of friends will run their own servers, because they would just need a lot of liquidity. The liquidity requirements would just be so high that it just wouldn't be practical.

Steven: Yeah, gotcha.

Stephan: Okay, so just to be clear, we've spoken about, I guess, effectively what we've spoken about today is known as clArk, right? Like Covenant-less Ark. So just to make it clear for listeners, this is today without protocol change, without a soft fork of bitcoin.

I'm just curious as well to understand a little bit of your view on Ark with CTV or TXHASH or something like this. What would be concretely enabled by this, and what kind of efficiency gains do you see being possible there?

Ark's future with CTV

Steven: That's a good question. The current implementation that we're building is built on what we call co-signing. So the whole transaction tree, instead of being non-interactive, it's co-signed. All the users who are part of the tree need to put some signatures there, and all the transactions have signatures on them, and then they cannot change anymore if just one of the parties who are participating holds up the contract of the co-signature.

With CTV, you can just remove all of the signatures, all of the messages that need to be passed beforehand to make the signatures, and just immediately, the server can create the whole tree of transactions with all the different VTXOs in its leaves and just send them to the users and say, "Here, this is the tree that we're going to do for this round," and then immediately move on.

So there's definitely, primarily, a lot of efficiency gains. It reduces the protocol from being a three-step to a two-step process. It reduces the amount of data that needs to be passed. Especially on mobile, I think this can be a big benefit.

But then there are also a few things that are just not possible. The main way to think about it is that with clArk, the person who will eventually be the owner of a VTXO needs to be present when the VTXO is created, because otherwise, it's not trustless. Because they need to sign all the transactions that lead up to their VTXO. So if they're not present, it's not possible to create a VTXO for someone else in a trustless way.

There are a few things that would be enabled if it would be possible to create a VTXO for someone else.

One of the things is, as I already said before, some big payout provider like an exchange or a DCA provider, or even a miner—because this is also very interesting, I think, for miners—they cannot just create VTXOs for their users. With CTV, they could do that. They could basically create their own tree of VTXOs because a VTXO is just an onchain contract with a certain template. So anyone can create a VTXO for a certain Ark.

So then, for example, an exchange could just create a whole tree with 10,000 different payouts of different VTXOs, deterministically created using CTV and unfund the output, and suddenly tell the users, "Hey, here you have bunches of VTXOs" without needing the users to be there. I think that's something very powerful.

Another thing is, for example, for Lightning receives—as users might have noticed, it's not something we support right now in our signet. We had some ideas, we were refining the ideas still, and we didn't want to hold up doing this signet launch until we had everything figured out. But we have a version now that we're testing in our tests.

Lightning receive is a little bit more involved to do because, somehow, if your user doesn't have anything in the Ark and you want to receive some Lightning, there needs to be something created for the user in the Ark. With CTV, it would be a little bit easier because then the ASP could just create a VTXO with an HTLC again, but then an incoming HTLC, not an outgoing one. The user just gives the preimage, and from that point on, the user owns the VTXO.

Without CTV, the user would have to somehow be woken up like, "Hey, hey, you're going to receive a Lightning payment," and he needs to enter the next round, be online for maybe half an hour to wait for the round to start, and then do the whole shenanigans of participating in the round to then have their Lightning payment, instead of having just one message signature and done. So for Lightning receives, CTV also is very useful.

And then the last big thing is something that we want to provide as a service: when users forget to refresh their VTXOs before they expire. Your phone goes down, or you don't have internet for a week because you forgot, or like you say on iOS, your app got killed and it didn't manage to just wake up to refresh.

There are going to be cases when users forget to refresh their VTXOs in time, and they're going to expire. Obviously, we as the server don't intend to just take the money and be very happy with it. No, we want the user to have the money back.

What we want to do, and what we can do with CTV, is immediately when it expires, immediately reissue the VTXOs again, so that the users, when they come back online one day too late, will see, "Ah, okay, my money is still here, and it's still in a trustless VTXO." So then there's only this split second where the ASP could have done something bad but didn't.

It's actually also possible for the ASP to continuously cryptographically prove like, "Hey, we didn't take any money, we didn't take any money, we didn't take any money." So someone who's monitoring the server can basically guarantee, "Okay, this server has behaved well since its inception, and it has never taken anyone's money." This should give a little bit of a guarantee to users to put a little bit more trust into this server.

But without CTV, this is also not possible to do because you cannot recreate these VTXOs for the user. The user would have to be present for them to be created. So with CTV, we can just always see, "Oh, this VTXO expired; immediately we create them again in the next block." But that's not possible without CTV.

Stephan: I see. So just to clear up, to summarize, you've got this mass payout use, like the exchange/custodian, the trustless Lightning receive, and then also the refreshing case.

Steven: Oh, and one that I forgot—another one is just sending payments in rounds. Currently, we send out of rounds, and we use the rounds for refreshes. This is because the receiver needs to be online, and the sender always needs to be online, and it's kind of annoying to have them both need to be online. So when you do a refresh, the receiver and the sender is the same person, and since the sender has to be online anyway, he's also the receiver, so it doesn't add any interactivity requirements.

But with CTV, you could also send the VTXO immediately without having to use arkoor to someone else. Arkoor is usually the better option, but if you really want something—I don't know, if you're doing like plus $100K or something like that, you're buying a car or something—you might want to send something in rounds, and that's currently just not possible, while with CTV you could just say, "Hey, I'm sending this VTXO to this person and not myself," and then it would be possible.

Stephan: Interesting. As I'm understanding, the point here is—at least the approach that the Ark teams, both yourself and the other Ark Labs team, are taking—is more like, "Let's build with what we have today." But I guess you're also separately trying to explain and show, "Well, if we had CTV or TXHASH and so on, these are the efficiency gains we could get."

But the point is to show: at least today, can there be users, can there be some kind of efficiency or at least some kind of onboarding use case even with clArk as it exists today, before adding CTV and all these things, right?

Steven: Definitely. We're definitely confident that we can build something that is already a good benefit over lots of the current self-custodial Lightning experiences just with what we have today in bitcoin, in the clArk version, the Covenant-less version.

We're also in a very good position when it comes to covenants because, in theory, any covenant possible would make a difference for us, would make it better for us. So we just want something to happen at some point, and then we will be happy. It's not like we need something very specific.

So we're definitely in the covenant camp, and we're definitely trying to make bitcoin better also on this front, also to enable lots of other things that have nothing to do with Ark. But we're also not too worried or not too time-sensitive because what we're building right now, I think, can be very valuable as well without having the covenants yet.

If this wasn't possible, we wouldn't be building it today because it's a lot of work, as you can see. We've been six months in or even more, and we still have some work to do. But of course, we want to deliver user experience—we don't want to be waiting on the bitcoin protocol to upgrade before we can deliver that.

Stephan: I see. I don't consider myself a technical protocol expert or anything, but from your perspective—you're someone who's really deeply into this—can you explain your thoughts on it? It seems like developers are excited about CTV and CheckSigFromStack. Can you explain a little bit of your perspective on this? Why is this a useful path forward from your perspective, and what do you see being enabled by CTV and CheckSigFromStack?

What is the potential of CTV and CHECKSIGFROMSTACK?

Steven: The people that are following—there's been some noise or some movement around the CTV plus CheckSigFromStack package as a potential software upgrade. It mostly started from some Twitter things going on, and I posted some kind of roadmap that I thought was a good roadmap. Obviously, it was Twitter, so I hadn't thought a whole lot about it. And then people started to be a little bit interested in this.

One of the main points that I found compelling in this is that CTV and CheckSigFromStack are both very simple primitives. They're very technically well specified, and there's not much bikeshedding potential. They're all several years old—CTV has been proposed maybe like four or five years ago, quite some time ago, and CheckSigFromStack has been in Liquid since seven years ago. They're both doing a very specific thing.

I think since they're going to be useful into the future anyway, even if we have more complex covenants like CheckContractVerify or TXHASH or stuff like that, or direct introspection, I think having either CTV and CheckSigFromStack are going to be useful anyway. So my point of view was: if we're going to use them in the future anyway, why not already add those while we work out which other things we think are useful?

I mean, any software upgrade that enables covenants in a good way is going to involve multiple moving parts that are a little bit independent from each other. I don't think we need to package everything in one go and say, "Okay, this is everything you need to do the perfect covenants," and then do it in one go. I think it makes sense to first start with some smaller building blocks and then see which other building blocks we want to build on top of that. I just thought CTV and CheckSigFromStack were really good small first building blocks.

Independently, they don't enable everything that we want to enable with full covenants—they don't, they're not magical tools, they're quite simple—but there are still, I think, quite some compelling things that you can do using CTV and CheckSigFromStack. Things like L2 like the Lightning symmetry that people have been talking about for a long time. The Lightning symmetry has gone up and down a little bit among Lightning developers, but I think it's still something that many Lightning developers are very excited about.

All the things I mentioned with Ark you can do, and then there are some smaller optimizations or changes that can be made to things like DLCs, to things like even very primitive vaults or stuff like that.

There's a lot of discussion of "Can we really say CTV can do vaults? Can we really say CTV can do X or Y?" And it's like, yeah, maybe not the way we really want this to be done, but we can already move the needle a little bit forward and then see what else we need to make the full vaults, the full coin pools, the full like BitVM-like offchain proving protocols.

I think we're a bit far from having the full covenant package figured out, and I think we have iterated and thought enough about CTV and CheckSigFromStack specifically that we can enable them. We see some value in them, and we can keep them even when we move beyond, even if we move into more elaborate constructions like the full covenants. But it's definitely a difficult topic to talk about.

Stephan: And I get the sense, or at least from what I'm seeing, some developers are saying is that these are small changes that are relatively well understood. Do you think the, let's say the naysayer might look at that—I'm not a naysayer myself—but could a naysayer say, "Well, I'm concerned there could be some kind of deep implication. If you create this or you enable this, you're going to enable some other things that they don't want"? I'm curious how you see that or how you think about that.

Steven: Specifically, these two opcodes are so basic, it's really hard to do any cool stuff, basically. That's where the discussion also halts a little bit, because for some people, it's like, "Oh, we can't do enough. What this enables is not enough to convince us that we should do a soft fork." Because a soft fork is not something you just do every day. So some people are like, "Okay, sure, you can improve Ark and do L2, but is this enough to do a soft fork?"

Stephan: Too small to bother...

Steven: Exactly. On this argument, I don't think it would upset any naysayers or people who are afraid of fully recursive covenants or whatever they are called—these more elaborate constructions that covenants can give, things like market makers, things like coin pools. There's nothing like that that's kind of possible in a real way to build with this.

So that's for me one of the compelling arguments—that we can already innovate, even if it's a little bit, on Ark, on Lightning, stuff like that, without having fully figured out as a community what kind of covenants we're scared about when it comes to mempools or something like that. What kind of covenants do we really want to build? Which ones do we not want to build? How do we want to build them? Because we still have several different proposals on how to build good covenants in a good developer-friendly way and in a network-safe way.

So while we still figure those things out, I think those two are tools that can be used in surprising ways. Like I said, CTV has been around for something like four years (since 2019, I think, so maybe like five years), and only last year someone came up with Ark. I mean, Ark is something that was actually entirely built on CTV. We kind of made tweaks to not need CTV in the end, but it was totally built on CTV, and this was 3 or 4 years after CTV existed.

So people still have a lot of room to figure out new cool things, and I think if we enable them, people will move the barrier and how far they can think into possible protocols a bit further. So maybe there's going to be something really cool that CheckSigFromStack and CTV enable that we only find out 2 years after it's been activated, but you never know.

Stephan: And I think it would be—it sounds like from what I've heard from developers, it sounds like it would really get us more efficiency, whether that's Lightning and Lightning symmetry or L2 or DLC or whatever the different forms people are talking about with that. Or on the Ark side, the improvements you've mentioned there.

But I guess it'll take some time, and maybe people have to sort of see some people using, let's say, clArk, the covenant-less form of Ark, and then maybe after some time of that, then they think, "Okay yeah, let's—we want CTV and CheckSigFromStack." I mean, who knows, right?

So let's close up. If you have any closing thoughts on bringing it back to bitcoin today, what's possible today with Ark—can you spell out for people what are they missing? What is the big takeaway that you think most bitcoiners do not understand about Ark and what it can do for people?

The importance of Ark in bitcoin's ecosystem

Steven: The biggest one is that it exists. I mean, we're actually building it. We're targeting for mainnet, and currently, you can try it out on signet. So like, go try it out because it's actually a thing. It's actually making Lightning payments possible without all the headaches that traditionally came with Lightning.

We've talked with several wallet developers who have tried to integrate Lightning. They have tried different approaches, different stacks like the Breez stack that is now based on Liquid or something like that, or the Greenlight stack that also has a different approach. They've tried several of them, and they were not very satisfied because there's always a little bit of hurdles that they don't want their users to need to take on.

With Ark, the user experience is just slightly better than all that, even without covenants or even without whatever. Today on bitcoin, we can have an experience that is better than what we have today. It's way easier for developers to actually give this experience to their users.

So yeah, try it. We have the tutorial and the things up if you go to second.tech, and you can just play with it. We have a little store where you can pay some Lightning payments using Ark. We have a faucet where you can get some Ark coins. And the next step will be making this SDK implementable in mobile wallets or mobile platforms.

Stephan: Excellent. Let's see, maybe this will be a good way to onboard people where those people would have otherwise been custodial. So I think that's something that, let's say, most of us who are ideological bitcoiners would like—we want more people to use "not your keys, not your coins."

So yeah, let's leave it there. Listeners, check it out—links will be in the show notes. And the website again is second.tech. Steven, thanks for joining me today.

Steven: Awesome, yeah. Thank you for having me.

Today we're launching our implementation of the Ark protocol on signet. This is our first major step toward bringing Ark to bitcoin mainnet, and we're inviting the developer community to help us test, explore, and break things (preferably in that order).

Get your apps ready for Ark's launch

The Ark protocol is a new bitcoin layer two that enables fast, low-cost payments without sacrificing self custody.

Ark offers bitcoin users a whole new way to transact, while also making it much easier to deliver self-custodial Lightning in your apps.

But Ark is unlike anything built on bitcoin so far, so there are a few new concepts to get to grips with, like sends and refreshes, rounds and expiry, and off-boarding and exits.

If you're interested in being a first mover, the time is now to start getting comfortable with the tech. Nothing beats getting hands-on.

Why signet?

Ark is still in alpha, and it can lose you sats. There's time for recklessness, but now isn't it. Signet provides the perfect sandbox—a bitcoin testnet with predictable block times and network conditions that closely mirror mainnet.

Testing tools at your disposal

To make testing as straightforward as possible, we've created two companion tools:

Signet faucet

No one likes having to hunt down signet sats. Our faucet makes it simple to request signet sats over both Ark and "on-chain".

Test store

Somewhere to spend your signet sats. Buy Byte treats on our simple test store that accepts signet payments over Lightning (bark supports sending Lightning payments!)

Collecting usage data and feedback

This signet deployment is also going to help our team prepare for mainnet launch beyond basic bug hunting. We're especially interested in getting some basic usage data so we can begin optimizing our liquidity management (both Ark and Lightning liquidity). Data from testers is not going to match real-world usage, but we have to start somewhere!

It's important to gather feedback on the developer experience too, so make sure you share both the good and the bad!

Work in progress

One feature you'll notice is conspicuously absent: Lightning receive functionality. We're aware of this limitation and actively working on it.

We also haven't yet implemented any transaction fees—we're still researching what makes most sense here. If you want to send free transactions, now is the time 👌.

Subscribe to be first to hear about updates.

Get started

The fastest way to get started is to follow our new signet testing guide. That covers everything from getting bark running on your device (Linux, macOS, and Windows supported) to funding the wallet, to making payments over Ark and Lightning.

Let us know how you get on in our new forum and thanks for helping us pioneer the next frontier of bitcoin payment tech!

We’ve made arkoor the standard for payments on our Ark implementation. Instead of offering users the option of making either out-of-round (arkoor) or in-round payments, all payments will be arkoor by default, with in-round transactions reserved for refreshing VTXOs only.

We took this decision after our tinkering indicated that an arkoor-first policy helps on multiple fronts:

• Expands device support by reducing the interactivity between wallets and Ark server.
• Offline receive enabled on wallets by default.
• Makes the Ark server more reliable with less failed rounds.

Moreover, there are no security trade-offs as long as the receiver chooses to “refresh” into an in-round VTXO in the round immediately after receiving a payment. This takes the same amount of time it does to receive an in-round payment directly. 

Don’t worry, you won’t even notice—Ark payments will be swift and your bitcoin will be self-custodial.

Let’s dive into our motivations and how the new policy works in more detail…

A brief recap: In-round vs. arkoor

There are two ways of constructing a transaction (VTXO) on Ark: 

For more details on how each transaction type works, see our docs.

Interactivity hurts reliability and UX

In a successful Ark round, all users and the Ark server will together construct various transactions and sign them. Users connect to the Ark server to coordinate and aggregate transaction data and signatures.

Reliability issues of in-round payments

Each round has three phases of interaction.

1. Transaction registration (senders): Senders register their transactions. They tell the Ark server which VTXOs they want to spend and what VTXOs they want in return.
2. Tree signing (receivers): All receivers sign their branch of the tree.
3. Forfeit signing (senders): All senders sign the forfeit transactions. The forfeit is conditional on the round coming through.

At each phase in the process things can go wrong. An honest client might lose their internet connection and fail to provide the required signature. Or a malicious client could Denial of Service (DoS) attack the round by providing a faulty signature. In either case, the round must be aborted and restarted.

While an Ark server can defend against DoS attacks by banning misbehaving clients, it’s still unavoidable that the more users you have using in-round payments to send to one another, the higher the chances of failed rounds occurring.

UX issues of in-round payments

Then there’s the UX issues of in-round payments. Our current line of thought is to perform a round every hour. This means that an Ark user has to wait up to an hour to attempt the payment. And if the receiver isn’t online at the time, the payment will fail and the sender has to wait another hour for a second attempt.

An in-round payment also requires both the sender and receiver to be online throughout the round—a burden for the sender to coordinate.  

A naïve solution: Sender-signed trees

Sender-signed trees were our first attempt to tackle the problem. In this concept, we modified the round-signing ceremony so that senders could perform all the steps without any signatures from the receivers. This eliminated the need for both sides to be online during the round.

Sender-signed trees result in a slight change to the phases of interactions:

• Transaction registration (senders): Unchanged.
• Tree signing (senders): All senders sign the full tree (not just their branch).
• Forfeit signing (senders): Unchanged.

However, this approach resulted in a new problem: the receiver no longer had a signature in the tree, without which, they couldn’t be absolutely certain that nobody could change the tree with their permission.

In practice, we expect trees to become quite large, making it feel relatively safe to assume that at least one out of, say, 100 senders (or the Ark server) is acting honestly. However, this assumption can create a false sense of security, as the Ark server could launch a Sybil attack on the receiver. A receiver might believe their transaction is secured by hundreds of independent senders when, in fact, all the senders are the Ark server in disguise.

We are not aware of a practical defense against such a Sybil attack and we have abandoned the sender-signed tree concept.

A better solution: Pay out-of-round and refresh in-round

Eventually, we realized the solution was much simpler—just make arkoor transactions the default and reserve in-round transactions to “refreshing” balances only:

1. Sender creates an arkoor VTXO.
2. The Ark server cosigns the VTXO.
3. The sender delivers the cosigned VTXO to the receiver via Ark server or any other channel. 
4. The receiver chooses to refresh the VTXO in-round in the upcoming round (higher cost), or wait until close to expiry to refresh (lower cost). 

In this model, payments are completed instantly and receivers do not need to be online at the moment of payment. The receiver only needs to come online when they want to perform the refresh. 

The model also significantly reduces the amount of interactivity required by Ark participants each round. Instead of our original sender-receiver round process:

• Transaction registration (senders)
• Tree signing (receivers)
• Forfeit signing (senders)

We now get a receiver-only round process:

• Transaction registration (receivers)
• Tree signing (receivers)
• Forfeit signing (receivers)

In any one transaction, only one user needs to be online. It’s kind of like the receiver is sending transactions to themselves to gain additional security. If the receiver is not online, they simply don’t participate in the round. This will drastically decrease the occurrence of connectivity issues causing rounds to be aborted and restarted.

What if the receiver prefers in-round payments?

This all sounds great, but what about user choice? Isn’t there a security trade-off with arkoor? What if the Ark server and the sender collude?

In practice, the receiver doesn’t lose any security compared to direct in-round payments. 

If they prefer in-round VTXOs and choose to refresh their arkoor VTXO as soon as possible, they obtain an in-round VTXO in exactly the same amount of time it takes to receive an in-round VTXO direct from the sender. But they enjoy the additional benefit of receiving an earlier assurance of the payment via the arkoor VTXO:

The only trade-off is that the liquidity fees of the in-round transaction must be borne by the receiver instead of the sender. 

How will this change benefit you?

As a sender, you'll be able to “fire and forget” your payments. As a receiver, you'll be in full control of the security model you want to use and can adapt it to your use case.

Some examples:

• Low-value retail: Alice runs a lemonade stand and sells lemonade for 1,000 sats (~$1). Performing a unilateral exit on a single 1,000 sats VTXO is not economically feasible, so Alice chooses to not refresh her arkoor VTXOs immediately after every sale. Instead, at the end of the week, Alice refreshes all her VTXOs into one aggregate VTXO. This VTXO is sufficiently large to perform a unilateral exit (if she ever needs it) so is worth covering the cost of refreshing in-round.
• High-value retail: Bob has a shop that sells computers for 1,000,000 sats each (~$800). Bob only wants to ship a computer once he is absolutely sure the payment is secure. Bob sets his wallet to refresh his VTXOs every morning so that he can ship all pending orders.

Note that in-round transactions come with a real cost because the Ark server needs to pay on-chain fees and allocate capital to make them work. In our new arkoor-first model, the receiver is in total control and can adjust costs based on the security model they need. 

What does the future look like?

In light of these changes, we’ll have to update our nomenclature. The distinction of in-round vs. out-of-round payments isn’t useful anymore. From now on we will simply talk about:

• “Payments”: Assumed to occur out-of-round.
• “Refreshes”: Refreshing arkoor and/or in-round VTXOs into new in-round VTXOs.

We’ll also keep looking into ways to reduce interactivity. For example, if we get covenants on bitcoin, we can completely skip the second phase of the round process in which the tree must be co-signed by all users.

The new arkoor-first model makes Ark more reliable, intuitive, and puts users in control of balancing cost and security. We’re working hard to get it in your hands soon!

To keep up with Ark protocol progress, sign up to our newsletter. Monthly, no spam, unsubscribe at any time.

Bitcoin Core released a major update to bitcoin’s relay policy in v28, introducing the first iteration of a new feature called package relay. Package relay enables multiple transactions to be packaged, broadcast, and relayed together, and is a huge improvement for layer twos like Lightning and Ark, making the protocols more reliable in emergency situations and less expensive to use. 

It’s an underreported update that’s great for bitcoin users, so in this article I’m hoping to give it the attention it deserves and describe how it’s made our work at Second a lot easier.

Transaction relay and relay policy?

Transaction relay is the peer-to-peer mechanism through which bitcoin nodes share bitcoin transaction data with each other, ultimately passing the data to miners to commit to the blockchain.

This process is governed by a relay policy, a filter which prevents spam transactions from entering a node’s mempool and crowding out legitimate transactions. Most nodes rely on the default relay policy settings, though operators can adjust these based on their needs.

You might think that this system already works great—your bitcoin transactions have all made it into a block and been confirmed without an issue. But unfortunately, the relay policy was not designed to support the exotic off-chain payment schemes that are emerging on bitcoin, for example, those used by the Lightning Network and the Ark protocol. 

How is the relay policy relevant to Ark?

Similar to Lightning, Ark users rely on pre-constructed transactions to protect their balance and retain self-custody. These transactions—VTXOs—are normally held and transacted off-chain, but at any time, a user can broadcast their VTXOs to the network to complete a unilateral exit and retrieve their bitcoin on-chain. 

A transaction fee must be baked into a VTXO when it’s created, so under the old relay policy, users (and wallet developers) would struggle to decide on what fee rate to use. They basically had two options: 

• Underpay: Assign an acceptable fee for the fee environment at time of creation and hope the user doesn’t need to broadcast them during times of on-chain congestion.
• Overpay: Assign an excessively high fee to “future-proof” the transaction for possible on-chain congestion.

But either way, there was no way to guarantee a transaction would make it past the relay policy filters when the time comes, never mind into a block.

Unilateral exits are always performed in an emergency scenario, and have strict deadlines, so it’d be a big problem if a user couldn’t get their transaction relayed because all nodes think it’s spam!

Does CPFP not fix this?

Some readers may be thinking that the obvious solution, to overspending at least, would be to always set a low fee rate on VTXOs and rely on child-pays-for-parent (CPFP) to accelerate any unilateral exit transactions that are not getting confirmed. 

CPFP is a widely used method to unstick a low-fee transaction by creating a second child transaction that spends from it but includes a higher fee rate. Miners, incentivized by the higher fee on the child transaction, must first mine the parent transaction to validate the child, effectively unblocking both transactions together.

But it’s not that simple. Using CPFP you can only bump transactions that can make it into the mempool. If the parent (unilateral exit) can't enter the mempool because it pays insufficient fees, the child transaction will be refused because the parent doesn't exist. CPFP only works if both the parent and child transactions are in a miner’s mempool at the same time.

Arkoor chains and disappearing sats

Ark’s out-of-round (arkoor) payments were particularly problematic. 

Arkoor payments are the primary way to send VTXOs between users on Ark because they can be completed without the time-consuming interactive process of rounds (as required by in-round transactions). 

Although the vast majority of arkoor VTXOs will never see the bitcoin blockchain (this would only happen in a unilateral exit), we still had to hard-code a 1 sat/vbyte base fee rate to ensure they could get through the relay filters and into mempools if required. Of course, this wouldn’t guarantee they’d get confirmed, but the assumption was that wallets would use CPFP to pay the actual fee required.

This hard-coded fee meant that even the smallest payments on Ark would always lose a few hundred sats—very annoying. And because the transactions would typically not be mined, the fees would seemingly go nowhere (actually picked up by the ASP after VTXO expiry).

Core have cracked it with package relay

The smart trick the Core team have come up with to solve these issues (and more, see below!) is called package relay. Included in the Bitcoin Core v28 release in October 2024 is an early iteration of package relay, which enables nodes to bundle and relay two dependent transactions together as a single package, allowing mempools to evaluate their combined fee rate rather than assessing each transaction separately.

While the functionality is currently limited to two transactions in a single parent-child relationship (a structure referred to as “one-parent one-child” or “1p1c”), it’s already a powerful improvement for protocols like Ark that depend on CPFP constructions.

Ark users can now reliably set their unilateral exit fees at the time they make their exit, without worrying about whether the parent transaction will be relayed. And wallet developers no longer need to hard-code wasteful fees of 1+ sat/vbyte into every transaction. By bundling a unilateral exit transaction with a child transaction that pays an appropriate fee, Ark users can be confident that both transactions will reach miners’ mempools as a package.

Zero-fee transactions are now viable

Another consequence is that the bitcoin network now reliably supports zero-fee transactions. A child payment can get any parent payment through the relay policy spam filters, no matter how low its fee is, even zero! 

This solves arkoor’s “disappearing sats” problem, we can now simply set the on-chain fee rate for all arkoor VTXOs to zero, and a user can pay the appropriate fees in a bundled child transaction if they ever need to use their VTXOs to make a unilateral exit.

Benefits beyond Ark

We’ve focused package relay’s impact on Ark, because Ark’s what we do, but there are a number of other great benefits from package relay for the broader bitcoin ecosystem that’re worth mentioning here:

• Mitigating transaction relay attacks: DoS attacks enabled by the nature of bitcoin’s relay policy, such as pinning and transaction cycling, can now be overcome by “forcing through” targeted transactions with 1p1c packages. This is possible because the 1p1c package relay also enforces some restrictions on the children that prevent many of the attacks (TRUC).
• Improved transaction conflict handling: Off-chain protocols rely on UTXOs that can be spent by multiple users. The relay policy can sometimes cause the “wrong” transaction to be prioritized in the mempool, but now wallet devs can overcome this with higher fee 1p1c packages.
• More reliable Lightning channel closures: Like Ark, Lightning relies on pre-constructed off-chain transactions (commitment transactions) that are broadcast later. Package relay ensures these can be relayed and confirmed more reliably with optimized fees.

Final words

Package relay might seem like a simple improvement, but it is only a small part in a larger project that is still very much in development. We will only get the full benefits of generalized package relay once we improve the internal structure of the mempool. This is being worked on in a project called cluster mempool. We’re grateful to the Core team for putting in the hard work to make this happen. These are some of those thankless, seemingly obvious features that miss the spotlight but will have a big impact on Ark, Lightning, and more.

On Friday, September 20st, 2024, we gathered for a video conference with one goal: make some of the first Ark payments on bitcoin mainnet.

We invited some notable bitcoiners and early contributors to the Ark protocol to join us on this adventure. Among the group were Stephan Livera, Marty Bent, John Carvallo, Vivek4real, Jonas Nick, Robin Linus, and Super Testnet.

Steven Roose, our CEO at Second, kicked things off with a short intro:

Nothing we’re doing today is faked. But, just so you know, I’m obviously sweating because the software is still experimental and fragile. To the developers: please stick to the script—no one needs to break things… at least not yet. You’ll get your chance after the call!

Over the past few months, we’ve implemented an ASP (Ark Service Provider) and a command-line wallet called bark. It’s a terminal-only experience for now, but that didn’t stop anyone. Our guests created their first wallets and received some sats to start testing.

In-round payments

With everyone set up, it was time to run the first round. In the Ark protocol, the ASP automatically triggers rounds at regular intervals (e.g., every hour), but for this test we had to manually trigger the round.

Each round results in a single on-chain transaction. We had seven guests on the call, each adding their transaction to the round. But, importantly, we only had to pay the on-chain fee for a single small transaction. Efficiency is beautiful.

To make an in-round payment, our participants used the command:

$ bark send-round <vtxo-pubkey> <amount_sat>

When they saw Waiting for round… appear in their logs, they knew they were ready. Steven then manually triggered the round.

Success! Our transaction (txid 32cea70…baad051) was broadcast to the mempool and confirmed in block 862149. The payments were smooth, and everyone verified their balances had been updated.

This is the most amazing feeling I’ve had since the Lightning Network came out.
—Super Testnet

Out-of-round payments (arkoor)

Our ASP also supports out-of-round payments, otherwise known as arkoor. Unlike traditional Ark payments, these don’t require waiting for a round. Everyone made an arkoor transaction with:

$ bark send <vtxo-pubkey> <amount>

Arkoor payments are much simpler and faster than a typical Lightning payment and they completed almost instantly. With Ark, you only need a single round-trip between client and server. In contrast, Lightning payments get routed through multiple hops, with handshakes at each step to update channel states.

Insanely fast!
—Marty Bent

That said, there are trade-offs. The security model for arkoor payments is different. The recipient needs to trust that the payer and the ASP aren’t colluding to double-spend. If that feels risky, the recipient can cycle their arkoor transaction into an in-round transaction during the next round.

Lightning payments

We still had one trick up our sleeve. Even though we were demoing Ark, we knew we had to show off how it works with Lightning. After all, Lightning has become the go-to mechanism for bitcoin payments. With Ark, you’re not stranded on an isolated island. You can easily send payments to any Lightning wallet, with the ASP acting as the Lightning "gateway".

Participants made transfers to their own Lightning wallets. Payments were delivered seamlessly in seconds. The swap from Ark to Lightning is handled atomically, so at no point did any user have to take on any counterparty risk.

Getting a bitcoin balance off Ark

Ark offers two ways to get your sats back on-chain: offboarding and unilateral exits.

Offboarding

The cheapest option is to offboard, which requires collaboration with the ASP and the user needs to waiting for a round. You can initiate an offboard with the simple command:

$ bark offboard-all

You can see this round transaction from the demo has an extra output that represents an offboard. I won’t mention who did the offboard to protect their on-chain privacy!

Unilateral exit

If the ASP refuses to cooperate or is unavailable for whatever reason, a user can choose to unilateral exit. Unilateral exits are bit more involved than offboarding and are more expensive due to multiple on-chain fees, but it gets the job done.

We had two adventurous (and patient!) participants initiate unilateral exits during the demo. Here's an example of one of the exit transactions.

Can I try it myself?

Right now, the software is experimental, and we've disabled our mainnet Ark server. But if you want to give Ark a spin, you can do it on signet: follow the guide to get started!

Slightly over a year ago, an idea for a new off-chain payment protocol for bitcoin was proposed: Ark. Originally conceived as a solution for onboarding Lightning users, Ark’s design has evolved significantly since then, and it’s become a full-fledged bitcoin scaling protocol in its own right.

Now, we believe Ark is ready for primetime. That’s why we’ve formed Second—a company dedicated to scaling bitcoin through Ark and other second-layer technologies. 

To demonstrate the progress we made, we ran the first-ever Ark transactions with some friends on bitcoin mainnet yesterday—yes, real sats. Read our dedicated report.

Beyond Lightning

Since its reveal in 2016, the Lightning Network has made incredible progress, becoming the undisputed standard for making retail payments with bitcoin. 

However, with this success, we’ve also started to see the challenges of Lightning’s limitations. While it works incredibly well for tech-savvy users with high payment volumes, retail users often face friction with onboarding and channel management.

Lightning Service Providers (LSPs) can alleviate some of this, but if users are relying on centralized entities for their payments, it raises the question: do they need the complexities of Lightning, which was originally designed for a fully peer-to-peer network?

Simpler bitcoin scaling

This is where Ark comes in. Ark embraces a centralized approach, adopting a client-server model for fast, low-cost payments while leveraging smart cryptography to ensure that users remain in full control of their bitcoin. 

It achieves this while offering an easier experience for developers and users alike: simpler integrations and simpler wallet management.

An extension of Lightning, not a replacement

Ark was initially designed to improve Lightning onboarding, so it’s naturally compatible with Lightning and should be seen more as an extension than a replacement. For instance, Ark users can directly pay Lightning invoices (and soon, receive payments too!), allowing them to participate seamlessly in bitcoin’s wider payment ecosystem while enjoying the benefits of Ark when transacting with other Ark users.

We’re still in the early stages of working out how things will shake out, recognizing that some users may benefit more from Ark, others from Lightning, and many from a combination of both.

An open Ark

Bitcoin and Lightning thrive because of their development communities’ strong dedication to self-custody and open-source. We intend no different with Ark—our implementations of both the client wallet and the Ark server will be open-source. This transparency is essential for Ark’s success within the bitcoin ecosystem.

Who are we?

Our small team consists of a group of former Blockstreamers, all passionate about bitcoin’s censorship-resistance and scaling it to a global user base. Personally, I’ve also been a lead contributor in developing the Ark protocol to its current state.

We’re on the hunt for talented developers too. If you have experience with Rust, C++, or devops (especially running Lightning infrastructure!) and share our passion for bitcoin, we’d love to hear from you!

Get involved

If you’re interested in enabling Ark payments in your app with Second, check out our new developer docs, and visit the repository of our Ark implementation.

Ark opens up a new frontier for scaling bitcoin and we hope you’ll join us in making it a reality!