The C tor retirement roadmap: sunset dates, Arti's status, and what operators should watch
The retirement of Tor's original C implementation has moved from principle to schedule. On 23 June 2026, the Tor Project announced its intent to stop network compatibility for Tor 0.4.8 and all earlier releases: after 1 September 2026, those versions will "no longer work on the network at all." The announcement, anchored in the ongoing Arti Relay project, is the clearest public marker so far of how the transition from C tor to Rust is being sequenced.
Why Tor is being rewritten in Rust
Arti is the project's next-generation implementation of the Tor protocols in Rust, described in the project's own README as an effort to build an embeddable, production-quality codebase. The stated reasons are practical rather than cosmetic. The team estimates that at least half of its tracked security vulnerabilities would have been impossible in a memory-safe language. The C codebase, in continuous development since 2002, has accumulated what the same document calls needless spaghetti relationships between components. And a Rust library can be embedded into applications in ways the original SOCKS-proxy design never anticipated, which the developers expect to speed up future work. The migration timeline was sketched in February 2023 by Nick Mathewson, Tor's co-founder and one of Arti's lead architects, in a tor-dev discussion:In the medium term, we will deprecate the C Tor client implementation. This will not be until some time after Arti is a complete tor client with support for onion services, with a complete embedding/FFI/RPC solution.In the long term, Mathewson wrote, Arti is meant to replace C tor entirely, which requires relays and directory authorities in Rust as well. He stressed that no schedule had been committed and that whatever timeline emerged would look annoyingly long from some points of view and annoyingly short from others. Three years on, the sequence is playing out largely as described: the client finished first, the network's core roles last.
What Arti can do today, and what it cannot
As a client, Arti is in good shape. The README, updated as of August 2026, calls it a full-featured Tor client suitable for general client usage: it runs as a SOCKS proxy, connects to onion services, and supports bridges with pluggable transports including obfs4 and Snowflake. Releases have been steady. Arti 2.0.0 arrived in February 2026, and the current release, Arti 2.7.0, landed on 1 October 2026 with more relay and directory-authority groundwork plus a batch of security fixes. We looked at that client-side progress in more depth in our earlier Arti coverage. Beyond the client, the honest picture is thinner. Running Arti as a relay or directory authority is not yet supported, as the 2.0.0 release notes state directly, and the relay README carries a standing warning that relay support is experimental and "not at all ready for general deployment," asking people not to run an Arti relay on the public network. The project's internal checklist shows real progress, including incoming channels, CREATE2 and EXTEND2 handling and ORPort listening, with congestion control, descriptor publishing, exit policies and denial-of-service defenses still open. Onion services sit in a similar position on the service side. The project's own documentation says a service run on Arti is suitable for testing and experimentation only: it lacks client authorization, vanguard relays, meaningful denial-of-service protections and circuit padding, and warns that operating one could even compromise the privacy of other uses of the same Arti instance. Connecting to onion services from Arti as a client, by contrast, is part of normal client operation.The September sunset, explained
The 1 September cutoff is a compatibility move, not a security deadline. Tor 0.4.8 already reached end of life on 1 June 2026 according to the project's release calendar and receives no further updates. What changes after September is directory protocol behavior: the 0.4.9 series drops the old TAP onion keys and relay family lines from directory data, following proposals 350 and 321, which trims client bandwidth and speeds up bootstrap for everyone. Because clients and relays on 0.4.8 and earlier expect TAP keys to be present, they stop working once those fields disappear. A secondary motivation is candid: the Arti directory authority implementation needs network integration soon, and is easier to write without deprecated fields. Nor is this the end of C tor itself. The same calendar lists 0.4.9, marked stable in February 2026, with its own end of life still to be decided, and a 0.5.0 series whose merge window opened in March 2026. The team describes current C tor maintenance as including features chosen to ease the transition to Arti. Downstream projects that still bundle old versions are being contacted directly, with outreach tracked in a network-health ticket that also takes requests from operators who need more time.What operators should watch
- Relay operators: run 0.4.9.x before 1 September 2026; anything older will drop off the network. There is no Arti relay to migrate to yet, so treat claims otherwise with skepticism and follow the Arti changelog.
- Onion service operators: C tor remains the supported way to run a service. The markers that will signal Arti service-readiness are the missing pieces listed above: restricted discovery, vanguard support, denial-of-service defenses and circuit padding.
- Application developers: the intended end state is embedding and RPC rather than a bundled SOCKS daemon. Arti 2.0.0 marked the top-level arti crate's APIs experimental while arti-client remains the supported interface, and 2.7.0 added RPC-based configuration control.