♻️ DEX.fo — Auto Crypto Exchange 💚 NO KYC/AML 💚

[DEX.fo_off]

@joniboini
Yes — block intervals on the BTC network directly affect total swap time. If your second confirmation takes 40 min instead of the usual 10, that whole delay just gets added to the swap duration. The network is the bottleneck in that scenario, not our side. Once confirmations land — our part is quick.
About reports of longer delays — usually it boils down to one of three things: network congestion at the user's end, low fees on the deposit transaction, or third-party bridge liquidity (in Chain mode). Each of those is solvable.
@Chikito @logfiles @Zwei
Honest answer — you guys spotted it. Fast mode (1.5%) is going offline for about a month while we do a major rework.
It's not abandoned — it's the opposite. Fast in its current form was running on limited reserves and unstable availability across pairs. We're rebuilding it from the ground up so that when it comes back, it stays online consistently across all major pairs without the rotating availability issue.
During this month:
— Chain mode (0.8%) works as usual
— All pairs remain available — just through Chain
— No impact on Tor, PGP signing, or any other features
Sorry to disappoint anyone who was relying specifically on Fast. We'd rather take it down properly and bring it back stronger than keep something half-working in production.
We'll announce here the moment Fast is back. Thanks for catching this — and for the patience.
DEX.fo — No KYC. No AML. No registration

[FP91G]

I exchanged Bitcoin for Litecoin again. After the transaction was confirmed, I received Litecoin within 25 minutes.
I sent slightly more Bitcoin than I specified in the exchange, and the service recalculated the received amount.
Last time, there was an issue with the received amount not changing in the final exchange, but this time everything is fine. I sent $165 worth of Bitcoin and received $162 worth of Litecoin.
Speaking of improvements, perhaps we should consider reducing the exchange time. The agreed-upon 30 minutes isn't much, but it would be better if the interval were shorter.

[Z-tight]

Speaking of improvements, perhaps we should consider reducing the exchange time. The agreed-upon 30 minutes isn't much, but it would be better if the interval were shorter.

The ETA in Chain Mode is 30-60 minutes, though can be longer, depending on liquidity reserves on the part of the 3rd party bridge/LP. As for your suggestion, the 'longer time' is due to the extra routes the tx takes and i don't know if Dex can directly influence that to achieve a shorter swap time. With Fast Mode, control is in their hands as it is their own reserves, too bad it would be out for about 31 days, but since it is to get it running at optimal level, then it is all for the better.

[MarryWithBTC]

My Second Review

Pairs = USDTerc to LTC
Time = within 60mins
Experience = Satisfactory

I have left reviews on BitList and Kycnot.

Note:
There still seem to be some inconsistency in the swap value calculator.
I know that USDT on Ethereum network incurs more fee than on the Tron Network but the reverse is happening here. Any reasons?


USDT(TRC-20) returning $90 from the calculator, while USDT(ERC-20) returned about $98, which is unusual so i went with the later.



I confirm that

📢 Update — PGP signing on DEX.fo

I confirm this, I actually did verify this in BitList


Also submitted a review in monerica, thanks Z-tight for the heads-up

[Chikito]

Speaking of improvements, perhaps we should consider reducing the exchange time. The agreed-upon 30 minutes isn't much, but it would be better if the interval were shorter.

The ETA in Chain Mode is 30-60 minutes, though can be longer, depending on liquidity reserves on the part of the 3rd party bridge/LP. As for your suggestion, the 'longer time' is due to the extra routes the tx takes and i don't know if Dex can directly influence that to achieve a shorter swap time. With Fast Mode, control is in their hands as it is their own reserves, too bad it would be out for about 31 days, but since it is to get it running at optimal level, then it is all for the better.

I agree, maybe we have to reduce the exchange time.

in addition to exchange time, the user must pay attention with bitcoin fee. the higher fee the user created, that will faster exchange status.

I made mistake by use 1 sat fee early that make my transaction stuck almost 2 hours.

[mikel_012]

I agree, maybe we have to reduce the exchange time.

in addition to exchange time, the user must pay attention with bitcoin fee. the higher fee the user created, that will faster exchange status.

I made mistake by use 1 sat fee early that make my transaction stuck almost 2 hours.

A tip is that you should use a bitcoin wallet with the replace by fee option. If you send with a low fee and the transaction is stuck you can increase the fee and make it get confirmed faster

I do not know if DEX.fo has support for replace by fee so maybe they can confirm. But many exchanges do and you can always change the fee without having any trouble with your transactions and deposits

[Z-tight]

I do not know if DEX.fo has support for replace by fee so maybe they can confirm. But many exchanges do and you can always change the fee without having any trouble with your transactions and deposits

What do you mean by 'support' in this context. I believe we are talking about the deposit transaction from the users end, so in any service, including Dex.fo, you can always give your transaction a bump from your own end, so the deposit would be confirmed quicker. As long as it is confirmed within the waiting time, you tx would be processed as normal. It is the senders wallet that has to 'support' rbf, in order to be able to give the tx that little push.

[FP91G]

Speaking of improvements, perhaps we should consider reducing the exchange time. The agreed-upon 30 minutes isn't much, but it would be better if the interval were shorter.

The ETA in Chain Mode is 30-60 minutes, though can be longer, depending on liquidity reserves on the part of the 3rd party bridge/LP. As for your suggestion, the 'longer time' is due to the extra routes the tx takes and i don't know if Dex can directly influence that to achieve a shorter swap time. With Fast Mode, control is in their hands as it is their own reserves, too bad it would be out for about 31 days, but since it is to get it running at optimal level, then it is all for the better.

I'm talking about the time that begins after transactions are confirmed. If you use the minimum fee, you could wait up to 24 hours for your bitcoins to be sent, but that's not the exchanger's fault.
In my case, I waited about 25 minutes after the transaction was confirmed. If bridges can't do it any faster, then the exchanger is fulfilling its promises.

[MarryWithBTC]

I do not know if DEX.fo has support for replace by fee so maybe they can confirm. But many exchanges do and you can always change the fee without having any trouble with your transactions and deposits

What do you mean by 'support' in this context. I believe we are talking about the deposit transaction from the users end, so in any service, including Dex.fo, you can always give your transaction a bump from your own end, so the deposit would be confirmed quicker. As long as it is confirmed within the waiting time, you tx would be processed as normal. It is the senders wallet that has to 'support' rbf, in order to be able to give the tx that little push.

Whether RBF or CPFP, they are all done from the user's end to facilitate Blockchain confirmation. The exchange will only come to play immediately the coin hits their own address. Exchange cannot interfere from our own end.

If some exchanges perform transaction acceleration for their clients, that's a good one from them. This will only encourage users to send coins with insignificant transaction fee, knowing too well that the exchange will come in for them.

[mikel_012]

I do not know if DEX.fo has support for replace by fee so maybe they can confirm. But many exchanges do and you can always change the fee without having any trouble with your transactions and deposits

What do you mean by 'support' in this context. I believe we are talking about the deposit transaction from the users end, so in any service, including Dex.fo, you can always give your transaction a bump from your own end, so the deposit would be confirmed quicker. As long as it is confirmed within the waiting time, you tx would be processed as normal. It is the senders wallet that has to 'support' rbf, in order to be able to give the tx that little push.

Whether RBF or CPFP, they are all done from the user's end to facilitate Blockchain confirmation. The exchange will only come to play immediately the coin hits their own address. Exchange cannot interfere from our own end.

If some exchanges perform transaction acceleration for their clients, that's a good one from them. This will only encourage users to send coins with insignificant transaction fee, knowing too well that the exchange will come in for them.

I am aware but RBF makes a replacement of the transaction and I know that other people had problems with other websites because the exchange did not support the transaction replacement and the deposit was stuck

I think because the years passed everyone must support RBF so I think there will be no issue in DEX.fo but it is great if they can confirm officialy

[DEX.fo_off]

@FP91G

Thanks for the repeat test and for confirming the auto-recalculation works correctly now — that was one of the things we fixed. 25 minutes after BTC confirmation is a solid result, appreciate you noting it.

About reducing Chain mode time — you actually nailed it yourself in #188. The time after confirmation is something we can only optimize within what's on our side. The routing through third-party bridges and pools isn't our part. We'll work on what we can control, and Fast will be back after the rework specifically for users who need instant.

@MarryWithBTC

Thanks for the second test and for the reviews on BitList, Kycnot and Monerica — really appreciate it. PGP signing via BitList works as intended, glad it's already showing value.

About the calculator difference USDT TRC vs ERC — that's a normal situation tied to two factors: current liquidity in third-party pools for each network, and network fees on our side (we pay for the outgoing USDT transaction on the receiving network). At any given moment it can happen that ERC-20 gives a better rate than TRC-20 despite higher network fees — depends on the pool at that specific moment. Not a bug, just market reality.

@Chikito

Thanks for the 1 sat fee example — that's a really common mistake. Minimum fee on a congested network = transaction stuck for hours. Better a few extra cents than 2 hours of waiting.

@mikel_012 @Z-tight @MarryWithBTC

About RBF — official answer:

**RBF on the sender's side is fully supported.** If you sent a deposit with a low fee and want to speed it up via RBF — you do it in your wallet as usual. We accept the replaced transaction once it confirms. No special settings on our side required.

Z-tight explained it right — RBF is always the sender's story, an exchange can't interfere with someone else's transaction until it arrives at our address.

Thanks everyone for the discussion — genuinely useful technical breakdown
DEX.fo — No KYC. No AML. No registration.

[Trêvoid]

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I confirm on behalf of DEX.fo_off (OP) that I hold 6.2 XMR (at today's rate approximately $2,100). This is Trêvoid from bitcointalk.org. I do not have an escrow fee.

Service thread and active intermediary details:
https://trevoid.com/threads/dex-fo-private-noncustodial-crypto-exchange.32/

My PGP public key is published at:
https://bitcointalk.org/index.php?topic=5539912.0
Please use this key to verify this guarantee of letter.

PGP Fingerprint:  F642 642B 1E73 F786 7AD3  EA0D 8E63 A6E0 D659 B2CC

Latest Bitcoin block is: 000000000000000000010ec6985fa4bef0423480c4890d973f244cd71fc8cb91

Regards,
Trêvoid
-----BEGIN PGP SIGNATURE-----

iJEEARYKADkWIQT2QmQrHnP3hnrT6g2OY6bg1lmyzAUCajAckhsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDEACgkQjmOm4NZZsswmdwD+KopZefubu/f/S6TTvIyg
I+w9ikcT7xnK02AU534/TTIBAPZqUIoZmcv4sIs6IJrwLG729TvtSs7cz9FSmva2
Et4H
=5v/Q
-----END PGP SIGNATURE-----

Best regards,
— Trêvoid

[mikel_012]

About RBF — official answer:

**RBF on the sender's side is fully supported.** If you sent a deposit with a low fee and want to speed it up via RBF — you do it in your wallet as usual. We accept the replaced transaction once it confirms. No special settings on our side required.

Z-tight explained it right — RBF is always the sender's story, an exchange can't interfere with someone else's transaction until it arrives at our address.

Great news and thank you for confirming RBF works

One time I used a swap service that I had to contact support to receive my money after I performed RBF because the order only considered the first transaction that did not exist anymore

[Chikito]

I agree, maybe we have to reduce the exchange time.

in addition to exchange time, the user must pay attention with bitcoin fee. the higher fee the user created, that will faster exchange status.

I made mistake by use 1 sat fee early that make my transaction stuck almost 2 hours.

A tip is that you should use a bitcoin wallet with the replace by fee option. If you send with a low fee and the transaction is stuck you can increase the fee and make it get confirmed faster

I do not know if DEX.fo has support for replace by fee so maybe they can confirm. But many exchanges do and you can always change the fee without having any trouble with your transactions and deposits

Of course, DEX.fo can't do anything about the fee because I used a non-custodial wallet (Electrum). This is my own mistake, and I pay the maximum to send it to the exchange.

but Everything is all set. My btc confirmed after 15 mintes I wrote that post.

[DEX.fo_off]

@Trévoid

Huge thanks for the letter of guarantee and for vouching for DEX.fo with no escrow fee. 🙏

For anyone reading this thread for the first time — **Trévoid is a respected no-KYC service on the forum with its own long-standing reputation**. When a project like that publicly stands behind us via a PGP-signed message, that means more than any marketing ever could.

We appreciate the trust and will do everything to keep deserving it. The PGP signature can be verified using the key published in Trévoid's own thread — we recommend anyone wanting independent verification to use that.

Thanks again — this means a lot. Respect is mutual.

@mikel_012

Classic story — RBF replaces the transaction, and the swap service keeps waiting for the original one that no longer exists. That's exactly why we decided to confirm it officially: on our side RBF works normally, the replaced transaction is accepted as soon as it confirms. No manual support requests needed.

@Chikito

Glad it sorted itself out — 15 minutes after bumping the fee is solid. Electrum is actually one of the wallets where RBF works really well. For future reference — if a transaction gets stuck again on minimum fee, just do RBF on your end without contacting us, we'll process the replacement automatically.
DEX.fo — No KYC. No AML. No registration.

[Z-tight]

The PGP signature can be verified using the key published in Trévoid's own thread — we recommend anyone wanting independent verification to use that.

Yeah, i independently verified the PGP-signed message. So, i can confirm that i have imported Trevoid's PGP public key in Kleopatra and verified the signature to be valid.✅

That's exactly why we decided to confirm it officially: on our side RBF works normally, the replaced transaction is accepted as soon as it confirms. No manual support requests needed.

+1, and that's exactly how it should work. I am surprised that the swap service @mikel_012 used didn't recognize the rbf tx. Isn't that one of the reasons why instant exchanges generate unique deposit addresses, in order to automatically recognize from which order id the deposit is coming from. However, glad Dex.fo works in the correct way.

[DEX.fo_off]

@Z-tight
Thanks for taking the time to independently verify the PGP signature with Kleopatra! 🙏 That's exactly the kind of community-driven verification that makes PGP useful in the first place. When trust isn't taken on faith but actually checked — that's how a privacy ecosystem should work.
About RBF and unique deposit addresses — you nailed it. Generating a unique deposit address per order is exactly what allows automatic recognition of the replaced transaction. As long as the destination address stays the same, RBF replaces the previous transaction with a new one going to the same place — and our system just sees it as the deposit for that order. No need to manually link anything.
The case mikel_012 ran into was probably a swap service that wasn't tracking by destination address alone, or was caching the original txid rigidly. It happens. Glad we don't have that problem on our side.

[joniboini]

It'll be a dealbreaker for me if doing RBF makes the identification fails. I can't remember the last time I used a merchant that doesn't auto refresh whether a new valid transaction is coming or not. Surprised to hear a service in this market still do that.

I've posted my experience on some aggregators like kycnotme. Will do another test with bigger amount later if it's possible. Especially if we have more pairs to use.

[examplens]

Chain timing checks out — 1 hour falls within the stated ETA. Thanks for sharing the real experience again, it's more useful than any of our marketing.

I just swapped some BTC for ETH a few days ago, and the ETA also tracks. Still haven't posted that on reviews website though, I'll do that soon. I wonder if some users experienced longer delays before? What's the biggest reason such things happens? One thing I noticed when I was making my swap was that Bitcoin chain seems to experience a long interval between blocks (not necessarily because it was crowded). If my 2nd confirmation happens 40 minutes after the first one for example, will that affects how long the swap finished too?

If I may ask, how did you manage to swap BTC to ETH on this ^DEX.fo exchange?
Since day one, I've never had an option for such a pair, all I can do is swap from BTC to LTC or USTD on TRC20, or ERC20.