Honesty
Many services promise to “respect your privacy” without ever saying what they write down. This page does the opposite: here is the complete list, field by field, of what our database holds about you, why each line exists, and how long it stays.
This page describes the actual state of the service, not an intention. It is written from the database schema, and it is updated when the schema changes. If a line seems unjustified to you, write to us: several columns have already been removed for that reason alone.
The full record
Each exists because the service does not work without it. None of them is there “just in case.”
| What we write | Why | For how long |
|---|---|---|
| Your email address | It is your only identifier. It receives the login link to your space, the confirmation of your payment and your configuration. Without it we can neither recognize you nor deliver to you. | As long as the account exists |
| Plan and expiry | COVE or NODECOVE, monthly, yearly, or over two years, with the end date. This determines whether your tunnel should stay open tomorrow morning. | As long as the account exists |
| Signup number and rank | Your place in the signup order. It determines which referral rate applies to you, three free months for the first thousand, one afterward. Without this number, we couldn't keep that promise. | As long as the account exists |
| Your referral code | And, if you came through someone's link, that person's identifier, to credit their months. It's a link between two accounts, not an identity. | As long as the account exists |
| If you open a referral link | A fingerprint of your address, computed with a secret kept outside the database, so the same visit isn't counted twenty times. It can't be turned back into the address. | 30 days |
| The language you chose | To write to you in this language. | As long as the account exists |
| Per device: the public key, the internal address, and the exit | A WireGuard tunnel works exactly like a directory: the server needs to know that public key K corresponds to internal address 10.x.y.z, otherwise it doesn't know where to send responses. It's not a log, it's the routing table. The tunnel doesn't work without it. | As long as the device is active |
| Per device: a readable label | “iPhone,” “Linux laptop.” You choose it or we guess it, solely so you can recognize your own devices in your account and revoke one. | As long as the device is active |
| A byte counter per device | Two numbers: what went up, what came down. They're used only for the 50 GB quota, and for nothing else. A volume doesn't say what you did: a hundred gigabytes of backup and a hundred gigabytes of video give the same figure. | Detail purged after 40 days · monthly total kept |
| Your payments | The amount, the plan, the payment status, the order number and the assigned city. That's all. No name, no address, no ID: we don't ask for them, so we don't have them. The payment goes straight to our own server, with no intermediary. | As long as the account exists |
| Your open browser sessions | A label like “Safari · macOS” and the time of last activity, so you can see where your account is being accessed from and close a session remotely. These are site sessions, not tunnels: closing one doesn't cut off any VPN. | Disappears from the list after 90 days of inactivity |
| A count of orders by country and by month | A line such as “Vietnam, September 2026, twelve”. It helps us decide where to open the next exit and which language to write in. The country is worked out at the moment of the order, then the address is discarded without ever being written down: this count designates nobody, and nothing ties it to your account. | Kept: it is a total, it no longer describes anyone |
A word about referral clicks
When someone opens a referral link, we need to avoid counting the same visitor twenty times if they reload the page twenty times. So we record a fingerprint of their address, computed with a secret kept outside the database. That detail makes the difference: a fingerprint computed without a secret can be reversed in seconds, there are only four billion possible addresses, and a computer can try them all. With a secret kept elsewhere, someone who obtained a copy of the database would get nothing from it.
This fingerprint only serves to rule out a duplicate, which stops making any sense after a few weeks: it is destroyed after thirty days by the same nightly purge that erases traffic measurement.
A word about the country an order comes from
We needed to know where our customers are: that is what decides the next city where we open an exit, and the next language we translate. The usual way to know it is to keep the connection address, which we refuse to do. So we took the other road.
When an order opens, your address is matched against a table of address ranges installed on our own machine: the free DB-IP Lite dataset. Out of it come two letters, “VN”, “BR”, “DE”. Those two letters increment a count for the current month, and the address disappears when the request ends: it is written nowhere.
What this implies, said plainly. Nobody else is queried: your address does not leave the machine, no third-party service sees it go by. The count is a total by country and by month, with no finer timestamp, with no link to your account, your payment or your tunnel; it cannot tell where a given person comes from, only where our customers come from. And if the table cannot place an address, which happens with a Tor relay or another VPN, the order is counted as unplaced, with no other consequence.
We measure how these public pages are read
This has to be said here, or this page would be lying. Since September 2026, the site's public pages, this one included, record one line per visit, for a single reason: to know where people drop off. We were selling a service that almost no one completed the order for, without knowing why. Guessing cost more than measuring.
This measurement touches neither your account nor your tunnel. It stops at the marketing pages. What's written amounts to one anonymous line: which sections were shown and for how many seconds, how far down the page was scrolled, whether the screen is a phone's or a computer's, the language reported by the browser, the domain of the site that sent you here, and how far you got in the ordering process.
What isn't there, and matters more: no tracker placed on your device, no visitor identifier, no connection address, not even as a fingerprint, no browser signature, no text you may have typed. Two visits from the same device remain two lines with nothing linking them. We cannot reconstruct an individual's path, and we don't want to: we're looking for the place that blocks people, not the person who gets blocked.
These lines are destroyed after seven days. Only counters per day and per section survive, of the kind “forty-eight visits viewed the pricing”, numbers that no longer describe anyone. And if your browser sends “Do Not Track” or refuses data resale, nothing is sent at all: no line is written for your visit.
The other half
This list matters more than the previous one. What isn't written can't leak, can't be sold, and can't be handed over.
· No connection address, neither raw nor transformed
We do not write down the address you connect from. Not raw, not “hashed for privacy.” That last phrase is often a sleight of hand anyway: an address fingerprint computed without an outside secret is trivially reversed. Our database no longer contains any column of that kind for connections. Only one thing is derived from your address when an order is placed: the country, added to a monthly counter, the address itself is never written, and this is explained above.
· No log of the sites you visit
No history of destinations, no list of domains, no timestamp of your requests. The name resolver that answers inside the tunnel is our own, installed on the exit itself: your requests don't go out to a DNS giant. It runs with request logging disabled and verbosity at zero, and it only accepts requests from inside the tunnel.
· No content
We keep nothing of what passes through the tunnel. No page, no message, no file, no fragment.
· No civil identity
No name, no postal address, no date of birth, no ID document, no phone number. We don't ask for them, so we don't have them. Payment is made in bitcoin: there's no card number or bank details to protect either, because they never reach us.
· No Bitcoin address, no balance, no extended public key
On NODECOVE, your wallet queries your own indexer. That indexer receives your addresses, that's its job, it has to look up their transactions, but we don't copy its queries into our database, and we don't touch it. We never ask you for your extended public key, and you shouldn't give it to anyone. To keep the key itself out of reach, we compare eight hardware wallets on what matters: what can be verified, and what the manufacturer has already let leak.
· No log on the exits themselves
This isn't an intention, it's the state of the machines, and it's verifiable. On every one of our exits, the system log is memory-only: the directory that would make it permanent doesn't exist, so a reboot leaves nothing behind. The second logging service is disabled and locked. The firewall has no rule that would log a packet's passage. An hourly job runs as a safety net and strips out any system-log line that mentions the tunnel. No traffic analysis, no packet inspection, no capture is installed. Last checked on September 10, 2026, exit by exit, and that day we found something, written further below.
· No browser fingerprint
We do not keep the full signature your browser sends on every visit. We derive a readable device label from it at the moment of connection, “Firefox · Windows”, and discard the rest without writing it down.
What bothers us
A privacy page that contains only good news is an advertisement. Here are the points where our position is less clean, and what we do about them.
We hold the private key of a tunnel only until you install it. The server builds your tunnel configuration, which means it knows the private key at that moment. Once the tunnel has been installed on your device, the server erases that key and keeps nothing but the public key it needs to let you through. What this honestly means: between the order and the installation, someone who obtained the database could impersonate that device to our server. After installation, there is nothing left to take. What it never allowed, at any moment: reading past traffic, or getting into your devices. The price of this choice is on you: we cannot send you a configuration again, because we no longer have it. If you lose the file, revoke the device in your account and install a new one, which takes a minute and does not count against your device allowance.
While you're connected, the machine sees your traffic pass through. That's what a tunnel is: your packets cross our server, otherwise there would be no exit. Our commitment is about what we write down, not about a physical impossibility. Anyone who claims otherwise is lying to you. This is also the whole point of your node: for Bitcoin operations, the only model that holds up is one where you don't have to trust us.
We do not control our hosting providers. Our servers are rented. The landlord sees the machine's total traffic volume and knows its address, like any provider. We choose hosting providers and jurisdictions accordingly, but we cannot promise you a third party's behavior. That's why our exits are spread across several unrelated companies: a failure or an order affecting one takes down its machines, not the others'. We won't go so far as to write that no authority can reach all of them at once, several of our exits still share a hosting provider, and a decision targeting it would reach them together. Replacing a lost exit takes us a few days, the time to rent a machine elsewhere and test it before opening it. We'd rather write this down than let you guess it.
The site's server keeps a two-hour log that carries your address. It doesn't concern the tunnels, only requests arriving at these web pages. It exists so a defense tool can recognize and ban a machine attacking the site, which is impossible without seeing where it comes from. It is wiped every hour and keeps only one generation: two hours of life at most, never a copy, never a backup. It's the only place in the setup where an address is written down, and we'd rather tell you than let you believe in a purity that doesn't exist.
Our emails go through a provider. The login link, the payment confirmation and the configuration are sent by a third-party delivery service, which therefore sees your email address and the content of the message. This is true of any email sending. If this bothers you, open your account with a dedicated address that reveals nothing about you: it is the only thing we ask of you, and it can be as anonymous as you like.
Legal requests
The honest question isn't “will you resist?” but “what do you have to give?”
We are a company, not a cause: upon valid request from a competent authority, we will comply with the law. What the file handed over would contain is therefore exactly the first list on this page: an email address, a plan, dates, payments, volumes in bytes. Nothing resembling a browsing history, because none exists.
That's the whole point of writing down little. A privacy policy protects you as long as the company stands and keeps its word. A database that doesn't hold the information also protects you the day the company changes hands, has its machines seized, or has its backups stolen.
A limit we cannot work around. A legal request can also ask not for what we have, but to start writing down what we don't write, for a named account and going forward. No provider on earth can promise you they'd escape that, and be wary of anyone who claims otherwise. Our only honest answer: we haven't built a tool to do it, and the day we were forced to build a permanent surveillance capability, we would shut the service down rather than keep selling this page.
NodeCove is not meant to get around a legal obligation. It's meant so that the privacy of your finances isn't, by default, everyone's business.

Removal log
We keep this log because a verifiable promise is worth more than an elegant one. Each line is a place where we used to keep something we shouldn't have kept.
| Date | What disappeared | Why |
|---|---|---|
| September 2026 | The address fingerprint of sessions | We used to write a fingerprint of your connection address combined with a device identifier. Since that identifier was stored on the same line, the fingerprint could be reversed in seconds: it wasn't anonymous. It was also never read back by our code. The computation was removed and the column destroyed. |
| September 2026 | Two address and browser columns, left empty | Our sessions table was designed to record the connection address and the full browser signature. They were never filled in, but their mere presence would one day invite someone to fill them in. We destroyed them rather than rely on discipline. |
| September 2026 | A column named “device fingerprint” | Planned at the very start of the project, never written by any code, never filled in. A field with this name in the customers table is exactly what we'd rightly be criticized for. Destroyed. |
| September 2026 | The detailed history of traffic readings | We used to record each device's counters at regular intervals, and nothing erased these readings. Strung together over years, they trace out your connection hours. The monthly total is enough for the quota: the detail is now automatically purged after 40 days. |
| September 10, 2026 | Packet logging left active on eight exits | While checking our own machines one by one, we discovered that a firewall rule, written to develop the bypass mode, was writing the tunnel's internal address and the destination of refused packets into the system log. It had stayed active on eight of ten exits, with a permanent log and no purge. We didn't find it because someone complained: we found it by looking. The rule was removed, the log switched back to memory-only, the second logging service locked, the existing traces destroyed, and an hourly purge installed on all ten machines. |
| September 10, 2026 | Address fingerprints of referral clicks, kept without limit | The fingerprint that rules out duplicates from a referral link used to stay in the database indefinitely, for lack of a planned expiry. It is now destroyed after thirty days, by the same nightly purge that erases traffic measurement. |
It's the only guarantee that survives a change of ownership, a seizure, or a leak.
See pricing