Open Source
What I built and maintain for the open source trading community
Most of my trading work since 2019 has depended on other people's open source: broker SDKs, a crypto bot framework, pricing formulas. When those projects had gaps, I forked them, fixed what I needed, used the fork in my own tooling, and sent fixes upstream where I hit bugs. Alongside the forks I have open sourced two tools of my own. This post is an inventory of all of it, how to get started with each, and how to contribute if you use the same brokers.
A note on language. I say "forked and adapted" rather than "maintain" for most of these because that is what they are. The upstream projects have their own maintainers. My forks carry the changes I needed, and I keep them usable because I depend on them.
Broker and platform SDKs
gokiteconnect: Zerodha Kite Connect in Go
Kite Connect is Zerodha's trading API and the one I have used the longest. I wanted a Go client for a low-latency order service I was building, so I forked the Go SDK, adapted it to how I structure services, and used it as the order and market data layer in my own tooling. The things I touched were the parts you only notice under real use: reconnect behaviour on the ticker, error surfaces that were swallowed, and typed responses where the upstream returned loosely structured data.
Getting started looks like any Go module. Add the fork as a dependency, create a client with your API key, exchange the request token for a session, and you are placing orders.
package main
import (
"fmt"
kiteconnect "github.com/aadityatamrakar/gokiteconnect"
)
func main() {
kc := kiteconnect.New("your_api_key")
// requestToken comes back from the Kite login redirect
data, err := kc.GenerateSession(requestToken, "your_api_secret")
if err != nil {
panic(err)
}
kc.SetAccessToken(data.AccessToken)
margins, err := kc.GetUserMargins()
fmt.Println(margins, err)
}
xts-interactive-nodeJS-api-v2: XTS in Node
XTS is the API platform used by several Indian brokers. The official Node client works, but I needed it to behave inside a long-running process: survive socket disconnects, not leak listeners, and expose promises instead of callbacks in the places I called most. The v2 fork is that. If you are on a broker that uses XTS and you write JavaScript, it is the version I would start from.
5paisa-js: 5paisa in Node
5paisa's API had a JavaScript client that covered login and order placement but was thin on the pieces I needed around market data and session handling. I forked it, filled the gaps I hit, and used it in a small screener. It is the least developed of the three broker forks and the one I would most like help with.
hbot-remote-client-py: a Hummingbot remote client in Python
Hummingbot is an open source market making and arbitrage framework for crypto. Running it is fine; controlling it from outside its own console is the hard part. The remote client fork lets a separate Python process send commands to a running Hummingbot instance and read its state, which is how I wired it into my own monitoring. If you run more than one bot, something like this becomes necessary quickly.
option-pricing: the CCP formulas
This is a small repo of option pricing formulas. I use it to compute theoretical values and Greeks alongside the live chain, so I can see whether a premium is rich or cheap relative to a model. It is deliberately a formulas library and not a framework. You give it spot, strike, time, rate and volatility and get back a price. Here is the shape of a call to it, with a plain Black-Scholes style signature:
from option_pricing import call_price, put_price, greeks
spot, strike = 24500, 24600
t = 7 / 365 # years to expiry
rate = 0.065
vol = 0.14
theo = call_price(spot, strike, t, rate, vol)
g = greeks(spot, strike, t, rate, vol, kind="call")
print(theo, g["delta"], g["theta"])
zenbot
Earlier on I also forked zenbot, a Node crypto trading bot, to try strategies against exchange data. It is the oldest of the set and I do not actively use it any more, but the fork is still there for anyone who wants a starting point.
Tools I open sourced
option_chain_analysis
A Node app that fetches the NSE Nifty option chain on each visit and labels every strike as a long buildup, short buildup, short covering or long liquidation from the price change and the open interest change. It has an expiry selector, a FINNIFTY switch in app.js, and it uses cURL for the fetch because Node's HTTP clients were blocked by the exchange. I hosted it on Heroku in 2019. It is education only. At 106 stars and 77 forks it is the most used thing I have published, and I have written about how it is built and how to read what it shows.
futures_spread_chart
A Node and Express app that computes the daily cash versus futures spread for NSE stocks in spreadData.js and plots it at /chart.html. It exists because no broker UI I used would show the two prices as a difference over time. The write-up covers the design.
How to get started with any of them
Every repo follows the same shape, so the on-ramp is the same:
# pick a repo
git clone https://github.com/aadityatamrakar/option_chain_analysis
cd option_chain_analysis
# Node projects
npm install
node app.js # or: node server.js for futures_spread_chart
# Go projects
go get github.com/aadityatamrakar/gokiteconnect
# Python projects
pip install -e .
For the broker SDKs you will need API credentials from the broker, and for most of them a daily login step that produces a request token. Keep credentials in environment variables, never in the repo; every fork reads them from the environment or from a config file that is git-ignored.
How to contribute
These are small projects and I treat contributions the same way across all of them.
- Open an issue first for anything beyond a typo. Broker APIs change under us, and half the time the fix is already in progress or the behaviour is intentional.
- Keep the data source behind a flag. If you add a new exchange or endpoint to
option_chain_analysisorfutures_spread_chart, add it alongside the existing one so both keep working. - Match the upstream style in SDK forks. That makes it easier to send the change upstream later, which is where it should live if it is a general fix.
- No credentials, ever. Pull requests containing API keys, tokens or account IDs are closed without review.
- Tests where they exist, examples where they do not. Several of these repos have no test suite. A runnable example that shows the change working is an acceptable substitute.
- Say which broker and which API version you tested against. This matters more than anything else for SDK bugs.
If you use the same brokers and you fix something, I would rather you send it than keep a private patch. Most of the useful changes in these forks came from me doing exactly that.
What I learned
- Forking to fix a bug is a commitment. Once your tooling depends on the fork, you own keeping it current with the broker.
- The most valuable contributions to an SDK are reconnect logic and error surfacing, not new endpoints.
- Small tools with one clear job get forked and adapted far more than large ones. The option chain analyser is a few files and that is why it travelled.
- Writing "education only" and "no credentials" in the README up front saves a great deal of email.
Repos mentioned: gokiteconnect, xts-interactive-nodeJS-api-v2, 5paisa-js, hbot-remote-client-py, option-pricing, option_chain_analysis, futures_spread_chart.