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.

Diagram of a classic Ark connector-based refreshes: the old VTXO and a dust connector output from the funding transaction both serve as inputs to the forfeit transaction, which pays to the server

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.

Diagram of the new hArk-based refreshes: the old VTXO is spent to a forfeit output locked by a preimage, which the server then claims by revealing the preimage

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.

Diagram of a VTXO from a delegated refreshes: cosigners K₁..Kₙ sign A's branch during the round then delete their keys. A's wallet collects the signed transactions later.

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.