Trading journal: capture the decision before the outcome can rewrite it

The short answer

A trading journal joins four records: the pre-trade decision, the intended execution, the actual onchain events, and the later review. Each needs its own timestamp. If the thesis and invalidation are written only after the exit, the record cannot show what governed the original decision.

CME Group's trade-log guidance emphasizes recording why a trade was made, targets, entry and exit, time, drawdowns, and conclusions. Onchain trading adds mints, pools, routes, wallet roles, signatures, transaction state, token balance deltas, and costs that may not appear in an interface's P&L card.

Start with the exact economic object

Record chain, mint or contract, token program, pair and quote asset, pool or curve, launch or migration state, and the source that connected the token to its claimed identity. Tickers, names, and images are search labels—not unique identifiers.

Assign wallet roles such as research, burner, execution, treasury, or destination without exposing secrets. If several wallets participate in one economic trade, give the trade one parent ID and list every related address and transfer so the position cannot disappear between accounts.

Write the decision before signing

Save the setup tag and version, thesis, direct evidence, tool-derived claims, unresolved questions, expected holding window, outcome branches and probabilities, invalidation, entry conditions, intended size, maximum loss, route, slippage, planned exit, and reasons to skip. Timestamp the completed record before the first transaction is signed.

Distinguish required fields from optional notes. A compact form completed every time creates better comparison than an elaborate narrative filled only for the most memorable trades. Use “unknown” rather than converting an absent fact into a confident guess.

Preserve execution as a sequence

Store quote time, quote input and output, route, pools, price impact, slippage or minimum output, priority settings, platform fee, expected token fees, wallet, submitted signature, status, confirmation time, actual balance deltas, and any retry or replacement. One decision can produce several transactions and one routed transaction can contain several swap legs.

Record changes as appended events instead of overwriting the original plan. If size, route, invalidation, target, or thesis changes, preserve who changed it, when, why, what new evidence arrived, and whether the rules permitted the change.

Close the economic position, not only the row

Reconcile all wallets, token accounts, open orders, claims, LP positions, bridge transfers, pending transactions, and withheld or residual balances. Record gross proceeds, realized and unrealized position, every cost, duration, maximum favorable and adverse movement under a defined price source, and the remaining exit capacity.

Mark the outcome branch from the pre-trade plan. If reality produced an unmodeled branch, preserve it as such rather than forcing it into “win” or “loss.” The new branch may be the most useful information in the record.

Use separate tags for separate failure layers

• Strategy outcome: whether the defined setup produced the modeled market outcome across its appropriate sample.
• Decision process: whether required evidence, sizing, risk, and approval gates were satisfied before entry.
• Execution quality: quote freshness, route, fill, slippage, fees, failures, and operational handling.
• Rule adherence: overrides, late entries, moved invalidation, session breaches, revenge behavior, or unauthorized strategy changes.
• Data quality: missing signatures, uncertain labels, stale prices, conflicting indexers, and unverified assumptions.

Keep final P&L beside these tags, not above them. The expected-value guide explains why decision quality and one realized outcome require separate review.

Record skipped and missed opportunities carefully

A no-trade decision is part of the strategy sample when the setup was evaluated and rejected under a documented rule. Save the candidate, timestamp, rejection reason, and information available then. Do not add every token that later pumped; that creates a hindsight-selected comparison set.

For simulated or counterfactual trades, use quotes available at the decision time and model execution costs and liquidity. Label them separately from live fills. Never let a hypothetical best exit compete with an actual executable result.

Version rules and derived metrics

Give each strategy, checklist, and sizing rule an effective date and version. A trade is evaluated against the version active when it began. Later edits should not make earlier decisions appear compliant or noncompliant under rules they never faced.

Define formulas for cost, realized P&L, marked value, R multiple, drawdown, win, and process score. When the formula changes, retain the old result and compute the new one with a version label so historical comparisons remain auditable.

Protect the journal as sensitive operational data

Never store seed phrases, private keys, raw recovery material, or unredacted authentication secrets. Limit access to address maps, balances, planned trades, screenshots, exchange identifiers, and personal notes. Use the minimum retention and sharing needed for the review purpose.

Back up records according to a tested recovery plan and preserve exportable data. A journal locked inside one service is not a durable evidence system if access, schema, or the service itself can disappear.

A journal-entry workflow

1. Create the parent record. Assign trade and session IDs, asset identity, wallets, setup version, and decision timestamp.
2. Freeze the plan. Save thesis, evidence, unknowns, outcome tree, size, risk, route, invalidation, exit, and skip conditions before signing.
3. Append execution events. Capture quotes, settings, signatures, status, balance deltas, retries, and every plan change.
4. Reconcile the position. Join wallets and transactions, include costs, value residuals, and resolve pending state.
5. Classify independently. Tag strategy, process, execution, rules, data quality, and P&L without allowing one to overwrite another.
6. Queue review. Add the record to a comparable strategy cohort and preserve changes as new rule versions.

Primary and official sources