How to Independently Verify a Public Trader Track Record

A 10-minute, code-driven workflow for an allocator, journalist, or regulator to re-verify a NakedPnL trader chain end-to-end using only public data.

Most published trader track records are decorative. A screenshot is a JPEG. A spreadsheet of trades is a spreadsheet. A sentence on a website that says "audited by [name]" is a sentence on a website. None of these can be re-verified by a counterparty without trusting the publisher — which means they cannot survive serious due diligence.

NakedPnL is built on the premise that a trader's track record should be re-verifiable by anyone, using only public data and standard cryptographic tools, in a fixed amount of time. This article walks an allocator, a journalist, or a regulator through that workflow end-to-end. The whole thing takes about 10 minutes for a 12-month chain, no privileged access, no NakedPnL software dependencies.

The four levels of trader verification

Before walking through the verifier, it's useful to fix vocabulary. Verification of a self-published track record falls onto a strict ladder. Each rung makes a fundamentally different trust claim:

NakedPnL targets level 4 by default. Connecting an exchange account is a level 3 operation; what makes it level 4 is the daily SHA-256 chain, the Merkle root anchored to Bitcoin via OpenTimestamps, and the public read API that lets anyone re-verify the chain without trusting NakedPnL's database.

Why level 4 needs three independent layers

The verification stack at level 4 is composable. Each layer is independently checkable, with strictly different trust assumptions:

1. Per-trader hash chain (lib/calculation/audit-hash.ts): every NavSnapshot stores contentHash = SHA-256(canonicalize(rawResponse)) and chainHash = SHA-256(previousChainHash + contentHash). Detects in-place modification, deletion, or reordering of any record. Verifiable in any browser.
2. Daily Merkle root (lib/ots/merkle.ts): a deterministic binary Merkle tree built from every active entity's chain head, sorted by entityId + chainType. Compresses the entire registry into one 32-byte digest each day.
3. OpenTimestamps Bitcoin anchor (lib/ots/anchor.ts): the daily Merkle root is submitted to four independent OTS calendar servers, which batch and commit to a Bitcoin transaction. Once confirmed, no actor can rewrite the historical commitment without rewriting Bitcoin's proof-of-work history.

The point of layering is that a verifier can stop wherever their trust budget runs out. Casual readers can re-verify the chain in their browser at /verify/chain/[handle] without thinking about Bitcoin. A serious allocator can verify the Bitcoin anchor against their own node. A regulator running a forensic timeline can do both — and additionally cross-reference timing against published Merkle roots and trader profile snapshots from external archives (Wayback Machine, search engine caches).

The 10-minute end-to-end verification workflow

What follows is the actual procedure. Pick any verified trader on NakedPnL. Replace alice with the @handle from their public profile URL.

Step 1 — Fetch the chain

The public read API exposes every chained NavSnapshot for a given handle. Each row contains the snapshotDate, the canonical raw response (the bytes the venue actually returned), the contentHash, the chainHash, and the previousChainHash. This is the entire input the verifier needs.

# Replace alice with the actual handle.
curl -s https://nakedpnl.com/api/chain/alice > chain.json

# Sanity check: how many snapshots, and what is the chain head?
jq '.snapshots | length' chain.json
jq '.chainHead' chain.json
# 365
# "00ff11ee2233...c4d5e6f7"

Step 2 — Replay the hash chain locally

Walk the snapshots forward from the genesis seed. For every row, recompute contentHash from the canonical raw response, then recompute chainHash by combining the prior chainHash with the current contentHash. The first index where the recomputed chainHash diverges from the stored chainHash is where the chain breaks. If it never diverges, the chain is intact.

async function sha256Hex(input) {
  const bytes = new TextEncoder().encode(input);
  const digest = await crypto.subtle.digest("SHA-256", bytes);
  return Array.from(new Uint8Array(digest))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
}

function canonicalize(value) {
  return JSON.stringify(value, (_k, v) => {
    if (v && typeof v === "object" && !Array.isArray(v)) {
      const sorted = {};
      for (const k of Object.keys(v).sort()) sorted[k] = v[k];
      return sorted;
    }
    return v;
  });
}

const data = await fetch("/api/chain/alice").then((r) => r.json());
let prev = "genesis";
for (let i = 0; i < data.snapshots.length; i++) {
  const row = data.snapshots[i];
  const ch = await sha256Hex(canonicalize(row.rawResponse));
  if (ch !== row.contentHash) throw new Error(`contentHash mismatch at ${i}`);
  const linked = await sha256Hex(prev + ch);
  if (linked !== row.chainHash) throw new Error(`chainHash mismatch at ${i}`);
  prev = row.chainHash;
}
console.log("Chain valid. Head:", prev);

This is exactly what /verify/chain/[handle] does behind the scenes. The page only emits a green check after every snapshot validates and the final prev value matches the chainHead reported on the trader profile. Run it in the browser console with no third-party JavaScript dependencies — the Web Crypto API ships with every modern browser.

Step 3 — Verify the daily Merkle anchor

The chain replay establishes that the snapshots have not been retroactively altered, but only relative to whatever chain head you are currently observing. To upgrade that to an absolute claim — that the snapshots existed at a specific moment in the past — you need the OpenTimestamps anchor.

Pick a date during the trader's history. Fetch the AnchorRecord for that date. The response includes the daily Merkle root, the calendar URL, the OTS proof bytes, and (if the proof is UPGRADED) the Bitcoin block height and transaction ID.

# 1. Fetch the anchor record for a specific historical date.
curl -s https://nakedpnl.com/api/verify/2026-05-06 > anchor.json

# 2. Confirm the proof is UPGRADED (i.e. confirmed on Bitcoin).
jq -r .status anchor.json
# UPGRADED

# 3. Extract the Merkle root and the proof bytes.
jq -r .merkleRoot anchor.json | xxd -r -p > root.bin
jq -r .proofBase64 anchor.json | base64 -d > anchor.ots

# 4. Verify against your own Bitcoin node (or a trusted block-header source).
ots --bitcoin-node http://user:pass@127.0.0.1:8332 verify anchor.ots root.bin
# Got 1 attestation(s) from https://a.pool.opentimestamps.org
# Success! Bitcoin block 901234 attests existence as of 2026-05-06 00:08:13 UTC

The output proves the Merkle root existed at the time the referenced Bitcoin block was mined. That fact, combined with the deterministic Merkle tree construction, means every chain head committed in the tree existed at or before that block time — including the chain head of the trader you are verifying.

Step 4 — Prove the trader's chain head was in the tree

The final step ties the per-trader chain replay (step 2) to the Bitcoin-anchored Merkle root (step 3). Request a Merkle inclusion proof from the public API: given the trader's handle and the anchor date, NakedPnL returns the path of sibling hashes from their leaf to the root. Verify the proof locally — no NakedPnL trust required at this stage.

# 1. Fetch the inclusion proof for alice on the anchor date.
curl -s "https://nakedpnl.com/api/verify/2026-05-06/proof?handle=alice" > proof.json

# 2. Reconstruct alice's leaf hash.
node -e '
  const c = require("crypto");
  const p = require("./proof.json");
  const leafInput = `${p.entityId}|${p.chainType}|${p.chainHash}`;
  const leaf = c.createHash("sha256").update(leafInput).digest("hex");
  let cur = leaf;
  for (const step of p.path) {
    const concat = step.position === "left" ? step.hash + cur : cur + step.hash;
    cur = c.createHash("sha256").update(concat).digest("hex");
  }
  console.log(cur === p.expectedRoot ? "INCLUDED" : "NOT INCLUDED");
'
# INCLUDED

If the script prints INCLUDED, you have completed the four-step end-to-end verification: alice's chain replays cleanly, alice's chain head was a leaf in the daily Merkle tree, the Merkle root was committed to a Bitcoin transaction at a specific block, and the Bitcoin transaction is buried under the rest of the chain.

Reading a NakedPnL trader page like a verifier

Every public trader profile and badge surfaces the chain head and the latest Bitcoin-anchored Merkle root publicly. The /docs/verification page on the site provides language-specific code snippets (Python and JavaScript) that mirror the workflow above. A few practical notes when reading a profile through a verifier's lens:

• Chain length and continuity matter. A clean chain that started 14 days ago is not a 14-month track record. Look at the snapshot count and the date range, not just the chain head.
• Chain breaks are visible. If the public verifier reports a mismatch at index k, the trader profile flags the chain as broken and surfaces the date. NakedPnL does not silently re-anchor.
• Multi-venue traders have multiple chains. A trader who has connected Binance and Bybit will have two independent chains, each with its own chain head. Both should be re-verified separately.
• On-chain reconciliation is available where applicable. For Polymarket positions, NakedPnL cross-references the venue REST API against the Polymarket subgraph (lib/venues/polymarket/reconcile.ts). Discrepancies surface on the on-chain tab of the trader profile.

When a chain is broken

Chain breaks are rare and operationally significant. There are exactly three legitimate causes, and the trader page surfaces which one applies:

• API key rotation: a trader rotated their venue API key without re-binding the connection. The new key produces snapshots that cannot be linked to the prior chain. NakedPnL flags the prior chain as historic and starts a new chain from genesis. Both chains remain independently verifiable.
• Venue API schema change: an exchange materially changed the response shape (rare). Pre-change and post-change canonical responses no longer match. Same flagging behaviour as a key rotation.
• Database incident: a row was lost or corrupted. This has happened zero times on NakedPnL since launch, and an incident report would be published on the public ops page if it ever did.

What this workflow is not

It is worth being explicit about scope. This workflow proves that NakedPnL has not retroactively modified the published record. It does not prove:

• That the venue itself reported true balances. If Binance, Bybit, OKX, or IBKR fabricated an API response, the chain faithfully fingerprints a fabrication.
• That the trader does not run other accounts elsewhere with offsetting losses. The chain is per-account, not per-person.
• That the trader's identity has been verified. NakedPnL offers optional identity attestation as a separate layer; it is independent from the chain.
• That past performance predicts future returns. Verification answers "did this happen?". It does not answer "what is this trader good for?".

An allocator should treat the verified chain as one of several due-diligence inputs alongside venue cross-checks, identity attestation, capacity analysis, strategy interview, and capital-account verification. The chain raises the floor of what is provable. It does not replace the rest of the diligence stack.