<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>NALOG · Read NALOG by RSS</title><link>https://ordzu.com/en/</link><description>Binance Spot. Orders &amp; rules.</description><language>en</language><item><title>The limit price was reached. Why no fill?</title><link>https://ordzu.com/en/guides/limit-order-not-filled/</link><guid isPermaLink="true">https://ordzu.com/en/guides/limit-order-not-filled/</guid><description>A candle touching a limit price does not prove that an entire order could execute. This guide starts with the instruction itself: pair, side, limit, original quantity and cumulative fills. A fixed three-level book separates acceptable prices from available opposing quantity and explains why a smaller order can behave differently. The later checks connect submission time, open remainder and final status, including cases where an instruction was never accepted. All numbers are teaching assumptions. Changing a limit changes the prices you are willing to accept; it does not simply repair a display problem or guarantee execution.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>Is the visible depth enough for this market order?</title><link>https://ordzu.com/en/guides/market-order-price/</link><guid isPermaLink="true">https://ordzu.com/en/guides/market-order-price/</guid><description>Visible depth answers a quantity question before it answers a price question. Using a fixed three-level book, the article follows a market buy across available asks and calculates its weighted average from executed quantities. It also considers selling against bids and warns against adding cumulative depth twice. When the requested amount exceeds the displayed book, the uncovered portion remains unpriced rather than receiving an invented estimate. The exercise isolates depth by omitting live changes, fees and additional protections. Actual execution must be checked in trade records, with any price difference compared against a clearly identified reference.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>Only part filled. Where did the rest go?</title><link>https://ordzu.com/en/guides/partially-filled-order/</link><guid isPermaLink="true">https://ordzu.com/en/guides/partially-filled-order/</guid><description>Partial execution means something has already traded, even when the original instruction remains incomplete. The guide separates requested quantity, cumulative fills and the unexecuted difference, then uses status to determine whether that difference can still trade. Worked examples show how repeating the original amount can exceed an intended target and why cancellation does not remove completed execution. Further checks reconcile several fills, compare observations made at different times and distinguish order quantities from wallet balances. The examples support record reading rather than a recommendation to continue buying or selling, and no unchanged future price is assumed.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>Enough value, but an invalid quantity. Why?</title><link>https://ordzu.com/en/guides/minimum-order-and-increments/</link><guid isPermaLink="true">https://ordzu.com/en/guides/minimum-order-and-increments/</guid><description>An order can meet a minimum value and still contain an invalid price or quantity increment. This article treats price steps, quantity steps and notional value as separate checks, using boundary examples to show why the right number of decimal places is insufficient. It explains how rounding can alter a budget, why copied separators deserve inspection and why market-order validation cannot blindly reuse a limit-price calculation. The local checker uses exact decimal arithmetic for its displayed conditions. Passing those checks does not establish compliance with every exchange rule, acceptance of the instruction or a subsequent fill.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>The stop triggered. Why do I still hold the asset?</title><link>https://ordzu.com/en/guides/stop-limit-trigger/</link><guid isPermaLink="true">https://ordzu.com/en/guides/stop-limit-trigger/</guid><description>A triggered stop-limit instruction has reached an activation condition, not necessarily a completed trade. The article gives trigger price and execution limit separate roles, then uses a hypothetical price jump to show why the resulting instruction may find no acceptable match. Buying and selling boundaries are read independently, and several possible post-trigger states are compared instead of being merged into a single success label. A compact observation record tracks the relevant order, cumulative execution and remainder. The examples explain mechanics only: adjusting a limit changes acceptable prices and cannot guarantee an exit under all market conditions.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>I pressed cancel. Can I place the whole order again?</title><link>https://ordzu.com/en/guides/cancel-order-safely/</link><guid isPermaLink="true">https://ordzu.com/en/guides/cancel-order-safely/</guid><description>Clicking cancel, processing the request and refreshing the screen can occur at different times. A hypothetical four-unit target shows how another fill may arrive before cancellation completes, changing the quantity that must be reconciled. The guide distinguishes ending an unfilled instruction from selling assets already purchased, and it treats missing feedback as unresolved rather than automatic success or failure. Before a replacement, the original order needs a confirmed state and the intended target needs another check. Order identifiers matter when several instructions look alike; balance changes offer supporting evidence but cannot establish the outcome alone.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>GTC, IOC and FOK: same price, different result</title><link>https://ordzu.com/en/guides/gtc-ioc-fok/</link><guid isPermaLink="true">https://ordzu.com/en/guides/gtc-ioc-fok/</guid><description>Identical prices and quantities can produce different outcomes when instructions have different time-in-force conditions. One fixed, partially sufficient book lets the guide compare continued waiting, immediate execution of an available portion and an immediate all-or-nothing requirement. The useful distinction is between what executed, what remains active and what ended, rather than memorizing three abbreviations. Price boundaries and timing conditions are checked separately, with expiry distinguished from a user cancellation request. The scenario omits other validations and protections. A parameter documented for an API does not establish that every application exposes an equivalent button or guarantees a fill.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>EXPIRED: did nothing trade, or did the order end?</title><link>https://ordzu.com/en/guides/expired-order-status/</link><guid isPermaLink="true">https://ordzu.com/en/guides/expired-order-status/</guid><description>An expired order has ended under relevant rules, but the status alone cannot establish whether anything traded. This guide pairs final state with cumulative execution and explains why an instruction can end quickly without having waited for a long period. It distinguishes ordinary expiry, a self-trade-prevention-related status and a timeout in receiving a request response. When an order disappears from the open list, history and execution records provide the next evidence. Examples with several instructions prevent an ended difference from being counted as an active remainder, while keeping uncertainty explicit before any decision about another order.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>Order history vs trade history: match one order</title><link>https://ordzu.com/en/guides/order-history-vs-trade-history/</link><guid isPermaLink="true">https://ordzu.com/en/guides/order-history-vs-trade-history/</guid><description>Order history describes an instruction and its state, while trade records describe execution. Different row counts can reflect aggregation rather than missing activity. The article follows one identifier through original quantity, individual matches and cumulative execution, then checks date boundaries, time zones and export scope. A worked example separates quantity reconciliation from weighted value, without turning it into a complete profit calculation. Where identifiers are absent, similar times and amounts remain clues rather than proof. The resulting note records what executed, whether a remainder stays active and when that conclusion was checked.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>Bid, ask and last price: units and spread</title><link>https://ordzu.com/en/guides/bid-ask-last-price/</link><guid isPermaLink="true">https://ordzu.com/en/guides/bid-ask-last-price/</guid><description>Best bid and best ask describe current visible quotes; last price belongs to an earlier trade. The article begins with quote units and observation time, then calculates the absolute gap and a percentage with an explicitly named denominator. Comparing a midpoint-based result with an ask-based result explains small numerical differences without assuming an error. Additional checks cover missing data, rounding, separators and grouped book levels. A saved snapshot can support a calculation for its recorded moment, but it does not establish a reserved offer, the duration of a spread or an executable arbitrage opportunity.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>Open orders: why your available balance is lower</title><link>https://ordzu.com/en/guides/open-order-locked-balance/</link><guid isPermaLink="true">https://ordzu.com/en/guides/open-order-locked-balance/</guid><description>Assets can remain in a spot account while part of their quantity is reserved for open instructions. This guide separates total, available and reserved amounts, then follows the quote asset used by a buy and the base asset delivered by a sale. A simplified shared-budget ledger shows how several pairs can reserve the same asset and why cancellation releases only an unspent remainder. Checks also align observation times and distinguish asset quantities from portfolio valuations. The explanation concerns ordinary spot reservations; it does not diagnose every withdrawal hold, account restriction or special product rule.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item><item><title>Binance order timeout: check before submitting again</title><link>https://ordzu.com/en/guides/order-timeout-before-retry/</link><guid isPermaLink="true">https://ordzu.com/en/guides/order-timeout-before-retry/</guid><description>A timeout reports missing expected feedback, not a confirmed rejection of an order. The article preserves the original pair, side, quantity and time, then queries open instructions, history and actual execution. Several possible outcomes from the same initial error show why immediately repeating the whole amount can create an additional obligation. A short timeline separates observed states from assumptions and keeps different order identifiers distinct. Official API timeout semantics support the checking principle, without being presented as a fixed waiting period for an application. A new quantity is considered only after the original outcome and remaining intention are clear.</description><pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate></item></channel></rss>