From a first look the exchange looks a bit simplistic. But I have not tried it because it seems like an unregistered centralized and custodial exchange to me.
So how does this work? A server functions as the exchange engine? Is it not still rated as an unregistered centralized exchange? Can transactions be re-routed? Frozen? Onion servers get taken down easily and an exchange could get DDOSed out of existance.
The entire anonymous and custodial aspect is a red flag. I am guessing that is why you are doing the escrow PR. But there is no guarantee that a large enough amount could not get rugpulled. How do you ensure that user funds do not get stolen/hacked?
What exactly does that mean? Are you talking about transactions? Give an example.
No information on refunds, no information on jurisdiction, no information on what data is collected.
Thanks for the questions — they are fair questions, especially for a new exchange thread.
To answer the general point first: yes, this is a centralized exchange service, not a decentralized protocol. We do not present it as a DEX. The exchange engine runs on our side, and the purpose of the service is to provide simple privacy-focused swaps without KYC/AML friction. At the same time, we understand very well that this model requires trust, which is exactly why we started adding public trust signals such as the escrow deposit. As already mentioned in the thread, $5,000 has already been deposited with Little Mouse escrow.
Regarding security and custody: user funds are not meant to sit on the service as balances or accounts. A swap request is created, processed, and completed within that request flow. We are not operating a wallet-balance platform where users keep long-term deposits on the site. That does not remove trust requirements, of course, but it does reduce the exposure model compared with a classic custodial account-based exchange.
We also pay special attention to security architecture. The public website and the server environment where exchange operations and fund storage are handled are separated and do not run on the same server. This separation is intentional and is part of our effort to reduce risk and add an extra layer of protection. In general, infrastructure protection and operational security are areas we take very seriously.
As for the question about freezing, rerouting, or rejecting transactions: we do not collect personal identity information, and we do not perform KYC or AML checks. The phrase in our Terms, "Suspicious or invalid requests may be rejected," was poorly worded and I agree it can be misunderstood. What it was intended to refer to was not a normal paid order or a successful deposit, but abnormal or malformed request creation attempts — for example, clearly invalid request parameters, broken input, or non-standard request patterns that look like probing, abuse, or an attempt to attack the service during the order creation stage. It was not meant as a vague excuse to reject a legitimate user’s already created and paid exchange. Because that wording can mislead users, we are going to remove or rewrite that point in the Terms so it is clearer. Thanks for pointing that out.
On data collection: we do not collect KYC data or personal identity documents. In practice, the data we currently keep is limited to normal technical cookies and the exchange request data that is created as part of the order flow and stored in the database so the swap can function correctly. We agree this should be stated more explicitly, and we will add that clarification to the Terms / rules as well.
There is no section on refunds, as we do not carry out AML checks and every request is processed.
So in short:
- yes, this is a centralized privacy-focused exchange service;
- no, we do not collect KYC data;
- the website and the exchange/funds infrastructure are separated for additional protection;
- security is something we take very seriously;
- the "Suspicious or invalid requests" line referred to malformed / abusive request creation attempts, not normal paid swaps;
- we will revise that wording now so it does not create confusion;
- and we will also expand the Terms to clarify data collection and other operational points.
Thanks again for the feedback — this is exactly the kind of thing that helps us improve the service and present it more clearly.