Changelog

?ref= and document.referrer are stored on first touch, before any navigation loses them, and ride along on the login event. The deposit modal beacons once per open.

The navbar badge was hardcoded; it now renders only when NEXT_PUBLIC_HL_TESTNET is set. The wallet-reset copy loses its testnet wording, and notes that the old key stays recoverable — true since the vault, and the thing a user staring at that confirm needs to know.

Direct-to-HL calls (price fallback, live-candle WebSocket) each named their own endpoint, one of them testnet — mixing venues with the backend proxy. NEXT_PUBLIC_HL_TESTNET now decides both, defaulting to mainnet to match the production flip.

Where a Chipa product (ChipaEditor first) sends its user to link their ChipaX account. The request is validated against /oauth/client before anything approvable is shown, sign-in reuses the ChipaAuth modal, and approve/deny/failure all exit by redirecting back to the product with either a code or error=access_denied.

The recorder loaded the whole chart and then panned the visible range across it, so every candle after the entry was already on screen: the outcome was visible before the trade played out, which is not a replay. The charting library edition we ship has no bar-replay mode, so panning was the only thing it could offer. The replay is now painted directly onto a canvas from the candle data. That allows a bar to be revealed while it is still forming — walking open to extreme to close — and it lets the price scale ease toward its new bounds rather than snap, so the chart moves continuously rather than one jump per bar. The entry level, the profit region, the exit marker and a running PnL figure are drawn as the trade progresses. It also removes the iframe canvas compositing that made recordings come out blank: the canvas the user watches is the one being recorded, so there is no second rendering path to drift.

The old share modal painted its own canvas, which meant the exported image and the on-screen preview were two implementations that could drift. ShareTradeCard is now the single source of truth for both: it is sized in container query units, so the same component serves the in-app preview, the 1200x675 landscape export and the two portrait sizes. Export rasterises the card through an SVG foreignObject. That cannot fetch subresources, so the referral QR is encoded to a data URI at render time rather than served as a file — which also keeps the code on the card and the link behind the QR from ever disagreeing. The referral code is still a placeholder pending a real referral backend; it lives in one constant so there is a single place to change.

/demo/portfolio was reading the live Hyperliquid account and showing real balances under a demo URL, which is precisely the confusion the demo mode exists to prevent. Orders and assets had the same problem. All three now read the paper account when the path says demo. A shared adapter reshapes it into the payloads these pages were built against, so they render it unchanged and the two modes cannot drift apart visually — practising on a different-looking screen defeats the point. Portfolio shows demo equity, positions and history; orders lists resting demo orders including armed take-profit and stop-loss exits; assets reports the paper balance with an empty token table, since a paper account has no spot wallet to enumerate. Every loader re-runs when the mode changes rather than leaving the other account's rows on screen.

Demo was only the trading desk, so a demo trader who opened Portfolio or Orders was looking at their real account without being told. The mode belongs to the product, not one page. A proxy rewrites /demo/<anything> onto the same route, so every page renders from the same code with the /demo prefix intact in the address bar, and the client reads the mode straight off the path — no stored preference to go stale and no route to duplicate. /demo alone lands on the trading desk. Internal links carry the mode through a href() helper, so browsing from the demo desk to Portfolio stays in demo and leaving it has to be deliberate. The live/demo switch keeps you on the page you were reading: /demo/trade/ETH toggles to /trade/ETH rather than dumping you at a default market. Verified: /demo, /demo/portfolio, /demo/alerts, /demo/watchlists, /demo/marketplace, /demo/changelog and /demo/orders all render, navbar links from a demo page all point back into /demo, and toggling live from /demo/trade/ETH lands on /trade/ETH.

Demo was a stored preference, so which account an order would hit depended on what the last session had chosen and the URL said nothing. It is now a place: /demo/trade/BTC is the demo desk, /trade/BTC is live, and each pins the mode on arrival — a live link opens live even if the browser last remembered demo, which is the direction that matters. The desk is the same components as live trading, because rehearsing on a different screen than the one you will trade on defeats the point; only the account behind it changes. The header toggle navigates between the two routes instead of flipping state in place, and changing market from inside demo stays in demo rather than dropping into live. Verified: /demo/trade/BTC titles as Demo and lights the amber toggle, clicking live lands on /trade/BTC, and opening /trade/ETH with demo stored as the preference still opens live.

The form already collected them for live trading; they now reach the demo engine too, so a demo order behaves the same way as the live one it is meant to rehearse.

A live/demo switch in the pair header routes the order form, positions, history and balance to the paper account. The mode persists across sessions, because a trader who left in demo yesterday should not return to an order form that looks identical but spends real money — while it is on, the toggle and the header edge are amber. Demo positions are reshaped into the live position format so the existing table renders them unchanged, including the liquidation price the engine computes. Balance shows equity rather than deposits, since that is what an account with open positions is actually worth. Switching modes refetches immediately instead of leaving the other account's numbers on screen until the next poll. Spot is refused in demo: the engine models perps, and silently treating a spot order as a perp would teach the wrong thing.

Every file under public/ returned 404 in production — the logo, the svgs and the whole charting_library, so the chart could not load at all. Removing standalone output did not help: Firebase App Hosting deploys the traced file set, and tracing only keeps what the code demonstrably touches. Nothing references public/ from code, so the entire folder was dropped. The giveaway was that exactly one file survived: public/changelog.json, which the changelog page reads with readFileSync — tracing followed that read and kept it, which is why one asset served while its neighbours did not. outputFileTracingIncludes now pins the folder to every route. Verified against the build output: the trace manifests list all 364 public files, including charting_library.standalone.js and chipa-logo.png, where they previously listed only changelog.json.

exchange.chipatrade.com returned 404 for every file in public/ — the logo, the svgs, and the whole charting_library, so the chart could not load at all. The requests fell through to the prerendered 404 page (x-nextjs-prerender: 1) because output: 'standalone' deliberately omits public/ from the build: a standalone build carries the server and nothing else. The Dockerfile copies public/ and .next/static back in afterwards, so the container was fine and nobody noticed. Firebase App Hosting deploys the build as it finds it, and there was nothing to serve. Standalone is now opt-in through BUILD_STANDALONE, which only the Dockerfile sets. Verified both ways: a default build produces no .next/standalone and keeps public/ in place, and BUILD_STANDALONE=1 still produces the standalone tree the image expects.

next.config.ts reads version.json when the server starts and bakes it into an env var, so a running dev server keeps whatever version it booted with — the footer sat at 2.22.30 while the repo had moved on. The badge now reads the version from the changelog file in /public, which is served from disk and rewritten on every commit, falling back to the build-time value if the fetch fails. Verified against a dev server still holding 2.22.30 in its env: the footer shows 2.23.0.

version.json sat at 2.22.30 with nothing to bump it. A pre-commit hook now raises the patch and a pre-push hook raises the minor and resets the patch, so "2.23.4" reads as four commits since the 23rd release. Both are counters seeded from the version the file already held, so the numbering continues instead of restarting at a commit count. The major stays manual. The bump is staged by the pre-commit hook so it travels in the commit it describes. A pre-push hook can't join the push that triggered it — the refs are already fixed — so the minor lands with the next commit and trails the live deploy by one push. /changelog renders commit history from a JSON file written at commit time, since the deployed build runs from a snapshot without git history. Entries are grouped by day and show the reasoning from the commit body, with plumbing commits filtered out; the version badge in the ticker links to it.

The recording chart was rendered at left:-10000 to keep it out of the way, but browsers throttle rendering for off-screen content, so the charting library never painted and every captured frame was empty background. It now records on screen, scaled down to fit the dialog while keeping its full internal resolution, so the user watches the replay as it captures. Frame compositing also used the parent-side iframe offset together with rects measured inside the iframe: two different coordinate spaces, which under a CSS scale would both misplace and shrink every canvas. In-iframe rects are now used on their own. A capture whose frames are entirely background is reported as a failure instead of handing over a black file, and the finished video plays back in the dialog rather than only being downloadable. Verified in the running app: a scaled on-screen chart composites 7 canvases into a non-blank frame and records a 247KB webm.

The order form now asks the API for the real approval state on load and shows a banner when the agent has lapsed or expires within two weeks, with a one-click re-approve when the key is available in the session. Until now the first sign of a lapsed approval was a rejected order.

"Auto chart patterns" in the Chipa Indicators menu scans the last 400 bars and draws what it finds: double tops and bottoms, head and shoulders and its inverse, and ascending, descending and symmetrical triangles — each outlined leg by leg, labelled, and given its measured target as a dotted line where the pattern implies one. Everything is built from pivots — swing highs and lows that stand clear of their neighbours — because each classic pattern is a statement about the shape of consecutive pivots. Detection is deliberately conservative, with a price tolerance and a minimum pullback, since a pattern drawn where none exists is worse than a blank chart. Overlapping matches resolve to the richer pattern, so a head and shoulders isn't also reported as two double tops. Also fixes header buttons racing the header widget: createButton throws if the header hasn't mounted, and chart-ready doesn't imply header-ready. The buttons had been created on the wrong signal all along and had started failing outright — they now wait on headerReady. Verified against live BTC data: six patterns detected and drawn as 6 labels and 22 outline and target segments.

Bars that close on volume or on price movement are a Trading Platform chart type this Charting Library build doesn't have — but the datafeed decides what a bar is, so they're built here instead and handed over as ordinary bars. New resolutions: V10/V50/V100 close a bar once that much base volume has traded, R25/R50/R100/R250 once the bar spans that much price. Both aggregate from one-minute candles, and each bar keeps the open time of the minute it started so the series stays strictly increasing. Live updates rebuild the tail from recent candles on a poll: a bar that closes on its own terms can't be described by the time-based candle socket. These are approximations — one minute is the finest input Hyperliquid offers, so a bar can overshoot its threshold by whatever happened inside that minute. True range bars need tick data. Verified the aggregation against a synthetic series: 100 candles at volume 3 give ten V30 bars each of exactly 30, a one-per-minute drift gives ten R10 bars each spanning at least 10, and bar times increase strictly in both.

Closed trades in Trade history get a replay button. It opens a dedicated chart sized for video, marks the entry and the exit with the trade's PnL, then pans the visible range forward one bar at a time from before the entry to past the exit while recording, and hands back a .webm to download. Configurable: timeframe, playback speed, 720p/1080p/square output, how many bars of context to show either side, and whether to overlay Quantum Flux. The chart lives in an iframe, so each frame is composited by drawing every chart canvas onto one output canvas at its own offset — panes, scales and all — and that canvas is what MediaRecorder captures. Recording uses its own widget instance off-screen, so the chart being traded on is untouched. Hyperliquid reports fills rather than round trips, so a closing fill is paired with the most recent opening fill on the same coin and side to recover the entry price and time. Verified in the running app: 7 chart canvases composite into a non-blank frame, VP9 is selected, and a 40-frame capture produced an 87KB webm.

/marketplace browses published scripts, publishes new ones with named setting fields per indicator, mints and redeems invite codes, and manages your library. Scripts you add appear under a "FROM MARKETPLACE" heading in the chart's Chipa Indicators menu and apply with their saved inputs.

/watchlists manages named symbol groups: create, rename in place, add and remove symbols, delete, with live mid prices beside each symbol and a link through to that market. The alert dialog gains an "Applies to" selector — this symbol only, or any watchlist — so one alert can cover a whole group.

Restoring chart state with widget.load() after the chart was ready left the chart in a state where createShape and createMultipointShape silently returned undefined. Any user who had drawn something would have lost the BUY/SELL signal labels with no error to explain it. The saved state now goes to the widget constructor's saved_data option instead, which skips the post-ready reload; verified that drawings survive a reload and new shapes can still be created afterwards. Volume Profile (VPVR) joins the Chipa Indicators menu as the first "drawing" indicator: volume is bucketed into 24 price rows over the last 300 bars of the chart's interval and drawn as horizontal bars anchored to the latest bar, with the point of control in gold. Each bar's volume is spread across the price band it actually covered rather than dumped at its close. Clicking the entry again clears it. It is drawn with the shape API because study plots are vertical — one value per bar — and a volume profile is the transpose of that. getVisibleRange() reports {0,0} in this library build, so the window comes from the candle feed.

First batch from the TradingView Premium feature list, limited to what this charting library edition and the Hyperliquid feed can actually support. Hyperliquid caps a candle request at roughly 5,000 bars — measured, not documented: asking for 10,000 one-minute bars returns about 5,200. getBars now walks the range backwards in chunks, capped at eight pages (~40k bars) so a wide range can't fan out into unbounded requests. Enables study_on_study (apply an indicator to another indicator's output), custom_resolutions (type any interval instead of picking from the list) and chart_style_hilo, and adds an Export button that downloads the visible chart data with all indicator columns as CSV.

The drawing toolbar was switched off (left_toolbar disabled and the side toolbar hidden), so none of the line tools were reachable. Enabling it brings back the full set: cursors, trend lines, Gann and Fibonacci, geometric shapes, annotations, patterns, prediction and measurement, emoji, ruler, zoom, magnet, drawing mode, lock all, hide all and remove all. Undo/redo comes back to the header with it, since drawing without undo is painful. Drawings only persist with a save/load adapter, so chart state is saved per symbol to localStorage on the library's autosave signal and restored when the chart is ready — BTC's drawings stay off the ETH chart. Verified in the running app: the toolbar renders every group, and a drawn horizontal line survives a full page reload with its id intact.

The chart's only realtime path was a 10s poll of the candle endpoint, so the price on screen could be ten seconds stale and moved in visible steps. subscribeBars now opens a websocket to Hyperliquid and subscribes to the candle channel for the chart's symbol and interval. It also subscribes to allMids and applies mid prices to the live bar between candle frames: the candle channel only emits on trades, which on a quiet market measured three frames a minute against fourteen for mids. The browser connects to Hyperliquid directly rather than through the API — a persistent socket via Cloud Run would hold an instance open and bill for every second a chart is on screen. The socket points at the same environment the bars come from (the backend candle proxy serves testnet: its last close matched the testnet mid, not mainnet's), overridable with NEXT_PUBLIC_HL_WS_URL. Ticks more than 5% from the last known bar are dropped, so a misconfigured URL degrades to the poll instead of drawing a wrong price. The poll stays as a backstop, and reconnects back off from 1s to 30s. Verified in the running app: the chart's legend price moved through 10 distinct values in 50 seconds, updating within 2s of each change.

The bottom-panel tab is too cramped to actually manage alerts, and there was no way to see at a glance which ones are armed. /alerts now lists every alert with its status, condition, trigger mode, channels, fire count and when it last fired, with filters for active and paused, per-row pause/edit/test/delete and multi-select for bulk pause, resume and delete. Alerts that differ only by id are easy to create by accident, so identical settings are flagged as duplicates in the list. Reachable from the navbar and from a "Manage all" link on the chart's alerts tab, which stays for quick access while trading.

Lets the UI be pointed at a local API with CHIPAX_API_BASE so features can be tested before they are deployed. Defaults to the deployed API, unchanged.

A "🔔 Alert" button on the chart toolbar opens a dialog for the current symbol: condition (crossing, above/below, percent move, Quantum Flux signal), timeframe, trigger frequency, optional message and expiry, and per-alert notification channels — desktop, email, Telegram chat id, Discord webhook and a generic webhook URL. An Alerts tab beside Positions lists alerts with pause, edit, delete and a Test button that fires every channel so wiring can be checked without waiting for a real trigger, plus a log of what has already fired and how each channel delivered. Alerts are evaluated server-side, so AlertNotifier just polls /alerts/events for anything newer than this browser has seen and raises a desktop Notification, requesting permission when the desktop channel is first ticked.

Custom studies can't render text inside a shape plot — the API exposes no text or size for shape markers — so the signal markers were an unreadable ~13px glyph. Read the study's plot values back with exportData and draw a white-on-colour "BUY"/"SELL" badge at each signal bar with the chart shape API instead. Labels are cleared and redrawn when the study is re-added or the timeframe changes, since they're pinned to bar times.

The label shapes render, but they are a ~13px glyph and signals are rare (two in a 301-bar window on BTC 1h), so they are easy to miss. Add a bar_colorer plot that recolours the signal candle itself in bright green or red. bg_colorer was tried first and draws nothing in this library version.

Two separate problems kept the buy/sell markers off the chart: - `shape_label_up`/`shape_label_down` were paired with `textColor` and `histogramBase`, which the library's own shape studies never set. Matching the built-in metainfo (plot_0..plot_3 ids, isHidden, _metainfoVersion 52, scriptIdPart) makes the shape plots draw. - The state machine committed its state only when a new bar opened, so when the library replayed history over the same study instance the state never rewound and the trigger flags were lost. State is now a per-bar timeline that rolls back whenever a bar is re-run. Verified against the rendered canvas: the shape plot draws exactly one marker per signal. Uses the label shape rather than the arrow — at roughly three times the pixel footprint it's the most visible option the custom-study API offers, since it exposes no marker size or text.

The shape plots used `shape_label_up`/`shape_label_down` plus `textColor` and `histogramBase`, none of which the library's own shape studies use, and nothing was drawn. Match the built-in shape metainfo exactly: arrow shapes, `isHidden: false`, and no extra style keys.

Ports the "Quantum Flux [Strict Alternating]" Pine v5 script to a TradingView custom study: denoised OHLC, EMA/z-score/RSI confluence and a strict-alternating BUY/SELL state machine with ATR take-profit and stop-loss levels. All lengths and multipliers are exposed as study inputs. Two PineJS constraints shaped the implementation: - Std.ema/Std.stdev keep running state, so the NaN warm-up bars of the denoised series poisoned them permanently. The denoise falls back to the raw price while its SMAs warm up. - Series only expose the history depth Std.* helpers happen to request, so persistent state is kept in instance fields committed per bar rather than in new_var series. This also makes the non-repainting one-bar shift rollback-safe on the live bar. Adds a "Chipa Indicators" dropdown to the chart header that lists our custom studies and adds the selected one to the chart.

- Add global styles with Tailwind CSS support - Create layout component for the application - Implement home page with initial content and layout - Set up ESLint with Next.js configurations - Configure Next.js with basic settings - Add package.json with scripts and dependencies - Set up PostCSS for Tailwind CSS - Include SVG assets for branding and icons - Create TypeScript configuration for the project