Budget crypto workflow branches by identifying which actions can coexist, measuring them in the same risk unit and reserving shared capacity before submission. Truly exclusive alternatives can share an allowance based on their largest permitted outcome; concurrent actions need a combined allowance. Include existing positions, pending orders and unresolved submissions. A branch finishing or failing does not prove that its exchange exposure disappeared.
A fork does not define a capital boundary
Two lines leaving a node might mean “choose one,” “run both,” or “try another if the first fails.” Those meanings create different exposure. A signal labeled bullish and another labeled bearish are not necessarily exclusive: separate workers can observe different snapshots, or an earlier order can remain active when the next evaluation starts.
Concrete engine semantics help explain the distinction. In AWS Step Functions, a Choice state selects the first matching route, while a Parallel state starts separate branches concurrently. These are examples from AWS, not descriptions of KLINEO's executor. Inspect the actual workflow and its lifecycle rather than inferring exclusivity from its drawing.
First identify the budget boundary: account, subaccount, strategy or a deliberately shared group. Then list every action that can occupy it, including work started by earlier runs. The risk-check placement guide covers the paths that must pass approval; this article addresses how much shared capacity those paths can consume together.
Choose one measure before adding branches
A risk budget needs an explicit unit. Quote-currency purchase commitment, gross notional and modeled loss at a planned exit are different measures. A 500 USDT order is not interchangeable with a 500 USDT loss allowance. Margin requirements are another constraint and do not establish the maximum loss.
For each measure, define valuation time, currency conversion, costs and treatment of pending orders. Keep separate limits where necessary. A branch might satisfy its modeled-loss allowance while exceeding available cash or an instrument concentration cap.
An unknown required allowance must remain unknown; treating missing data as zero makes an incomplete graph appear fundable. Also avoid counting the same pending intent twice when it appears in both an account snapshot and a branch result.
The worked example uses hypothetical modeled-loss allowances in USDT. They include assumed fees and slippage under one stated scenario. The policy sums allowances without hedge credit. Real gaps, failed protection, liquidation or different costs can produce larger losses; this is an admission model, not a loss guarantee. The portfolio correlation guide explains why apparently different positions can lose together.
Work the mixed graph from the leaves inward
Assume a fictional account policy allows 300 USDT of aggregate modeled loss. Existing positions occupy 70 and earlier pending intents occupy 30, leaving 200. A new evaluation contains:
- Route A: a smaller entry with a 90 USDT allowance.
- Route B: an alternative larger entry with a 140 USDT allowance.
- Route C: a separate overlay entry with an 80 USDT allowance that can coexist with either A or B.
A and B are exclusive within this evaluation only because one routing decision selects one route, and no fallback can activate the other while exposure from the first remains. C is concurrent. All amounts below are hypothetical; no trades were run.
| Permitted action set | Additional allowance | Including the existing 100 | Within 300? |
|---|---|---|---|
| A or B, with enforced exclusivity | max(90, 140) = 140 | 240 | Yes |
| A and B if both can remain exposed | 90 + 140 = 230 | 330 | No |
| Either A or B, alongside C | max(90, 140) + 80 = 220 | 320 | No |
| A selected, alongside C | 90 + 80 = 170 | 270 | Yes |
| B selected, alongside C | 140 + 80 = 220 | 320 | No |
The graph cannot promise every permitted combination under the 300 cap. It can require a route-specific admission decision, remove a combination, or revise the proposed sizes and obtain the required approval. It should not quietly shrink B after a person approved its original quantity.
For a larger graph, calculate the largest permitted combined allowance across its reachable action sets. Add allowances that can coexist; take the maximum across genuinely exclusive alternatives. Sequential actions still add if the first position remains exposed when the second starts. Loops require an explicit bound on simultaneously surviving intents. An unbounded loop cannot receive a finite allowance from these rules alone.
Branch probability is unsuitable for enforcing this hard cap. Even if A were assumed to occur 60% of the time and B 40%, the weighted allowance would be 0.6 × 90 + 0.4 × 140 = 110. Adding C and the existing 100 gives 290, but the B-plus-C outcome still reaches 320. A hypothetical frequency estimate does not remove that permitted outcome.
Turn the chosen allowance into a durable reservation
Planning the envelope and admitting an actual order are separate tasks. After choosing A and C, the executor still needs current shared capacity. Another run may have occupied some of the 200 while analysis was underway.
The admission operation should check the applicable cap and record its reservation together, with coordination across all workers using that budget. PostgreSQL's Serializable isolation documentation describes committed transactions behaving as if executed sequentially, with serialization failures requiring retry handling. That is one implementation building block, not a complete exchange execution protocol. A database transaction cannot make an external exchange submission atomic with a local ledger.
Record the budget identity, run and intent identities, selected route, amount, measure, policy revision and reservation status. A repeated delivery of the same intent must not create another reservation. Conversely, two legitimate evaluations need separate capacity even if both selected route A. Trigger deduplication establishes the run boundary; it does not authorize reusing one allowance for distinct orders.
Follow the reservation beyond branch completion
A reservation tracks potential exposure, not whether a worker is busy. Consider A's 90 allowance under an explicitly proportional model. If 40% fills, 36 moves to position exposure and 54 remains reserved for the unfilled portion. The total remains 90. Fixed fees or nonlinear risk would require recalculation rather than this proportional split.
| Observation | Treatment to verify |
|---|---|
| Branch completes after submitting | Keep capacity for the accepted order and any fills. |
| Submission times out | Preserve unresolved capacity until the outcome is reconciled. |
| A partly fills and cancellation is requested | Keep filled exposure plus the potentially executable remainder. |
| Cancellation and cumulative fills are confirmed | Release only the unfilled amount that can no longer execute. |
| A position is closed and final state is reconciled | Recalculate occupied risk under the stated policy. |
For venue scope, Bybit's place-order documentation says acknowledgement is asynchronous and directs clients to confirm order status through WebSocket. An accepted request is therefore insufficient evidence for a completed lifecycle. Use the order-timeout reconciliation guide when submission outcome is uncertain.
An expired local reservation is not permission to forget an order. A timed-out worker may have submitted before its lease expired. Recovery must prevent that worker from submitting later with stale authorization and reconcile any submission already possible before releasing capacity.
Keep the budget attached to the reviewed graph
Changing a fork from exclusive to concurrent changes the envelope without changing any leaf's size. Changing a fallback so that it can run before cancellation confirmation has the same effect. Bind the allowance calculation to the reviewed workflow revision; the configuration-drift guide covers changes after approval.
Before relying on a graph, exercise both alternatives, concurrent arrivals, overlapping runs, partial fills, late cancellations and worker restarts. Record occupied capacity and resulting orders at each transition. If the test environment cannot produce one of these states, label it untested.
KLINEO's workflow review and activation guide explains the current testing boundary: new-workflow controls open Live activation, while compatible historical paper and backtest records remain readable. This worksheet does not establish that KLINEO exposes custom branch reservations or a fixture runner. Retain an unverified workflow as a draft when the required testing path is unavailable.
Method and limits
This AI-assisted article applies primary workflow, database and venue documentation to an original hypothetical budget worksheet. The max-and-sum calculations assume additive, nonnegative allowances with no hedge offsets. No exchange order, database concurrency test or live workflow was run. The worksheet can reveal oversubscribed permitted combinations; it cannot establish future loss, execution quality or strategy returns.