Suggestion to include Hashed Timelock Contract

I would like to propose to include a Hashed Timelock Contract (HTLC) for ERC20 tokens and one for ERC721 tokens in OpenZeppelin, to support atomic swaps between these types of tokens. Sample implementations can be found here https://github.com/kaleido-io/token-sample-htlc (which is forked and enhanced from Chris Hatch).

this contract is for consumers or organizations
who want to trade tokens but do not want to use a 3rd party centralized component that they must trust
this implementation uses the Hashed Timelock mechanism to guarantee the trading parties never lose their tokens regardless of how the trading parties behave (except for their own fault)
that provides security
unlike other bridging techniques that rely on a centralized application to coordinate reciprocating actions between the token contracts
this solution works in a peer-to-peer fashion without reliance on a trusted 3rd party

2 Likes

In my opinion, I think the HTLC is not universal, it is for some special requirements.

1 Like

I think the Solidity community look at OpenZeppelin today to make judgement on how “legitimate” some technologies or techniques are, and if they are mature enough to be adopted. The simple fact that something gets included in the library signals that it’s been well exercised and peer reviewed. In a sense it’s up to the OpenZeppelin team/community to make something universal.

In the case of HTLC, in my opinion it’s by far the most proven technique for cross-contract or cross-chain value transfer, without involving complex cryptography required to do cross-chain state validations like BTC Relay. The underlying technique has been used for many years in Lightning Network to manage payment channels. Ethereum based HTLC is even simpler than how it’s set up in Bitcoin because of the smart contract capability (eg. no separate locked multi-sig transactions needed for the refund).

As tokens get adopted and DEX springing up everywhere, plus the enterprise side with permissioned chains adopting the tokens concept, adding HTLC to the library seems a natural evolution.

2 Likes

Hi @jimthematrix

Thanks for the suggestion. Welcome to the community. :sunny:
It would be great if you could take a moment to Introduce yourself here!

I haven’t done any cross chain swaps, so am new to how this works, I have only used bridges between Ethereum networks as a user e.g. https://github.com/poanetwork/token-bridge

What do you need HTLC for (I assume at Kaleido)?

What examples are there of HTLC being used already on Ethereum?

In your opinion what are the pros and cons of HTLC compared with other techniques for cross chain swaps? Is there any reading suggestions?

Hi @Skyge

Thanks for adding to the discussion. It is much appreciated.

Would you mind expanding on your thoughts a bit more?

What do you see as the use cases for HTLC?

Hello @jimthematrix, welcome to the forum! :slight_smile:

Thanks for the suggestion, it definitely sounds interesting. Would you mind helping the community understand what Hashed Timelock is by filling this:

this contract is for <target user>
who <have the following problem/need>
this implementation <describe solution>
that provides <cite the breakthrough capability>
unlike <alternative contract / implementation / competition>
this solution <key point of differentiation>

Thanks again!

1 Like

Emmm, I don’t have a real usage case, I know this approach, cause my friends ask me if there is a way to replace the existing shopping settlement system, such as Amazon, so I think it is similar to HTLC. There are three parts, Buyer, Contract, Seller. Buyer sends money to the Contract with a hash, Seller sends goods to Buyer, when Buyer gets goods and is satisfied with it, Buyer gives Seller the original data, so Seller can use this to get money. If Buyer wants to withdraw his money, he should get approval from Seller; If Buyer does not withdraw money and does not give data to Seller, the Seller can get money after a special time, expired time.
So they have similar logic, but they are not exactly the same.
Maybe you have known this article, but I just paste it here for someone else who wants to know about guide-hashed-timelock-contracts

1 Like

Thanks everyone for your interest and prompt responses! Atomic Swaps have a wide range of use cases, which mostly fall under the “I want to trade my tokens, and I do not want to trust a centralized party to perform the right actions” category. I’m somewhat familiar with poa.network and understand that it relies on the bridge app to guarantee “mass conservation” between the two sides, by listening for events on the bridge contract on one chain and perform the corresponding actions on the bridge contract on the other chain.

Atomic Swaps allows the trading parties to control the entire flow themselves, using a “hash lock”. If both parties act honestly, both succeed. If either party rejects the offer, the deal fails and both parties get their money back. You can not cheat and you don’t have to trust a 3rd party for the deal to go through. This article is among the better ones explaining the design details.

HTLC is definitely not unique to Kaleido. We are just making use of it and would like to see it getting more widely adopted.

this contract is for consumers or organizations
who want to trade tokens but do not want to use a 3rd party centralized component that they must trust
this implementation uses the Hashed Timelock mechanism to guarantee the trading parties never lose their tokens regardless of how the trading parties behave (except for their own fault)
that provides security
unlike other bridging techniques that rely on a centralized application to coordinate reciprocating actions between the token contracts
this solution in a peer-to-peer fashion without reliance on a trusted 3rd party

3 Likes

This is great, could you put it in the original post so it’s easier to understand what the topic is about? :slight_smile:

1 Like

thanks for the suggestion, @martriay. done

2 Likes

It seems that https://github.com/kaleido-io/token-sample-htlc (shared by @jimthematrix) provides three separate contracts, each for a different kind of token: Ether, ERC20, and ERC721.

Ideally I would like to see a single contract that could be used for all types of tokens, internally reusing a generic hashlock implementation.

Does anyone have a suggestion for how to implement that?

1 Like

This one is a raw idea I just had.

We can make a hashlock contract for arbitrary transactions. The contract is initialized with parameters hash, timeout, and receiver as usual, and additionally a target address, and two byte arrays withdraw and refund.

If receiver shows up with the preimage of hash on time, a transaction is sent to target with data withdraw. If receiver never shows up, after the timeout the contract can be made to send a transaction to target with data refund.

To transfer an ERC20 token you can then

  • define target as the ERC20 contract,
  • define withdraw as the encoding of calling transfer(receiver, amount), and
  • define refund as the encoding of calling transfer(sender, amount).

Create the contract, and transfer amount to it.

This is a very low level interface, and it may go against usual OpenZeppelin standards since it could really be misused. It does the job, though.

To generalize it to Ether transfers you would need to have two separate targets withdraw_target and refund_target, and additionally specify a value to be sent along with the transaction. withdraw and refund would simply be empty.

2 Likes