Krishan Yadav Get in touch
Quantstantra

I build execution systems for crypto markets.

Execution algorithms, transaction cost analysis, and the risk layer around them. The problem is narrow and testable: take a large order, work it into the market without moving it, and prove afterwards exactly what it cost.

Get in touch What I build
Working 500 BTC — live
—Filled
—Avg fill
—vs arrival
—vs VWAP
Simulated on synthetic data. Switch the algorithm and watch the cost change.
What I build

Execution, measurement, and the controls between them

These three are usually separate tools that never quite agree with each other. I build them against a single event stream, so they always do.

Execution algorithms

Working a parent order into the market without moving it — adapting to the liquidity that's actually there rather than following a fixed schedule.

  • TWAP
  • POV
  • VWAP
  • Implementation shortfall
  • Adaptive passive

Transaction cost analysis

What the execution actually cost, broken into its parts rather than averaged into a single flattering number. Decomposed, so each part can be argued with.

  • Arrival slippage
  • VWAP slippage
  • IS decomposition
  • Adverse selection

Risk and controls

Limits checked before an order reaches the venue rather than reconciled after it. A kill switch that stops the system instead of politely asking it to.

  • Pre-trade checks
  • Drawdown limits
  • Reconciliation
  • Kill switch
How I build it

Three rules I design around

Most trading failures aren't bad strategies. They're systems that behaved differently in production than in research, or that couldn't say afterwards what they had done. These three remove those failures by construction rather than by vigilance.

01

One event interface for live and backtest

Algorithms consume the same events whether they come from a historical file or a live venue, and cannot tell which. If code branches on "am I backtesting", that's a design bug. Divergence becomes structurally impossible rather than something to hunt for.

02

Everything is an append-only log

Every order, fill and decision is written down before it is acted on. Any day can be replayed and any millisecond accounted for. That's the difference between a performance claim and an auditable one.

03

Assume the process dies at the worst moment

The system is designed to be killed mid-order. On restart it reads its log, queries the venue, reconciles the difference and resumes — without duplicating an order or losing a position.

Stack

What it's built on

Chosen for correctness under failure rather than for novelty.

NautilusTraderEvent engine
Python 3.13Managed with uv
Polars · ArrowMarket data
BinanceSpot · USD-M perps
Krishan Yadav
Who I am

Krishan Yadav

I'm a quantitative developer working on execution and market microstructure. I came to it from the trading side rather than from software, which is why I care less about elegant abstractions and more about whether a system can tell you honestly what it did at 3am on a bad day.

Most of my time goes into qexec — an execution management system built on NautilusTrader, running against Binance spot and perpetuals. Everything on this page is drawn from that work.

Based in India · IST
Contact

Get in touch

If you're working on execution, measurement, or trading infrastructure — or want an existing setup reviewed honestly — I'm glad to talk. Tell me what you're trading and I'll tell you straight whether I can help.

[email protected] LinkedIn GitHub