That work used to take weeks or months. It doesn’t anymore.

I recently recorded a session with Groww to show exactly how this works now. I started by downloading Claude, with nothing but an idea. I ended with a tested backtester, a dashboard that audits every trade, and an engine that can paper trade or place real orders through the Groww API. I didn’t write a single line of code by hand.

The strategy we used was a simple 9/21 EMA crossover on NIFTY options. The strategy isn’t the point. The workflow is, and it works for any rule-based idea you have. You can have a look at the dashboard created here. (groww.raahibhushan.in)

Watch the full video here:

Then vs now

My first algos were hand-written, and each took a couple of month to write and test them throughly. With AI, the same kind of build now takes less than a day.

Your job moves from writing code to writing rules. That’s a much better use of a trader’s time. And now it has become super simple for traders who don’t know how to code.

Steps 1 and 2: Install Claude, connect your broker

Install Claude. Download the desktop app and sign in. This takes a few minutes. Codex or another coding agent works too; the workflow is the same.

Connect the Groww API. You create an API key on Groww. There are two ways to authenticate: an access token you regenerate by hand every day, or an API key with TOTP, which lets your system log in on its own. Use TOTP if you want anything to run unattended.

Then ask Claude for a small first app: log in to Groww and show my profile and funds. It sounds trivial, but it proves the connection works before you build anything on top of it. In the video, Claude:

• set up the project and Groww’s official SDK

• kept the keys in a local file that is never logged, copied or committed to git

• made the app read-only, so it could not place orders

• tested it against my account and wrote 7 passing tests

That’s your foundation. Everything after this reuses it.

Step 3: Describe the strategy

This is the only step that needs real thought. Claude writes the code, but you still write the rules. A good prompt covers six things:

Add two lines to every prompt, whatever the strategy:

• “Make every ambiguity explicit.” Does the signal fill on the close of the bar or the next open? What if two signals tie? What about days with missing data? If you don’t ask, the code quietly picks an answer for you.

• “Plan first, show me the plan, then build.” You review the plan before any code exists. Fixing a misunderstanding there costs a sentence. Fixing it later costs a rebuild.

Here is the full prompt I used, lightly trimmed. Swap the strategy rules for yours and keep the rest:

I want to build a 9/21 EMA crossover options strategy to live trade
during market hours, and a backtester + trade-viewer web app.

Build an app that can run an intraday 9/21 EMA crossover on NIFTY
index options. Create a webpage where I can see the results of the
strategy using 1-minute historical data downloaded from the Groww API.
Also create a dashboard where I can audit every simulated trade on a
candlestick chart. Plan first, show me the plan, then build.

Strategy rules
- Signal: 9 EMA crosses 21 EMA on closed spot bars. Timeframe is
  selectable: 5m, 15m or 30m, resampled from 1m bars aligned to the
  09:15 open.
- Entry window: start time every 30 mins from 09:30 till 10:30, and a
  cutoff from 11:30 till 14:30 (configurable). Signals outside it are
  ignored.
- Exit: opposite crossover, or mandatory square-off at 15:00.
  Immediate reversal: an opposite cross inside the window closes the
  trade and opens the reverse trade.
- Execution modes (all compared in the UI): Deep ITM buy (ITM 5),
  ATM buy, ATM sell.
- Sizing: lot size 65, 1 lot.

Make every ambiguity explicit (which bar triggers the fill, tie
handling, no-trade days).

Data: get the data using Groww APIs and store it in a Postgres
database. If Postgres is not available, install it locally.

Other things
- Friction: slippage (0.5% of premium plus fixed points; sell price
  floored at the 0.05 tick) and the full Indian options cost stack
  (brokerage, STT, exchange charges, SEBI fee, stamp duty, GST).
  Show gross PnL, friction and net PnL.
- Metrics: trades, win rate, net/gross PnL, profit factor, payoff
  ratio, expectancy, max drawdown (₹ and %).
- Test everything thoroughly so that there are no bugs.

Step 4: Backtest and audit

Claude showed me the plan, I approved it, and it built the rest on its own:

• Downloaded two years of 1-minute NIFTY spot and option candles from Groww and stored them in a local Postgres database

• Built the backtester and precomputed all 189 combinations of timeframe, mode, entry window and cutoff, so every filter on the dashboard is instant

• Wrote 61 automated tests, and checked one trade by hand against the raw candles

• Built a dashboard showing net and gross P&L, win rate, profit factor, drawdown and the full cost breakdown, with equity curves for each mode side by side

• Put every trade on its own candlestick chart, with both EMAs, the entry and exit markers, and the option’s 1-minute premium

• Flagged where the data was thin: 24 days with no option data in one mode, and 15 of about 59,000 trades filled from a later bar

The trade-by-trade view is the most valuable part. It’s how you catch a bug, or a rule that doesn’t do what you meant.

You can view the dashboard created by Claude here. (groww.raahibhushan.in)

As for this particular strategy, the backtest was honest with me. Only one of nine variants made money after costs, and that result is still in-sample. That’s exactly what a backtest is for: you find out in a day, not with real money.

Step 5: From backtest to execution engine

A backtest only matters if you can trade it. I asked Claude to make the strategy tradeable, and it built a Live page on top of the same app.

The key design choice: the backtest, paper trading and live trading all share one decision core. The code that decides when to enter and exit is the same in every mode. What you tested is exactly what trades.

The engine has three modes:

Live trading sits behind three locks. It is switched off on the server by default. You must tick a box saying you understand the risk. Then you type TRADE LIVE to confirm.

Each session also has risk limits you set up front: a maximum daily loss (₹10,000 in the video), a maximum number of trades per day, lot size and product type. The engine passed 100 automated tests, including browser tests.

Claude was also upfront about what it hadn’t done. We recorded on a Saturday, so the engine had never run against the live Groww API. It said the order and quote handling was written from the SDK docs and covered only by simulated tests, and asked me to run a full paper session on Monday before turning live on. That’s the kind of note you want from a developer.

What still needs you

The code is no longer the hard part. These still are:

• The rules. A vague prompt gets you a vague strategy. Spell out every edge case.

• The costs. If your backtest ignores slippage and charges, it will flatter you. Put them in the prompt from day one.

• The review. Read the plan before the build. Click through the trades after. Read the notes about data gaps and untested parts.

• The patience. Paper trade before you go live, and judge a strategy on forward results, not just the backtest.

The tools changed. Trading discipline didn’t.

Try it yourself

You don’t need to be a developer. You need:

• A Groww account with Trade API access

• Claude (or another coding agent) on your laptop

• A strategy you can explain in plain English, edge cases included

• The prompt above, with your rules swapped in

Start with a setup you already trade by hand. Write the rules as if you were explaining them to a new trader. Ask for the plan first. Audit the trades. Paper trade it. Only then think about going live.

The full walkthrough, from installing Claude to the live trading page, is in the video:

If you build something with this, reply and tell me what you automated.

This post is for education only. It is not investment advice. Backtested results don’t guarantee future returns, and automated trading carries real risk, including losses from bugs and bad fills.

Jump to: Why I built this · What it does · Architecture · Installing on your own server · Security · Building on top of it · Lessons learned · Compliance note · Issues

Why I built this

I’ve been trading NIFTY and SENSEX options for a while, and the manual parts of it — watching gaps, re-placing orders as price moves, tracking Greeks across positions, remembering to exit before expiry decay eats the premium — were exactly the kind of repetitive, rules-based work that should be automated. So I built myself a Flask dashboard on top of Zerodha’s Kite Connect API: live positions with Greeks, a few automated strategies, GTT monitoring, a trade journal.

Over time it grew into something I actually run every trading day. And once I had something real and working, it felt worth sharing — not because it’s a polished product, but because the shape of the problem (broker API → order engine → dashboard → strategies) is one a lot of people trading through Zerodha run into, and there wasn’t an open reference implementation I could point people to. So I cleaned it up, stripped out my personal/experimental strategies, added the safety rails a stranger’s install would need, and put it up.

What it does (Existing Modules)

Everything runs as a single process on your own machine, against your own Zerodha account. Nothing phones home, nothing routes through a third-party server.

Architecture

It’s one Flask process (served by waitress, bound to 127.0.0.1 only) plus a handful of strategy subprocesses it spawns and tracks by PID:

Auth:                    Browser → Flask gatekeeper login → Kite Connect OAuth
                              → access_token → Flask session + instruments.db (restart recovery)

Orders:                strategy process → common_lib.place_order()
                             → [safety] live_trading gate → Kite Connect API
                             → on_order_update() WebSocket callback → JSON state file

Positions:           KiteConnect.positions() → positions_lib → Greeks (Black-Scholes)
                             → dashboard

Instruments:     daily 9 AM IST → instrument_cache.sync_instruments()
                           → SQLite, atomic swap

The core engine (common_lib.py) handles order placement/cancellation with retry-with-backoff, gap management, delta calculations, and order-state persistence. Everything reads instrument tokens through instrument_cache.py rather than hardcoding them — tokens change after corporate actions, and lot sizes change too (NIFTY’s lot size, for instance, has changed more than once).

Strategies that trade continuously — Wave Extractor, Survivor — run as separate OS processes rather than threads inside the Flask app, one per symbol, each writing its own log. The dashboard tracks them by PID and refuses to double-spawn a scraper for a symbol that already has one running.

Installing on your own server

The quickstart is genuinely three commands:

git clone https://github.com/Raahi-Bhushan/ui-trading-system.git
cd ui-trading-system
python -m venv venv && source venv/bin/activate
pip install -r requirements.txt
python flask_app.py

Open http://127.0.0.1:5010/ and you land in a setup wizard — it collects your Kite Connect API key/secret and a dashboard username/password, and writes configfile.ini for you. No hand-editing an INI file. When you submit the form, the app restarts itself in place automatically (same process, same port) — the wizard page polls in the background and redirects you to login the moment it’s back up.

That’s enough to run it locally. If you want it always-on, here’s the version of the setup I actually run:

1. A small always-on VM. I run mine on GCP; AWS works the same way. An e2-small (or equivalent burstable instance) is plenty — this isn’t compute-heavy, it’s mostly waiting on WebSocket ticks and making occasional API calls.

2. A static external IP. Reserve one (gcloud compute addresses create on GCP, an Elastic IP on AWS) and attach it to the instance. You need this because the Kite Connect app’s redirect URL is fixed — if your IP changes on every reboot, your OAuth login breaks every time the instance restarts.

3. Put a TLS-terminating reverse proxy in front, don’t expose the Flask port directly. The app deliberately binds to 127.0.0.1 only — that’s not a limitation, it’s the point. Run Caddy or nginx on the box, forward your domain (or https://your-ip) to 127.0.0.1:5010, and only open 80/443 in your firewall, not 5010. A minimal Caddy config:

trading.example.com {
    reverse_proxy 127.0.0.1:5010
}

4. Configure the Kite Connect app’s redirect URL to match. In the Kite Connect developer console, set the redirect URL for your app to https://trading.example.com/login (or https://<static-ip>/login if you’re not using a domain yet). This has to match exactly what your reverse proxy serves, or the OAuth callback lands nowhere. If you run more than one instance of this app (say, a local dev copy and a server copy) against the same Kite Connect app, be aware that browsers scope cookies by hostname only — not by port — so the OAuth redirect always lands wherever that fixed URL points, regardless of which instance initiated the login. Either use separate Kite Connect apps for separate environments, or only run one at a time.

5. Run it under systemd, not a raw terminal. A simple unit file that restarts on failure:

[Unit]
Description=Trading Dashboard
After=network.target

[Service]
WorkingDirectory=/home/you/ui-trading-system
ExecStart=/home/you/ui-trading-system/venv/bin/python flask_app.py
Restart=always
User=you

[Install]
WantedBy=multi-user.target

Because the setup wizard restarts the app via os.execv (an in-place process replacement, not a fresh spawn), it keeps the same PID — systemd doesn’t even register it as a restart event, so this works cleanly under a service manager too.

Security by default, not as an afterthought

This is code that, if you enable live trading, can place real orders on your account. I didn’t want “here’s a GitHub repo, good luck” to be the trust model, so a few things are deliberate:

• Dry-run by default. Every fresh install starts with [safety] live_trading = false. Every order-placement call is logged with full parameters, but nothing reaches Zerodha. The header shows a yellow DRY-RUN badge until you explicitly flip it (and it turns red LIVE when you do).

• CSRF protection on every state-changing request (Flask-WTF), with a JS shim that attaches tokens to fetch/XHR calls automatically so it doesn’t leak into every template.

• Rate limiting on order-affecting endpoints — generous enough (up to 120/min) that an emergency stop-all is never itself rate-limited, but enough to blunt a runaway script or leaked credential.

• Input validation on trading parameters — symbol allowlist regex, numeric range checks — before anything reaches a filename or a subprocess call.

• Login lockout: 5 failed attempts per IP triggers a 15-minute lockout.

The known, accepted trade-offs (documented, not hidden): it’s single-user with one shared gatekeeper credential, lockout/rate-limit state is in-memory and resets on restart, and configfile.ini holds your API key/secret in plaintext on disk. This is a self-hosted single-operator tool, not a multi-tenant SaaS — restrict filesystem access accordingly, and always run it behind HTTPS if you expose it beyond localhost.

Building on top of it

The reason I structured it the way I did — a core engine (common_lib.py, positions_lib.py, instrument_cache.py, greeks_lib.py) cleanly separated from the Flask routes and the strategy scripts — is so it’s a base, not a finished product. A few ways to build on it:

• New strategies as standalone scripts. Look at place_order_at_nifty.py or ticker_single_scraper_new.py as templates — they import common_lib, use retry_with_backoff( ) for every Kite call, and persist state as JSON via save_executed_order()/load_todays_orders( ). A new strategy is mostly “when should I call place_order( )”, not new infrastructure.

• The core library is pip-installable on its own, if you just want the primitives (order placement with retries, instrument cache, Greeks) without the dashboard: bash pip install . python -c “import instrument_cache, positions_lib, greeks_lib”

• Greeks are pluggable. greeks_lib.py is a facade over either the embedded Black-Scholes implementation or the faster opengreeks package, selected via config — swap the backend without touching strategy code.

• Notifications are a drop-in hook. The notifications / blueprint already wires Telegram and browser Web Push into order events; a new strategy gets alerting for free by going through the same event path.

If you build something interesting on top of it, I’d genuinely like to hear about it.

Lessons learned

A few of the more interesting bugs from actually running this on a fresh server, for anyone building something similar:

Cookies are scoped by hostname, not port. I hit a very confusing session bug where logging in on one running instance of the app would silently log out a different instance running on another port on the same machine. The cause: browsers scope cookies by hostname only (RFC 6265) — port is irrelevant. Since the Kite Connect redirect URL is fixed to one host:port, any OAuth flow always lands there regardless of which instance kicked it off, and two Flask processes with different secret keys stomp on each other’s session cookie. Fix: separate Kite Connect apps per environment, or run one instance at a time.

SQLite atomic swaps aren’t automatically race-free. The instrument cache syncs by writing to a staging table and doing an atomic rename — but with no locking, a background auto-sync and a manual “Sync Instruments” click could race on the same staging table, with one thread’s DROP TABLE pulling the rug out from under the other’s INSERT. Fixed with a simple non-blocking threading.Lock(): if a sync is already in flight, the second caller backs off cleanly instead of racing.

WebSocket order updates don’t arrive in the order you’d expect. A COMPLETE callback can arrive before the corresponding OPEN callback — especially for GTT-fired orders. If your state machine assumes OPEN always comes first, it’ll silently drop completions. The fix wasn’t in the callback logic at all — it’s a 180-second polling loop that’s the authoritative source of truth, with the WebSocket as a fast-path optimization, not the other way around.

A note on compliance

This is India, trading through Zerodha, so it’s worth being explicit: automated/algorithmic order placement may fall under SEBI and exchange rules around algo trading, separate from the general “you can lose money” risk disclaimer. This project doesn’t make any claim about regulatory compliance on your behalf — it’s your responsibility to understand what rules apply to how you use it, same as if you wrote the code yourself.

Running into issues

If you hit a bug or get stuck setting it up, ping me on X — @raahi_bhushan. I’d rather you ask than silently give up or, worse, run something you don’t understand.

FAQ

(I’ll keep adding to this as people ask questions — these are the ones that have come up already.)

Do I need a paid Zerodha API subscription? Yes. Kite Connect is a paid add-on from developers.kite.trade — the free Kite web login doesn’t give you API access.

Why does the header say DRY-RUN and won’t go away? Because live_trading = false is the default, on purpose. Flip it in configfile.ini (or re-run the setup wizard) and restart once you’ve verified your setup.

Orders return -1 in dry-run — is that a bug? No — that’s the established “not placed” sentinel so strategy code follows its no-fill path cleanly instead of tracking a phantom order.

Why do I have to log in every morning? Zerodha invalidates access tokens daily, around 6 AM IST. Click Connect Kite each trading morning. The token’s cached so restarts within the day don’t need a fresh login.

Can I run this on a VPS / cloud VM? Yes — see the installation section above. Keep the Flask port on localhost, put a TLS reverse proxy in front, use a strong gatekeeper password.

Where’s the copy-trading / ML predictor / backtesting code you’ve mentioned elsewhere? This public repo is exported from a larger private codebase. Those modules are personal/experimental and intentionally weren’t included in the public release.

What’s next

The core library is already pip-installable; I’d like to publish it properly. A hosted docs site (architecture reference, per-module guides, full FAQ) is in progress. And I’ll keep adding strategies as I build them for myself — the point of open-sourcing this was never to freeze it, it’s to have a base that keeps growing.

If you found this useful: star the repo, follow @raahi_bhushan on X, and subscribe here for updates as the project grows.

Disclaimer: This project is shared for educational purposes — to demonstrate one way to build a self-hosted trading setup, not as investment advice or a guaranteed money-making system. It can place real orders with real money when live trading is enabled and may contain bugs. The author accepts no responsibility for any financial loss arising from its use. Read the code, understand what it does, and test thoroughly in dry-run mode before you ever enable live trading — everything it does in your account after that is your responsibility. Full disclaimer: DISCLAIMER.md.

You can also connect with me directly on X (Twitter) — my DMs are open!

Connect with me on X

Let’s exchange ideas. That’s how we all grow 🚀

On Feb 3, 2026, following the landmark India-US Trade Deal announcement, the Nifty didn't just move—it leaped. I opened my terminal to see a sea of red: an MTM staring back at me at >-₹10,00,000.

The “Trap” Positions

Going into the day, I was carrying short Call positions that were effectively "blown out" by the 1,200-point gap. Here is what the damage looked like:

While the initial gap and IV spike made the MTM feel like -13L at the peak, I eventually booked these at a total loss of ₹5,79,126 (relative to the previous close).

The question was: How do I recover from a 6-figure hole? Using my tradebook and AI-assisted insights, here is the session-by-session breakdown of the "Firefighting" that saved the day.

Here is the trades breakdown in different sessions during the day

Session 1: The First Hour Firefight (09:15 – 10:15)

This hour was about raw survival. The old "safe" zones were gone; I had to move my strikes to the very edge of the new price action.

• The Activity: I aggressively sold 10,075 units of Puts and 2,600 units of Calls at much higher strikes.

• The Floor (25450 – 25700 PE): With the market near 26,300, I sold deep into the “Panic Premium.” The 25450 PE was paying ₹81 at open despite being 800 points away.

• The Ceiling (25800 – 26000 CE): I tested a new “Strangle” around 26,000 but remained cautious with Call quantity to avoid a second “melt-up” wave.

The Lifecycle of Session 1 Puts (FIFO): I didn’t just “set and forget.” Out of the 10,075 Puts sold:

• 325 units were scalped immediately for a quick gain.

• 8,775 units (the core recovery) were closed in Session 2 as the market stabilized.

• Outcome: I locked in ₹4.05 Lakhs in earned premium just from this first-hour offensive.

Session 2: The Strategic Grind (10:15 – 13:15)

Once it was clear the market wouldn't collapse back into the gap, I turned the heat up on theta decay.

• Chasing the Trend (25750 – 25900 PE): I moved strikes closer to the spot. Since I still held those deep ITM calls (which have a Delta of ~1), they acted as a natural hedge against my aggressive Put selling.

• The IV Crush: As Implied Volatility began to contract in the afternoon, these Puts decayed rapidly. This session contributed another ₹2.13 Lakhs to the recovery.

• Rolling Up and Out: I accepted that the 25xxx Calls were “dead money” and reset my wing to the 26000 – 26200 CE range to buffer against late-day rallies.

Premium Dynamics: Selling into the “IV Spike”

The genius of your Session 1 and Session 2 trades was Time and Volatility.

Session 3: The Clean-Up (13:15 – 15:30)

The final session was about closing the “legacy” positions that started the nightmare.

• Realizing the Pain: I systematically bought back the 25250 and 25350 Calls. The realized loss on those initial positions was -₹5.78 Lakhs.

• The Math of Survival: Because I had collected ₹6.8L+ in premium from new trades throughout Sessions 1 and 2, I was able to absorb the massive hit and finish the day within striking distance of green.

The Final Takeaway

When you start the day at >-10L, your goal isn’t a jackpot—it’s Capital Preservation. By selling over 20,000 units across the day, I replaced “dead” delta with “active” theta.

Discipline > Luck. The process of active adjustment turned a potential account-killer into a survivable day.

Let’s Talk: How Did You Handle the Gap?

The Feb 3rd “Trade Deal” gap will likely be talked about for months. It was a day that separated those who have a plan from those who have a process. While the numbers on my screen were intimidating at 9:15 AM, the process of active adjustment turned a potential nightmare into a successful recovery.

But enough about my screen—how was your day? * Did you get caught on the wrong side of the gap, or were you riding the momentum?

• What was your “firefighting” move of the day?

• If you’re a beginner and seeing an MTM of -10L sounds terrifying, what’s the one question you have about how I managed the risk?

Share your story in the comments below! I’ll be jumping in to answer any specific queries about the strikes, the margin management, or the FIFO logic used in this recovery. Let’s learn from the fire together.

You can also connect with me directly on X (Twitter) — my DMs are open!

Connect with me on X

Let’s exchange ideas. That’s how we all grow 🚀

Want to understand how the Wave strategy actually works? Check out the detailed explanation here:
👉 The Wave Extractor Algo Explained

If you’ve read about how this algo works, you can now see the code, tinker with it, and build on top of it.

🔗 GitHub Repository:
👉 Raahi-Bhushan/trading-algo

⚠️ Disclaimer

This algorithm is shared for educational and informational purposes only. Trading carries substantial risk, and you could lose your entire investment or more. Any trades you make using this code are entirely at your own risk. The creators assume no responsibility for financial losses.

Before deploying with real capital, thoroughly test the code itself and your configurations in a simulated environment to ensure everything works as expected. The code may have bugs, broker APIs can change, and market conditions vary — what works in testing may behave differently in live markets. Never run untested code with real money. Always do your own research and consult a qualified advisor before trading.

What’s new:

• Wave Strategy added: The range-trading algo that captures intraday volatility is now available alongside the Survivor strategy

• Broker code standardization: Cleaner, more maintainable code structure for better extensibility

The idea is to make these systematic strategies more accessible and share what’s been learned, help others avoid mistakes, and contribute to the trading and coding community.

If you’re interested in algorithmic trading, whether you’re a coder, trader, or just curious, this is a good place to start exploring.

📢 Questions or Issues?

If you run into any problems or have questions:

• Create an issue on the GitHub repository

• Reach out on X to Raahi or Sambath

And if you want updates when more algos go live, consider subscribing!

When I first dipped my toes into trading, I noticed something curious about NIFTY: it kept bouncing up and down all day, but by the end of it, hadn’t really gone anywhere. That daily volatility felt like untapped opportunity. I thought to myself — if I can just time my entries and exits well, there’s money to be made in this sideways movement.

Back then, I didn’t have much technical knowledge. I wasn’t drawing support/resistance lines or looking at moving averages. I was just observing price behaviour and trying to make sense of it in the most intuitive way.

The Birth of a Simple Idea 🔄

That’s when I built one of my first algos — super simple but very logical at its core.

Here’s how it worked:

• If the price went up by X points, the algo would sell Futures or Call Options (CEs).

• If the price then dipped, it would buy them back, locking in the difference as profit.

• The same logic applied on the downside:

  • If the market fell, the algo would sell Puts (PEs).

  • As the price recovered, it would buy them back.

The logic was rooted in one principle: always sell first, and buy back later — especially in options. This made the strategy theta positive, which means time decay was working in our favour. Every passing minute increased our chances of profit — provided price stayed within a range.

The Catch: One-Sided Trends 💥

As elegant as it sounds, the strategy wasn’t foolproof. It worked beautifully in choppy or range-bound markets, but there was a catch…

In a strong one-sided trend — say, when the market kept moving up or down without reversing — this strategy could quickly accumulate heavy losses. Why? Because it kept fighting the trend, expecting reversals that never came.

Connect with me on X

The Saviour Combo 🤝

To protect against this, I paired this strategy with the Saviour Algo — a trend-following system that thrives during strong directional moves. So if the market does start trending sharply in one direction, the losses from the range strategy are offset (and sometimes even overcompensated) by the gains from Saviour.

Think of it like this:

• Range Strategy: Makes money in sideways markets.

• Saviour Algo: Kicks in when the market breaks out of the range.

Together, they balance each other out — one zigging when the other zags. 🧘‍♂️

We are looking at making this code opensource for this algo as well, so stay tuned.

What AI has to say about the code 🤖

Let's decode the run command:

python3.8 ticker_single_scraper_new.py 30 30 <OPTION_SYMBOL> 75:75 <REQUEST_TOKEN>

Once you run this, the bot comes to life. It connects to the API, fetches the current price of your chosen symbol, and immediately places its first "duo order" using the place_duo_order function.

The Secret Sauce: The multiplier_scale

This is where the Scraper goes from being a simple bot to an intelligent trading machine. What happens if the market starts trending strongly in one direction? A simple bot might keep buying as the price falls, digging itself into a deeper and deeper hole.

The Scraper has a brilliant solution: the multiplier_scale.

This is a built-in "learning" mechanism that makes the bot more cautious when it's on the wrong side of a trend. It works by tracking its net position (the total number of buys minus the total number of sells).

If the bot has a net SELL position (e.g., it has sold 3 times but only bought back once), it means the market is trending up. To avoid fighting this powerful uptrend, it automatically makes it harder to sell again. It does this by multiplying the sell_gap by a factor (e.g., 1.3x or 1.7x). The sell order is now placed further away, requiring a much bigger price spike to get filled.

If the bot has a net BUY position, it means the market is trending down. The bot adapts by widening the buy_gap, making it more difficult to add to its losing position.

This dynamic adjustment is the bot's superpower. It allows it to be aggressive in a sideways market but automatically becomes defensive and cautious when a strong trend emerges. It widens its trading bracket to avoid getting run over by the trend.

Built-in Safety Features

Any good trading bot needs safety nets. The Scraper has a few key ones:

1. The Cool-Off Period (cool_off_time): Inside the place_duo_order function, there's a mandatory pause (e.g., 5 seconds) before a new bracket is placed. This is a critical circuit breaker. It prevents the bot from firing off dozens of trades in a few seconds during a "flash crash" or a sudden, volatile news event. It forces the bot to "take a breath" and re-assess before jumping back in.

2. The Guardian Loop: The main while True: loop in the script constantly asks one question: "Are there any active orders in the market?" If the answer is no (meaning a trade was just completed or canceled), it knows it's safe to place a new duo order. This ensures the bot is always working but never places new orders while old ones are still pending.

3. Delta-Based Restrictions: The bot is smart enough to consider the risk of your entire portfolio. Through the check_changes_in_restrictions function, it can check your portfolio's overall "delta" (its directional exposure). If your portfolio becomes too bullish (high positive delta), the bot will automatically be forbidden from placing new BUY orders, even if its own logic wants to. This is a powerful, portfolio-level safeguard that prevents one aggressive bot from unbalancing your overall strategy.

A Walkthrough: The Scraper in Action

Let's imagine you run the bot on Nifty Futures, currently at 23,000, with a 10-point gap.

Launch: The bot starts and places a BUY order at 22,990 and a SELL order at 23,010.

Market Dips: The price falls and hits 22,990. The BUY order is instantly filled.

Instant Reaction: The bot immediately cancels the pending SELL order at 23,010. Its net position is now +75.

Adapt: The bot consults its multiplier_scale. Since its position is positive, it widens the buy_gap for the next trade (e.g., from 10 points to 13 points).

Cool-Off: It waits for the 5-second cool-off period.

New Bracket: The market is now at 22,990. The bot places a new bracket: a SELL order at 23,000 (10 points above) and a new, more cautious BUY order at 22,977 (13 points below).

And the cycle continues, 24/7, for as long as the script is running.

Conclusion

The ticker_single_scraper_new.py script is a brilliant example of how a few hundred lines of code can create a sophisticated, adaptive, and automated trading strategy. It's more than just a simple buy/sell program; it's a dynamic system that brackets the market, manages its own orders, and intelligently adapts its behavior based on the market's flow.

While it's a powerful tool, remember that all trading, especially algorithmic trading, carries risks. Understanding every line of code and testing thoroughly in a simulated environment is the first step before ever letting a bot like this trade with real capital. Happy coding, and trade safe

💬 Your Turn — What Do You Think?

I'm curious to hear your thoughts:

• Have you ever tried trading range-bound setups like this?

• What would you do differently to handle one-sided trends?

• Do you think combining strategies is the way forward in algo trading?

This strategy was born from pure observation, and over time, refined with logic and layering. But I know many of you reading this have your own approaches, experiences, and maybe even critiques — and I’d love to hear them.

👉 Drop your thoughts in the comments below, or connect with me directly on X (Twitter) — my DMs are open!

Connect with me on X

Let’s exchange ideas. That’s how we all grow 🚀

1. Not a single red day — steady gains📈

This was the 1st month ever in my entire trading carrier where there was no negative day.

Here is the link to verified P&L.

One of the reasons probably was as the market has fallen consistently in the month of Jul. From a peak of 25600 on 1st and 2nd Jul it touched the low of 24600 on 29th Jul. The anticipation of fall after 23rd (Tweet here) worked out really well except in 23rd itself.

Connect with me on X

This is how the weekly expiries Premium earned looked like.

2. VIX stayed sleepy 😴

Vix fell steadily from 1st Jul (13) to a low of 10 on 24th Jul, after which it spiked to 12 due to fall after 24th. This pointed out people were expecting breaking of 25000 would be difficult which did happen in the last week of Jul.

3. 🔥 30-day win streak hit — eyes now on 50 👀

I have completed 30 days of consecutive streak which is still active. I am praying to reach to 50 this time. Lets see what is there in the store for me.

4. 🧠 Survivor Algo officially open-sourced

With the help of Sambath (his X Profile) we have been able to ope source the Survivor Algo (1st in the list).

5. 📩 What would you like to read more about?

I’m always looking to share things that are useful, actionable, or thought-provoking. If there’s something specific you’d like me to write more about just leave a comment. I’d love to hear from you and add more posts on this substack with your input.

Do share what you found interesting in July and what worked for you and what did not. Looking forward to hearing from you.

🧠 Why I Don’t Use Strict Exit Criteria in My Trades

When I first started writing about how I trade, one question came up a lot —
“What’s your exit criteria?”
Truth is… I don’t have one in the traditional sense.

🧩 How Most Traders Think

Over time, while interacting with readers and fellow traders, I noticed a common pattern:
Most traders think in strategies — each with clear entry and exit rules.

They run multiple strategies at once, each adjusted and optimized on its own.
Makes sense. It’s clean, it’s structured, it’s easy to track.

🧠 How I Think About It

I do things a bit differently.
Rather than seeing trades as multiple separate strategies, I look at all my open positions as one single evolving strategy.

So instead of optimizing each strategy on its own, I adjust my entire position book as a whole, trying to get the best out of the combined state of my trades.

🎭 The Pros and Cons

Doing this gives me the freedom to hold positions longer and benefit from theta decay.
But — and it’s a big one — it also removes the clarity and structure of predefined exits.
It makes the whole thing… messier.

Yet, it fits my personality. I like the fluidity. I like adapting dynamically.
And that’s why none of the algos I’ve built have strict exit criteria either.
They operate on this same philosophy.

🤔 Will It Work Long-Term?

That’s still an open question.
It works for me right now.
But whether this style survives over the long run — we’ll see.

⚙️ Adjustments of Option Positions!

I have certain thoughts on adjusting positions when I see all the open positions as ongoing strategy. You can read about it in detail here -

Connect with me on X

💬 What Do You Think?

• Do you believe in having strict exit rules?

• Or do you prefer a more dynamic approach like this?

• Would you ever consider merging your trades into a single “position book” view?

Hit reply or leave a comment — I’d love to hear how you approach exits in your trades.

With the generous help of Sambath (his X Profile), who took the lead in cleaning, structuring, and making the code more accessible. He also added Fyers as a broker along with Zerodha. I’m thrilled to finally open-source the first of many algos that power my trading.

🔗 GitHub Repository:
👉 Raahi-Bhushan/trading-algo

Disclaimer:
This algorithm is provided for educational and informational purposes only. Trading in financial markets involves substantial risk, and you may lose all or more than your initial investment. By using this algorithm, you acknowledge that all trading decisions are made at your own risk and discretion. The creators of this algorithm assume no liability or responsibility for any financial losses or damages incurred through its use. Always do your own research and consult with a qualified financial advisor before trading.

🧠 What's in this Algo?

You can read a detailed post on the algo

This particular strategy is designed around directional breakout confirmation. It uses:

• VWAP, ATR, and MAs for entry signals

• Smart filters to reduce noise

• Clean order management with execution logic for Zerodha and Fyers (via kiteconnect)

• Configurable risk parameters

We’ve tried to keep it plug-and-play for anyone who wants to experiment or build on top.

🔗 GitHub Repository:
👉 Raahi-Bhushan/trading-algo

Connect with me on X

This is just the beginning. Many more algos will follow — cleaned, documented, and designed to help other coders, traders, and curious minds.

Again huge thanks again to Sambath (X Profile) for making this happen. He is super strong in coding and building things.

📢 If you want to get updates as more algos go live or read about the thought process behind them, consider subscribing!

Incase you find any issues running or understanding the code, do comment here or connect with me or Sambath on X.

[Update] - Have add the exit and take profit section at the end of the post.

I learned this brutal lesson the hard way during the relentless bull market that stormed through 2022 and into early 2024. In just two years, the NIFTY index rocketed up by nearly 70%.

My conviction was firm. After the massive recovery from the COVID crash to the peak in October 2021, I was sure another explosive move was impossible. Inflation was soaring, and interest rates were at multi-year highs—historically, these are headwinds for the market, not rocket fuel.

But the market doesn't care about our convictions. It does what it wants. And in this case, it wanted to go up, and up, and up.

December 2023 was my breaking point. The relentless climb of the NIFTY shattered my positions and dealt me a significant financial loss. At the time, I was still new to full-time trading, and the blow was humbling. Lying in the wreckage of my Option positions, I faced a critical choice: abandon my strategy, or find a way to make it smarter, stronger, and more resilient.

That's when the idea for the Survivor Algo was born. I realized I needed a mechanism—a saviour—that could protect me not when the market behaved as expected, but when it entered a state of wild, sustained momentum.

The logic behind the Survivor Algo is deceptively simple. It doesn't fight the trend; it adapts to it in a controlled, systematic way. Here’s the core concept:

Imagine the market breaks through a critical resistance level. Instead of betting on it to reverse, the Survivor Algo activates. It then follows a simple rule:

For every $n$ points the index moves further into the trend, the algorithm automatically sells a new option (a Put in an uptrend, or a Call in a downtrend) at a strike price $y$ points away from the current market price.

In this system, $n$ and $y$ are the key variables you control.

• $n$ = The trigger. How many points of movement before the algo takes action?

• $y$ = The safety buffer. How far away from the current price should the new option strike be?

Think of it like a boxer strategically giving ground. Instead of standing still and taking heavy blows (a huge loss), the boxer takes small, calculated steps back, all while continuing to land jabs (selling new options) to stay in the fight. It’s a dynamic defense system designed to endure the storm and survive to trade another day.

It's one thing to talk theory, but another to see it in practice. Here is the actual algo command I ran last Friday, putting the Survivor to work in the live market:

python3.8 place_order_at_nifty.py NIFTY25724 300:300 NFO 15:15 90:90 300:300 25140:24928 <REQUEST_TOKEN>

1. Here NIFTY25724 is the next week NF Expiry (24th Jul Expiry Prefix)
2. 300:300 variable tells that PE and CE will be sold which are 300 points away from ATM. So if NIFTY is at 25100 it will sell CE of 25400. This reduces as we reach closer to the expiry. 
3. 15:15 variable tells that with every 15 points move it will execute 1 order. 
4. 90:90 is another variable which helps in retracing the thresholds, we will discuss about this later. 
5. 300:300 this variable tells how much to sell in every execution. Here it is NIFTY and will sell 300 (4 lots) in a single transaction. 
6. 25140:24928 This is the support and resistances defined, above and below which the trade will execute. 

- Case #1
1. If market moves 15 point above 25140 a PE will be sold 300 points away from the ATM. Which is if NIFTY reaches 25155, 24850PE will be triggered of 300 qty. 
2. If the market further moves by 15 points which is if it reaches 25170 another 24850PE will be sold 300 qty. 
3. On another 15 point move 25185, 24900 PE will be sold instead of 24850PE as 24900PE is closer to 25185 points taking a 300 points diff. 

- Case #2
1. Similarly if market moves 15 points below 24928 (24913) a CE will be sold 300 points away (25200CE) from ATM which in this case.
2. If it moves another 15 points lower (24898) another 25200CE of 300 qty will be sold. 

I hope the sample execution is clear. I have added AI explanation of the code through code assist at the bottom of the post. It has more nuances related to the algo.

This algo ensures that if there is an ongoing trend I am not stuck doing nothing instead follow the trend to save my a** from huge losses. This algo has proven to be really helpful incase of any large movements as it executes fast.

[Update] - After some people asked me about the exit and take profit, here are my insights on it.

1. As I run this algo only on Mon, Tue and Wed and only to adjust current positions there is a scope of 100-150 points of back trace without causing loss. As I constantly adjust my positions so I do not have a stop loss or a take profit thing. Bure here are my thoughts on it.

2. Its a good idea to exit from these stand alone position if -

   1. The positions have gone into ITM and are in loss.

   2. If the positions are in loss of ~30-50% (This varies depending on when the trade was taken). If it is on the same day 50% is fine, if not this should be reduced to 30%.

3. For take profit if the price has gone below Rs. 20/- and the profit is more than 50%. It’s a good idea to close positions and start taking profits.

Connect with me on X

I also have a of variations of the same code which ensure the margin requirement is lower by doing a spread instead of a naked sell. When the movement is huge the margin requirements sometimes passes the margin available.

Difference between place_order_at_nifty_with_buy_auto.py and place_order_at_nifty.py scripts - (AI generated Text)

While both scripts are built on the same foundation of selling Nifty options in a trending market, they represent two different levels of strategic complexity. The original script is a pure seller, while the _with_buy_auto version is a more sophisticated trader that actively manages its positions.

1. Core Strategy: Selling vs. Selling + Managing

place_order_at_nifty.py (The Pure Seller): This script's logic is one-way. It only places SELL orders for Out-of-the-Money (OTM) options when the Nifty index shows a strong trend. It never buys options. Its entire goal is to collect premium, assuming the trend will continue and the sold options will lose value or expire worthless. It manages risk simply by resetting its trigger levels if the market reverses.

place_order_at_nifty_with_buy_auto.py (The Position Manager): This is a more advanced version that includes active position management through automated buying. While its primary action is still selling options, it adds a crucial layer of logic to automatically BUY options for two main reasons:

Closing Positions: To buy back a previously sold option, either to lock in a profit (if the premium has decayed significantly) or to cut a loss (if the market has moved against the position).

Hedging: To buy a cheaper option to offset the risk of a newly sold option, creating a spread. And to save on the margin requirement.

2. The Decisive Functional Upgrade: find_nifty_symbol_auto_buy

The critical difference lies in the use of the find_nifty_symbol_auto_buy function from common_lib.py.

The original script only uses find_nifty_symbol_from_gap to locate an appropriate option to sell.

The _with_buy_auto script uses this same function to sell, but it also leverages find_nifty_symbol_auto_buy to make intelligent decisions about buying.

This new function doesn't just find an option to buy; it intelligently compares the price of a new potential buy with the price of an existing sold position. It essentially asks: "Is it better to buy a new option to hedge, or is it more cost-effective to simply buy back (close) the old sold position?"

3. A Practical Example

Let's see how they behave in the same scenario.

Scenario: The bot has already sold a Nifty PE option at a strike of 22000. The market continues to rally.

place_order_at_nifty.py's

Action:

1. Nifty rallies another 20 points, triggering a new trade.

2. It uses find_nifty_symbol_from_gap to find a new PE option to sell, perhaps at a 22100 strike.

3. It places the new SELL order. It now holds two open short PE positions (at 22000 and 22100). It does not touch the old position.

place_order_at_nifty_with_buy_auto.py's

Action:

1. Nifty rallies another 20 points, triggering a new trade.

2. Before selling the new 22100 PE, it uses find_nifty_symbol_auto_buy to analyze the situation.

3. It checks the premium of the old 22000 PE it sold. Let's say the premium has decayed and is now very low (e.g., under ₹20).

4. The logic inside find_nifty_symbol_auto_buy determines that it's a good time to lock in the profit on the old position.

5. It first places a BUY order to close the 22000 PE position, and then places the new SELL order for the 22100 PE.

The bot ends up with only one open short position, having actively managed and closed the previous one.

AI Explanation Seeing the Code

This Python script is an automated trading bot designed to work with the Zerodha Kite Connect API. Its core strategy is to sell Nifty options (both Puts and Calls) based on significant price movements in the Nifty 50 index. It's built for a trending market, aiming to profit from the decay of Out-of-the-Money (OTM) option premiums as the market moves decisively in one direction.

Let's break down its execution step-by-step.

1. Initialization and Configuration

When you run the script from your terminal, it first needs a set of instructions. These are provided as command-line arguments.

python3 place_order_at_nifty.py <SYMBOL_INITIALS> <PE_SYMBOL_GAP>:<CE_SYMBOL_GAP> <EXCHANGE> <PE_GAP>:<CE_GAP> <PE_RESET_GAP>:<CE_RESET_GAP> <PE_QTY>:<CE_QTY> <PE_START>:<CE_START> <REQUEST_TOKEN>

Here’s what each argument means:

After parsing these arguments, the script:

Connects to the API: It uses the initilise_basic function from common_lib.py to log into the Kite API and start a WebSocket connection for receiving live data.

Sets Initial Trigger Levels: It establishes the starting "lines in the sand" for Nifty. These are stored in nifty_pe_last_value and nifty_ce_last_value. These are the price levels the bot will monitor.

Fetches Instruments: It calls get_all_fut_opt_instruments() to get a complete list of all available Nifty options, which it will need later to find the right contract to sell.

Subscribes to Nifty Ticks: The script subscribes to the live price feed for the Nifty 50 index. The on_ticks_update function is designated as the handler that will be executed every time a new Nifty price is received.

2. The Core Trading Logic: on_ticks_update

This function is the heart of the bot. It runs every time the Nifty 50 index price changes.

The Strategy:

The bot maintains two key price levels:

nifty_pe_last_value: The upper price boundary. If Nifty crosses this, it's a signal to sell a PE option.

nifty_ce_last_value: The lower price boundary. If Nifty drops below this, it's a signal to sell a CE option.

Scenario 1: Nifty is Trending Up (Selling a Put Option)

1. The function checks if the nifty_current_val has risen above nifty_pe_last_value.

2. If the upward move (nifty_current_val - nifty_pe_last_value) is greater than the configured pe_gap (e.g., 20 points), a trigger occurs.

3. Find the Right Option: The bot uses find_nifty_symbol_from_gap to locate a PE option contract with a strike price that is approximately pe_symbol_gap (e.g., 200) points below the current Nifty price.

4. Premium Check: It ensures the premium of this option is above a minimum threshold (min_price_to_sell = 15). If the premium is too low, it searches for a slightly closer strike price until it finds one with a decent premium. This is a practical step to avoid selling worthless options.

5. Place Order: It places a market SELL order for the selected PE option.

6. Update Trigger Level: The nifty_pe_last_value is updated to the new, higher Nifty price level, setting a new line in the sand for the next potential trade.

Scenario 2: Nifty is Trending Down (Selling a Call Option)

This is the mirror image of the first scenario.

1. The function checks if nifty_current_val has dropped below nifty_ce_last_value.

2. If the downward move (nifty_ce_last_value - nifty_current_val) is greater than the ce_gap (e.g., 30 points), a trigger occurs.

3. Find and Place Order: It finds a suitable CE option (e.g., 250 points above Nifty), checks its premium, and places a market SELL order.

4. Update Trigger Level: The nifty_ce_last_value is updated to the new, lower Nifty price.

5. Adapting to Market Reversals (The Reset Logic)

Markets don't move in one direction forever. What if Nifty rises, the bot sells a PE, and then the market starts to fall? The nifty_pe_last_value is now far above the current price. The reset logic handles this:

If a PE has been sold (pe_reset_gap_flag is set) and the Nifty price subsequently falls by more than the pe_reset_gap (e.g., 30 points), the bot resets nifty_pe_last_value to a new, lower level closer to the current market price.

This allows the bot to re-engage with the market and be ready to sell another PE if the uptrend resumes, rather than waiting for the price to climb all the way back to the previous high. The same logic applies symmetrically for CE options.

3. Execution Loop

The script ends with time.sleep(22000), which is over 6 hours. This indicates that the main program thread does very little. All the action happens in the background thread managed by the Kite Ticker WebSocket, which continuously listens for Nifty price updates and triggers the on_ticks_update function.

In summary, this script automates a directional options selling strategy. It intelligently selects which option to sell based on market direction and pre-configured parameters, and it includes a crucial reset mechanism to adapt to market reversals.

From Surviving to Thriving

The true power of the Survivor Algo shines in the early days of the trading week. It's my frontline defense on Mondays, Tuesdays, and Wednesdays, systematically adjusting my weekly positions whenever NIFTY makes a sudden, drastic move. It’s designed to prevent a small, unexpected move from turning into a tidal wave that sinks my entire week's strategy.

And the results speak for themselves. Since integrating this tool into my trading arsenal, the catastrophic losses that once haunted me are a thing of the past. The algorithm has truly lived up to its name, ensuring my capital survives to fight another day.

Join the Conversation

But the journey of a trader is one of constant learning and evolution. I'm always eager to hear from fellow traders who are navigating these challenging markets.

What are your thoughts on this approach? Do you use a similar mechanism to protect against powerful trends?

Drop your insights and questions in the comments below. For a more direct chat, feel free to send me a DM on my X profile (@raahi_bhushan). Let's learn and grow together.

But here's the cool part: volume isn't just one thing. It's like a multi-layered story. So, today, I want to share the three different types of volume I've been tracking, and how they've helped me in trading NIFTY.

1. The Classic Volume (Traded Volume)

This is the volume we all know and love. It's like the crowd noise at a stadium. When it's loud (high volume), you know the action is intense, and the price is probably moving strongly in a certain direction. Simple, right?

Beyond just the traded volume, there's also delivery volume, which is like the fans who stayed until the very end. It's the volume of shares that traders took home overnight. By comparing delivery volume to traded volume, you can get a sense of how committed the traders are.

2. The Detective: Fixed Range Volume Profile

Imagine a map that shows where the most battles were fought. That's kind of what the Fixed Range Volume Profile does. It shows you, over a longer period (like 15 days), at which price points the most trading happened. These 'battlegrounds' become key support and resistance levels. It's like finding hidden clues on the chart!

Looking at NIFTY, I've noticed certain price ranges where the volume is super high. That tells me those areas are going to be tough to break through, either up or down.

If you like the post, do share it with your friends. It will help us in reaching out more people and making the community stronger.

Share

3. The Spy: Relative Volume (RelVol)

Here's where it gets really interesting. Volume isn't constant throughout the day. It tends to spike at the start and end of trading. So, just looking at volume alone can be misleading. That's why I started using the RelVol indicator on Trading View.

RelVol compares today's volume to the volume at the same time over the last few days. It's like having a spy who tells you if the action is unusually hot or cold. This helps me understand:

1. Overall day's volume: Is it higher or lower than usual for this time?

2. Recent volume bursts: Are there sudden spikes in volume compared to the past few days?

This is how the ratio chart look like for 10th Jun day. See how the ratio chart differs from the overall volume chart.

The start of the day on 10th was with higher than usual volume, also because of it being an expiry day. This indicator does provide extra in time information on the market and what’s going on.

Connect with me on X

Disclaimer: I'm still on my technical analysis journey, so this is what I've learned so far. It might seem basic to some, but it's been eye-opening for me. I'm eager to learn more!

Your Turn!

What are your favorite ways to track volume? Any tips or insights you can share? I'd absolutely love to hear from you in the comments or feel free to DM me on X profile. Let's learn together!"

I usually play it safe, aiming for steady, consistent returns. But even I can't resist the thrill of short-term expiries. That's where gamma, the unsung hero (or villain!) of options, comes into play. It's the force that amplifies price movements, turning a small market twitch into a 10x or even 20x jump in option prices.

The Mystery of the Sudden Spike

Imagine this: the market's chugging along, and then BAM! A sudden, massive swing of 150-200 points. For option sellers, this can be devastating. But what if these aren't random events? What if they're calculated moves by "big players" to rake in massive profits?

I believe these spikes are engineered. Think about it: big players buy or sell huge amounts in the cash market, creating a sudden, temporary market shift, especially on expiry day. Their secret weapon? Loading up on "near the money" (ATM) and "slightly out of the money" (OTM) options just before the blast – sometimes as little as 30 minutes before!

Catching the Wave: The Open Interest Clue

My hunch led me to examine "Open Interest" (OI) – the total number of outstanding options contracts. And guess what? Before these sudden market explosions, I noticed a massive surge in OI for ATM and slightly OTM options, sometimes jumping 30% to a whopping 100%!

This was my "aha!" moment. What if we could use this spike in OI as an early warning system?

Enter Google Jules: My AI Co-Pilot

To turn this idea into a reality, I challenged Google Jules, my coding AI, to build a tool that could track these crucial OI changes. I wanted a live table, updating every minute, showing the percentage change in OI for ATM and surrounding strikes (2 strikes in-the-money and 2 strikes out-of-the-money, for both calls and puts).

My instructions to Jules were precise:

Hi Jules, today I am going to test you if you are of any use or not. I am looking at building a code in this repository which does a specific thing.

I want to track the change in OI for ATM and 2 slightly ITM and 2 slightly OTM options both call and put.

I want to create a live table in python which updates every minute. Here are the specific points I want in the code -

2 tables to be created one for Put options and 1 for Call
    1. Each table will have 5 rows and 3 columns
    2. Each row is a strike price which is ATM -2, ATM -1, ATM, ATM +1, ATM +2 strikes
    3. The columns will be 10 mins, 15 mins, 30 mins
    4. Each cell will show the difference in the OI for that particular time and strike price.
    5. You can fetch the OI using historical_data api in kite connect.

You can get the details of the API from this documentation - https://kite.trade/docs/pykiteconnect/v4/

Jules delivered a fantastic, working code! But I pushed further, adding more layers to refine the alert system:

I want to do 2 more things -

1. Instead of the change in OI I want you to show the change in OI as a % of initial OI.

2. I want to color code the cells. If the change in OI is > 10% in 10 mins, 15% in 15 mins and 25% in 30 mins then the color of the cell is to be updated to Red.

3. Add alert sound if more than 50% of the cells are color coded. 

Here is the final version of the code I have been testing -

Download Gamma Blast Detector Code

The code is still being tested for exact numbers and alert system to configure it properly. Generally if the market movement is normal but OI change is abnormal (huge increase in OI in short span) it does indicate something big is coming. Will keep on posting testing results on this X thread.

The "Gamma Blast" Detector is Born!

The result? A powerful tool that generates two dynamic tables. When you see a sudden surge in OI velocity across multiple strikes – especially if those cells start flashing red – it's a strong signal. It suggests big players are accumulating options in massive quantities, hinting that a market push could be just 30-45 minutes away.

This isn't about predicting the exact direction every time, but it's about getting ahead of the curve. It's about empowering option sellers (and buyers!) with an early warning system to navigate the treacherous, yet exciting, world of 0DTE "Gamma Blasts."

Incase you have any queries or comments, please do share it here or on my X profile. And don’t forget to share it with your friends.

Stay alert, stay informed, and happy trading!

Until recently, my focus was primarily on the overall Theta and Delta of my portfolio, both for the current and next expiry cycles. This gave me a decent snapshot of my overall stance, but it felt like looking at a map without a scale. I was missing crucial information about position sizing.

While I used these aggregate values to make adjustments, the burning question always lingered: How aggressive can I be? When the market nudged my positions, should I sell a modest 0.2 delta, a more assertive 0.3 or 0.5 delta, or even venture in-the-money to sell a higher delta? It felt like guesswork at times!

Disclaimer - This content is only for recommendation purposes. I am myself stuck with some short positions.

Greeks Data

Let's take a peek at the data I used to track before – it gave me a basic overview of my current overall position:

The CE and PE premium data was primarily for keeping an eye on margin optimization – something I'll touch upon later.

Now, after a bit of tinkering with my code, I've added some more granular data that gives me a much clearer picture of my Current Overall Positions:

Ah, this is where things get interesting! The Average PE Delta and Average CE Delta are game-changers for me. Now I can instantly see my current exposure on the call side and, crucially, what delta I should typically sell on the put side if I want to nudge my overall delta closer to neutral. Similarly, the average theta values give me a daily breakdown of the premium I'm expected to gain from time decay on my call and put options separately. It's like having a mini-forecast for my premium collection!

Let's look at my position data for the 15th May expiry:

(Notice how the closer expiry has a lower overall delta and, thankfully, a lower average delta too! This means that, barring any major market surprises, adjusting these near-expiry positions should be relatively easier.)

(This data also subtly reveals my current market bias: a slightly bearish short-term view, which I have the flexibility to adjust if the situation demands.)

And here's the data encompassing all my positions till the May expiry:

So, you can see that if I need to adjust my broader May positions, I'd likely be looking at selling put options with a delta in the 0.3 to 0.4 range.

This specific information wasn't readily available in the tools I was using, so I did what any curious trader would do – I whipped up a quick Python script to fetch and calculate it for my own positions!

Understanding Lots for Margin Optimizations: A Lifesaver Near Expiry

We've all been there – those nail-biting days near expiry when market volatility spikes and margin requirements seem to balloon out of control! To stay in the driver's seat, understanding the current margin rules and the rebates available is absolutely crucial. Here are the key rules I keep in mind and actively use:

1. Spreads are your friends for margin relief: If the gap between the Near and Far leg of a Nifty spread is 400 or less, the margin is roughly 25% of what you'd need for selling a naked option. This holds true for calendar spreads as well, except on the day of expiry.

2. Selling both PE and CE offers margin benefits: When you sell both a put and a call option, the total margin required is typically around 1.2 times the margin for a single naked short position (instead of the usual 2 times). This is a significant saving!

3. Expiry day margin dynamics: On the day of expiry, the margin for sold positions usually settles around 1.25 times the regular requirement. However, if you have a spread, it can ironically jump to almost 2 times due to the margin benefit pointed out in 1st point. This is something to be very aware of!

As the theta premium is low near the expiry sometimes to adjust requires a lot of margin thus understanding from where the margin can be freed becomes super critical.

These 3 rough rules are used to understand what scale can be sold to adjust.

Here are a couple of tactics I often employ to free up margin when the situation calls for it:

1. Rolling over positions: Closing out distant expiry positions and establishing new positions in closer expiries can free up a considerable chunk of margin.

2. Converting naked sells to spreads: If the number of my naked sold options on one side has grown significantly, converting them into spreads can provide substantial margin relief.

A Little Note: I understand that these margin optimization techniques might not be universally applicable, especially for those who strictly adhere to a specific trading strategy. However, for someone like me who adjusts positions dynamically based on market movements, these insights can be incredibly valuable in navigating those tricky expiry situations.

Hope this gives you a clearer and more personal glimpse into how I'm using Delta and Theta in my trading! Please do comment on what you think or if you have any questions. Always happy to chat!

Follow on X

In my previous post, "Greeks (Friends and Foes" I talked about my love affair with Theta – the decay that consistently fills my pockets. (Think of it as premium harvesting!). But as any seasoned options trader knows, the market can be a fickle beast, and sudden, sharp moves can quickly turn those sweet premiums into stinging losses.

Over time, I've developed a, three-pronged strategy to mitigate these risks and keep my Theta machine running smoothly. Let's dive in! Firstly, do subscribe to my substack below for updates on new posts.

The Foundation: Strategic Position Creation

Before we get to the adjustments, let's lay the groundwork:

1. Out-of-the-Money (OTM) Focus: I primarily sell OTM options, typically 200+ points away from the at-the-money (ATM) strike. The exact distance is adjusted based on time to expiry, but my sweet spot is around ₹50 premium – where Theta decay is most potent as shown in Max Theta Decay in a day analysis.

2. Early Exit: I close most positions one day before expiry to avoid the dreaded Gamma risk.

3. Weekly Expiries: I focus on weekly Nifty expiries, entering positions by Friday and reserving Monday, Tuesday, and Wednesday for adjustments.

4. Margin Buffer: Crucially, I maintain 3x the deployed margin as free capital. This allows for flexible adjustments without margin calls. (e.g., ₹1 crore deployed, ₹3 crore available).

The Defense: Adjustments on Monday, Tuesday, and Wednesday

When the market throws a curveball (say, a significant upward move in Nifty), here's how I react:

1. Algo 1 - Saviour Code (Delta Hedge) (Detailed Explanation in the link) - When NIFTY moves higher by x points a PE position is sold which is y points away from the current NIFTY price. Here both x and y are configurable and depends on current delta and days to expiry.

   1. Eg

      1. Monday: For every 20-point Nifty rise, sell a PE 200 points away.

      2. Tuesday: For every 15-point Nifty rise, sell a PE 120 points away.

      3. Wednesday: For every 10-point Nifty rise, sell a PE 70 points away.

   2. So on Wed whenever this algo is running and some of my CE sell positions are in ITM, for every 10 points move in NIFTY the algo sells a PE position which is 70 points away from current price.

   3. This algorithm sells Put options (PE) to counteract the increasing Delta from my losing Call options (CE).

   4. To free up Margin I close far OTM profitable PE positions.

2. Algo 2: The "Wave Extractor Code" -

   1. This algo capitalizes on intraday market swings.

   2. It sells CE on Nifty upticks and buys them back on pullbacks, and vice-versa for PEs.

   3. A crucial delta check ensures that trades only reduce the overall position delta, preventing excessive risk.

3. Manual adjustments of ITM positions - This is done manually on ITM positions.

   1. Converting Delta to Theta #1 - ITM CE positions are converted into ATM straddles (ATM CE + ATM PE). This transforms Delta risk into Theta profit as expiry approaches. (Implemented progressively: 1/3 on Monday, 1/2 of the remaining on Tuesday).

   2. Converting Delta in to Theta #2 - ITM positions are converted into multiple OTM positions of the same type (e.g., 1 ITM CE becomes 2-3 OTM CEs). This reduces Delta and increases Theta.

Margin Handling

• The 3x margin buffer is essential for these adjustments.

  • Say I have a margin used of 10 Lakh on Friday for next Thu expiry, I will have 30L as a buffer margin for adjustments on Mon, Tue & Wed.

  • On Monday if market moves in opposite direction to me position.- I can use another 10L to adjust. Now the open position will be of 20L and 20L will be buffer margin.

  • On Tuesday if the market still moves in the opposite direction- I will use remaining 20L as margin to adjust positions. This will make total open position margin of 40L and 0 as remaining margin.

  • If required on Wednesday, I buy far OTM options (400+ points away) to free up additional margin. Also I would close profitable positions and use that margin to adjust the positions. And I will close my positions on Wed to save myself from gamma impact.

• This have been proved to be a good strategy over last 12 months and I have been able to successfully adjust my positions without taking huge losses.

My Trading Style

I have found that my trading style is a bit different than that of other traders due to one very important difference. I think trading through a unified position book instead of multiple rigid strategies. You can read the complete details here -

I'm always eager to learn and improve. Share your thoughts and strategies with me via DM on my X profile.

Connect with me on X

Note - The algos which I have mentioned here are basic idea on how they run, after running them and learning from them, there have been many boundary cases implemented on top of the base idea which make these algos way more robust.

I plan to make the algos open source but as the quality of the code is bad, I am hesitant on making it open. The code written is in Python and if someone help me to make it more modular and readable, please DM to me on my X profile.

This realization pushed me to improve my trading approach.

To address my gap in technical analysis, I decided to create a pattern-matching tool. The goal is simple: when I provide 3-minute closing values, the tool identifies similar patterns from the past 5 years. I usually run this analysis around 12:30 PM, as there are sufficient data points by then for meaningful comparisons.

If you're interested in staying updated on my work, follow me on X for regular insights and updates:

Follow on X

Note - The pattern matching analysis is still very preliminary, I will share the whole thing along with code once it is complete and I have more insights from it.

Data Collection and Setup

To implement this pattern-matching tool, I needed accurate NIFTY data. Thankfully, I was able to extract this data using KITE Connect’s historical APIs. Writing the code and fetching the data took less than two hours, thanks to the excellent APIs developed by the Zerodha team.

Sharing the Data

I believe this data can benefit many traders, so I’m sharing it here in two formats:

1. 3-Minute Candlestick Data (OHLC)

   • File size: 10 MB

   • Format: Each row represents a 3-minute candlestick with OHLC data.

     Download Format 1

2. Daily 3-Minute Closing Price Data

   • File size: 1.6 MB

   • Format: Each row includes daily data with 3-minute closing prices in CSV format.

     Download Format 2

I hope this data is helpful to people to improve their trading.

Below is a detailed mathematical approach on finding the answer to this question.

Note - To keep things straightforward, this analysis focuses solely on Theta, disregarding other Greeks.

I have attached an excel at the bottom of the article. This will allow a DIY implementation of this.

Key Objective: Maximizing Absolute Returns and Minimizing Risk

Absolute Return Calculation

The goal is to achieve maximum time decay while balancing returns against risks. This is done by analyzing:

1. Daily Decay (driven by Theta).

2. Return on Margin (profit as a percentage of margin money used).

Here’s the method I use for rough daily return benchmarks:

• Next week expiry: ~0.4% return.

• Two weeks ahead: ~0.3% return.

• Three weeks ahead or more: ~0.25% return.

Let’s assume some close rough numbers :

• Margin required for 25 lots of NIFTY options: ₹50,000

• Per-share margin: ₹2,000

To achieve a 0.3% return, we need a daily gain of ₹6 per share. Thus, the option price must decay by ₹6 within the day to meet this target.

Minimising Risk

To reduce risk, the chosen strike price should have the maximum Theta decay as a percentage of the option price. This ensures better returns with less exposure.

The Harmonic Mean Approach

Once we calculate:

1. Absolute Returns (based on decay and margin).

2. Risk Reduction (based on Theta decay as a percentage of price).

I use the Harmonic Mean of these two metrics to determine the optimal strike price. The strike price with the highest harmonic mean is the best one to sell.

One important question here is why Harmonic Mean and not any other mean. I chose harmonic mean because of this property of it -

Emphasizes Small Values: The harmonic mean is dominated by the smallest values in a dataset. If any value is very small, the harmonic mean decreases significantly.

You can access the working excel file here -

Open Excel

Results of Analysis

Using the Option Chain for 5th December Expiry, exported at 12:58 PM on 19th November, the analysis identifies 24400CE at ₹52.25 as the optimal strike price to sell.

Given today’s significant market movement upward, selling Call options (CE) seems more reasonable.

Note: This analysis is for educational purposes only and is not a trade recommendation.

How to Perform This Analysis Yourself

Here’s how you can replicate the analysis using data from Sensibull:

Export the Option Chain:

1. Goto option chain page on sensibull.

2. Select All Column view from bottom left option.

   1. 

3. Use the settings button on the right bottom to open Download Option.

   1. 

4. Select Large and Download the excel. Sample Downloaded Excel

Process the Data:

1. Copy the rows and columns from the downloaded Excel.

2. Paste them into the Google Sheet provided below.

You can access the working Google Sheet here. It automates the calculations and helps you identify the optimal strike price.

Let’s Collaborate!

If you’ve performed any analysis which talks about answer to the question mentioned on top or spot any mistakes in this, please share your insights. I’m here to learn and grow with you.

• Reach out to me on X (Twitter) here.

• Drop a comment on this article.

Feedback From Readers

1. If hedging is done due to reduced margin cost the return can be higher. The loss due to hedge can be offset by the increased position sizing due to reduction in margin requirement. Though complete analysis will have to be done on what can be the further expected gains.

Disclaimer - This is for educational purposes only. Please consult your adviser before taking any trade based on it.

For those who aren’t experts in Greeks, exiting positions may be the only option when the market doesn’t move as expected. However, with a deep understanding of Greeks, you gain the ability to adjust your positions and ride through turbulent market movements.

Note: I trade options exclusively in NIFTY, both weekly and monthly. You can check my trades and verified P&L for the last 180 days here.

I believe everyone interprets Greeks differently, shaped by life experiences and personal biases. In fact, you can learn a lot about a person by understanding how they view the Greeks.

The Main Greeks: Delta, Theta, Vega, and Gamma

While there are more than four Greeks, I focus primarily on Delta, Theta, Vega, and Gamma in my trading. I won’t go into detail on what each Greek means or how they impact option pricing; these topics are extensively covered in Zerodha Varsity’s option theory course, which I found to be the best course on options. If you have questions, feel free to comment here or DM me on X (formerly Twitter) @raahi_bhushan.

In this post, I’ll mainly share my personal approach to each Greek:

Theta

Growing up in a middle-class family, patience was always valued as a way to earn money. Theta, therefore, has been my favorite Greek—it’s like a close friend. Since I sell options 99% of the time, Theta works in my favor, consistently adding to my returns.

Vega

I’ve recently started understanding Vega, and it’s quickly become a “fast friend.” Knowing how Vega behaves under different conditions has proven useful, especially in tandem with tracking implied volatility (IV) to optimize option pricing. Here are a few insights on IV behavior that I use daily:

• On a typical trading day, IV is high in the morning and drops significantly by 11 AM.

• IV tends to increase around 3 PM, likely due to a general expectation of significant moves at that time. (If anyone has insights on this, please share in the comments!)

• IV usually rises when NIFTY falls and decreases if the market rises at a moderate pace.

• High IV often means it’s not a good time to close (i.e., buy back) positions, as prices are inflated by the elevated IV.

Tracking IVs: With so many strike prices, tracking overall IV can be overwhelming. For a broader view, I monitor ATM (at-the-money) IV in real-time using Sensibull’s Live Option Charts. Here’s a quick snapshot of NIFTY’s IV for November 12.

Delta

Delta and I don’t always get along; in fact, I try to keep my open positions as Delta-neutral as possible. I typically manage my overall positions to be Delta-neutral, similar to complex calendar option positions where Delta is kept close to zero.

If I could befriend Delta, I believe I’d be a better trader. But due to my tendency toward mean reversion, Delta remains elusive, making me feel a bit disappointed. I hope to overcome this bias someday.

I’ll share a detailed post soon on how I manage Delta across calendar positions to reduce trades and increase profits.

Gamma

Gamma feels like the “notorious” Greek I try to avoid, which might stem from my conservative and middle-class background. To keep my distance from Gamma, I close all positions at least one day before expiry, ensuring I’m not exposed to the Gamma effect that could cause significant fluctuations in my P&L.

Also as gamma movements can be very rewarding I researched a bit to see if there is any opportunity. I wrote and open sourced Gamma Blast detector.

My Trading Style

Due to this understanding of Greeks my trading style is a bit different from others. I have detailed about my trading style in the post -

How Do You See the Greeks?

I’d love to hear how other traders view and use Greeks in their strategies. The more perspectives I gain, the better I’ll become as a trader. If you have insights or experiences with Greeks, please share in the comments! I plan to compile a post on diverse viewpoints to highlight how different people interpret and utilize them.

Let’s analyse their current numbers, challenges and then we will get into some predictions.

Zomato’s overall which is called ‘Eternal’ internally, currently has 3 businesses

1. Zomato core food business

2. Hyperpure which is sort of backward integration to partner deeper with Restraunts.

3. Blinkit which they acquired, to use quick delivery expertise and expand the wallet share of food and related items.

Lets start with Zomato’s core business. It runs on 2 revenue streams - 

1. Food delivery (Commission + Delivery). Ads for food delivery it is counted as a part of the commission only.

2. Advertisements for Restaurants (To drive more in table reservations to restaurants, there is an integration of the payments on top of it)

   
   ** There is a new revenue stream of Zomato Gold which is relatively new.

Most of the operations revenue comes from food delivery business. Here is how the unit economics of that business looks like. The 2nd Ads business is anyways a high margin business but has a limited revenue capability. This should only reduce as a percentage of the total operational revenue as the food delivery business scales.

Unit Economics details for Food Delivery Business - 

• Commission (positive)

• Delivery Charges (positive)

• Delivery Cost (negative)

• Discounts given by Zomato (negative)

• Other costs (Support + Transaction Charges + SMS + Calls)

• After all this CM is calculated

• Marketing and other central costs comes after that to get Adjusted EBIDTA

• ESOPs allocation cost comes to get to EBIDTA (we can neglect this for now, below that anyways is not important)

Working Excel with analysis comments and notes -

Excel Sheet

Here are some of the FAQs which would be helpful to get a deeper understanding of the business. These questions were written before writing the article so some of them would be semi answered and some of them would still not be answered. These questions were answered after OND quarter results

1. How has there unit economics been over last 6 quarters?

   • Has the CM and Adjusted Ebidta improved?

Ans - CM and adjusted Ebidta both have improved. There are 4 levers with Zomato to increase their Ebidta. 

1. Increasing number of users

2. Increasing number of orders per user

3. Increasing AOV

4. Increase margin per order from Restaurants.

1,2 has not happened in the last quarter. This can be because of current market situations where the market seems to have stopped growing. The movement in 2nd is yet to be seen and Zomato Gold might help in it. Which means that only 3rd and 4th have contributed an increase of contribution in Q3 of FY 2023.

Going ahead it will be tricky for Zomato to further increase their margins or increase AOV fast enough. So to work on 2nd point is the only option left. Which zomato seems to be focussing on with re-launching their loyalty program. 

Its super difficult to find the unit economics for every quarter, but there has been a rough estimation for the same. See from row 32 in the sheet Zomato Result Tracking

2. How has the delivery cost reduced as a percentage in last 6 quarters?

Ans - Delivery cost seems to have remain same for last 2 quarters and is estimated to be at around 55 Rs. Zomato is trying to further reduce this number, and is facing some heat from delivery partners.

3. What have been the delivery charges for last 6 quarters are they on an uptrend.

Ans - Delivery charges has been on an uptrend, and currently stands at Rs. 30. In the last quarter there might be some campaign where the cost was reduced. 

4. How have discounts been panning out?

Ans - Delivery charges has been on an uptrend, and currently stands at Rs. 30. In the last quarter there might be some campaign where the cost was reduced. 

4. What is the percentage of the delivery cost as the AOV. This can be an important metric which can define the AOV to target. 

Ans - With increase in AOV the percentage seems to have been going down. 

6. What have been the CAC and cost of acquiring a user 

Ans - CAC per order was Rs. 23.26 which is higher than the previous quarter by more than 2 Rs. This was because of higher spends and lower number of orders. 

7. How has been the growth of orders over last 6 quarters - 

   • New users contribution

   • Improve in recurring customers (Can there be some second order analysis done here)

Ans - Both seems to be stagnant which is very concerning. 

8. What is the scope of other 2 businesses - 

   • Hyperpure, backward integration. Restaurants order size and number of restaurants its serving.

   • Blinkit and what does economics look like for it. What is the retailer + wholesaler margin in the fmcg products? Can delivery costs be covered with that?

9. What are the future prospects of the business and the teams capabilities to be able to execute them. 

Findings - 

• Users who ordered at-least 1 order in CY22 was 58M, in a good scenario this should be close to 60M in CY23 (~3.44% increment only). (I15 of Zomato Result Tracking). This means that user growth will be pretty bad for the whole year. And the growth will have to come from one of these 3 

  1. Number of orders placed by each user

  2. Increase in AOV 

     • AOV already has reached 455 Rs. in last quarter (see H19 of Food Delivery sheet). Moving it higher will be difficult keeping in mind it is already on the higher side. 

  3. Increase in CM 

     • Higher margins from restaurants.

     • Lower cost of delivery

• Findings on changes in AOV and Number of Orders (QoQ). (2nd case looks more probable, as the money paid to the delivery boys have not reduced to the same extent as reduction in money charged). So free delivery is somehow used as a promotion tactics.

  1. If it is assumed that Customer Delivery Charges per order remains same then in Q3 of FY23 there has been a drop of ~7% in the orders in Q3 FY '23. Most of which would have been compensated with proportionate increase in the AOV (Most likely case)

  2. If the delivery cost paid by Zomato has remained same then there has been a drop of 2.5% in the number of orders which would have been almost equally compensated by the increase in AOV. This is with an assumption that restaurants have given the same commission. Also there has been better ad monetisation which has helped in increasing the AOV. 

• The Q4FY’23 looks even more bleak with further drop or same average monthly transacting customers. 

• The chances of stock to go above 56 Rs are less after the next result announcement based on the core food business. 

Notes - 

• Sales promotion per order was 22.44% in 9 months FY 21. This includes - 

  • Discounts by Zomato

  • Marketing & Branding Cost 

  • Customer Appeasement cost

  • Refunds made to restaurant partners

• Contribution Margins - 

  • 9 months FY-2021 - 22.9

    • Earned Commission + Delivery Charges - (62.8 + 26.8) - This includes income from ads for food delivery.

    • Delivery Cost - 44.6

    • Discount - 7.3

    • Other costs (Support + Transaction Charges) - 14.8

    • Net CM - 22.9

    • This does not include the cost for marketing and branding. (Marketing should be the part of CM)

    • CM as a percentage of GOV - 4.6%(3rd Quarter 2021)

We will be doing analysis of Blinkit in another article in sometime.