C01-TO: Yes
Rationale
A v3 onion address is derived from the service identity key rather than its network attachment. After losing one IPv4 access connection, the same service can reconnect through another usable attachment, rebuild introduction circuits and publish current introduction information. A client uses the unchanged onion address to retrieve the service descriptor and establish a new rendezvous circuit.
Assessment method
Primary specification review; no runtime experiment
Source context
Tor onion-service protocol and pinned Reticulum 1.5.5 announcement routing
Outstanding qualification
Preserve the service identity and configured client-authorization material, restore permitted Tor connectivity and allow fresh descriptors to propagate through the public directory system. This protocol-native lookup discovers routing/introduction information; it does not ask the sender to replace the destination onion address or follow an application redirect. Stale descriptors, blocked access, guard policy and unavailable relays can delay or prevent recovery. New circuits/streams are allowed; uninterrupted existing streams, simultaneous migration, OnionBalance and Conflux execution are not credited. Documentary architectural witness, not a mobility test.
Public sources
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round526.html
- round526-sources.json