Signal Numberless Registration Trades Phone Verification for Zero-Knowledge Proofs

Signal numberless registration has moved from a long-standing user request into working Android code, despite years of mandatory phone verification. Recent commits add numberless account creation, login, payment handling, recovery, and end-to-end tests. The code also uses a zero-knowledge credential, which lets someone prove authorization without exposing the underlying purchase record during registration.

That combination matters because removing phone numbers creates a difficult abuse problem. A phone number has never guaranteed a real identity, but obtaining numbers imposes friction on people creating disposable accounts. Signal appears ready to replace that imperfect barrier with a paid credential while separating payment from the resulting account.

This is more than another privacy setting. Signal introduced usernames in 2024, but users still needed phone numbers to register. Services such as SimpleX have made identifier-free communication central to their designs. Signal is now testing whether a mainstream encrypted messenger can remove phone numbers without making purchases a durable tracking mechanism.

Signal Numberless Registration Is Now Visible in the Android Code

Signal has not announced a public launch, but its Android repository shows a coordinated numberless registration flow rather than an isolated experiment.

On September 2, 2026, Signal developers committed the “numberless account” registration work to the public Android repository. The commit changed 49 files, adding 871 lines and removing 359. Its scope extended across registration screens, account state, network requests, recovery, testing, and username creation.

The code changes allow the registration system to treat a phone number as optional. They also let the application recognize an account whose primary device has no phone number identifier, known internally as a PNI. That distinction reaches beyond the first signup screen.

Signal’s application previously assumed that primary accounts had E.164 phone numbers, the international format used to represent telephone numbers. Numberless support forces the client to revisit those assumptions wherever registration, restoration, contact discovery, or account state depends on a number.

The same September 2 group of commits hides settings that do not apply to numberless accounts. Those include phone-number discoverability controls and some PIN reminders. Other changes add a special numberless country code configuration and login support for an existing numberless account.

A separate commit introduced a new credential from Signal’s zkgroup cryptographic library. This library supports privacy-preserving credentials and group operations. The registration client can present such a credential when creating an account without supplying a phone number.

Signal followed that work on September 9 with payment handling and further numberless-account fixes. The additions cover backup onboarding, account restoration, contact discovery, multi-device synchronization, and registration-lock errors. Signal also added 619 lines of “registration tests” covering numberless flows.

That breadth is significant. A prototype might stop after displaying a new registration screen. These commits instead address the less visible dependencies that often prevent an identity-system change from reaching users.

The feature remains gated inside internal builds, according to the repository. Public Android users should not interpret merged code as immediate availability. Signal has not published a launch date, supported-country list, payment policy, or final user documentation.

The evidence therefore supports a narrow conclusion. Signal is actively implementing and testing numberless accounts, including their payment and privacy mechanisms. It does not yet establish when Signal numberless registration will become a general feature.

That distinction is especially important for existing users. The visible code creates and restores numberless accounts, but it does not clearly promise that registered users can remove an attached number. A community participant asked whether an existing account could be unlinked, and another contributor said the available changes did not establish that option.

The first release could consequently support new numberless accounts without converting old accounts. It could also limit the feature by platform, region, or testing cohort. Until Signal publishes its design, those questions remain open.

Why Signal Needs a Replacement for Phone Verification

Removing the phone number also removes a scarce resource that Signal has used to slow automated registration and disposable-account abuse.

Phone numbers perform several jobs inside messaging systems. They help users find contacts, provide a familiar recovery channel, and create an account identifier people already understand. They also introduce a cost when an attacker needs hundreds or thousands of registrations.

None of those benefits makes a phone number private or secure by default. Numbers often connect to legal identities, billing records, employers, and location histories. People can lose them through reassignment, account cancellation, or SIM-swapping attacks.

Signal reduced interpersonal exposure when it introduced usernames and new privacy controls in 2024. Its official “username design” lets people initiate conversations without sharing their numbers. Exact usernames are required, and Signal does not provide a searchable public directory.

However, usernames changed discovery rather than registration. Signal’s current support documentation still says that the service uses an existing phone number. A number must receive an SMS message or phone call during conventional account creation.

That gap has frustrated privacy-focused users for years. A journalist might want to publish a Signal username without exposing a personal number. An organizer might need a separate identity without buying another cellular line. A tablet owner might not have a number available at all.

The risk grows for people whose phone records are accessible to employers, telecommunications companies, or governments. End-to-end encryption protects message content during transit. It does not erase every external record created while acquiring and maintaining a telephone number.

Yet simply deleting the number requirement would make account creation cheap and repeatable. Spammers could cycle through usernames after blocks. Fraud operators could rebuild account inventories, while automated systems could overwhelm message requests or infrastructure.

Signal already limits what unsolicited senders can do, but content encryption restricts server-side moderation. The service cannot inspect every conversation and classify abusive text like an unencrypted platform can. Registration friction therefore carries more weight.

A community participant identified another conversion problem. If users could register with one number and immediately detach it, one number might generate many free accounts. A cooldown would slow that loop, but determined attackers could wait or distribute their activity.

A payment requirement provides a different scarce resource. It asks each registrant to obtain a valid purchase instead of a valid telephone number. The charge can deter bulk creation without requiring Signal to retain a phone-linked identity.

This approach moves the pressure rather than eliminating it. Payment systems create their own records, geographical restrictions, and access barriers. Someone without a supported payment method might find numberless registration less accessible than SMS verification.

Store operators can also know that a purchase occurred. Google Play, financial intermediaries, or another payment provider might associate that transaction with an existing account. The central privacy question is whether Signal can redeem the purchase without learning which eventual messaging account bought it.

That is where the zero-knowledge credential enters the design. It aims to separate two statements that would otherwise arrive together: a valid purchase exists, and this particular Signal account made it.

How the Zero-Knowledge Credential Breaks the Payment Link

The proposed mechanism lets Signal verify eligibility while avoiding a reusable record that directly joins the payment to the new account.

A zero-knowledge proof lets one party establish that a statement is true without revealing the secret behind that statement. Here, the relevant statement is not the user’s name or financial identity. It is that the registrant holds an authorized receipt credential.

The visible Android code creates a randomized receipt request and sends it through a payment-related registration endpoint. After the purchase is verified, the client receives a credential response. The client then checks that response and constructs a credential presentation for account registration.

This process uses blind credential concepts. A blind credential lets an issuer authorize a hidden value without learning that value in a form it can later recognize. The user can subsequently prove possession while limiting linkability between issuance and redemption.

In practical terms, Signal’s payment service can validate a purchase token and issue a cryptographic receipt. The registration service can later verify that receipt presentation. A correctly designed protocol prevents the server from matching the presentation with the earlier issuance record.

The September code makes that separation visible through several distinct objects. These include a receipt serial, request context, credential response, credential, and credential presentation. Randomness enters when the client creates the request context.

The payment implementation also treats the purchase as a reusable product category rather than a subscription. The visible “payment flow” supports repeatedly purchasing the same one-time item. It checks for an unconsumed purchase before starting another charge.

After successful redemption, the app can consume the purchase token. That makes the store item purchasable again while preventing the same token from authorizing repeated registrations. This detail connects the anti-spam goal to the credential design.

The system therefore needs two protections at once. The credential should be unlinkable enough to protect registrants, while the redemption rules must prevent duplicate use. Weakness in either side would undermine the feature.

If the payment and registration records were directly joined, numberless signup would merely exchange a telecommunications identifier for a financial identifier. That might offer convenience, but it would not deliver the privacy improvement suggested by the feature.

If the credential could be copied or replayed, attackers could purchase once and create many accounts. Signal would then lose the abuse resistance that motivated payment. The code’s receipt serials, verification steps, and consumption process appear designed to prevent that outcome.

Signal already applies related cryptographic ideas elsewhere. Its private group system uses anonymous credentials so servers can enforce group operations without learning group membership in ordinary operation. Donation badges also use receipt credentials to separate payments from profile badges.

This history lowers implementation novelty, but it does not remove deployment risk. Reusing a reviewed primitive is safer than inventing a new one. Registration still introduces new endpoints, state transitions, store dependencies, and failure cases.

The visible source code also cannot prove what production servers retain. Client-side cryptography can constrain what a valid protocol reveals. Researchers still need the final server implementation, protocol specification, retention policy, and deployment behavior to evaluate the complete claim.

Signal’s earlier work on “private discovery” illustrates the same philosophy. Its clients should avoid trusting servers with plaintext social graphs whenever possible. Numberless registration extends that principle into account creation.

The mechanism also protects a specific relationship, not every form of metadata. A store can still know that someone purchased a Signal-related item. Signal can still observe network requests, timing, device information, and subsequent account activity under its normal service architecture.

Users should therefore read “zero knowledge” precisely. It describes what a proof conceals within a defined protocol. It does not mean every participant learns nothing about every event.

For a high-risk user, timing remains particularly relevant. Buying a credential and redeeming it seconds later could permit correlation across separate systems. Network separation, batching, delayed redemption, or other operational choices might reduce that exposure.

Signal has not explained whether the final workflow introduces such measures. It has also not stated what payment metadata its servers receive or retain. Those omissions matter more than the reassuring label attached to the cryptography.

Phone-Free Signup Changes Signal’s Competitive Position

Signal is moving from hiding phone numbers inside conversations toward removing them from account creation, where several privacy-first rivals already differentiate themselves.

WhatsApp still centers account registration on telephone numbers, even though it also uses the Signal Protocol for message encryption. Telegram similarly uses numbers during standard signup and offers usernames for discovery. Those designs preserve easy contact matching but inherit the privacy costs of phone-based identity.

Signal historically occupied a similar position. Its message encryption collected strong reviews, yet critics could point to mandatory phone verification as a foundational identity link. Usernames reduced exposure between contacts without eliminating that link at enrollment.

Signal numberless registration would narrow the gap with services designed around alternative identifiers. SimpleX, for example, says its network does not assign users a global identifier. Contacts connect through invitation links and pairwise addresses rather than a universal phone number or username.

Session uses account identifiers rather than phone numbers and distributes message routing across a decentralized network. Matrix permits accounts on independently operated servers, usually with usernames tied to a chosen homeserver. Each route makes different tradeoffs in discovery, moderation, metadata, and usability.

Signal is not adopting those systems’ architectures. It remains a centrally operated service with a tightly controlled client and server relationship. The numberless work changes its enrollment credential, not its approach to federation or infrastructure governance.

That focus is sensible for Signal’s stated priorities. Central operation lets it update protocols, deploy abuse controls, and coordinate client behavior. It also concentrates trust in Signal’s implementation and policies, even when encryption minimizes available data.

The competitive shift is therefore narrower than “Signal becomes anonymous.” A numberless account can still have a username, profile name, device, network address, contacts, and behavioral patterns. Privacy depends on how those signals interact with the user’s real-world identity.

What changes is the default requirement to present a telephone endpoint before joining. That matters because phone numbers are unusually durable, interoperable identifiers. They travel across messaging, banking, advertising, employment, and government systems.

A paid credential has different properties. It can impose economic friction without becoming the address that contacts use. If its cryptographic separation works, the purchase can authorize registration without remaining attached to the account.

That design also changes the usability contest. Signal can retain familiar usernames and a polished contact experience while offering a more private entry path. Rivals built around anonymous identifiers often ask users to understand invitation links, server selection, or unfamiliar recovery models.

However, Signal’s approach may exclude people who cannot use the supported store or payment rail. Privacy tools often serve users in constrained environments, including regions with restricted app stores. A payment-dependent option needs broader access than one Android billing integration.

The commits currently expose Google Play billing support, while non-Play builds can report that purchasing is unavailable. That raises immediate questions for users of alternative Android stores and direct application packages. Signal has not announced its final cross-platform plan.

Apple’s platform would require its own implementation and review. Desktop devices cannot create primary accounts under the same assumptions as mobile clients today. A complete launch must decide which device and payment combinations can originate a numberless identity.

The comparison with phone verification will also vary by region. SMS delivery can fail in some countries, while prepaid numbers remain accessible in others. Store billing can work well for one user and become impossible for another.

Signal will need to present numberless registration as an option with defined limitations. Treating it as a universal replacement for numbers would overstate what the current code supports. The strongest design might preserve several enrollment paths while keeping their privacy properties clear.

The Hardest Questions Start After the Proof Succeeds

Zero-knowledge credentials can break one link, but recovery, abuse control, payment access, and metadata determine whether the complete system deserves trust.

Account recovery is the first pressure point. A phone number gives users an external channel for reclaiming an identity, although that channel creates SIM-swap risks. A numberless account must rely on secrets, devices, backups, or other credentials.

The Android changes include password-manager support for numberless login and adjusted backup onboarding. They also remove some PIN behavior for numberless accounts. These details suggest that Signal expects recovery material to carry more responsibility.

That shift can improve security for careful users. It can also produce permanent account loss when people misplace a credential or fail to save a recovery secret. Signal must explain that consequence before registration, not after a device disappears.

The code refers to an account entropy pool, a high-entropy secret used across backup and recovery workflows. A password manager can store such information more reliably than human memory. Yet users who lack a password manager need a safe, understandable alternative.

Abuse is the second pressure point. A payment discourages mass registration only when its cost and redemption rules meaningfully affect attackers. Fraud operations can use stolen payment instruments, compromised store accounts, or refund schemes.

Signal must also decide how bans interact with fresh credentials. If a blocked actor can immediately purchase another registration, the system creates friction without stopping persistence. If Signal links too much information to enforce bans, it weakens the privacy promise.

This tension cannot be solved through cryptography alone. Zero-knowledge proofs can show that a valid purchase occurred and prevent simple replay. They cannot decide which abuse signals Signal should collect or how aggressively the service should correlate them.

Payment accessibility creates a third concern. The visible Android work relies on Google Play for its implemented purchase path. Devices without Play billing return an unavailable state, according to code comments. That includes some privacy-oriented Android configurations and distribution channels.

A feature meant to reduce dependence on telecommunications companies could therefore increase dependence on app-store operators. Google might not learn the final Signal account, but it can know that its customer purchased a Signal registration item.

The distinction is meaningful but incomplete. Some users primarily want their Signal account separated from a phone number. Others also want to avoid creating a store or financial record that indicates Signal use.

Signal could eventually support alternative payment providers or vouchers. It could also design giftable credentials that allow one person to authorize another. The current repository does not establish those options, so they should remain possibilities rather than expectations.

Metadata creates the fourth concern. A privacy-preserving credential can be mathematically unlinkable while operational events remain correlated. Issuance time, redemption time, network addresses, device fingerprints, and error logs can narrow anonymity.

Signal’s client is designed to reveal less data to its servers, but no deployed network operates without metadata. The relevant standard is not perfect invisibility. It is whether the system collects only what it needs and prevents avoidable joins.

Independent assessment will require a protocol description and a clear threat model. Signal should identify which parties it assumes can cooperate. That list includes the store operator, payment processor, credential issuer, registration service, and network observer.

Researchers will also need to evaluate whether one organization controls multiple roles. Cryptographic separation can remain valuable even under shared operation. Its guarantees depend on correct construction, key handling, logging behavior, and deployment boundaries.

A community thread helped surface the code, but community discussion is not an official product announcement. Some participants describe the design confidently, while others question unlinking and payment privacy. Their debate identifies valid issues without settling them.

The Android repository provides stronger evidence of implementation. It still represents software under development. Feature flags, interfaces, tests, and comments can change before release, while server behavior may differ from assumptions drawn from client code.

Signal should receive credit for making substantial client work inspectable. That visibility lets developers identify receipt credentials, payment boundaries, and numberless-account states. It also enables scrutiny before marketing language defines the story.

The responsible conclusion is conditional. The mechanism appears designed to prevent a direct payment-to-account link while enforcing one-time authorization. Whether the deployed service achieves that goal has not yet been independently verified.

What to Watch Before Signal Launches Numberless Accounts

Three signals will show whether this becomes a credible privacy feature: public availability, a documented threat model, and broad registration access.

The first signal is a public beta or stable release. The Android code currently gates phone-numberless registration to internal builds. Moving that gate into beta would establish that Signal considers the flow usable outside its development environment.

A beta would also reveal the actual onboarding sequence. Users could see whether payment is mandatory, whether username creation can be skipped, and what recovery material must be saved. Store availability and country restrictions would become measurable.

Watch whether existing accounts can detach their numbers. New-account support alone solves enrollment for future users but leaves Signal’s current population linked to historical phone identifiers. A migration process would expand the feature’s impact considerably.

Signal must explain what detachment means. Removing a number from the interface is not identical to deleting every related server record. Users need a precise account-state definition and a retention policy.

The second signal is publication of a technical design. A useful document should describe credential issuance, purchase redemption, replay prevention, recovery, and relevant metadata. It should also state what payment providers and Signal services can observe.

A formal security review would strengthen the case. The zkgroup library has prior uses inside Signal, but numberless registration creates a new protocol composition. Reviewers should examine both the mathematics and the surrounding application flow.

The most important question is linkability. Signal should define whether the issuer can recognize a redeemed credential, whether multiple presentations can be correlated, and which timing information remains available. Clear limits are more credible than broad anonymity claims.

The third signal is platform and payment coverage. Google Play billing appears in the current Android implementation. A privacy feature cannot serve Signal’s full audience if direct Android builds, iOS users, or unsupported regions lack a registration path.

Alternative credentials would reduce that dependence. Gift codes, nonprofit distribution, or provider-neutral payment mechanisms might help users without supported store accounts. Any such route must preserve one-time redemption and resistance to bulk abuse.

Developers should also watch the server repositories and protocol libraries. New endpoints, credential types, and documentation can reveal which guarantees are enforced cryptographically. Client interfaces alone cannot answer every retention question.

Privacy-sensitive organizations should wait for those details before changing onboarding guidance. Journalists, researchers, organizers, and enterprises need to understand recovery and account-loss risks alongside the reduced phone exposure.

Knowledge workers evaluating privacy tools can record these design assumptions in a personal knowledge base. That creates a durable comparison when Signal publishes documentation or changes the rollout.

Signal numberless registration tackles a real contradiction. The service wants low-data enrollment, yet it must prevent disposable accounts from overwhelming an encrypted network. A paid, unlinkable credential is a coherent answer, but implementation details decide whether it works.

The next move belongs to Signal. It should release the feature, document the observable metadata, and explain recovery without hiding uncertainty behind cryptographic terminology. Readers should ask one practical question when that happens: can each party prove what it needs without gaining a durable path back to the person?