In the AI era, high-quality context becomes the most scarce asset. This repository is an open-intelligence experiment: a public, inspectable mirror of a real trading account since May 2020. This build contains 43,258 orders and 173,577 balance-affecting execution records, plus the available order-lifecycle events described below. A public, multi-year account ledger at this level of detail offers a way to examine predominantly BTC trading beyond screenshots and retrospective claims.
This archive is more about decision quality under uncertainty than prediction quality over price.
Final archive snapshot — 2026-09-11. This is the final refresh requested by the account owner. Account ledgers use a common cutoff of 2026-09-11T09:43:29Z; position, wallet, and margin snapshots were read sequentially afterward, not atomically. Activity after those reads is not included.
BitMEX recognized Paul Wei (@coolish) as one of its 11th anniversary Legends and, on its public Hall of Legends page, highlighted a 70x Bitcoin-trading return over 3 years (source). But the deeper value of this repository is not a single headline number. It is a public, timestamped archive of long-term BTC trading through multiple market cycles — including strong calls, reversals, drawdowns, and recoveries — so readers can inspect the record in sequence rather than rely on retrospective storytelling.
Any long-term result includes timing and luck. What makes this archive unusual is that much of the trail was public before the outcome was known. That makes it a more durable record of decision-making under uncertainty, not just a curated victory lap.
Most public trading content is narrative without ledger truth.
This repository does the opposite: it publishes a long-horizon historical mirror of one real trading account so other people can inspect the actual execution ledger, wallet ledger, terminal snapshots, and reconstruction anchors instead of relying on screenshots, selective anecdotes, or marketing summaries.
Open intelligence instead of selective narrative.
This is not a dataset for HFT (high-frequency trading), CLOB (central limit order book) microstructure work, or millisecond price prediction. 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.
- First public event in this dataset: 2020-05-01T01:05:55.004Z
- Latest recorded account event/snapshot timestamp: 2026-07-23T12:56:05.357Z
- Versioning policy: stable root filenames + Git commit/tag (
data-YYYY-MM-DD, dated by export, not the last account event) - Export completed (UTC): 2026-09-11T09:57:16Z. Export time and last recorded account event time are different.
- If you just want a one-click download instead of cloning the full git history, use the GitHub Releases page.
- Each tagged build can be attached there as
.zipand.tar.gzarchives containing this same flat repo root.
| File | Source endpoint | Role |
|---|---|---|
api-v1-execution.csv |
/api/v1/execution |
API-returned execution events, including available order lifecycle changes; not a guaranteed complete historical lifecycle log |
api-v1-execution-tradeHistory.csv |
/api/v1/execution/tradeHistory |
primary execution ledger |
api-v1-order.csv |
/api/v1/order |
order intent and latest returned state per order; timestamp-cursor export |
api-v1-user-walletHistory.csv |
/api/v1/user/walletHistory?currency=all |
wallet event ledger across deposits, withdrawals, funding, realised pnl, spot trades, conversions |
api-v1-position.snapshot.csv |
/api/v1/position |
terminal position anchor |
api-v1-user-wallet.snapshot-all.csv |
/api/v1/user/wallet?currency=all |
terminal wallet anchor |
api-v1-user-margin.snapshot-all.csv |
/api/v1/user/margin?currency=all |
terminal margin/equity anchor |
api-v1-user-walletSummary.all.csv |
/api/v1/user/walletSummary?currency=all |
BitMEX-generated summary cross-check |
api-v1-instrument.all.csv |
/api/v1/instrument |
instrument dictionary and contract spec reference |
api-v1-wallet-assets.csv |
/api/v1/wallet/assets |
asset scale and wallet metadata reference |
derived-equity-curve.csv |
derived | XBT-equivalent wallet curve across XBT and USDt balances used for the chart |
cumulative-performance.png |
derived | README performance figure |
manifest.json |
derived | checksums, row counts, time ranges, and build metadata |
api-v1-execution.csv: 173,592 rows (all execution events returned by the API for this export)api-v1-order.csv: 43,258 rowsapi-v1-execution-tradeHistory.csv: 173,577 rowsapi-v1-user-walletHistory.csv: 17,620 rows- Time span: 2020-05-01 → 2026-07-23
- By executed trade notional, BTC-related symbols account for ~84.0% of the full archive
- The account becomes much more BTC-concentrated in later years: ~93.8% from 2022 onward, ~96.1% from 2023 onward, and ~99.0% from 2024 onward
- Chart baseline: 1.83953943 XBT at 2020-05-01T14:39:40.387Z
- Total completed deposits in XBT ledger: 1.77199051 XBT
- Total completed withdrawals in XBT ledger: 99.51625171 XBT
- Latest adjusted wallet-equivalent wealth (XBT+USDt scope): 99.46454272 XBT (54.070351x vs baseline)
- Latest adjusted marked wealth (XBT+USDt scope): n/a — not calculated from this snapshot
In plain English: 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 unrealized PnL still sitting in open positions.
- BitMEX API Explorer docs: https://docs.bitmex.com/api-explorer/bitmex-api.html
- BitMEX API Explorer / Swagger JSON: https://www.bitmex.com/api/explorer/swagger.json
XBTis another ticker used by some exchanges for Bitcoin (BTC). If you are unfamiliar with the term, see: https://coinmarketcap.com/academy/glossary/xbt
For a community-created real-time dashboard showing this account's live positions and order data, see: https://wsnb.online
This repository is the long-horizon historical layer; wsnb.online is the live current-state layer.
This final export uses timestamp-cursor pagination, keeping equal-timestamp groups together, and verifies that every orderID is unique. This corrects duplicate and omitted orders caused by unstable ordering across offset-page boundaries in earlier snapshots. Some order-file diffs therefore recover older records rather than represent new trading activity.
api-v1-execution.csv now publishes the records returned by GET /api/v1/execution. The endpoint is documented to include order opening, cancellation, and order-status changes, in addition to balance-affecting events. That describes its event types, not a promise of complete historical retention.
- Observed
execTypecounts in this export:Funding: 12,916,New: 8,Replaced: 6,Settlement: 19,Trade: 160,642,TriggeredOrActivatedBySystem: 1. - Events other than
Trade,Funding, andSettlement: 15; their observed timestamp range is 2025-06-13T00:17:51.654Z → 2025-06-19T21:24:46.794Z. - Returned
Canceledevents: 0; returnedRejectedevents: 0. An absent event is not evidence that the corresponding action never occurred. - This is not a complete historical order lifecycle log. The export preserves what the API returned; it does not fabricate missing New/Canceled/Replaced/Rejected events or infer their timestamps from order snapshots. Date filters do not establish historical completeness.
- Join
executiontoorderusing nativeorderID; identify individual execution events usingexecID.order.csvpreserves the states returned for individual orders, not every intervening state transition. Use a left join and retain unmatched execution rows: even a nonemptyorderIDmay have no corresponding order record returned by the API. - Do not concatenate
executionandtradeHistoryfor PnL or volume totals: they overlap. Continue usingtradeHistoryas the balance-affecting execution ledger, or explicitly deduplicate byexecIDwhen combining sources.
executionadds all API-returned execution events, including the available lifecycle changes; see the coverage limits above.tradeHistoryis the main balance-affecting execution ledger.orderrecords order intent and the latest state returned for each order; it is not a complete state-transition log.walletHistoryis the wallet-side ledger for deposits, withdrawals, funding, realised PnL, spot trades, conversions, and related events.position/wallet/marginsnapshots are terminal anchors for reconstructing state at the export time.instrumentandwallet-assetsare reference dictionaries so downstream users can interpret symbols, scales, settlement currencies, and contract metadata using BitMEX-native semantics.walletSummaryis kept as a cross-check layer, not as the primary historical ledger.
accountis removed from every published file where it existed.api-v1-user-walletHistory.csv:txis removed,textis removed, andaddressis redacted only whentransactTypeisWithdrawalorTransfer.api-v1-order.csv:textis removed.api-v1-execution-tradeHistory.csv:textis intentionally kept because it helps explain fills, funding, and settlements, but non-BitMEX hostnames inside that field are redacted.api-v1-execution.csv: all returned events are retained, butaccount, client/broker identifiers (origClOrdID,clOrdID,clOrdLinkID,brokerLinkID), and free-form fields (text,ordRejReason,error,algoOrderDetails) are excluded. Only explicitly reviewed columns are published.- Native exchange
orderIDandexecIDremain unchanged for cross-file joins; no client-provided IDs are needed for those joins. /api/v1/userprofile data and API credentials are never published.
derived-equity-curve.csv is intentionally simple and auditable:
- It tracks wallet-equivalent wealth across XBT and USDt balances.
- The baseline is the first fully-funded XBT wallet balance after the final completed deposit on the first trading day.
- After that baseline, completed withdrawals are added back, completed deposits are subtracted, and internal
Transferrows are neutralized. Conversionand XBT/USDtSpotTradepairs are treated as internal wallet swaps, not losses.- USDt balances are converted back into XBT using the latest observed internal XBT/USDT conversion or spot rate in the published wallet ledger.
- For wallet-history-driven cash flows, event ordering uses
timestampwhen BitMEX provides it;transactTimeis preserved as the original exchange field but is not blindly treated as the accounting-effective order. - The resulting series is a public-friendly XBT-equivalent wealth curve. It is not a full historical mark-to-market NAV across every non-XBT wallet or every asset BitMEX ever credited.
In practice, almost all trading activity in this account was BTC-settled on BitMEX: by executed trade notional grouped by settlement currency, about 98.9% settles in XBT, while only about 1.1% settles in USDt. That is why the realized PnL story is overwhelmingly a story about BTC quantity and BTC-denominated value changing over time; the USDt component is a small supplementary layer; the only completed external deposits were the two initial XBT deposits on 2020-05-01, and there have been no completed deposits since.
This keeps the methodology auditable from the published files themselves while avoiding false cliffs when the account temporarily rotates between XBT and USDt.
- Raw API secrets
/api/v1/userprofile payloads- Client-supplied order identifiers and unreviewed execution free-text fields
- login/IP/device/profile data
- chain tx hashes from wallet history
This release is the final archive refresh requested by the account owner; no further routine refreshes are planned. It is a dated snapshot, not a claim to include future account activity. The reproducible update procedure is retained below for auditability.
Each update should:
- pull the full raw dataset from BitMEX,
- rebuild the public root with the same filenames and privacy rules,
- commit the new root,
- tag the commit as
data-YYYY-MM-DD.
That gives stable filenames for readers and full daily traceability through Git history.
