Differences

This shows you the differences between two versions of the page.

--- the_trade_portal_-_info [08/25/2021 20:01] – gfactor
+++ the_trade_portal_-_info [11/16/2021 13:26] – [Functionality] gfactor
@@ Line 25: / Line 25: @@
 All that is necessary for the user, is leaving their core running.
-**Important note:** If you wipe your database then you will lose access to any funds tied up in trades (QORT or LTC). For pretty much the same reason as if you wiped your Litecoin wallet DB.
+**Important note:** If you wipe your database then you will lose access to any funds tied up in trades (QORT, DOGE or LTC). For pretty much the same reason as if you wiped your Litecoin wallet DB.
+===== Additional Notes =====
+The trade portal is peer to peer and quite a complex sequence of communications need to take place betwen the buyer and seller's node. There is no central server to ensure everything goes smoothly - it's down to both the parties following the "rules".  When a trade is unsuccessful, it is likely that the TradeBot has stopped working on the buyer’s or seller's node. This is why the automatic refund feature exists - as a fallback for when one of the two nodes isn't correctly participating in the trade. This is something that we have to live with in a trustless, decentralized environment. It will never be as "user friendly" as a centralized exchange but that's the price of not having some central entity dictating what you can and can't do. And we're lucky that with LTC the fees for a failed trade are almost zero.
+That being said, it's likely that a lot of these issues could be detectable upfront - e.g. we may be able to better screen out offers where the buyer’s or seller's node isn't in the correct state. "PRESENCE" transactions were the solution to this as we now remove offline nodes from the list (some will remember that in the first version of the trade portal it was pot luck as to whether the buyer’s or seller's node would be even online when you traded). So this concept could probably be expanded upon, and we could also do something like dropping an order from the list if there have been multiple failures associated with it.
+We will try and look into this particular sell offer as soon as we can to see if anything can be improved in the next version(s).
+Currently, if the node that listed the sell offer is in a bad state, all attempts to buy it will be refunded (after 1 hour or more). The sell order disappears from the list as soon as the selling node acknowledges that there is a buyer - we refer to this as "locking the trade" to the buyer. In this case, the seller's node never responded so there was no acknowledgement. So your idea of hiding the order as soon as there has been a buy transaction is a good one and would have helped here. But we'll need to make sure that the buy offer is valid before hiding anything - i.e. they have paid enough LTC.
+When we're dealing with cross-chain trades, there is no way to avoid the transaction fees on the chains involved. That’s just part of the deal when you're taking the middle man out of the scenario. Whether the trade fails to complete and is refunded, or completes, there will be a TX fee on the LTC chain. That will never change. The tx fee is very low and we can't be thinking of this like a centralized exchange, it isn't one. It is far superior in every way; exchanges are manipulated at best, and straight up scams at worst.
+QORT will eventually go feeless on QORT side for trades, but there's nothing we can do about the external chains involved. We have no control over their networks and can only play by their transaction rules. In our opinion, the tiny transaction fee is absolutely worth there being ZERO risk of loss in the trades. We can probably add additional checks before submitting the presence transactions. This is something to look at when the current features are out of the way.

Qortal Project

User Tools

Site Tools

Differences

Page Tools