Deribit trade history chart
This guide is for Deribit derivatives traders — BTC and ETH futures, perpetual swaps, and options — who want their real fills on the chart instead of buried in a transaction log. Export your trade history from Deribit, map the fill rows into KLinePic's CSV schema, and render a shareable review image with entry/exit (B/S) markers, holding window, return, max run-up, max drawdown, and optional indicators such as MACD.
Because Deribit is a derivatives venue, direction matters: the same schema records long and short lifecycles explicitly, so a short is charted as cleanly as a long. KLinePic is free to start and needs no account to render — the loop from log to review image takes minutes.
Deribit's exact menu names and paths change over time, and the retail terminal, mobile app, and API each surface history a little differently. Rather than quote a click path that may already be stale, the notes below stay deliberately general; check Deribit's official documentation or help center for the current wording before you export.
BTC-PERPETUAL, ETH-PERPETUAL, or dated futures such as BTC-27DEC24.Wherever the export button lives today, the goal is the same: a CSV with one row per executed fill that you can rename into the KLinePic schema, with each row's long or short direction preserved.
Deribit's export column headers can differ between the trade history and the broader transaction log, so treat this as a checklist against whatever columns your export actually contains rather than a fixed header list. The target schema is fixed: KLinePic reads trade_id, symbol, event_type, position_side, time, price, quantity, fee, note, documented in the data protocol. Extra columns are ignored on import and listed back to you; copy details such as the fee currency into note only when you want them preserved in the normalized record.
The one field that carries more weight on Deribit than on a spot exchange is position_side. On a derivatives venue a sell can be opening a short or closing a long, and a buy can be opening a long or closing a short. The event_type alone cannot tell those apart, so mark long or short explicitly on every row.
| KLinePic field | Your export's typical column | Notes |
|---|---|---|
| trade_id | Trade id / order id, if present | Use one stable id per round-trip trade; entry and exit fills share it. Reuse a Deribit id or create your own. |
| symbol | Instrument name column | Deribit instruments read like BTC-PERPETUAL, ETH-PERPETUAL, or dated futures BTC-27DEC24. Keep options instruments separate from futures and perps. |
| event_type | Side / direction column | Normalize to lowercase buy or sell. Remember a sell may open a short or close a long — direction lives in position_side, not here. |
| position_side | Position direction, if present — otherwise you assign it | This genuinely matters on Deribit. Set an explicit long or short on every row so a sell-to-open-short is never confused with a sell-to-close-long. One trade_id stays a single long or short lifecycle. |
| time | Trade / execution time column | Deribit logs are typically UTC; write explicit offsets like +00:00 so markers land on the right candles. |
| price | Fill / executed price column | Use the executed price, not the order's limit price. |
| quantity | Size / amount / contracts column | A positive number. Deribit expresses size in contracts or the base asset depending on the instrument; keep the unit consistent across all fills of a trade. |
| fee | Fee amount column | Optional, but useful for honest net-return journaling. Deribit fees may settle in the base coin (inverse) or the settlement currency (linear). |
| note | Fee currency or free text | Optional. There is no fee_asset column in KLinePic — keep the fee currency as note text such as fee_asset=USD or fee_asset=BTC, or drop it. |
Deribit is derivatives, so a short round-trip is the instructive example — a sell to open the short, then a buy to close it, both carrying the same trade_id and position_side=short:
trade_id,symbol,event_type,position_side,time,price,quantity,fee,note DERIBIT-BTC-001,BTCUSDT,sell,short,2026-05-10T09:15:00+00:00,61250.00,0.5,3.06,fee_asset=USD DERIBIT-BTC-001,BTCUSDT,buy,short,2026-05-10T18:45:00+00:00,60100.00,0.5,3.00,fee_asset=USD
Here the sell opens the position and the later buy closes it, so falling price is a profit — exactly the opposite of a long. A long round-trip is the mirror image: a buy to open with position_side=long, then a sell to close. Scaling in or out simply adds more rows with the same id. The crypto exchange template ships this exact header so you can paste mapped rows straight in.
| KLinePic | Manual screenshot + spreadsheet | Typical trading-journal SaaS | |
|---|---|---|---|
| Setup time | Minutes: export, map, paste | Slow, repeated by hand per trade | Onboarding plus per-exchange import setup |
| Account required | No account needed to render | None | Usually requires sign-up first |
| Long/short handled | Yes, explicit position_side per trade | Tracked by hand, easy to mislabel | Varies by product and plan |
| Output | Annotated K-line image with trade metrics | Static screenshot plus separate numbers | Web dashboards and statistics |
| Buy/sell markers on real K-line | Yes, B/S at actual fill price and time | Drawn manually, easy to misplace | Varies by product and plan |
| Cost to start | Free to start | Free, but pays in time | Commonly subscription-based |
On Deribit a sell can open a short or close a long, and a buy can open a long or close a short. Without an explicit long/short on every row, an opening short is indistinguishable from a closing long. Always set position_side.
Option contracts carry a per-contract premium, not a directional entry and exit price. Keep options separate; the K-line review view is built for linear and inverse futures and perpetuals with a clear price path.
A perpetual such as BTC-PERPETUAL and a dated future like BTC-27DEC24 are different instruments with different prices. Map each to its own symbol and never merge their rows into one trade.
Deribit logs are typically stamped in UTC. Chart those times as local and every marker shifts by hours. Encode the offset explicitly — +00:00 — in time after you confirm the zone.
Deribit sizes can be in contracts or the base asset depending on the instrument. Keep quantity as one consistent, positive unit across all fills of a trade so opening and closing sizes reconcile.
Order history records what you asked for — limit prices, canceled orders — not what executed. Use the trade or fills export and drop every row without a real fill price and size.
Export your trade history or transaction log from Deribit as CSV, map the fill rows into KLinePic's CSV fields (trade_id, symbol, event_type, position_side, time, price, quantity, fee, note), then upload or paste the CSV to render. No account is needed.
Yes, but map the instrument name to a spot pair first. BTC-PERPETUAL, ETH-PERPETUAL and dated futures such as BTC-27DEC24 are Deribit instrument names, not market-data symbols — write BTCUSDT or ETHUSDT in the symbol column and keep the original instrument in note. Options instruments such as BTC-27DEC24-70000-C have no candle series at all, so chart the underlying instead. After that mapping they render the same way once each row has symbol, side, time, price, size, and an explicit long or short position_side. Linear and inverse futures with a clear entry and exit price are the best fit.
Options are a different instrument shape — a per-contract premium rather than a directional entry and exit price — so the review chart is best suited to Deribit's futures and perpetuals. You can still record option rows, but the entry/exit K-line view is designed for linear and inverse contracts with a clear price path.
On derivatives a sell can open a short or close a long, and a buy can open a long or close a short. Set position_side to long or short on every row so KLinePic knows which lifecycle a fill belongs to, and keep one trade_id to a single long or short.
No. A downloaded trade history or transaction log is enough; KLinePic renders from an uploaded or pasted file. For automation there is a documented Agent API and a CSV/JSON data protocol.
Yes. Batch rendering is supported — a month of Deribit fills becomes a full set of review images in one pass, via the web UI or the documented Agent API.