1. Detection is not confirmation
A pending payment is shown as soon as it is detected. It becomes eligible only after the quoted confirmation target is met. Monero funds must also be unlocked. Full payment detection starts the quoted confirmation window, three hours by default for new offers. Block timing varies; expiry before eligibility sends funds down the refund path once they qualify. Outgoing payouts have separate completion targets shown in the quote. Loading current confirmation requirements…
2. Fund an offer before it opens
Maker and taker payment windows are fixed by the service, each defaulting to 30 minutes for new offers. Send the full amount within the window shown in your quote. Your full maker deposit must be detected before the funding deadline. Your offer becomes public only after its funds qualify. Its availability countdown starts then.
3. First confirmation earns the reservation
Preparing an acceptance reserves nothing. The first full taker payment with at least one confirmation to be processed within a valid acceptance window earns the reservation. Existing acceptances can earn it after listing closure. Partial or unconfirmed payments do not reserve it. Other acceptances become refund-only.
4. Know when cancellation stops
You can cancel before your full deposit is detected, including after a partial deposit. Once full payment is detected, cancellation stops while it confirms. A funded maker can cancel an open offer until a taker earns the reservation. Neither side can cancel a reserved or committed convert. After listing closure, the maker cannot cancel while existing acceptance windows resolve.
5. Waiting has a deadline
Listing expiry is the last moment to start an acceptance, not a promised refund time. The fixed taker payment window is shown before acceptance and defaults to 30 minutes for new offers. Existing acceptances keep their full payment windows after the listing closes. Full payment detected in time starts a fixed confirmation window immediately. Its deadline replaces the payment deadline; it is not extra time added to that deadline, and later updates do not restart it. Maker funds stay held until active windows resolve, even if an acceptance is still unpaid. The payment window locked into the offer can keep maker funds held beyond listing closure. A qualifying payment can still earn the reservation. No new acceptances can extend the hold after listing closure. If its payment or confirmation deadline passes without qualification, the acceptance becomes refund-only; late confirmation never revives it. The maker offer reopens only if its listing deadline has not passed. Older offers retain the expiry rules quoted when they were created.
6. Refunds wait for eligible funds
Cancelled, expired, or unsuccessful payments become eligible for return to the fixed refund address once confirmed and spendable. Sending a refund also requires an actual network fee within the saved refund budget, available wallet inputs and passing safety checks. Funds remain owed while any of these conditions delay sending. Quoted cancellation or expiry fees may apply. If the maker cancels or another taker reserves the offer, affected takers pay no service penalty. A maker who cancels still pays the quoted maker cancellation fee. If cancellation refunds arrive in multiple batches, the service fee is calculated cumulatively without charging the same funds twice. Each separate refund also incurs its network fee. Uneconomical amounts remain owed.
7. Convert terms and payout fees
Convert amounts, platform fee rates, destinations, confirmation targets and timing rules are locked before funding. The confirmation deadline is calculated when full payment is detected; listing availability starts when the maker’s deposit qualifies. Bitcoin receiving and refund addresses must use native SegWit (bc1q…). For new offers, market amounts after platform fees are shown before the variable payout network fee. The maker chooses a speed and maximum fee for their incoming payout when listing; the taker chooses their own when accepting. Suggested limits account for the selected speed; Bitcoin suggestions use a fresh estimate with headroom when available. Suggestions are not guaranteed fees. Review the maximum deduction and minimum received before funding. Refund budgets are separate. Each recipient receives the incoming amount after platform fees minus the actual network fee. The fee limit is a maximum deduction, not a fixed charge; any unused allowance stays in the payout. Review your minimum received amount before paying. Fee-free offers waive service fees only; both displayed coin limits must be met. Existing orders keep their original terms.
8. Speed is a preference, not a guarantee
Bitcoin payout speeds target initial inclusion in 12, 6 or 2 blocks using the node's available fee estimate at payout time. Current estimates are approximate and can change before sending. Monero offers standard or higher priority; its fee is calculated when constructing the payout. Speed does not change the required security confirmations. A missing Bitcoin estimate or a fee above your limit delays that payout; funds remain owed. With your recovery kit, you can raise your own fee limit before signing, authorizing a larger deduction. A signed transaction cannot be changed through this control. Refunds use their separately quoted network budget.
9. Recovery continues after you leave
Save your recovery kit. A committed convert remains owed even if one payout is delayed. Other payouts can proceed when independent spendable inputs are available; waiting for one currency does not block the other. An accounting or wallet-balance discrepancy automatically stops new outgoing payments. An administrator may acknowledge an exact surplus and resume payouts while investigating it; shortfalls and other safety failures cannot be overridden. Any changed acknowledged surplus requires another review. If current wallet verification is unavailable, new payouts wait; funds remain owed. Already-sent transfers can still be acknowledged. Failed transfer attempts retry automatically; after eight failures, retries pause for operator intervention. Waiting for confirmations, a sufficient fee allowance or spendable funds does not count as a failed attempt. Closing the browser does not stop the service, but an offline or sleeping server delays processing. Deadlines do not guarantee an exact payment time.
btc