Glossary

Proof of Trade — On-Chain Reconciliation as a Verification Primitive

Proof of trade is the property of a trade history whose existence can be confirmed against an independent on-chain or signed-message record. Used heavily in prediction markets and DeFi venues.

By NakedPnL Research·May 9, 2026·5 min read

TL;DR

Proof of trade is a verification surface in which the existence and outcome of a trade can be reconciled against an independent on-chain record or cryptographically signed message.
It is most useful where the primary venue is decentralised or where on-chain settlement provides a parallel record that the venue cannot edit retroactively.
On NakedPnL, Polymarket positions are reconciled against the Polymarket subgraph, giving every Polymarket NAV figure a parallel on-chain anchor.

Definition

Proof of trade is a verification surface in which a trade's existence, fill price, size, and outcome can be confirmed against an independent record outside the venue itself — typically an on-chain transaction, a subgraph index of on-chain events, or a cryptographically signed message that the venue cannot retroactively edit. The label is meaningful only when the parallel record is genuinely independent of the venue's mutable database, which is why proof of trade applies most cleanly to decentralised exchanges, prediction markets that settle on-chain, and venues that publish signed message logs.

Why centralised venue API responses are not, on their own, proof of trade

When a centralised exchange returns a fill record from its API, the response is a database query against the exchange's own database. The trader has not lied — but the exchange could in principle edit the underlying row before responding to a future query. The defence on a centralised venue is procedural: read-only API key issuance, snapshot canonicalisation, SHA-256 chain hashing, and external timestamp anchoring. Proof of trade adds a parallel surface: a record that exists outside the exchange's database in a form the exchange cannot rewrite.

On-chain reconciliation in practice

A practical proof-of-trade workflow uses the venue's API as the primary source and an on-chain subgraph or event log as the cross-check. NakedPnL's Polymarket integration is the canonical example: the REST API returns a position list and balance figure for the connected wallet, and the Polymarket subgraph returns the same positions reconstructed from on-chain CTF (Conditional Token Framework) events. The reconciler in `lib/venues/polymarket/reconcile.ts` compares the two records position-by-position and flags any divergence. Convergence between the API and the subgraph means the published NAV figure is supported by a record the venue cannot retroactively rewrite without leaving an on-chain trail.

Where proof of trade applies cleanly

Polymarket and other on-chain prediction markets with public subgraph coverage.
Decentralised perpetual exchanges that publish on-chain settlement (Hyperliquid, dYdX v4, GMX, Aevo on settlement events).
Token-level wallet activity reconcilable against block explorers.
Any venue that exposes signed message logs the trader can independently verify against the venue's signing key.

Where proof of trade does not directly apply

Centralised spot and perp exchanges (Binance, Bybit, OKX) — fills exist only in the exchange's database. NakedPnL falls back to read-only API plus chain hashing plus OpenTimestamps for these.
Traditional brokers (IBKR via Flex Web Service) — primary records are regulator-supervised statements, not on-chain events.
Self-reported transaction logs without venue corroboration — these are claims, not proofs.

How NakedPnL combines proof of trade with chain hashing

For Polymarket positions, NakedPnL uses a layered surface. The venue API response is hashed and chained the same way as any other venue snapshot (see the hash chain glossary entry). The same daily NAV is independently reconstructed from the Polymarket subgraph and compared. The daily Merkle root that goes into OpenTimestamps includes the chain head; the on-chain subgraph itself is independent of NakedPnL and can be queried by anyone. A reviewer can therefore confirm three things: that the chain has not been retroactively edited, that the daily NAV has an external Bitcoin timestamp, and that the underlying positions match what the on-chain CTF events show.

Hash chain — the data structure that makes NAV history append-only.
Canonical JSON — the byte-stable serialisation that makes content hashes deterministic.
OpenTimestamps — the Bitcoin anchor for the daily Merkle root.
Verified track record — the four properties a trade history needs to stand up to outside review.

Frequently asked questions

Is proof of trade the same as proof of work or proof of stake?

No. Proof of work and proof of stake are consensus mechanisms used to secure blockchains. Proof of trade is a verification surface for individual trade activity, where the existence of a trade can be confirmed against an independent record. The terms share the prefix 'proof of' but operate at completely different layers.

Does proof of trade require the venue to be on-chain?

Cleanly applied, yes — the parallel record needs to be outside the venue's mutable database. Centralised venues without an on-chain settlement layer fall back to procedural defences (chain hashing, external timestamp anchoring) rather than direct proof of trade. The two approaches are complementary, not substitutes.

Can a centralised exchange ever offer proof of trade?

In principle, by publishing signed message logs that include trade fills with timestamps, signed by a key the exchange commits to publicly. A handful of CEXes have experimented with this (proof-of-reserves attestations are the closest production analogue). Until it becomes standard, NakedPnL treats centralised venues with the procedural verification surface and reserves proof of trade for venues with on-chain settlement.

Is the Polymarket subgraph good enough as the parallel record?

Yes for the verification question NakedPnL asks. The Polymarket subgraph is hosted on the Graph network and indexes on-chain CTF events; the underlying events are anchored on Polygon, not on the subgraph operator. A reviewer who distrusts the subgraph can reconstruct the same position set from raw on-chain events, which is slower but produces the same conclusion.

Does proof of trade work for every Polymarket position size?

Yes. The on-chain CTF event log records every position regardless of size; reconciliation runs at the position level, not at an aggregate threshold. Small positions show up in the subgraph the same as large ones.

References