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

[cryptofrka]

I just tried it and was able to place a swap order and see the deposit address without any issues. It seems that something is preventing the page from loading properly for you. Did you try visiting the website with a VPN or a different browser?
The very large value displayed as "ordered amount" in your screenshot also looks weird. In my order, that field shows both the amount and the currency.

Yeah, managed to do it now. Not sure what was the case but it was happening to me on multiple occasions in a span of 1-2 hours.

I did the needed swap from a different PC/browser now so will retry the one that caused me issues later when I get home. The important thing is that it works

[examplens]

I just tried it and was able to place a swap order and see the deposit address without any issues. It seems that something is preventing the page from loading properly for you. Did you try visiting the website with a VPN or a different browser?
The very large value displayed as "ordered amount" in your screenshot also looks weird. In my order, that field shows both the amount and the currency.

Yeah, managed to do it now. Not sure what was the case but it was happening to me on multiple occasions in a span of 1-2 hours.

I did the needed swap from a different PC/browser now so will retry the one that caused me issues later when I get home. The important thing is that it works

It seems to me that the problem is with the ordered amount, which is unrealistic for any currency.
Maybe it can be considered as a bug because the system does not show the error and the reason why it happened, so it looks stuck

[DEX.fo_off]

@Ultegra134

You captured the actual issue perfectly — the first automated acknowledgment ("we got your message, working on it") does more for user experience than a fast final answer with no interim response. Silence during waiting is what generates panic, not the wait itself. We're looking at automating that first-touch acknowledgment so it lands consistently regardless of team load. Thanks for continuing to push on this.

Also — appreciate the second review below. Chain mode running smoothly under load is exactly what we design for. Fast mode availability for USDT-BTC depends on reserves in the moment; when Fast is back consistently across all pairs, that limitation goes away. Working on it.


@hosemary

On the on-chain proof-of-reserves — you're right, at our scale it's genuinely hard to implement cleanly. The moment we publish a set of addresses claiming "this is our reserves," we've published targeting information plus the aforementioned honeypot risk. Services that do full on-chain proof-of-reserves usually either aggregate into fewer wallets (concentrating risk) or use zero-knowledge proofs (which are technically expensive to set up and verify). Both are on the horizon for our roadmap but not something we can flip on this quarter.

The trade-off in the meantime — forum escrow + PGP-signed guarantees from independent parties + operational track record over time. Not perfect, but a reasonable stack.


@MarryWithBTC

Fair take across the board. The prize scaling from $30 to $50 to $100 mirrors the thread's activity growth honestly — more engagement, better contests. Credit to Peanutswar for driving that consistently.

On the escrow suggestion — Trévoid's response below covers the practical side. Their escrow is a limited-capacity arrangement they extend selectively, not a service they scale up. That's actually a feature, not a bug: if they took on every request, the guarantee would mean less. We're grateful they extended it to us; adding more services would dilute what makes their word carry weight.


@bitmover

Well-summarized on the Exploit escrow dynamic — it's basically the forum administration acting as a trusted third party specifically because their reputation is worth far more than the escrow itself. Skin in the game at multiple layers.

On PGP-signed statements as a general reputation feature on sites — noted. Something we can look at implementing on our /reputation page: rotating PGP-signed status updates that any user can verify with our public key. Would make ongoing status claims (like "site status normal," "no outstanding disputes," etc.) independently verifiable rather than just published text.


@hosemary (post 361)

Both points are constructive and both are on our list. The OP does need refreshing — the asset list is outdated (still shows DAI which we removed), and there's no compact summary of the discussion topics that keep repeating. We'll batch these updates:

— Updated coin list: BTC, ETH, XMR, LTC, USDT, USDC
— Escrow summary (1 BTC on Exploit.in + 6.2 XMR via Trévoid)
— PGP infrastructure (support signing + per-order signing)
— Refund address explanation with the "same coin you send FROM" framing
— Chain vs Fast mode mechanics
— Coming soon: Solana, BSC/BNB
— FAQ links for the most-repeated questions

The idea is exactly what you said — new users read the OP first and if it's comprehensive, they don't need to trawl 20+ pages to find answers already given. Should reduce the repetitive questions and let the thread focus on actual new discussion.


@MarryWithBTC (post 362)

"Set reminder, don't miss unless the operator says no" 😅 — sound approach.


@Trévoid

Fully understand the position. Extending guarantees is a limited resource that only carries weight because it's used carefully. We appreciate the trust you extended to us — and respect the boundary you keep for it. Both matter.


@dwyane36

Understood on the exotic/underserved pair interest. RUNE-BTC and similar emerging Layer 1 pairs are interesting from a demand standpoint, but the liquidity constraints on smaller L1 assets make them tricky to route reliably in Chain mode without wide spreads. We evaluate them individually as their liquidity ecosystem matures.

The general logic — we'll add pairs when we can offer them cleanly (reasonable spread, reliable settlement, no dead-ends on refund). Not just when they're asked for. Better to say "not yet" than to add a pair that quietly fails 30% of the time.


@AnybodyElse

Thanks for the swap report and the honest $150 first test — 27 minutes on Chain mode USDT (ERC-20) → BTC is a solid result. Glad the experience landed well.

On Fast mode for USDT → BTC specifically — it comes and goes depending on our BTC reserves at that specific moment. When Fast is available for that pair, the swap is instant post-confirmation. Right now Fast is in a broader rework to make it consistent across pairs — when that lands, "sometimes available, sometimes not" won't be the answer anymore.


@Ultegra134 (post 366)

Fair on the status messaging inside the UI during longer swaps — this ties directly to the point in your earlier post. A "currently routing through liquidity pool, expected 15-20 min remaining" indicator (or similar) during longer flows would help users understand what's happening instead of just watching a spinner. Adding to the UX list along with the refund field improvements.

Thanks again for the multi-angle feedback — you're pointing at real friction, not hypothetical.


DEX.fo — No KYC. No AML. No registration.

[SamReomo]

The minimum exchange amount starts at $30, but when you factor in transaction fees for certain coins, such operations aren't very cost-effective. I don't think the exchange limit should be lowered. Lowering the threshold would result in users losing a significant portion of their funds to fees, especially on the Ethereum or Bitcoin blockchains.

Well, that $30 is a good amount for anyone who wants to use the exchange, I'm very sure most of the users who use instant exchanges often exchange more than $30 per transaction. Only those who want to test an instant exchange for review purpose would like to have lower minimum amount to exchange. The fees aren't that high these days, there might be another reason why the minimum amount starts at $30, personally, I think majority of users would exchange higher than that amount that might be the reason why they've put minimum at $30.

[DEX.fo_off]

We're pleased to announce that we've updated the Escrow information and added links to the first post in the thread.

Information on all supported coins has also been updated.

Escrow:

1️⃣ Trevoid $2000: https://trevoid.com/threads/dex-fo-private-noncustodial-crypto-exchange.32/
2️⃣ Exploit 0.96 BTC: https://forum.exploit.in/topic/280924/

[stompix]

We're pleased to announce that we've updated the Escrow information and added links to the first post in the thread.

You should also add the links to the website, including the Trevoid's link.
Not that 0.00x matters that much to anyone, but you're guaranteed to see some nitpicking about why it's 0.96 and not 1.00; this is the world we live in 

Yeah, managed to do it now. Not sure what was the case but it was happening to me on multiple occasions in a span of 1-2 hours.
I did the needed swap from a different PC/browser now so will retry the one that caused me issues later when I get home. The important thing is that it works

How did you manage to create the order for that amount in the first place?
Whenever I try to use more than the max, I get a zero in my receiving amount.

[cryptofrka]

How did you manage to create the order for that amount in the first place?
Whenever I try to use more than the max, I get a zero in my receiving amount.

That's just the regular size I move

________________________

Kidding of course, it was a small 200$ swap. Must have been some sort of a bug.

[DEX.fo_off]

📢 DEX.fo Update

Two big changes from this thread's discussions:

🔓 Refund address is no longer mandatory — by popular demand from the community. Fill it in if you want a safety net. Leave it empty if you don't. Your call.

🌍 5 new languages added — German, Spanish, French, Polish, and Chinese. The site is now available in more languages so users can operate in their native tongue.

Come try it out. Big thanks to everyone in this thread who kept pushing on these — the service moves forward because of you.

DEX.fo — No KYC. No AML. No registration.

[Z-tight]

🔓 Refund address is no longer mandatory — by popular demand from the community. Fill it in if you want a safety net. Leave it empty if you don't. Your call.

Fair enough. If there is ever a need for a refund, it would be sent to the sender's address. So, up to users to decide what they want and how they would want a refund if it ever gets to that. You do a good job of listening to the community, which is great.

🌍 5 new languages added — German, Spanish, French, Polish, and Chinese. The site is now available in more languages so users can operate in their native tongue.

Congratulations on your growth thus far, which is very evident. And much more to come, cheers!

[MarryWithBTC]

🔓 Refund address is no longer mandatory — by popular demand from the community. Fill it in if you want a safety net. Leave it empty if you don't. Your call.

Nice update.
But then, leaving it empty will increase the workload of the support. If swap doesn't go through and I didn't provide a refund address, my next destination is the support.

[TokenTikas]

🔓 Refund address is no longer mandatory — by popular demand from the community. Fill it in if you want a safety net. Leave it empty if you don't. Your call.

Absolutely good update, but if there is any problem during the swap, then please also explain the refund system. Previously, there was a refund address criteria for making refunds but now if there is a problem because the refund address is no longer being used then how will the refund be made? Will the refund be sent to the same address from which the funds were sent?

Come try it out. Big thanks to everyone in this thread who kept pushing on these — the service moves forward because of you.

Actually, no one is putting pressure on you here but they are giving suggestions about the things in the project that need to be improved or added. We are happy that you are taking the different opinions we are sharing here seriously and updating everything in the project accordingly.

[hosemary]

🔓 Refund address is no longer mandatory — by popular demand from the community. Fill it in if you want a safety net. Leave it empty if you don't. Your call.

Since it's no longer mandatory to provide a refund address when creating an order, you need to update the last statement under "How exchanges are performed?" in the FAQ. Now it says "The refund address is required to create an order and cannot be changed after the order is created."

[examplens]

Refund address is no longer mandatory — by popular demand from the community. Fill it in if you want a safety net. Leave it empty if you don't. Your call.

OK, this is not bad progress here, although the 'notification' of why the refund address is incorrect is still missing. As far as I can see, only the wallet icon changes color from green to red, but no information about why.
A few who participated in that discussion know about it, and I think it would be more complete with such information.

[DEX.fo_off]

Important clarification for everyone reading this thread:

If you don't provide a refund address, funds will be returned to the address they were originally sent from.

That's the automatic fallback. No refund address = we use the sender address.

The optional refund address field is there for cases where the sender wallet can't receive back — for example when funds come from a custodial exchange address that only sends but can't accept incoming transfers. In those cases, providing a refund address ensures the coins go somewhere retrievable.



Thanks — and yes, that's exactly the reasoning behind making it optional. Users know their own threat model better than we do. Some want the safety net, some prefer not to hand over an extra address for something that might never happen. Their call.

Appreciate the kind words on the growth. There's more work ahead.


On the support workload concern — good question. The automatic fallback (return to sender address) handles the vast majority of cases without any support ticket needed. Support only comes into play for edge cases where the sender wallet is a custodial address that can't receive back. So leaving refund empty doesn't dump the load on support — it just uses the sender as default.

Direct answer — yes, if refund is left empty and something goes wrong, the funds will be sent back to the address the deposit came from. That's the default automatic behavior.

The refund address field is only useful when the sender wallet can't receive back (custodial exchanges, for example). Otherwise the sender-address fallback handles it cleanly.

FAQ will be updated to reflect this — you're right, the current wording is outdated.

Well said — this thread is a source of specific, constructive suggestions, not pressure. That's rare and we appreciate it.

Good catch — the FAQ statement about the refund address being required is now outdated. Updating this week to reflect:

— Refund address is optional
— If left empty, funds are returned to the sender address in case of any issue
— If provided, funds are returned to the specified refund address

Thanks for pointing to the exact line that needs to be updated.


DEX.fo — No KYC. No AML. No registration.

[SensitiveEyes]

@SensitiveEyes @logfiles

Thanks for flagging the XMR sending issue. Confirming on our side — XMR is currently being fine-tuned and is temporarily unavailable during a specific overnight window, roughly 21:00–07:00 UTC (window is variable, give or take).

This is a temporary phase. Soon XMR will be running 24/7 without interruptions. A bit more patience — we're wrapping up the last adjustments.

Thanks for understanding, and for flagging these things quickly — helps us close the loose ends faster.

I flagged the XMR sending issue because other currencies worked. Closing the loose ends faster is going to benefit everyone. There must be a demand for XMR because consumers are focused on privacy. You are taking care of your topic because you read the posts and reply directly.

[MarryWithBTC]

Congratulations on your growth thus far, which is very evident. And much more to come, cheers!

I love the growth of DEX in this community and I love the fact that I am involved in this. The team is purely determined and not giving up. They way they systematically accept and implement community suggestions amazes me. Kudos!

Direct answer — yes, if refund is left empty and something goes wrong, the funds will be sent back to the address the deposit came from. That's the default automatic behavior.

Thanks for the direct answer. It brings more clarity. With this, there'll be no shifted workload on the support.

[LoyceV]

I was asked to write a review on DEX.fo.

Disclaimer
I used only Tor Browser for this review. Note that my review style it not telling you what's good. I'll only tell you what I notice and think can be improved. This is me going through the site with a big red marker.
I later added quotes from this topic where they fit in my review.

First impressions
I usually limit my testing to the coins I'm familiar with: BTC (for obvious reasons) and XMR (for privacy). I try to stay away from stable coins and ETH.
First impression: why is the minimum amount so high?
BTC > XMR: min: 0.00795921 BTC ($500!)
When I change BTC to LTC, the minimum is lower: min: 0.66867855 LTC ($30). But it took me a while to realize the trading pair automatically changed from the expected "LTC > XMR" to "LTC > BTC".
Clicking the green vertical arrows ("reverse transaction") doesn't work. If I select "XMR" under "YOU SEND", the receiving coin keeps animating:

So I can't send XMR and exchange it to something else.

This got me curious what works or doesn't work. Available coins:
BTC, ETH, LTC, USDC, USDT (ERC-20), USDT (TRC-20), XMR.
Every time I change the coin under "YOU SEND" to something else, the "YOU RECEIVE" reverts back to "BTC" (unless I select BTC, then it changes to ETH). It would be nice if the "RECEIVE" coin doesn't change (assuming the trading pair is available), so if I want to receive XMR, I want to be able to change what I send to compare rates without having to keep selecting XMR.

For other trading pairs, the minimum amount is more reasonable. To keep the minimum low, I'm not testing with XMR. BTC > LTC: min: 0.00047729 BTC ($30)
There are 2 options: "Chain" or "Fast". The latter isn't available:

I tried many different trading pairs, but none of them can use "Fast". At the same time, I see this:

I don't think this accurately reflects the System Status when not all functionality is available:

Fast mode (1.5%) is going offline for about a month while we do a major rework.

This could (and should) reflect in the System Status.

Rates and competitiveness
Let's compare rates. DEX.fo: 0.0005 BTC > 0.67763909 LTC.
On Orangefren, I selected "Never-KYC" and got 3 available options that would give me:
0.69833597 LTC (3.05% more)
0.7018 LTC (3.57% more)
0.70034971 LTC (3.35% more) (I didn't want to name the competitors here, that's not needed to make my point)
So for small amounts, DEX.fo gives terrible rates:

The difference in BTC received when using USDT-TRC20 vs USDT-ERC20 comes from network fees, not our exchange rate.
Our fee is the same — 0.8% Chain or 1.5% Fast for all networks and all pairs.

As I expected, this topic explained that the difference is caused by certain fixed fees per transaction, but if that's the case, shouldn't you post the actual fee including everything in the OP?
If the higher fees are because of transaction fees in multiple hops, I would expect "Fast" to be cheaper for small transactions, but I can't test it now due to unavailability.

Let's compare larger amounts:
DEX.fo: 0.01 BTC > 13.98818788 LTC
No-KYC competitors:
13.98654157 LTC (0.01% less)
14.028 LTC (0.28% more)
14.0217529 LTC (0.24% more)
14.0351 LTC (0.34% more)
14.05098916 LTC (0.45% more)
13.84152475 LTC (1.05% less)
So for larger amounts, the rates are more competitive, but not the best in the market.

At the bottom of the page, it shows what I think are the site's reserves. If that's what it is, it would be good to add the word "Reserves":


Exchanging
When I click "Exchange", I get a short time limit:

Code:

Remaining Time: 29:37

I like to thoroughly prepare transactions, and it might include manually typing and verifying addresses for offline signing, which takes a while (depending on the amount of course). Either way, 30 minutes can be tight.
This instantly raises questions: what if my transaction doesn't confirm fast enough? What if I use a fee < 1 sat/vbyte: will it be picked up? What if it arrives late: will it be refunded or do I get the option so accept current exchange rates?
I found the answer on the forum, but it should be easier to find (in the Q&A):

if the order timer runs out before the deposit confirms, the swap goes into manual review.

The Letter of Guarantee is signed using PGP. I've always preferred a Bitcoin signed message, that's much easier to verify: any half decent can wallet do it without downloading additional software. So I suggest to create and offer both "types" of LoG.

@TryNinja
Huge thanks for adding our PGP key to BitList! 🙏 This is exactly what PGP is for — independent verification through a trusted third-party service. Now any user can verify the authenticity of our messages and orders directly through bitlist.co.

Trusting a third party with your transaction details is terrible for privacy. If that's what needed to easily check a PGP signed message, that should be a very strong argument to just use a Bitcoin signed message.

Because XMR wasn't possible in a reasonable amount for testing, I didn't want to touch any of my Bitcoin. So I created a small ETH > LTC exchange. The speed was not disappointing: about 7 minutes after I sent ETH, I had LTC with 2 confirmations in my wallet.
But: while the website shows: "No hidden fees", and "YOU RECEIVE <amount>", I'd expect to receive that exact amount. I know the differences are tiny, but I like data, and data should always be consistent.
In just 7 minutes, I saw this:





This is what I would call hidden fees.

Suggestion: I'd like to be able to edit the amount in the "YOU RECEIVE" field: I type how much of a certain coin I need, and the site should tell me how much to send. But that only works if I get the exact amount I entered.

Terms of Service

The minimum deposit amount must meet the established limit for the selected direction. If not followed – the deposit will not be processed, and the funds will be lost. The maximum deposit amount must not exceed the set limit. In this case, we process only the maximum allowable amount; the remaining amount will be lost.

Brutal! May I suggest to add a recovery option? Sooner or later, someone is going to mess up, and if they lose a large amount of money, one way or another that looks bad on you. Just charge them for manual recovery.
To think about: what happens when 2 users make a transaction that drains most of the reserves at the same time? Say, right now, I can make 2 transactions: 2 BTC > 2802 LTC and 2.5 BTC > 3498 LTC. That exceeds the current max: 2.7839187 BTC (for this pair), so even though both transactions stayed under the maximum, the second one to be processed will be above the (new) maximum. Does that mean the amount above the maximum of the second transaction ends up "lost" as the ToS suggests?

Prohibited Jurisdictions: None (we cannot determine the client's country, as IP logging is disabled, and none of our software components process such information).

If this exchange becomes successful, this will become a problem. To quote myself:

I've said it before and I'll say it again: in the long run, we can't have good trusted no-KYC exchanges: if they're good, they'll be used by bad people, authorities will target them, and eventually shut them down. If they're bad, well, there's no point in using them.

Q&A

We can provide a proof of reserves on request.

I'm curious, but I didn't want to install SimpleX chat just for this.

.onion address

I suggest to make this more obvious. It took me a while to find it at the bottom of each page, I would have expected the link under the word "TOR" on the main page. I always overlook the ".onion available" on the address bar.

If you have selected the Simple mode during the order creation, we have sent Bitcoin to you and used the lowest possible mining fee.

I don't see a "Simple mode" when creating an order.

I'm missing the ELI12 explanation to this in the Q&A:

2️⃣ Chain mode: 0.8% fee, up to 60 minutes. Via decentralized cross-chain mechanisms.

How does this work? OmegaStarScream asked the same question 2 months ago, but I'd like to see a more detailed answer than we use atomic swap technology. I had to read through many pages to find it, although "a vetted pool" still sounds ambiguous. Without a clear explanation, it sounds like just buzz words, so I suggest to add this to the Q&A.

This should be included in the Q&A:

If you send more than the amount specified in your order — the exchange will automatically recalculate and process the full amount you sent at the same rate.

Escrow

1️⃣ Trevoid $2000: https://trevoid.com/threads/dex-fo-private-noncustodial-crypto-exchange.32/

I wouldn't call this an escrow, as discussed here. To use is, a user has to trust Trevoid instead of your site. It basically means a user won't use your site directly, and by adding a middleman that also means the middleman has access to private transaction data. That's one more party than needed.

2️⃣ Exploit 0.96 BTC: https://forum.exploit.in/topic/280924/

That forum has a hard time loading in Tor Browser, and when it works, it tells me I need to Sign In to read any details. Having to create an account to read the escrow conditions to use an anonymous platform is kinda ironic.

We'll look at posting a screenshot or additional confirmation format that Bitcointalk users can independently review without needing exploit.in access. Something visible from here, not just a link to a place most of the thread can't reach.

Posting a screenshot isn't enough if a future victim has to pay $200 to register in order to be able to contact the escrow holders.

TL;DR: you made it to the end

[TryNinja]

The Letter of Guarantee is signed using PGP. I've always preferred a Bitcoin signed message, that's much easier to verify: any half decent can wallet do it without downloading additional software. So I suggest to create and offer both "types" of LoG.

@TryNinja
Huge thanks for adding our PGP key to BitList! 🙏 This is exactly what PGP is for — independent verification through a trusted third-party service. Now any user can verify the authenticity of our messages and orders directly through bitlist.co.

Trusting a third party with your transaction details is terrible for privacy. If that's what needed to easily check a PGP signed message, that should be a very strong argument to just use a Bitcoin signed message.

What if I'm exchanging ETH for XMR, because that's what I have and want, do I need to download an unrelated Bitcoin wallet to verify their signed message?

FYI, BitList PGP verification runs entirely on your browser/device.

[Hamza2424]

Well, that $30 is a good amount for anyone who wants to use the exchange, I'm very sure most of the users who use instant exchanges often exchange more than $30 per transaction. Only those who want to test an instant exchange for review purpose would like to have lower minimum amount to exchange. The fees aren't that high these days, there might be another reason why the minimum amount starts at $30, personally, I think majority of users would exchange higher than that amount that might be the reason why they've put minimum at $30.

There are some other exchanges with lower fees and lower minimum exchange amounts, but why would person X prefer this over them? Obviously, there must be some benefit, right? No KYC and no AML mean something here. If you advertise No AML and someone makes a transaction without checking their AML score, then the platform freezes their funds, saying they had a high AML score while claiming to be No AML, is that a good deal?

That's why fees and the minimum exchange amount are not the only things that matter. What matters most is the transparency of the project's team with their customers and how they manage their requests and issues. Have you read the GhostSwap story? A member lost more than 12 ETH there. Read it, and you will understand what I am saying.

[LoyceV]

What if I'm exchanging ETH for XMR, because that's what I have and want, do I need to download an unrelated Bitcoin wallet to verify their signed message?

Good point, so using both types of LoG would be good.

FYI, BitList PGP verification runs entirely on your browser/device.

Still, I would consider anything that runs online a privacy risk.