Zeto 🔄 Non-custodial BTC → XMR | Trustless atomic swaps - No custodian - No KYC

[Zeto Cash]

Zeto 🔗 [Swap] | [Create Wallet] | [Market] | [How-it-works] | 🛡️ $21,000 Guarantee

Pyccкий | Italiano | Naija | বাংলা | Português | Filipino | Turkish | Español | Bahasa Indonesia

[AB de Royse777]

Zeto 🔗 [Swap] | [Create Wallet] | [Market] | [How-it-works] | 🛡️ $21,000 Guarantee

Bitcoin to Monero Atomic Swaps  Built on eigenwallet protocol.

  NO CUSTODIAN, NO KYC, NO ACCOUNT.  ZETO is a web interface for BTC → XMR atomic swaps, built on the swap protocol of eigenwallet (formerly UnstoppableSwap). You trade peer-to-peer with a liquidity maker - at every point of the protocol, either the swap completes or you can recover your bitcoin.

Quote — you ask a maker for a price over libp2p.
Setup — both sides generate key shares and pre-sign the Bitcoin cancel, refund and punish transactions, before anything moves.
BTC lock — your bitcoin goes into a 2-of-2 output.
XMR lock — the maker locks monero to an address derived from both key shares, and sends you the transfer proof.
Redeem — you hand over an encrypted signature. The maker redeeming your BTC reveals their Monero key share, which sweeps the locked XMR to you.
Safety — if anything stalls, timelocks let you cancel and refund the BTC.
Setup is what makes the rest safe: adaptor signatures on secp256k1, tied to the ed25519 Monero key shares by a cross-group DLEQ proof.

 BROWSER ARCHITECTURE
The protocol needs a Bitcoin wallet, a Monero wallet and a libp2p node. Your browser runs the interface and drives a daemon (zetod) embedding the audited eigenwallet Rust crates. A daemon is required — ZETO performs real swaps, so there is no simulated mode to mistake for one.

Makers come from libp2p rendezvous through that daemon, so you see the same book as the desktop app — including  TOR  makers a browser could never reach on its own.

 YOUR KEYS NEVER LEAVE YOUR BROWSER
Your Bitcoin wallet lives only in this browser, encrypted with your password. The lock transaction is built and signed locally — the daemon receives the signed result and never your keys.

Two checks make that safe against the daemon itself, which is shared infrastructure. Your browser signs only the exact transaction it just built, and it verifies the change address is the one you gave when starting the swap — the protocol reuses that address as the destination of every refund path. If either differs, nothing is signed.

 IF ZETO DISAPPEARS MID-SWAP
Atomic swaps run on timelocks, so a coordinator vanishing at the wrong moment would be a real problem. At every stage you can download what you need to finish without us — a plain text file, broadcastable from any node, from a phone.

Bitcoin refund kit. From the lock until the maker redeems, you can save two already signed transactions — a cancel and a refund — that return your coins to your own address, with no cooperation from anyone. The cancel becomes broadcastable 24 blocks after the lock confirms, and you have 144 more before the maker may claim the coins. Every output pays you, so the file is worthless to whoever steals it.

Monero redeem kit. Once the maker has redeemed the Bitcoin, ZETO publishes the Monero transaction that pays you and keeps retrying until it confirms — you normally do nothing. You can still save it and publish it on any Monero node yourself; its outputs are fixed at signing time.

 FEES
ZETO charges a 0.7% coordinator fee for infrastructure. It is not a custody fee: it is one output of the final Monero redeem transaction — the protocol-native receive pool eigenwallet uses for its own developer tip. Network fees and the maker's spread go to miners and makers, not to ZETO.

Don't want to pay it? Use the eigenwallet desktop app directly: same protocol, same makers, zero coordinator fee. ZETO exists for those who prefer a browser.

Questions, or a swap that needs a hand? zeto.cash@proton.me
Clearnet: https://zeto.cash
Terms: https://zeto.cash/terms

[Original Topic] Zeto 🔄 Non-custodial BTC → XMR | Trustless atomic swaps - No custodian - No KYC

[hugeblack]

+15 Merit, good job, The last time I saw Adaptor signatures was with ---> https://basicswapdex.com/protocol.html. https://zeto.cash/ implements them much easier.

Why do I need to enter the “Unlock wallet” password every time I update https://zeto.cash/wallet page + The site accepts any password even if it is not in English.
What will the $21,000 guarantee be used for?

I have already created a wallet. I will deposit an amount and try how it works soon.

[logfiles]

Nice one!

When we talk about a noncustodial swap, this is what I want to see!

May add the terms of service link right before one creates the wallet or makes the swap  

Also, a FAQ page would be awesome. I will have more to say once I am a swap through the platform.

[hugeblack]

May add the terms of service link right before one creates the wallet or makes the swap  
Also, a FAQ page would be awesome. I will have more to say once I am a swap through the platform.

Both pages are available: the FAQ page is located at  ---> https://zeto.cash/how-it-works and the Terms of Use are at the bottom of the website ---> https://zeto.cash/terms (I'm just surprised there's no button to agree to them before starting any trading).

[Cinexa]

I checked Zeto.cash (BTC -> XMR atomic swaps in the browser, eigenwallet under the hood). Poked at the live site and the JS they ship. Not an audit, didn't run a real swap with money. Just what you can see from the outside.

Stuff that bothered me:

- "Keys never leave the browser" is only half the story. Signing keys stay client-side, fine. But if you use the hosted daemon (which is the default), that machine sees your XMR receive address, BTC refund/change address, which maker you picked, approvals, wallet balance hints, etc. Not the same as running asb/swap locally. If you care about that, force a local daemon and don't let it auto-connect to theirs.

- No CSP, no HSTS, no X-Frame-Options / frame-ancestors, no nosniff. For a page that keeps an encrypted seed + session tokens in localStorage, that's sloppy. One XSS and you're done.

- When you start a swap the client sends the expected receive pool (your addr 99.3% + their fee addr 0.7%). The approval UI then just displays whatever monero_receive_pool the daemon sends back. I didn't see a hard client-side assert that it still matches the hardcoded fee address before you hit accept. If the daemon is evil or pwned, don't blindly trust that screen - check the actual addresses.

- They say the Rust crates are audited / from eigenwallet. Cool. The thing signing PSBTs in your browser is a fat minified blob with no public repo that I could find. Trust model is "trust this website's JS". Filename is content-hashed which is better than nothing, still not source.

- Daemon token on the websocket URL. events?token=... Tokens in query strings end up in proxy logs, CF logs, random extensions. Put it in a header like a normal person.

- Keystore KDF is on the light side. scrypt N=2^15, r=8, p=1. Password gate is length >= 8. If someone yoinks the .json from disk/localStorage, that's not a lot of work by 2026 standards. Bump N or use argon2id, and don't allow "password1".

- Session PoW is ~18 bits of SHA256. Seconds on a laptop. They 429 you without the header, which is something, but 18 bits won't stop anyone who wants to burn sessions. /health also happily tells you how many sessions are live.

- Cloudflare beacon on every page. Browser hits Kraken + CoinGecko for XMRBTC and mempool.space / blockstream for fees and broadcast. Your IP, their edge, your UTXO activity - you do the math. At least make analytics opt-in and let people set their own electrum/explorer.

- Manual "Daemon URL" field. Placeholder is 127.0.0.1:9976 but it will talk to whatever you paste. Classic phishing angle: fake daemon, convince you to unlock wallet and approve a lock. Warn hard if the URL isn't localhost / their known host.

- Number(x) || 0 on approval amounts. Garbage from the daemon becomes zero in the UI. Also expiration_ts uses || so a falsy/0 value becomes "now + 180 seconds". Don't use || for numeric fields, use nullish checks.

- Wallet state uploaded to the daemon. balance, max giveable, next receive address. Needed for their architecture maybe, still a data leak on the hosted path.

- When I looked, a bunch of makers had maxSwapAmount=0 or version < 4.13.0 (client filters those). Clearnet TCP multiaddrs still show up. Prefer onion/wss if you're swapping for privacy reasons. Also discovery can fall back to api.unstoppableswap.net - third party in the loop.

- Suspend path can clear local state even if the daemon didn't ack ("clearing locally anyway"). History is localStorage only - wipe the profile and the in-app history is gone. Download the refund/redeem kits. Seriously.

- Some of the hostnames look like shitposts. You're trusting whoever runs those for lock checks if the UI uses them. Run your own daemon/node if you can.

What I liked

- They do check change address against what you started with before building
- They refuse lock amount above your approved budget
- Refund kit hex gets some local sanity checks before you broadcast
- CORS on the API is locked to https://zeto.cash (not *)
- Asset filenames are hashed; CF insights script has SRI

Bottom line:
Interesting project, better than another custodial "instant exchange". I would not put serious coin through the hosted path until the frontend is public, CSP/HSTS are on, and the approval screen cryptographically checks the fee outputs. If you use it, local zetod + download kits + verify every address on the lock screen yourself.

Again: read-only look at the shipped JS and public API. No funded swap from me. DYOR.
NB: I have used my AI assistant tool to decorate this post. 

[Zeto Cash]

Thanks all three. This thread has been more useful than anything else we've had so far, so I'm answering everything, including the parts that are still wrong.

@hugeblack

Password on every reload: the decrypted seed only ever lives in a JS variable. Nothing derived from your password touches localStorage, sessionStorage or a cookie, so a reload has nothing left to restore from and asking you again is all it can do. Staying unlocked would mean parking the key somewhere injected script can read it. We'll put that reason on the unlock screen, since right now the page doesn't say it.

Non-English passwords: that one is deliberate. Passwords are treated as Unicode and NFKD-normalised before the KDF runs, so the same passphrase unlocks whether you typed it on a phone IME or a desktop keyboard. Restricting to ASCII would push most of the world onto weaker passwords for nothing. What you should be suspicious of is the strength rule: 8 characters and no other check. That's too weak and it's changing.

The guarantee: 0.33 BTC sits in escrow with Royse777, not with us. Signed message and claim terms are in his escrow post. Worth being precise about what it's for, though. A failed swap refunds itself on the timelock and needs no fund behind it. The escrow covers the part where we could actually be at fault (the coordinator fee, the hosted daemon, a bug in our own frontend), judged by someone who isn't us and paid from coins we can't touch.

@logfiles / @hugeblack, terms before the swap

Shipped. There's now a consent checkbox on the swap form itself, right above the start button: no custodian, failed swaps refund after ~4h, the refund kit is yours to save. It's versioned, so you tick it once and only get asked again when the terms actually change. FAQ is at /how-it-works.

@Cinexa

Accurate post. Splitting it honestly.

Fixed and live now:

• CSP, HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy, COOP. Check it yourself with curl -sI https://zeto.cash/
• The receive pool is asserted client-side before approve. Your address has to be present, the shares have to sum to 100%, and your share has to be at least 99.3% minus rounding. Fail any of those and the button is disabled with the reason on screen. It's checked against the browser's own copy of the address you typed, never the daemon's echo of it
• Cloudflare beacon is gone. One script on the page now, same-origin, content-hashed
• Unusable makers (no liquidity, dust cap, old protocol) are out of every headline figure, not just the picker

Correct and still open. No dates, we'd rather post them fixed:

• Token in the WebSocket query string. Moving it to a header
• scrypt N and the 8-char minimum, both going up. This is the one that bothers us most
• Number(x) || 0 and expiration_ts ||. Nullish checks, and unparseable becomes an error instead of a zero
• No warning when the manual daemon URL is neither localhost nor us
• 18-bit PoW, and /health handing out the session count

The frontend being a minified blob with no repo is the point that undercuts every other answer here, and you were right to lead with it. It's going public soon. After that, none of the above has to be taken on our word.

By design, and worth saying plainly. "Keys never leave the browser" is about keys and signatures and it's true in that narrow sense: the lock tx is built and signed client-side, against a change address the browser verifies, capped at a budget it enforces. It is not a claim about metadata. The hosted daemon does see your receive address, refund address, maker choice and balance hints.

One correction to your post while I'm here. Pointing the client at your own zetod isn't a working path today. The field is there, the setup around it isn't. So that metadata is unavoidable if you use zeto at all right now. That's a limitation and we're not going to dress it up as a choice you have.

Same story with the wallet snapshot. The engine needs it to size the swap. What keeps it from being dangerous is that the browser refuses any PSBT whose change address or amount it didn't approve.

History is localStorage only because there's no account to put it in, which is exactly why the refund kits exist and why the terms now say saving them is on you.

We haven't been audited. Your post is currently the most rigorous external look this project has had, which tells you how much external review there is. So keep the two habits from the bottom of it that still apply: download the kits, and read the addresses on the lock screen yourself. The screen checks them for you now, but checking too costs you ten seconds, and not having to take anyone's word for anything is the whole point of an atomic swap.

[Cinexa]

Thanks for the reply.
I was interested in joining the review Campaign. But my forum ranks won't let me apply for the review campaign.
I would have focused on the Tech side, especially during the review campaign, if possible.

Rechecked against the live site.

Fixed side checks out. Headers are there (CSP, HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy, COOP). Cloudflare beacon is gone; one same-origin hashed script. Lock screen now refuses approve when the receive pool fails the checks you described — address has to match what the browser already has, shares have to sum, your cut has to clear ~99.3% minus the rounding slack. Unusable makers are out of the headline figures (still show up greyed in the list, which is fine).

One small leftover on the pool assert, not a disagreement with what you wrote: it enforces your share and the sum, it does not pin the leftover 0.7% to the hardcoded fee address. So a bad daemon cannot quietly cut your Monero below the advertised cut anymore, but it could still point the fee slice somewhere else without tripping that check. Worth tightening when you touch that path again.

Appreciate the straight answers on the design points. Especially the correction that pointing at your own zetod is not a working path today, that means the metadata exposure (receive/refund/maker/balance hints to the hosted daemon) is not optional if you use zeto at all right now. Same with the wallet snapshot: need it to size the swap, browser still has to refuse a PSBT it didn't approve. History in localStorage + refund kits is coherent once there's no account.