Declared relay families: why Tor path building avoids same-operator circuits
For most of Tor's history, running more than one relay came with a small piece of administrative homework: a MyFamily line in every torrc, listing the fingerprints of every other relay under the same operator's control. That mechanism has now left the network, and multi-relay operators are expected to declare their families with a key-based successor instead. The reason the option existed in the first place has not changed, and it is worth restating for anyone adding a second relay today.
What a family declaration is for
A relay family is a set of relays under a single administrative control: one person, one organization, or one host running several tor instances. The declaration exists for path building. Tor clients try not to place two members of the same family in one circuit, because a circuit whose entry and exit positions both answer to the same party is the exact setup needed for an end-to-end correlation attack: the entry sees the client, the exit sees the destination, and a single operator holding both views can join them.When two relays both declare that they are in the same 'family', Tor clients will not use them in the same circuit.The community documentation describes the successor option the same way: FamilyID, it says, is simply telling Tor clients what Tor relays are controlled by a single entity, operator or organization, so that same-operator relays are not used in multiple positions of one circuit. Without that signal, path selection treats related relays as strangers.
When operators forget to declare
The old design depended entirely on operators doing the bookkeeping on every relay and keeping it in sync. A group that shares an operator but ships no declaration is invisible to path selection: the network counts its relays as independent participants. That distorts the diversity statistics used to describe the network, and it narrows the protection clients actually get, because the client-side rule stops exactly at the boundary of what is declared. The OrNetStats project, run by long-time relay researcher nusenu, has tracked this for years. It aggregates relays into effective families - relays with a mutually configured MyFamily setting - and its standing questions include which relay groups have potential MyFamily misconfigurations and which potentially pose a risk to Tor users through end-to-end correlation. Its dedicated report lists operators only where the combination is realistic: guard and exit probability above zero, no properly configured family, and relays spread across more than a single /16 network block - in other words, groups that could actually hold both ends of a circuit. Once a family is configured correctly, the report notes, the relays drop off the page within a day or two. Contact information belongs to the same story. ContactInfo is an unauthenticated string, and OrNetStats notes that this has allowed malicious entities to impersonate other relay operators, something it says has been exploited in the wild. The project therefore displays Authenticated Relay Operator IDs (AROI) where available, which bind contact data to a DNS or webserver control the operator must actually hold.From MyFamily to Happy Families
The old mechanism also scaled poorly. Every relay had to list every other member, and every change required every member to update its configuration. Proposal 321, written by Nick Mathewson in May 2020, put a number on the cost: family declarations made up over 55 percent of microdescriptor content by its February 2025 measurement, and adding or removing a server required all the other servers to change their torrc settings. A November 2021 call for feedback on an easier way to declare families drew responses from operators including nusenu, and the design that emerged keeps the security property while changing the mechanics: an operator generates a family signing key once, hands the key to each family relay, and sets the FamilyId option. Membership is proven with certificates in relay descriptors, and directory authorities publish compact family-ids lines instead of quadratic fingerprint lists. The community guide calls the design Happy Families; it is implemented in the Tor 0.4.9 series and in Arti 1.4.1. The transition closed in 2026. The 0.4.8 series - the last to require MyFamily alongside the new mechanism - reached end-of-life on June 1, and September 1 was set as the date after which 0.4.8-and-earlier clients would no longer be kept working on the network, with the old family lines made obsolete to save client directory bandwidth. The community portal now states plainly that MyFamily has been removed and directs multi-relay operators to FamilyID and a valid ContactInfo. Tooling has followed: the ansible-relayor role dropped MyFamily support in its June 2026 release, noting that all supported tor versions speak the new design.Practical guidance for multi-relay operators
- Run a supported tor release on every relay; the network no longer carries the old family lines.
- Generate a family key with tor --keygen-family, copy the key file into each relay's KeyDir, add a FamilyId line to torrc, and reload.
- Rotate keys in stages: deploy the new FamilyId alongside the old one, wait a few days for propagation, then remove the old line.
- Set a working ContactInfo, which the manual has always required for multi-relay operators, and consider publishing an AROI so your operator identity cannot be spoofed.
- Check how the network sees you: OrNetStats family pages and its end-to-end correlation report show whether your relays are grouped correctly.