Erik De Smedt over at Second published this great explainer for how Second recently changed their Ark implementation to rely on hash-lock contracts.

"How rounds worked: forfeit, then broadcast""How rounds worked: forfeit, then broadcast"

Ark gets its unilateral exit guarantees by giving users pre-signed transactions (a lot like lightning nodes do for their channel partners). But in Ark, all transactions are part of a large timelocked transaction that must be periodically refreshed. Ark users must come on line to do this refresh or the Ark provider can take their coins.

Here's how Second describes that process working:

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.

They also include a diagram, but it looked so complicated, I decided not to try to understand it. The thing to keep in mind is that in this model of Ark, a user must come online every so often to give back their old VTXOs and get new ones (this is called a forfeit) via an atomic swap.

Now, Second has come up with a new way to do the swap that may make it so the user doesn't need to come online on any particular time schedule.

"How rounds work now: broadcast, then forfeit""How rounds work now: broadcast, then forfeit"

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.

Here's how they describe it working:

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:

1. The server does nothing, and the user reclaims their bitcoin after the timeout delta.
2. 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.

How this allows users to be offline during a refresh roundHow this allows users to be offline during a refresh round

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.

In this case, the user is trusting the cosigners as a group.

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.

@supertestnet pointed out on X that because "currently, the only cosigner is the server itself"

The server can steal. For now.

It's hard to build decentralized software that has great UX. But also, this seems to be a trend.