Qortal Project

The future of blockchain platforms

User Tools

Site Tools


Sidebar

Qortal Project Wiki

Qortal Project Model

Important Notices - MUST READ

QORT Minting

QORT Communications Plugin

QORT Trade Portal

Qortal Voting System

Qortal Data Hosting

Qortal Hardware

Frequently Asked Questions (FAQ)

QORT How-To Guides

the_trade_portal_overview

The Trade Portal Overview

The Trade Portal, was initially the main service for the Qortal blockchain is a COMPLETELY DECENTRALIZED peer-to-peer (p2p) trade platform, built inside the Qortal User Interface.

Qortal’s Trade Portal aims to remove the need for centralized exchanges and ‘decentralized exchanges’ which riddle the blockchain space with all sorts of flaws. That is not to say that all exchanges which claim to be decentralized are flawed, but surely most are. The idea of the Trade Portal is to provide true peer-to-peer (p2p) transactions between buyers and sellers without the need of the middle man by utilizing cross-chain trades in the form of the ‘ACCT’ SmartContract (Atomic Cross Chain Trade). The only authority over a trade taking place is solely between the buyer and seller! The custom trade bot for the buyer and seller automates the multiple stages involved in a true cross-chain trade so that the Trade Portal is as simple to use as any centralized service but without any of the associated risks such as 1) historically these exchanges have been prone to hacks and failure, 2) depositing assets into a wallet or temporarily releasing control of assets during a trade, 3) any need for KYC/AML tools.

How can Qortal guarantee no theft can occur within the Trade Portal? Simple. The fact is, the Trade Portal utilizes LOCAL wallets to make trades. At the time of this publication, Litecoin is natively supported. Bitcoin is not supported for trades, only wallet services. This implementation of cross-chain trades can be reused for any number of Litecoin forks that work on the same transaction sending and address generation schemes. The Dev Team has taken extensive time to ensure that only LOCAL wallets are made use of and the keys for those wallets are never exposed in an unencrypted fashion. Therefore, the Trade Portal is just as secure as sending from a local wallet to another, except they are one chain to another.

The Portal is a system that makes use of the ACCT system by the CIYAM developers (http://ciyam.org) with which to make completely cross-chain coin/token trades.

Initially, support for only BTC was implemented but found to be too expensive and slow to continue at this time. LTC was then implemented and has replaced BTC. In other words, BTC trade have been discontinued while the BTC wallet feature remains. There are currently LTC/DOGE/QORT markets only. Native BTC and LTC support in Qortal allows users to store BTC and LTC in their Qortal UI wallet, just as they would in a BTC local wallet. Without the need for installation of a BTC or LTC wallet itself.

The system allows for completely cross-chain trades between LTC, DOGE and QORT! Users NEVER RELINQUISH CONTROL OF THEIR COINS/TOKENS. Never have to 'deposit' assets in order to make trades. This allows for COMPLETE SECURITY. Never again, will there be worry about centralized exchanges failing, and taking with that failure, users' assets.

As time goes on, and development progresses, support for other coins/tokens will be implemented into the system. Votes in the system will be the primary factor as far as which new coins/tokens will be added, however, a vote is not a guarantee of listing, there will also be an independent verification done on the project pre-listing, to ensure only the most quality projects are listed in the Trade Portal.

Functionality

The Trade portal functions by making use of an automation system that creates and executes placement of ATs on behalf of the private key of a 'logged in' account.

The account's 'bot' (for lack of a better term) takes the trade data from the user, and issues a SmartContract (AT, ACCT AT to be exact) that then awaits input from another user, then picks up on behalf of both users, to execute a Cross-Chain trade.

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, 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.

It is normal for cryptocurrency transactions to take a while and not be immediate. They take a certain number of "confirmations" before they become spendable in the receiving wallet. For LTC that can be 10 mins or so, for BTC it can be up to an hour. So this is a limitation of the BTC/LTC/etc networks. Luckily QORT transactions are much faster. Also, if the other network has a lot of demand for transactions, it can take a while for it to even be processed and included in a block. Especially if the fee is low. So that can slow things down too.

the_trade_portal_overview.txt · Last modified: 2021/11/19 13:32 by gfactor