When an address is retired
Addresses do not last forever. They get retired for reasons that have nothing to do with the market being in trouble, and the retired ones have a second life that users need to know about. This is the single most exploited gap in user knowledge, so it is worth the read.
#Why an address gets retired at all
The usual reason is accumulated attention. An address that has been public for a couple of years is in every scraped list, every archived forum post, and every abandoned gateway. A large share of the traffic hitting it is not users at all, it is automated scanning, stale bookmarks, and whatever flooding happens to be pointed at it that week. At some point the ratio gets bad enough that the address costs more than it delivers, and a fresh one serves users better.
Less often, an address is retired because the key material behind it needs to be rolled, or because the address was published in a context the operators later decided against. Whatever the reason, the pattern is the same from outside. One address stops answering permanently while the others keep working normally.
#Retirement versus outage
These look identical for the first few hours and then diverge sharply. Telling them apart matters because the correct response is different.
| Outage | One address is unreachable, the others answer normally, and the affected one comes back within minutes to a few hours without anyone doing anything. The roster still lists it. Correct response is to use another address and forget about it. |
|---|---|
| Retirement | One address is unreachable and stays unreachable across days. The roster no longer lists it. The other addresses are unaffected the whole time. Correct response is to delete it from your saved list. |
| Retirement that starts answering again | An address that was dropped from the roster and later starts serving a login page again is not back. Somebody else is running it now. Correct response is to close the tab. |
#Why a retired address is valuable to somebody else
Think about what a retired address has that a fresh phishing domain does not. It has years of accumulated links. It sits in old forum posts, in list sites nobody maintains, in bookmarks, in screenshots. Users recognise it. Some of them recognise it well enough to type it from memory and skip verification because it looks familiar.
Whoever stands up a login clone at that address inherits all of that trust for free. They do not have to rank for anything or convince anyone to click a link. They just have to wait for the traffic that was already going there. That is why retirement is a security event rather than an administrative one, and why the handbook keeps returning to the point that familiarity is not verification.
Worth being precise about one thing. Nobody can steal a v3 onion address. The address is derived from a public key, and serving traffic at it requires the matching private key. A retired address that starts answering again is either being run by someone who obtained that key material, or, far more commonly, is a slightly different address that differs from the original by a few characters in the middle where nobody looks. The second case is the one you will actually encounter. See the glossary entry on v3 onions for why the address length makes this both hard to forge exactly and easy to forge approximately.
#How rotation is announced
An orderly rotation looks like this from the outside. The new address appears on the roster alongside the existing ones and both work. After some overlap period, the old address starts serving a notice instead of the login screen, and that notice is signed with the same key that signs everything else. Then it stops answering.
The overlap is the important part. It exists so that users who only check in occasionally get a chance to see both addresses on the roster at the same time and update what they have saved. If you check the roster once a month you will almost certainly catch a rotation during its overlap window rather than after it.
What a rotation never looks like is a message on a clearnet forum, a post in a chat group, or an email. Those channels are not controlled by anyone who can prove anything, and they are exactly where fake rotation announcements circulate. A rotation announcement you cannot verify with GnuPG is not a rotation announcement, it is a stranger telling you to go somewhere new. The chapter on reading announcements covers how to check one properly.
#What to do about your saved list
The maintenance burden here is small and the failure mode is expensive, which is a good trade to make deliberately rather than by accident.
- Keep your addresses somewhere you control. A text file, a password manager entry, a piece of paper. Not a browser bookmark synced to an account, and not a list site you do not run.
- Compare against the roster every few weeks. Not because addresses change often, but because the cost of noticing a rotation late is high.
- Delete rather than archive. An old address kept around for sentimental reasons is an old address you might paste in one distracted evening.
- Verify on arrival regardless. Rotation hygiene reduces how often you land somewhere wrong. Signature checking is what catches it when you do. Neither replaces the other.
If you want the underlying reasoning for why several addresses exist in the first place, that is covered in the previous chapter. If you have landed somewhere and want to confirm it is genuine before typing anything, go straight to what a signature proves.