Trading on xud without running node

[xVETTEx]

I was just wondering if it would be possible to trade without running node. Has anyone thought about this? It could work like atomic swaps. When trader make order he create HTLC with node which can be spent by node by transferring tokens that trader wanted to buy to trader. Problem might be that if trader want cancel order before timelock ends, and node won't sign new state for channel. Node could still fill order until timelock ends. However I think this problem isn't impossible to solve. Trader could maybe use Exchange Union through ccxt api.

[kilrau]

Good thinking (and yes, we thought about it)!

Trading on OpenDEX without running a node (xud is the node) e.g. via a mobile wallet on a phone will be possible in the very near future via so-called "OpenDEX-enabled" exchanges: https://opendex.network/trade/exchanges

They act as a remote xud node (kind-of) which traders can connect to and setup htlcs/atomic swaps through these to trade on OpenDEX.

Admitted, I simplified a bit here. The reality is a bit more complicated since the atomic swap between exchange and end-user is de-coupled from the atomic swap on OpenDEX. And the end-user doesn't know anything about OpenDEX. That's necessary to make trades easy and reliable for end-users.

Is that understandable? WDYT? @xVETTEx

[xVETTEx]

Trading on OpenDEX without running a node (xud is the node) e.g. via a mobile wallet on a phone will be possible in the very near future via so-called "OpenDEX-enabled" exchanges: https://opendex.network/trade/exchanges

I think these exchanges is enough for users who want swap token A to token B, but boltz don't provide any API to market data, so it isn't useful for day traders or trading bots. They would still need to run xud node or connect ccxt api and trade through boltz. So it would be simpler to them if they could also do trading through ccxt. .

[kilrau]

Gotcha (finally)! Interesting idea and definitely agree, that exposing xud's api (ccxt, once we have https://github.com/ExchangeUnion/xud/issues/707 in) to the public can be useful to gain insight in what's happening in the OpenDEX network without the need to run a node.

Thoughts: Providing market data via api is definitely possible, e.g. our friends at Boltz could do that as a centralized service provider by adding a marketdata endpoint. Apart from knowing the current OpenDEX orderbook, what use case do you have in mind?

Offering users to actually trade through the public api would mean either a) require the standard trusted exchange setup: let users create an account, deposit coins, once deposited allow the user to trade for the deposited balance... which definitely defeats the purpose of what we are building. Not an option. OR b) allow user to create on-chain atomic swaps (since this works with all crypto wallets in existence, no need to run any nodes), which a provider like Boltz then directly translates into off-chain atomic swaps on OpenDEX. Two ways to do that in turn:

1. End-user atomic-swap = opendex atomic-swap using same preimage (considered, decided against it for now) [Trader] <--Atomic Swap(a_preimage)--> [Service Provider] <--Atomic Swap(a_preimage)--> [OpenDEX Network] Pro: direct trading on OpenDEX without running an OpenDEX node setup. Con: Might fail frequently, since trades on OpenDEX are less reliable. Service provider needs to price in service (on-chain fees, locking capital etc), so rate for end-user will be slightly more expensive. IMO, there is no way around that, otherwise the Service Provider operates at loss. Plus user has to pay on-chain fees for every trade, goes without saying. Rules out smaller trades.
2. End-user atomic-swap independent from OpenDEX atomic swap (current approach) [Trader] <--Atomic Swap(a_preimage)--> [Service Provider] <--Atomic Swap(b_preimage)--> [OpenDEX Network] Pro: 100% reliable for end-user if operated properly, but service provider takes a risk since it is guaranteeing the user a price based on current OpenDEX orders which might be not available a millisecond later. This risk has to be priced in, hence pricing will be X% above OpenDEX rates. Con: User gets a higher price, higher than in first approach since risk needs to be priced in

c) An idea I just had (potentially doesn't make much sense): end-user deposit = opendex atomic-swap using preimage provided by end user, that takes away/adds deposit. The idea: the user locks a rather large amount, like 5 BTC into her HTLC with the Service Provider. End-user instructs the service provider via ccxt to trade on OpenDEX based on the orderbook she sees via the ccxt api up to the amount "deposited". End user controls preimage. Now we need to find a way that with every preimage release Service Provider can only redeem the amount that was actually traded on OpenDEX from the "deposit". AAAAND drum roll we ended up with: a lightning channel. This is precisely how a lightning channel works. Let me think about this some more if there is a way to make this work with a deposit in form of one BTC lightning channel from end-user to service provider only.

Conclusion: a service provider can definitely offer a b)1.-style API. Just need to consider the cons.