Creating a Marketplace

The Currency Marketplace on SteemIt is hypnotizing. This marketplace lets people trade SBD for STEEM and visa versa.

I understand the motivation for buying STEEM. We get half of our payout in SBD. We need to convert SBD to STEEM so that we can power up.

Since STEEM and SBD are both cybercurrencies offered by the same company, I find the motivation for buying SBD with STEEM to be a bit elusive. The primary buyers of SBD appear to be large accounts exploiting price differentials between SBD and STEEM on the open market.

The market place is intriguing but I don't think it gives a complete picture of how people value STEEM. It only shows how people perceive STEEM in relation to SBD.

I am not interested in speculating on currency.

The marketplace shows one of the most basic forms of exchanges. One has two entities that vary in accordance with each other. The exchange trades one thing for another.

I am making a game called Vagabond Spirits. The basic idea is that vagabond spirits decide to leave their human hosts and wander the world.

The game will include some fantasy exchanges. This type of commodity exchange is one of the easiest to implement; So I decided to create one.

The exchange game in the exchange will have two commodities: One call "bits" the other called "millies." A bit is a fantasy token used in the game. A milly is a thousandth of a dollar or a tenth of a penny.

There will be a very simple program to allow people to exchange millies for bits.

The rest of this post is geeky programming stuff.

When I start a project I like to define the data structure first. I am using SQLite3. So, I make ample use of the INTEGER PRIMARY KEY feature. I will also use a partial index to show Open Orders.

CREATE TABLE Trade_Account (
  account_id INTEGER PRIMARY KEY,
     millies INT,
        bits INT);

CREATE TABLE Order_History (
    order_id INTEGER PRIMARY KEY,
   status_cd int default 1,
  account_id int,
   bit_price int,
     millies int default 0,
        bits int default 0,
   remaining int,
      add_ts real,
      end_ts real
);
CREATE INDEX Open_Orders_IX ON Order_History (bit_price) WHERE status_cd = 1;
CREATE INDEX Order_Account_IX ON Order_History (account_id);

CREATE TABLE VS_Trans (
    trans_id INTEGER PRIMARY KEY,
   action_id INT,
  account_id INT,
      ref_id INT,
  session_id INT,
     note_id INT,
     amt_int INT,
 balance_int INT,
    hash_int INT,
          ts REAL default (julianday('now')));
CREATE INDEX Account_Trans_IX ON VS_Trans (account_id);


CREATE TABLE Order_Trans (
    order_id INT,
    trans_id INT,
     from_id INT,
       to_id INT,
     millies INT,
        bits INT);
CREATE INDEX Order_Detail_IX on Order_Trans (order_id);

The exchange only needs three flat tables. The fist table called "Trade Account' holds the balances of user accounts.

The second table "Order_History" holds the orders. The status_cd is 1 for an open order, 2 for a fulfilled order and 3 for a canceled order. I use a partial index so I can select just the open orders.

The third table is the transaction table.

I intend to use the same transaction table for every action in the game. So, this file will get huge. I will publish this table as a chain of blocks.

The public will be able to download the chain of blocks and run a program that produces the current state of the program from the chain of blocks.

The table is not normalized. The type_id determines what take of transaction took place.

The actual trade program works as follows:

When one places an order, the program will search the open orders for any order that satisfies the given price.

If it finds orders; it will execute and record the transactions for each open order affected. The program will close orders that are fulfilled completely, else it just records the amount used in the used field of the order.

The fourth table is really just an manually maintained index to the transaction table. The transaction table will get huge. I don't like putting too many indexes on huge tables.

Unfortunately, I have to run. Let me know if you see any obvious gaps in this diagram.

I will write a mock up of the program in PHP. I might convert the program to c. I will open source the code after I write it.