@joniboini
Just to be clear — RBF on our side works as expected. You won't run into identification issues here. As we confirmed earlier, the replaced transaction is accepted automatically as soon as it confirms. Looking forward to your bigger test, and yes — more pairs are coming. Native ETH is next.
@examplens
Fair catch! BTC→ETH direct isn't a listed pair, joniboini likely meant going through USDT or via a multi-step swap. Native ETH is in active development and will be the proper fix for that — coming soon.
@AakZaki @TryNinja @dwyane36
Thanks AakZaki for the detailed comparison and thanks TryNinja and dwyane36 for breaking down the math correctly — the explanation is exactly right.
Let's be transparent here. On small USDT swaps via Chain mode, the network costs eat a big chunk of the output. On a $30 swap, paying multiple TRX fees across the routing chain plus a destination network fee can absolutely push the effective fee to 25-30% — not because our platform fee is 30%, but because $7-9 of fixed network costs on a $30 swap is mathematically a huge percentage.
That's why our platform fee is 0.8-1.5%, **but the effective cost on tiny amounts via Chain mode is much higher**. We don't try to hide this — you can see it in the calculator before confirming the order.
What changes the math:
1. **Bigger swaps** — fixed network costs become a small share. $1,000 swap = around 1.7% all-in. $10,000 = around 1%.
2. **Fast mode** — single transaction from our own reserves, no bridge hops. Effective fee much closer to the platform 1.5%.
We're working on expanding Fast mode availability across more pairs exactly to solve this. Right now Fast is undergoing a rebuild — when it's back, the picture for small USDT cross-chain swaps will look completely different.
@bitmover @ovcijisir @Hamza2424 @joniboini @MarryWithBTC
You're absolutely right on the UI/UX feedback. The grayed-out Exchange button without clear indication of what's missing is a real problem. We're working on it.
Plan for the next UI update:
- Clear placeholder text on the refund field: "Refund address (required) — same network as the deposit"
- Inline warning if the address format doesn't match the network
- Tooltip explaining why the refund address is required
About **why** the refund is required — TryNinja explained the practical side perfectly. Sending coins back to the original sending address is risky because most users deposit from exchanges, mixers, or custodial wallets, and those addresses aren't always credit-able. The refund address lets the user explicitly tell us where to send the funds if something goes wrong.
@Chikito
Order data on your local storage stays as long as you keep the bookmark — it's saved client-side. On our side, we don't keep order history beyond the operational window needed to complete the swap.
On CPFP — that's a sender-side maneuver. If the user can't bump the fee, we technically can't either on the receiving side. The exchange would have to wait for the original transaction to either confirm or drop from the mempool. Reach out via SimpleX support if you ever hit that scenario and we'll help work through it.
@logfiles @mikel_012
Quick clarification — **we're temporarily off Monerica** because we're rebuilding XMR processing under the hood. Once the new XMR handling is fully stable, we'll be re-listed. Nothing dramatic — just a technical pause while we finish that work. No reason to worry. We'll announce when we're back on Monerica.
@irfan_pak10 @Hamza2424 @MarryWithBTC
Glad the XI League sponsorship landed well! Supporting community projects is part of what makes this whole space worth being in. Good luck to everyone joining the fantasy league. 🏆
[DEX.fo](
https://dex.fo/) — No KYC. No AML. No registration.
