Your trade log can prove the numbers, not the reasoning

A journal you can hand to a stranger changes one specific thing about trading review: the numbers stop being yours to edit. That is worth having. It is also much smaller than what journal-keeping is sold as, and the gap between the two is where retail traders get hurt.

The honest version of the pitch splits in half. Onchain records settle what happened and what it cost. Nothing onchain settles why. Every serious journal needs both halves, and only one of them can be audited by anyone.

What a third party can re-derive today

Both major onchain perp venues expose your fill history over unauthenticated endpoints. No key, no account, no permission. dYdX describes its Indexer as a read-only service serving off-chain data over REST and Websockets, and states it is completely open source and can be run by anyone. Hyperliquid's info endpoint needs nothing but an address in the request body.

A re-derivable journal differs from a spreadsheet in three ways, and each is mechanical rather than aspirational:

The record carries a cryptographic identifier. Every Hyperliquid fill returns a hash. Ethereum.org's transaction documentation explains that a transaction signature is the identifier of the sender and proves the transaction could only have come from that sender and was not sent fraudulently. A spreadsheet cell has no third party who can say "this row came from me."

Anyone can recompute your total. Because the fill list is a projection of state rather than your assertion about it, a reviewer can pull your own numbers and check your arithmetic. That is the entire value proposition, and it is real.

Reorg risk is bounded and priced. A finalized block, per Ethereum.org, could only ever be changed by a network-level attack costing many billions of dollars. "Can I trust this row" becomes a question with a number attached instead of a feeling.

A worked example, pulled live

To make this concrete I queried the public APIs directly, with no authentication, and recomputed the totals from the raw responses. The subject below is a public address used only to demonstrate the mechanics.

One call to POST https://api.hyperliquid.xyz/info with {"type":"userFills","user":"0x5078…Db6"} returned HTTP 200 and 722,191 bytes containing 2,000 fills. Summing the response fields:

• Fees: 5,158.10 USDC (sum of fee across 2,000 records)
• `closedPnl`: −64,711.53 USDC (sum across the same 2,000 records)
• 617 fills carried a `liquidation` block, each with method: "market" and a markPx
• Zero fills carried a `builderFee` key at all, so a zero builder fee is genuinely absent rather than zero-valued
• 9 distinct instruments, from BTC and ETH to xyz:SP500 and two spot tickers
• Window covered: 2026-03-30 to 2026-09-04

Funding is a separate call. Over the 90 days ending 2026-09-04, userFunding returned HTTP 200 with 153 rows summing to −1,608.53 USDC, negative meaning paid out. Widen the window and the number moves: 180 days returned 198 rows and −2,880.76 USDC; 365 days returned 314 rows and −19,929.16 USDC. A funding total is a function of the window you pick, so any single headline figure needs its date range attached.

Three things fall out of that account that no self-report would have surfaced.

The liquidations are the uncomfortable one. 617 of 2,000 fills, about 31%, are marked as liquidation events. Whatever that trader's account of their month sounds like, the record contains a mechanical count of being liquidated repeatedly, visible without asking permission.

Fees are a third of the visible cost line and would be easy to omit. Fees plus the magnitude of realized PnL on the fill sample total 69,869.63 USDC, of which fees are 7.4%. A journal reporting only closedPnl would have shown −64,711.53 and made that share invisible.

Position state is reconstructable, not just prices. Each fill carries dir (Open Long, Close Long, Open Short, Close Short, Long > Short) and startPosition. In that live sample the distribution was 1,017 Open Short against 172 Open Long, with 727 Close Short and 78 Close Long. The distribution itself is a finding.

dYdX offers the same shape. GET /perpetualMarkets returned HTTP 200 with 296 markets, BTC-USD carrying oraclePrice 85,988.84234, volume24H 2,511,675.27, openInterest 194.2127, alongside per-tick and per-step sizing fields. Fill, funding, and PnL history sit behind /fills, /fundingPayments, and /historical-pnl, all unauthenticated but scoped per subaccount.

What the record cannot hold

These are the load-bearing limits. Each one changes what a journal can honestly claim.

There is no intent field, on either venue. Every field in the Hyperliquid fill object is price, size, side, fee, PnL, or time. dYdX's fill object carries clientMetadata and no rationale field. Nothing onchain records your thesis, your level, or the invalidation you had in mind. When a trade fails, the ledger can tell you the size of the loss and cannot tell you the reason.

There is no chart state. No schema on either venue has a screenshot field. What you can reconstruct is the price path around your fill, from candle data and order-book snapshots, retrieved after the fact. That is not the chart you saw, with your annotations, at the moment you clicked. Tools that build journals on top of these APIs reconstruct trade-level exports as one entry and one exit at reported average prices; their own documentation states plainly that P&L is preserved exactly but fill-level granularity is not. A journal showing one tidy entry and exit may be showing you a reconstruction rather than what happened.

The `closedPnl` formula is undocumented. Hyperliquid returns a per-fill closedPnl and I found no prose definition of how it is computed in the documentation I fetched. You are accepting the venue's number on its own authority.

Cost-basis method is your choice, and it changes the answer. dYdX returns totalPnl and netTransfers as separate fields, a different decomposition from Hyperliquid's per-fill figure. Third-party attribution layers add a third: Arkham's documentation states it uses as cost basis the value of holdings at time of initial transfer to the entity. Same address, different PnL, all three defensible. A journal that does not name its method is not reporting a number, it is reporting an opinion with a decimal point.

History is capped, not merely awkward. userFills returns at most the 2,000 most recent fills. The time-range variant exposes only the 10,000 most recent. A high-frequency account loses its earliest history from the API path, silently. The bulk archive offers no timeliness guarantee: Hyperliquid states historical data is uploaded approximately once a month, with no guarantee of timely updates and data possibly missing. Back up. Do not assume.

Do not join funding to fills on `hash`. In every one of the 153 funding rows I pulled live, hash was 0x0000…0000. Real fills carry real hashes. TWAP fills are documented as carrying a hash of 0 as well. Joining those tables on that key produces silent errors rather than an exception.

The agent-wallet trap is worse than an error message. The documentation is explicit that querying a master or sub-account requires the actual address of that account, and that a common pitfall is passing an agent wallet's address, which leads to an empty result. I confirmed how that reads in practice. On Hyperliquid, an address with no trading history returned HTTP 200 with [] for both userFills and userFunding. On dYdX, /fills, /fundingPayments, and /perpetualPositions all returned HTTP 200 with empty lists. So a wrong address is indistinguishable from a quiet trader, unless you check the endpoints that error out: dYdX's /historical-pnl and /pnl returned HTTP 404 with "No subaccount found with address… and subaccountNumber 0". Even sharper, 0xdeadbeef is not a valid address, and the indexer still answered HTTP 200 with {"fills": []}.

Spot and perp PnL are not additive. closedPnl appears on spot fills, and portfolio separates its buckets from the perp* buckets, so any total depends on which bucket you read.

Rate limits make archiving a paced job. Hyperliquid documents 1,200 aggregated weight per minute per IP, with user-specific requests adding weight per items returned. A few years of fills are a scheduled script with sleeps, not a single click.

The price of a public ledger

A spreadsheet is editable and private. An onchain journal is append-only and queryable by anyone holding your address. Ethereum.org's own account documentation motivates using multiple accounts partly so that your assets and value cannot be easily tracked. Verifiability and privacy trade directly against each other.

Publishing your journal publishes your positions, your size, and your timing. That is a real cost, paid for a real benefit, and any article that sells the second without naming the first is selling you something.

Measurement honesty, not process honesty

Here is the part that matters most, and the part most product copy omits.

Verifiable data fixes measurement honesty. It does not fix process honesty, and it can quietly inflate your confidence in yourself. A journal that cleanly reconstructs 2,000 fills is not a strategy. A perfect record of what you paid does not tell you why you paid it.

It can also make a bad process look rigorous. Every figure is recomputable, so every figure looks adjudicated. But the choices upstream of those figures, which instrument, which position size, which entry, were never recorded onchain and never will be. One note in a well-designed journal tool is deliberately outside the verified layer, user-typed and unauditable, because that is where the reasoning lives.

If you keep one, keep both: the address, so the numbers are checked, and the written reason, so the numbers get interpreted. Use the first to stop arguing with your own arithmetic. Use the second, and only the second, to decide whether to take the next trade.

Risk note: nothing here is financial advice, and none of it has been validated as a strategy. Onchain history describes what happened to one public account at one point in time and is not evidence of any future result. Reconstructing a journal does not tell you whether the trading was sound, and the `closedPnl` figures quoted are the venue's own computation under an undocumented formula. Endpoints, field sets, rate limits, and archive availability change without notice; verify against the current documentation before relying on any number in this article.

Risk note: cryptocurrency trading, leveraged perpetual futures, and automated algorithmic strategies carry significant risk of rapid and total financial loss. Never risk funds you cannot afford to lose completely. Data recovered from a public chain or indexer describes what happened, not whether the decision was sound, and order-flow protections reduce extraction without removing it. Nothing in this article is investment advice, a recommendation, or an offer to sell any product.