I'm thinking about building an xcat tool (something like the zcash/bitcoin zbxcat tool https://github.com/zcash-hackworks/zbxcat) for swaps between Stellar and other networks. I don't think there are any implementations of cross chain swaps with Stellar as yet?

One way of doing this would be to build on the python zbxcat tool adding stellar support. But I think it'd be useful to have an implementation in js that could be used in browser apps, electron apps, etc.

I've sketched out how swaps might look between Stellar and Ethereum native tokens here: https://github.com/chatch/xcat/blob/master/docs/protocol_stellar_xlm_to_ethereum_eth.md and it would be great to get some feedback on this.

Ideally this protocol could be extended to support swapping ANY Stellar Asset for ANY Ethereum ERC20 token allowing for many swap pair possibilities.

For the Ethereum side I've written an implementation of Hashed timelock contracts: https://github.com/chatch/hashed-timelock-contract-ethereum that supports the deposit, withdraw and refunds transactions as described in the gist.

Amazing, that is something I was looking for. I wasn't clear on couple of points how to implement that.
Your version looks great. There are still couple of things I need to
Doesn't really make sense to do that for tokens, because you still need to trust anchor, unless anchor itself is controlled by a smart contract, but currently I don't know how to implement with all limitations.

21 days later

Hi.

I'm reviewing your protocols and they seems promising (currently at 'initiated by stellar part').
In your current design you are using payment to Alice as a refund transaction in case Bob does something wrong at his side. I think it would be better to use merge operation, as it will not leave unused account with unusable 40 XLM on network.

For transactions that sends XLM from Hold account to Bob it is better to leave it with payment as now, so in case Alice by mistake transfers too much to this Hold account she still can use the Merge transactions to get the rest back.

I think that with proper timelock on both stellar and eth transactions you could even get rid of Bob as a signer of Hold account.

    I don't understand why it doesn't make sense to do that for non-native Stellar assets. If you trust the anchor, if the anchor is something publicly trusted whose assets both Bob and Alice deal with it regularly, why shouldn't they transfer them using xcat?

    25 days later

    rafal oh yeah that makes sense. I'll change those to be account merges (S1: 2.3, 3.2 and S2: 3.1). thanks!

    i think the payment to Bob can also be a merge because 1) if Alice is using the xcat tool the correct amount will be sent. 2) she doesn't have permission to pay herself back anyway as she isn't a signer on the holding account

    as for the Timelock I can't see how you could get rid of Bob. as time bounds are on transactions and not on the account. the account needs at least one signer that stops Alice from just paying herself back out of that account.

      Updated protocol docs with account merge change and an overview UML sequence diagram:
      protocol_stellar_xlm_to_ethereum_eth.md
      protocol-scenario1.png

      There is now a script which orchestrates scenario 1:
      integration-test/protocol-scenario1.js

      The main flow works however cases like refunds etc. need more testing.

      There is a cli interface. The main entry point is 'xcat status' which will scan the trade defintiion and scan the ledgers to determine whats the next step in the protocol. If it requires action from the party running the status check then it will fulfill that step. I'll post a demo of this cli flow soon.

      13 days later

      I've written out how a swap for Stellar Assets with Ethereum ERC20 tokens might be done for this. For initiating from the Stellar asset side only for now: protocol_stellar_asset_to_ethereum_erc20.md.

      The Stellar side is basically the same except for an additional operation to create a trustline from holding account to asset issuer. And the tool would need to check the asset receiver address has trust already too.

      The Ethereum side needs a variation on the HashedTimelock contract that works with ERC20 tokens. I've written one here:
      HashedTimelockERC20.sol

      See at the top of the protocol doc there are few issues like auth flag assets to be considered. But I think this protocol would work for most swaps.

        hatch

        ...
  Operation: Allow Trust:
                Source: hold acc
                Line: CNY / CNY Issuer
                Limit: agreed amount 
 ...

        I think you meant ChangeTrust operation. Allow trust is something that only asset issuer needs.

            2 months later

            @hatch Interested in working on this with you. Let me know the best way to get in contact.

            6 days later
            a year later