Here is my review of the zeto.cash platform
Maybe I will start from the end, but first I will summarise the complete user experience.
I really have no objection to the interface itself. Everything is quite clear and logical, even someone who does not have much experience will not have any difficulties when using zeto.cash. Mostly, everything is sufficiently explained, and it is clear at all times which part of the swap process I am in and which next steps are necessary for the further process
The only moment where I may not have managed to capture everything was the moment after confirmation and before the refund kit was generated. Everything flashed for a moment, maybe I lost a little time because I was taking screenshots. I certainly didn't follow that detail very well.
So I can freely summarise, the design and functionality are at a fairly good level.
Now, to deal with other things and potential shortcomings, I believe it is more useful for the Zeto team.
First, regarding the wallet application. An eight-character password as a minimum is really not enough today. I believe that a minimum of 12 characters or a passphrase is recommended, with a mandatory built-in password-strength estimator as a must.
Also, the wallet does not have too many options, so it would be recommended to integrate support for another major wallet or even a hardware wallet.
Claim:
Swaps are funded and signed in this browser — nobody else ever holds your Bitcoin.
The entire swap protocol is executed server-side on the api.zeto.cash backend, not in the browser. Therefore, the above claim could be considered incorrect.
The browser is actually a "remote signer": a server via WebSocket (wss://api.zeto.cash/.../events), so 'trustless' or 'serverless execution' It can't be true. This is not a criticism of the way it works, but of how it is presented.
What I find in the browser log:
The browser sends information to a third party, i.e. blockstream.info, every 1-2 minutes.
Blockstream receives: the user's IP address, all derived wallet addresses, time and frequency of checks, the platform that collects them (Origin)
https://zeto.cash, browser and platform metadata.
Each call goes to a different, unique BTC address, which means that the wallet internally rotates the addresses when checking the balance. However, all these calls, to all these different addresses, are sent by the same browser from the same IP address in the same session, Blockstream (or anyone who intercepts/logs on their side) can trivially connect all these addresses as belonging to the same user
For a service aimed at BTC/XMR and privacy users, this is a serious drawback. No-KYC does not solve the problem of network and blockchain correlation.
"request": {
"method": "GET",
"url": "https://blockstream.info/api/address/bc1qqx0y4y2nlvn3l4ck5ppw0uhr0ltjnd07653ugr",
"httpVersion": "HTTP/1.1",
"headers": [
{
"name": "Accept",
"value": "*/*"
},
{
"name": "Accept-Encoding",
"value": "gzip, deflate, br, zstd"
},
{
"name": "Accept-Language",
"value": "en-US,en;q=0.9"
},
{
"name": "Connection",
"value": "keep-alive"
},
{
"name": "Host",
"value": "blockstream.info"
},
{
"name": "Origin",
"value": "https://zeto.cash"
},
{
"name": "Sec-Fetch-Dest",
"value": "empty"
},
{
"name": "Sec-Fetch-Mode",
"value": "cors"
},
{
"name": "Sec-Fetch-Site",
"value": "cross-site"
},
{
"name": "User-Agent",
"value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36"
},
{
"name": "sec-ch-ua",
"value": "\"Not=A?Brand\";v=\"99\", \"Google Chrome\";v=\"151\", \"Chromium\";v=\"151\""
},
{
"name": "sec-ch-ua-mobile",
"value": "?0"
},
{
"name": "sec-ch-ua-platform",
"value": "\"Windows\""Correct me if I'm wrong here.
The REST API authenticates requests exclusively through the sessionId, which is embedded directly in the URL path (/s/<sessionId>/...), without any additional credentials (no authorisation header, no cookie, no request signature).
If someone malicious gets into the possession of the path, they will not be able to sign the transactions, but they will be able to monitor them, spam, suspend the session, download the refund kit...
It seems to me that this could be an oversight. I would definitely look for a solution for this.
"request": {
"method": "GET",
"url": "wss://api.zeto.cash/s/19735176e2eccd16/events?token=2b87b8f00e01a67b3a3334ce6406e392",
"httpVersion": "HTTP/1.1",
"headers": [
{
....As for the result of the order itself, it corresponds closely, 100%, to the conditions mentioned everywhere.
However, the final result is somewhat different
(The third picture is the offer at that moment on the third service.)
,
,
How everything looks in numbers:
(Kraken price at the time of the swap):
Kraken XMRXBT pair: price ~0.006607-0.006644 BTC for 1 XMR (bid/ask/last)
Fair value for 0.00043907 BTC at Kraken rate: ~ 0.0663-0.0665 XMR
What I actually got:
Gross amount given by the maker: xmr_receive_amount = 0.055669595933 XMR
Net to my wallet (after 0.7% zeto coordinator fee): 0.993 × 0.055669595933 = 0.055280685 XMR - exactly matches what I expect to receive
Finally, I got 0.055152645881 XMR
Total effective spread: ~16.6-17%, broken down into:
~16.0% = maker's margin built into the exchange rate, offered by the maker (quote), which is not shown anywhere as a "fee", it is the pure difference between the Kraken market price and the price at which the maker agreed to perform the swap.
~0.7% = declared "Zeto coordinator fee"
~0.23% = additional, unexplained loss (probably Monero network fee, but not shown to the user in advance)
The declared 0.7% is exactly as much as it says, but it represents only a small part of the real cost. Over 95% of the total spread (16.3 out of a total of 17%) comes from the maker's margin built into the rate itself, not from Zeto's fee.
I believe that 16% is too high a fee rate
note: I would reserve the right to supplement this review if I recognise something else that I think is important.
edit: my new feedback on welivecrypto is on pending.
