BTC-Trading-Since-2020: a public execution ledger of one BitMEX account

A trade record published before the outcome was known

The repository calls itself an open-intelligence experiment: a public, inspectable mirror of a real trading account since May 2020. The current build contains 43,258 orders and 173,577 balance-affecting execution records, plus the available order-lifecycle events.

The stated problem it addresses is that most public trading content is narrative without ledger truth. Screenshots and retrospective claims can be selected after the fact in a way that flatters the outcome. This repository publishes the actual execution ledger, wallet ledger, terminal snapshots and reconstruction anchors instead, so a reader can check the sequence rather than accept the summary.

The account is identified. The README names Paul Wei, with the handle `@coolish`, and links to the BitMEX Hall of Legends page, where BitMEX highlighted a 70x Bitcoin trading return over three years. The README is explicit that the deeper value is not that headline number but the timestamped archive covering multiple market cycles, including strong calls, reversals, drawdowns and recoveries.

One claim deserves emphasis because it is the methodological core. The README argues that much of the trail was public before the outcome was known, which makes it a record of decision-making under uncertainty rather than a curated victory lap. That is a stronger standard than most performance publishing, and it is also the reason the archive is worth keeping around after the account owner stopped it.

What each CSV actually holds

The value of this dataset is that every file maps to a named API endpoint, so a reader can trace any number back to where it came from. The mapping is given in a table, and the roles are worth summarising because they distinguish the primary ledger from the derived material.

The primary execution ledger is `api-v1-execution-tradeHistory.csv` from `/api/v1/execution/tradeHistory`. Alongside it, `api-v1-execution.csv` holds API-returned execution events including available order lifecycle changes, with the README careful to say this is not a guaranteed complete historical lifecycle log. `api-v1-order.csv` from `/api/v1/order` holds order intent and the latest returned state per order, exported with a timestamp cursor. `api-v1-user-walletHistory.csv` from `/api/v1/user/walletHistory?currency=all` is the wallet event ledger across deposits, withdrawals, funding, realised pnl, spot trades and conversions.

Three files are terminal anchors rather than histories. `api-v1-position.snapshot.csv` is the terminal position, `api-v1-user-wallet.snapshot-all.csv` the terminal wallet, and `api-v1-user-margin.snapshot-all.csv` the terminal margin and equity. The README also includes `api-v1-instrument.all.csv` as an instrument dictionary and contract specification reference, `api-v1-wallet-assets.csv` for asset scale and wallet metadata, and `api-v1-user-walletSummary.all.csv` as a BitMEX-generated summary used as a cross-check.

Only three files are derived. `derived-equity-curve.csv` is the XBT-equivalent wallet curve across XBT and USDt balances used for the chart, `cumulative-performance.png` is the README figure, and `manifest.json` carries checksums, row counts, time ranges and build metadata. If you are going to audit anything, start with the manifest.

Adjusted wealth, marked wealth and a 1.83953943 XBT baseline

The headline figure needs unpacking, and the README does the unpacking for you in unusually careful language.

The chart baseline is 1.83953943 XBT at 2020-05-01T14:39:40.387Z. The total completed deposits in the XBT ledger are 1.77199051 XBT, and total completed withdrawals are 99.51625171 XBT. The latest adjusted wallet-equivalent wealth on the XBT plus USDt scope is 99.46454272 XBT, which the README reports as 54.070351x the baseline. The latest adjusted marked wealth is listed as not available, not calculated from this snapshot.

The two concepts are defined precisely. Adjusted wealth is the wallet-equivalent curve after stripping out later external deposits and adding back later external withdrawals, so it is closer to the trading result itself. Marked-to-market wealth uses the same framework but swaps in the current marked margin balance, so it also reflects unrealised PnL still sitting in open positions.

That distinction matters when you read the 70x figure elsewhere. The 54.070351x number in this repository is the adjusted wallet-equivalent series, which is a different measure from a marked-to-market or an exchange-reported return, and the repository does not present a marked figure for this snapshot. Anyone comparing a headline multiple against this file should compare like with like, and the method is documented well enough to do that.

The concentration figures are worth a separate look too. By executed trade notional, BTC-related symbols account for about 84.0% of the full archive, and the account becomes more concentrated over time: about 93.8% from 2022 onward, about 96.1% from 2023 onward, and about 99.0% from 2024 onward. That is a description of the archive, not a forecast.

What this dataset is explicitly not

The README draws a boundary that most trading datasets cross, and it is worth repeating because it determines what research the data can support.

It is not a dataset for high-frequency trading, for central limit order book microstructure work, or for millisecond price prediction. The recommendation is to read it instead as a timestamped archive of manual, discretionary, chart-driven BTC trading: regime adaptation, position sizing, risk management, drawdown handling and long-term compounding under uncertainty.

That is a coherent and narrow claim. At 43,258 orders across more than six years, the average is roughly nineteen orders per day, which is a human decision cadence. There are no millisecond-level price series, no book depth, no queue position, nothing to reconstruct a market microstructure event from. The event data that does exist is the exchange's own execution and order reporting, which is what the account saw, not what the market did.

The README also names the archive's own framing in a single line: it is more about decision quality under uncertainty than prediction quality over price. That is a self-limiting claim, and a good sign. It tells you the intended reading is a record of how a person sized and held through cycles, and that the project is not claiming its subject can predict direction.

One more caveat is stated in the file table rather than the prose. The execution file is described as not a guaranteed complete historical lifecycle log, which means reconstructing the full life of a single order from these files can run into gaps. A study that needs perfect per-order lifecycle data has to account for that.

A final snapshot with a cutoff that is not the export time

The archive is closed, and the closure is documented in a way that shows the author was thinking about the integrity of the data.

The headline is a final archive snapshot dated 2026-09-11, and the note explains it was the final refresh requested by the account owner. Account ledgers use a common cutoff of 2026-09-11T09:43:29Z, and position, wallet and margin snapshots were read sequentially afterward, not atomically. Activity after those reads is not included.

That non-atomic read is the detail that matters most for anyone building on the data. The three terminal anchors, position, wallet and margin, were captured one after another, so a market move between reads leaves them slightly out of sync with each other. That is exactly why the marked-to-market figure is not calculated for this snapshot, since a marked number would combine a margin anchor and a position anchor that were never simultaneous.

The dataset window is stated separately from the export. The first public event is 2020-05-01T01:05:55.004Z, the latest recorded account event or snapshot timestamp is 2026-07-23T12:56:05.357Z, and the export completed at 2026-09-11T09:57:16Z. The README is explicit that export time and last recorded account event time are different, and a reader who assumes the data runs to the export date will misread the coverage.

Versioning follows a simple rule: stable root filenames plus a Git commit and tag, named `data-YYYY-MM-DD` and dated by export rather than by the last account event. The recent tags are `data-2026-09-11` for the final snapshot, `data-2026-07-19` and `data-2026-07-03`. The last push was on 2026-09-11 and the repository is not archived.

Getting the files without cloning the history

There is no package to install and nothing to build. This is a flat repository of CSV files at the root, and the README gives you two ways to get them.

The first is the GitHub Releases page, which the README describes as the option for anyone who wants a one-click download instead of cloning the full git history. Each tagged build can be attached there as `.zip` and `.tar.gz` archives containing the same flat repository root. The second is a normal clone, which gives you the history along with the files.

The choice depends on what you are doing. For a one-off analysis, the release archive is faster and smaller. For work that tracks how the data changed between exports, the git history is the point, since each `data-YYYY-MM-DD` tag is a dated rebuild of the same root files.

Two practical notes follow from the file list. The `manifest.json` is the place to start regardless of method, because it carries the checksums, row counts, time ranges and build metadata that let you confirm the archive you hold matches the one that was published. And the row counts it should agree with are given in the README: 173,592 rows for `api-v1-execution.csv`, 43,258 for `api-v1-order.csv`, 173,577 for `api-v1-execution-tradeHistory.csv` and 17,620 for `api-v1-user-walletHistory.csv`, across a time span of 2020-05-01 to 2026-07-23.

There is also a live companion, and the README is careful about the distinction. A community-created real-time dashboard at wsnb.online shows the account's live positions and order data. The repository itself is described as the long-horizon historical layer, and that dashboard as the live current-state layer. They are different things with different provenance, and the community dashboard is not part of the archived dataset.

No licence, one account, and the limits of a mirror

Two constraints should shape any decision to build on this repository.

The first is licensing, and here the repository is silent. There is no licence file among the top-level entries, and the project metadata lists the licence as unknown. That means the permissions are not stated in a form you can rely on. Public availability on GitHub is not the same as a grant to copy, modify and redistribute the files, and for a dataset you might want to mirror into your own storage or publish a derived version of, that distinction matters. This is a note about the absence of a stated grant, not legal advice, and the practical move is to ask the account owner or the repository maintainers what they intend rather than assume.

The second is scope. This is one account, one exchange, one asset concentration and one person's decision style. Even a well-documented ledger of 43,258 orders across several cycles is a sample of size one, and the repository's own framing, decision quality under uncertainty rather than prediction quality over price, is an acknowledgement of that. Conclusions drawn from it do not generalise to other traders, other venues, other periods, or to a strategy.

There is a legitimate alternative use that this data supports better than most performance publishing, which is as a teaching corpus. Because the order intent, the execution record, the wallet events and the position anchors are all present with the deposits and withdrawals in the same ledger, a reader can reconstruct what the account actually did, including the deposits that flatter a naive equity curve, and check it against the derived curve. The README's own framing is that the value is in the record being inspectable in sequence. That is a real and unusual thing to have, and it is available without trusting the headline.

Editorial conclusion

This repository is worth adopting as a teaching and research corpus if you want a real, dated execution ledger rather than a curated track record, and you are comfortable reading CSVs and rebuilding the derived numbers yourself. It is not a strategy you can deploy, it is not microstructure data, and it is not a licence you can build on: the repository states no licence, and the export was frozen at the account owner's request. Verify three things before you use it: that the `manifest.json` checksums and row counts match the files you downloaded, that the export cutoff of 2026-09-11T09:43:29Z is acceptable given activity after those reads is not included, and that the deposits and withdrawals in `api-v1-user-walletHistory.csv` are handled the way the README's adjusted-wealth method handles them.

Frequently asked questions

Official sources

1. bwjoke/BTC-Trading-Since-2020 on GitHub
2. Issues
3. Project website
4. README
5. Releases