Hash-based Escrow

[KElkhiyaoui]

Problem

This involves three parties at least. Escrow, Alice and Bob. The Escrow is trusted by Alice and Bob.
Alice locks the token wit the help of the escrow. The escrow verifies the conditions to release the token and decides whether the token should be sent to Alice or Bob.
Ideally, the escrow should not own the locked token, just facilitates the lock and release.

Solution

The Escrow selects a secret pre-image whose hash is provided to both Alice and Bob. Alice locks her token such that the lock is released if the transaction carries a signature from either Alice or Bob and the pre-image.
The assumption is that Escrow will provide the pre-image only to party with the right to claim the token.
With this solution, the escrow facilitates the release of the token but does not have ownership rights to the token.

Alternatives

No response

Additional Context

No response

[Flamki]

Hi @KElkhiyaoui,

I would like to work on this issue (#1657) if it is still available.
I can start by sharing a short design/implementation plan here, then proceed with a scoped PR and tests.

[KElkhiyaoui]

Sounds good.

[Flamki]

Hi @KElkhiyaoui,

Thanks for confirming. Here’s the short plan I’m following for #1657.

I’m keeping this scoped by reusing the current HTLC flow and adding an optional escrow mode, instead of introducing a separate protocol path.

Plan:

1. Add an explicit option (for example WithEscrowMode) on lock creation.
2. Keep default behavior unchanged for backward compatibility.
3. In escrow mode, allow pre-deadline claim with preimage + authorized signature from either Alice or Bob.
4. Keep reclaim behavior after deadline unchanged.
5. Enforce the same rule in transaction assembly, signature verification, and owner/identity validation.
6. Add focused unit tests for default mode, escrow mode, and rejection paths.

Escrow remains non-custodial in this design: it controls preimage release, but does not own the locked token.

I’ve opened a scoped draft PR here: #1678.

[KElkhiyaoui]

@Flamki I suggest that we do not use a timeout. I would also suggest that we add a separate identity. So we have an HTLC-based Identity and a Hash-based Escrow Identity, to clarify that they are not the same. The hash-based escrow identity reflects that what controls the release of an asset in the hash-based escrow is the pre-image and a signature of one of the parties.
@adecaro what do you think?

[adecaro]

@KElkhiyaoui , do you want to still name the parties or anyone who has the pre-image can spend?

[adecaro]

I would agree that it is better to keep identities separated