An OTC Trading dApp on an Ethereum Parity Blockchain containerized & deployed with Red Hat OpenShift

Over-the-counter (OTC) trading

OTC trading is an important means of trading for financial institutions and is used primarily to trade bonds, currencies, derivatives and other structured products. Unlike stocks traded on formal centralized exchanges, OTC securities are electronically traded via a dealer network, the key difference is the transaction medium. Dealers act as market makers by quoting prices at which they will buy and sell a security or currency. A trade can be executed between participants in an OTC market without others being aware of the price at which the transaction was executed. On an exchange, every party is exposed to offers by every other counterparty, which usually is not the case in an OTC market.

In general, decentralized OTC markets are less transparent than central exchanges and are also subject to fewer regulations and barriers to entry. OTC markets often bear high counterparty risk that one party will default prior to the completion of the trade and/or not make the current and future payments required by contract.

OTC trading on a blockchain — why?

If you are new to blockchain technology, we recommend you to check out the following excellent explainer video. If you feel more hackish, try this video and play around with the concepts live.

The rise of blockchain and smart contract technologies enable the OTC trade to be at the heart of the matter. The blockchain mainly mitigates counterparty risks in an OTC trade by building a trust layer between the trading parties. The transfer of the digital asset representing the traded security is directly coupled with the transfer of the agreed payment through the execution of a smart contract deployed on the blockchain. If the agreed payment is not fulfilled the transfer of the digital asset is not executed.

Besides the reduction of counterparty risks, a blockchain used as trust and interaction layer between OTC traders allows to execute the trades much more efficient. Each participant in the OTC trading network can rely on executed trades that are mined into the blockchain. The blockchain transaction both represent the asset transfer, the payment and hence also as proof for the clearing and settlement. OTC trades that are nowadays handled within days via redundantly hard-maintained database copies between trading partners, become executed in seconds on a trusted shared distributed ledger.

However, as the blockchain is a shared distributed ledger where transactions representing OTC trades are propagated in a peer-to-peer network, the privacy of an OTC trade is harder to maintain and for OTC markets where this is essential, at least a public blockchain is not the way to go. We outline two potential approaches to mitigate this issue:

  1. Keep sensitive transactions of an OTC trade private by utilizing second layer protocols with Onion routing on top of a blockchain layer, as the lightning network enables it to for the Bitcoin blockchain or the Raiden network for the Ethereum blockchain. As these promising second layer technologies are still maturing and introduce additional complexities, we neglect them for our OTC trading solution.
  2. A so-called private consortium blockchain only accessible to the participants of an OTC market might be a good compromise solution. It keeps OTC private to the participants but still builds a trust layer between the participants without need for additional mediating middlemen.

Private Ethereum with Proof-of-Authority consensus — our choice for OTC trading

Ethereum is the most prominent and most mature blockchain with smart contract features. It is meant to be a decentralized platform that runs decentralized applications where smart contracts are executed as programmed by the developer without any possibility of downtime, censorship, fraud or third-party interference. To be careful here: incidents like the The Dao Hack suggest that this goal is only achievable if the smart contract deployment happens after a proper security audit and ideally after formal verification.

The technology of Parity is one of the most advanced blockchain technology stacks for Ethereum and Parity offers a node implementation for Ethereum. Roughly one third of the nodes of the public Ethereum blockchain are using Parity’s Ethereum client built with the programming language Rust. The Parity Ethereum client is highly configurable and can be used to set up an enterprise consortium blockchain with configurable consensus mechanisms like Proof-of-Authority (PoA). Parity is readily available in Docker image format. We favor PoA consensus over Proof of Work and Proof of Stake as it is much more efficient in a trusted consortium network where permissionless entry of a miner is not a necessary design goal.

Containerize the nodes of the blockchain

One final ingredient in order to easily build a decentralized app (dApp) for an OTC market based on a private Parity Ethereum blockchain is missing: An easy way to spin up a blockchain between the OTC market participants, because setting up and deploying a blockchain can be tricky.

Fortunately, modern container platforms can help here. One popular container platform is OpenShift from Red Hat. OpenShift is a container application platform based on a OCI-compatible runtime (like Moby from Docker) and Kubernetes that allows developers to create, test and run their applications and deploy them easily whether it is physical, virtual or public cloud environment. OpenShift provides support for many applications. It is especially easy to deploy code written in Java, Node.js, .NET, Ruby, Python, PHP, and Perl. It is extensible so that users can add support for other languages. Resources allocated for applications can be automatically or manually scaled so that as demand increases there is no degradation of performance.

Right — Now, how do we build such an dApp?

  1. A web app client that gives the OTC trader a user interface (UI) to interact with via a web browser: We implement the web app client with Vue.js, a light-weight web framework that has all you need for a slick frontend.
  2. A proxy backend that receives requests from the web client and proxies the request to a Parity blockchain node: We utilize a Node.js backend for that.
  3. A backend database that serves as persistence layer for the proxy backend: We utilize MongoDB for that.
  4. A blockchain node that interacts with the consortium blockchain of the OTC market: We run a Parity blockchain with Proof-of-Authority consensus. On the blockchain we deploy smart contracts for the ERC20 token standard adapted from OpenZepplin that represent the OTC assets and a smart contract from MakerDao that serves as decentralized marketplace.
  5. A container platform that containerizes all of the above components: We use Kubernetes based Red Hat OpenShift for that.


The following personas interact with the dApp:

  1. Market maker or asset seller: A user of the dApp, that offers an OTC asset as ERC20 tokens in exchange for another OTC asset to other users of the dApp.
  2. Market taker or asset buyer: A user of the dApp accepting the offer of a market maker and executing the OTC trade.
  3. Market initializer: This is a special role of our dApp that is not needed for liquid markets where the ERC20 tokens are spread across market participants. The market initializer can perform the role of a central bank, buy issuing assets as ERC20 tokens to be traded.

The smart contract architecture of our dApp

Let’s observe an OTC trade and the action that happen on the blockchain/smart contract layer with an asset pair example “Asset token sold for Euro token”:

  1. Starting point:
    a) The asset seller owns asset tokens that he wants to offer in an OTC trade. The tokens are assigned to an Ethereum address/account within the Asset ERC20 smart contract for which address he exclusively controls the private keys.
    b) The asset buyer owns Euro token that he wants to sell in exchange for Asset tokens. The tokens are assigned to an Ethereum address/account within the Euro ERC20 smart contract for which address he exclusively controls the private keys.
  2. Place offer transaction:
    a) When the asset seller places an offer as Ethereum transaction in the OTC market smart contract, this very same smart contract escrows the asset tokens of the seller. That means the asset tokens are transferred within the Asset ERC20 smart contract from the asset seller address to the OTC market smart contract address acting as escrow agent.
    b) Note that the initiating Ethereum transaction is created on web app client-side and is propagated unchanged to the blockchain via proxy backend without the private keys leaving the client-side.
  3. Take offer transaction:
    a) When the asset buyer triggers a transaction that takes the offer (partially or complete) stored in the OTC market smart contract, the Euro tokens are transferred within the Euro ERC20 smart contract from the asset buyer to the asset seller and at the same time the Asset tokens are transferred within the Asset ERC20 smart contract from the escrowing OTC market address to the asset buyer address.
    b) Again, the initiating transaction is created client-side and propagated unchanged via proxy backend without the private keys leaving the client-side.

Properties of our dApp to highlight:

General properties:

  1. The web app client is solely responsible for providing the user with a UI, controls the client-side maintained blockchain wallet and creates blockchain transactions.
  2. The proxy backend serves as web app backend and proxy for communicating with the blockchain node. It has no control over transmitted blockchain transactions and is a trustless connection provider for the dApp.
  3. The backend database stores the user accounts of the dApp, but no wallet information.
  4. The blockchain nodes are running in an OpenShift cluster that easily allows to scale with respect to the demand by adding resources to existing nodes or allows extending the network by adding blockchain nodes.

Blockchain properties:

  1. The smart contracts are deployed on a private Ethereum blockchain. However, the smart contracts and dApp implementation would work exactly the same way in the context of the public Ethereum blockchain.
  2. The OTC marketplace smart contract works with any token that follows the ERC20 token standard.
  3. The OTC marketplace smart contract is not controlled by any administrative entity.
  4. Any asset seller can place an offer and any asset buyer can take an open offer.
  5. An offer can be cancelled solely by the creator of the offer, cancellation returns the escrowed tokens to the address of the creator.

Now — do you want to try it out? How to setup and use the dApp yourself!

You need a running OpenShift cluster to deploy the dApp to. If you do not want to install OpenShift locally, Red Hat offers an OpenShift playground environment where you can deploy the dApp for 60 minutes to an OpenShift cluster hosted freely for you. If you want to install OpenShift locally, Red Hat has excellent tutorials for that here. Or use a local install with the Minishift based Container Development Kit.

Once you have an OpenShift cluster available you simple fetch the source code from our GitHub repository here:

Change into the folder openshift:

Login into your OpenShift cluster. If you use OpenShift playground environment, check your playgroundId, that is defined by the first 10 digits of the cluster URL. For example, if the cluster URL is 2886795332– then your playgroundId is 2886795332. Execute the following command in the bash terminal of the playground after you have replaced <playgroundId> with your specific playgroundId to login into your cluster:

If you run local OpenShift cluster, use the same command oc login with your locally defined user credentials and local cluster URL.

Deploy the components of the dApp following the instructions from here. For the following, we assume you want to name the OpenShift project projectName=otc. If you use OpenShift playground environment, the wild card domain is the following:

(again, the first 10 digits represent your playgroundId)

For a local setup the OpenShift wildcard domain is usually something like:

Execute the following command to deploy the dApp:

Once you executed this command, building the OpenShift container usually takes a couple of minutes. Now you can manage the containers via OpenShift console from your web browser.

When the container build process is finished you are able to access the web app client of the dApp via:

(for OpenShift playground environment)

(for local setup)

Awesome, deployment done! Now you are ready for demo!

User experience for OTC traders (market maker & taker)

Interacting with a web app, every trader has to register as a user at the OTC platform. Note: The user credentials are stored in the backend database but cannot be used to authorize OTC trades.

The assets are encoded as ERC20 tokens and maintained within a client-side wallet, which is not stored in the backend database. Therefore, after registering as user, a trader has to initialize a wallet, either by importing the mnemonic seed phrase of an existing wallet or by creating a new seed phrase. Side note: The seed phrase has to be kept secure and private by the user, as it can be used to access all private keys of all Ethereum addresses/accounts that have been generated from the seed phrase! The wallet is encrypted on client-side with a password that the user has to set. The wallet is stored encrypted within the browser cache, so whenever the browser cache is emptied, the user as to import the wallet again.

Make the market liquid (only needed for illiquid markets/demo purposes!). Login with an initial setup user that distributes the OTC assets to market participants as described here.

A market initializer can act as issuer of a newly generated OTC asset where they hold the complete supply of the new asset. They can release an OTC asset for trading by offered the new ERC20 tokens on the marketplace in exchange for other tokens.

A market initializer can act as administrative donor where they assign tokens to other users without reward. Note that this can only be done with tokens that are in control by the market initializer.

Now a market maker that wants to offer an OTC asset can create an offer in the marketplace by specifying the quantity of the OTC asset that he wants to sell and the corresponding rate he expects in the OTC asset that he takes.

A trader can take an offer from the marketplace and execute the OTC trade, either completely or partially.


This article showed how to utilize blockchain technology in order to build a decentralized OTC trading platform as web app based on an Ethereum blockchain where OTC assets are represented as ERC20 tokens. Furthermore, we showed how to efficiently utilize OpenShift as containerization for the blockchain infrastructure.

By using blockchain technology we achieve the following:

  1. No middlemen are involved in the OTC trade between market maker and taker.
  2. The control over the OTC assets is maintained on client side.
  3. The OTC platform serves as trustless entry point into the order book of the marketplace.

By using Kubernetes/OpenShift container technology we achieve the following:

  1. Easy infrastructure-as-a-code based rollout of the entire scenario. Compared to a local setup, one saves lots of time by just running the deployment script.
  2. Basically, unlimited scalability of each containerized component: The OTC dApp could be deployed everywhere, from bare metal over open stack and private cloud to every major public cloud platform.
  3. Built-In continuous deployment. In case you want to start hacking on your fork of the project, replace the repo URL in OpenShift, add a GitHub web hook and you’re good to go.

We’re happy to see your pull requests :)

Disclaimer: ITP Innovative Technologie Projekte GmbH is a software consulting and development company based in Berlin and Potsdam. ITP is a solution provider and partner of Red Hat and has expertise in cloud management and cloud automation products of Red Hat. The partners have researched and implemented this OTC trading dApp in a joint own initiative project in the period April 2017 — February 2019.

Acknowledgement: This work was supported by Andreas Deil, Siamak Sadeghianfar, Karsten Gresch and Lutz Lange. We thank our colleagues for researching, developing and documenting this work and many insightful discussions around it.

CEO at CPG Finance Systems GmbH

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

A Systems Engineer’s Guide to… The Blockchain

All about Credits

AERGO Leading the Mass Adoption of Blockchain Technology, Building the Bridge Between Blockchain…

EFUN 🤝 FABWELT Partnership

Web3 Enables A New Data Economy

ConsenSys Acquires J.P. Morgan’s Quorum to Advance Enterprise Blockchain Adoption

Outsource Computation on Bitcoin SV

Launching the Priviti blog: decentralised innovation in an era of consent

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dr. Martin Berger

Dr. Martin Berger

CEO at CPG Finance Systems GmbH

More from Medium

Is Fe the next smart contract language?

Building a High Performance Trading System in the Cloud

Discovering BBGO

Understanding Trading Latencies