DN AI Trading Beginner Series · Reviewed 10 November 2026
What matters
An order amount needs a unit, a field name and an exact API context. The number displayed in a bot setting does not establish what the connector will send. Before interpreting “10,” ask whether the actual field means 10 units of the asset or 10 units of the currency used to price it.
Keep your intended amount beside the amount and unit reported in the submitted request. A matching number can conceal a different instruction. A matching reference value also cannot establish an actual fill, fee-inclusive cost or appropriate trade size.
The free DN Order Unit Lab compares two reader-declared amounts. It uses an optional hypothetical price for cross-unit comparisons. It does not inspect a request, identify a field’s unit or connect to an account.
Imagine telling a bot to use 10 QUOTE, then finding the number 10 in a field that represents BASE. The digits survived, but the unit changed. At an invented reference price of 25 QUOTE per BASE, the field represents 250 QUOTE rather than your intended 10.
The earlier order-types guide introduced the difference between acquiring an asset quantity and specifying a quote amount. This guide follows that intention into the field selected by a particular integration. It asks what evidence would show that the unit survived the journey.
1. Name the exact route before interpreting the amount
Start with the provider, API product, operation, order type and side. Include whether the request concerns ordinary spot trading and which connector version constructs it. A label such as “Coinbase order” or “market buy” leaves several of those questions unanswered.
Keep the scope small: one intended instruction and one corresponding request. An account-wide “order size” setting may be an input to the bot’s own calculation, while the request field is the output of that calculation. Comparing the two requires knowing where the transformation occurs.
For a redacted review, write something like: “REQUEST-A, CONNECTOR-A, named spot API, market BUY, selected size field.” Use aliases for private account and instance details. Preserve the real route in your private evidence without sharing an authorization header or signed request.
This also prevents a documentation shortcut. A field described on one provider’s institutional API does not acquire the same meaning on its consumer API because the company name matches. Likewise, a spot field should not silently become a derivatives contract count. If the product context is unknown, record that uncertainty before doing arithmetic.
2. Identify BASE and QUOTE from product metadata
The lab uses BASE and QUOTE as fixed teaching labels. They are placeholders for two specific assets, not names for “crypto” and “cash.” Both sides of a pair can be digital assets, and a familiar currency-like label does not make two asset identifiers interchangeable.
Coinbase Advanced’s product response provides separate base_currency_id and quote_currency_id fields. Kraken’s WebSocket v2 instrument data likewise identifies the pair’s base and quote assets. [1] [2]
Record those identities beside the pair and API product. Do not infer them from a portfolio’s display currency or a balance converted for presentation. A screen showing a holding’s dollar value is not evidence that an order amount is denominated in dollars.
Side describes the direction of the instruction; it does not rename the pair. When comparing a BUY and a SELL, keep the same asset identities and then examine how the selected field uses them. If a bot changes the pair or route between steps, the earlier unit label needs to be checked again.
In an evidence note, “0.4 BASE” should therefore be shorthand for a known asset in a known product. In this article’s invented examples, it remains a mathematical label and never identifies a real trade to make.
3. Compare the intention with the field actually serialized
Separate three records: the amount you intended, the bot’s configuration value and the request field it constructed. A settings screenshot can explain the middle record while leaving the final one unknown. An AI-generated explanation produced afterward cannot substitute for the contemporaneous request evidence.
The useful comparison includes both value and unit. “Intent: 10 QUOTE; request field: 10 BASE” reveals a mismatch that “10 equals 10” would miss. Conversely, different numbers can have equal hypothetical values: 0.4 BASE at 25 QUOTE per BASE equals 10 QUOTE.
Ask which adapter selected the field, whether a library transformed the value, and which record establishes the field’s denomination. If you only have a summary saying “amount: 10,” keep the unit unknown. A plausible price does not resolve what the integration sent.
Use a harmless request alias to connect the evidence. DN’s bot-logs guide explains how to preserve links and gaps between decisions, requests and replies. The unit lab accepts only manually entered labels and numbers; it does not parse raw logs or authenticate your declared units.
The distinction matters even when the numbers happen to agree. Equality in the lab means equality of the declared quantities or reference values. It is not a certificate that the bot chose the intended API field.
4. Check the side and conditions attached to the field
The following examples show why a field name should travel with its route and conditions. They describe documented interfaces, not a universal payload template. Product availability, valid combinations and actual request handling remain separate checks.
| Documented context | Size distinction | Boundary to retain |
|---|---|---|
| Binance Spot REST, MARKET | quantity specifies base quantity. quoteOrderQty specifies quote spend for BUY or quote receipt for SELL. |
The base quantity for a quote-sized request depends on liquidity. [3] |
Coinbase Advanced, spot market_market_ioc |
The market guide allows quote_size or base_size for BUY; SELL uses base_size. |
That guide identifies market FOK as Perpetuals only. [4] |
Kraken Spot WebSocket v2, add_order |
order_qty is base quantity. cash_order_qty expresses quote volume. |
The quote field is conditioned on market BUY without margin funding. [5] |
These differences matter when a strategy moves between connectors. A quote-sized SELL described by one route does not establish that a similarly named field is available for SELL elsewhere. Copying the value while changing the route can preserve the number and change the instruction.
Read the actual configuration selected by your integration. A generic schema can display several alternatives together without establishing that every combination is valid. Do not infer that both size fields should be sent, or guess which one wins, from an example object.
Keep unfamiliar combinations unresolved until their exact conditions are documented. The lab intentionally has no provider selector: it compares the units you declare and cannot decide which field a venue accepts.
5. Find out whether the connector converts amount into cost
A wrapper can expose a convenient argument while sending something different underneath. This is another reason to trace the value to the actual request rather than stopping at the function name or bot setting.
CCXT documents exchange-specific market-buy behavior in which an amount and a supplied price are multiplied to form quote cost. That price is used in the conversion; its presence does not turn the market instruction into a limit order. [6]
The CCXT FAQ also describes an explicit createMarketBuyOrderWithCost helper, subject to capability support. Disabling the documented price requirement does not make an endpoint that expects quote cost start accepting base quantity. [7]
For a review, identify the exact method, adapter version and relevant options already in use. Ask whether the displayed amount is an input to conversion or the value sent afterward. Do not treat a generic example as evidence of the configuration running in your bot.
Suppose an invented integration converts 0.4 BASE using a reference of 25 QUOTE per BASE and constructs 10 QUOTE. You can explain that arithmetic without concluding that the order will acquire exactly 0.4 BASE. The reference used to construct an instruction and the prices at which it might execute are different evidence.
6. Keep order denomination separate from an all-in budget
A quote-denominated field is not automatically a complete accounting rule. Establish what the route says about that field before calling it a total spend cap, net proceeds target or fee-inclusive budget. Those descriptions make additional claims beyond identifying the unit.
For the separate Coinbase Exchange REST API, the Funds section states that a market BUY specified with funds uses that quote amount including fees. This is an Exchange-specific example; it does not establish the treatment of Advanced Trade’s quote_size. [8]
The lab deliberately excludes fees, balances and execution. Its reference equality says only that two declared amounts have the same value under your entered price. It cannot determine what leaves one balance, what reaches another or how much remains available afterward.
Keep a separate evidence question for cost treatment: “Which documented rule explains fees for this exact route?” If you do not know, do not quietly assume zero fees or add a universal percentage. A unit mismatch and an unresolved fee rule can coexist; solving one does not resolve the other.
Similarly, an intended order amount is not a statement of maximum loss. The purpose here is to understand an instruction, not choose its financial size or certify its suitability.
7. Check increments and minimums only after identifying the unit
A correctly identified unit can still contain a value that fails another rule. Keep the questions in order: what does the field mean, and which separate constraints apply to that field and product? Correct formatting cannot repair a mistaken denomination.
Coinbase Advanced exposes separate base_increment, quote_increment and price_increment fields. Kraken’s instrument data separates quantity and price increments, base-quantity minimums and cost minimums from ledger or display precision. [1] [2]
A display rounded for readability is not evidence that the underlying request was rounded the same way. Equally, a numeric conversion can produce a value that a particular route does not accept. The unit lab keeps exact mathematical values without claiming that they are valid submission quantities.
The minimum-order guide handles the separate increment, minimum-notional and funding questions within its stated limit-order scope. This article does not repeat that eligibility worksheet or extend it to market orders.
Preserve the original intended amount and request evidence when investigating a rejection. Changing a value until an error disappears would not, by itself, establish that the resulting instruction still expresses the original intention.
8. Finish with a record that preserves unknowns
A compact unit review should distinguish what you intended, what you observed and what you assumed. That makes a support question useful without exposing credentials or presenting an inference as a captured fact.
| Record | Useful content |
|---|---|
| Context | Named API, route, product, side, order type and connector version. |
| Intention | Original amount with its asset unit. |
| Request evidence | Field name, recorded value and a private evidence pointer. |
| Unit support | The documentation or implementation establishing that field’s meaning. |
| Assumptions | Any illustrative reference price, clearly separated from execution evidence. |
| Open questions | Unknown field mapping, conversion, fee treatment or request outcome. |
A useful question is: “Our intention was 10 QUOTE. Which unit did CONNECTOR-A serialize for REQUEST-A, and where is that conversion recorded?” It invites evidence. “The bot must have bought the wrong quantity” already assumes an execution outcome.
If the request outcome is uncertain, the order-timeout guide addresses that separate problem. Discovering a unit concern does not establish whether the earlier request was accepted, rejected or filled, and the lab never gives permission to send another order.
Use the DN Order Unit Lab
Enter an optional alias, the intended amount and unit, and the field amount and unit. The sixth field is an optional hypothetical reference price, expressed as QUOTE per one BASE. BASE and QUOTE remain reader declarations; the tool does not infer them from a number.
When the two units match, their amounts can be compared directly without a price. When the units differ, a supported positive reference price is needed. Unknown units remain unknown even when a price is present.
The six fictional examples cover a unit mismatch, reference-value equivalence, same-unit agreement and disagreement without price, an unknown field unit, and a nonterminating conversion. JSON and CSV downloads preserve the inputs and findings. They contain no retrieved account or exchange information.
Declared units, exact comparisons
DN Order Unit Lab
Compare the amount and unit you intended with the amount and unit you declare for a field. BASE and QUOTE are educational labels. The lab does not identify a trading pair or verify what an API field means.
A reference-value match is not an accepted order, an execution forecast or a quantity to submit. Amounts exclude fee accounting.
Selecting a case does not change the inputs until you load it.
Use positive decimal text, with at most 18 integer digits and 18 fractional digits. These are lab bounds, not venue limits. Blank stays unknown; zero and negative amounts are outside this lab.
The lab runs locally in this page and does not save inputs between visits.
The dimensional comparison remains unknown
Unit labels are reader declarations. These findings do not verify API semantics, order acceptance, fills or a quantity to submit.
Comparison inputs
A required amount, declared unit or conversion price is unknown. No overall amount comparison is inferred.
Independently calculable equivalents are retained below.
Exact equivalents under your declarations
An amount in its own declared unit needs no price. Conversion into the other unit requires the hypothetical reference price. An unresolved conversion does not erase an independent known value.
Intended amount · BASE equivalent
Unresolved
An amount, unit or needed reference price is unknown.
Depends on: Intended amount; Intended unit.
Intended amount · QUOTE equivalent
Unresolved
An amount, unit or needed reference price is unknown.
Depends on: Intended amount; Intended unit.
Field amount · BASE equivalent
Unresolved
An amount, unit or needed reference price is unknown.
Depends on: Amount entered in the field; Declared field unit.
Field amount · QUOTE equivalent
Unresolved
An amount, unit or needed reference price is unknown.
Depends on: Amount entered in the field; Declared field unit.
Unknown inputs and numeric normalization
- Intended amount is unknown.
- Amount entered in the field is unknown.
- Reference price is unknown. Cross-unit comparisons and other-unit conversions need it; same-unit amount comparisons do not.
- Intended unit is unknown; an amount does not establish its unit.
- Declared field unit is unknown; an amount does not establish its unit.
Numeric outer whitespace, when present, is ignored for parsing and reported here. Original strings remain in the exports.
What this lab cannot establish
- Verifying a venue, trading pair, endpoint, API field or the meaning of the declared units.
- Actual order acceptance, execution, fills, balances, holdings or a recommended quantity to submit.
- Fees, slippage, market movement, a universal spending cap or a forecast execution price.
- Minimums, increments, precision filters, other venue rules, order eligibility or retry decisions.
- Network requests, account connections, credentials or storage of this record between visits.
Documentation review: 2026-11-10 (Africa/Johannesburg). The lab uses reader-declared units and hypothetical prices. No API field or account is verified.
JavaScript is off. This is the initial unknown record. Editing and downloads require JavaScript; the article and scope remain readable.
Worked example: the same digits, different amounts
In the first fictional case, the intention is 10 QUOTE, while the declared field is 10 BASE. With a reference price of 25 QUOTE per BASE, the comparison is 10 QUOTE versus 10 × 25 = 250 QUOTE. Equal digits did not mean equal reference values.
Change the fictional field to 0.4 BASE, keeping the same price. Then 0.4 × 25 = 10 QUOTE. This is reference-value equivalence, not a prediction that a quote-sized market instruction will deliver 0.4 BASE.
For a different example, 1 QUOTE at a reference price of 3 QUOTE per BASE corresponds to exactly 1/3 BASE. Entering 0.333333 BASE gives 0.999999 QUOTE, which differs from 1 QUOTE. The lab uses exact fractions for comparison and labels a nonterminating decimal illustration as truncated.
Finally, compare 0.4 BASE with 0.5 BASE while leaving price blank. Their same-unit difference is still known. Their quote equivalents remain unresolved. Missing conversion information does not erase a comparison that does not depend on it.
Methodology and limits
DN authored this deterministic dimensional comparison. Positive decimal inputs are parsed into reduced rational numbers using integer arithmetic. BASE amounts multiply by the entered QUOTE-per-BASE price; QUOTE amounts divide by it. Same-unit comparisons use the amounts directly. Cross-unit comparisons use exact quote equivalents.
For a nonterminating result, the lab retains the exact fraction and provides a separately labeled 12-place truncated illustration. That illustration is not used for equality and is not a quantity recommendation. Unsupported input syntax and the positive-only input bounds are lab restrictions, not venue rules.
A blank or unsupported optional price cannot erase a known same-unit finding; dependent conversions remain unresolved. A missing unit prevents the corresponding denomination from being inferred. Neither an amount match nor a reference-value match verifies your declared field mapping.
All six dataset cases are invented. The lab does not validate a payload, order eligibility, increments, balances, fees, slippage, fills or spend limits. Its results do not select an order size, authenticate a request or establish what an account did.
Frequently asked questions
Can the same number represent different order sizes?
Yes. In the fictional example, 10 QUOTE and 10 BASE represent different reference values at 25 QUOTE per BASE. The unit is part of the amount.
What is the Binance Spot MARKET distinction between quantity and quoteOrderQty?
quantity is base quantity. quoteOrderQty is quote spend for BUY or quote receipt for SELL; the base quantity depends on liquidity. [3]
Can Kraken cash_order_qty be assumed to work for every order?
No. Kraken’s WebSocket v2 documentation conditions it on market BUY orders without margin funding. [5]
Does Coinbase Advanced use identical market sizing for BUY and SELL?
Its market guide allows quote_size or base_size for BUY and specifies base_size for SELL. Keep this guidance within its named API context. [4]
Does a price passed to a CCXT market-buy conversion become a limit price?
No. The documented exchange-specific behavior uses the supplied price to calculate quote cost; that calculation does not change the market instruction into a limit order. [6]
Does reference-value equality prove the bot will execute the intended quantity?
No. It establishes only mathematical equality under your entered price and declared units. It does not verify the field mapping, fees, eligibility or execution.
Can the lab compare amounts without a reference price?
Yes, when both declared units are the same. Different units need a supported reference price. Unknown units remain unknown, and missing conversions do not erase a known same-unit finding.
Research scope and disclosure
Official sources were checked on 10 November 2026, Africa/Johannesburg. Product, route and side conditions are retained. No private account, credential, signed request, preview or live order was accessed.
The labeled affiliate link may earn Decentralised News a commission. Other provider references are neutral documentation links. The article explains units and evidence; it does not recommend a trade amount or a request to submit.
Primary sources
Official documentation reviewed on 10 November 2026 (SAST). Product names, routes, sides and sizing fields are kept separate. Documentation is evidence for the stated reference, not verification of an individual account or payload.
