Currently people are placing orders mindlessly. To prevent random orders from being placed, a fee of 3 % is charged on whatever the order is worth (price x quantity).

I'm not a 100% sure on the kind of effect this will have on the game but atleast for the demo, we can see how this works out. Can be removed if it doesn't add any positive effect.

For the game to adjust in terms of difficulty for relatively wealthy players, we could have tax instead of mortage interest over time. I feel this solves the issue better. We could have tax brackets based on net worth.

These are modified version of the files on DalalStreetv3 repo. I'm updating those too with this commit.

Actions for getting data aren't available yet. But the structure is laid out in this commit.

This PR addresses #236 - check this issue for an explanation on the implementation.

Issues that still exist :-

• After a tax is charged, there is no indication on the frontend that a tax was charged.
• The cash and stock value changes in the Nav Bar immediately after a trade happens but this doesn't reflect the tax that was charged. Only after refreshing the page does it update correctly.

Also change the styling of the line graph. It's honestly terrible.

Volume already arrives with the stock history data, but doesn't get plotted. It'll be cool to show the volume on the charts as well to show which periods are most active, etc.

This is bad. The first thing to do for next year is to undo whatever this issue asks you to. Since we now reserve assets prior to execution of requests, all subsequent OrderFillTransactions received to the frontend will only contain partial information. OrderFillTransactions will no longer have details like how much stocks were sold for an AskOrder, how much cash was taken from reserved cash for a BidOrder.

Solution

1. Create a new type of Transaction. Call it ReserveUpdateTransaction
2. These transactions WILL NOT be saved in the database. This is to maintain the sum(...) integrity.
3. For an AskOrder being matched, the transaction will have how much stocks were matched.
4. For an BidOrder being matched, the transaction will have how much cash was taken out of reserve.
5. Send this transaction to the frontend.

• removed frontend & bots submodule
• removed wrapped improbable-eng/grpc-web server (we'll use envoy here after for grpc-web client)
• add serve mux for rest api
• go fmt
• removed docker files
• news(market events) assets files will be downloaded in public directory and served statically (rest fashion)
• add air conf for live reload (not hot reload)

TODO

• dockerize the server with envoy proxy

IMP

• dalal-street-web will not work without improbable-eng/grpc-web (can we use it in dev mode ?)

Alright so here's the deal.

I guess we still don't know why we faced an integer wraparound error last year, and I haven't investigated it yet, so until we have the time and patience to read through the entire codebase to figure out the root cause, I'd prefer it if we just merged this hack that we used last year.

k thnx.

This PR closes #248

Right now Market Orders can be heavily exploited. Either clear pending Market or add a Market Order fee for getting (if margin of profit is large enough, then this doesn't help). Or something else?

Problem

We do not have a proper mechanism to handle stock history. We returned entire history of the stock last year, but that's a terrible thing to do.

How other sites solve it

Most stock sites provide you to specify the ranges of the stock history (1day, 5day, 1month, 3month, 6month, 1yr, 2yr, 5yr, Max - these are standard ranges, some offer lesser, some more). We'll follow the same. However, our game will be of only 10-14 days (mostly 10) and will run for 5-6 hours a day, so people won't be using most of the ranges except for looking at how the company did in the past. So maybe we should change our ranges to something more relevant (like have more short term ranges starting from 1 hour). We'll still need long-term ranges for completeness and for giving the gameplay some story factor.

Also, for each range the granularity/interval (we'll call it interval from now on) will be pre-decided. For example, in 1day range, stock prices of every minute will be shown. In 5day range, stock prices of every 5min interval will be shown, etc.

To get a feel of these, checkout any site - yahoo finance is pretty good, or http://gdax.com/trade/ETH-USD

Candlesticks business

Also, we'll be showing price candlesticks on the frontend. These require 4 things - Open, High, Low, Close prices for each interval. Open is the price at the start of the interval, High is the highest price during the interval, Low is the Lowest price during the interval. Close is the price at the close of the interval (this will coincide with the Open price of the next interval). Look up stock candlesticks if you're still confused.

And, I'd like the trade volume to be stored as well. But that'll be part of another PR.

Parts of the problem

1. First part of this feature would be to figure out what ranges & corresponding intervals we want to support.

2. Second part would be to figure out how we'd be querying the data.

3. Third part will be the actual coding. It'll affect models and proto and gRPC API.

THIS IS A MAJOR PR. Read it carefully and TEST IT TEST IT before merging.

Like seriously, clone it to your local and do whatever you can to try and break it. Only then should we merge it.

Old stock price logic :-

1. stock.CurrentPrice = price at which last transaction was executed The problem - This could cause the stock to fluctuate wildly as we saw last year in Dalal

2. stock.avgLastPrice = average price at which last 20 transactions were executed. The problem - This doesn't take into account the number of stocks that were traded in each transaction i.e A transaction with 1000 stocks would carry the same weight as a transaction with 1 stock.

What this PR changes the stock price logic to :-

1. stock.CurrentPrice is now the weighted average of the price at which the last x stocks were traded where

x = min(1% of total number of stocks in circulation, 20)

The reason for the upper limit of 20 is that as x increases, the amount of stock price fluctuation reduces, and if we allow x to increase unchecked, then the stock price will never change.

This solves both of the above problems

2. stock.avgLastPrice has been renamed to stock.lastTradePrice since the currentPrice now stores the average price anyways. The table column names and proto files have been updated accordingly.

Commit notes

• This PR resyncs with proto
• This PR closes #214

We faced some weird issues like market sell orders not getting matched for some time even though there was a matching buy order for that. On looking upon the matching engine code, we found out that there is some issues regarding the implementation of that. Try to refactor that

This might be useful during testing and in prod also if you find that people are manipulating the market then we can clear it from the admin panel itself

We tried to find people who played in groups using Strongly Connected Components by taking transactions between users as the edge but during event , we saw that it wasnt effective in finding groups as even a small number of random transactions were making them come into the SCC. Try to come up with new idea for that

This year , we tried to add a constraint where we check in each transaction if the user has enough cash to retrieve the stocks after short selling, but in the main event as the no of transactions were high, we faced some sql lock timed out issues during first day. Have to think about better way of doing this and also we need to write stress tests to check with lot of concurrent transactions.