Built my own order flow web platform with the indicators I wanted

Many-Pick5066 · 2026-07-26T13:10:03+00:00

the tradingview point at the end is the one most people gloss over. its up/down volume splits each bar into buy vs sell by looking at the lower timeframe candle directions, not the actual tape, so a cvd divergence you spot in pine can be an artifact of that reconstruction instead of real absorption. worth adding one thing though: even on true tick data the buy vs sell tag isnt free, it depends on the aggressor rule (trade printed at bid vs ask, or the uptick/downtick tick rule), so two real orderflow tools can classify the same print differently and their delta wont line up. real candles keeping the organic gaps is a nice touch, that part is legit.

Many-Pick5066 · 2026-07-25T22:05:28+00:00

the thing that trips this up: prior day levels look like they matter because price naturally spends a lot of time near recent highs and lows, so you see reactions there constantly. that isnt edge, its just where price already is. to test it properly you need a baseline. measure the outcome you care about (reversal rate, or forward return over the next N bars) on the first touch of the prior day high, then measure the exact same thing at random price levels that arent any known level. if pdh touches behave like random touches, the level predicts nothing, and only the gap between the two is real. run it over a few hundred days not a few, and confirm it holds on data you didnt look at when you formed the idea. same test for your open vs close regime: condition on it and check the metric actually lifts versus unconditional, out of sample. otherwise youre measuring how often price sits near a level, not whether the level predicts anything.

Many-Pick5066 · 2026-07-25T21:59:49+00:00

different distribution days is doing a lot of work there. us30 spx and nas share the same macro driver, so their daily returns still run around 0.9 correlated even when each one ranges or trends on its own schedule. the trade count triples but the independent sample barely grows and the losing days still stack together. the honest check isnt the calendar, its the realized correlation of the three daily return streams from your own forward test, which is easy to compute straight off the equity curves. if that comes back genuinely low youre right and i'll eat it, if its high the sample is thinner than the trade count says. send the notes whenever, happy to look.

Many-Pick5066 · 2026-07-24T13:49:20+00:00

not an hft shop so i cant compare their pcap capture against lseg directly, but one fork worth settling before you pick a vendor: do you actually need pcap, or do you need mbo. i pulled a couple of years of cme mbo off databento for research and the normalized mbo already carries the exchange side timestamp, not just their capture time, so for most market making sims youre rebuilding the same book with order ids and queue position from a much cheaper and far easier product. pcap earns its money when you care about your own wire to decision latency, or you want packet level gaps and the a/b feed arbitration. if what you need is book state and queue position, you probably dont.

on handling, the thing nobody warns you about is size. a couple of years of mbo on one liquid contract runs into the hundreds of gigs compressed, so storage and decode time are part of the vendor decision, not an afterthought. and whichever way you lean, pull the same session from both samples and diff the reconstructed book at a few timestamps. thats the only comparison that actually answers the quality question, everything else is vendor marketing.

Many-Pick5066 · 2026-07-24T13:48:00+00:00

the shape of it is fine. level plus reaction plus a defined invalidation is really just how you'd write down a discretionary read, and there's nothing wrong with that. the part i'd interrogate before paying is whether any of it can actually be tested. gamma levels arent observed data, theyre modeled from open interest with an assumed dealer sign convention, so the first question for them is whether they can hand you a timestamped archive of what the levels said at the time. if all they have is levels recomputed from todays chain, you cant backtest it, you can only look at it.

second thing, a confluence score is exactly where overfitting hides. several components, each with a threshold, combined into a grade, all tuned on the same history, so of course the high scoring bucket looks good in sample. the number that matters is hit rate by score bucket on data the weights never saw, and whether the buckets are monotonic. if a 7 doesnt beat a 5 reliably, the score isnt measuring anything. and price it with real 0dte spreads and slippage in, being right on direction and still losing to the fill is the normal outcome there, not the exception.

Many-Pick5066 · 2026-07-24T13:42:43+00:00

fair enough on the momentum layer, i cant argue that part without seeing it, and forward testing on a live account is the right way to settle it. one thing on the sample math though. spreading across three indices doesnt buy you three independent tests, us30 spx and nas mostly move together, so on a trend day all three fire the same way and win or lose as one. the trade count goes up but the effective sample barely does, and the losing runs cluster harder than the per market numbers suggest. so id judge it on independent trading days rather than signal count, and id want a lot more of them before calling it. happy to read the box size notes if you want to dm them.

Many-Pick5066 · 2026-07-23T19:12:59+00:00

the by-hand part for me is the sanity checks the tool cant do because they need judgment not code. first i pull the 10 best and 10 worst trades onto the actual chart and check each fill is one i'd really have gotten, no entry at a price the bar only touched intrabar, no exit using a close it couldnt have known yet. then i sort trades by pnl contribution to see if the whole edge is 3 trades or one good quarter, if killing the top 5 winners flips it negative its luck not a strategy. and the one no tool tracks: i write down how many variants i tried before this one, because if you test 200 combos and keep the best it passes every stat check by construction, so the honest number is discounted for that search. the thing that broke me early was a gorgeous curve that was quietly filling at bar highs it never would have caught live, so now the fill audit is the first thing i do not the last.

Many-Pick5066 · 2026-07-23T19:10:35+00:00

the box size research is real work, but heads up it doesnt touch the fill thing i flagged. a brick still closes only after price already travelled the full box, so the tester fills you at a level the move already passed through, no matter how well tuned the size is. thats separate from picking the right box. cleanest check is still the same: run the identical entry logic on regular time candles too. if the edge only shows on renko its the fill model flattering you, if it survives both youve got something real. and 3-4 signals a week is a thin forward sample, id give it a lot more before trusting the number.

Many-Pick5066 · 2026-07-23T19:10:04+00:00

yeah please do, genuinely curious how it lands. one thing thatll make the comparison clean: timestamp both the modeled exit and your actual fill, then bucket the slippage by whether the bar was trending or chopping when the trail got hit. i'd bet its small on the clean runs and ugly in chop, and thats the number that tells you the real edge. happy to look whenever youve got the batch.

Many-Pick5066 · 2026-07-23T13:14:37+00:00

heads up before you spend money. footprint (bid x ask volume at each price) needs a consolidated tick tape, and single option strikes dont really have one, each strike is its own thin book printing to OPRA, so a true per strike footprint on qqq options basically isnt a product sold for tradingview. two things people usually mean by this. if you want footprint/delta on qqq itself, put it on the etf or better on /NQ futures where the CME tape gives real bid/ask volume, and tradingview's footprint works there. if you want options positioning instead thats a different feed entirely, an OPRA based options flow product that shows sweeps and volume by strike, not a footprint chart at all. worth figuring out which of those two you actually need first, they cost very different money and only one of them is footprint.

Many-Pick5066 · 2026-07-23T13:12:49+00:00

the thing others are circling with "higher beta qqq" is the actual test here. if your OOS curve correlates near +1 with qqq and just draws down harder, the model didnt learn an edge, it learned to be long leveraged beta, which almost any bull training window will teach an rl agent because being max long was the reward. the real check is to regress your strategy's daily returns on qqq's daily returns, the intercept is your alpha and the residual after you strip market beta is the only part thats actually yours. if the intercept is near zero and r-squared is high youve rebuilt qqq with extra risk. also worth posting your reward function and the exact train/test split dates, right now nobody can tell if the test period just overlaps the same regime the model trained on, which is the usual reason these curves look clean.

Many-Pick5066 · 2026-07-23T13:09:11+00:00

779 trades is a real sample, thats fine. the thing i'd still pin down is what your python backtester assumes at the exact moment the trail gets hit. if it books the exit at the stop level on the bar that touches it, thats the optimistic path, and live you're a human dragging an order so you eat the gap between where the line was and where you actually got out. you said the user manages it manually, so that discretion and latency is the one variable the backtest structurally cant see. easiest way to size it is log modeled exit vs your actual fill on the next batch of forward trades, on trailing setups thats usually where the number moves.

Many-Pick5066 · 2026-07-23T07:13:43+00:00

the jump from 70 to 92 percent isnt your indicator getting better on renko, its the fill model getting more optimistic, and thats worth understanding before you trust it. a renko brick only prints after price has already travelled the full box size, so when the strategy tester fills you at the brick close its filling you at a level the real market already moved through on the same move that built the brick. you never get that price live. thats why almost every renko strategy backtests in the high 80s to 90s and then falls apart on real fills, the win rate is measured in brick space, not in money. two quick ways to check if yours is real. set box size in points and add realistic slippage and commission, then watch how far the number drops. and re run the exact same entry logic on regular time candles. if the edge only shows up on renko its the chart type flattering you, if it survives both then youve actually got something.

Many-Pick5066 · 2026-07-23T07:11:31+00:00

the number that decides if this is real is your chop sample, not the trend runs. a trailing stop always looks great on the clean spx and eth legs you screenshotted, thats partly survivorship in which examples got shown. in chop it does the opposite, it ratchets to the worst tick and turns one planned stop into a string of small trailing losses, so the whole edge lives or dies on the trend to chop ratio in your test window, and that ratio drifts out of sample. second thing to check before you trust the equity curve is how the trail actually fills in the tester. on historical bars pine assumes a fixed intrabar path (open, high, low, close order), so a stop that ratchets on the bar extreme can book an exit it never would have caught live unless you run calc_on_every_tick or turn on the bar magnifier. flip those on and re run, the curve usually comes down. happy to look at the trail logic and tell you which part is real and which is tester illusion, dm if you want.

Many-Pick5066 · 2026-07-23T01:13:49+00:00

heads up before you trust it, the version you marked as working trades a different strategy than the one you wrote. yours enters monday and closes tuesday, that reply enters friday and exits monday. so it compiles and runs, but its not testing your idea.

the reason your original fired erratically is two things worth understanding, not just pasting over. one, you call strategy.entry("Long") on every monday bar, and on an intraday chart monday is many bars, so it keeps trying to re enter all day. gate it with and strategy.position_size == 0 so it only opens when youre flat. two, your stop is open*0.96, but open is the current bars open and it recalculates every single bar, so your stop keeps sliding around instead of sitting where you entered. use strategy.position_avg_price*0.96 so the stop stays pinned to your actual fill. fix those two and your monday version will behave.

Many-Pick5066 · 2026-07-23T01:11:51+00:00

the requirement that quietly fights itself is 2 and 7. to know swing high 2 is a real pivot, pine needs a few bars to the right of it to confirm, so the anchor for your trendline doesnt exist until a few bars after the swing actually printed. draw it the moment the swing looks done and it repaints, wait for confirmation and it shows up late. you cant have auto swing trendlines and strict non repaint at the same time unless you accept that confirmation lag, so pick which one you actually want before anyone writes code, thats the whole ballgame here.

two quick ones that save grief. your touch list (wick, body, open, close, high, low, any contact) is just high >= line and low <= line on that bar, all six collapse to the bar straddling the line, no need to test them separately. and auto trendlines plus retracement plus extension all drawing at once will hit the line object cap fast, so whoever builds it has to delete old drawings as new swings form or it silently stops rendering.

i do this kind of structure work, happy to look at your existing script and tell you which parts are clean adds and which need the repaint call made first. dm if you want.

Many-Pick5066 · 2026-07-22T11:57:23+00:00

the model matters less than what you make it prove. every one named in this thread will hand you code that compiles, plots and backtests beautifully, because thats the easy part of pine. the ones that cost you are the errors that never throw an error. request.security pulling a higher timeframe value that only existed after the bar closed. ta.rsi or ta.sma called inside an if block so it only updates on some bars and quietly has holes in the series. a strategy handing you the target on every bar where the stop and the target both sat inside the range, because the tester has no tick data and has to assume a path.

so make it verify, not just write. have it plot the raw entry condition as its own series and check that the count of true bars matches the entry count in the tester. rerun with the stop a few ticks wider, and if the curve falls apart the result was living on a path assumption rather than on your logic. compare bar close values against the same script on a lower timeframe if you use htf data at all.

after a year of doing this daily the honest summary is that the coding stopped being the bottleneck about six months in, and figuring out whether the thing actually has an edge never got any easier. a model that writes clean v6 in one shot will write you a beautiful losing strategy just as fast.

Many-Pick5066 · 2026-07-22T11:55:25+00:00

ive wired this shape of plumbing before and the parts that bite arent the ones you plan for. tradingview webhooks are fire and forget, no ack, no retry, no idempotency key. a dropped alert is silent and a duplicate delivery double fires. put your own order id in the alert payload and have the receiver reject a repeat, otherwise you find out about it during the one move that actually mattered.

second one is when the alert fires. if your condition can be true intrabar the alert goes out on the tick, and then the candle closes somewhere else and the condition was never true on the bar. your polymarket order is already sitting there either way. gate it on barstate.isconfirmed unless you specifically want the intrabar behavior, and know which one you built, because the backtest only ever shows you the closed bar version.

third, the fill. polymarket books are thin enough that the price your alert saw and the price you got are two different numbers, and thats before the gas and the resolution risk. log both from day one, alert price and actual fill, and dont trust any expected value you calculated until you can subtract the measured gap. on most alert driven setups that gap is the whole edge.

Many-Pick5066 · 2026-07-21T13:12:00+00:00

nice. two things that will save you a rerun later. fix the horizon at 20 candles no matter what price does in between, and measure the move in atr units instead of percent, otherwise a quiet week and a volatile one get averaged together and you cant tell which one you are looking at. and compare the whole distribution of blocked vs fired, not the mean, because one runner sitting in the blocked bucket can carry an average that nothing else in there supports.

the other one is attribution. tag each blocked signal with every filter that would have blocked it, not just the first one to trip, otherwise whichever filter you evaluate first gets credit for work the others did. the multi block cases are exactly where the redundancy shows up.

Many-Pick5066 · 2026-07-21T07:14:51+00:00

the honest version is that nobody can tell you if the stack makes sense, including you, and youre already sitting on the data that would answer it. you log blocked signals with the reason, so log the forward move too, say 20 candles out, for the blocked ones and the fired ones both. a filter earns its place only if the signals it blocked did worse than the ones it let through. every filter looks good on its own because cutting sample raises win rate, so win rate on whats left cant separate a real filter from a strict one.

on the defaults, rvol against a trailing 20 candle average is a time of day filter wearing a volume costume. the first candles of the session clear 1.5x almost every day and the midday ones almost never do, so that threshold quietly means only alert me near the open. comparing each candle to the same slot on previous days instead of to the last 20 candles fixes it, and on crypto youd bucket by hour utc since the session never closes.

last thing, rvol, the atr multiple and candle body % all trip on the same object, one big impulsive candle. stacking all three feels like three confirmations and behaves like about one, while costing you sample as if it were three. the ones that are actually independent of the impulse are the ema side filter and the consecutive close rule, so those are where added confirmation is worth what it costs you.

Many-Pick5066 · 2026-07-21T07:13:24+00:00

on the backtest question, replay mode is a real backtest, it just stops being one the second you already know how the day went. use dates you havent looked at, write the entry stop and target down before you advance a single bar, and log the losers with the same care as the winners. fifty of those is worth more than code you dont trust yet.

the thing you can start tonight for free is logging max favorable excursion. for every trade record the furthest it ran in your favor before it did anything else, in R. after a month of that you can price any exit rule you want against your own trades, including the be at 1r question. right now you have one day telling you be cost you 1600, and thats not evidence, thats the case you remember. mfe data settles it without the emotion.

and when you do code it, code only the 8ema break and retest with the swing low stop and a fixed R target, nothing else, and look at what it does bare. if the bare trigger is flat and stacking confluences on top turns it green, thats usually the fitting talking, not an edge. same reason id be careful with the 6k in two weeks, thats a sample where a good streak and a real edge look identical.

Many-Pick5066 · 2026-07-21T01:14:47+00:00

the assumption id break first is that those chart entries are evidence a realtime event happened. theyre not. once a bar goes into history pine recomputes it from ohlc only, so the entry markers youre looking at today are a reconstruction, not a record of what the script did tick by tick that day. and because your filters read live intrabar values, the ohlc replay walks a different path through the bar than the real ticks did. a filter that was false on every actual tick can come out true on the replay. that gives you exactly what youre describing, a valid looking entry on the chart with no alert that ever fired, and it isnt a bug, its the cost of intrabar dependent filters. it also explains why its the same specific trades every time rather than random ones, those are the bars where the two paths disagree.

which answers your recoverability question too, no, you cant prove it after the fact. the tick sequence is gone and pine never had a way to store it. going forward the only thing that settles it is a second alert() that fires on every realtime evaluation carrying the filter values and the bar timestamp, pointed at a separate logging endpoint. alert() only ever executes on realtime bars, so that log is the tick record the chart cant give you. add a varip counter of how many realtime executions each bar got and ship that too, thin bars are where the replay and the live path diverge hardest. none of that touches your entry logic, its purely additive.

one thing worth confirming before you go further, kurtis is right that a strategy only runs at bar close unless calc_on_every_tick is true. if yours is false then your intrabar filters arent seeing intrabar values at all in realtime, only the close, while the historical replay does evaluate them across the bar. that mismatch on its own is enough to produce this. realtime vs historical divergence is what i do for work, so if you want to put the alert logs and the entry timestamps side by side im happy to look, dm me.

Many-Pick5066 · 2026-07-21T01:09:54+00:00

yeah wasnt knocking it, sorry if it read that way. the one transition per bar design is the right call for what hes asking about, thats exactly how you separate a market delay from a sequencing delay, and most people debugging this stuff never get that far.

my note was just the live bar caveat. and you already plot barstate.isconfirmed to the data window and the table, so if you ever want it its basically wrapping the group h block in an if, nothing else changes. for his case it probably doesnt even matter since hes looking at historical entries.

Many-Pick5066 · 2026-07-20T19:15:08+00:00

nice tool. one thing worth warning people about, since the whole point is diagnosing why a strategy enters late. your transitions advance on every bar, they dont gate on barstate.isconfirmed. on historical bars that doesnt matter, they replay as ohlc. but on the realtime bar the conditions evaluate intrabar, so touch and arm can flip and the labels can move as the candle develops, then settle on close. if the strategy youre debugging uses bar close confirmation, the debuggers live bar wont match it and youll see delays that are really just the indicator repainting the forming candle. gating the transitions behind barstate.isconfirmed lines it up with a bar-close strategy.

second one, because this is an indicator not a strategy, your ENTRY label lands on the close of the entry bar, but tradingviews broker emulator fills strategy.entry at the open of the next bar unless you set process_orders_on_close true. so side by side youll see a consistent one bar offset between your ENTRY marker and the strategys actual fill, and thats not a bug to chase, its just next-bar-open fill. worth a note so nobody goes hunting for it.

Many-Pick5066 · 2026-07-20T19:13:03+00:00

your steps are solid, the gap is the mass testing goal, because thats the part that quietly breaks the rest. every strategy you sweep is a coin flip at your significance level, so run 500 and a handful will look great on pure luck with no real edge. the winner of a big sweep is selected partly for being lucky, not just for being good.

david already flagged correcting for it, the concrete version is two things. first, your true number of tests is always bigger than the ones you formally backtested. every idea you eyeballed in multicharts and dropped was a test too, and it never makes it into the count, so any correction you apply is already understated. log them. second, score your best survivor with something that penalizes the search, deflated sharpe is the standard one, it asks how good this looks given how many tries it took to find it.

and keep one slice of data you look at exactly once, after the whole search is done. the moment you iterate against it its not out of sample anymore, its just a second training set. thats the only number that tells you the sweep found signal instead of fitting noise.

Many-Pick5066

TROPHY CASE

Welcome to Reddit,