DCA deal queues: who gets the next slot?

A DCA bot deal entry queue needs a stated admission rule: discard invalid candidates, rank the remaining entries, break ties with a durable unique sequence, and recheck capacity before reserving a deal slot and its funding. A maximum active-deal setting supplies a ceiling, not that ordering rule. First confirm whether blocked signals are retained at all; some systems reject them instead of maintaining a waiting queue.

When several pairs signal together, the next available place can change which market the strategy holds. An unexplained selection order makes that behavior hard to reproduce even if every indicator calculation is correct.

The worksheet below defines a hypothetical spot-bot scheduler. It illustrates a specification to verify, rather than claiming KLINEO provides a configurable entry queue or these priority controls.

Establish what “waiting” means

A signal can have three different outcomes while all deal slots are occupied:

• Rejected: the event is recorded but never reconsidered.
• Recalculated: a later evaluation considers current conditions, without preserving the earlier event.
• Queued: an identified candidate persists until admission, cancellation or expiry.

These produce different trades. A crossing that occurred at noon does not automatically remain an entry opportunity at 12:15.

Freqtrade's trade-creation documentation explicitly lists unavailable slots, insufficient funds and other checks as reasons a signal might produce no order. That establishes the distinction between a signal and an admitted trade in that software; it does not establish that a rejected signal waits in a persistent queue.

Check your system's actual behavior before designing priorities. The max-active-deals guide addresses how much concurrent capacity exists. The question here is who receives that capacity.

Choose the ordering before observing returns

Common admission policies include oldest accepted candidate first, a fixed pair priority, and rotation among pairs. FIFO favors earlier acceptance; fixed priority favors the designated class; rotation can prevent one frequently signaling pair from taking every newly available place.

None identifies the most profitable next trade. Rotating deal counts also does not equalize capital: one large ladder can commit more than several small ones. Keep the multiple-pair allocation plan separate.

For a fixed-priority example, define lower numbers as earlier service. Within the same priority, use a durable increasing acceptance sequence. Python's official priority-queue implementation notes illustrate this pattern with an entry count that resolves equal-priority ties in insertion order.

“Accepted first” must have an authority. Two workers can observe the same timestamp, or receive external events in a different order from their source timestamps. A centrally assigned, persisted sequence provides a definite tie-break for this example. Source event time remains evidence about signal freshness; it is not the admission sequence.

If candidates are selected from a database, an apparent natural row order is insufficient. PostgreSQL's LIMIT documentation explains why selecting a subset needs an explicit unique ordering. Sorting by priority alone still leaves equal-priority candidates unresolved.

Work through two newly available slots

Assume a fictional scheduler evaluates at 12:05 UTC. Its maximum is three active deals, with one existing deal still active. Therefore, two slots are available.

It has 600 USDT available for new purchase commitments after reconciling existing reservations and excluding a separately funded cost allowance. Each commitment below covers the candidate's whole planned purchase ladder. The example ignores stablecoin value changes and makes no fill or return forecast.

Its written rules are:

1. Remove a candidate at or after its expiry.
2. Revalidate the current entry condition and other eligibility checks.
3. Sort eligible candidates by ascending priority, then ascending sequence.
4. Skip a candidate that cannot fit the remaining purchase budget; retain its original sequence until expiry.
5. Reserve one slot and the full commitment together before considering another candidate.

Unexpired candidates pass the current entry and risk checks.

ETH and SOL were accepted at the same displayed second. Sequence 302 wins that tie. BTC's earlier acceptance cannot rescue an expired signal.

The check is 400 + 200 = 600 USDT, with two reservations and one existing deal reaching the three-deal ceiling. SOL needs 50 USDT more than the remaining budget at its turn.

A different policy could stop at SOL and leave the second slot idle. That is a head-of-line blocking choice. This example explicitly permits bypassing an unfundable candidate; it does not quietly resize SOL's ladder to make it fit.

The two admitted candidates have permission to begin their submission process. They are not confirmed fills. Pending or unknown submissions must continue consuming their reservations until their actual outcome is reconciled.

Priority can be reproducible and still starve a pair

Fixed priority can repeatedly bypass a lower-priority candidate when higher-priority candidates keep arriving. A candidate may remain valid and funded yet expire without receiving a place. That is starvation, not a broken indicator.

Possible policies include rotating eligible pairs or increasing an entry's service priority as it waits. These change the strategy and require implementation support. Age must never override expired evidence, a funding limit or a risk block.

A maximum wait is also not a promise of eventual execution. Expiring a candidate after five minutes bounds its queue lifetime, while permitting every candidate to expire. If existing deals never close, no admission policy can create an available slot.

Record waiting time by pair alongside admissions, expiries and budget skips. An average alone can conceal a pair that repeatedly misses out. Also state what repeated signals do: create another candidate, refresh an existing one, or leave it unchanged. Refreshing expiry indefinitely can preserve an obsolete event; resetting the acceptance sequence on every update can continually move a candidate backward.

Preserve decisions across failures

Stable sorting is only one part of a reliable admission record. Two workers can each see one free slot and spend it unless the claim and reservation are coordinated. A unique queue sequence does not prevent that race.

For each decision, retain the candidate identity, rule version, rank, eligibility evidence, funding requirement, remaining capacity and resulting reservation. If a submission times out, reconcile that exact attempt before permitting another entry. An assumed rejection can otherwise free capacity that an exchange order is already using.

After a restart, restore commitments before admitting new work. The restart budget-ledger guide covers that funding recovery boundary. Restoring a waiting list while forgetting its admitted but unresolved entries can create apparent headroom twice.

Use cash available now. An expected maker rebate is not automatically spendable funding for the next candidate. The maker-rebate and cost-basis guide addresses how an eventual credit enters the ledger; queue priority should not turn an unbooked credit into cash.

Write an admission acceptance record

Use this compact worksheet when reviewing a bot or replay:

Test equal timestamps, an expired top-ranked signal, a budget-blocked first candidate and two workers competing for the final slot. Include a restart after reservation but before receiving the order response.

Keep cooldown eligibility separate; the cooldown timing guide explains its clock and scope. In a backtest, preserve missed opportunities too: Freqtrade's report definitions count rejected entries caused by the open-trade limit. A report of completed trades alone cannot show which signals lost access to capacity.

For KLINEO, use the DCA configuration guide to check the saved trade limits and selected execution path. Treat the queue worksheet as a behavioral question to verify in that path. A deterministic ordering makes decisions explainable; it does not establish a trading advantage.

Editorial method: This AI-assisted article combines primary software documentation with an original admission worksheet. The queue policy, timestamps, candidates and amounts are hypothetical; no live scheduler test or customer outcome is reported.