From Phone Number to Cryptographic ID: How eSIMs, Internet Providers and VoIP Really Work, and What VIVON Changes

A long read on the three networks hidden inside every phone, the metadata they leak, and why LINKSPREED is rebuilding the access layer on top of UIID

Estimated reading time: 55 to 60 minutes

Key takeaways

A phone is three services in one. It bundles a SIM identity, a data connection and a phone number for calls and texts. All three trace back to one customer record that someone else issued and controls.
An eSIM is a SIM you download. That makes switching easier. It does not change who owns the identity, because the profile still belongs to an operator.
Encryption protects content, not the fact of communication. Providers, carriers and signalling servers see who connects, when and from where, even when the content is unreadable.
The phone number is a weak master key. It sits on legacy signalling systems, can be moved to another SIM, and is now being phased out as a security factor by major vendors.
Peer-to-peer calling still needs servers. Signalling and relays are unavoidable because of NAT. What matters is how little those components learn.
VIVON is Layer 2 of the LINKSPREED Web4 stack. It is designed to bring calls, messages and internet access to a phone, addressed by UIID identities instead of phone numbers and delivered over eSIM connectivity with metadata shielding.
The hard questions are real. They include the radio link itself, who issues the eSIM profile, emergency calls and network effects. This article treats them openly.

Introduction: three networks in a trench coat
Why this matters now
Part One: SIMs and eSIMs
Part Two: What the radio network knows
Part Three: Internet access and what the provider sees
Part Four: Voice and messaging
The common weak point: identifiers owned by someone else
A threat model in plain language
UIID in brief: the foundation VIVON builds on
Part Five: VIVON
How the VIVON design maps to each threat
Who this is for: seven scenarios
How VIVON compares with other approaches
The honest part: what is hard
Twelve questions to ask any private connectivity provider
Why this matters for Web4
How to get started
FAQ
Glossary

1. Introduction: three networks in a trench coat

Most people think of “my phone” as one thing. Technically it is three separate systems that happen to share a device.

An identity system. A SIM, or an eSIM profile, proves to a mobile network that this device belongs to a paying subscriber.
An access network. A carrier or internet service provider (ISP) hands the device an IP address and carries its packets to the rest of the internet.
A communication service. Calls and text messages, addressed by a phone number, routed by a telecom core and delivered to another phone number.

These layers were designed decades apart, by different industries, for different goals. What holds them together is one identifier: the subscriber identity on the SIM and the phone number that maps to it. Because that identifier was created under rules that require a registered customer, it usually leads straight to a real person.

Almost every privacy tool on a phone works above this foundation. Encrypted messengers, password managers, private browsers and even good VPNs all assume the connection underneath is simply there. They protect what you do on the connection. They do not change the fact that the connection itself was issued to you by a third party who knows who you are.

LINKSPREED’s next product, VIVON, starts from a different question. What happens if the identity layer is replaced by something the user owns, and the access and communication layers are rebuilt on top of it? VIVON has been announced as coming to Google Play together with the UIID app. It is described as a secure mobile access layer that decouples a connection from ISP surveillance using eSIM technology and metadata shielding.

To judge whether that idea makes sense, we first need to understand how each of the three layers works today. The first half of this article does that, in detail and with sources. The second half introduces UIID, explains VIVON, and ends with an honest list of what is hard and how to evaluate any provider that makes similar claims.

2. Why this matters now

Four developments make this topic more urgent in 2026 than it was a few years ago.

eSIM has reached scale. The Trusted Connectivity Alliance reported that consumer eSIM profile downloads in the first half of 2026 almost equalled the volume of the whole of 2025, with a strong uplift in China after domestic operators received regulatory approval in October 2025. Analysts have forecast more than 633 million eSIM-enabled device shipments in 2026. The delivery mechanism for a new kind of connection is now in hundreds of millions of pockets.

SMS is being retired as a security factor. NIST’s digital identity guidelines no longer treat SMS one-time codes as adequate for the practical baseline most regulated systems use. Microsoft has announced that, starting 1 September 2026, passkeys become the default sign-in experience in Entra ID, and that Microsoft-provided SMS and voice authentication will be retired from 1 February 2027 for most users. When the largest identity platforms move away from the phone number as a trust anchor, the question of what replaces it as an address and an identity becomes practical, not academic.

Retention rules keep moving. In Germany, a draft bill circulated in December 2025 would require ISPs to retain IP addresses and timestamps for 90 days. Reporting in spring 2026 described it as awaiting a Bundestag vote. Whatever one thinks of it, the direction of the debate shows that connection data is a live legal subject.

Digital identity is becoming a mainstream topic. EU member states must offer a digital identity wallet by the end of 2026. LINKSPREED has been publishing on the contrast between that approach and UIID. A communications layer that starts from an owned identity is the next logical question.

3. Part One: SIMs and eSIMs

3.1 What a SIM actually does

A SIM card is a small secure computer. It stores a few secrets and answers one question for the network: is this subscriber legitimate?

When a profile is created, the operator generates the subscriber identifier (the IMSI, which identifies the subscription on the network), a card serial number (the ICCID) and encryption keys. For compatibility with older networks, a secret key called Ki and an operator code called OPc are part of the profile. When a phone attaches to a network, the network sends a challenge. The SIM answers using its secret key. If the answer is right, the phone is admitted. The secret key never leaves the SIM.

This design is clever and has held up well. It also has a consequence that matters for privacy: the identity belongs to the operator. The operator created it, knows who it was sold to, and can switch it off.

3.2 From plastic to chip: eUICC, eSIM and iSIM

The plastic card became a chip soldered onto the device board. That chip is called an eUICC (embedded Universal Integrated Circuit Card). It is a tamper-resistant secure element that can host several isolated profiles, each containing one operator’s credentials. A useful picture is a vault with several locked rooms.

The next step is the iSIM, where the same function is integrated into the main processor of the device. A research paper from the University of Colorado Boulder makes a point worth repeating: even with eSIM and iSIM, subscriber identity remains coupled to hardware, and all profiles link back to the same hardware identity. The authors propose a software-based “vSIM” running in a trusted execution environment, so that identity can rotate or move between devices, for example to give someone different numbers for different purposes. That is a research direction, and we do not claim VIVON uses it. It is useful here because it shows that decoupling identity from hardware is an open problem the industry itself is working on.

3.3 How an eSIM is downloaded

The consumer standard behind every eSIM on a phone is GSMA SGP.22, known as Remote SIM Provisioning (RSP). It defines five actors:

eUICC: the chip in the device.
SM-DP+: the “profile factory”. It builds, encrypts and delivers profiles to a specific chip.
SM-DS: a discovery service that tells a device a profile is waiting. It holds pointers, not profiles.
LPA: the Local Profile Assistant, the software on the device that orchestrates the process.
Operator: the company that owns the subscription.

The flow most people experience goes like this. The user receives an activation code, usually as a QR code. The LPA contacts the SM-DP+ at the address embedded in the code. The SM-DP+ authenticates the eUICC against the GSMA certificate hierarchy, and the eUICC downloads and installs the profile. A profile is delivered in three phases: initiation, mutual authentication and an encrypted download. The profile is encrypted with keys bound to the chip’s identifier (its EID), so only that one secure element can decrypt and install it. Interestingly, the LPA is treated as an untrusted pass-through, and all cryptographic verification happens inside the eUICC.

On Android and iOS the details differ. On iOS the LPA is managed by the system, while on Android it may be the standard Android component, an OEM variant or, in some architectures, a carrier app.

In plain language, an eSIM download is a secure delivery of an operator’s identity into a chip over the internet within seconds. The security of that delivery is good. The question is what is being delivered, and whose it is.

3.4 Why eSIMs took off

eSIM is now ten years old, and travel is where it has changed behaviour the most. GSMA Intelligence reported that 60 percent of eSIM users used an eSIM service while travelling abroad within the previous twelve months. Awareness of eSIM doubled in two years, from 25 to 50 percent. One industry executive described “silent roamers”, people who simply do not switch roaming on when they travel, as accounting for as much as 90 percent of mobile users, and eSIM gives them an easy alternative to buying a local SIM.

The IoT side is moving too. SGP.32, the newer standard, adds an eSIM IoT Manager (eIM) and an IoT Profile Assistant (IPA) for devices without screens, while the consumer LPA model in SGP.22 stays unchanged. The TCA reported a fivefold increase in the number of subscription manager platforms supporting SGP.32 compared with the full year 2025.

3.5 What eSIM did not change

It is worth being precise here, because eSIM marketing often implies more than the technology delivers.

The profile still belongs to an operator. Whoever sells the profile knows the subscriber and holds the commercial relationship.
Many travel eSIMs are data-only. They give a fast connection but no phone number, so there are no inbound calls, no SMS and no SMS verification codes.
Plans with a number come with a number from one country and the rules of that operator.
Switching is easier, but the model is the same. eSIM did not trigger the dramatic churn some predicted. It made the existing model more convenient. It did not replace it.

So eSIM solved the delivery problem of identity. It did not solve the ownership problem. That distinction is the starting point for VIVON.

4. Part Two: What the radio network knows

Before we reach the internet or the phone number, there is a layer that most privacy discussions skip: the radio link between the phone and the tower.

4.1 The permanent identifier and the IMSI catcher

In 2G, 3G and 4G, a device identifies itself to the network using its IMSI, a 15-digit subscriber identifier made of a country code, a network code and a subscriber number. In 4G the IMSI is transmitted in plaintext during the initial attach. That made it trivial for a device impersonating a tower, commonly called an IMSI catcher, to collect identifiers from phones in its range. A permanent identifier that leaks early in the attach flow makes passive tracking cheap.

4.2 What 5G changed: SUPI and SUCI

5G tried to close that door. The permanent identifier is renamed SUPI (Subscription Permanent Identifier). When the device first registers, it should send a SUCI (Subscription Concealed Identifier) instead, which is the SUPI encrypted with the home network’s public key. Only the home network, which holds the private key, can recover it. After a successful registration, the network assigns a temporary identifier, the GUTI, which the phone uses for later registrations so the permanent identity is exposed far less often.

This is a real improvement, and it comes with caveats that matter for any honest discussion of mobile privacy:

It is optional. NIST describes SUCI as an optional 5G capability and encourages operators to enable it and to configure a non-null encryption scheme. 3GPP also defines a “null” scheme, in which nothing is concealed.
It depends on the deployment. One security firm notes that SUCI is the single biggest privacy improvement in 5G, but only in 5G standalone networks. In non-standalone deployments, the LTE anchor still transmits the IMSI in plaintext, so the IMSI-catcher risk persists.
Misconfiguration brings the old exposure back. If concealment is badly rotated, downgraded or bypassed through fallback, the result is legacy-style exposure.

4.3 What this means for any “private mobile” product

The radio layer is where the network has to know a device exists in order to deliver data to it. Any design that uses a mobile radio network, including one with a borderless eSIM, has to live with that. Even in the best case, the serving network sees that a device with a temporary identity is attached to a given tower. What can change is what is linked to that attachment: a stable permanent identifier, a billing record with a name, a phone number.

This is an important framing for evaluating VIVON. The design goal is not to make the radio link invisible, which no software can do. The design goal is to ensure that what the radio network and the layers above it can link together is as little as possible. We return to this in Section 14.

5. Part Three: Internet access and what the provider sees

5.1 What an ISP does

An ISP or mobile carrier hands each connected device an IP address, usually through DHCP, and carries traffic between that device and the rest of the internet. On mobile networks, many subscribers typically share public addresses, which matters later in the discussion of peer-to-peer calls.

5.2 What the provider can see

Even when the content of a connection is encrypted, the provider sees a lot around it:

Connection logs. Which customer had which IP address at which time. These are typically retained for six months to several years depending on jurisdiction and policy. Providers can also log destination addresses, timestamps, data volumes and protocol types, which reveals which services someone uses even when the content is encrypted.
DNS queries. By default, DNS lookups go to the ISP’s own resolvers, so the provider sees every domain looked up. The source describes DNS logs as arguably the most privacy-sensitive data an ISP collects. Switching to encrypted DNS with a non-ISP resolver stops the ISP from reading the queries, but it can still see destination IP addresses.
Deep packet inspection. Some providers inspect packet payloads for malware detection or traffic classification, and some for advertising. With HTTPS, the provider can still see the destination domain through the TLS handshake. A VPN prevents inspection at the ISP level by encrypting packets before they leave the device.

For a mobile carrier there is one more category: location. The network knows which cell a device is attached to, because it needs that to deliver calls.

5.3 The last plaintext hostname: SNI and Encrypted Client Hello

Many people believe that HTTPS hides which sites they visit. It hides the content. For years, the hostname still travelled in plaintext in the TLS handshake, in a field called Server Name Indication (SNI). Anyone on the network path, including an ISP, a hotspot operator or a corporate firewall, could read it. Encrypted DNS closes one channel, and SNI was the third channel that still named the destination.

Encrypted Client Hello (ECH) is the fix. The browser builds two messages: a readable outer one addressed to a generic, shared hostname, and an encrypted inner one carrying the real destination. A network observer then sees only the shared hostname. The standard was published as RFC 9849 in March 2026.

Two honest limits are worth keeping in mind:

ECH needs encrypted DNS. The key is published in a DNS record, so if the lookup is readable, the protection collapses.
It moves the secret, it does not remove it. The server or CDN that decrypts the inner message still sees everything.

The privacy benefit is biggest when many sites share one front, because the observer’s uncertainty grows with the number of sites behind it.

The lesson is general. Each step that closes one metadata channel tends to move trust to another party. The question is always who that party is, and how little it needs to learn.

5.4 CGNAT: why your phone’s IP address is not yours

IPv4 addresses ran out. The IANA stopped handing out new blocks in 2011. Providers responded with carrier-grade NAT (CGNAT), which places many subscribers behind one shared public address. The IETF’s requirements document describes it as a NAT function used to share the same IPv4 address among several subscribers, one the subscribers do not manage.

Three consequences matter here:

Incoming connections fail. Because the translation happens inside the provider’s network, subscribers cannot open ports. Port forwarding on a home router has no effect.
An IP address is a poor identifier of one person. One source notes that a mobile phone’s address is often shared with thousands of other subscribers and that mobile networks use CGNAT almost everywhere. That cuts both ways: it gives some accidental anonymity toward websites, and it makes it hard for the provider to log a one-to-one mapping without extra records.
Peer-to-peer connections get harder. CGNAT is one of the reasons direct device-to-device traffic often needs help. This is exactly the NAT problem VIVON’s calling design has to solve, and we come back to it in Section 6.5 and Section 10.

IPv6 removes the need for CGNAT, which is why many networks run both. Some modern fibre and mobile networks now give customers IPv6 only.

5.5 The legal picture, in Germany and in the EU

Retention rules are a moving target, which is exactly why they matter.

Germany’s Federal Commissioner for Data Protection (BfDI) describes the position this way. The Telecommunications Act still contains retention rules in Sections 176 to 180, which oblige providers to store location data for four weeks and defined traffic data for ten weeks. Because of pending legal proceedings, the Federal Network Agency suspended that retention in 2017. The European Court of Justice ruled in September 2022 that the indiscriminate retention of traffic and location data under German law is incompatible with European law.

At the EU level, the Court has progressively struck down general metadata retention since 2014, but carved out an exception for IP addresses in April 2024. In Germany, the draft bill mentioned above would require ISPs to keep IP addresses and connection timestamps for 90 days. It does not yet have the force of law.

The point is not to take a side in that debate. The point is structural. Whatever a provider can see, a law can one day require it to keep, and a breach can expose it. A design that reduces what the provider can see changes that equation.

5.6 Roaming, MVNOs and country-locked contracts

Two more pieces of context matter for VIVON.

A mobile virtual network operator (MVNO) sells mobile service without owning radio towers. It rents capacity from a network operator. Digital-first MVNOs are one of the ways eSIM has introduced competition.

Roaming is the arrangement that lets a subscriber’s home operator use a partner network abroad. It has historically been expensive, and as the numbers above show, many travellers avoid it altogether. Country-locked contracts are the commercial side: the relationship, the billing and the number belong to one country.

6. Part Four: Voice and messaging

6.1 The legacy: SS7 and SMS

Classic voice and SMS are carried by signalling systems whose core, SS7, was developed in the 1970s for a closed ecosystem of trusted telecom operators. It lacks modern authentication and encryption. The ITU describes SS7 as having long been “broken”, with published vulnerabilities, some over twenty years old, that allow fraud, account takeover and interception.

SMS inherits this. It was introduced in the early 1990s with no authentication and no encryption, and it travels through the core signalling network. Attackers have abused operations such as SendRoutingInfoForSM to reroute or capture messages, including one-time passwords. Subscriber location tracking and SMS interception are two of the most commonly described SS7 problems. The ITU also lists SIM cloning, SIM swaps and SIM recycling among the main SIM risks.

A mobile number’s ownership is maintained by the carrier. If someone calls the carrier and convinces a representative to move a number to a new SIM, every call and SMS to that number goes to whoever holds the new SIM. The attack exploits a legitimate business process, and it works through customer service, not through hacking the network. The ITU’s recommendations for carriers include biometric checks, multi-factor validation before a swap, holding times before activation of a swapped SIM and notifications to the user.

6.3 The number as a master key, and why that era is ending

For many people the phone number has quietly become the master key of their online life. Banks, social networks and email providers send recovery codes to it. That role is weak for two reasons: the number can be intercepted at the signalling level and it can be moved to another SIM.

The industry response is already visible. NIST’s guidance moved SMS one-time codes out of the set of authenticators it accepts for the practical baseline of most regulated workloads. The recommended replacement order is passkeys first, then authenticator-app codes, then push with number matching. Passkeys are phishing-resistant by construction, because the credential is bound to the site it was registered with, and the private key stays in the device’s secure hardware. Microsoft’s Entra ID plan to make passkeys the default and retire its own SMS and voice delivery follows the same logic.

This is directly relevant to the VIVON story. UIID is built on WebAuthn and device-bound keys, the same technology family as passkeys. If the world is moving its trust anchor from “a number you can receive a code on” to “a key your device holds”, an address system built on keys is a natural counterpart, and a connectivity layer addressed by those keys is the logical next step.

6.4 VoIP: SIP and RTP

Voice over IP replaces the dedicated telephone circuit with packets. Two jobs are done by two protocols:

SIP (Session Initiation Protocol) handles signalling. It sets up, modifies and tears down sessions. It is a text-based protocol standardised in RFC 3261 and borrows heavily from HTTP in its design. A call typically involves a REGISTER (the device announces itself), an INVITE (the call starts) and a BYE (the call ends).
RTP (Real-time Transport Protocol) carries the actual voice and video packets. SIP itself does not transport media. SIP negotiates parameters such as codecs and ports by carrying an SDP (Session Description Protocol) payload.

6.5 VoLTE and VoNR: the carrier’s own VoIP

When a modern phone makes a “normal” call, it is usually already VoIP. VoLTE replaced circuit-switched calls with SIP-based sessions over the carrier’s IP Multimedia Subsystem (IMS), and VoNR extends the same architecture to 5G. The IMS core uses elements such as the P-CSCF (first SIP contact point), the I-CSCF, the S-CSCF (registrar and session control) and telephony application servers. As of 2025, the GSMA reported VoLTE deployed by more than 310 operators in more than 140 countries, and VoNR on more than 45 networks.

The consequence is worth stating clearly. Even when a call is “just VoIP”, it is VoIP inside the carrier’s walled garden: the carrier’s registrar, the carrier’s numbering and the carrier’s records. Moving to packets did not by itself move control to the user.

6.6 WebRTC and the NAT problem

The other major family is WebRTC, the standard behind browser and app calling. Its promise is direct peer-to-peer media: lower latency, no server in the media path and no single choke point. The obstacle is NAT. Most devices sit behind a router that translates private addresses into a public one, so an outside peer does not know how to reach them. On mobile networks, CGNAT adds a second layer of the same problem, as Section 5.4 showed.

WebRTC solves this with ICE (Interactive Connectivity Establishment), a framework that gathers and tests possible connection paths called candidates. It collects three kinds: host candidates (the device’s own addresses), server-reflexive candidates (the public address and port the NAT allocated, discovered through STUN) and relayed candidates (a relay server’s address, used when no direct path exists).

STUN tells a device what its public address and port look like from the outside, so two peers can attempt a direct connection.
TURN relays the media through a server when no direct path works. It is needed with symmetric NAT, where the router assigns a different external port for every destination, so the address STUN discovered is useless for the peer. TURN adds overhead and is used only when nothing else works.
Signalling is how peers exchange session descriptions and candidates. The WebRTC specification does not define it. Every application builds its own.

One practitioner puts the reality bluntly: WebRTC is peer-to-peer, but reliable peer-to-peer connections across the modern internet are impossible without supporting server infrastructure. Two details follow. First, whoever runs the signalling knows who is calling whom and when. Second, whoever runs the relay sees the traffic pattern, even if the content is encrypted.

That is the core insight for the rest of this article. Encryption protects what is said. Architecture decides who learns that a conversation happened.

6.7 Metadata: the part end-to-end encryption does not cover

A correctly implemented end-to-end encrypted message hides what you wrote. It does not by itself hide who you wrote to. The service still has to know where to deliver a message, and before 2018 Signal’s server could see sender, recipient and timestamp in each envelope. A motivated adversary with server access, or with legal power over the operator, could build a graph of who communicated with whom and when. The source quotes a former NSA director’s remark that metadata is what decisions are made on, which captures why this matters.

Signal’s answer, introduced in 2018, was “sealed sender”. The sender wraps their identity inside an encrypted envelope for the recipient, so the server learns only the destination. To prevent spam in a system where the server cannot see who sends, Signal uses delivery tokens derived from the recipient’s profile key. The approach has limits. The recipient’s identity is still known to the server, timing analysis could in theory correlate sender and recipient, and it works best between parties who already have a session.

Two lessons carry over to any identity-addressed messaging layer, VIVON included:

Metadata protection is possible, not only content protection. It is an engineering choice about what the server needs to know.
Removing visibility creates an abuse problem. If the server cannot see the sender, it needs another way to stop floods. Any system that moves away from phone numbers has to answer that question.

6.8 Emergency calls: the part nobody can skip

Calling an identity instead of a number is elegant between two people who both use it. It does not on its own reach an emergency service. Under EU and German law, providers of publicly available communications services that allow calls to numbers in the national numbering plan must make sure emergency calls reach the correct local emergency centre without delay, with caller number and location information.

The EU’s rules continue to develop. A Commission delegated regulation (2023/444) sets measures on caller location, access for users with disabilities and routing to the most appropriate emergency centre. The Commission’s press release adds that it acknowledges the migration to all-IP networks, requires Member States to provide roadmaps for upgrading national systems to receive emergency communications over packet-switched technology, and asks them to cooperate on common interoperability requirements for emergency communication apps. That is a direct signal for any app-based calling service: emergency access is a regulated function, not a feature to add later.

7. The common weak point: identifiers owned by someone else

Put the three layers side by side and a pattern appears.

Layer	Today’s identifier	Who issues and controls it	What it reveals
SIM / eSIM	IMSI, ICCID, profile	The operator	Who the subscriber is, which cell they use
Internet access	IP address, DNS queries, SNI	The ISP or carrier	Who connects to what, and when
Voice and messaging	Phone number	The operator, via the numbering system	Who talks to whom

Each layer has its own identifier, but all three are issued by a third party and linked to one customer record. Encryption in the middle of the stack, such as HTTPS or end-to-end encrypted messaging, protects content but does not touch these identifiers.

This is the problem UIID was built to address at the identity level, and VIVON extends it to the physical access level.

8. A threat model in plain language

A privacy claim is only meaningful against a specific adversary. Here are the adversaries that matter for mobile connectivity, what each can do today, and what would reduce the exposure.

Adversary	What it can do today	What would reduce the exposure
A passive listener on the radio link	Collect permanent identifiers in 4G, or in non-standalone 5G	Concealed identifiers, standalone 5G, and not linking the radio identity to a person
A fake tower (IMSI catcher)	Capture the IMSI and track the device	SUCI with a non-null scheme
The ISP or carrier	Log IP assignments, DNS queries and destinations	Encrypted DNS, ECH, tunnelling and traffic masking
A signalling-level attacker	Intercept or reroute SMS, track location	Not using SMS and numbers for trust or addressing
A social-engineering attacker	Move a number to a new SIM	Identity bound to device keys, not to a number
A messaging or signalling server operator	See who talks to whom	Sealed-sender-style designs, minimal signalling
A relay operator	See traffic patterns, not content	Encrypted media, many independent relays, minimal logs
A legal request to any of the above	Compel whatever is retained	Retaining less in the first place

No single product removes every row. The useful question is which rows a design addresses, and which it leaves to others. That is the lens we use for VIVON in Section 11.

9. UIID in brief: the foundation VIVON builds on

UIID, the Universal Integrated Identity Decoupled, is LINKSPREED’s identity layer. It is Layer 1 of the Web4 stack. Its main ideas are:

A Core ID and Aliases. The architecture splits a person’s presence into a master Core ID and multiple context-specific Aliases. This separation is designed to prevent platforms from correlating behaviour across independent services.
Keys that stay on the device. Identities are generated on the device and secured with WebAuthn and local biometrics. LINKSPREED describes UIID as a local-first protocol using on-device biometrics and zero-knowledge proofs for passwordless authentication.
Proofs instead of documents. Zero-knowledge proofs let a person prove a statement, such as an age or a location, without disclosing a name or a government ID.
Hardware-anchored enrolment. LINKSPREED states that because the system requires localized biometrics, creating mass bot networks or throwaway deepfake profiles becomes economically and technologically impractical. This is the company’s claim, and it matters for the abuse question in Section 14.
More than humans. With version 2.8, announced on 16 June 2026, UIID covers six entity types, including human individuals, organizations and AI agents. An Agent Factory lets creators issue provisioning tokens and monitor agent fleets, and static API keys are replaced by dynamic authorization tokens.
A resolvable identifier. UIID identities appear in the form did:uiid:… in the Web4 reference material.

For this article, the relevant property is the combination of these: an identity that is owned by the user, can be turned into many unlinkable aliases, can sign and prove things without a central database, and can also belong to a machine. That makes it a candidate for something the phone system never had: an address that is not a phone number.

Anyone can claim a free Core ID at uiid.me.

10. Part Five: VIVON

10.1 Where VIVON sits in the Web4 stack

LINKSPREED describes Web4 as a seven-layer stack:

Layer	Name	Role
1	UIID	Universal Integrated Identity Decoupled
2	VIVON	Physical Web4 mobile access
3	ARCTIC	Decentralized compute backbone
4	HELION	Intelligent network routing
5	TRIVE	Free and unlimited SaaS
6	ATRIUM	Super apps as a service
7	WYNIX	Smart consumer hardware

The company has also described submitting a seven-layer architecture paper and a reference implementation report that map these layers to concrete components.

VIVON is Layer 2, labelled “Physical Web4 Mobile Access” and “powered by UIID”. LINKSPREED describes it as the layer that connects a decentralized internet to the real world: it provides global eSIM data, shields connection metadata from ISP tracking and decouples a phone connection from traditional telecom gatekeepers. Another description calls it the physical bridge connecting sovereign identity to radio towers and mobile data networks.

The placement is logical. Software-level identity is only as private as the connection that carries it. If the SIM, the IP address and the phone number still point to a customer record, an identity layer above them is partly undermined. Layer 2 exists to close that gap.

10.2 Three promises: chat, call, connect

The Web4 materials summarise VIVON in three lines:

Chat with VIVON on UIID infrastructure as if it were SMS.
Call IDs as if they were phone numbers, without phone numbers.
Connect to Web4 via eSIMs from anywhere in any country.

Each of these maps to one of the three layers we looked at earlier. Chat replaces the messaging layer. Call replaces the voice layer. Connect replaces the access and SIM layers.

10.3 Calls: identity-addressed and peer-to-peer

The calling model is the most technically interesting part, and LINKSPREED has published material on it. The company describes VIVON calls as direct device-to-device voice and video, using UIID cryptographic addressing instead of phone numbers.

The connection model, as described, combines three things we already know from Part Four:

Identity-based signalling. Instead of looking up a phone number in a carrier’s registrar, a call is addressed to a UIID identity.
ICE and STUN hole punching. The two devices try to find a direct path through their NATs.
A Web4 TURN fallback layer. Where a direct path is impossible, such as with symmetric NAT, corporate firewalls or strict mobile carriers, a relay layer carries the call. LINKSPREED states this keeps calls connected on restrictive networks without compromising end-to-end privacy.

LINKSPREED’s own framing of the problem is the same one this article has described: peer-to-peer calling is better for speed and privacy, so the reason not every app uses it is NAT.

Here is what this means in practice, compared with the carrier VoIP model from Section 6.5.

Question	Carrier VoLTE call	VIVON call, as described
How is the other person addressed?	Phone number	UIID identity
Who registers the device?	The carrier’s IMS	The identity layer (UIID)
Where does media travel?	Through the carrier’s network	Direct between devices where possible, via a relay when not
Why is a relay needed?	Not an issue inside one carrier	NAT, CGNAT and restrictive networks
What does the relay see?	Not applicable	Encrypted traffic, not content
Is a number involved?	Yes	No

The honest framing is that this is not magic. It is the standard ICE, STUN and TURN toolkit applied to a different addressing and identity model. The new part is the addressing. Because the callee is a cryptographic identity and not a number in a carrier’s database, there is no number to intercept through SS7, no number to swap onto another SIM, and no phone-number-to-name mapping to leak.

10.4 Messages: SMS behaviour without SMS

The “chat as if it were SMS” promise describes a user experience: a short message to a recipient, addressed to an identity, working without a phone number. The important point is what it removes. SMS travels through the signalling systems that Section 6.1 showed to be open to interception and rerouting. A message addressed to a UIID identity and carried over VIVON does not use that path.

There is a side effect that is easy to overlook. Because UIID supports Aliases, a person could in principle use a different identity for a different context, such as one for a bank and one for a community, without handing out a number that links them. That is a property of UIID’s architecture. With a phone number this is hard, because a number is one stable identifier shared with everyone who has it.

The sealed-sender discussion in Section 6.7 sets the bar for how far metadata protection can go. How VIVON handles who learns that a message was sent is a detail worth watching once it is documented.

10.5 Connections: borderless eSIMs and metadata shielding

This is the physical layer. LINKSPREED’s published descriptions give three aims:

Borderless eSIMs. Users can chat, call and browse without relying on country-locked contracts. The eSIM is the delivery mechanism, using the same Remote SIM Provisioning flow described in Section 3.3.
Metadata shielding. VIVON is described as providing advanced routing protocols that mask traffic patterns and prevent tracking by traditional internet service providers.
Independence from regional gatekeepers. The material also refers to bypassing regional censorship.

The target audience named in the material is international professionals and privacy advocates who need secure, private access across borders without relying on standard roaming.

10.6 An illustration: a day with VIVON

To make the design concrete, here is an illustrative walk-through. It shows how the pieces are meant to fit together. It is not a product specification.

Before travel. A user holds a UIID Core ID, stored on their phone and unlocked with biometrics. There is no account and no password.
Arrival. The user lands in another country. Instead of buying a local SIM or paying roaming fees, the phone installs an eSIM profile through the standard download flow. The user is online within minutes.
Access. The connection is the physical link. Traffic patterns are shielded as described in LINKSPREED’s material, so the local provider has less to log and nothing tied to a phone-number identity.
A call. The user calls a colleague. The colleague appears as a UIID identity in the contact list. Signalling resolves the identity, ICE and STUN try a direct path, and the call connects. If the hotel network blocks direct traffic, the relay layer carries the encrypted call.
A message. The user sends a short message to a different contact under an Alias, so that contact cannot link it to the identity used with the colleague.
Verification. A service asks for proof that the user is over 18. A zero-knowledge proof answers yes or no. No document and no number are shared.
Leaving. The user removes the eSIM profile. The Core ID stays on the device and travels to the next trip.

The thread running through the story is that every step uses the same owned identity, and none of them requires handing over an identifier issued by a third party.

10.7 Side by side: today’s stack and the VIVON model

Function	Today	VIVON model, as described
Subscriber identity	IMSI on an operator-issued SIM or eSIM profile	UIID identity as the root
Address for calls and messages	Phone number	UIID cryptographic ID
Authentication	SIM challenge-response, SMS codes	Device-bound keys with biometrics and proofs
Voice signalling	SIP and IMS inside a carrier	Identity-based signalling
Media path	Through the carrier core	Peer-to-peer, relay fallback
Messaging	SMS over SS7, or an app’s servers	Messages on UIID infrastructure
Cross-border use	Roaming or local SIM, country-locked contracts	Borderless eSIM
Metadata	Visible to carrier and ISP	Shielded, per LINKSPREED’s description
Multiple identities	Multiple numbers or SIMs	Aliases under one Core ID

11. How the VIVON design maps to each threat

Returning to the threat model in Section 8, here is how the described design relates to each row. The third column is deliberately cautious, because a design on paper is not a measured result.

Threat	Design response, as described	What to verify
Phone number intercepted over SS7	No phone number in ID-to-ID calls and messages	Whether any fallback to numbers exists, and how it is protected
SIM swap	Identity bound to device keys and biometrics, not to a number	How recovery works if a device is lost
ISP logs and DNS records	Metadata shielding and traffic masking	What exactly is masked, and who operates the shielding layer
A signalling server learning who calls whom	Identity-based signalling	What the signalling layer can observe, and how it is distributed
A relay seeing traffic	Encrypted media over a Web4 TURN fallback	How many independent relays, and what they log
Cross-border lock-in	Borderless eSIM	Which underlying networks supply the connectivity
Cross-context correlation	Aliases under one Core ID	Whether aliases are unlinkable at the network layer too
IMSI catching and radio tracking	Not something an app can remove on its own	Which radio identity is exposed, and what it is linked to

The last row is the important one for honesty. Software above the radio layer can reduce what is linked to a radio identity. It cannot make the radio link itself disappear.

12. Who this is for: seven scenarios

12.1 The frequent traveller

A person who crosses borders every few weeks pays for roaming or collects local SIMs. A borderless eSIM tied to an identity they already hold addresses the cost and the friction. The material names international professionals as a target audience.

12.2 The privacy-minded individual

Someone who does not want a stable phone number linked to every account and every contact is currently limited to buying extra SIMs. Aliases under one Core ID give a different way to separate contexts.

12.3 Journalists, researchers and activists

For people whose contacts are sensitive, the question of who learns that a call took place can matter as much as what was said. The lesson from sealed sender is that protecting that metadata is an engineering choice. Such users also have the most to lose from design gaps, so they should apply the checklist in Section 15 most strictly.

12.4 Remote teams and small businesses

A team spread across countries could in principle give each member an identity-based address that works the same everywhere, instead of a mix of national numbers. This is also a natural fit with UIID’s support for organizations as an entity type.

12.5 Families and shared devices

A family travelling together needs simple, predictable connectivity. Here the value is convenience: one identity model, no per-country contracts.

12.6 AI agents and machines

UIID v2.8 gives agents their own verifiable identities and replaces static keys with dynamic tokens. An identity-addressed communications layer is a natural place for agents to reach humans and each other without a phone number. Verified agents that can call, message and connect under their own identity are a direction LINKSPREED is clearly building towards. This is also where the abuse question in Section 14.7 becomes sharp, since agents can generate traffic at scale.

12.7 IoT and devices

SGP.32 shows that the industry is making eSIM work for devices without screens. Whether VIVON addresses devices is not something we can conclude from the published material, but the entity model in UIID, which includes hardware devices, points in that direction.

13. How VIVON compares with other approaches

Aspect	Traditional carrier	Travel eSIM	Messaging app	VPN	VIVON (stated design)
Identifier	Phone number	Often none (data-only) or a foreign number	Usually a phone number	Account with the VPN provider	UIID ID
Who issues it	Operator	Reseller or operator	The app, tied to a number	The VPN provider	The user
Works across borders	With roaming fees	Yes, for data	Yes, over data	Yes, over any connection	Yes, via borderless eSIM
Hides destinations from the ISP	No	No	Not by itself	Yes, from the ISP	Metadata shielding, as described
Call path	Carrier core	Not applicable for data-only	App servers or P2P	Not applicable	P2P with relay fallback
Exposed to SS7 risks	Yes	For voice and SMS, yes	Not for in-app messages	Not applicable	Not for ID-to-ID traffic
Identity ownership	Operator	Operator or reseller	Platform	Provider	User
Provides the connection itself	Yes	Yes	No	No	Yes, via eSIM

Two points are worth drawing out. First, a VPN and VIVON are not the same thing. A VPN protects traffic on a connection that someone else issued. VIVON is described as a connection and an address system together. Second, a VPN moves the point of trust from the ISP to the VPN provider, which is the same “trust moves” pattern we saw with ECH. Any design that shields metadata has to say clearly who the new party is.

The table uses cautious wording for the VIVON column, because it describes the design as published. Measurable results will come from the launch.

14. The honest part: what is hard

A deep dive that only lists strengths would not be useful. These are the questions that a system like VIVON will be judged on, and the ones we want users to ask.

A device connecting to a mobile network has to attach to a tower, and the network needs to know a device is there to deliver data to it. Section 4 showed that even 5G’s improvements are optional and deployment-dependent. Metadata shielding can reduce what is visible above the radio layer, such as which services are used and who talks to whom. It cannot make the radio link itself invisible. How much is shielded, and against whom, is the key technical question.

14.2 Who issues the eSIM profile

An eSIM profile is delivered by an SM-DP+ and belongs to an operator relationship. Someone has to provide the underlying network capacity. The privacy benefit of a borderless eSIM therefore depends on how that relationship is structured, and how much it reveals about the user. If a profile is bought with a payment method tied to a name, the shielding above it has less to hide behind. This is a detail to evaluate once it is documented.

14.3 Emergency calls and the old world

As Section 6.8 explained, emergency access is a regulated function. Reaching 112 or 110 with caller location is not optional for services that connect to the national numbering plan. The EU is actively working on how emergency communications work over packet-switched networks and apps. An ID-to-ID service that does not touch the numbering plan sits in a different regulatory position than one that does. Either way, users should be told clearly what happens when they dial an emergency number. Bridging to the phone network and handling emergency calling are real regulatory and engineering topics, and every VoIP service has had to do careful work here.

14.4 Relays, signalling and what they learn

As Section 6.6 showed, even peer-to-peer systems need signalling and sometimes relays. The privacy of such a system rests on how little those components learn and how well they are decentralized. The Web4 TURN layer and the identity-based signalling are the places to scrutinise. The questions are simple: who operates them, how many independent operators there are, what is logged and for how long.

14.5 Metadata still exists somewhere

Sealed sender shows that even a mature, well-respected design leaves residue: the server still knows the recipient, and timing correlation is possible in principle. The honest claim for any system is “less metadata, held by fewer parties, for less time”, not “no metadata”.

14.6 Network effects

Phone numbers work because everyone has one. An identity-addressed network starts small. Its value depends on adoption, which is why bridging from existing logins, messaging and community tools matters so much. Until a contact also uses the system, a call to an ID has no one to reach.

14.7 Abuse and spam

Phone numbers are cheap to obtain in bulk, and spam and fraud calls are a well-known problem. An identity-addressed system faces the same issue in a different form. LINKSPREED’s answer rests on hardware-anchored, biometric enrolment making mass fake identities impractical. Whether that holds at scale is something only real use will show. The sealed-sender experience adds a practical lesson: if a system hides the sender from the server, it needs a separate mechanism, such as delivery tokens, to keep floods out. This question gets sharper once autonomous agents can place calls and send messages.

14.8 Lost devices and recovery

If identity is bound to device keys and biometrics, the user’s central question is what happens when the device is lost. Passkey migrations have shown that the support burden does not disappear but moves, from “I did not get the code” to “I lost the device”, which is the harder problem. A connectivity layer built on the same identity inherits the question. It deserves a clear answer before launch.

14.9 Platform dependence

VIVON and UIID are announced for release on the Google Play Store. Mobile platforms control what an app can do with the network stack and with eSIM management. That is a boundary every independent project has to work within, and users should expect the feature set to depend on the operating system and device.

14.10 Law and lawful access

Operators of connectivity services are subject to national laws, including those on retention and lawful access. As Section 5.5 showed, these rules are contested and change over time. A design that retains less is exposed to less of that, but the service has to be transparent about what it retains and where.

14.11 Trust in the identity layer itself

VIVON inherits the properties and the risks of UIID. UIID’s own documentation of cryptography, audits and governance is therefore part of VIVON’s trust story. Independent review is the normal route to credibility for any privacy system.

None of these are reasons to dismiss the approach. They are reasons to measure it carefully. A privacy system earns trust by being specific about what it protects and what it does not.

15. Twelve questions to ask any private connectivity provider

These questions apply to VIVON and to every competitor that makes comparable claims. We think a good provider welcomes them.

What identifier does the network see for my device, and is it linked to my name?
Who issues the eSIM profile, and what do they know about me?
Which underlying networks carry my traffic, and in which countries?
What exactly is shielded: DNS, destinations, timing, volume?
Who operates the shielding, signalling and relay components, and how many independent operators are there?
What is logged, for how long, and what happens on a legal request?
Does any part of the service fall back to phone numbers or SMS?
How do emergency calls work, and what happens to my location?
How does recovery work if I lose my device?
How is spam and abuse prevented without reading my traffic?
Is there independent review of the cryptography and the architecture?
What works outside the app, and what depends on a specific operating system?

A provider that answers these in specific, checkable terms is easier to trust than one that answers in slogans.

16. Why this matters for Web4

LINKSPREED’s broader argument is that the internet’s addressing has always been an afterthought. IP addresses identify network locations, not people, and phone numbers identify subscriptions, not people. The company’s recent explainers frame this as identity becoming the addressing layer, an internet addressed by identity instead of IP routing.

In that stack, VIVON is the part that touches the physical world. UIID answers who someone is. VIVON gets that identity onto a radio network and into a phone call. The layers above it, such as HELION for routing and ATRIUM for community apps, build on both. A communications layer that starts from an owned identity is also a precondition for something LINKSPREED is increasingly building towards: verified humans and verified AI agents that can reach each other without a phone number in between.

The bet is simple to state and hard to execute. If the trust anchor of online life moves from a number you can receive a code on to a key your device holds, as the SMS phase-out suggests it will, then the address, the connection and the call should move with it. That is what Layer 2 is for.

17. How to get started

Claim a free UIID Core ID at uiid.me.
The UIID app is listed on Google Play as a biometric-secured digital passport and wallet for Web4.
Follow VIVON at vivon.linkspreed.com for launch news.
Read the Web4 architecture at web4.one.
Use the checklist in Section 15 on any provider you consider, including ours.

18. FAQ

Is an eSIM more private than a physical SIM? Not by itself. It changes how a profile is delivered, not who owns the identity. The profile is still an operator’s.

Why do some eSIMs have no phone number? Many travel eSIMs are data-only, so they do not support inbound calls, SMS or SMS verification codes.

Is a call over the internet automatically private? No. Encryption protects content. Signalling and relays can still reveal who called whom and when.

What is the difference between STUN and TURN? STUN lets a device discover its public address so two peers can try to connect directly. TURN relays the traffic when that fails.

Does 5G fix IMSI catchers? It can, where SUCI is enabled with a non-null scheme on a standalone 5G network. In non-standalone deployments the LTE anchor can still expose the IMSI.

Does HTTPS hide which sites I visit from my ISP? It hides the content. The destination hostname can still be visible through SNI and DNS unless ECH and encrypted DNS are in use.

Why is my phone’s IP address shared with so many people? Carrier-grade NAT places many subscribers behind one public IPv4 address.

Is SMS still safe for two-factor codes? It is being phased out. NIST’s guidance no longer counts it for the practical baseline of many regulated uses, and passkeys are the recommended replacement.

Does VIVON need a phone number? According to LINKSPREED, no. Calls are addressed to UIID identities instead of phone numbers.

Can VIVON hide the fact that my phone is on a mobile network? No software can fully hide a radio attachment. The aim is to limit what is linked to it. See Sections 4 and 14.1.

What about emergency calls? This is a regulated function and a question to ask any provider. See Sections 6.8 and 14.3.

When does VIVON launch? It is described as coming to Google Play together with the UIID app. Watch vivon.linkspreed.com for the date.

19. Glossary

eUICC: the secure chip that holds eSIM profiles.
eSIM profile: an operator’s credentials, downloaded into the eUICC.
iSIM: a SIM function integrated into the main processor.
SM-DP+ / SM-DS / LPA: the profile server, the discovery service and the on-device manager in the consumer eSIM standard.
SGP.22 / SGP.32: the GSMA specifications for consumer and IoT remote SIM provisioning.
IMSI: the identifier of a subscription on a mobile network.
IMSI catcher: a fake tower that collects subscriber identifiers.
SUPI / SUCI / GUTI: the 5G permanent identifier, its concealed form and the temporary identifier.
SS7: the legacy signalling system for voice and SMS between operators.
SIM swap: moving a number to a SIM controlled by an attacker.
SIP / RTP / SDP: signalling, media transport and session description in VoIP.
IMS: the carrier core used for VoLTE and VoNR.
NAT / CGNAT: address translation, and its large-scale version run by providers.
ICE / STUN / TURN: the toolkit WebRTC uses to find a path between peers.
SNI / ECH: the plaintext hostname in the TLS handshake, and the standard that encrypts it.
Sealed sender: a messaging design in which the server does not learn who sent a message.
Passkey: a phishing-resistant credential based on WebAuthn.
UIID: Universal Integrated Identity Decoupled, LINKSPREED’s identity layer.
Core ID and Alias: the master identity and its context-specific, unlinkable identities.
VIVON: Layer 2 of the Web4 stack, for physical mobile access.