Signal's Phone-Numberless Registration Work Moves Zero-Knowledge Proofs Into Account Creation

Signal appears to be moving phone-numberless accounts from product intention toward implementation. Public Signal Android work discussed this weekend adds registration and login paths for accounts that do not use a phone number and introduces a new zkgroup credential in the flow.

The change does not mean anonymous registration is generally available today. It is evidence in source code and community discussion, while rollout details, eligibility, recovery behavior, and final pricing remain product decisions. The distinction matters because privacy features are often reported as shipped long before ordinary users can depend on them.

What happened

Signal has previously described an optional paid route for creating an account without supplying a phone number. The fee is intended to raise the cost of abuse that phone verification currently helps deter. The recent Android changes discussed in the Signal community show the client preparing for a distinct account type and using credentials built with Signal’s zkgroup cryptographic system.

Zero-knowledge proofs let one party prove that a statement is valid without exposing the underlying secret. Signal already uses related techniques in private groups and other credential flows. In registration, the goal is not to make the service know nothing; it is to prove the properties needed for account operation and abuse controls while revealing less identity data.

The September 13 Hacker News submission reached 157 points and 74 comments by the September 14 check. Much of the reaction focused on recovery, spam resistance, payment privacy, and whether a paid option shifts rather than removes identity leakage.

Why it matters

Phone numbers are convenient global identifiers, but they are poor privacy primitives. They can be reassigned, exposed through address-book matching, targeted by SIM-swap attacks, and tied to legal identity through telecom systems. Signal has already reduced number exposure with usernames; eliminating the number at registration would address the dependency earlier in the account lifecycle.

The hard problem is abuse. Creating accounts must be cheap enough for legitimate people and expensive enough to slow industrial spam. Phone verification outsourced some of that friction to carriers. A one-time payment can replace part of the cost, but it introduces payment processors, regional availability, refunds, and users who cannot pay digitally.

Zero-knowledge credentials are relevant because the service may need to recognize that a user completed an approved issuance flow without retaining a plain link between the payment, account, and future activity. Whether the deployed system achieves that property depends on the full protocol and operational metadata, not the phrase “zero knowledge.”

Evidence

The Signal community thread links the implementation work and discusses the new account path. Signal’s earlier announcement is the primary product source for the planned paid option. Together they support a cautious statement: the company announced the direction, and client-side implementation is progressing.

They do not establish a public launch date. Code can be merged behind flags, redesigned, or removed. Server support and policy can lag behind the Android client. iOS, desktop linking, backups, account transfer, and abuse appeals may require separate work.

The public reaction is valuable as a threat-model checklist, not as proof of product behavior. Commenters raised concerns about cryptocurrency, app-store payments, burner payment instruments, and account recovery. Signal has not necessarily adopted the architectures commenters speculate about.

Practical takeaway

Privacy products should map the complete identity lifecycle before celebrating less data at signup. Ask what the service learns during issuance, what the payment provider learns, how credentials are refreshed, how devices are linked, how abuse bans work, and what happens when access is lost.

For developers, the design pattern is broader than messaging. A service can issue a credential after checking payment, membership, age bracket, or organizational entitlement, then let the user prove that property later without presenting the original record. The verifier should learn only what it needs.

That architecture still needs rate limits, revocation, secure device storage, replay protection, and recovery. Cryptography reduces disclosure at a protocol boundary; it does not automatically eliminate logs, IP addresses, push-notification metadata, or support records.

Limitations

EgoistAI verified the public announcement, community thread, and current discussion but did not audit the complete Signal protocol or build the Android branch. The final user experience may differ from current code. “Phone-numberless” should not be read as “untraceable,” and payment mechanics may vary by country.

The Signal community forum is not itself an official release note. It is useful because it points to public development artifacts and captures informed reactions. Final claims should rely on Signal’s shipped clients and formal documentation when the feature launches.

Final verdict

Signal’s work is a meaningful attempt to remove a legacy identity dependency without opening unlimited free account creation. The important innovation is not merely replacing a phone number with a username. It is separating eligibility from identity through cryptographic credentials. Until server support and end-to-end rollout are documented, treat it as credible implementation progress rather than a finished feature.