Kairos · working analysis · 9 September 2026 · updated 11 September
DHH did not find a faster installer. He refused the vendor's pipeline, measured the disk and transfer constraint underneath it, and found that most of the forty-two minutes was ceremony. This runs the same audit on residential-IP VPN: strip it to the parts that obey physics, then name every remaining cost that survives only because nobody questioned it.
A consumer VPN charges three visible costs: the wait before it connects, a latency tax while it runs, and losing what you were doing when it drops.
Physics accounts for none of the first, about a tenth of the second, and none of the third. One architectural decision collapses all three at once.
A caution on the whole page, added after the fact: the network runs near 0.4% of installed capacity. Nothing here is supply-constrained. Every gain below is a gain in the experience, and the binding constraint is demand.
Part one
Everything below is irreducible. No protocol, no funding round and no clever engineering moves any of them. Anything not on this list is negotiable, and the rest of this page is the negotiation.
Single-mode fibre carries light at 204,190 km/s. Real routes run about 1.5× the straight-line distance, so the working constant is 1.47 ms of round trip per 100 km as the crow flies.
Bangkok to a US East datacentre is 14,140 km. The floor is 208 ms. Nothing gets under it.
Routing through an exit cannot be shorter than going direct. But it can be equal. The penalty is pure geometry: how far the exit sits off the straight line between you and what you are reaching.
It goes to zero when the exit sits next to the destination. This one fact is worth more than any protocol choice on this page.
To forward a packet, the exit has to read the destination address. A one-hop VPN moves trust from your ISP to a stranger. It does not remove it.
Only splitting the two facts, who you are and where you are going, across independently operated hops changes the shape of that trust. Geometry charges for it.
Your download through a node is capped by that node's upload, minus whatever the household is already using. On cable that is often 20–50 Mbps against a gigabit downstream. On fibre it is symmetric.
Irreducible for one node. Not irreducible in aggregate.
But it is not currently binding. Payouts against installed capacity put the average node near 0.4–1% utilisation. Real physics, dormant constraint. See M3.
They sleep, reboot, roam and get switched off by their owner. Availability per node is structurally poor and cannot be engineered upward.
Availability across a pool can be engineered as high as you like. Every reliability question here is really a question about which of the two you designed for.
One abusive user burns an address for everyone who uses it afterwards. That is admission control, not code, and it is why credible residential supply is expensive.
Behind it sits the harder one. The addresses belong to people who have to agree, keep agreeing, and not be harmed by agreeing. Contractual, not technical.
Part two
A country is a legal category. Routing is a geometric one. When a customer picks "United States" and gets whichever US node is free, you have chosen a point on a continent at random and charged them for the detour.
| Traveller in Bangkok reaching a US service | Round trip | Penalty | vs direct |
|---|---|---|---|
| No VPN at all | 208 ms | — | — |
| Exit beside the destination (US East) | 208 ms | +0.0 ms | +0% |
| Exit in New York | 210 ms | +2.1 ms | +1% |
| Exit in London | 227 ms | +19.2 ms | +9% |
| Exit in Frankfurt | 228 ms | +20.2 ms | +10% |
| Exit in Los Angeles ("a US node") | 249 ms | +41.4 ms | +20% |
| Exit in Singapore ("one close to me") | 249 ms | +41.3 ms | +20% |
Note the two intuitive answers at the bottom. "Pick a node near the user" is wrong. "Pick any node in the right country" is wrong by the same amount. The correct rule is the one nobody exposes: pick the node nearest the thing being reached.
It opens five concurrent TCP connections to each region host on port 80, scores a failure as a flat 1,000 ms, and takes the smallest median. That is a measurement of distance from the user to a region, which the table above shows is the wrong variable. Source-documented in the client, not executed by us. The registry also reports that in Asia, 62.2% of nodes sit at least 2× the global minimum latency and at least 100 ms above it, median difference 139.8 ms — stored registry aggregates at one instant, not client round trips. The proposal's example customer is travelling in Thailand.
There is a second consequence that matters more than the speed. Because the client already knows its own destination, the ranking can be done on the customer's device against a published latency map. The network never has to learn where anyone is going. Better routing and better privacy are the same change here, not a trade between them.
Part three
Each is an accepted limit. For each: what the market assumes, what physics permits, why the gap exists, and the cheapest measurement that would prove me wrong. That last part is the important one. A claim with no falsifier is a sales pitch.
The connect path runs serially through DNS, TLS to a control API, an auth call, a node-list fetch, a payment check, a rendezvous through a broker, and only then the tunnel handshake. Every step except the last is cacheable, pre-authorisable or backgroundable. None is on the physical critical path.
The fix is not a faster handshake. It is never disconnecting: hold three to five tunnels permanently handshaken and let "connect" become a route change. A WireGuard keepalive costs about four bytes per second per tunnel. The whole warm pool costs less bandwidth than one web font.
98.9% of proposals are WireGuard, so the one-round-trip floor is available today with no protocol work. Every contact in a 10,397-proposal capture is nats/p2p/v1 carrying only broker addresses, so a broker rendezvous sits on the connect path by construction. Discovery also drops a node when the requested NAT compatibility is symmetric, which is supply lost to a problem a warm pool would already have solved.
Packet-capture the current client connecting. Count round trips, mark each avoidable or not. If fewer than four are avoidable, the mile is not there.
Covered above. The selection input the industry uses is a legal jurisdiction; the input that determines latency is a position. Different variables, and choosing the wrong one costs a fifth of the customer's speed on the most common long-haul case.
Closing it is not research. Nodes probe a set of landmark prefixes and publish a round-trip vector; the client scores candidates locally against its own destination. A few kilobytes and a dot product. Content networks have done this since the early 2000s.
Twenty destinations customers actually reach. Measure flag-selected against path-selected exits from real probes. If the median improvement is under about five percent, drop it.
True for one node, permanently (Atom 4). False for one session. An earlier draft called this the largest unclaimed opening here. The node economics say it is not, and it is revised down.
Video, the highest-value thing anyone does through a residential exit, is not one stream. It is a sequence of independent requests for numbered segments. Fetch segment N through one node, N+1 through a second, N+2 through a third. Three ordinary 40 Mbps home uplinks deliver 120 Mbps to one viewer. Download accelerators did this in 2003. Nobody has pointed it at a residential exit network.
On-chain payouts held flat near $54k/month across June to August 2026 while node identities went 21,598 → 30,212: about $1.79 per identity per month. A median residential uplink of 32.29 Mbps saturated around the clock would carry 10,462 GB, worth $418 at four cents a gigabyte. That is 0.43% utilisation, roughly 45 GB a month per node, a sustained 0.138 Mbps. Re-derived from those inputs, it holds; more usefully, it survives being wrong. Divide the node count by three and raise the price and utilisation still lands near one percent.
The two halves of that ratio are not equally sound, and it is worth knowing which is which. The numerator is the strong half: every settlement event decoded off the live payment contract on UTC month bounds, with the fee share landing at 21% against a documented 20% service fee, which checks the decode against something it does not control. The denominator is the weak half: the node count is an inference, not a census.
One thing could genuinely break it. Bulk deals settled off-chain would be invisible to that decode, so real revenue could be higher than the figure above. That axis had not been tested, so I tested it: the network would need $6.3 million a month, about 117× the decoded settlement, before capacity became the binding constraint. Off-chain business does not plausibly run two orders of magnitude above on-chain settlement at this size. The conclusion holds.
So striping across nodes to beat a per-node ceiling solves a problem the network does not currently have. It stays valid as a way to make one viewing good when the node you drew is poor, which the Asian latency spread says is common. It is not a capacity play, and it is not first.
The honest risk is that the service sees several source addresses against one session. Some tolerate it, because that is what a phone handing between towers looks like. Some will not. There is a real chance it reads as more natural rather than less: several residential addresses in one metro is what a household with several devices actually is.
Metering is per byte, taken as a high-water maximum per direction and per session. Striping one viewing across three nodes multiplies the number of sessions being metered, so the billing path has to be checked alongside the transport. That is an accounting question, not a physics one, and it is answerable before anything is built.
One afternoon. One player, three nodes, five services. Either the sessions hold or they break, and you will know which services do which. Still cheap, no longer first — M1 is.
ChaCha20-Poly1305 runs at roughly two gigabytes per second per core on any current processor, and hardware-accelerated AES runs faster. A gigabit uplink, far above anything a real node offers, consumes six percent of one core.
Any control in the product that trades protection for speed honours a constraint that expired when AES instructions shipped in consumer silicon. It should be deleted, not tuned. There is no dial.
This is the invisible-recovery experience the proposal describes, and it is not a separate feature. It is the warm pool from M1 seen from another angle. The default keepalive of 25 seconds is what makes reconnection visible; you own that number, and it can be 200 milliseconds for the price of half a kilobyte per second.
The real constraint is not the tunnel. It is that the exit address changes. Segmented video, ordinary browsing and downloads survive that without noticing. A single long-lived connection, a shell session or an open socket, cannot, if the machine holding it has gone.
So the truthful promise is narrower than "nothing ever breaks" and still remarkable: streaming, browsing and downloads never notice; a live terminal session might. Stated that precisely, the promise survives being tested.
The client tears the existing tunnel down before fetching a replacement configuration. A failed configuration request leaves it disconnected with no restore of the old one. Source, plus a mocked test. Separately, the iOS and macOS OpenVPN extension calls reconnect(afterTimeInterval: 5) on regaining WiFi — a fixed five-second wait against a floor near zero. Invisible recovery is not a missing polish item. It is an inverted order of operations, and inverting it is the same change as M1.
The strongest privacy property available, that no single machine knows both who you are and where you are going, costs about a tenth of your latency when the hops sit on the path. The industry sells it as a slow premium tier because it places hops by country: the same error as M2, compounded twice.
A property most customers assume is a luxury is available for ten percent. That is a positioning fact as much as an engineering one.
The address is one signal out of roughly seven. The others are the shape of the TCP stack (time-to-live, segment size, window scaling, the order of options), the TLS handshake fingerprint, the HTTP/2 settings fingerprint, timing coherence, resolver behaviour, and simple consistency across the whole picture.
A residential address wearing a datacentre TLS fingerprint is more anomalous than a clean datacentre address, because that combination does not occur in nature. And detection vendors increasingly score the behaviour on an address rather than the address itself: many unrelated destinations at once from one home line reads as a proxy whatever network it sits in.
The unclaimed ground is coherence. Nobody ships a consistent identity across all seven layers. For a VPN this is far easier than for a scraping proxy, because the customer genuinely is a real browser on a real operating system. You do not have to manufacture authenticity. You only have to avoid destroying it in transit.
The residential label in the registry is copied from a location oracle's node type, matched on literal residential and cellular strings, with a manual override path. 68 proposals labelled residential name a network whose own site sells hosting. And the discovery endpoint applies a per-country cap near 1,000 with unordered map iteration, so observed inclusion for the US ran at 6.3%. Any "we have N residential nodes in country X" figure taken from that endpoint is a count of returned rows, not of nodes.
The best public measurement of who actually blocks datacentre traffic is from 2016, and it measured Tor rather than proxies: about 3.67% of the top thousand sites. Nothing comparable has been published since. So the blocking-and-challenge tax that every residential-address product prices against has no current public number anywhere in the industry. From a Kairos literature scan; citation not yet verified. Kairos's own screening matrix on 10 September found residential refused identically on the two destinations that refused every datacentre exit, and residential transport failures on four of twelve requests. That is consistent with the address alone not carrying a person's identity. Curl with a browser user-agent is still no browser, so it is no evidence for the fingerprint argument.
That reframes the test below. The question is no longer whether Mysterium gets blocked. No calibrated, browser-grade number for the tax exists yet, so measuring it well is worth more than another feature. Run the control first: prove the instrument can detect a refusal at all, then measure the gap between a datacentre route and a residential one. An uncalibrated run that finds nothing is not a finding.
Run the current client past a fingerprint-inspection endpoint and see whether the exit address and the stack above it tell the same story. If they already agree, this mile is closed.
M2 and M3 push toward an exit that terminates and re-originates traffic: split the connection, run modern congestion control on each leg, stripe across nodes. M7 pushes the opposite way, toward forwarding packets untouched so the customer's own fingerprint survives.
You cannot have both on the same connection. Any product claiming both is not being examined closely.
The resolution is per-connection policy rather than a global mode. Accelerate the traffic nobody inspects, which is video segments, downloads and updates. Forward untouched the traffic that gets scrutinised, which is the first request to a login page or a checkout. I know of no product that makes this distinction, and it is harder to copy than an interface.
Two counter-intuitive points. First: a single connection over a long lossy path is capped by round-trip time and loss, not by bandwidth. At 250 ms and half a percent loss it tops out under a megabit no matter how much capacity exists at either end. Break the path into two shorter control loops and the ceiling roughly doubles per leg while loss stops propagating across the whole distance. On long-haul, a well-built tunnel can be faster than no tunnel. Large infrastructure companies sell this. Nobody sells it on a residential network.
Second: a residential exit inside the customer's own access network can be closer in routing terms than a datacentre reached across an exchange. For the ordinary "give me an address in my own country" case, residential is not the slow option.
Part four
A page that only lists opportunities is a sales document. These are the five walls, and the last one decides whether any of this becomes a business.
That leads to the conclusion that matters most here. If there is a durable advantage in a residential node network, it is on the consent axis, not the speed axis.
Speed advantages are engineering, and engineering is copyable. A supply of addresses whose owners opted in knowingly and are paid for it is a position a competitor cannot buy into in a quarter. The physics in Part three tells you what to build. The consent structure tells you what you already have.
Part five
| Claim class | Basis | Status |
|---|---|---|
| Distances, round-trip floors, triangle penalties, keepalive and cipher budgets, the throughput ceiling | Computed here from published constants: refractive index of silica, a 1.5× route factor, the standard throughput relation | Arithmetic. Re-runnable; the script sits beside this page as floors.py. |
| One-round-trip handshake, cipher rates, segment-level video retry, the fingerprint layers | Established protocol behaviour | High confidence, independently checkable |
| Mysterium's region selection, the reconnect teardown order, the five-second extension wait, broker-only contacts, the residential label's provenance, the discovery cap | Read out of Mysterium's own source and registry captures during the freestyle investigationSource-documented or measured; none of it is a live client measurement. | Source-read; verify each against a running client before relying on it |
| "The industry ships 2–8 second connects", "nobody selects exits by measured path", "nobody stripes segments across nodes" | My characterisation of the wider market | Weakest layer. Unverified. |
| Node economics: the 0.43% utilisation figure and its consequences for M3 | Kairos on-chain settlement decode; re-derived and stress-testedNumerator decoded from on-chain settlement with an independent fee-share check. Denominator is an inference, not a census. Survives every sensitivity corner tried, including a 117× numerator. | Direction reliable, decimal not |
| Measured latency, throughput or loss through a Mysterium exit; exit-class access; the current industry blocking rate | Mostly absent | One ~50 ms relay detour was measured on one node, one session, in August; no systematic latency, throughput or loss measurement through Mysterium exits exists. Exit-class access was screened on 10 September: twelve destinations through Mysterium residential, Mysterium datacentre and a competitor's datacentre, with curl, two repeats and no guard. Nine ignored exit class, two refused every exit including residential, one separated Mysterium's datacentre ranges from the competitor's. A red team withdrew the causal readings; only the recorded contrasts stand. The last public blocking measurement is from 2016 and measured Tor. |
This is a confident prescription built from first principles and arithmetic, and confident prescriptions are exactly the thing that feels like insight while being unmeasured. The registry and source findings sharpen it, but they are still not a measurement of a working tunnel. Every one of the nine miles carries a cheap falsifier for that reason. Run two or three of them and the argument stops being a good argument and becomes a finding.
The 1.5× route factor is a working assumption; real fibre paths run roughly 1.4 to 1.6 times great-circle distance and specific routes vary. The relative comparisons in Part two are insensitive to that choice. The absolute floors are not.