Changenow is a swap status chain from deposit confirmation to asset delivery

Changenow is a staged exchange order whose status page separates an incoming blockchain payment, its confirmation, the conversion, and the outgoing delivery. "Awaiting deposit" means no recognized payment; "Confirming" means the source network is adding blocks; "Exchanging" covers conversion; "Sending to you" covers payout creation; and "Finished" means the destination transfer was sent. Read each label against the matching transaction hash, because the order record and the two blockchains prove different parts of the same swap.

Which costs move between the quote and delivered balance?

The Changenow quote reflects 3 economic effects: the source-chain transaction cost, conversion execution, and the destination-chain payout cost. The sending wallet pays the first cost when it creates the deposit, while the displayed receive estimate incorporates the service's remuneration, execution conditions, and the fee needed to send the output asset. A wallet or exchange that subtracts its withdrawal charge from the entered amount can therefore make the deposit smaller than the order expects.

Classic-rate and fixed-rate orders bind those effects differently. A classic quote remains an estimate until the confirmed deposit reaches conversion, so market execution and the destination network fee shape the delivered quantity. A fixed-rate order preserves its displayed output only when the exact amount and the order page's countdown conditions are met. The countdown shown on that order is the operative timing value; it should not be replaced with a remembered generic window.

Status helps locate the cost boundary. Before "Confirming," the source fee has already been committed but conversion has not begun. At "Exchanging," the service is executing the quoted route. By "Sending to you," the output and its payout transaction are being formed, so the relevant remaining variable is destination settlement rather than another trade.

Changenow, Uniswap, and Binance expose different completion proofs

The Changenow order page combines a source deposit, an off-chain conversion, and a destination payout into one status line. Uniswap exposes an Ethereum Virtual Machine (EVM) smart-contract receipt for a swap, while a Binance spot trade and withdrawal appear as two separate custodial records. Their completion evidence is therefore structurally different.

An Etherscan receipt proves what an Ethereum contract executed, yet it does not describe an off-chain liquidity handoff. A Binance balance proves an internal credit before withdrawal. The instant-exchange status model bridges these views: the order ID follows internal processing, and the two transaction hashes anchor the incoming and outgoing chain events.

Awaiting deposit begins with one exact on-chain action

The "Awaiting deposit" state means the order exists but its requested input has not been recognized. Recognition requires the displayed asset, network, amount, deposit address, and any extra identifier to arrive together. Copying only the address is insufficient when the page also supplies an XRP destination tag or a Stellar memo.

Network identity matters even when tickers match. USDT issued as an ERC-20 token on Ethereum follows a different ledger from USDT on Tron under TRC-20 or USDT represented by the Solana Token Program. An Ethereum address contains 20 bytes and is normally written as 40 hexadecimal digits after the 0x prefix, but that format does not make every EVM token or chain interchangeable.

Shared deposit accounts need a second routing field. An XRP destination tag is an unsigned 32-bit integer, while a Stellar memo ID is an unsigned 64-bit integer. Those values route one on-chain transfer to the intended order. Until the complete routing tuple is detected, the page remains at the opening state even if the sending wallet already shows a broadcast.

Confirming turns a broadcast into an accepted deposit

The "Confirming" state means the input transaction has been detected and the source network is building the required confirmation depth. A wallet's "sent" label records broadcast or inclusion; the exchange waits for its own acceptance threshold before releasing the order to conversion.

Changenow sets the normal acceptance point at 6 block confirmations while retaining a chain-specific threshold for each asset. Confirmation time therefore starts with protocol cadence: Bitcoin targets a 10-minute block interval, Litecoin targets 2.5 minutes, Dogecoin targets 1 minute, and Ethereum proof of stake advances through 12-second slots. These are construction parameters, not end-to-end completion promises.

The source transaction fee affects how quickly validators or miners first include a payment, whereas the required depth governs what happens afterward. Once the order page advances to "Exchanging," additional source-chain blocks remain visible in an explorer, but they no longer describe the conversion queue or the destination payout.

Exchanging marks the off-chain conversion handoff

The "Exchanging" state begins after the deposit satisfies the confirmation rule and enters the conversion process. At this point, the source hash proves that value arrived, but no destination transaction must exist yet because the output asset has not reached the payout stage.

Liquidity-provider execution, asset availability, and the selected rate mode govern this interval. A classic order settles against the executable route, while a qualifying fixed order carries forward its locked output. This step distinguishes the service from an atomic Uniswap call: one contract receipt contains the decentralized swap, whereas an instant exchange coordinates confirmed input, venue execution, and a later withdrawal across separate systems.

Refreshing the page does not restart conversion, and closing the browser does not cancel it. The durable handle is the order ID. A motionless "Exchanging" label describes an incomplete internal stage; the source explorer cannot reveal whether the next event will be payout, an action request, or another terminal status.

Sending to you separates conversion from settlement

The "Sending to you" state means conversion has completed and the service is preparing or broadcasting the output transfer. It shifts the evidence boundary from the source chain to the destination chain. Before an outgoing hash appears, the recipient wallet has nothing chain-specific to index.

Bitcoin transaction IDs and Ethereum transaction hashes each represent 32 bytes and are displayed as 64 hexadecimal digits. Solana uses the first Ed25519 signature as the transaction identifier; an Ed25519 signature is 64 bytes and is normally rendered in Base58. These identifiers are not the exchange order ID, even when the order page displays both.

Etherscan, Solscan, and Blockchair read ledger data, while MetaMask, Phantom, and Ledger Live present wallet-specific views of that data. The explorer record should show the selected output network, recipient address, transferred quantity, and growing confirmation count. A delayed wallet notification does not move the order backward to conversion.

Finished is a delivery claim with a second confirmation layer

The "Finished" state means the payout has been sent to the recipient address; the destination blockchain then continues its own settlement process. The outgoing hash is the bridge between that order-level claim and the receiving ledger. Matching the hash, asset contract or native coin, network, and address closes the evidentiary gap.

Wallet displays can round balances, so base units provide a cleaner check. Bitcoin uses 8 decimal places, with 100,000,000 satoshis in 1 BTC. Ether uses 18 decimal places, with 10^18 wei in 1 ETH. Solana uses 9 decimal places, with 1,000,000,000 lamports in 1 SOL. These fixed unit relationships let the delivered amount be reconciled without relying on a fiat conversion.

An ERC-20 receipt can be present even when MetaMask has not added that token contract to its asset list, and a Solana token account can settle before Phantom refreshes its interface. "Finished" should therefore be read as a payout event, not as a guarantee that every portfolio screen has updated or that every recipient platform has applied its own credit policy.

Verifying, Failed, and Refunded are different endpoints

The "Verifying," "Failed," and "Refunded" labels describe three different branches, not synonyms for a delayed order. "Verifying" pauses progression for a compliance workflow; "Failed" says the planned exchange did not complete; "Refunded" records a return path after the forward route ended.

For integrated transactions, a Sumsub verification link is valid for 3 days. Completing the requested workflow allows an eligible order to resume, while declining it moves the case toward the return rules that apply to that order. The order page, rather than elapsed clock time, identifies which branch is active.

A "Failed" page does not by itself prove that a return transaction has settled. Refund evidence requires its own asset, destination address, transaction hash, and source-chain confirmations. If conversion had already occurred before the route stopped, the returned asset can follow a different leg from the original deposit, so the displayed action and outgoing hash determine what was actually sent. A related page goes further into Changenow limits.

Underpayment and overpayment create a decision branch

The amount-mismatch branch appears when the recognized deposit differs from the quantity attached to the order. The exchange page can present 2 actions - continue under the revised conditions or request a refund - when both routes remain available. In other cases, only the executable action appears, such as a refund when the output network fee makes continuation impractical.

An underpayment changes the amount available for conversion, while an overpayment requires the system to resolve value beyond the original instruction. The minimum is calculated for the selected asset, pair, and network at order creation rather than supplied as a universal protocol constant. Reading the offered branch before authorizing anything preserves the link between the deposited amount and the eventual payout or return.

A rate change is also a state transition, not merely a different number on the original quote. Continuing accepts the newly displayed route; choosing refund abandons the forward delivery path. The next useful evidence is then either a destination payout hash or a refund hash, not another copy of the source transaction.

Why the same five-state language spans unlike networks

The five-state vocabulary - Awaiting deposit, Confirming, Exchanging, Sending to you, and Finished - normalizes networks with very different clocks and identifiers. Bitcoin counts mined blocks, Ethereum counts proof-of-stake slots, and XRP Ledger uses validated ledger versions, yet the reader still sees the same operational boundaries.

Under normal conditions, Changenow launched its instant-exchange platform in September 2017, and the status abstraction reflects the service's role between wallets, chains, and liquidity venues. The labels do not erase network mechanics; they tell the reader which dependency currently owns progress. That separation also explains why one universal completion time would be misleading.

Closing the order means reconciling four identifiers

The closing record contains 4 independent references: the exchange order ID, source transaction hash, destination transaction hash, and recipient address. The order ID identifies internal workflow; the source hash proves the deposit; the destination hash proves payout; and the address ties delivery to the instruction created at the start.

A forward swap is closed when the order shows "Finished" and the destination explorer matches the intended network, asset, address, and delivered base-unit amount. A refunded route substitutes the refund transaction and return address for that destination evidence. Keeping those records together preserves the full lifecycle without treating a wallet notification, an internal status, or a single chain event as proof of every stage.

Last updated 5 August 2026