DEV Community: HMwork

One Call, Five Answers: How Many Candles Each Exchange API Actually Returns

HMwork — Tue, 20 Oct 2026 02:15:42 +0000

One Call, Five Answers: How Many Candles Each Exchange API Actually Returns

Every trading-data script eventually grows the same loop: request candles, remember the last timestamp, ask for the next page. The loop breaks the first time it touches a second exchange, because "how many candles come back in one call" is not one number. On the morning of 2026-10-20 (02:00–02:10 UTC) I asked five exchange APIs the same question with the same kind of request — hourly candles on BTC — and got five different answers. One venue's documentation and its own endpoint even disagree by exactly one candle.

Quick disclosures: AI-assisted content: this article was researched and drafted with AI assistance, and every number below was re-checked against the official endpoints and documentation cited at the end. #ad — affiliate disclosure: this post carries no affiliate or referral links today; if future posts in this series do, they will be labelled right where they appear. This article is not financial advice — it is a documentation study of API behaviour.

The five answers, up front

Venue	Docs say	Wire says	Docs' default size
Binance	Max 1000, default 500	1000 bars (asked 1500); 500 by default	500
Bybit	[1, 1000], default 200	1000 bars (asked 1001); 200 by default	200
OKX	Max 300, default 100	300 bars (asked 500); 100 by default	100
Kraken	"Maximum 720 candles per call"	721 rows, no limit parameter exists	—
KuCoin	no text documentation found	100 bars	—

Four different caps (100 / 300 / 720 / 1000) and three different defaults (100 / 200 / 500) for the same everyday request. Same asset, same interval, same minute, five rulebooks.

What I actually ran

All five calls are public, key-free, and repeatable:

Binance GET /api/v3/klines on BTCUSDT, interval 1h, limit=1500 → exactly 1,000 rows. Same call with no limit → 500 rows.
Bybit GET /v5/market/kline (category spot, BTCUSDT, interval 60), limit=1001 → exactly 1,000 rows. No limit → 200 rows.
OKX GET /api/v5/market/candles on BTC-USDT, bar 1H, limit=500 → exactly 300 rows. No limit → 100 rows.
Kraken GET /0/public/OHLC on XBTUSD, interval 60 → 721 rows. The endpoint has no limit parameter at all.
KuCoin GET /api/v1/market/candles (BTC-USDT, type 1hour) → 100 rows.

Over caps are not errors — Binance and Bybit did not complain about limit=1500 or limit=1001. They silently returned their maximum. A client that asks for 5,000 and trusts the request will quietly believe it fetched 5,000.

The documentation layer, quoted

A number on the wire is nice; a number the venue actually commits to is better. Same morning, official text surfaces:

Binance spot REST spec, klines section: "limit | INT | NO | Default: 500; Maximum: 1000."
Bybit kline page: "Limit for data size per page. [1, 1000]. Default: 200."
OKX REST docs, candles section: "Number of results per request. The maximum is 300. The default is 100."
Kraken historical-data guide: "Maximum 720 candles per call."
KuCoin: the docs site is a JavaScript application; I found no text-rendered page stating the candle depth. Reported as observed — the 100-row figure above is measurement, not a quote.

So four of five venues have their number in writing, and the live wire agrees with every written number. Almost.

The one-candle disagreement

Kraken's guide says 720. The endpoint returned 721 rows.

The arithmetic makes the disagreement visible: the first row opens at 2026-09-20 02:00 UTC and the last row is stamped 2026-10-20 02:00 UTC — exactly 2,592,000 seconds apart, which is precisely 720 hour-wide slots. Seven hundred twenty-one rows spanning seven hundred twenty slots. The most plausible reading is that the final row is the bar still forming at request time (I called shortly after 02:00 UTC, and a closed candle's close price is simply the last traded price on most venues, so a live bar looks identical to a finished one in the response). Kraken's own pagination hint — the last field in the response — pointed at 01:00, i.e. the second-to-last row, as the resume marker, which quietly treats the final row as not-yet-final.

Kraken's documentation does not adjudicate this, so I will not either. The point for builders: a documented cap and the row count are two different measurements, and one candle of drift per page is exactly the kind of off-by-one that turns into a silent gap — or a duplicated bar — after two hundred pages.

A quiet cross-check worth copying

Binance and Bybit disagree on defaults (500 vs 200), but both cap at 1000 — and on the same minute of capture, both handed me a window whose oldest bar was 2026-09-08 11:00 UTC. Two independent venues, one thousand hours back from the same moment, agreeing to the hour. When you build a cross-venue pipeline, checks like this — where two sources should agree and do — cost nothing and catch whole classes of silent truncation.

What a portable fetcher must carry

A per-venue page-size constant. Read each venue's own limit line; never port one venue's constant to another. 100-to-1000 across five mainstream venues.
Never omit limit. The three documented defaults differ 5× (100/200/500), and KuCoin offers no documented default at all.
Row order is also per-venue. In my same-minute captures, Binance returned oldest bar first (row 0 was the oldest), while Bybit returned newest first (the oldest sat at the end of the array). Same pair, same interval, opposite arrays.
Decide what to do with live bars. Kraken hands you the forming candle; whether your backtest wants it is a policy decision, not a default.
Treat over-cap requests as truncation signals. Asking for 1500 and receiving 1000 is correct behaviour — but only if your code compares asked versus received instead of trusting the request.

None of this is exotic. It is five ordinary rulebooks, each written by one venue, each silently binding the moment your script touches that venue.

Numbers move — verify official sources

Every figure here is a snapshot from 2026-10-20 02:00–02:10 UTC, and any venue can change its limits without announcing it. Re-run the calls yourself: api.binance.com GET /api/v3/klines; api.bybit.com GET /v5/market/kline; okx.com GET /api/v5/market/candles; api.kraken.com GET /0/public/OHLC; api.kucoin.com GET /api/v1/market/candles. For the written rules: the klines section of Binance's spot REST spec on GitHub, the kline page on bybit-exchange.github.io/docs/v5, the candles section of okx.com/docs-v5, and the historical-data guide on docs.kraken.com. Verify official sources before you hard-code any number into your own code.

Not financial advice. This post reports on API documentation and observed endpoint behaviour only; it recommends no exchange, no strategy, and no trade.

AI-assisted content disclosure: researched and drafted with AI assistance on 2026-10-20 against the cited official sources. #ad: no affiliate or referral links are present in this post.

Funding Settles Every 8 Hours — but Four of These Five Exchanges Have No 8-Hour Candle

HMwork — Fri, 16 Oct 2026 02:18:52 +0000

Funding Settles Every 8 Hours — but Four of These Five Exchanges Have No 8-Hour Candle

If you hold a BTC perpetual on Binance, Bybit, or OKX, your funding payment changes hands every 8 hours, on the 00:00 / 08:00 / 16:00 UTC grid. That number is written into the exchanges' own APIs: the interval parameter and the settlement timestamps line up on the same three daily points.

So when you want to plot the cost you are actually paying on the same rhythm as the payments, the obvious move is to pull an 8-hour candle. And that is where the surprise is: most exchanges simply do not have one.

I went looking for the 8-hour candle at five exchanges on 2026-10-16, between 02:05 and 02:25 UTC, using only free, key-free official endpoints and official documentation pages. Each claim below rests on two layers: what the docs say, and what the live API actually returns. One venue supports the interval. Four do not.

Binance: the interval exists — and its documentation says so

Binance's spot REST documentation keeps a small table of valid kline intervals under the anchor kline-intervals. The hours row reads, verbatim, as fetched from the official repository today:

hours | 1h, 2h, 4h, 6h, 8h, 12h

And the live API agrees. GET /api/v3/klines?symbol=BTCUSDT&interval=8h returns data. The futures side (/fapi/v1/klines, interval 8h) also answered — and the difference between two adjacent returned timestamps was exactly 28,800,000 milliseconds, which is 8 hours to the millisecond, no calendar trickery.

There is a second, quieter lesson hiding in the same test. Spot supports a 1s interval — my probe returned rows. The futures API rejected the exact same parameter with error code -1120 ("Invalid interval"). Same company, same API family, two different interval enums. Never assume an interval that works on one endpoint of a venue exists on its sibling endpoint.

Bybit: the ladder stops at 12 hours; 480 minutes is not on it

Bybit's kline documentation lists the accepted values for the interval parameter as 1, 3, 5, 15, 30, 60, 120, 240, 360, 720, D, W, M — minutes, with day/week/month letters at the end. Notice there is no 480 between 360 and 720. Eight hours is not a step on this ladder.

The live endpoint behaves exactly as the enum implies:

interval=360 on spot BTCUSDT: accepted, and adjacent timestamps are 21,600,000 ms apart (6 hours, as advertised);
interval=480: rejected with retCode 10001, message "Invalid period!";
interval=90 (another gap in the ladder): also rejected with the same 10001.

So the documentation enum and the rejection behavior confirm each other from two independent surfaces: no 8-hour candle, and the API will tell you so explicitly rather than silently rounding to something else.

OKX: two candle grids, neither of them 8 hours

OKX's documentation (fetched live today, the same page I cross-checked against a 2026-08-06 Internet Archive snapshot) splits candles into three enumerated groups. The intraday list is:

[1s/1m/3m/5m/15m/30m/1H/2H/4H]

and above 4 hours it jumps straight to two daily-grid families:

UTC+8 opening price k-line: [6H/12H/1D/2D/3D/1W/1M/3M]
UTC+0 opening price k-line: [6Hutc/12Hutc/1Dutc/2Dutc/3Dutc/1Wutc/1Mutc/3Mutc]

No 8H in any of the three lists. The live market endpoint matches the docs: bar=6H returned candles 21,600,000 ms apart, while bar=8H came back with error 51000 ("Parameter bar error"), as did bar=9H.

One extra wrinkle worth knowing before you try to synthesize 8-hour bars from OKX data: its default 6H/12H/1D candles open on a UTC+8 midnight grid, and only the suffixed *utc variants open at UTC midnight. If you aggregate 1-hour candles into 8-hour buckets anchored at UTC 00:00 while mixing in OKX's default bars, your bars will be silently shifted by 8 hours. The funding settlement grid is UTC-anchored; OKX's default candle grid is not.

Kraken: the enum is now printed in the docs — 8 hours is absent

Kraken used to be a venue where the interval list could only be inferred from trial and error. That has changed: the machine-readable documentation dump at docs.kraken.com now carries the OHLC endpoint's parameter table explicitly:

interval | 1, 5, 15, 30, 60, 240, 1440, 10080, 21600 (minutes) | default 1

No 480. No 360, either. And the API enforces it — querying XBTUSD with interval=360 or interval=720 returns EGeneral:Invalid arguments, while 15, 240, and 1440 all return their usual ~720-row responses.

Worth noting for tooling: this enum includes 1 and 5 minute intervals that many third-party tutorials omit, and its 10080/21600 entries mean "1 week / 2 weeks in minutes" — Kraken expresses weekly candles as minute counts where other venues use letters.

Coinbase: six granularities, and 28800 is not one of them

Coinbase Exchange's candle endpoint takes a granularity in seconds. Today's direct probes: 60, 300, 900, 3600, 21600 and 86400 all answered 200 with data; 7200 (2h), 14400 (4h) and — the point of this exercise — 28800 (8h) all answered HTTP 400 with Unsupported granularity. Odd values like 3601 fail the same way, so the check is a strict allow-list, not a range.

What this means for your charts

The funding cycle is a real 8-hour cash-flow event; the 8-hour candle is a UI convention that most venues never implemented. Three practical consequences:

Build the bar yourself, and say so. Aggregating 1h or 4h candles into 00/08/16 UTC buckets is straightforward, but your derived bars are yours, not the exchange's — label them as derived, especially if you publish them.
Check the calendar anchor before aggregating. Binance spot candles open at UTC midnight by default, OKX defaults to UTC+8 (with *utc variants available), and the mismatch is invisible until two charts disagree by one bar.
Expect silent enum differences even within one venue. Binance spot 1s works while futures reject it; Kraken encodes weeks as minutes; Coinbase answers in seconds. A cross-venue fetcher needs a per-venue interval map — there is no shared standard.

None of this makes one exchange better than another; it is just five independent design choices that your software has to know about.

Reproduce it yourself

Everything above is one request away: Binance GET /api/v3/klines?interval=8h plus the kline-intervals table in its spot REST docs; Bybit GET /v5/market/kline?interval=480 plus its kline docs page; OKX GET /api/v5/market/candles?bar=8H plus the bar enum in docs-v5; Kraken GET /0/public/OHLC?interval=480 plus the parameter table in its docs dump; Coinbase GET /products/BTC-USD/candles?granularity=28800. All measurements were taken 2026-10-16 02:05–02:25 UTC; exchanges can and do change enums without notice, so verify against the official sources above before you rely on any of it.

AI disclosure: This article was researched and drafted with AI assistance under a documented methodology (official documentation pages plus live key-free API probes, each cross-checked), then reviewed before publishing.

Not financial advice: This article describes public API behavior and documentation enums. It is not investment, trading, or tax advice, and nothing here recommends any exchange, order type, or strategy.

Affiliate disclosure (#ad): This publication may carry affiliate links in the future; any such link would be labeled #ad next to it. This article contains no affiliate, referral, or sponsored links.

Same BTC Perp, Two Leverage Ceilings: 150x on One Venue, 100x on the Other — Both Straight From the API

HMwork — Tue, 13 Oct 2026 02:17:01 +0000

Same BTC Perp, Two Leverage Ceilings: 150x on One Venue, 100x on the Other — Both Straight From the API

Disclosure: This article was written with AI assistance under human editorial review. Data below was pulled live from public exchange endpoints and may change at any time.

#ad / Affiliate disclosure: This article currently contains no affiliate links. If that ever changes, affiliate links will be marked clearly here and at each link.

Not financial advice. This is an observation about publicly published contract specifications, not a recommendation to use leverage, trade perpetual futures, or choose one venue over another. Leverage magnifies losses as fast as gains, and liquidation can erase your margin in a single candle.

The question, kept simple

Bitcoin's most traded derivative in crypto-native circles is the BTC/USDT perpetual futures contract. Nearly every major venue lists one, and the underlying is identical: one Bitcoin, priced against Tether.

But the rulebooks are not identical. A previous piece in this series compared funding-rate mechanics; this one asks a single, concrete question:

What is the maximum leverage the exchange itself advertises for its BTC/USDT perpetual — as published in its own public API, today?

Two of the largest venues answer without requiring a login, a key, or a page full of JavaScript. We queried both, twice each, on 13 October 2026 between 02:07 and 02:11 UTC.

Venue A: the field is called `maxLeverage`, and it says 150

Bybit publishes contract specifications through a authentication-free GET endpoint:

GET https://api.bybit.com/v5/market/instruments-info?category=linear&symbol=BTCUSDT

The relevant fields from our capture (identical in both requests, at 02:08 and 02:10 UTC):

Field	Value
`contractType`	`LinearPerpetual`
`status`	`Trading`
`settleCoin`	`USDT`
`leverageFilter.maxLeverage`	`150.00`
`leverageFilter.minLeverage`	`1`
`lotSizeFilter.minOrderQty`	`0.001` BTC
`lotSizeFilter.minNotionalValue`	`5` USDT
`upperFundingRate` / `lowerFundingRate`	`±0.00333`
`fundingInterval`	`480` minutes (8 hours)

So the headline number for the same contract: 150x.

Venue B: the field is called `lever`, and it says 100

OKX serves the same category of information through its own authentication-free endpoint:

GET https://www.okx.com/api/v5/public/instruments?instType=SWAP&instId=BTC-USDT-SWAP

Our capture (identical in both requests):

Field	Value
`instType` / `ctType`	`SWAP` / `linear`
`state`	`live`
`lever`	`100`
`ctVal` / `ctValCcy`	`0.01` `BTC` per contract
`minSz`	`0.01` contracts
`uly`	`BTC-USDT`
`settleCcy`	`USDT`

A companion endpoint, GET /api/v5/public/funding-rate?instId=BTC-USDT-SWAP, returned maxFundingRate = 0.00375 at the same moment — a useful cross-check that these are genuinely two independently maintained rulebooks sitting on top of the same underlying asset.

150 vs 100: what the gap actually means

The advertised ceiling differs by half again: 150x versus 100x, the same contract family, the same day, the same minute.

Three honest caveats before anyone treats this as a scoreboard:

The ceiling is an upper bound on a selector, not a promise. Both venues run tiered risk systems: as position size grows, the maximum leverage you can actually open drops in steps, and the maintenance-margin requirement that defines your distance to liquidation rises. The headline number typically applies only to the smallest position tier. (We have measured those staircases separately in an earlier piece; they are published on the very same public endpoints.)
The units are not the same. Bybit quotes order size directly in BTC (minOrderQty 0.001, a qtyStep of 0.001). OKX quotes in contracts: one BTC-USDT-SWAP contract (ctVal) is 0.01 BTC, and the minimum order (minSz) is 0.01 of a contract — one ten-thousandth of a coin. A naive script that reads "minimum size" from both APIs and compares the raw numbers is comparing coins to contracts.
A ceiling is not a risk comparison. We are not claiming either venue is safer, cheaper, or better. What we are claiming is narrow and checkable: the field exists, the field is public, and today the values read 150 and 100.

Why this belongs in the "fees are not the only fine print" series

Fee schedules get all the attention, yet the rulebook around a trade — maximum leverage, tick size, funding caps, order minimums, price collars — is a second layer of costs and constraints that differs from venue to venue far more than most traders expect. And crucially, most of it is now machine-readable: no login, no scraping of a JavaScript page, just a documented GET request whose answer is a number.

If you are comparing venues, the leverage field is one line in a table you can build yourself in ten minutes. The two endpoints above are the starting point.

Verify official sources

Do not take our word for any number in this piece. At any time you can re-run:

https://api.bybit.com/v5/market/instruments-info?category=linear&symbol=BTCUSDT — the maxLeverage and minNotionalValue fields
https://api.bybit.com/v5/market/tickers?category=linear&symbol=BTCUSDT — the fundingCap field (read 0.00333 at 02:07 UTC)
https://www.okx.com/api/v5/public/instruments?instType=SWAP&instId=BTC-USDT-SWAP — the lever, ctVal and minSz fields
https://www.okx.com/api/v5/public/funding-rate?instId=BTC-USDT-SWAP — the maxFundingRate field
Field definitions: the Bybit market-instruments documentation at bybit-exchange.github.io/docs/v5/market/instrument and the OKX API v5 documentation at www.okx.com/docs-v5/en/ — both fetched live at those addresses, HTTP 200, at 02:10 UTC on 2026-10-13

All figures in this article are values returned by those endpoints at 02:07–02:11 UTC on 13 October 2026. Exchanges revise specifications without notice. Always confirm against the venue's own endpoints and pages before acting on any specification.

Once more, plainly: this post is informational only and is Not financial advice. Perpetual futures with high leverage can lose more than your initial margin. Trade only what you can afford to lose, and verify everything.

Written with AI assistance; all numbers were machine-read from the cited official endpoints and double-checked in two independent fetches.

Same BTC Perp, Four Self-Reported Fee Schedules: Taker Fees 3.75x Apart — and One Venue Pays Its Makers

HMwork — Fri, 09 Oct 2026 02:20:59 +0000

Same BTC Perp, Four Self-Reported Fee Schedules: Taker Fees 3.75x Apart — and One Venue Pays Its Makers

Disclosure: This article was drafted with AI assistance from public exchange API data and reviewed before publishing. #ad — affiliate disclosure: this article contains no affiliate or referral links. Nothing below is investment or trading advice (not financial advice). All numbers are point-in-time snapshots from exchange-published endpoints; rules change without notice, so re-check the official sources named at the end.

The fee page you read is not the fee field the machine reads

Most traders learn exchange fees from a marketing-friendly fee page: a table of tiers, a footnote about VIP levels, maybe a promotional banner. Those pages are rendered with JavaScript, behind logins, and restructured every few months — which is why so many "exchange fee comparison" posts on the internet quietly copy each other.

But four exchanges publish something rarer: a base fee-rate field for perpetual contracts on a public, no-key API endpoint. The exchange itself reports the number, in a machine-readable field, and you can query it yourself in one request. We did exactly that on 2026-10-09 (02:10–02:14 UTC, two independent rounds, values identical between rounds), for the BTC/USDT perpetual at each venue. Four venues, four answers — and one of them is a negative maker fee.

The four readings

Venue	BTC perp symbol	Maker (base)	Taker (base)	Field names
Gate	BTC_USDT	-0.01%	0.075%	`maker_fee_rate` / `taker_fee_rate`
KuCoin	XBTUSDTM	0.02%	0.06%	`makerFeeRate` / `takerFeeRate`
MEXC	BTC_USDT	0%	0.02%	`makerFeeRate` / `takerFeeRate`
Bitget	BTCUSDT	0.02%	0.06%	`makerFeeRate` / `takerFeeRate`

Read the taker column first. On the same underlying asset, with the same USDT margin mode, a one-way taker print costs 0.02% at MEXC, 0.06% at KuCoin and Bitget, and 0.075% at Gate — a 3.75x spread between cheapest and dearest base reading. A round trip (open and close as a taker) is 4 basis points at one venue and 15 at another. That gap is the same order of magnitude as the entire maker/taker discount structure on many venues: before you optimize which side of the book you sit on, the venue choice already moved your cost by more.

A negative maker fee is not a typo

Gate's maker_fee_rate for BTC_USDT reads -0.0001. Gate's own published SDK documentation defines the field with the sentence "Maker fee rate, negative values indicate rebates" — so the minus sign is intentional: resting orders that get filled earn 0.01% instead of paying it. Across the venue's full contract set (1,028 symbols in our pull), every single contract reports the same -0.0001 maker / 0.00075 taker pair, and both of our fetch rounds agree, so this is a systematic base schedule, not a stale field on one symbol.

That gives us three distinct pricing philosophies on the maker side of the same product:

Pay makers (Gate, -0.01%): liquidity provision is subsidized.
Free for makers (MEXC, exactly 0%): resting costs nothing but earns nothing.
Charge makers (KuCoin and Bitget, +0.02%): passive orders still pay, just less.

"Free maker" and "negative maker" sound identical in a headline and are completely different line items in a PnL statement.

Second underlying, same shape

To confirm we were not reading a one-off symbol configuration, we repeated the pull for the ETH perpetual at all four venues: Gate ETH_USDT reports -0.0001 / 0.00075, KuCoin ETHUSDTM 0.0002 / 0.0006, MEXC ETH_USDT 0 / 0.0002, Bitget ETHUSDT 0.0002 / 0.0006. Same four-way pattern, same ordering on the taker side. The schedule differences are venue-wide policies, not per-coin quirks.

(One honest footnote from our own archive: when this pool first cross-checked MEXC's ETH reading back on 2026-09-08, the taker field showed 0.01%; today it reads 0.02%. Fee fields are live data — that is precisely why they should be re-queried, never quoted from memory.)

What these fields do not claim

Fairness requires four limits, and we will not paper over them:

Base tier only. Every venue layers VIP tiers, fee-card levels, and occasional campaigns on top. The numbers above are what the venues themselves label as the standing rate. MEXC even ships a feeRateType flag that distinguishes BASE from TEMP (promotional) rates, and BTC/ETH both read BASE — a rare, explicit admission of the base-versus-promo distinction.
Self-reported, not audited. These are the exchanges' own fields. We report what they publish, not what your invoice will say.
Two venues do not play. Kraken, Coinbase, OKX, Bybit and Binance either gate their perp fee fields behind authentication or never expose them publicly, so they cannot appear in this comparison at all. Absence here is an API-transparency fact, not a verdict.
Not a ranking. The cheapest base taker rate on paper may come bundled with other trade-offs (spread, depth, funding rules, region availability). Two venues happened to print identical numbers (KuCoin and Bitget, 0.02/0.06) while differing elsewhere — for instance, KuCoin's own contract data shows maxLeverage 125 consistent with initialMargin 0.008 (1 ÷ 0.008 = 125), a self-consistency check of its published fields.

Why this matters for a fee-atlas mindset

Every cost you can see on a fee page has usually already been reformatted for persuasion. The API fields are the exchange talking to machines: terse, unsigned where the marketing copy would never put a minus sign, and identical whether or not anyone is reading. When four venues say 0.02%, 0.06%, 0.06% and 0.075% about the same BTC perpetual, the fee page stops being a detail and starts being the product.

The lesson is mechanical, not editorial: before you compare venues, pull the numbers from the source that has no reason to round them up — and pull them again the day you act, because these fields move.

Verify official sources

Do not trust this article. Reproduce it:

Gate: GET https://api.gateio.ws/api/v4/futures/usdt/contracts (fields maker_fee_rate, taker_fee_rate; field semantics defined in Gate's published SDK docs, docs/Contract.md)
KuCoin: GET https://api-futures.kucoin.com/api/v1/contracts/XBTUSDTM (fields makerFeeRate, takerFeeRate, maxLeverage, initialMargin)
MEXC: GET https://contract.mexc.com/api/v1/contract/detail?contract_code=BTC_USDT (fields makerFeeRate, takerFeeRate, feeRateType)
Bitget: GET https://api.bitget.com/api/v2/mix/market/contracts?productType=usdt-futures (fields makerFeeRate, takerFeeRate)

All four are unauthenticated, published by the exchanges themselves, and queried here at 02:10–02:14 UTC on 2026-10-09 (two rounds, identical results). If a field disagrees with the venue's own fee page, the fee page — or your account's tier — wins. Always verify official sources.

This post is for education and transparency around public market-data fields only. It is not investment, trading, tax or legal advice (not financial advice). Leveraged perpetual contracts can lose more than you deposit. AI-assisted drafting; affiliate disclosure per the note at the top (#ad: none present in this article).

Same Wrong Request Type, Four Different Answers: 404 Silence, a Named 405, and Two Venues That Simply Do Not Care

HMwork — Tue, 06 Oct 2026 02:20:31 +0000

Same Wrong Request Type, Four Different Answers: 404 Silence, a Named 405, and Two Venues That Simply Do Not Care

By FeeAtlas — an independent, neutral researcher of exchange fee and specification data. No affiliations with any venue named here.

Disclosure: this article was drafted with AI assistance from measurements taken directly against the exchanges' own public endpoints. Every number and response body quoted below was captured live and can be reproduced by you in under a minute.

Ad/affiliate disclosure (#ad): this site participates in affiliate programs. There are no affiliate or sponsored links in this article — every link is a link to an official exchange document, placed for verification purposes only.

Every trading API tutorial eventually hits the same wall: you sent a POST where the endpoint wanted a GET. On the open web, HTTP gives a clean, standardized answer — status 405, "Method Not Allowed." Case closed.

Crypto exchanges, it turns out, hold four completely different opinions about what should happen. Some do not have the concept at all.

The experiment: one wrong button, pressed five times

Five exchanges expose a clock endpoint that requires no account and no API key: a GET that returns the server's current time. For this test, each endpoint received the same request it did not ask for — an empty POST — twice, on two independent rounds, about one minute apart. Nothing else changed: same machine, same browser-like request header, no body, no credentials.

Measured live on 2026-10-06 at 02:08–02:09 UTC (first detection round: earlier the same day at 00:44–00:55 UTC, identical outcomes).

Answer 1 — Binance: 404, and a completely empty body

POST https://api.binance.com/api/v3/time → HTTP 404, zero bytes returned. Both rounds, exactly the same.

The subtlety is worse than the 404 itself. GET a path that genuinely does not exist on Binance and you also get a 404 with an empty body. The response cannot tell you whether your path is wrong or your method is wrong — "typo in URL" and "wrong verb" collapse into one indistinguishable silence.

Answer 2 — Bybit: 200, and it hands you the time anyway

POST https://api.bybit.com/v5/market/time → HTTP 200 with the same JSON you would get from a GET: retCode: 0, timeSecond, timeNano. The public market endpoints simply do not check the verb. Both rounds identical.

This is friendly the way an unlocked door is friendly. Your script has a bug, and the API rewarded it with success. The bug now lives silently in your codebase until it meets an endpoint that does check.

Answer 3 — OKX: 405 with a name you can grep for

POST https://www.okx.com/api/v5/public/time → HTTP 405 with body:

{"code":"50115","data":[],"msg":"Invalid request type"}

Byte-identical across both rounds. OKX is the only venue of the four that (a) uses the semantically correct 405 status and (b) wraps it in its usual machine-readable envelope with a named error code. The code is documented: re-checking OKX's own docs-v5 error table today (5,247,990 bytes, fetched and searched live) confirms 50115 is listed. If you build per-venue error-handling maps, this is the only venue that hands you a key to put in the map.

Answer 4 — Kraken: 200, and it isn't even pretending

POST https://api.kraken.com/0/public/Time → HTTP 200, same JSON as GET: unixtime and rfc1123. Both rounds.

Kraken's tolerance is at least consistent with its own published self-description: its documentation states that HTTP status codes are generally not used by its API to convey information (errors arrive inside the JSON error array instead). A verb check would be out of character.

The fifth answer that isn't about methods at all

POST https://api.exchange.coinbase.com/time → HTTP 401 {"message":"Unauthorized."} — while GET on the very same path returns 200 with the time.

Read that carefully: the response talks about credentials, not method. Whatever Coinbase does internally, its rejection never mentions the verb, so it tells you nothing about how that venue handles method errors. I record it as a fifth shape — a rejection that answers a question you did not ask — rather than counting it in the four-way comparison. Re-probed a third time: same 401.

Results table (measured 2026-10-06, two rounds each)

Venue	GET /time	POST /time	Dialect
Binance	200, `{"serverTime":...}`	404, 0 bytes	Ambiguous silence
Bybit	200, full time JSON	200, same JSON	No verb check at all
OKX	200, `code:"0"`	405, code `50115`	Proper 405 + named code
Kraken	200, time JSON	200, same JSON	Status codes carry no meaning (self-documented)
Coinbase	200, iso+epoch	401, "Unauthorized."	Credential-flavored rejection, method unmentioned

Why this matters beyond a chuckle

If you maintain one client that talks to several venues — a fee tracker, a monitoring bot, a backtest data pipe — "wrong HTTP method" is the layer where no shared handling exists. One venue gives a 404 indistinguishable from a bad URL. Two give a success you did not earn. One gives a documented code. One gives an error about something else entirely.

Three practical habits fall out of the table:

Parse bodies, not just status codes. A 200 here can mean "you used the wrong verb and nobody noticed." Trusting status codes across venues is exactly the mistake Kraken's own docs warn about.
Log raw responses during development. Bybit's and Kraken's tolerance turns method typos into silent drift that surfaces only when a different endpoint on the same venue does enforce the verb.
Expect the empty-404 class. Where a venue cannot distinguish "no such path" from "wrong verb" (Binance today), keep a local list of known-good method/path pairs instead of trusting error feedback.

None of this makes one venue's API "better." It is one more reminder, in the same family as tick sizes, price collars and rate-limit stopwatches we've measured before: each exchange writes its own rulebook, including for the parts the HTTP RFC was supposed to have settled decades ago.

Reproduce it yourself

Open a terminal and run, for each venue, one GET and one POST with a browser-like user agent, and compare the status lines. Five URLs:

https://api.binance.com/api/v3/time
https://api.bybit.com/v5/market/time
https://www.okx.com/api/v5/public/time
https://api.kraken.com/0/public/Time
https://api.exchange.coinbase.com/time

Verify official sources

Numbers in this article are live observations, not quotes from press releases. Before relying on any endpoint behavior, check the venues' own current documentation:

Binance spot API docs (error definitions including the -1xxx parameter family): github.com/binance/binance-spot-api-docs
Bybit V5 docs (market/time endpoint, rate limits): bybit-exchange.github.io/docs/v5/
OKX V5 API docs (error code table including 50115): okx.com/docs-v5/en/
Kraken API docs (response format and error convention): docs.kraken.com
Coinbase Exchange API docs: docs.cdp.coinbase.com

Exchange behavior changes without notice. What you can verify in one terminal command is worth more than any summary, including this one.

This article is provided for information and technical reference only. It is **not financial advice, not a recommendation of any exchange, and contains no trading guidance. Exchange API specifications and behaviors change at any time; always confirm against the official documentation of each venue.

One Concept, Four Field Names, Three Numbers: The Funding-Rate Ceiling on the Same BTC Perp

HMwork — Sun, 04 Oct 2026 13:46:34 +0000

One Concept, Four Field Names, Three Numbers: The Funding-Rate Ceiling on the Same BTC Perp

Disclosure: this article was researched and drafted with AI assistance, using public exchange APIs and documentation, and reviewed for accuracy against the sources cited below.

This is not financial advice. All numbers below are parameter values read from public exchange APIs at a specific moment in time. Exchanges can and do change these values without notice. Always verify against the official sources listed at the end.

The number everyone quotes doesn't exist

Ask five traders what the maximum funding rate on a Bitcoin perpetual is and you'll get a confident shrug. There is no industry-wide ceiling. Funding-rate caps are per-exchange, per-contract parameters — and even for the single most liquid contract in crypto, the BTC/USDT perpetual, the four venues examined here publish three different answers under four different field names.

I pulled all of them live, without an API key, from official public endpoints on October 4, 2026 at 13:37 UTC. Here is what the same concept looks like at four exchanges.

The four readings, side by side

Venue	Field name(s)	BTC perp cap	ETH perp cap	Settlement interval
Gate	`funding_rate_limit`	±0.30%	±0.30%	28800 s (8 h)
KuCoin	`fundingRateCap` / `fundingRateFloor`	±0.30%	±0.375%	28800000 ms (8 h)
Bybit	`upperFundingRate` / `lowerFundingRate` (specs) + `fundingCap` (tickers)	±0.333%	±0.333%	480 min (8 h)
OKX	`maxFundingRate` / `minFundingRate`	±0.375%	±0.75%	8 h

Three numerical answers for the identical underlying exposure: 0.30%, 0.333%, and 0.375%. The spread between the lowest and highest cap is 25% — small in absolute terms, but it defines how far an overheated or capitulating market can push the cost of holding a position before the ceiling bites.

Live funding values at the same moment, for context (these change every interval and are not the point of this article): Gate BTC perp −0.0017%/8h, Bybit +0.006547%/8h, OKX +0.0027116%/8h, KuCoin −0.0002%/8h.

Four names for one concept

If you are writing any tooling that compares funding terms across venues, the field names alone will humble you:

Gate exposes funding_rate_limit in its futures contracts model. The field's meaning is confirmed in Gate's own public API documentation changelog, which added the field "to indicate funding rate cap value."
Bybit publishes the same parameter twice under two names: upperFundingRate/lowerFundingRate in the instruments-specification endpoint, and fundingCap in the tickers endpoint. On October 4 both endpoints returned 0.00333 for BTCUSDT — a useful internal cross-check you can reproduce yourself.
OKX calls it maxFundingRate/minFundingRate on its funding-rate endpoint.
KuCoin uses fundingRateCap/fundingRateFloor — and note the data types differ too: KuCoin returns numbers, while Gate, Bybit, and OKX return strings.

One concept, four spellings, two data types. There is no standard.

The ETH side is where the philosophies split

The BTC caps differ, but the more interesting divergence is on the second-most liquid contract. At the same moment:

OKX sets ETH's cap at ±0.75% — exactly double its own BTC cap of ±0.375%.
KuCoin sets ETH at ±0.375% — exactly double its own BTC cap of ±0.30%.
Gate (±0.30%) and Bybit (±0.333%) give ETH the same ceiling as BTC.

So two venues deliberately price volatility headroom by asset, and two treat majors as one class. Neither approach is right or wrong — but it means "the cap on this exchange" is not a single number you can memorize per venue. It is a matrix: venue × contract.

Why the ceiling matters even if you never see it

Most funding intervals settle near zero — a few basis points every eight hours. The caps are invisible in calm markets. They matter in the tails: when a crowded position unwinds, funding can pin at the cap for consecutive intervals, and that pinned value is your holding cost, compounding every settlement period. A position on the venue with a 0.30% cap faces a structurally different worst-case carrying cost than the same position where the cap is 0.375% — and, as previous measurements in this series have shown, some exchanges settle smaller contracts hourly or every four hours, where the same cap applied more often multiplies the effect.

Two caveats that deserve repetition: the caps are parameters exchanges can adjust at will, and the interval length is a separate field you must read before comparing any two caps. "0.333% every 8 hours" and "2.5% every 1 hour" are not comparable numbers.

How to verify every number in this article

No login or API key is needed for any of it:

Gate: GET https://api.gateio.ws/api/v4/futures/usdt/contracts/BTC_USDT (and ETH_USDT) — read funding_rate_limit.
Bybit: GET https://api.bybit.com/v5/market/instruments-info?category=linear&symbol=BTCUSDT — read upperFundingRate; cross-check GET https://api.bybit.com/v5/market/tickers?category=linear&symbol=BTCUSDT — read fundingCap.
OKX: GET https://www.okx.com/api/v5/public/funding-rate?instId=BTC-USDT-SWAP (and ETH-USDT-SWAP) — read maxFundingRate.
KuCoin: GET https://api-futures.kucoin.com/api/v1/contracts/XBTUSDTM (and ETHUSDTM) — read fundingRateCap.

Snapshot taken 2026-10-04 13:37 UTC. If you re-run these calls next week and the numbers moved, that is the exchange exercising the very parameter this article describes — not an error in the measurements.

Not financial advice. This article describes publicly published contract parameters. It makes no recommendation to trade, hold, or move positions on any venue named. Perpetual futures involve substantial risk of loss. Funding rates, caps, and settlement intervals change without notice.

#ad — affiliate disclosure: no sponsored or tracked links appear in this article; no exchange named here has paid for inclusion. If this publication adds such links in the future, they will be marked the same way, before the link.

Verify official sources: always confirm current terms directly on each exchange's official API documentation and fee pages before relying on any number — exchanges revise these parameters at their discretion.

Your Dollar Is Not a Dollar: USDT Trades at a Measurable Discount Right Now

HMwork — Fri, 25 Sep 2026 02:13:55 +0000

Your "Dollar" Is Not a Dollar: USDT Trades at a Measurable Discount Right Now

Disclosure: This article was researched and drafted with AI assistance, then checked against primary sources listed at the end. Nothing here is investment advice — this is an observation of publicly available numbers. This publication may carry affiliate links in the future; at the time of writing, this article contains no affiliate or sponsored links (#ad disclosure: none present).

If you hold stablecoins, you probably treat one USDT as one dollar. The market disagrees — not dramatically, not dangerously, but consistently. Right now, at the moment of writing, three independent price sources all say the same thing: USDT trades a few basis points under the face value of a US dollar, and the exact discount depends on where you ask.

This is not a prediction about depegs, solvency, or risk. It is simply a measurement, taken live from public endpoints, of a friction that sits below most people's radar — and next to your fee schedule, it is a real cost line.

The measurement: three sources, one minute apart

On 2026-09-25 at 02:07–02:08 UTC, we queried three independent public sources within one minute of each other.

1. Kraken spot market (USDT/USD). The official public ticker endpoint returned a bid of 0.99967 and an ask of 0.99968. The midpoint is 0.999675 — about 3.3 basis points below par. The 24-hour range printed on the same response was tight: low 0.99964, high 0.99971.

2. Coinbase Exchange (USDT-USD). The official public ticker endpoint returned bid 0.99971 / ask 0.99972, a midpoint of 0.999715 — about 2.9 basis points below par. The stats endpoint for the same product showed a 24-hour open of 0.99983 and a low of 0.99875: at its worst moment of the day, USDT sold at a 12.5 basis point discount on this venue.

3. CoinGecko (aggregated reference price). The simple-price endpoint returned Tether at $0.999725 (about 2.75 bps under), alongside USDC at $0.999809 and DAI at $0.999957.

We repeated the two exchange queries twice each, two seconds apart; the numbers came back identical, so this is not a one-frame fluke of a single request.

What the numbers actually say

Three independent sources — two exchange order books and one aggregator — agree on direction and magnitude: USDT currently changes hands for roughly 0.9997 US dollars. The order books are extremely tight (Kraken's bid-ask spread is one ten-thousandth of a dollar wide), so this is not a liquidity artifact. It is simply where the "dollar" that is USDT clears.

Two subtleties worth naming:

The discount is small but persistent. At the moment of writing it is ~3 bps; earlier the same day, Coinbase's own stats show it briefly reaching ~12.5 bps. Stablecoin discounts breathe with market stress and tend to widen exactly when holders want out.
The discount is not uniform. USDC's aggregated price ($0.999809) and DAI's ($0.999957) show smaller haircuts than USDT's ($0.999725) at the same minute. Different "dollars", slightly different discounts.

Why this belongs next to the fee table

Most people compare exchanges by maker/taker fees. But if your balance sheet is denominated in USDT and your life is denominated in USD, then every round trip — sell your USDT to withdraw to a bank, for example — starts from a number below 1.0000. Three basis points sounds trivial until you notice it is the same order of magnitude as the maker fees on the deepest trading pairs. On the same day, the best-published maker tiers at major venues run in the tens of basis points, so the stablecoin discount is a meaningful fraction of a full trading cost stack — and unlike a fee schedule, it is invisible because no invoice ever shows it.

For context (measured in our earlier work, same kind of public-endpoint snapshots): a USDC/USDT cross also refuses to trade at exactly par, printing about 2–3 bps the other way. In other words, none of the "dollars" in crypto are interchangeable at exactly 1:1 with each other, or with the real one. They are all just very well-behaved, very slightly discounted claims.

What we deliberately do not claim

No depeg prediction. A 2–5 bps discount is normal, observable behavior; nothing here says anything about future stability of any token.
No ranking of venues. Kraken printing 3.3 bps and Coinbase 2.9 bps is within the noise of different order books at different seconds; it is not evidence that one venue is "cheaper".
No snapshot longevity. These numbers were true at 02:08 UTC on 2026-09-25. Stablecoin premia move constantly. Re-measure before acting on any of this.
This is not financial advice. It is a reading of public data, offered so that the number 1.0000 stops being an assumption.

Try it yourself

Every number above came from an unauthenticated public API — you can reproduce all of it in a terminal or a browser in under a minute: Kraken's Ticker endpoint for the pair USDTZUSD, Coinbase Exchange's /products/USDT-USD/ticker and /products/USDT-USD/stats, and CoinGecko's simple/price endpoint for tether,usd-coin,dai. Take the midpoint of each bid/ask, subtract from 1.0000, multiply by 10,000, and you have the discount in basis points. If your numbers differ from ours, that is the point: the discount is a live number, not a constant.

Verify official sources. All figures in this article are quoted from the primary sources themselves, timestamped 2026-09-25 02:07–02:08 UTC, and readers are encouraged to re-fetch them directly:

Kraken public ticker API: https://api.kraken.com/0/public/Ticker?pair=USDTZUSD
Coinbase Exchange public ticker: https://api.exchange.coinbase.com/products/USDT-USD/ticker
Coinbase Exchange public stats: https://api.exchange.coinbase.com/products/USDT-USD/stats
CoinGecko public price endpoint: https://api.coingecko.com/api/v3/simple/price?ids=tether,usd-coin,dai&vs_currencies=usd

AI-assisted content. Market data snapshots are momentary and change constantly. Nothing in this article is investment advice, a recommendation, or a solicitation to trade any asset. No affiliate links are present in this article.

The Same Bitcoin Answers to Three Tickers — and One Exchange Uses Two of Them Under Its Own Roof

HMwork — Tue, 22 Sep 2026 02:26:18 +0000

By FeeAtlas — neutral exchange-plumbing research. No sponsored placements in this article.

Ask three exchanges for the price of Bitcoin and you will get three numbers within a few basis points of each other. Ask their APIs for Bitcoin itself, and you will get three different words back — and one of those exchanges uses two different words depending on which product you touch. This is not a trivia question. It is the first wall every cross-exchange script hits, and it is documented in none of the fee tables.

On 2026-09-22 we queried the public, no-key endpoints of Kraken, KuCoin and Coinbase Exchange in the same session. Everything below is a literal field value or a literal error string from those endpoints, so you can repeat every check yourself.

Kraken: the asset is XXBT, the label is XBT

Kraken's asset registry returns the canonical code XXBT:

GET /0/public/Assets?asset=XXBT returns a record whose altname field is XBT.
GET /0/public/AssetPairs?pair=XXBTZUSD returns a pair whose base is XXBT, whose altname is XBTUSD, and whose WebSocket name (wsname) is XBT/USD.

So under one roof there are already two spellings: XXBT in the REST asset/pair identifiers, XBT in display names and the WebSocket stream names. A REST script that hard-codes BTC gets nothing; a WebSocket script that hard-codes XXBT/USD gets rejected. Both spellings are "correct" — in different halves of the same API.

KuCoin: spot says BTC, futures say XBT — and each half rejects the other's spelling

KuCoin is the most instructive case, because the split runs through the middle of one company's product line.

Spot side:

GET /api/v1/currencies/BTC returns a normal record (precision 8, withdrawal fields present).
GET /api/v1/currencies/XBT returns error code 900003 with the literal message: "XBT currency does not exist."

Derivatives side (a different host, api-futures.kucoin.com):

GET /api/v1/contracts/XBTUSDTM returns the perpetual with symbol: "XBTUSDTM" and baseCurrency: "XBT".
GET /api/v1/contracts/BTCUSDTM returns error code 404000 with the literal message: "The contract information you requested does not exist."

Read those two negative responses together with the two positive ones and the picture is unambiguous: the same company calls spot Bitcoin BTC and futures Bitcoin XBT, and each service will tell you, in as many words, that the other service's spelling does not exist. There is no alias translation layer between them. A portfolio tool that resolves "BTC" once and reuses the result across spot and perpetuals must special-case this venue.

Coinbase Exchange: only BTC-USD has ever lived here

Coinbase Exchange keeps it simple, in its own way:

GET /products/BTC-USD returns an online product with base_currency: "BTC".
GET /products/XBT-USD returns HTTP 404 with the body {"message":"NotFound"}.

No XBT spelling exists on this venue at all. The full product list (public, no key) contains no XBT-prefixed pairs — the ticker namespace is consistently BTC.

Why this matters beyond trivia

1. Cross-venue mapping is not optional. Three independent venues, three regimes: XXBT/XBT (Kraken, REST vs WebSocket), BTC on spot but XBT on perpetuals (KuCoin, spot vs derivatives), and plain BTC everywhere (Coinbase). A symbol-resolution table is table stakes before any comparison logic — fee, spread, or depth — can run.

2. The split can happen inside one roof. The KuCoin case is the genuinely surprising finding: you cannot even cache "what does this venue call Bitcoin" at the venue level. The correct answer is per-product-line.

3. Error handling tells you the truth. Both KuCoin negatives come back as explicit, greppable error strings ("XBT currency does not exist." / "The contract information you requested does not exist."). If you are building the mapping table from scratch, probing candidate spellings and reading the error messages is a legitimate discovery method — it is exactly what we did.

4. This is not a one-token problem. If Bitcoin — the most liquid, most-listed asset in the industry — cannot settle on one symbol, assume nothing about the long tail. Stablecoins, wrapped tokens and tokenized equities inherit the same naming autonomy, often worse.

What we deliberately did not do: explain why the three-letter code XBT exists at all. That story gets retold often, but we could not verify it against two reachable primary sources today, and FeeAtlas does not publish what it cannot cross-check. The observable facts — which endpoints accept which spelling, and what the rejection messages say — stand on their own.

Method and reproducibility

All values above were captured on 2026-09-22 (around 02:2x UTC) from the public, authentication-free endpoints of the three venues, with repeat fetches confirming identical responses. Ticker conventions can change without notice; re-run the calls before building anything on them.

AI-assisted research and drafting; human-owned channel reviewed the output.
This article contains no affiliate links — there are currently no sponsored placements or referral arrangements attached to it. Any future sponsored content will be labeled with #ad.
Not financial advice. This is a technical observation about public API interfaces, nothing more.

Verify with official sources

Do not take our word for any of it — every claim is one unauthenticated request away:

Kraken public API: api.kraken.com/0/public/Assets and /0/public/AssetPairs
KuCoin spot API: api.kucoin.com/api/v1/currencies/{currency}
KuCoin futures API: api-futures.kucoin.com/api/v1/contracts/{symbol}
Coinbase Exchange API: api.exchange.coinbase.com/products/{product-id}

The index is public; the recipes are yours to check.

One Page, Two Pricing Philosophies: 0.25% Flat on Perps, Tiered 0.40%/0.80% on Spot

HMwork — Fri, 18 Sep 2026 02:22:48 +0000

One Page, Two Pricing Philosophies: Kraken Charges 0.25% Flat on Perps but Tiered 0.40%/0.80% on Spot

A neutral fee-research note — no sponsored content, no position held.

AI disclosure: This article was researched and drafted with AI assistance under human editorial review. All quoted figures were fetched directly from the sources cited and re-checked on the publication date.

Disclosure (#ad / affiliate): This article currently contains no affiliate or sponsored links. If that ever changes, a visible #ad / affiliate disclosure will be placed before any such link.

Most people read an exchange fee page looking for one number. Kraken's fee page is interesting precisely because it refuses to give you one: on the same URL, at the same time, the same company publishes two completely different pricing philosophies — a flat fee on one product and a two-axis tiered ladder on another. Both are quoted verbatim below, and you can verify every figure yourself in about two minutes.

The flat side: "simple" Perps cost 0.25% per side

Kraken's fee schedule page (kraken.com/features/fee-schedule, fetched 2026-09-18) describes its simple perpetuals product in two sentences:

"A 0.25% fee is applied to the notional value of the trade to open the position. A 0.25% fee is applied to the closed notional value of the trade to close the position."

Notice what that structure means:

Round trip = 0.50% of notional, paid whether you opened as a maker or a taker.
No maker discount. Resting liquidity earns nothing extra here.
No volume discount. The rate does not step down as you trade more.

As a cross-check on stability, the same sentences appear word-for-word in an Internet Archive snapshot of the same page from 2026-08-20 (snapshot id 20260820055608) — so this is not a one-day promotion, it is a standing product design.

The tiered side: the order-book ladder

Scroll a little further on the same page and you are in a different world. Kraken's Pro / order-book pricing is a classic two-dimensional ladder: maker vs. taker rates, banded by 30-day trading volume (and, in the newer presentation, platform assets). The page currently prints two tier tables side by side — a legacy table and the "Cross-platform fee tiers" table that the page announces was "recently introduced". Both begin like this:

Tier	Spot 30-day volume	Legacy Maker / Taker	Cross-platform Maker / Taker
Tier 1	$0+	0.40% / 0.80%	0.38% / 0.80%
Tier 2	$2.5K+	0.30% / 0.60%	0.28% / 0.60%
Tier 3	$10K+	0.22% / 0.38%	0.20% / 0.38%

(Both tables, including the small maker-rate difference at Tier 1-2 between them, are visible in the live page and in the 2026-08-20 archive snapshot. The page itself does not state which of its two tables governs which checkout flow, so this article simply reports what is printed and does not pick a winner.)

The ladder keeps descending: by the higher tiers the maker rate reaches 0.0x% territory while taker stays materially above it — maker/taker is treated as two independent levers, and volume is rewarded on both.

What the same page admits about "simple"

Put the two halves next to each other and the marketing framing of a flat 0.25% "simple perps" fee starts to look like a trade-off rather than a discount:

A high-volume maker on the order-book side pays 0.22% or less from just $10K of monthly volume (Tier 3) — already cheaper than the flat 0.25%, and the ladder keeps going down while the flat fee never moves.
At Tier 1, the flat 0.25% is actually cheaper than the 0.80% taker rate on spot's first tier. For an occasional taker, the "simple" product is the cheaper door; for an occasional maker it is roughly comparable; for anyone who grows, it becomes the more expensive one by design.
The real cost of the simple product is not the headline number — it is the forfeited option to earn maker pricing and to graduate down a ladder.

None of this makes one product "better." A flat per-side fee is predictable and easy to reason about, which has genuine value for someone starting out. The point of reading both halves of the page is simply to know which knob you gave up.

The honest footnote

For completeness: Kraken's public asset-pairs API has historically exposed a separate fee-ladder field whose numbers did not match either table on the fee page, and this observer has previously seen the page and the API disagree. This article deliberately relies only on the fee page text (live fetch plus an archive snapshot from a different date), and flags the API/page mismatch as an unresolved transparency wrinkle rather than using any of those API numbers as a comparison. Treat every rate on any exchange as "as published, subject to change" — pages get revised without notice.

Not financial advice

This article is fee-schedule journalism for developers and cost-aware users. It is not financial advice, not investment advice, and not a recommendation to trade perpetuals, use any named exchange, or adopt any order strategy. Perpetual contracts involve substantial risk, including loss of more than your deposit. Fee tiers, product availability ("currently available in certain geos"), and rules change at the exchange's discretion.

Verify with official sources

Do not take this article's word for anything. Before acting on any number here, check the primary sources directly:

Kraken fee schedule page: https://www.kraken.com/features/fee-schedule (the perps paragraph and both tier tables)
Internet Archive snapshot 20260820055608 of the same page (independent earlier time point)
Kraken's own support articles, linked from the fee page itself, for tier-eligibility details

Data snapshot: live page fetched 2026-09-18; all quotations re-checked on that date.

Four Exchanges, Three Timestamp Units: Seconds, Milliseconds, Nanoseconds — and One Gives You Two at Once

HMwork — Tue, 15 Sep 2026 02:17:53 +0000

Four Exchanges, Three Timestamp Units: Seconds, Milliseconds, Nanoseconds — and One Gives You Two at Once

Disclosure: this article was researched and drafted with AI assistance, then checked against primary sources listed at the end. All figures below were pulled live from official public API endpoints on 2026-09-15 between 02:09:16 and 02:09:22 UTC.

If you have ever written code that talks to more than one crypto exchange, you have probably hit this bug: your signed request is rejected with something like "signature does not match" or "timestamp outside recvWindow", even though your key is correct, your signature algorithm is correct, and your clock is perfectly synchronized. Nine times out of ten, the problem is not your signature. It is your unit.

There is no industry standard for what "a timestamp" means in an exchange API. Four of the largest venues each made a different choice — and one of them gives you three precisions in the same response.

The live measurement

On 15 September 2026, within a single six-second window, we called the public time endpoint of four exchanges. No API key required — you can reproduce every number yourself.

Binance — GET /api/v3/time

{"serverTime": 1789438156343}

Thirteen digits. That is milliseconds since the Unix epoch.

Kraken — GET /0/public/Time

{"error": [], "result": {"unixtime": 1789438157, "rfc1123": "Tue, 15 Sep 26 02:09:17 +0000"}}

Ten digits — seconds — plus a human-readable RFC 1123 string as a bonus field. Kraken's own official documentation page for this endpoint uses the same 10-digit format in its example response ("unixtime": 1688669448), so the seconds convention is confirmed at the documentation layer, not just inferred from digit counts.

Bybit — GET /v5/market/time

{"retCode": 0, "retMsg": "OK",
 "result": {"timeSecond": "1789438157",
            "timeNano": "1789438157667206123"},
 "time": 1789438157667}

This one is a small masterpiece of confusion: the same response object carries seconds (timeSecond), nanoseconds (timeNano, 19 digits), and — in the outer envelope field time — milliseconds. Three precisions, one call. Bybit's official docs define each field in plain text: "timeSecond string Bybit server timestamp (sec)" and "timeNano string Bybit server timestamp (nano)".

OKX — GET /api/v5/public/time

{"code": "0", "data": [{"ts": "1789438159520"}], "msg": ""}

Thirteen digits again, so milliseconds — but note it arrives as a string, not a number. OKX is also the most explicit venue of the four: its REST documentation labels timestamp fields individually, thousands of times over, with lines like "Unix timestamp format in milliseconds, e.g. 1597026383085".

Cross-check: converting all four readings to a common unit, the four servers agreed to within about one second — the spacing of our own requests. The exchange clocks are in sync. The only disagreement is about units.

Why this bites you twice

First bite: parsing the server time. If you naively do datetime.fromtimestamp(serverTime) on Binance's 13-digit value, you get a date roughly 57,000 years in the future. Divide by 1,000? Fine for Binance and OKX, wrong for Kraken, wrong for Bybit's timeNano.

Second bite, and the expensive one: signing requests. The timestamp you sign must match what the server expects, in the unit the server expects:

Binance's official REST documentation states that SIGNED requests require a timestamp parameter "in milliseconds or microseconds" — yes, either one, but not seconds — with a default recvWindow of 5,000 ms.
OKX requires the OK-ACCESS-TIMESTAMP header and rejects requests whose timestamp differs from server time by more than 30 seconds.
Bybit validates your request timestamp against its own clock with a receive-window header in milliseconds.

The classic failure mode: you fetch Kraken's time (seconds), reuse the same helper for a Bybit signature (milliseconds), and your timestamp is a factor of 1,000 too small — instantly outside any reasonable receive window. The error message mentions signatures, so you debug signatures for a day. The bug was arithmetic.

The practical rule this creates for any multi-venue codebase: a per-exchange conversion constant — multiply by 10⁰, 10³, or 10⁹ depending on the venue — and a unit test that asserts the digit count of every timestamp before it is ever signed. Digit counting is a cheap, brutal sanity check: 10 digits means seconds, 13 means milliseconds, 16 means microseconds, 19 means nanoseconds.

Two subtleties worth remembering from the live data above: Bybit's triple-precision response means "the Bybit timestamp" is not one thing — pick the field deliberately. And Binance allowing either milliseconds or microseconds for signatures means two valid clients can look completely different in the logs, which matters when you are diffing a broken request against a working one.

What the docs say (so you don't have to guess)

Every claim above has a documentation layer, not just an observed value: Kraken's Get Server Time page shows a 10-digit example; Bybit's market-time page defines timeSecond and timeNano verbatim; OKX's docs label "Unix timestamp format in milliseconds" on individual fields; Binance's spot API spec states the milliseconds-or-microseconds rule for signed requests. Endpoint paths and quoted field names are listed in the sources below, so any of this can be re-checked in about thirty seconds by calling the endpoints yourself.

None of the four choices is wrong. There is simply no standard — so your abstraction layer has to carry the unit as a first-class attribute, not assume it. Before you write the converter, read the docs' unit. It is the cheapest bug you will ever prevent.

Sources (all official, all fetched 2026-09-15 02:09 UTC unless noted):

Binance public time endpoint: GET https://api.binance.com/api/v3/time (live value above); Binance official REST spec (binance-spot-api-docs/rest-api.md) on timestamp/recvWindow rules.
Kraken public time endpoint: GET https://api.kraken.com/0/public/Time (live value above); Kraken official "Get Server Time" documentation page (example response in seconds).
Bybit public time endpoint: GET https://api.bybit.com/v5/market/time (live value above); Bybit official v5 market-time documentation (timeSecond/timeNano field definitions).
OKX public time endpoint: GET https://www.okx.com/api/v5/public/time (live value above); OKX official REST v5 documentation (per-field millisecond labeling).

AI disclosure: This article was produced with AI assistance under a two-source verification process; every number was re-fetched from the official endpoints listed above immediately before publication.

Not financial advice. This is a technical article about API specifications. Nothing here is investment, trading, or legal advice. Exchange endpoints, fields, and rules change without notice — verify against each venue's current official documentation before building anything on top of them.

No affiliate or referral links appear in this article.

Verify with official sources: api.binance.com · api.kraken.com · api.bybit.com · www.okx.com/docs-v5

Same Minute, Five Prices: What Bitcoin Actually Costs Depends on Where You Ask

HMwork — Tue, 08 Sep 2026 02:08:33 +0000

Same Minute, Five Prices: What Bitcoin Actually Costs Depends on Where You Ask

Disclosures for this article are at the bottom — please read them. In short: this article was drafted with AI assistance, it contains no sponsored links, and nothing here is financial advice.

Ask five major exchanges what one Bitcoin costs and you will not get one answer. You will get a small pile of answers, and the gap between the highest and the lowest is not a rounding error — it is about the same size as the trading fee you would pay to move between them.

We queried five exchange venues within the same minute on 2026-09-08, 02:03–02:04 UTC, using only their free, no-login public market-data endpoints. Every number below is a raw value returned by the venue's own API, and you can reproduce the whole experiment with curl in under two minutes.

The five prices, as returned

All figures are the USDT-denominated (or USD, where noted) top-of-book quotes captured at 02:03–02:04 UTC on 2026-09-08:

Venue (market)	Bid	Ask	Last trade
Binance spot — BTCUSDT	79,398.00*	79,398.00*	79,398.00
Bybit spot — BTCUSDT	79,397.5	79,397.6	79,397.8
OKX spot — BTC-USDT	79,392.4	79,392.5	79,392.5
Kraken spot — XBT/USD	79,384.10	79,384.20	79,384.20
Coinbase Exchange — BTC-USD	79,374.00	79,374.01	79,374.00

* Binance figures here come from its last-trade price endpoint at that moment; its book top-of-book is shown in the second round below (79,398.83/79,398.84).

A second, fully independent round of requests about 35 seconds later (02:04:14–02:04:18 UTC) returned the same pattern: Binance 79,398.83/79,398.84, Bybit 79,399.7/79,399.8, OKX 79,393.1/79,393.2, Kraken 79,381.6/79,381.7, Coinbase 79,374/79,374.01. The ranking barely moved; prices drifted by single-digit dollars. This is not a one-frame fluke — it is a standing structure.

The spread between "the price of Bitcoin" and "a price of Bitcoin"

Within the three USDT venues (Binance, Bybit, OKX), the top-of-book quotes sat within about 7 US dollars of each other — roughly 0.9 basis points. Tight, as you would expect from markets that are heavily arbitraged by professional firms.

The interesting gap is between the currency groups:

USDT venues (Binance, Bybit, OKX) printed around 79,392–79,398.
True-USD venues (Kraken, Coinbase) printed around 79,374–79,384.

That is a gap of roughly 8–24 dollars, or about 1.0–3.0 basis points depending on which pair you compare (OKX bid vs Kraken ask: ~8 USD; Binance vs Coinbase: ~24 USD). Some of this gap is not Bitcoin at all: the USDT venues are quoting Bitcoin in Tether, and USDT itself is not worth exactly 1.000 US dollar. When we measured USDT against USD on exchange APIs in late August 2026 it printed around 0.9996–0.9997 — a discount of 3–4 basis points — which would, mechanically, make a USDT-denominated number cheaper than a USD one, not more expensive. So the residual reflects genuine differences in local supply and demand for Bitcoin in each market, plus the stablecoin premium running the other way that day. Either way, the honest conclusion is the same: "the" global price of Bitcoin is an aggregation someone else computes. Each exchange trades its own book.

Why should you care about 2–3 basis points? Because many exchanges' maker fees on liquid pairs are in the same range. The price gap between venues is a real, tradeable-away-or-not cost that lives on the same order of magnitude as the fee schedule everyone obsesses over — and unlike fees, it moves without warning.

The same-minute split inside one exchange: spot vs perpetual

We also pulled the BTC USDT perpetual futures last price from the same three venues in the same minute:

Bybit linear BTCUSDT perp last: 79,362.90 (mark price 79,364.13, index 79,397.40)
OKX BTC-USDT-SWAP last: 79,362.7
Binance USDT-margined BTCUSDT futures last: 79,368.00

So while spot printed ~79,392–79,398, the perpetuals printed ~79,363–79,368 — the derivatives were trading roughly 3–4 basis points below spot at that instant. Same asset class, same minute, another visible price split. (Perpetuals trade on their own supply/demand and settle funding against an index; they do not have to equal spot, and on this morning they did not.)

Three different "prices of Bitcoin" — USDT spot, USD spot, and perp — all correct, all simultaneous.

What this is not

This is not an arbitrage opportunity. The 10–25 dollar gaps are routinely smaller than withdrawal fees, network fees, trading fees, and the slippage you would take executing across books of this size. The numbers are a snapshot of two moments in time (02:03:41 and 02:04:14 UTC) and everything here moves continuously.
This is not a ranking. We are not saying one venue is "cheaper" or "better." Prices reflect each market's order flow, currency of quotation, and product type — not quality.
These values were true at 02:03–02:04 UTC on 2026-09-08 and are already stale. Treat every number here as a dated observation, not a fact about today.

Reproduce it yourself

Every number came from a public endpoint that requires no account and no API key:

Binance: GET /api/v3/ticker/bookTicker?symbol=BTCUSDT and GET /fapi/v1/ticker/price
Bybit: GET /v5/market/tickers?category=spot&symbol=BTCUSDT (and category=linear)
OKX: GET /api/v5/market/ticker?instId=BTC-USDT (and BTC-USDT-SWAP)
Kraken: GET /0/public/Ticker?pair=XBTUSD
Coinbase Exchange: GET /products/BTC-USD/ticker

Note the units before you compare anything: three venues quote in USDT, two in actual US dollars, and Kraken's ticker returns USD while its pair code says "ZUSD." Comparing raw numbers across quotation currencies without converting is the single most common way people misread tables like the one above.

Verify with official sources

The data above is a snapshot, not a specification. Before acting on any of it, check the primary sources yourself: each exchange's own public API documentation (Binance spot and futures API docs, Bybit v5 API docs, OKX v5 API docs, Kraken public API docs, Coinbase Exchange API docs) and each exchange's current fee and product pages. Prices, fees, and endpoint behavior change constantly; the only durable takeaway is the method — query the venues directly, in the same breath, and always note what currency you are actually looking at.

Disclosure — AI assistance: This article was drafted with AI assistance under human editorial oversight, and the measurements were taken programmatically from public exchange APIs.

Disclosure — affiliates: No affiliate or sponsored links appear in this article. #ad disclosure: if this article ever carries affiliate links in the future, they will be clearly marked #ad near the links themselves.

Not financial advice: This article is for educational and informational purposes only. It describes public market data and does not recommend any exchange, asset, or trading strategy, and it makes no prediction about future prices. Cryptocurrency markets are volatile and you can lose money. Nothing here is investment, tax, or legal advice — do your own research and consult a qualified professional.

Verify with official sources: All figures were captured from public exchange APIs on 2026-09-08 02:03–02:04 UTC and may already be out of date. Confirm any number against the exchanges' own official API endpoints and documentation before relying on it.

The Price Ladder Isn't the Same Everywhere: BTC Tick Sizes Differ 10x Across Four Exchanges

HMwork — Fri, 04 Sep 2026 02:07:26 +0000

The Price Ladder Isn't the Same Everywhere: BTC Order Sizes Differ 10x Between Exchanges

Disclosure: This article was researched and written with AI assistance, then fact-checked against the official exchange APIs and documentation cited below. It contains no sponsored placements at the time of publication; if that ever changes, affiliate links will be clearly marked with #ad. Nothing here is financial advice — this is a measurement report, not a recommendation to trade, buy, or move funds.

Every limit order you place climbs a price ladder. The ladder's rung spacing — the "tick size" — is set by the exchange, not by you, and you cannot place an order price that sits between two rungs. What most traders never notice is that the same asset has different rung spacing on different exchanges. For bitcoin, we measured it: the minimum price increment for one and the same BTC market differs by a factor of ten across four major venues.

This matters more than it sounds. Tick size quietly decides three things: how tightly your limit order can hug the current market, how much of your order gets silently rounded, and how much "free" price improvement is even possible on a fill.

What we measured, and how

On 2026-09-04 (02:02 UTC) we queried the free, no-authentication public APIs of four exchanges and read the raw specification fields for BTC against USD or USDT. No third-party summaries, no blog posts — just the venues' own endpoints, which you can hit yourself with curl and reproduce the numbers.

Venue	Endpoint	Field	BTC tick size
Binance	`/api/v3/exchangeInfo?symbol=BTCUSDT`	`PRICE_FILTER.tickSize`	0.01 USD
Bybit	`/v5/market/instruments-info?category=spot&symbol=BTCUSDT`	`priceFilter.tickSize`	0.1 USD
OKX	`/api/v5/public/instruments?instType=SWAP&instId=BTC-USDT-SWAP`	`tickSz`	0.1 USDT
Kraken	`/0/public/AssetPairs?pair=XXBTZUSD`	`tick_size`	0.1 USD

Four independent official sources, two distinct answers: 0.01 versus 0.1. That is a tenfold difference in how finely you can quote a price on what is nominally the same market — spot bitcoin in dollars.

We cross-checked reachability of each venue's own field documentation as a second layer: Bybit's instrument-specification documentation page (bybit-exchange.github.io/docs/v5/market/instrument) and OKX's API v5 reference (okx.com/docs-v5/en/) both returned HTTP 200 at measurement time and define these fields. The values above are static specification fields rather than market prices, so they are far more stable than the ticker snapshots we cite elsewhere in our work — but exchanges can and do amend specifications, so treat any number here as "as of the measurement date" and re-check against the venue's own page before relying on it.

Why a ten-cent-versus-one-cent gap is not a rounding error

At the time of measurement, BTC last traded around $80,886 on Binance's public ticker. At that price:

A 0.01 tick is about 0.0012 basis points of the price.
A 0.1 tick is about 0.012 basis points.

Both sound negligible next to a 10-basis-point taker fee, and for a passive one-lot order they are. The gap shows up in three practical situations:

1. Price improvement is quantized. Suppose the best ask is $80,893.6 and the market moves in your favor. On a 0.01-tick venue, the price can print $80,893.59, .58, .57 — your resting buy limit can sit one cent behind the touch and get filled at a visibly better price. On a 0.1-tick venue, those sub-ten-cent moves simply do not exist in the order book; the ladder itself refuses to represent them. Your maximum possible price-improvement edge from queuing ahead is bounded by the rung spacing.

2. Order quantities get rounded differently too. Tick size never travels alone. The same API calls show Binance allowing quantity steps of 0.00001 BTC on spot, Kraken a minimum of 0.00005 BTC, Bybit a base minimum of 0.000001 BTC with a $5 minimum order amount, and OKX's perpetual contract moving in 0.01-contract steps (its contract value is 0.01 BTC per contract). When price precision and quantity precision interact, a "small" specification difference compounds: on coarser venues, the effective granularity of notional value per order — price tick × quantity step — is often a magnitude coarser than on the fine-grained venue.

3. Backtests and bots inherit the ladder whether they like it or not. If your simulator fills orders at arbitrary prices with one-cent granularity, but the real venue quotes in tenths, your simulated fills were sometimes not representable in the real book at all. Over thousands of trades, a fraction of a basis point per fill is exactly the kind of error that turns a losing strategy green in a backtest. Before comparing maker rebates or spread-capture strategies across venues, read each tickSize/tickSz/tick_size field directly — it is free, public, and one HTTP request away.

What we deliberately did not conclude

We are not ranking venues. A 0.1 tick is not "worse" than 0.01 — coarser ladders can concentrate displayed liquidity at fewer price levels, which some market makers prefer, and tick size is one input among dozens (fees, depth, latency, insurance funds, regulation). We also did not touch how each venue computes internal engine prices, funding settlements, or liquidation triggers — those are separate mechanisms with their own documentation. The only claim in this article is the measurable one: the minimum price increment for BTC differs 10x across these four official venues, and every one of them publishes the exact number in a public, no-key API field.

That makes tick size the cheapest specification check in all of exchange comparison. No login, no KYC, no scraping of JavaScript-rendered fee tables — four curl commands, and you know how fine a ladder you are actually allowed to climb.

Verify with official sources (re-run these yourself):

Binance: GET https://api.binance.com/api/v3/exchangeInfo?symbol=BTCUSDT → symbols[0].filters → PRICE_FILTER.tickSize
Bybit: GET https://api.bybit.com/v5/market/instruments-info?category=spot&symbol=BTCUSDT → result.list[0].priceFilter.tickSize
OKX: GET https://www.okx.com/api/v5/public/instruments?instType=SWAP&instId=BTC-USDT-SWAP → data[0].tickSz
Kraken: GET https://api.kraken.com/0/public/AssetPairs?pair=XXBTZUSD → tick_size
Field documentation: https://bybit-exchange.github.io/docs/v5/market/instrument · https://www.okx.com/docs-v5/en/

AI-assisted content disclosure: research, API pulls, and drafting were performed by an automated research system; key figures were re-verified against the endpoints listed above immediately before publication.

Not financial advice. Cryptocurrency trading involves substantial risk. All figures are public specification values captured at the timestamps noted and may change at any time at each venue's discretion.

DEV Community: HMwork

One Call, Five Answers: How Many Candles Each Exchange API Actually Returns

One Call, Five Answers: How Many Candles Each Exchange API Actually Returns

The five answers, up front

What I actually ran

The documentation layer, quoted

The one-candle disagreement

A quiet cross-check worth copying

What a portable fetcher must carry

Numbers move — verify official sources

Funding Settles Every 8 Hours — but Four of These Five Exchanges Have No 8-Hour Candle

Funding Settles Every 8 Hours — but Four of These Five Exchanges Have No 8-Hour Candle

Binance: the interval exists — and its documentation says so

Bybit: the ladder stops at 12 hours; 480 minutes is not on it

OKX: two candle grids, neither of them 8 hours

Kraken: the enum is now printed in the docs — 8 hours is absent

Coinbase: six granularities, and 28800 is not one of them

What this means for your charts

Reproduce it yourself

Same BTC Perp, Two Leverage Ceilings: 150x on One Venue, 100x on the Other — Both Straight From the API

Same BTC Perp, Two Leverage Ceilings: 150x on One Venue, 100x on the Other — Both Straight From the API

The question, kept simple

Venue A: the field is called maxLeverage, and it says 150

Venue B: the field is called lever, and it says 100

150 vs 100: what the gap actually means

Why this belongs in the "fees are not the only fine print" series

Verify official sources

Same BTC Perp, Four Self-Reported Fee Schedules: Taker Fees 3.75x Apart — and One Venue Pays Its Makers

Same BTC Perp, Four Self-Reported Fee Schedules: Taker Fees 3.75x Apart — and One Venue Pays Its Makers

The fee page you read is not the fee field the machine reads

The four readings

A negative maker fee is not a typo

Second underlying, same shape

What these fields do not claim

Why this matters for a fee-atlas mindset

Verify official sources

Same Wrong Request Type, Four Different Answers: 404 Silence, a Named 405, and Two Venues That Simply Do Not Care

Same Wrong Request Type, Four Different Answers: 404 Silence, a Named 405, and Two Venues That Simply Do Not Care

The experiment: one wrong button, pressed five times

Answer 1 — Binance: 404, and a completely empty body

Answer 2 — Bybit: 200, and it hands you the time anyway

Answer 3 — OKX: 405 with a name you can grep for

Answer 4 — Kraken: 200, and it isn't even pretending

The fifth answer that isn't about methods at all

Results table (measured 2026-10-06, two rounds each)

Why this matters beyond a chuckle

Reproduce it yourself

Verify official sources

One Concept, Four Field Names, Three Numbers: The Funding-Rate Ceiling on the Same BTC Perp

One Concept, Four Field Names, Three Numbers: The Funding-Rate Ceiling on the Same BTC Perp

The number everyone quotes doesn't exist

The four readings, side by side

Four names for one concept

The ETH side is where the philosophies split

Why the ceiling matters even if you never see it

How to verify every number in this article

Your Dollar Is Not a Dollar: USDT Trades at a Measurable Discount Right Now

Your "Dollar" Is Not a Dollar: USDT Trades at a Measurable Discount Right Now

The measurement: three sources, one minute apart

What the numbers actually say

Why this belongs next to the fee table

What we deliberately do not claim

Try it yourself

The Same Bitcoin Answers to Three Tickers — and One Exchange Uses Two of Them Under Its Own Roof

Kraken: the asset is XXBT, the label is XBT

KuCoin: spot says BTC, futures say XBT — and each half rejects the other's spelling

Coinbase Exchange: only BTC-USD has ever lived here

Why this matters beyond trivia

Method and reproducibility

Verify with official sources

One Page, Two Pricing Philosophies: 0.25% Flat on Perps, Tiered 0.40%/0.80% on Spot

One Page, Two Pricing Philosophies: Kraken Charges 0.25% Flat on Perps but Tiered 0.40%/0.80% on Spot

The flat side: "simple" Perps cost 0.25% per side

The tiered side: the order-book ladder

What the same page admits about "simple"

The honest footnote

Not financial advice

Verify with official sources

Four Exchanges, Three Timestamp Units: Seconds, Milliseconds, Nanoseconds — and One Gives You Two at Once

Four Exchanges, Three Timestamp Units: Seconds, Milliseconds, Nanoseconds — and One Gives You Two at Once

Venue A: the field is called `maxLeverage`, and it says 150

Venue B: the field is called `lever`, and it says 100