Changelly is a one-time swap route from quote acceptance to wallet receipt

Quote acceptance creates an order, not a wallet balance

The notable feature of the current Changelly swap flow is that accepting a quote creates a trackable order before any crypto leaves the sender's wallet. The order stores the input asset, output asset, amount, rate mode, recipient network, recipient address, and any required extra identifier.

The standard exchange route advances from an actual wallet transfer, not an ERC-20 allowance. This entry mechanism separates it from a decentralized swap approval: the user broadcasts one deposit to the generated address, and the order reads that deposit before exchanging anything.

Two rate modes - fixed and floating - lead into the same status system. The order model defines 10 named states: Created, Waiting for payment, Hold, Confirming, Exchanging, Sending, Finished, Failed, Not paid, and Expired. Created and Waiting cover setup and deposit detection; Confirming, Exchanging, and Sending describe active processing; Finished closes the route. Hold branches into identity review, while the remaining terminal labels explain why the normal route did not finish.

Before payment, the order is an instruction rather than a funded position. Sending the quoted asset is the action that moves control from the sender's wallet into the swap lifecycle.

A single-use pay-in address makes timing part of the order

The pay-in address belongs to one order and is non-reusable. A floating-rate address remains usable for 3 hours, while a fixed-rate address normally carries a 15-minute window. Fixed-rate addresses for 8 listed assets - BTC, XMR, LTC, DCR, EOS, GAS, BNB, and VET - use 20 minutes.

Fixed execution also requires the amount received to match the amount stated when the order was created. A late transfer, a repeat payment to the same address, or an incorrect fixed-rate amount leaves the automatic path; manual processing or a refund then replaces straight-through execution where the remaining amount covers the outgoing network charge.

Quote acceptance therefore binds three moving parts at once: amount, address, and deadline. Copying the pay-in address or scanning its QR code carries the same instruction; the source wallet must still broadcast on the order's selected network. The transfer should reproduce all three values rather than treating the displayed address as a standing deposit account.

Network selection decides whether the deposit can be matched

Network selection is part of the deposit instruction, not a cosmetic label beside the ticker. An ERC-20 token on Ethereum and a BEP-20 token on BNB Smart Chain use compatible-looking account formats, so the selected chain must travel with the asset name. USDT alone does not identify a transfer route.

Ethereum mainnet uses chain ID 1, while BNB Smart Chain mainnet uses chain ID 56; a matching 20-byte account shape does not identify the network. An EVM address is displayed as 40 hexadecimal characters after the 0x prefix, which explains why format validation alone cannot distinguish those two mainnets.

Extra identifiers solve a different matching problem. Shared deposit accounts on the XRP Ledger use destination tags; Stellar supports memo IDs, while Cosmos Hub ATOM and Hedera HBAR deposit flows use memos when the recipient specifies one. When the order displays a tag or memo beside the pay-in address, both fields form the deposit key.

Blockchain confirmations move the order into exchange processing

The Confirming status begins after the pay-in transfer is detected and ends when the input chain reaches the required acceptance depth. At 0 confirmations, the order cannot advance to Exchanging because the deposit has not entered a confirmed block.

Block production supplies the clock. Bitcoin targets an average interval of 10 minutes per block, although any individual interval differs. Ethereum assigns 12 seconds to a slot, and 32 slots form a 6.4-minute epoch. Those protocol figures do not set the service's confirmation threshold; the selected input asset and the order screen supply that requirement.

The sender's pay-in hash is the durable reference during this stage. The service observes the chain but does not create its blocks or shorten its consensus interval. Block inclusion and the growing confirmation count - not time spent watching the status page - cause the next transition.

Rate mode determines the amount carried into the payout

The Exchanging stage starts after the input is confirmed, and the chosen rate mode determines how the output amount is finalized. A timely fixed-rate order with the exact input preserves its quoted output, whereas a floating-rate order uses the market rate available during processing.

Changelly's published 0.25% exchange fee is included in the exchange rate, while the payout network charge is deducted from the final amount. The pair minimum also has to cover that outgoing network charge and the market's minimum exchangeable lot. A deposit below the displayed minimum is a stated reason for a Failed status.

Once processing begins, changing the desired size means creating another order later. The original order continues toward one output amount rather than becoming a balance that accepts incremental adjustments.

The payout hash separates platform status from network settlement

The Sending status means the exchange step has completed and the output transfer is moving toward the recipient address. Finished means the output was sent successfully, so the payout chain - not the input chain - now carries the final settlement evidence.

A normal completed swap leaves 3 references to reconcile: 1 Changelly transaction ID and 2 separate on-chain hashes, one for the pay-in and one for the payout. The platform ID locates the order inside transaction history, but it is not searchable on a block explorer. The first hash proves the deposit path; the second identifies the wallet receipt path.

If a status page and wallet display disagree, the payout hash answers the narrower question: which asset moved, on which network, to which address, and in what amount. It also separates a completed blockchain send from a wallet interface that has not refreshed its local token list.

Wallet accounting turns Finished into an observable balance

The recipient wallet closes the swap by showing the output asset at the selected address on the selected network. Wallet software converts integer base units into the decimal balance people read, so display precision matters when reconciling a payout.

Bitcoin accounts for value in satoshis: 1 BTC equals 100,000,000 satoshis and Bitcoin amounts resolve to 8 decimal places. Ethereum uses wei, where 1 ETH equals 10^18 wei and the familiar ETH display has 18 decimal places. ERC-20 token precision is separate from ETH; the Ethereum implementation of Tether's USDT uses 6 decimal places.

A wallet interface may need the correct network view and token entry before it renders that balance. The closing test aligns four facts - the payout hash, recipient address, token contract or native asset, and network - rather than relying on the Finished badge alone.

A routine adjustment creates a new one-time swap

A completed Changelly swap has no adjustable open quantity; a routine increase, reduction, or reversal starts with a new quote. Converting only part of a wallet balance therefore happens by entering that smaller send amount before accepting the order.

Adding another amount later creates a new transaction ID, new pay-in address, new deadline, and new pair of hashes. Reusing the previous address does not append value to the finished record. To unwind the conversion, the user selects the reverse pair and sends the chosen portion through a separate lifecycle, with a fresh quote and its own network charges.

Recipient custody does not change these mechanics. Ledger and Trezor devices or the Exodus software wallet receive the payout through an address for the exact asset and chain selected in the order.

A timestamped example shows where elapsed time accumulates

A swap timeline adds user delay, input-chain confirmation, exchange processing, and payout settlement. Separating those intervals explains why an order's total elapsed time is longer than any single platform stage.

Hypothetical inputs: a fixed-rate order is accepted at 12:00; the sender broadcasts at 12:03; the screen hypothetically requires 2 confirmations; hypothetical Bitcoin blocks include the pay-in at 12:08 and add the second confirmation at 12:17; exchange processing hypothetically takes 6 minutes; recipient-network settlement and wallet display hypothetically take 4 more minutes. These values form an illustrative sequence, not a live estimate.

Because BTC belongs to the 20-minute fixed-address group, inclusion at 12:08 falls inside the order window. Confirming ends at 12:17, Exchanging ends at 12:23, and receipt appears at 12:27. End-to-end elapsed time equals 27 minutes from quote acceptance, or 24 minutes from broadcast. The calculation assigns each delay to its actual dependency.

Discrete conversions suit a defined input and destination

The discrete conversion model fits a wallet-to-wallet action whose amount, pair, network, and destination are known when the quote is accepted. A single BTC-to-ETH conversion, a one-off change of a received token, or a direct payout to self-custody all match that structure.

Continuous position management requires a different workflow because this order has no persistent size, collateral, or adjustable exit. Changelly's one-time route instead gives every conversion its own boundary: one quote, one pay-in instruction, a finite status sequence, and one payout destination.

Closure is concrete. Finished status, the payout hash, the correct recipient address, and the balance on the selected network provide 4 aligned records. Reversing the conversion opens a new route in the opposite direction rather than editing the completed receipt. The model works cleanly when the recipient accepts a direct blockchain deposit and the sender wants no standing exchange balance afterward.