Trust

Security

Super intelligence audited, and built so ZeroFee's servers never hold your money or your keys. ZeroFee Swap and ZeroFee Pay connect you straight to the protocols, the parts in between are small and stateless, and every swap goes through the checks below.

Audit

Super intelligence audited: an AI review went through every place in ZeroFee's code that could hold, sign for or redirect funds.

Custody

ZeroFee's servers never hold your money or your keys. Privacy steps' temporary wallets are made in your browser, and their keys stay there.

Deposit addresses

Issued by the protocol itself, never by ZeroFee. Check each one on the protocol's own tracker.

Tracking

No analytics, no advertising scripts, no tracking cookies, no request logs.

In flight

Your coins sit with the protocol that carries the swap, under its own audits, listed below.

Architecture: what runs where#

The same picture in words:

• In your browser: the pricing code, the swap page that follows a swap while it runs, and, during privacy steps, the temporary wallets that carry your money between steps. There is no swap history and nothing to connect. You send the money yourself, from the wallet or exchange you already use.
• On ZeroFee’s servers: small stateless endpoints. The pass-throughs exist for practical reasons: provider keys (for NEAR Intents and the exchanges) must not ship to browsers, and some providers should see our server rather than your IP address. The developer API and MCP server (see Developers) only fetch prices, deposit addresses and status. There is no account system and no user database, and no server ever receives one of your keys.
• At third parties: everything that actually performs a swap or holds funds in flight: the protocols that issue the deposit address (NEAR Intents, Relay), Privacy Cash's pool, the two exchanges of the Monero step, and the blockchains. Your browser talks to some of them directly, so they see your IP address, as any website would.

Keys stay in your browser#

There is no account, password or sign-in, and nothing to connect. A standard swap makes no key at all: the protocol issues a one-time deposit address, you send to it from any wallet or exchange, and the protocol delivers to the address you gave.

• Temporary wallets for privacy steps. The ZK pool, or a mix of privacy steps, needs wallets to carry the money between steps. The swap page makes them in your browser. Their keys are encrypted with a key your browser keeps for this site and can't export, and they never reach ZeroFee's servers. Each wallet sends on everything it holds, so it is designed to end empty. The swap's page lists them under Where your money is, where you can see each key and download a recovery file.
• If a step fails. It is tried once more on a different route. If it still can't finish, the money goes back to your refund address automatically, so it does not sit in a temporary wallet.
• What this browser keeps. A swap only while it runs, so its page survives a reload: the coins and amounts, the addresses you entered, the deposit address, the status and, for privacy steps, the temporary wallets. It is forgotten once the swap finishes, and there is no History page. A swap that stopped keeps its details until you choose “Forget this swap”, 30 days at most. Plus a few preferences and a record that you accepted the terms.
• Keep this browser to yourself. There is no password on any of it, so anyone who can use this browser profile while a swap runs could read it and open a temporary wallet's key. Clearing site data erases it, and we can't restore it, so don't clear it while a private swap runs. A single-deposit swap keeps going on the protocol's side either way.

Non-custody, checked in the code#

Super intelligence audited: on 15 October 2026 an AI review went through ZeroFee's code for every place that could hold, sign for or redirect funds (see Testing and review). The privacy steps of 16 October came after it; how they handle keys is described above. What it checked:

• Every deposit address comes from the provider. NEAR Intents' 1Click API returns it with a live price, Relay returns it with its price, and the exchanges return it when the order is created. ZeroFee's servers never generate one. On a route with several steps, each later step's deposit address is set as the earlier step's payout address, provider to provider. (Since 16 October, a privacy step can also pay into a temporary wallet made in your browser.)
• No keys on the server. The server creates no keys and signs nothing. On 15 October nothing in the swap, pay-link or funding flows created a private key either. Since 16 October, the swap page's privacy steps create temporary wallets in your browser and sign their transfers there; the keys never leave it.
• A placeholder can never become your address. Before you type an address, prices are worked out with placeholder addresses. Each is derived from a published hash, so nobody holds its key (except two that providers require to be existing accounts), and every reservation refuses a placeholder as a recipient or refund address, in the app and in the API.
• No fee added. Requests to NEAR Intents and Relay carry no fee field, and no exchange affiliate code is set in production.
• Nothing stored. The server has no database and writes no request logs. The one thing it records is a problem report from a swap page (see Problem reports). It holds only provider keys (such as those for NEAR Intents and ChangeNOW), a secret that signs status links, and the details it needs to reach our support system.
• No tracking. No analytics, advertising scripts or tracking cookies.

Fixed during the review: three placeholder addresses (EVM, Solana and Bitcoin) had been ordinary wallets, and the reservation step relied on the page having replaced them. Both are closed: the placeholders are keyless and refused at reservation.

How the page itself is guarded. A compromised build or library could show a different address, so the page that shows it is protected by locked deploy access, exact package versions, framing protection (see Browser protections), and by you: the provider's own tracking page shows the same deposit address.

Who holds your funds: the providers and their audits#

While a swap fills, your coins are held by the provider that carries it, never by ZeroFee's servers. Their security is what protects the money in flight, so here is what each publishes, read from the sources linked on 15 October 2026 (ChangeNOW and Privacy Cash on 16 October). Each audit covers that provider's own systems.

Checks on every swap#

• The protocol issues the deposit address. It is one-time, for one swap, one coin and one chain, and it expires. Sending a different amount or coin, or sending after it expires, can delay or lose the funds. The swap’s page shows the exact amount, the network and any memo or tag.
• Prices expire. A price older than about 25 seconds is checked again before a deposit address is issued. If what arrives would now be below the minimum you accept, the swap stops before anything is reserved, instead of going ahead at a worse price.
• Slippage guard. Every route carries a minimum received derived from your slippage (0.5% by default). The protocol refunds rather than filling below it.
• Addresses are checked by their checksums where the chain has one. You give a receiving address and a refund address on the paying chain (without privacy steps, one address does both when the two chains use the same kind, and you can untick that; with privacy steps they must differ). Each is validated before a deposit address is requested: EIP-55 for EVM; base58check for Bitcoin, Litecoin, Dogecoin, TRON, XRP and Zcash transparent addresses; bech32 / bech32m for SegWit; the full ZIP-316 decoding for Zcash unified addresses (checked against the official Zcash test vectors); a Solana address must decode to a 32-byte key. So a mistyped address on those chains is refused here, not left to a route that might not check. Other chains are checked for shape here and in full by the protocol when it prices the swap. A swap that cannot complete is refunded by the protocol to the refund address.
• Every refund reaches an address you control. A route with a step in the middle (a conversion around the Monero step, or a two-step route through a middle chain) needs your own refund address on the chain where that step runs, and reserves nothing without it. A middle step never refunds to the recipient unless you confirm the receive address is yours and the step runs on the receiving chain.
• Temporary wallets are designed to end empty. Between privacy steps, a temporary wallet only pays routes whose fees are inside the price, and sends everything it holds, so it ends at zero. A step that fails is tried once more on a different route; if it still can't finish, the money goes back to your refund address automatically. On its own, the Monero step needs no wallet at all: the first exchange pays the second's deposit address directly, and neither exchange sees both ends.
• You see the cost before you start. Beside the button: what arrives, how long it takes, the total cost and what's in it. Nothing is reserved until you press it.
• Privacy steps are checked before you start. The page checks that each step's providers are answering. A step that isn't is paused, with the reason on its row, and no swap starts through it.
• If a swap stalls or fails, its page says “Slower than usual” or that something went wrong, tells our support team automatically (see Problem reports), and has a support button that opens @ZeroFeeSi_bot on Telegram with the swap attached. A stopped swap also shows “Try again” and “Send my money back”. The page links to the protocol's own tracker.
• A failed swap keeps its details. Its deposit address, order id and tracking links stay on its page in this browser for up to 30 days, until you choose “Forget this swap”, so support can find the money.

The server pass-throughs, precisely#

These are the server-side parts that sit between your browser and a provider. Each is a few dozen lines that forwards a request and returns the answer. The code writes no log and keeps no copy of what passes through. The only state is a per-address request counter held in memory for a minute at a time to enforce the rate limit.

/api/oneclick: confidential NEAR Intents swaps

Forwards three paths only (quote, deposit/submit, status), each with its one allowed HTTP method, to the NEAR Intents 1Click API, adding the partner key on the server. Rate limited per client IP address. Public NEAR Intents requests (a swap on one chain, or a pair NEAR can't take confidentially) go straight from your browser to 1Click instead; one that 1Click rate-limits is retried through this proxy once. A status check answers only the swap's status (waiting, done, refunded…): never its receiving or refund address, amounts or transactions, because a deposit address is public on-chain. The amount paid out and the payout transaction come back only with a proof the proxy issued with that confidential deposit, which only your swap page holds.

/api/exchange: the exchanges

Forwards price, create and status calls to the Exolix and ChangeNOW APIs. It passes on only known fields and never relays arbitrary client-supplied keys. Provider keys are applied on the server. Rate limit: 120 requests per minute per client IP address. The Monero step sends both exchanges’ requests through it, so this proxy sees both sides while the orders are made; it stores nothing. The Monero step uses Exolix and ChangeNOW only, whether it runs from the swap page, the REST API's xmr option or a pay link's private payment. FixedFloat is no longer used for any new swap or payment.

/api/rpc, /api/pool-relayer and /api/lwd: privacy steps

The temporary wallets of privacy steps use three more pass-throughs: /api/rpc (Solana network requests: balances and the wallets' own transactions, unless the site is set up with its own Solana provider), /api/pool-relayer (Privacy Cash's withdrawal service, so it never sees your IP address) and /api/lwd (a Zcash light-wallet server, for the Zcash step). They follow the same rules as above: an allow-list of what may pass, no logging and a per-address rate limit, with a tighter one (30 a minute) for the calls that send a signed transaction, and a Solana request batch counts as every call in it. They also let anyone holding a private run from before 14 October 2026 finish it. /api/keyed (0x, for wallet-signed routes) was removed on 16 October 2026: no route in the app needs your wallet to sign.

Problem reports

When a swap fails, runs much longer than usual, or is found interrupted, its page sends one short report to /api/report, so our support team knows at once. It holds the swap's id, its deposit address, the coins, chains and amounts, the step, the protocol, its tracking id and the error; for a step that is only slow, just which stage it is at, never the step's raw progress line. It has no field for a key, a seed or your receiving address, and the server refuses any extra field. The server writes it to its log as one line, which our support team watches, and forwards it to our support system. It is sent once per swap and step, and limited per IP address.

Limits every proxy enforces

• Body size caps. A request body is read only up to its cap and refused with 413 past it: 16 KB for /api/exchange, /api/oneclick and the public API, 64 KB for /api/rpc, 256 KB for /api/pool-relayer.
• A rate limit that can’t be dodged. The client address comes from X-Forwarded-For only behind Vercel’s edge, which sets it; anywhere else the header is ignored, so a client can’t mint a fresh allowance by sending a different value each time.
• Timeouts. Every NEAR Intents request gives up after 20 seconds with a plain error, so a stalled provider never leaves “Reserving deposit address…” spinning. Every other pass-through has its own deadline too: 20 seconds for the exchanges, 25 for Solana requests, 30 for the pool relayer.

Browser protections#

Every page and API response carries these headers:

• No framing. Content-Security-Policy: frame-ancestors 'none' and X-Frame-Options: DENY: no other site can show ZeroFee inside a frame, so no one can lay a fake overlay over a deposit address. The same policy pins base-uri, object-src and form-action.
• No referrer. Referrer-Policy: no-referrer: swap pages and pay links carry addresses in their URLs, so no URL is ever passed to another site when you follow a link.
• Narrow permissions. Permissions-Policy allows the camera to this site only (the QR scanner) and turns off microphone, location, payment, USB and ad-topic APIs; X-Content-Type-Options: nosniff; Strict-Transport-Security with preload; Cross-Origin-Opener-Policy: same-origin-allow-popups.

Content security policy: enforced. Content-Security-Policy is not just a framing rule: the browser only runs scripts and workers served from ZeroFee itself, never evaluates text as code (eval is off; WebAssembly is allowed for the Zcash wallet and the privacy pool prover), and loads images only over https. It opens no frames, plugins or foreign form targets, and only https connections (the chain RPCs and swap providers). The one allowance still open is inline scripts, which Next.js needs for its page bootstrap; closing it takes a fresh per-request key on every page, which would make every page slower to load. A stricter copy that lists each provider we call runs as Content-Security-Policy-Report-Only: it blocks nothing, but your browser reports (through Reporting-Endpoints) anything it would have refused, and so does a block by the real policy. From a report we log only the rule, the blocked site and the app section it happened on (such as /swap): never a link, a swap id, a wallet address or an IP. A test frames every main page from another site in a real browser on each release and requires each to be refused.

ZeroFee Pay: the same custody model#

Pay links and the API's exact-output payments (amountOut) do not change the custody model. ZeroFee never holds a payment, keeps no merchant accounts, stores no links or payment records and its own fee is 0%. A link is only a URL: everything in it (the receiving address, coin, amount, name and note) is visible to anyone who has it, and nothing about it is saved on a server.

• Payments run through Relay or NEAR Intents. Both are asked at once and the one that asks the payer for less carries the payment. The payer sends a deposit from any wallet or exchange to that provider, which delivers the exact amount to the merchant's address. While the order fills, the provider holds the funds, as for any crossing. A payer who chooses to pay privately goes through privacy steps instead (the Solana ZK pool, Zcash shielded, or the Monero step run by Exolix and ChangeNOW), and a private payment delivers at least the amount.
• The payer's refund address applies. If a payment cannot complete, or a deposit arrives after the price has moved past the payer's slippage, the route provider refunds the payer at their refund address, and on a NEAR Intents route the unused part of the small exact-output margin goes back to them too. ZeroFee cannot refund, reverse or redirect a payment.
• Merchants: confirm receipt on-chain. Treat a payment as received when it is at your address, not when a page says so. A link can be paid more than once, and a lookalike page could show a fake success screen.

Testing and review#

The Super intelligence audit above is backed by automated tests of the route logic, the fee maths and the public API (including a test that refuses every placeholder address), browser end-to-end checks of the swap screens on every release, and live test prices against the providers. ZeroFee's own part is narrow: it shows you the provider's deposit address, passes on the addresses you give, and runs the privacy steps' temporary wallets in your browser. The funds in flight are covered by each provider's own audits, listed above.

Responsible disclosure#

Found a vulnerability? We want to hear about it before anyone is harmed. Tell us privately through support on Telegram, and please keep exploit details off public channels until it is fixed.

What we will never do#

• Hold your keys on our servers, or have any way to move your funds from them. That includes payments made through a pay link.
• Ask for the private key, seed or secret words of any wallet, by message, email or support chat. Nobody from ZeroFee will, and ZeroFee support never needs them.
• Ask you to sign in, connect a wallet or approve anything in one.
• Add a hidden fee. Every cost is in the total shown before you start, and ZeroFee's own fee is 0%.
• Set tracking cookies or add analytics or advertising scripts. There are none.
• Claim a security review we have not had, or promise privacy we cannot back.

More: Privacy protocols · Terms of use · Privacy policy · Risk disclosure.