Mechanism
What happens between the master order and every child account
QuantGrid is plumbing, not a strategy. You connect your broker accounts, pick which one leads, and set the multiplier for each account that follows. From there the software does one job: mirror the orders the master places, quickly and identically, and write down exactly what it did.
Setup
Four steps to go live
This part is a genuine sequence: each step depends on the one before it. Most people finish it in an afternoon, and the slowest part is usually waiting for a broker's API access to be enabled on their side.
Connect your broker accounts
You authorise each account through your broker’s own login screen: Kite Connect for Zerodha, SmartAPI for Angel One, API v3 for FYERS. QuantGrid receives a session token scoped to that account. It never sees your broker password, and you can revoke the token from your broker’s console at any time, which stops replication immediately.
Connect the account that will lead and every account that will follow. All API traffic for your account leaves from one dedicated static IP that is never shared with another customer, so brokers that whitelist an address see one stable address belonging only to you. The supported broker list covers what is live today.
Nominate a master
Mark exactly one connected account as the master. That is the only account QuantGrid watches for order events. It can be your own primary account, or an account you have been given read access to follow. You choose it, and you can change it.
Every other linked account is a child. A child’s own fills are still recorded in the log for audit, but they never trigger replication onward. That asymmetry is deliberate: it means a child account can never accidentally start driving the rest of the group.
Set copy factor, lot size and max quantity per child
Each master-to-child link carries its own three numbers, and they are yours to set:
- copy_factor multiplies the master’s quantity. 1.0 mirrors size for size, 0.5 halves it, 2.0 doubles it.
- lot_size is the exchange lot the result must be a whole multiple of. Set it for F&O contracts. Leave it empty for cash equity, where there is no lot constraint.
- max_quantity is a hard ceiling per order for that child, applied after the multiplier. It is the brake for the day the master sends something far larger than usual.
Children do not have to match each other. A ten-account setup can run ten different copy factors and ten different ceilings.
Go live
Switch the relationship on. QuantGrid opens the master’s order stream and begins mirroring from the next order onward. Orders already resting on the book when you go live are read once and marked as known, so turning the system on mid-session does not replay the master’s morning into your child accounts.
The platform itself runs 8:00 AM to 5:00 PM IST on NSE and BSE trading days and is switched off outside those hours. That has one consequence worth knowing before you rely on it, set out under the trading window below.
You can pause a single child, pause the whole relationship, or square off and cancel across every linked account from one screen. The full feature list covers the operator controls in detail.
A limit worth knowing before you set any of this up: QuantGrid replicates equity and F&O orders on NSE, BSE, NFO and BFO. Commodities (MCX) and currency (CDS and BCD) are outside that scope and are never replicated. The engine reads the exchange off the event before it looks at anything you configured, so an order outside that scope is written to the log as skipped and no child order goes out for it.
Event path
What happens the moment the master places an order
Five things happen, in this order, every time. None of them wait for a human.
Stream
The broker pushes the order update
Your master's broker publishes an order update the moment the order's state changes: accepted, partially filled, complete, cancelled, rejected. QuantGrid holds an open WebSocket to that stream, so the event arrives on a connection that is already established. Nothing is waiting on a poll interval to come around.
Normalise
QuantGrid converts it into one internal shape
Every broker describes an order differently. Zerodha sends BUY and SELL as strings; FYERS sends 1 and -1; statuses are words in one API and integers in another. The adapter for that broker rewrites the event into a single internal record: symbol, exchange, side, product, order quantity, filled quantity, status. Everything downstream sees only that record, which is what makes cross-broker replication possible at all.
Quantity
Each child's quantity is computed
For every active child link, the engine applies that child's copy factor, floors the result to the child's lot size and caps it at the child's maximum quantity. Each child gets its own number. A result that floors to zero is recorded as a skipped job and never reaches a broker.
Place
Child orders go out over the broker REST API
Each child order is placed against that child account's own broker, using that child's own session. Before anything is sent, the order passes three independent duplicate checks, so a retry or a reconnect cannot place the same child order twice. Children are dispatched concurrently, not one after another.
Log
Every step is written down
The event received, which source it came from, the quantity decision and why, the exact payload sent to the broker, the broker's response and its order id, all with timestamps. The trade log is append-only and exportable. If you need to reconstruct what happened at 09:15:04, the record is there.
Latency budget
Median under 50 milliseconds, measured from the master’s order update reaching QuantGrid to the child order being handed to the child broker’s API. That is the segment we control, so that is the segment we publish a number for. What happens after we hand the order over: the broker’s own API latency, the exchange acknowledgement, and conditions in the market at that instant, is not ours to promise and we do not put a number on it.
Every account runs this identical engine. Pricing never changes the speed or the limits: one flat price per broker account for its dedicated static IP, with every feature included.
Quantity
How each child's quantity is calculated
One formula, applied per child, on every replicated order. It is worth reading closely, because this is the number that determines the size of your risk in each account.
child_qty = floor_to_lot(master_qty × copy_factor)
child_qty = min(child_qty, floor_to_lot(max_quantity))Worked examples
| Master qty | Copy factor | Lot size | Max qty | Child qty | Result |
|---|---|---|---|---|---|
| 100 | 1.0 | none | none | 100 | Straight mirror. Cash equity has no lot constraint, so nothing is rounded. |
| 100 | 0.5 | none | none | 50 | Half the master's size, exactly as configured. |
| 750 | 0.4 | 75 | none | 300 | 750 × 0.4 = 300, which is already 4 whole lots. Nothing to round. |
| 375 | 0.5 | 75 | none | 150 | 187.5 floors down to 2 lots. Rounding up to 225 would be 3 lots, more size than 0.5 asked for. |
| 75 | 0.5 | 75 | none | 0 | Skipped. 37.5 is below one lot, so the job is logged as qty_zero and no order is sent. |
| 1,000 | 2.0 | 75 | 1,000 | 975 | 2,000 hits the 1,000 ceiling, and the ceiling is then floored to 13 whole lots. |
Scroll the table sideways on a narrow screen.
Why it always rounds down
Exchanges reject any F&O quantity that is not a whole multiple of the contract lot, so the result has to land on a lot boundary one way or the other. Rounding up would put more size in the child account than the copy factor asked for, which is a decision the software is not entitled to make on your behalf. So it rounds down, always, and when the result falls below a single lot it sends nothing and records the skip.
Partial fills are handled as deltas
When a master order fills in several chunks, each increase in filled quantity is replicated on its own rather than re-sending the whole order. That is what stops a staggered fill from doubling up on the child. The trade-off is that each chunk is floored to the lot on its own, so a child can finish a fraction of a lot under the total. Under-replicating is the safe direction to be wrong in.
Reliability
A dropped socket does not stop replication
Broker WebSockets disconnect. Tokens expire. Networks stall for a second. The interesting question is not whether that happens, it is what the system does in the seconds afterwards.
The WebSocket is primary
While the socket is up, order updates arrive pushed, not fetched. This is the fast path and it is the one you are on almost all of the time.
Order-book polling is the standing fallback
If the socket drops, QuantGrid starts reading the master's order book over REST every few seconds and keeps replicating from that. It is the same code path, the same duplicate checks and the same trackers, so the handover is safe in both directions and a brief overlap changes nothing.
Three independent duplicate checks
A cache marker keyed on the order, the child account and the quantity. A distributed lock so two workers can never act on the same fill at once. A unique database constraint that rejects a second write outright. Each one is enough on its own; all three run every time.
Reconnect keeps its memory
When the socket comes back, the engine resumes with the state it already had, so nothing already replicated is replicated again and nothing placed during the gap is missed. You get a Telegram alert on connection loss, and a reconnect button that forces a fresh handshake immediately.
The fallback is not a degraded mode you have to notice and act on. Every event in the trade log records which source it arrived from, so you can see after the fact that the socket was down between 11:04 and 11:06 and that replication carried on regardless. The uptime commitment is 99.9% during NSE and BSE market hours. More on how the platform is built and isolated is on the security page.
Trading window
The platform does not run around the clock, and an order placed while it is off is never replicated
QuantGrid runs from 8:00 AM to 5:00 PM IST on NSE and BSE trading days. Outside those hours, and at weekends and exchange holidays, the platform is taken offline for maintenance and to keep running costs down.
That matters more than a maintenance window usually would, because of the startup behaviour described in step four above. When the engine starts, it reads the master’s order book and records everything already on it as seen, so that going live mid-session does not mirror the whole trading day into your child accounts. There is no state that means “seen but not yet filled”: an order is either new to the engine or it is history.
Place your orders while the platform is up. An order placed on the master account outside the hours above, including an after-market (AMO) order, is not replicated at all: it is already on the order book by the time the engine starts, so it is treated as history rather than as a new order, and a later fill on it does not replicate either.
Cross-broker
A Zerodha master can drive a FYERS child
Because every event is normalised into one internal record before anything is calculated, the master and the child do not have to be at the same broker. The translation back out to the child's broker is automatic.
What gets translated
Symbols carry broker-specific suffixes. Product types have different names for the same thing. Sides are strings at one broker and integers at another. QuantGrid rewrites all of it on the way out, using the child broker’s own vocabulary, so the child order is the order the master placed, expressed correctly for wherever it is going.
Live today, in any master-to-child combination:
Groww, Upstox and Dhan adapters are in development and are not available yet. The brokers page is kept current.
Zerodha master, FYERS child
| Field | Master sends | Child receives |
|---|---|---|
| Symbol | NSE:RELIANCE | NSE:RELIANCE-EQ |
| Intraday product | MIS | INTRADAY |
| Carry-forward product | NRML | MARGIN |
| Delivery product | CNC | CNC |
| Side | BUY / SELL | 1 / -1 |
CNC is CNC at both brokers. Not everything changes.
Boundaries
What QuantGrid does not do
Worth being blunt about, because it is the part that decides whether this product is right for you. QuantGrid is execution software. Every decision that matters stays with you.
It does not choose what to trade
QuantGrid has no view on any security and never originates an order. Every order it places is a copy of one your master account already sent.
It does not decide when
Timing comes entirely from the master account. If the master does nothing all day, QuantGrid does nothing all day.
It does not act on its own
There is no discretion in the software. It applies the copy factor, lot size and maximum quantity you set, and nothing else. Change a number and the next order follows the new number.
It never holds your money
Funds and securities stay with your SEBI-registered broker throughout. QuantGrid holds an API session, not an account, and cannot withdraw or transfer anything.
Regulatory position
QuantGrid is a technology platform, not an investment adviser.
QuantGrid is not registered with SEBI in any capacity, gives no investment advice and makes no claim about what copying any account will do to your account. You select your own master, you set your own multipliers and limits, and you remain solely responsible for every order placed in your name and for every consequence of it. Replication can also fail: a child account can be short of margin, a broker can reject an order, a session can expire mid-session.
Get started
See it run on your own accounts
Open an account, connect one master and one child, and watch the first order go through end to end before you scale the copy factors up. Or book a 20-minute demo and we will walk through copy factors, lot sizes and limits for your setup first.
Prepaid wallet · No lock-in, stop any time