An Exchange with a Different Approach

by hyper

The cryptocurrency Bismuth was integrated and listed on it’s first exchange during September/October 2017. Both the Bismuth developers and the community overall have been very satisfied with this exchange. It has handled user support issues in a timely fashion and upgraded it’s Bismuth node well in advance when hard forks have been required.

In order to increase the awareness of the Bismuth project and to expand the user base, both the developers and the community have had a desire to get listed on additional exchanges. The dev team uses an internal Trello board which currently includes more than 40 exchanges. The exchanges are categorized by the dev team as follows:

  • Exchanges that expressed interest in listing BIS, work in progress.
  • Asked, but no reply.
  • Asked and declined.
  • Expensive or other reason.
  • Low volume or not yet launched.

Due to the ICO craze in 2017 a lot of cryptocurrency projects collected large amounts of funds, and investors demanded listing on the top exchanges. For this reason, the top exchanges have been able to charge large amounts for a listing, in one case more than 20 BTC was asked. Bismuth never ran an ICO and the development work is funded by a percentage of the block rewards, which means that the core team simply does not have the funds to pay for listing on the top exchanges.

Some of the exchanges asked have been positive towards the Bismuth project, and a typical conversation goes like this: bis team: “would you be interested in listing Bismuth, and if so, how much would that cost”, exchange: “yes, we are interested in listing your project, the price would be x BTC”. After some internal discussions, the bis team answers: “yes, we would like to proceed, our open source code is available here: https://github.com/hclivess/Bismuth”, exchange: “Oh, it is a custom coin and not erc20, sorry we do not have the internal resources to integrate your project”.

Come qTrade. After many dialogs with exchanges like the one described above, it was soon clear to the Bismuth team that the qtrade.io exchange had a different approach. The initial communication went something like this: “Thanks for making contact. We’re gonna start digging a little deeper into BIS and try to identify sticking points for an integration. In the meantime take a look at our Development Guidelines: https://github.com/qtrade-exchange/integration-tools/blob/master/qTradeOriginalDevelopmentGuidelines.md”. A private channel on Discord was set up to discuss the integration.

After some technical discussions and clarifications, qTrade came back with a price offer to list BIS, which the team found reasonable and acceptable. Although it may in retrospect seem natural to work in this way, to clarify the technical scope and limitations beforehand, and to estimate the amount of work required from both sides for a listing, qTrade is the first exchange since the first listing that engaged with the dev team in such a way. On Discord one of the BIS core devs responded like this:

“I have to say I’m very pleased with the way you handle things, publicly disclose your requirements and process, and engage conversation with the team, make sure of technical points before a quote. That’s how I see things as well, but quite not the way other exchanges go (look at code, non standard, won’t support. Or accept blindly and code a mess because they did not even ask). Your feedback also helps us move in the right direction (code documentation, ad hoc scripts…), thanks a lot!”.

After that the qTrade team responded: “I’m glad to hear you’re a fan of the process — lots of teams aren’t interested in actually changing/writing any new code and it is refreshing to work with an active development team. Working through this process with you has pointed us towards a couple areas that need improvement in our technical guidelines and hopefully refine our process for the future, so a big thank you for that”.

qTrade has demonstrated real involvement and willingness to list custom coins, not just easy ones and they seem to share some common values with the bis team. The bis team hopes for a long-term relationship with the qTrade exchange. Clearly, this engagement and collaboration during the listing process has so far turned out to be a win-win for both parties.

As part of the listing process with qTrade, the BIS team started to study the exchange architecture in more detail. A figure illustrating the overall network setup is shown below:

In the qTrade Development Guidelines, it is written: “We have two separate programs that are highly isolated from each other, and from the actual p2p-node software. Effectively they only have HTTP API inter-communication possible, and have no access to each others filesystem, processes, etc. We refer to these separate components as the ‘signer’ and ‘watcher’. The watcher connects to the fully synced p2p-node, but the signer does not.”

In the figure above, by “push only” it is meant that only the signer or the watcher can initiate a connection. So the signer will connect and ask the exchange backend for any new transactions to be signed then disconnect. This is a good safety paradigm because if the backend is compromised the attacker has less access to the signer(s), multiple signers can operate in multisig, etc.

Another key safety feature of qTrade is “Idempotent deposit and withdraw handling”. At https://en.wikipedia.org/wiki/Idempotence it is defined as follows: “… is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.” The lack of idempotency is a common corner cut by exchanges. It is very simple to tell the coin server to send XXX funds to XXX address. The server then creates a transaction and tries to send it. But what if those funds do not get properly transmitted over the network, or what if the send command does not make it due to network congestion? And in the case of poorly designed systems the user might be able to bog down the server enough to get the backend to send multiples. An automated way to detect failures and send again is needed, but care must be taken not to send multiple withdrawals. So for withdrawals, idempotency at qTrade means two things:

  • Instead of telling the server to send XXX to XXX address it is told to ‘send this signed transaction I have created’. Even if the server receives that command multiple times, it is looking at the same transaction, not creating a new one.
  • If a user creates a withdrawal it is handled atomically in the database (ie, the user cannot accidentally cause the system to generate multiple transactions for a single withdrawal). For database atomicity, see for example: https://en.wikipedia.org/wiki/Atomicity_(database_systems)

When Bismuth is listed on qTrade, it becomes part of a good neighborhood, as there are other nice coins with custom features like VEO, RVN and SNOW. qTrade may be a young exchange, but as far as the bis team can see, the exchange is based on solid technical ground (safety features, signer machine, tests based on both testnet and a new Bismuth regnet implemented during the listing process). The bis team expects that the trading volume on qTrade may increase in the future because of this solid foundation. Additional benefits for Bismuth from the process are:

All that ease the development (for core dev as well as external devs) and provide BIS with more tools to help future exchanges.

The picture above shows results from the internal testing of deposit and withdrawal of BIS on qTrade a few days before launch. From first contact to launch it took 1 month. The qTrade team estimated in the beginning that the integration time would take 1 month, and in the end, that was exactly the amount of time it took. During this period several safety discussions took place as well as improvement suggestions for the new regnet mode.

Disclaimer: This article is not an endorsement by the Bismuth Foundation of the qTrade exchange. Potential new users of the exchange should do their own evaluation of risk before signing up.