Open-source trading journal for DeFi perp traders

If you trade GMX, Hyperliquid, or any other DeFi perpetual seriously, the trading journal you actually need has fields the established SaaS journals never added. Funding rate paid over the hold. Borrow fee accrued against pool skew. Liquidation price at fill, and again at close. Pool the trade was on. Wallet that opened it. None of these are exotic — they’re just specific to perps, and specific to perps that don’t exist on Tradervue’s roadmap.

I never signed up for a SaaS journal. Instead I built a free, open-source one. It runs on my laptop, the data file is mine, and the schema speaks fluent perp. This article walks through what’s in it, how I think the weekly review loop should look, and why I’m giving the whole thing away on a domain you’re already on.

Try it: journal.basiscalc.xyz.

What a perp trader’s journal needs to record

The minimum useful trade entry, for a position that lived on a DEX perp, has more fields than a stock trader’s journal does:

• Pair and pool. BTC-USDC is not the same trade as ETH-USDC; the pool’s existing skew determined your borrow rate.
• Side, entry, exit, size, leverage. Standard.
• Initial liquidation price — not just the static formula but the value the venue UI showed at fill time, because that captures pool state. (See the calculators on this site for the math: Hyperliquid / GMX v2.)
• Stop-loss price and the implied stop distance. R-multiple is computed from this, and “where I told myself I’d cut” is the only honest reference for whether I held discipline.
• Realized PnL, gross. Plus a separate field for fees + funding paid over the hold. On a 5-day GMX long against skewed pool you can pay 1–2% of size in borrow alone; if that’s lumped into “PnL” you’ll never see what’s eating the strategy.
• Strategy tag. Mean-revert, breakout, news, hedge — pick a fixed vocabulary, never free-text.
• Emotion / state. “Tilted from the prior loss” / “calm, planned” — three or four buckets is plenty. The single highest-information field for review.
• Policy violations. A separate table of “I broke my rule about X” linked to the trade. Without this, your journal slowly becomes a list of wins; with it, it shows you the discipline drift in numbers.

A SaaS journal aimed at US equities doesn’t have most of these. The ones that include futures usually still have a single “fees” column and no concept of pool skew or borrow rate. You can hack the description field, but then the dashboard can’t aggregate by it, and aggregation is the whole point of having a journal.

Why the established SaaS options miss

Several mainstream SaaS trading journals exist and they’re decent — for the audience they were built for. That audience is overwhelmingly US equities day traders and forex retail. The product surfaces, fields, and integrations all reflect that. Three structural mismatches with DeFi perps:

1. Field schema is fixed at the SaaS level. You can’t add borrow_fee_paid_usd as a real column — only as a free-text note. So aggregations (“avg borrow paid by pool”) don’t work. The reason the schema is fixed is the SaaS sells a single dashboard that has to ship for everyone; per-customer schema explodes the codebase.

2. Data lives on their server, behind their auth, under their TOS. That’s fine in normal times. It’s less fine when their pricing changes, when they add a feature you don’t want and remove one you used, or simply when you stop paying. Trade history is the slowest-decay asset a trader has — five years of journal entries is irreplaceable. SaaS lock-in on irreplaceable data is the wrong default.

3. No concept of venue-specific math. Liquidation price for a Binance ETHUSDT perp is computed differently than for a GMX v2 ETH/USD, which is computed differently than Hyperliquid’s hourly-funded version. The SaaS treats them all as “perp size + entry + exit,” missing the actual mechanics that make each venue distinct. (For Hyperliquid in particular, see the mechanics guide on this site.)

What I built

A self-contained trading-journal app — single Docker container, SQLite data file, no external accounts required.

• Stack. React 19 + Tailwind on the frontend, Express 5 + better-sqlite3 on the backend, served as a single Node process. Vite builds the SPA into the server’s static dir and Express serves both the SPA and the JSON API.
• Storage. SQLite at ./data/journal.db, with WAL mode and foreign keys. The whole database is one file you can copy to a USB stick. No cloud bucket, no other server.
• Auth. Optional. Single-user runs on the bare app with no auth; multi-user runs hit a session-cookie + bcrypt scheme that scoped every query to req.session.userId. Sessions live in the same SQLite file, 30-day cookie expiry.
• Schema. Trades, weekly notes, monthly notes, currency pairs (with per-user spread costs), policies, policy-violation join records. All in one DB so JOIN queries are cheap.
• Calculations. Pure functions in lib/calc.js: per-trade R-multiple including spread cost and funding cost as a deduction from gross PnL; aggregated stats (win rate, profit factor, by-pair, by-strategy, by-emotion, by-day-of-week, by-timeframe). All client-side — the server just serves rows; the dashboard does math.
• Symbols. Out of the box: 11 forex pairs, 5 commodities (XAU, XAG, USOil, UKOil, NGAS), and an extensible “pairs” table where you add BTC-USDC-PERP-GMX or whatever you actually trade.

The repo is open source: github.com/liugangdao/journal ↗. Clone, audit, fork, self-host. See the about page for the maintainer’s wallets and Twitter.

A weekly review loop that actually sticks

Most journals get abandoned in three weeks because the recording is friction-heavy and the review never happens. Two-thirds of the value of a journal is the review, not the recording. Here’s the cadence that works for a DeFi perp trader putting on 5–20 trades a week — pick the rhythm that fits your volume.

At every fill (closing the trade): 60 seconds. Open the new-trade form, paste in entry/exit/size from the venue, set side and leverage. Most of the math autocomputes. Mark the strategy tag and emotion bucket — these are the inputs that pay you back later. If you broke a rule (size too big, no stop, revenge trade), tick the policy-violation checkbox. Don’t editorialize in the notes field; that’s for week-end.

Once a week (suggested: Monday morning before you open the venue): open the dashboard, look at exactly three numbers from the prior week:

• Win rate by strategy. If one strategy’s hit rate dropped below your floor, freeze it for the next week.
• Profit factor. If under 1.0, the strategy isn’t paying you for the risk; tighter sizing or fewer trades next week.
• Violations count. If above 2, write a note to yourself in the weekly-notes panel about which violation and what the trigger was. Don’t trade more until you’ve named the trigger.

Once a month: scroll the monthly-notes panel. The themes that survived re-reading get promoted to your “policies” list — a written rule that the policy-violation tracker now enforces by reminder. Themes that didn’t survive get dropped; over-rule-making is its own problem.

The journal supports all of this directly: weekly notes by YYYY-Www, monthly notes by YYYY-MM, policies as toggleable rules, and a violations-stats endpoint that aggregates rule-breaking over time. It’s the smallest set of features that makes the loop friction-free.

Why it’s free and how it stays that way

There’s no journal subscription. No ads. No “premium tier.” No data resale. Three reasons the economics work without one:

1. Marginal cost is near-zero. The whole stack is open source and runs on a $6/month VPS. Hosting hundreds of users on one box is fine; thousands need a slightly bigger box.
2. basiscalc covers it. Affiliate commissions from the GMX referral code on the GMX calculator and (eventually) Hyperliquid pay for the infrastructure. The calculators monetize the funnel; the journal doesn’t have to.
3. Self-host as escape valve. If you don’t trust hosted-by-anyone-not-you with your trade history, fork the repo and run it locally. That option is real, not theatrical, because the entire stack fits in one Dockerfile.

There’s no commercial SaaS plan because adding one would mean prioritizing features that drive churn-resistant subscriptions over features that make the journal genuinely useful, and that drift is exactly why the existing SaaS journals don’t fit DeFi traders in the first place.

Who this is for (and isn’t)

It’s for you if:

• You trade DEX perps (GMX v2, Hyperliquid, dYdX, whichever) and want fields that name what you actually pay
• You want your trade book stored in a file you control, not in someone else’s database
• You’re OK with a web app you log into yourself; you don’t need broker auto-sync

It’s not for you if:

• You only trade US equities and want auto-sync from Interactive Brokers — Tradervue/Edgewonk/TraderSync target this exactly, use one of them
• You need team collaboration (multiple traders, manager dashboards) — single-user model only
• You want mobile-native — there’s a PWA, but it’s a wrapped web app, not a native app

Start here

• Open the journal and try it in sample mode (no signup; the demo data shows what the dashboard looks like with ~50 trades)
• Sign up if you want to keep your own trades — single-user creation is one form, no email confirmation
• If you came for the math first, the Hyperliquid and GMX v2 liquidation calculators on this site work standalone — bookmark them next to your venue tab

Most of the work in becoming a profitable perp trader is the review loop, not any individual trade. The journal exists to make that loop the path of least resistance. Two weeks of consistent recording will tell you something about your edge that no amount of post-hoc rationalization will.

---

Built and maintained by lz. About · Changelog · Trading Journal ↗