Building a Trade Journal: The Fields That Make Review Possible

A journal is not a diary of how trades felt. It is a record of the inputs you observed before the outcome was known, stored as raw numbers, so that a later review can ask whether your process did what you thought it did. Everything recorded after the outcome is contaminated.

Situation
You have taken enough trades that memory is no longer a record
Mechanism
Inputs recorded before the outcome are the only unbiased evidence available
Rule
Every position is written at entry, in fixed fields, with raw numbers
Cost
A minute per trade, permanently, including on trades you skip
Invalidation
The fields stop being filled honestly, at which point the record is worse than none

Record the inputs before the outcome exists: the rule you invoked, the trigger values you saw, the pool depth and its source, your size as a share of exit-side depth, the invalidation sentence and the exit design. Add the outcome later, in a separate column. That ordering is the entire discipline, and it is what makes a later review capable of saying anything true.

Why memory is not a record

Ask a trader why they entered a position from three weeks ago and you will get a coherent, confident, reconstructed answer. It will be built backwards from the outcome, because that is how recall works, and it will feel exactly as reliable as an accurate memory feels. There is no internal signal that distinguishes the two.

This is not a character flaw and cannot be fixed with effort. It is why the record has to be made at the moment of decision, when the outcome is genuinely unknown, and why entries added afterwards are worth less than nothing: they contaminate the dataset while looking like data.

The second failure of memory is selection. You remember the trades that were dramatic and forget the ones that were routine, so a mental review is a review of your most emotionally charged trades. Since the routine ones are the bulk of any process, the mental review describes a distribution you did not actually trade.

A journal fixes both problems in the same way: fixed fields, filled in before the outcome, for every position and every refusal. Not because writing things down is virtuous, but because the alternative is a dataset assembled by your own biases and then treated as evidence.

The journal schema

A minimal trade journal schema for Solana positions, showing when each field is recorded, what it is used for in review, and what goes wrong when it is missing.
FieldRecordedUsed in review to answerIf missing
Situation classAt entryWhich situations you actually engage with, versus which you think you doTrades cannot be grouped, so nothing can be compared
Rule invokedAt entryWhether entries were rule-based or discretionaryDiscretionary trades get credited to rules that were not in force
Trigger valuesAt entryWhether the trigger was genuinely presentCompliance cannot be checked at all
Depth and sourceAt entryWhether sizing arithmetic used a real denominatorEvery size figure becomes uninterpretable
Size as share of exit depthAt entryHow large you actually trade, as opposed to how large you believe you tradeThe most important distribution in the journal is unavailable
Invalidation sentenceAt entryWhether the exit reason was defined in advanceEvery exit looks intentional in hindsight
Exit designAt entryWhether the plan was chosen or improvisedLadders and single exits become indistinguishable in review
Unverified itemsAt entryHow often you traded on incomplete checksIncomplete checks disappear from the record entirely
Execution costsAt closeWhat the process costs before any market outcomeFee-heavy plans look free
OutcomeAt closeVery little on its own; it is context, not evidenceNothing important, which surprises people

Ten fields, eight of them filled before the outcome exists. The asymmetry is deliberate. A journal weighted toward outcomes produces reviews about luck; a journal weighted toward inputs produces reviews about behaviour, and behaviour is the only part you can change next week.

A plain column list you can paste

The schema above as a flat header row, suitable for a spreadsheet. Keep the order, because a fixed order is what makes entry fast enough to survive a busy week.

date_utc, pair, mint, venue, situation_class, rule_name, trigger_values, depth_quote_side, depth_source, size_value, size_pct_exit_depth, invalidation, check_interval, exit_design, unverified, fees_paid, realised_impact, exit_reason, outcome, note.

Two of these deserve comment. The field exit_reason is not the same as outcome: it records whether you left because the invalidation fired, because the ladder completed, because the clock expired, or because you changed your mind. That single column is the one that reveals the gap between a written method and an actual one.

The field realised_impact is the difference between the quote you saw and the price you received, recorded per trade. It is tedious and it is the only way to find out whether your sizing arithmetic corresponds to reality. If your computed impact says one percent and your realised impact is repeatedly three, something in your depth reading is wrong and no amount of rule refinement will fix it.

One entry, filled in

Illustrative entry

Invented values, describing no real trade, shown to make the schema concrete. Situation class: post-migration pool. Rule invoked: post-migration depth entry. Trigger values: destination pool identified, owning program recorded, quote-side reserves 240 SOL read from the pool account, routed and direct quotes within the limit set in advance.

Size: 4.8 SOL, which is two percent of exit-side depth. Invalidation: quote-side reserves below 150 SOL as read from the pool account, closing on that reading. Check interval: two hours. Exit design: ladder in three tranches, void condition a halving of quote-side reserves, fallback a single exit at the permitted size. Unverified: who holds the liquidity position, could not be established.

Everything above was written before the position existed, and the last line is the one that changes the trade. An unverified item is not a blank; it is a recorded gap that should have reduced the size, and in review this entry will show up in the group of trades taken with an outstanding check.

Two fields are added at close. Fees paid across all legs, and realised impact per tranche against the quote at the time. Then the outcome, in one word, in the last column where it belongs.

Written out, the entry takes under a minute because every field is a value rather than a sentence. The only field that requires composition is the invalidation, and by the time you have written a dozen of them the phrasing is close to mechanical.

The discipline being enforced here is subtle and worth naming. Filling this in at entry forces you to have already done the sizing arithmetic, already identified the venue, already chosen an exit design and already written the invalidation. A trader who cannot complete the row has discovered, in the safest possible way, that the trade was not ready.

Recording the trades you did not take

A journal containing only executed trades cannot evaluate a filter, because the entire effect of a filter is on the trades that never happened. If your rules refused eleven setups this week, those eleven are the evidence about whether the rules are calibrated, and they are invisible unless you write them down.

The entry can be short: date, pair, situation class, the rule that refused it, and one line on what you observed. Thirty seconds. The value appears at the end of a month, when you can look at the refusals as a group and ask whether they share a property that your rule is treating as disqualifying without good reason.

There is an uncomfortable second benefit. Refusal entries make it visible when you stop refusing. A week with zero declined setups is not a week of unusually good opportunities; it is a week in which the filter was not applied, and without the record that fact leaves no trace at all.

Recording costs properly

Costs are systematically underestimated because they arrive in pieces. There is the venue fee, the network fee, any priority fee paid to land a transaction, the realised price impact on entry and again on exit, and the cost of every leg in a split order. A ladder with six tranches pays several of these six times.

Recording them separately per trade turns a vague sense that fees are small into a number you can compare against your typical position size. In thin pairs the comparison is often unwelcome: the process cost of a small position can be a meaningful fraction of what the position could plausibly earn, which is an argument for fewer and larger trades within the depth limit rather than many small ones.

The same accounting applies on the other side of the market. Teams running activity budgets face the same question in a different currency, which is why Solana volume bot cost is discussed in terms of fee per swap and cost per unit of turnover rather than as a single headline price. Both sides are doing the same exercise: dividing a real cost by a real quantity instead of by an intention.

Note also what your fee record cannot capture. Time is a cost, attention is a cost, and the trades you missed while running a checklist are a cost. None of them belongs in a spreadsheet column, and all of them belong in the decision about how many positions you carry.

The weekly cadence

  1. Freeze the week. Stop adding entries for the period you are about to review, so the dataset is not moving while you read it.
  2. Check completeness before content. Count entries with missing required fields. That count is the first finding, and if it is high, nothing else in the review is trustworthy.
  3. Mark process compliance. For each entry, was the stated rule followed, yes or no, with outcomes ignored entirely at this stage.
  4. Group by rule. Collect entries under the rule invoked, with discretionary trades as their own group, and look at the size distribution within each.
  5. Read the refusals. Review declined setups as a block and ask whether the recorded reasons still read as sound a week later.
  6. Write one change, or none. At most one change to the rule set, with the specific entries that justify it. Recording that nothing changes is a valid and common result.

The constraint of one change per week is the part that does the work. Without it, review sessions become redesign sessions, and a rule set that changes weekly can never accumulate enough entries under any single version to be evaluated at all.

What a small sample can and cannot say

A journal of twenty or fifty trades can answer process questions with confidence. Did you follow your rules. How large do you actually trade relative to depth. How often did you enter with unverified items outstanding. How often did an exit happen for the reason you wrote down. These are questions about your behaviour and your own record is the complete dataset.

It cannot answer whether the rules work. That is a statistical question about a market, and it needs a sample size, a stable universe and a stationary environment, none of which this market provides. Anyone converting fifty memecoin trades into a claim about expected outcomes is producing a number with no support, and this desk publishes no such number for exactly that reason.

The honest middle position is that a journal improves the quality of your decisions and says nothing about your results. Reviewing tooling has the same limit: automated volume management and any other software can be judged on what it does and what it records, not on outcomes it cannot control. The distinction between process quality and results is not a technicality; it is the thing most trading content deliberately blurs.

How journals fail

They fail by growing. A schema that starts at ten fields becomes twenty-five, entry takes five minutes, and the journal is abandoned in a busy week and never resumed. Guard the field count; adding a column should require removing one.

They fail through retrospective editing. An entry improved after the outcome is known is no longer evidence, and once a few entries are edited the whole dataset is suspect. If a correction is genuinely necessary, add a dated note rather than changing the original line.

They fail through never being read. A year of diligent entries that nobody reviews is a filing habit. The weekly cadence exists to prevent this, and the review is the product; the entries are only the raw material.

And they fail through outcome contamination in the review itself. Reading a losing trade, it is nearly impossible not to mark the process as flawed, and reading a winning one, nearly impossible not to excuse a violation. Marking compliance before looking at outcomes, as a separate pass, is a crude fix and it is the one that works.

Questions the desk gets asked

What should a crypto trade journal record?

The inputs you observed before entry, as raw numbers: pool depth and its source, size as a share of exit-side depth, the rule invoked, the trigger values, the invalidation sentence, the exit design, the venue and the time. Outcomes are recorded too, but they are the least useful column, because they are the one thing you could not have known at the moment of decision.

Should you journal trades you did not take?

Yes, and this is the field most people omit. A record containing only executed trades cannot tell you anything about your filters, because the trades your rules refused are invisible. A one-line entry for a declined setup, with the reason, is what makes it possible to ask later whether a rule is refusing the right things.

How long should a journal entry take?

About a minute at entry if the fields are fixed and you are writing numbers rather than prose. If it takes longer, the schema is too elaborate and will be abandoned within a month. Simplifying the schema is a better response than resolving to try harder.

Is a spreadsheet enough?

A spreadsheet is usually the right tool, because the schema is small, the data is tabular and the review is a filter and a sort. Purpose-built software adds features that mostly matter at trade counts most individual traders do not reach. What matters is that the fields are fixed and that entries are made before outcomes are known.

How many trades before a review means anything?

Fewer than you would need for a statistical claim and more than most people wait. A review of twenty trades can honestly say whether you followed your own rules, which is a process question. It cannot say whether the rules work, which is a statistical question that a sample of that size cannot answer for any market.

Should the journal record how you felt?

One short field is defensible, recorded at entry rather than afterwards, because states like time pressure and frustration are real inputs to a decision. Anything longer becomes a diary, and a diary of a losing week is a document you will avoid reading, which defeats the purpose of keeping it.

What is the single most important field?

Size as a percentage of exit-side depth, recorded at entry. It is the field that connects every other part of the method, it is the one traders systematically misremember, and it is the one whose distribution over a month tells you the most about how you actually behave under pressure.

Filed in Playbooks by The Liquidity Tape Desk. Mechanisms on this page are described from protocol design and public documentation; every number in an example is labelled illustrative and describes no real trade. The standard the desk holds itself to is set out in how rules are written.