Author: Erik De Smedt
The term "hArk (Ark using hash locks)" first appeared in a post on the Delving Bitcoin forum and has been released in version v0.1.0-beta.6 of our Ark implementation . hArk is an update to our Ark protocol implementation that fundamentally changes how rounds are constructed. After the update, user forfeits rely on hash locks instead of connector outputs and are signed after the round's funding transaction broadcast (instead of pre-signing).
hArk makes developing mobile applications on Bark much easier, as it supports "delegated refreshes," a necessary mechanism because mobile devices cannot be reliably woken up to participate in the round-signing process. While delegated refreshes offer some security sacrifices compared to standard self-signing refreshes, rest assured that self-signing refreshes remain the default trust model, and the core of the protocol remains unchanged.
To be honest, we hesitated when implementing hArk, knowing it would delay the mainnet launch. But it was necessary—it's far more painful to revamp an existing model after users and integrators have become accustomed to it than to start with a new round model. Now that it's ready, we're happy—and we want Bark to be mobile-friendly from the start.
The (former) round-based mechanism: first sign off on abstaining from a transaction, then broadcast the investment transaction.
In the Ark protocol, users must periodically refresh their Ark balance, invalidating old VTXOs and obtaining new VTXOs with a single atomic operation.
In classic Ark, rounds proceed in the following order:
- Submit a request : The user tells the service provider which VTXOs they want to refresh.
- Building the tree and joint signing : The service provider builds a funding transaction and a transaction tree containing all new VTXOs; the users of this transaction tree jointly sign all related transactions.
- Signing an abstention transaction : The user signs an abstention transaction for their old VTXO.
- Broadcast : Service providers broadcast investment transactions.
Because the connector output is spent, the abstention transaction becomes conditionally effective: the connector is a dust-level output (extremely small denomination) in the funding transaction, and the abstention transaction uses it as input. If the funding transaction is not on-chain, the connector does not exist, and the abstention transaction cannot be spent. However, this conditionality is one-way: the abstention transaction depends on the funding transaction, but the new VTXO does not depend on the abstention transaction. Therefore, the service provider must collect the signature of each abstention transaction before broadcasting.
This model works fine for always-on desktop clients, but mobile operating systems (especially iOS) often fail to reliably wake up devices to participate in interactive rounds. To make mobile apps usable, we need a way to allow them to refresh without requiring user intervention in interactive rounds.
The only way to avoid using a "covenant" is to have a distributed group of co-signers sign the refresh operation on behalf of the user, allowing the user to claim their new VTXO later (i.e., "delegated refresh," which we'll discuss in more detail later). However, because the abstention operation is embedded in an interactive round-robin mechanism, we cannot implement delegated refresh—signing the abstention transaction requires the user's private key, and giving the private key to a third-party co-signer is unacceptable. We need to completely move the abstention step out of the round-robin and make it asynchronous.
The current turn-based system: broadcast first, then abstain.
The connectors couldn't meet our needs, so we went back to the design board and ultimately adopted hash locks and preimages—a cryptographic mechanism already validated in the Lightning Network. The hash lock provided the bidirectional conditionality we needed: the new VTXO depends on the abstention transaction, and the abstention transaction also depends on the new VTXO, allowing us to completely remove the abstention step from the interactive round.
In hArk, steps 3 and 4 are swapped, and step 4 can be completed outside the round window:
- Submit a request : The user tells the service provider which VTXOs they want to refresh.
- Building the tree and joint signing : The service provider builds a funding transaction and a transaction tree containing all new VTXOs; the users of this transaction tree jointly sign all related transactions.
- Broadcast : Service providers broadcast investment transactions.
- Signing for abstention transactions : Users sign for abstention transactions on their old VTXOs at their convenience. The service provider reveals a preimage after receiving each user's abstention transaction signature.
By separating the abstention step from the round, delegated refresh becomes possible. Co-signers can now pre-sign their respective branches on the transaction tree for mobile users during the round, and these signed transactions are then collected when the user's wallet comes back online—without waking the device during the round. The mechanism of delegated refresh is explained in detail below.
Another valuable byproduct is the reduced vulnerability of the Round interface to denial-of-service (DoS) attacks: if a user fails to sign their waiver transaction, it will no longer block others, thus making the Round more reliable for wallet developers and users.
How hash locks work for abstention transactions
This bidirectional dependency is achieved through a secret value: the "exit transaction" of each VTXO in the transaction tree is locked by a preimage p known only to the service provider, and the service provider only reveals p after receiving a signed abstention transaction. The service provider can first broadcast the funding transaction, which is safe because without p , users cannot access their new VTXOs. When a user signs their abstention transaction, the service provider reveals p , which simultaneously activates the user's new VTXO and gives the service provider the ability to claim the old VTXO.
Abstaining from a transaction is a two-step process:
- The user signs the abstention transaction, transferring its old VTXO into an abstention transaction output. One of the spending paths of this output has a hash lock with
pas the preimage, while the other spending path has a time lock (as shown in the middle of the diagram aboveForfeitoutput). - The service provider now holds the signed abstention transaction. If a user attempts to unilaterally return an old VTXO to the blockchain, the service provider can broadcast the abstention transaction and claim funds by revealing the preimage.
If the service provider refuses to disclose p , the user's Bitcoin remains safe. They can initiate an exit operation on-chain for the old VTXO, which will result in one of two outcomes:
- The service provider took no action, and the users reclaimed their Bitcoin after the time lock was unlocked.
- The service provider broadcasts a "forfeit claim transaction" (i.e.,
Forfeit claimtransaction in the middle of the diagram above), thus revealingpon-chain. The user then usespto activate their new VTXO.
In either case, the user will not lose their Bitcoin.
Delegated refresh: A new mode for mobile devices
By default, refreshes in hArk are still self-signed: you personally sign every relevant transaction on the transaction tree. These pre-signed branch transactions constitute your one-way exit path—if you need to exit your VTXO onto the chain without a service provider's cooperation, you can broadcast the chain of transactions from the root of the transaction tree to your current leaf. This is the strongest security model—completely trusting no one—but it requires being online and participating in signing during the round. For mobile operating systems that cannot be reliably woken up during the round, hArk introduces delegated refresh.
In delegated mode, a group of co-signers pre-sign the user's branch transactions during the round. When the user's wallet returns online, these fully signed branch transactions are collected from the service provider—giving the user the same one-way exit path (consistent with self-signing mode)—and their old VTXOs are forfeited. The service provider then reveals the preimage, thereby activating new VTXOs in the transaction tree.
All signers must conspire to hijack a user's VTXO; the more signers, the more difficult it becomes. Furthermore, signers automatically delete their signing keys after each round, providing forward security: even if a signer operates correctly during a round but is subsequently compromised, key deletion ensures the VTXO generated in that round remains secure. As long as at least one signer's software is functioning correctly during a round, collusion is impossible.
These two refresh modes are not mutually exclusive. Any wallet application can offer both modes simultaneously, using the appropriate mode based on connectivity. Alternatively, a wallet installed on multiple devices can have a desktop client handle all refreshes, while delegating refreshes on mobile devices serves as a contingency mechanism. Furthermore, a user who has delegated a refresh can always manually sign a refresh later, effectively reverting to a completely trustless mode.
However, please note that the only co-signer at present is the service provider itself. Releasing co-signing software that allows other entities to participate is one of our top priorities after the mainnet launch.
Stepping stone to restrictive clauses
Most existing Bitcoin constraint proposals would allow us to enforce Ark's tree structure without requiring pre-signed transactions. Users would gain the best of both worlds: the trustlessness of the current self-signature refresh model and the asynchronous convenience of the current delegated signature model. Users would still need to periodically return online to complete abstention transactions, but would not need to remain online during the construction of round-based funding transactions.
The beauty of hArk's design lies in the fact that it can be almost directly mapped to a restricted-term version of Ark. The hash lock abstention transaction mechanism, tree structure, and round-based flow can all remain unchanged. Therefore, if Bitcoin were to support restricted terms in the future (a dream come true), the migration from hArk to the restricted-term version should be seamless, causing minimal disruption to existing integrators and users.
It is already available in Bark.
hArk is already implemented in Bark— try it out on Signet . Also, subscribe to our newsletter to receive more updates from Second as soon as they're available.
(over)
