A multi-output swap's shares add up to one hundred percent, but that is not enough to check every branch. Dividing the budget can produce fractions of an atomic unit, while one direction's allocated amount may fall below its threshold. Check budget conservation, the rounding rule and each branch's constraints separately.
Identify the amount being divided
The sending amount, an intermediate budget and final receipts are different quantities. In the KOT.CASH split-swap description, shares concern allocation between directions. If outputs use different assets, their quantities cannot simply be added and compared with the number of source coins. That would require separate rates, conditions and a common measure.
This tool starts with an amount you identify as the allocation budget. Every entered minimum must use that same asset and the same process stage. If you only know an output coin's minimum, placing its number into an input-budget row is inappropriate. The model does not convert between assets.
| Branch | Share | Mathematical portion | Rule's allocation | Entered minimum |
|---|---|---|---|---|
| A | 50% | 50,000 + 0.5 | 50,001 | 49,000: condition met |
| B | 30% | 30,000 + 0.3 | 30,000 | 31,000: short by 1,000 |
| C | 20% | 20,000 + 0.2 | 20,000 | 19,000: condition met |
Why rounding every row independently is insufficient
Discarding every fractional remainder produces 100,000 units instead of 100,001. One unit remains unallocated. Rounding every portion upward can create the opposite problem: a sum larger than the budget. The rule therefore needs to cover the entire set rather than operate independently on each row.
- Convert the budget into an integer number of atomic units using the selected precision.
- Express shares in hundredths of a percent and check that they total exactly 100.00%.
- For each portion, take the whole number of units and retain its fractional remainder.
- Give the remaining whole units to branches with the largest remainders.
- Break equal remainders by a predefined ID order so rearranging input rows does not change the result.
The table's remainders are 0.5, 0.3 and 0.2. A receives the additional unit, making the allocations sum exactly to the budget. This is the chosen teaching rule. It does not assert that a real service uses the same order or rounding method.
Decimal notation and the atomic unit
With eight decimal places, 0.00100001 represents 100,001 units. One BTC contains 100 million satoshis; Bitcoin Core also uses this quantity. Precision is a separate input here because the tool neither identifies an asset automatically nor verifies its parameters.
Amounts use integer arithmetic without binary floating-point rounding of fractional amounts. Excess decimal places are rejected rather than silently discarded. Shares allow at most two fractional digits. These interface limits belong to this model; they do not describe every format supported by an actual exchange.
The decimal amounts in the example
For a budget of 0.00100001 with precision 8, the branches receive 0.00050001, 0.00030000 and 0.00020000. They sum to 0.00100001. This is arithmetic in one asset. Resulting ETH, SOL or other final assets are not calculated here.
Why adding up minimums is also insufficient
The example minimums sum to 99,000 units, less than the 100,001-unit budget. That checks only the aggregate amount. Under the selected shares, B receives 30,000 rather than the required 31,000. โThe minimums fit in totalโ and โone branch does not meet its minimumโ can both be correct.
- Budget conservation
- Checks that rounding neither lost nor created an atomic unit.
- Aggregate capacity for minimums
- Compares the entered thresholds' sum with the total budget.
- Each branch's condition
- Compares its allocated amount with its own entered threshold.
- Availability of an actual swap
- Requires the service's current conditions; the first three checks do not establish it.
What the model deliberately does not change automatically
- A shortfall is not silently covered from another branch, since that would change the selected shares.
- An unknown minimum is not declared zero. Entering zero only sets a zero threshold in this model.
- Zero allocations are reported separately instead of being dropped to make the total look better.
- An ID is a placeholder label; the address, network and ability to receive funds are not checked.
Before an actual operation, review the current calculation for every direction. If a minimum uses another asset, or fees change the available budget, this allocation alone is insufficient. Discuss the intended quantity and its units rather than moving a number between fields because they look similar.
When reviewing the KOT.CASH split-swap calculation, a useful question is: โAt which stage and in which asset is branch Bโs minimum stated?โ Prepare the selected shares and each thresholdโs units. This separates a direction-specific constraint from the simpler check that percentages sum correctly.
Allocate a teaching budget without losing atomic units
Teaching model with 2โ4 branches. Percentages use a decimal point, up to two fractional digits and total 100%. IDs are placeholder labels. Minimums must use the same asset and budget stage. Not a KOT.CASH quote; no fees or conversions are calculated. The calculation runs on your device; nothing you enter is sent anywhere.