Verified Track Record — Definition, Standards, and How It Differs from a Claimed One
A verified track record is a performance history a third party can re-derive from primary venue records. Definition, the verification surface that makes it stand up to due diligence, and the failure modes of self-reported records.
- A verified track record is a performance history that a third party can re-derive from primary records — typically venue API responses or prime-broker statements — without trusting the trader.
- Verification implies four properties: an independent data source, a deterministic computation, an append-only history, and a published methodology.
- Self-reported screenshots, broker PDFs, and venue-rendered leaderboards are claimed track records, not verified ones.
Definition
A verified track record is a record of investment performance whose figures can be re-derived from primary records by an independent third party, with a documented methodology, on a chain of historical entries that cannot be retroactively edited. The label is meaningful only when each of those four properties holds. A track record that depends on the trader's word, on a venue's curated rendering, or on a methodology that is not openly documented is, at best, claimed.
The four properties
- Independent primary data — performance is computed from records produced by the venue or broker, not from numbers self-reported by the trader.
- Deterministic computation — given the same primary data, any reviewer running the published methodology produces the same figure.
- Append-only history — historical entries are not editable; if a row is wrong, a new corrective entry is added with both visible.
- Published methodology — the calculation is openly documented, including the cash-flow handling, the snapshot cadence, and the precision discipline used.
Why each property matters
Independence of the data source eliminates the most common failure mode: a trader presenting numbers that no one outside the trader has access to. A read-only API key from Binance, IBKR, or any supported venue lets a verifier pull NAV from the venue itself. Deterministic computation means a reviewer can run the same algorithm and re-derive the figure to the precision the original engine used. Append-only history removes the temptation to retroactively smooth bad days. Published methodology lets a reviewer judge whether the method is appropriate for the question being asked — a TWR figure is comparable across managers in a way that money-weighted return is not, and the methodology document is what tells you which is being shown.
What a verified track record is not
- A screenshot of an exchange dashboard. The image cannot be re-derived; it is a moment-in-time projection by the venue.
- A broker PDF statement on its own. The document is primary evidence but the trader can choose which periods to disclose; without an append-only chain it is a curated subset.
- A self-reported P&L spreadsheet. The data is the trader's claim; there is no independent source.
- A venue-rendered leaderboard ROI. The number is operator-controlled and the underlying methodology is rarely fully documented.
- A backtested or paper-traded result. No real capital was at risk; nothing was 'tracked' in the trading-history sense.
How NakedPnL implements verification
NakedPnL is built around the four properties as design constraints. Read-only API keys provide the independent primary data. The TWR engine in lib/calculation/twr-engine.ts uses Decimal.js precision and GIPS-recognised geometric chain-linking — the algorithm is openly documented and reproducible from the canonicalised raw venue responses. Every NavSnapshot is hashed with SHA-256 and chained header-by-header to the previous day; the daily Merkle root of all chain heads is committed to Bitcoin via OpenTimestamps. The verification methodology lives at /docs/verification with reference Python and JavaScript snippets so any reviewer can re-derive the chain head and the published TWR without trusting NakedPnL.
Related terms
- Time-weighted return (TWR) — the GIPS-required metric for performance reporting.
- Hash chain — the data structure that makes the historical record append-only.
- OpenTimestamps — the Bitcoin-anchoring protocol that lets anyone confirm the publication date of a chain head.
- Net asset value (NAV) — the per-day primary data point from which TWR is derived.