Kraken's Maker Protection lets some cancelled futures limit orders fill anyway if the cancel lands inside a brief hold window, catching traders off guard when timing is tight.
Milliseconds can make or break a trade on Kraken's futures desk. Cancel a limit order at the wrong instant, and the platform's Maker Protection system may still let that order fill-even after the cancel goes through. This quirk, now covering more contracts, forces anyone running fast manual or automated strategies to rethink how they manage risk.
Maker Protection exists to blunt certain market manipulation tactics and to give resting orders a fighting chance before new liquidity takers hit the book. For each covered contract, Kraken applies a hold-anywhere from 20 to 100 milliseconds-on non-post-only limit orders. The exact delay shows up in the makerProtectionMillis field in Kraken's /instruments and /trading/instruments feeds. Cancel an order during this hold, and Kraken keeps the original timestamp. At the end of the window, the order turns into an immediate-or-cancel (IOC): it can fill in part or in full, but whatever's left disappears from the book.
A cancelled limit order during the Maker Protection hold can still be executed as IOC, even after a successful cancel response.
So a trader might see a "cancelled" status, only to get a fill report for that same order seconds later. The cancel gets processed and acknowledged, but the real outcome is decided when the hold ends. If the order can't fill at release, Kraken's REST v3 API returns an iocWouldNotExecute response-no trade, just confirmation that the order died on the vine.
On October 8, 2026, Kraken widened Maker Protection to 61 more perpetual contracts, finishing phase two of its rollout. The system skips the ten most liquid linear perpetuals, and spot trading isn't touched. Each contract's hold is visible in the makerProtectionMillis field. If that field is missing or set to zero, there's no hold for that market. Post-only orders dodge the hold entirely. Cancel requests themselves aren't delayed; they just change how the order is handled when the hold ends.
Other order types-immediate-or-cancel, fill-or-kill, or market-play by different rules. Cancel one of those during the hold, and the API returns ORDER_NOT_FOUND, but the order still heads to the matching engine when the window closes. Automated traders have to track both the cancel acknowledgment and any later fills to keep their books straight.
Kraken's Maker Protection does not apply to post-only orders or the ten most liquid linear perpetual markets, and spot trading is unaffected. The delay for covered contracts is always communicated via the makerProtectionMillis field, ensuring transparency for algorithmic and manual traders alike.
For anyone running bots or high-frequency setups, the difference between a cancelled and a filled order is more than a technicality. A cancel acknowledgment doesn't mean the order is safe from execution if it lands inside the Maker Protection window. That can trigger surprise fills, mismatched positions, or reconciliation headaches if systems aren't built to handle both cancel and fill reports. Kraken splits these events: the cancel gets a "cancelled" status, and any fills show up later, so traders have to watch both streams.
The Maker Protection window isn't standard across contracts, and you can't guess coverage from the coin name. Each market sets its own rules, visible in the instruments feed. This patchwork adds friction for anyone juggling risk or chasing best execution across several markets. Regulatory pressure on exchanges to tighten up order handling has only grown, with the EU's recent stablecoin clampdown reported earlier as one example.
Kraken's docs peg the Maker Protection hold at 20 milliseconds for covered contracts, but the real impact depends on how fast traders place and cancel orders. Expanding the system to 61 more perpetuals means more markets where this edge case can trip up fast-moving strategies. Kraken doesn't publish stats on how often held orders get cancelled and then filled, but the risk is sharpest for anyone relying on sub-second execution and tight order control. The REST v3 API's split responses help with reconciliation, but traders still have to monitor both cancel and fill streams and adjust their logic.
Maker Protection is Kraken's answer to latency arbitrage and market integrity concerns. By holding certain limit orders before they hit the matching engine, the exchange tries to give passive liquidity providers a fair shot. But this also brings new operational risks, especially for automated systems that expect deterministic outcomes. As crypto markets face more scrutiny, the fine print of order handling keeps getting more complicated for both exchanges and their users.
Maker Protection acts as a latency buffer, holding some limit orders before they reach the matching engine. The goal is to block traders from exploiting millisecond-level speed and to let resting orders react. But cancelling an order doesn't always erase execution risk. Traders need to know the timing and contract-specific rules to avoid surprise fills and keep their reconciliation tight.
