Change now

Change now is a Non-Custodial Cryptocurrency Exchange With Fixed Rates

Change now is a fixed-rate swap workflow in which a displayed crypto output remains tied to one order while its deposit window remains open. Select the send and receive assets plus their networks, enter the receiving wallet and confirm the order. Then send the stated input to the generated deposit address before the countdown ends. The service confirms the deposit, executes the conversion and broadcasts the quoted output to the wallet you supplied.

Expired quotes and unusable fixed terms

An expired fixed-rate quote breaks the original terms because the deposit no longer matches the active order window. The fixed-rate condition requires the deposit to be sent within 4 minutes of the order's creation. Use the order countdown as the visible clock and complete the wallet broadcast before the deadline. A transaction hash in the sending wallet confirms the network accepted the broadcast.

Each order binds a quoted output to a particular deposit instruction. Splitting the input across two transfers conflicts with the single-deposit rule, while sending less or more than the displayed amount separates the payment from its original fixed terms. A late deposit also reaches the address outside the agreed window. If any of those events occurs, stop creating additional transfers and use the affected order's available continuation or resolution path. A replacement quote creates a separate order with new instructions.

Prepare the sending wallet before requesting the quote.

Pair and network selection before the quote

Pair and network selection determines which asset leaves the sender and which chain delivers the quoted output. Choose fixed-rate mode first, then set both sides of the pair. The ticker alone does not settle the network choice. Tether USDt, for instance, exists as an ERC-20 token on Ethereum and as a TRC-20 token on TRON.

EVM-compatible networks reuse a familiar address shape while maintaining separate ledgers. Ethereum mainnet uses chain ID 1, BNB Smart Chain uses 56, Polygon PoS uses 137, Base uses 8453 and Arbitrum One uses 42161. An identical 42-character account string on those networks still refers to five distinct chain contexts. Solana and its SPL Token standard use another account model entirely. Select only the network named by the sending wallet, the order and the receiving wallet; all three must agree before the quote becomes actionable. A separate page looks at this in practice.

Recipient address, memo and chain checks

Recipient details bind the payout to one address plus any chain-specific routing field the order requests. Copy the address from a wallet already configured for the selected output network. Confirm the first and last characters after pasting, then read the complete network label beside the field.

EVM recipients

EVM recipient validation covers the account string, the selected chain and the intended native asset or token contract.

Address structure

An Ethereum account address contains 20 bytes, displayed as 40 hexadecimal characters with a two-character 0x prefix. That produces 42 visible characters. MetaMask presents the same account format across several EVM networks, so address validation alone cannot identify Ethereum, Base or BNB Smart Chain. A correct-looking address still needs the correct network context.

Network identity

ERC-20 tokens add a contract identity to the network and account. ETH uses 18 decimal places, while USDC uses 6 across its supported ecosystems. Native USDC contracts also differ between Ethereum, Base and Arbitrum One. The order's asset and network selection determines the expected contract; pasting an EVM address does not replace that choice.

Memo-based recipients

Memo-based networks attach routing data beside the address. XRP Ledger source and destination tags are 32-bit unsigned integers, and an X-address packages a classic address with its tag. Stellar supports several memo forms: a text memo holds up to 28 bytes, a memo ID is a 64-bit unsigned integer and hash-based memos hold 32 bytes. Enter the exact extra field displayed by the receiving service. Solana does not use an XRP-style destination tag; Phantom and Solflare expose 32-byte Solana account addresses encoded for copying.

The fixed-rate order as a temporary instruction set

The fixed-rate order turns a market quote into a temporary set of exact transaction instructions. Its page connects the input pair, quoted output, recipient details, generated deposit address, exchange ID and countdown.

Read the order once from top to bottom before opening the wallet confirmation screen. The send asset and network must describe the balance you control. The receive asset and network must describe the destination wallet. The deposit amount belongs in the wallet's amount field, while the generated address belongs in its recipient field. Save the exchange ID before broadcasting because it identifies the off-chain order; the blockchain transaction hash identifies the separate on-chain payment. Reloading the quote widget creates another instruction set rather than editing the existing order.

Sending the single deposit

A Change now order expects one deposit matching the displayed asset, network and amount. Send the transfer once, from a wallet ready to broadcast, and retain its transaction hash.

Wallets convert human-readable amounts into each chain's smallest unit. Bitcoin uses 8 decimal places, with 100,000,000 satoshis in 1 BTC. Ethereum represents 1 ETH as 1,000,000,000,000,000,000 wei. Solana uses 9 decimal places and 1,000,000,000 lamports per SOL. XRP uses 6 decimal places and 1,000,000 drops per XRP. USDC uses 6 decimal places, so its raw token amount follows a different scale from ETH. The wallet handles these conversions, but the displayed send amount must remain unchanged.

Worked example

Every changing input in this worked example is hypothetical: a 0.250 BTC send amount, an 8.125 ETH quoted payout and an unused Ethereum recipient address.

Select BTC as the input, ETH on Ethereum as the output and fixed-rate mode before generating the order. Paste the recipient address, confirm the displayed pair and create the deposit instruction. Enter the generated Bitcoin address in the sending wallet and place exactly 0.250 BTC in its amount field. Broadcast one transaction and save its transaction ID. After confirmation, conversion and payout, the completed order should show 8.125 ETH sent to the specified Ethereum address. The concrete result for these stated inputs is 8.125 ETH.

What should the wallet transaction match?

The wallet transaction should match the order's deposit address, network and input amount before broadcast. A required memo, destination tag or payment ID must also occupy its dedicated field.

Read the wallet's final confirmation screen as a second representation of the order. For a native Bitcoin payment, it should show BTC moving to the generated Bitcoin address. For an ERC-20 deposit, it should show the named token transferring on the selected EVM network, not native ETH moving to the same address. Ledger and MetaMask display the destination and network before signing. Compare those fields with the active order, approve one transfer and wait for the wallet to return a transaction hash.

From network broadcast to service confirmation

Network confirmation begins after the pay-in transaction reaches the selected blockchain and the service detects it. Chain timing sets the earliest possible movement, while the service's asset policy determines its required confirmation threshold.

Bitcoin targets a 10-minute block interval. Ethereum divides time into 12-second slots, with 32 slots forming a 6.4-minute epoch. XRP Ledger versions normally close every 3 to 5 seconds. Those protocol figures describe block or ledger production, not the total swap duration. The transaction still needs inclusion, the required confirmation count, conversion processing and an output broadcast. Deposit size, chain finality characteristics and the service's confirmation policy set the remaining wait. Keep the order page and transaction hash together while those stages advance.

Reading the order statuses

Order statuses separate deposit detection, blockchain confirmation, conversion and payout broadcast into four visible active phases. A finished record follows after the receiving transaction has been created.

Awaiting deposit means the order has not matched an incoming payment. Confirming means the service detected the transaction and is waiting for its network threshold. Exchanging marks the conversion stage after the input has cleared. Sending to wallet means the conversion finished and the output transaction is being prepared or broadcast. The payout transaction hash becomes the durable bridge between the service's final status and the receiving blockchain. A browser refresh changes the display only; the exchange ID continues to identify the same order.

Save the exchange ID and both transaction hashes.

Confirming delivery in the receiving wallet

Wallet delivery is complete when the payout transaction targets the supplied address on the selected receiving network. Check the output transaction independently from the original deposit.

For ETH, inspect the recipient and value on Ethereum. For an ERC-20 payout, inspect the token transfer record, contract identity and recipient rather than relying only on the wallet's headline balance. Solana SPL Token payouts land in token accounts associated with the supplied owner address. XRP and Stellar transfers also preserve their network-specific destination data. The output transaction hash, asset symbol and network must agree with the completed order before the delivered balance becomes the confirmed position.

Wallet presentation can lag behind the chain record. A successful payout remains tied to its network and token identity while the interface refreshes its asset list.

Clean exit after settlement

A clean exit preserves the delivered balance under the receiving wallet and keeps enough records to reconstruct the fixed-rate swap. Self-custody recipients already hold the output at the supplied address after settlement.

Record three identifiers: the exchange ID, the pay-in transaction hash and the payout transaction hash. The first reconnects the quote and service statuses. The second proves which deposit reached the order, and the third locates the delivered asset. Confirm the receiving wallet supports the token before moving it again. If the destination belongs to another platform, wait for that platform's internal credit process after the on-chain payout confirms. These records leave a clear path from fixed quote through final wallet delivery.

Still wondering about Change now?