Introduction

This document will detail both the domain and requirements for a trading platform that utilizes blockchain technology to form a secure, automated marketplace where participants do not have to rely on placing their trust with a third party. The trading that will take place in this marketplace is commodity trading, in high volume between peers, and apart from these peers there are no other entities that are involved in the marketplace in any way.

Rather than implementing a platform for a specific domain, we have tried to make a more general proof-of-concept implementation that be used as a basis for more complex domains if necessary, but otherwise stands on its own as a working example for a simple market.

The Domain

The domain considered is a commercial market with a few key characteristics:

1. Goods that are traded in the market have limited lifespans

For some products it is either expensive, undesirable or even impossible to store them for any amount of time. Therefore it is important for producers of these product to be able to sell them as soon as they are produced.

2. The volume of goods in the marketplace is high

Typically the trades that take place in the marketplace are for large quantities of goods between sizeable producers and consumers.

3. The number of participants in the marketplace is low

While the amount of goods being traded is fairly high, the number of producers and consumers involved in the market is fairly low. Therefore the number of trades that actually take place is not too high.

4. All participants are peers

There is no distinction or hierarchy between participants and as such expect to be treated fairly by the market. No participant has priority over another in the eyes of the platform, and the platform offers the same interactions to all.

Two examples of markets that meet these characteristics are: a local energy market and a market for food goods with short shelf life.

Requirements

To implement a system that is suitable for such a domain we elicit the following requirements which are split into function and non-functional:

Functional Requirements

1. Participants are able to place offers to sell and bids to buy

1. The details of these are known only to the submitting party and the party responsible for forming matching agreements (see following requirement)
2. Offers and bids have an expiry time, after which they are not considered in matchmaking
3. Offers and bids can be withdrawn only if they haven’t already been matched

2. Offers and bids are paired to form a match agreement. This agreement acts as an obligation for the offering party to supply the bidding party with an amount of goods for a certain price.

1. Offers and bids are only paired if the quantity and price are agreeable to both parties. This should be calculated from the information in the offers and bids
2. Matchmaking is performed by a leader who has been selected to form the next block in the chain by a fair proof of stake algorithm
3. The bidding party can update the match agreement upon receiving goods and the match agreement will keep track of how many goods have been supplied. Once the amount of goods supplied met the agreed upon quantity the match agreement is considered fulfilled

3. Once a match agreement has been fulfilled a payment agreement is automatically created. The payment agreement acts as an obligation for the demanding party to send the payment that was agreed upon in the match agreement to the offering party.^[1]

4. All of the information and entities mentioned in requirements 1 - 3 should be permanently recorded on a blockchain

Non-Functional Requirements

1. The application must run reasonably fast

1. While this is somewhat dependant on the domain it is expected that transactions made by participants are mined and matchmaking occurs fairly quickly
2. For example in reference to our two examples given earlier, for a market for food items with a short shelf life it maybe be acceptable for offers and bids to be matched on a hourly basis, but for a local energy market it could be desirable for matching to happen faster, perhaps at least every 10 minutes

2. The application must be easy to use and must not require prior knowledge of blockchain technology

3. The source code of the application must be available openly as participants are placing their trust in the system

4. Running the application should not consume a large amount of energy

1. We do not want to add any unnecessary cost to participating in the market