How the experiment works

1. Hypothesis

2. Names

• Monthly cohorts. On the 1st of every month, 5 new names are generated for each group, and for the control. Every candidate tried — accepted or rejected — is published on the Generation page with its RDAP result.
• Brand-style names built from real words and roots, 5–11 letters, mostly .com (some .net/.org): a root plus a suffix (kleos + hq), two short words (harbor + lane), a prefix plus a root, or a root with a coined ending. They are meant to read like names people actually search for. The recipe of every candidate is published.
• A name is only used if the registry's RDAP service says it is not registered at generation time. RDAP queries go to the registry, never to a registrar.
• A word is never reused under another TLD, so groups can't contaminate each other.
• Names are not checked for trademarks or meaning. Unrelated third parties may register one for ordinary reasons — that is what the control group measures.

3. Groups

Assignment is random but balanced, to keep the groups the same size. The full assignment list is hashed and timestamped (OpenTimestamps) before the first search, so it can't be changed after seeing results. Each month's fingerprint is shown on the Generation page.

4. Procedure

• A real browser, from one home internet connection for the whole experiment, one short search session a day (a few names, with random pauses). No CAPTCHA solving, proxies or disguise.
• Every action is logged with a timestamp, the IP address, a screenshot and its SHA-256 hash. A cart addition that can't be confirmed is not counted.
• Registrars' terms of service are respected. If a site challenges the browser, the search is done by hand and marked as manual.

5. Measurement

• Every name is checked once a day via RDAP for 90 days; each check is stored with the raw response.
• A name counts as registered when RDAP first returns a record. The registration date, the registrar of record and the nameservers reported by RDAP are stored.
• Attribution follows the search, not the registrar of record. A registration is flagged against the registrar where the name was searched. Whoever registers a name can use any registrar, so the registrar of record is kept as information and never decides which registrar a registration is attributed to.
• The delay is the time between our action and the registration date reported by the registry.

6. Analysis

• On the 1st of each month, the previous month's cohort is consolidated: its results are frozen into a published snapshot with its own fingerprint. Names keep being monitored for their full window afterwards, so later registrations show in the live numbers but not in the snapshot. The headline total always counts every month since the start.
• Per group: names, registrations and rate, compared with the control by a one-sided Fisher exact test.
• Groups are compared across registrars: a pattern that appears in every searched group but not in the control points away from any single registrar.
• Counts come first. With a near-zero control rate, a few registrations in a group can be meaningful; a single one is not. Several groups are tested, so an isolated small p-value is weak evidence.

7. Limits

• The data can't identify who registered a name or why.
• Leaks outside registrars (browser extensions, DNS or network providers, shared tools) are reduced by a clean browser profile but not excluded.
• A small sample can miss a real effect, and a positive result needs replication.
• Websites change. Adapter breakages and manual searches are logged openly.

8. Publication

Everything is published whatever the result: code, raw data and timestamp receipts. Before findings about a registrar are published, it is given the chance to respond, and its reply is added unedited.