atomicswap VS dcr-split-ticket-matcher

https://github.com/xmrswapme/swapfe https://github.com/UnstoppableSwap/unstoppableswap-gui#about-the-project https://help.1inch.io/en/articles/6018337-what-are-1inch-p2p-limit-orders-and-how-do-they-work https://github.com/decred/atomicswap

Atomic swaps require the supporting chains to have minimal scripting capabilities, and as far as I know all the bitcoin derivatives allow this. It is necessary to create a redeem script that has two branches, an immediate one and a time locked one. The immediate branch uses a oneway function supported on both chains and the time locked branch for the refund transaction with a regular signature. There is a four phase process in the exchange and this requires careful analysis of the timing. (This might work poorly with chains with unreliable performance at times of overload.) See the following example of how this might all be done. https://github.com/decred/atomicswap

Here's a project you can use to help: https://github.com/decred/atomicswap

Once atomic swaps are sorted it will be easy to add xmr to the various dex projects such as dcrdex https://github.com/decred/atomicswap

Also, why do you use term "ticket splitting", if it is widely known in the community as a non-custodial service powered by dcr-split-ticket-matcher? I think it may mislead some people to think BisonPool is also non-custodial, at least until they do due research.

The beta and design docs outlined a bunch of unsolved game-theoretic issues. I guess those were a factor for not putting more work into it.

In the more distant future, an exciting thing will be LN-based Multi-Owner Tickets. This will significantly lower the barrier to staking (without the drawbacks of the first iteration) of ticket splitting).

One was linked from matheusd's matcher repo: