How often does it wrongly block a real customer?
legitimate addresses were wrongly flagged. The corpus is ten residential, mobile, university and public-resolver addresses — Comcast, BT, Deutsche Telekom, Airtel, Tata, MIT, Duke, Quad9, OpenDNS, Cisco — none of them marked as VPN, proxy or Tor.
Across all 6 bands, 53 of 53 cases scored through the live API agree with an independent reference. Zero disagreements, measured 2026-08-17.
That is a small corpus and it is quoted as a fraction for that reason. It is not “100% accurate” — a sample this size cannot carry that claim, and anyone who tells you otherwise is selling. What it does show is that on every case we publish, we do not disagree with the Tor Project, Kickbox, libphonenumber, RDAP, or two commercial detectors run against us.
Legitimate addresses not flagged
The false-positive case, and the one that costs you a customer. None of these was flagged as VPN, proxy or Tor.
Compared against: Ten residential, mobile, university and public-resolver addresses — Comcast, BT, Deutsche Telekom, Airtel, Tata, MIT, Duke, Quad9, OpenDNS, Cisco
Tor exit nodes detected
Ground truth, not opinion: the Tor Project publishes exactly which addresses are exits.
Compared against: The Tor Project's own published exit list (1,504 nodes that day)
VPN and datacenter addresses flagged
Nobody can prove an address 'is a VPN'; every vendor runs heuristics. One dissenting vendor is a difference of opinion, not an error.
Compared against: Two independent commercial detectors, ip-api and proxycheck — an address counts as a miss only when BOTH disagree with us
Disposable domains agreed
Both directions: throwaway domains caught, and real providers left alone.
Compared against: Kickbox's open disposable-domain endpoint
Phone numbers agreed
Valid numbers across five countries, and four kinds of invalid one.
Compared against: libphonenumber, the de-facto industry reference
Registration dates matched
Domain age is the strongest 'registered yesterday' signal there is, so being wrong about it matters more than most.
Compared against: RDAP — the registry's own record
How this is measured
Two different standards, because the two kinds of question are not equally knowable.
Ground truth, where an authoritative record exists and being wrong is simply being wrong: Tor exits come from the Tor Project’s own published list, domain age from RDAP — the registry’s own record — phone validity from libphonenumber, and disposable domains from Kickbox’s open endpoint.
Reference consensus, where no truth exists to appeal to. Nobody can prove an address “is a VPN”; every vendor runs heuristics. So those cases are compared against two independent commercial detectors and only counted as an error when both disagree with us. One dissenting vendor is a difference of opinion.
Every case is scored through the live API with a real key, not against fixtures. Test mode returns fixtures by design, so the benchmark refuses a test key outright — a suite that grades its own fixtures produces a number that means nothing, which is a mistake this one made once and now fails loudly rather than repeating.
The corpus and the runner are in the repository at scripts/bench/corpus.mjs and scripts/bench/run.mjs.
What this does not prove
A corpus of 53 cases is not a statistical claim about your traffic. It cannot be, and neither can anybody else’s — the honest use of it is as a floor, not a guarantee: these are cases where being wrong would be embarrassing, and we are not wrong on them.
It also cannot tell you how the scorer behaves on the traffic you actually see, which depends on your market, your price point and who is attacking you. The way to find that out is to run it in shadow mode — score every signup, act on none of it, and compare after a fortnight. The free tier exists partly so that costs nothing.
The other questions buyers ask
What happens to my signups if LayerCall goes down?
Nothing. Both published SDKs and the Express and Next.js middleware fail OPEN: if we cannot answer, the request is allowed through and your signup flow continues. That is a deliberate choice and it is tested — the middleware suite asserts it, because a LayerCall outage becoming YOUR outage is the worst thing this product could do.
Do you have a published uptime figure?
The status page publishes measured uptime with the sample size and window next to it, from a probe that runs every five minutes and records failures as well as successes. An SLA is available on the Scale plan on request. We do not publish a number we cannot evidence.
Do you have SOC 2?
No. We are a small team and we have no security attestation, and saying otherwise would be the easiest lie on this page to tell. "We do not have SOC 2" is not a security posture though, it is the absence of a certificate — so the section below says what is actually true instead.
Who else uses it?
Not enough people to make a logo wall honest. The SDKs are public on npm and PyPI and the download counts are visible there. When there are customers worth naming, and they agree to be named, they will be here.
How do I tune this if it is too strict for my traffic?
Strictness 0–3 moves the allow/review/block thresholds without changing the score, so you can see the same numbers and act differently on them. Custom allow and block rules override the score outright for values you already know about. And /v1/outcome lets you tell us what actually happened, which is the only input that can improve the score for your traffic specifically.
Security posture
We have no SOC 2 and this section is not a substitute for one. It is the list of things that are actually true, each of them a property of the code rather than of a process, and each naming the file so you can go and look.
Stored identifiers are peppered HMACs, not raw values and not bare hashes
The reputation network keeps digests of IPs, emails, phone numbers and domains. A plain SHA-256 would not be enough — the whole of IPv4 is 4.3 billion values and a GPU walks it in seconds. The pepper lives outside the database, so reversing a dump needs the dump AND a secret that is not in it. Asserted by scripts/tests/hash-pepper.test.mjs, which exists because a downgrade to an unpeppered hash produces digests that look exactly as random and nothing breaks until the table leaks.
The analytics never retain an IP address
The pageview beacon resolves a country from the request address and discards the address in the same function. No raw IP, no user agent fingerprint, no third-party script. See app/api/pv/route.ts.
Every outbound request to an address a caller supplied is checked, and no redirect is followed
Webhook delivery, the agent key directory and the web-presence probe all resolve and judge the destination before fetching it, and every one sets redirect: "manual" — because a guard that runs before a fetch which then follows redirects is not a guard. Asserted by scripts/tests/outbound-guard.test.mjs.
A vulnerability report has a published address and a safe-harbour statement
/.well-known/security.txt names a monitored company mailbox and says plainly that we will not take legal action against good-faith research.
An outage fails open, and that is tested
Both SDKs and the Express and Next.js middleware allow the request through when we cannot answer. The middleware suite asserts it, because a LayerCall outage becoming your outage is the worst thing this product could do.
Uptime is a separate question and lives on the status page, measured from a probe that runs every five minutes and records failures as well as successes, published with its sample size and window. There is no latency figure there on purpose — that one needs real customer traffic to mean anything.
Run it against your own traffic
1,000 lookups a month, no card, no daily cap. Score every signup and act on none of it until you have seen a fortnight of your own numbers.
Get your free API key →