DN AI Trading Beginner Series · Reviewed 10 November 2026
What matters
Before treating a rejected request as a clock problem, identify the exact API, returned error and value being checked. A request timestamp, an increasing nonce and a token’s expiry serve different purposes. Changing one setting does not establish that you have addressed the relevant condition.
Keep the request’s authentication stage separate from what happened to an order. A timing calculation cannot tell you whether an uncertain submission traded, and an error banner is not a substitute for the response associated with that request.
The free DN Request Timing Lab below uses hypothetical values to explore one documented Binance Spot REST timing rule. It does not read your clock, contact an exchange, inspect credentials or recommend a receive-window setting.
Your trading bot reports a timestamp error. An online answer says to increase a window. Before changing anything, ask: which window, on which API, and which part of the request would that change?
Those questions become more useful when the bot has several components. A strategy may create an instruction, a connector may construct its authentication, and another service may deliver the request. Knowing where the error was observed is different from knowing where its cause lies.
This guide concerns request authentication. The separate stale-data guide covers signals, candles, timestamps and clock comparability. Here, the task is to preserve the meaning of the request’s fields and the limits of the returned evidence.
1. Identify the exact API and returned error
Start with the provider, product, protocol and operation. A provider name alone is insufficient when its products use different authentication schemes. Keep the production or test environment and the connector version with the record, using harmless aliases where appropriate.
For Binance Spot, -1021 concerns the timestamp condition; -1022 concerns the signature. Its -1007 timeout reports unknown send and execution status. These are different findings, not interchangeable descriptions of a slow request. [1]
Record whether the evidence is a captured exchange response, a connector’s interpretation or a later bot summary. Preserve the exact error code privately without copying a signed URL, key, authorization header or token into a public report. A message copied from a different attempt cannot explain this request merely because it looks similar.
A useful first statement is: “The connector reported this code for request alias REQUEST-A on this API.” A weaker statement is: “My computer is two seconds slow.” The first describes evidence you can trace; the second already asserts a diagnosis that the error may not establish.
If the actual response is unavailable, leave that gap visible. You can investigate the software’s error mapping without assigning an exchange rejection to a request whose result remains uncertain.
2. Name the field and its documented meaning
Do not group every number related to time under a single “timestamp” label. Write down which field the authentication mechanism consumes, its unit and which component supplies it. A date in a chart, a log entry or a signal payload may be unrelated to that field.
| API context | Relevant value | Documented distinction |
|---|---|---|
| Binance Spot REST | timestamp and recvWindow |
Timestamp accepts milliseconds or microseconds; the window stays milliseconds, with up to three fractional places. [2] |
| Kraken Spot REST | nonce |
An increasing unsigned 64-bit value for each API key. [3] |
| Coinbase Exchange REST | CB-ACCESS-TIMESTAMP |
Epoch seconds in UTC, with decimals allowed; within 30 seconds of service time. [4] |
| Coinbase App / Advanced Trade | Request JWT | Request authentication with a two-minute token lifetime. [5] |
These rows describe separate interfaces. They are not settings to copy between providers. In particular, a Kraken nonce need not be a date, and Coinbase Exchange’s timestamp rule does not define Advanced Trade’s token handling.
For your own integration, trace the field to its source in the connector’s documentation or implementation. If a hosted service owns that step, ask it to identify the mechanism and relevant version. Looking at your laptop’s clock does not establish what a remote service placed in a request.
3. Follow the value that was actually signed and sent
Distinguish the time at which a strategy decided to act from the value used to authenticate its eventual request. Your review should identify the relevant field’s construction point, then keep that exact request separate from a later reconstruction.
Coinbase Exchange signs a message containing the same timestamp supplied in its authentication header. A different value in the header and signed message would not be the documented matching pair. [4]
This makes “update the timestamp” an incomplete description of a proposed change. Ask which component owns construction and signing, whether it creates a fresh request or reuses prepared material, and how the resulting record is associated with the response. Do not change a captured request to make it look like the request you wish had been sent.
A hypothetical example illustrates the distinction. Suppose a connector prepares authentication before a request waits in a local queue. The time of that preparation and the time of eventual delivery are separate observations. Without evidence about the actual connector, the example is a question to investigate, not an explanation of your incident.
The bot-logs guide helps link decision, request and reply records. Use a redacted pointer to those records here; the timing lab needs no payload, token or signature.
4. Separate the future bound from the age allowance
It is tempting to picture a receive window as a single tolerance that accepts any nearby timestamp. Read the actual rule before using that mental picture. Conditions on a timestamp being too far ahead and on a request being too old can be different.
Binance Spot checks a separate future bound and an age allowance, then checks age again. Its window defaults to 5,000 ms when omitted and is capped at 60,000 ms. [2]
For the lab, call the first hypothetical server reading s1 and the request timestamp T. Define A = s1 − T. A positive A means the timestamp is behind that hypothetical reading; a negative A means it is ahead. This is a relative value you enter, not a measurement of your computer’s clock offset.
The first comparisons are A > −1,000 ms and A ≤ W. [2]
W is the entered window. Notice that it appears only in the second comparison. Changing W does not change the first expression.
This is the value of a boundary example: it lets you see which comparison a number affects. It does not tell you which clock is wrong, what a production server saw, or whether changing a setting would resolve an actual error.
5. Keep the later check separate from a network timeout
A first comparison is not the whole lab. Define D = s2 − s1 for the additional hypothetical time before the later check. The later age is A + D, which the model compares with W after both initial conditions are met.
D is not your HTTP round-trip time. It is not the elapsed time displayed by a browser, nor a measured network delay. The model assumes nonnegative D and lets you explore that additional interval without claiming to observe a server’s internal checkpoints.
A local timer expiring and an explicit authentication rejection are different evidence. Binance’s documented timeout can leave execution unknown. [1] If a request’s outcome is unresolved, a timing hypothesis cannot turn it into a confirmed failed submission.
Keep the questions separate: “Would these hypothetical values satisfy the modeled timing checks?” and “What response or account evidence exists for the real request?” The lab answers only the first. It does not set a timeout, poll an order or authorize another submission.
DN’s order-timeout guide addresses uncertain execution. Use that workflow for the outcome question instead of treating a new clock setting as retrospective proof about an earlier request.
6. Check nonce ownership before blaming wall-clock drift
A counter can produce a time-related-looking error without acting as a wall-clock expiry. This is why the mechanism identified in check 2 matters before you interpret the word “nonce.”
Kraken’s Spot REST guide allows an increasing counter; a timestamp is one implementation. It warns that shared processes, arrival order and clock recalibration can disrupt nonce progression. An existing key’s nonce cannot be reset downward. [3]
Kraken’s error guidance gives an arrival-order example: a higher nonce can arrive before a lower one, causing the later-arriving lower value to be rejected. Shared or simultaneous callers therefore matter to the diagnosis. [6]
Its nonce window tolerates some out-of-order values, and the equivalent time depends on the nonce generator’s resolution. Do not read the setting as a universal receive-window duration. [7]
Make an inventory of the processes that construct the nonce for the affected key alias. Does the bot have more than one worker? Is another app using the same key? Is the value produced by the SDK, an application service or a timestamp function? These are evidence questions; the article is not instructing you to create keys or alter their settings.
Separate keys also do not automatically isolate every other constraint. The shared API-budget guide explains why rate-limit scope is a different question from nonce ownership.
7. Identify who owns token generation and time adjustment
Before changing configuration, name the component that would receive the change. A setting in your strategy editor, a connector process and a hosted platform may belong to different owners. Keep the active version and environment attached to your evidence.
Coinbase’s App authentication guide, which includes Advanced Trade examples, requires a different JWT for each unique request. Its examples set not-before and expiry claims from current time and bind the request URI. [5]
For a JWT error, ask whether the integration generated the intended request token and how it records that operation without exposing the token. A token prepared for an earlier request is not made relevant merely by changing a receive-window value elsewhere. Do not paste the JWT into this article’s tool or a public support thread.
The current CCXT Manual marks adjustForTimeDifference as an exchange-specific option in its Binance examples. [8] That supports checking the specific implementation and version; it does not turn the option into a universal setting across every exchange and connector.
Use the bot-settings guide to plan which saved or running component a proposed change affects. Keep an observation before the change, the named change itself and a separately observed result. Changing several unrelated controls at once makes that record harder to interpret.
8. Finish with a narrow evidence question
A useful incident note should let another person understand the request without receiving its secrets. It should also distinguish a documented requirement, your observation and your current hypothesis. None of those should silently become another.
| Record | What belongs in a redacted note |
|---|---|
| Scope | Provider, API product, environment and connector version. |
| Request reference | A harmless alias linked to the original private record. |
| Observed evidence | Error code, source component and response-record pointer. |
| Field ownership | Which component constructs the relevant timestamp, nonce or token. |
| Hypothesis | One proposed explanation, clearly labeled as unverified. |
| Unresolved outcome | What is still unknown about that specific request. |
For example: “REQUEST-A received this timestamp code through CONNECTOR-A. We have not established whether the connector generated its value before or after queuing. Please identify that construction point.” That is actionable without asserting an unsupported clock offset or recommending a window.
If you investigate a change, preserve the earlier evidence and state what observation would answer your question. A later successful request would be evidence about that later request. It would not explain every earlier failure or settle an earlier ambiguous order outcome.
Use the DN Request Timing Lab
Enter a hypothetical first-check age A and additional delay D, both in milliseconds. Choose either an explicitly selected documented-default window or a custom W. An unselected mode stays unknown; the interface does not silently fill it with a default.
The lab compares the first two conditions separately. When they permit the later stage to be assessed, it compares A + D with W. A known failed comparison remains visible even if another input is missing. If the initial gate fails, the later gate is not treated as a production step that occurred.
Use the fictional examples to compare boundaries, or enter your own hypothetical values. Inputs accept at most three decimal places. The tool uses exact integer microseconds internally and presents the results in milliseconds.
The custom-window field remains in the exported record when inactive, but it does not replace the selected default. JSON and CSV downloads preserve your chosen inputs and model findings. They contain no retrieved server data.
Hypothetical ages, exact comparisons
DN Request Timing Lab
Explore the Binance Spot REST timing reference with invented relative durations. All numeric fields are milliseconds; no live clock, request or account is read.
Meeting these timing conditions does not establish actual acceptance, execution or permission to retry.
Selecting a case does not change the inputs until you load it.
Use plain decimal text, with up to three decimal places. The lab limits |A| and D to 24 hours; these are teaching limits, not provider limits. Blank never means zero.
Selected window
Selected W is unknown. No retained custom text is used unless custom mode is selected.
The lab runs locally in this page and does not save inputs between visits.
Initial timing comparisons remain unresolved
These are hypothetical timing comparisons, not observations of server checks or proof of real request acceptance, execution or retry safety.
Stage 1: hypothetical initial check
Future-side condition
A > -1000 ms
Unknown
No assessed margin.
Strict: the signed margin must be greater than zero.
Initial age/window condition
A <= W
Unknown
No assessed margin.
Inclusive: zero margin meets this condition.
Stage 2: hypothetical later check
The initial conditions are unresolved, so the later predicate is not assessed.
Later age/window condition
A + D <= W
Not assessed
No assessed margin.
Inclusive: zero margin meets this condition when the later branch is reached.
A + D is unavailable because an operand is missing or outside the supported lab.
Hypothetical arithmetic only; this sum does not establish that a later check was reached.
Exact arithmetic uses integer microseconds: 1 µs = 0.001 ms. A signed margin is a difference between entered values and a condition boundary, not measured live capacity.
Retained inactive custom window
No nonblank custom-window value is retained while inactive.
Unknown inputs and numeric normalization
- First-check request age A (ms) is unknown.
- Additional delay D (ms) is unknown.
- No window source is selected. A retained custom value is not used.
Numeric outer whitespace, when present, is ignored and reported here. No original input text is changed.
What this lab cannot establish
- Actual server clock readings, clock synchronization, network measurements or the cause of an API error.
- Real request acceptance, authorization, execution, fills, exposure or retry safety.
- Other signature, permission, balance, rate-limit or order-validation requirements.
- Other providers, products or authentication schemes, including nonce ordering.
- Inferring an actual processing delay from a response, or treating a larger window as a correction for every timing condition.
Documentation review: 2026-11-10 (Africa/Johannesburg). All lab inputs are hypothetical. No live request or server clock is observed.
JavaScript is off. This is the initial unknown scenario. Editing and downloads require JavaScript; the article and lab boundaries remain readable.
Worked example: inside the first window, outside the later one
Choose the fictional case with A = 4,999 ms, D = 2 ms and W = 5,000 ms. The first age is within the entered window, and the separate future comparison holds. The later hypothetical age is 4,999 + 2 = 5,001 ms, which exceeds W.
The result explains a difference between the two modeled checkpoints. It does not establish that a real server spent two milliseconds processing your request, that your network caused the failure or that an order was rejected.
Compare it with the equality case using A = 5,000, D = 0 and W = 5,000. Then inspect the exact future-boundary case and the missing-delay case. The examples isolate mathematical boundaries and missing information; their values are not operating targets or recommended settings.
Methodology and limits
DN authored this deterministic lab from the published Binance Spot REST timing logic. It uses relative hypothetical values instead of raw timestamps, timezone conversion or a clock-synchronization estimate. Kraken and Coinbase appear as explanatory contrasts and are not additional modeled providers.
The lab permits positive W up to 60,000 ms, nonnegative D, and a maximum magnitude of 24 hours for A and D. The positive-window and 24-hour bounds are lab scope choices, not claims about a venue’s full parameter rules. Zero W is outside this lab; the cited page does not establish an explicit minimum.
The six dataset cases are invented. Blank inputs remain unknown, and unsupported precision or out-of-scope values receive separate findings. The calculation cannot validate a signature, token, nonce, account permission or order. It cannot determine production acceptance, execution, safety, clock drift or whether another request should be sent.
Frequently asked questions
Will a larger receive window fix every Binance timestamp error?
No. The separate future-side condition still applies. [2]
Is a Kraken nonce just a wall-clock timestamp?
No. Kraken Spot REST requires an increasing value per key; a timestamp is one way to generate it. [3]
Does a timeout establish that authentication rejected my order?
No. Binance’s timeout can leave send and execution status unknown. It is different evidence from an explicit timestamp error. [1]
Do Coinbase Exchange and Advanced Trade use the same timing check?
No. Exchange documents a signed request timestamp; the App/Advanced Trade authentication path uses request JWTs. Keep the API products separate. [4][5]
Is CCXT time adjustment a universal exchange setting?
No. The Manual labels the demonstrated option exchange-specific. Check the actual connector and version before interpreting its configuration. [8]
Can the lab read my clock or send a request?
No. It calculates from hypothetical relative values entered locally. It needs no credentials or account connection and performs no order, authentication or clock-setting action.
What happens when I leave a timing value blank?
It remains unknown. Known failed comparisons remain visible; missing values are not replaced with zero. The documented default is used only when you explicitly select that window mode.
Research scope and disclosure
Official sources were checked on 10 November 2026, Africa/Johannesburg. Their product and protocol boundaries are retained. No private account, key, JWT, signed request or live order was accessed during this research.
The labeled affiliate link may earn Decentralised News a commission. Other provider references are neutral documentation links. This guide explains request evidence and model assumptions; it does not recommend a trade, configuration value or retry.
Primary sources
Official documentation reviewed on 10 November 2026 (SAST). Product names and authentication mechanisms are kept separate. Documentation is evidence for the stated reference, not verification of an individual account or request.
