Bitcoin Futures Positioning methodology
How weekly Bitcoin futures positioning is selected, normalized, and compared.
Inputs and coverage
The ledger uses the official CFTC Traders in Financial Futures Futures Only Socrata view. Configuration restricts commodity_name to the exact BITCOIN literal and retains both standard and micro Bitcoin contract markets returned by that view. Each normalized observation preserves its report date, market name, contract-market code, and the published long and short position counts for asset managers and leveraged funds. The public archive is capped at five hundred twenty weekly entries while source snapshots remain governed by the configured retention policy.
Positioning method
For each trader category, net positioning is calculated by subtracting published short positions from published long positions. Week-over-week change subtracts the immediately previous report’s net value for the same contract-market code from the current report’s net value. Standard and micro contracts are never combined because their contract sizes differ. These net values and changes are VUGA calculations rather than CFTC fields, forecasts, trading signals, or estimates of unreported positions.
Limitations
Commitments of Traders data are weekly snapshots with reporting lags and classification rules set by the CFTC. A trader can hold positions for hedging, arbitrage, market making, or other purposes that the table does not reveal. Netting long and short counts removes gross-position detail, and changes in open interest or trader classification can affect comparisons. The ledger therefore links to the official source and must not be interpreted as investment advice or a complete view of Bitcoin exposure.
Update schedule
The dataset checks weekly on Friday at 3:30 p.m. America/New_York time, after the usual CFTC release window. Required-field coverage and row-count continuity are validated before atomic promotion. Duplicate market-and-date identifiers are rejected. When retrieval or validation fails, the prior active snapshot remains published; repeated failures pause scheduled ingestion and trigger the configured stale-data state without deleting the last successful static ledger.