How internet control moved from blocklists to allowlists, why today's circumvention tools struggle with that shift, and a design sketch that combines local AI agents, sharded relay discovery, and a thin web3 coordination layer.
1. Introduction: When the Internet Becomes a Privilege
For a long time, the mental model of internet censorship was a blocklist. An authority decided that certain domains, IP addresses, or keywords were forbidden, and the network enforced it. Everything else worked. Circumvention was a race: find a path the list did not cover.
That model is eroding. In 2025 and 2026, several things happened at once:
- In Russia, mobile internet shutdowns became routine, and during them only a short list of approved services stayed reachable. Global Voices reported that on 27 September 2025, shutdowns were recorded in 54 regions and whitelists of available sites were active in 30 of them.
- In Iran, a nationwide shutdown began on 8 January 2026, and a second one followed from 28 February. Monitors described the second as the longest nationwide blackout on record, with fewer than one percent of users able to connect at one point. When access was partially restored in late May, Iran International reported that it came after nearly three months of blackout and remained heavily filtered.
- In China, a leak of internal documents from a Great Firewall vendor showed that the same technology had been deployed outside China, in countries including Ethiopia, Pakistan, Myanmar, and Kazakhstan.
This article does two things. First, it gives a unified technical picture of how modern network control works, drawing on published measurement research and reporting, so that readers who are not specialists in this field can see the whole system. Second, it proposes a design direction, built from existing research, that tries to answer a specific question: what would a circumvention network look like if it assumed that allowlists, per-ISP differences, and AI-assisted blocking are the normal case?
A note on scope. Iran, China, Russia, and North Korea are used here as points on a spectrum rather than as targets of an indictment. Iran is a particularly instructive hybrid, because its infrastructure draws on both Chinese and Russian technology (more on that below). The focus is technical: how the systems work, where current tools fail, and what might do better.
Nothing in this article is a finished invention. Most building blocks come from published research. The contribution, if there is one, is the composition, and an honest list of what remains unsolved.
This design also sits in the decentralized-AI stack. The agent runs small models on the user’s device (edge inference) rather than calling a central inference API, route intelligence is shared through a ledger with no single operator, and the aim is an AI-assisted network that is hard for any single party to switch off.
2. Four Eras of Network Control
The shift can be summarized in four overlapping eras. This is a simplification, since all four coexist in different places, but it is a useful frame.
| Era | Model | Typical techniques | Example evidence |
|---|---|---|---|
| 1. Blocklist | Everything works except listed targets | DNS poisoning, IP blocking, HTTP blockpages | OONI's 2014–2017 Iran measurements found DNS injection and transparent proxies serving blockpages, with circumvention-tool sites themselves blocked and Tor blocked on many networks |
| 2. DPI and traffic classification | Inspect traffic and block what looks suspicious | Protocol fingerprinting, SNI inspection, active probing | The Great Firewall's passive detection of fully encrypted traffic (first reported in November 2021); SNI-based QUIC blocking from April 2024; Russia's TSPU boxes |
| 3. Allowlist | Nothing works except listed targets | Blocked-by-default networks, approved-user tiers, whitelisted IP ranges | Russian mobile whitelists (2025); Iran's tiered access during the 2026 shutdowns |
| 4. Isolation | A domestic network is the default; the global internet is exceptional | National intranets, gateway control | North Korea's intranet model; analysts describe Iran's trajectory as a new stage of digital isolation |

The key observation is that each era is harder to circumvent than the last, for a different reason. Era 2 breaks tools that rely on looking like something else. Era 3 breaks tools that rely on being reachable at all, unless they can hide inside the allowed set.
3. Anatomy of Modern Censorship
3.1 The layers
A useful way to understand what a censor can see and do is to go layer by layer.
| Layer | What the censor controls or observes | What it breaks |
|---|---|---|
| Naming (DNS) | Resolver answers, injected responses | Lookups of blocked domains |
| Routing (IP, BGP) | Address-level blocks, route withdrawal | Reaching specific servers, or entire address families |
| Handshake metadata (TLS SNI, QUIC initial packets) | The destination name in the first packets | Reaching specific sites even when content is encrypted |
| Traffic shape (DPI) | Protocol fingerprints, packet sizes and timing, entropy-like heuristics | Known VPN and proxy protocols, and some unknown ones |
| Active probing | The censor connects to suspected proxies and tests them | Servers that answer probes like a proxy |
| Protocol allowlists | Only specific protocols or ports permitted | Anything that is not on the list |
| Economics | Differential pricing or quotas by destination | Practical use of international traffic |
| Endpoints and platforms | App stores, platform policies | Distribution of the tools themselves |
Two examples show how these layers interact.
- On the economic layer, an Iranian regulation made domestic traffic cheaper than international traffic. FilterWatch documents that the Communications Regulatory Authority's Regulation 266 (2017) splits traffic into domestic and international categories and prices domestic traffic well below international traffic, which makes international services and VPNs more expensive to use. This does not block anything, but it steers behavior.
- On the endpoint layer, Meduza reports that since 2022 Apple has removed dozens of VPN clients from the Russian App Store at Roskomnadzor's request, and that in late March 2026 the Digital Development Ministry told major platforms to block users with an active VPN or lose their place on the whitelist.
3.2 China: classification at scale
The Great Firewall (GFW) is the reference system. Research from Wu et al. (USENIX Security 2023) found that in early November 2021 the GFW deployed a technique that passively detects fully encrypted traffic, such as that produced by Shadowsocks, VMess, and obfs4. Rather than defining what fully encrypted traffic is, the censor applies crude heuristics (protocol fingerprints, the fraction of set bits, and the number and position of printable ASCII characters) to exempt traffic that is unlikely to be fully encrypted, then blocks the rest. The authors estimated that such rules could block roughly 0.6 percent of normal traffic as collateral damage. A key finding is that randomness itself became a signal. The study's artifact repository also records that the GFW had stopped this dynamic blocking at least since 15 March 2023, a reminder that these systems change on their own schedule.
In 2024 the GFW began another capability. Zohaib et al. (USENIX Security 2025) report that since 7 April 2024 it blocks QUIC connections to specific domains, even though QUIC handshakes are encrypted, by decrypting QUIC initial packets at scale. The Register's summary notes the system cannot block all QUIC traffic and that its success rate fluctuates by time of day, and UMass researchers explain that the computational burden of inspecting those packets can overwhelm the system under modest load. The lesson for designers is that censors have capacity limits and collateral costs. (Such limits are not an invitation to attack national infrastructure: doing so would also harm ordinary users.)
3.3 Russia: decentralized deployment, centralized control
Russia's approach is built on a different architecture. A 2019 law required operators to install DPI equipment. Measurement research on TSPU (IMC 2022) found that the boxes are deployed close to users while remaining centrally controlled. An earlier NDSS 2020 study found significant differences in the type and amount of blocking between ISPs.
Since then, the system has moved toward allowlisting. Global Voices describes whitelists applied during mobile shutdowns in 2025, and the Moscow Times quoted a ministry source describing shutdowns in Moscow as a test of the ability to block sites not on the whitelist.
3.4 Iran: a hybrid with a single choke point
Iran's system combines elements of both. A FOCI 2020 study documented a protocol whitelister that permitted only a small set of protocols (DNS, HTTP, HTTPS). More recent measurement work, IRBlock (USENIX Security 2025), finds that Iran's blocking strategies resemble the GFW's in many respects. A 2025 preprint describes a "stealth blackout" in which global routing appeared intact while users were isolated through DPI and protocol-based filtering, which is exactly the pattern that makes outage dashboards misleading.
The January 2026 shutdown is documented in unusual technical detail. FilterWatch's report, built on IODA, Kentik, and Cloudflare Radar data, describes a phased operation. In the days before 8 January, interference showed up as "zombie connections": devices looked connected at the IP layer while higher-layer performance was sabotaged, and VPNs showed "connected" but passed no data. On 8 January, 98.5 percent of Iranian IPv6 address space was withdrawn hours before the full cut, which the report interprets as herding traffic onto IPv4 infrastructure where inspection tools are more mature. Connectivity then fell to under 1 percent of normal. Restoration followed a blocked-by-default pattern in which services such as Google Search returned while the wider internet stayed dark, and, as an Iranian digital-rights researcher told Global Voices, whitelisting was enforced at the infrastructure level and not only at the service level. Its February 28 investigation describes "white" SIM cards and tiered pricing for international traffic. Iran International describes a related scheme branded "Internet Pro," in which access is organized around approved users and services.
3.5 North Korea: the end of the spectrum
North Korea represents what the fourth era looks like when it is complete. Pscore describes an internet subordinate to the domestic Kwangmyong intranet, with the global network available only to a small number of monitored users, and the Committee to Protect Journalists notes that mobile subscribers cannot reach content from outside the country. The relevant point for designers is not the details but the existence of the endpoint: a network where "which sites are blocked" is the wrong question.
4. Censorship as a Product
4.1 Technology flows between systems
Censorship infrastructure is increasingly a commercial product. In September 2025, more than 500 GB of source code, work logs, and internal documents from Geedge Networks and a related Chinese Academy of Sciences lab leaked. Tom's Hardware and the Jamestown Foundation describe deployments in Ethiopia, Pakistan, Myanmar, and Kazakhstan, as well as Chinese provinces such as Xinjiang and Fujian. The data suggest that a censorship system can now be bought, configured, and operated by an ISP without building it from scratch.
Iran shows the same thing from the other side. ARTICLE 19 documents Chinese support for Iran's infrastructure over more than a decade, including equipment from ZTE, Huawei, Tiandy, and Hikvision. On the Russian side, Global Voices recounts Citizen Lab's 2023 finding that Protei, a company with Russian roots, was selected to provide core network components, including DPI, to the Iranian mobile operator Ariantel, and notes Foreign Policy's reporting of Russian help in building Iran's control architecture. The same article is explicit that it remains unclear exactly what Protei supplied.
For designers, the implication is simple: the problem will not stay local. Techniques that are developed against one system will meet its commercial relatives elsewhere, which is an argument for designs based on principles rather than on tricks for one country.
4.2 A brief case: namespace control
One recent episode illustrates how network control reaches the naming layer. On 28 October 2026, Iran’s cybersecurity authority Afta urged organizations to migrate from foreign domains to .ir, citing the risk of sanctions-driven domain suspension. This shifts the threat model. For a platform hosted abroad on a foreign domain, the state’s main lever is blocking at the network level, and the site may remain reachable through circumvention. A domain under a domestic registry, by contrast, places namespace-level control with the state.
4.3 What the 2026 shutdowns added
Two further details from the 2026 shutdowns matter for what follows. First, circumvention was itself targeted. Chatham House reports that Starlink use is criminalized, with penalties of up to two years, and that the state reportedly uses jamming. Second, the shutdown decision was described as a security-institution decision: Iran International quoted a government spokesperson saying that security policymakers had decided the national network had to be cut and that the government could not override that decision. For design purposes, this means the people operating in-country infrastructure are a compliance point, and a design that depends on their cooperation is fragile.
5. Why Today's Tools Fall Short
Existing tools such as Tor with Snowflake, Psiphon, Lantern, and a long list of VPN protocols have done real work. This section is not a critique of them. It is a catalogue of the pressures that no single tool handles well.

5.1 Blocks differ by ISP and change over time
A circumvention method that works on one ISP today may fail on another, and may fail on the first tomorrow. There is evidence at several levels:
- OONI's Iran measurements concluded that censorship there was non-deterministic: many observations flipped between blocked and unblocked over time.
- The NDSS 2020 Russia study and the IMC 2022 TSPU study both found differences between ISPs.
- A recent study of refraction-based proxies in Iran, as summarized by a research corpus (the primary paper is Alaraj et al., ACM AsiaCCS 2025), reports that different Iranian ISPs used different techniques, with packet injection at one large ISP, IP-based blocking at another, and little or no proxy blocking at some others.
A design that treats the censor as a single adversary will be wrong on at least some networks. Each ISP should be treated as an independent adversary.
5.2 Hiding in the allowlist works, until it doesn't
When only approved destinations are reachable, one tactic is to tunnel through approved IP ranges. Community reports on the net4people forum describe exactly this in Russia, and also describe a crackdown in January 2026 in which Roskomnadzor reportedly demanded that cloud providers separate the address pools used for whitelisting from those used for other customers. In March and April 2026, as noted above, whitelisted platforms were told to block VPN users. A related failure mode is worth naming: in Iran, circumvention developers reported a "no-ping" pattern in which a VPN shows as connected but cannot pass data (see the FilterWatch report above). A tool that only checks whether a handshake succeeded will mislead its user. The pattern is the allowlist era's version of the old arms race: every trick that rides on collateral dependency invites a countermeasure that raises the cost of that dependency.
5.3 Censors use AI too
Russia's arms race is not one-sided in tooling. TechRadar, citing Forbes Russia, reports that Roskomnadzor was set to allocate about 2.27 billion rubles to build an AI-powered traffic-filtering mechanism aimed at prohibited content and VPN connections. This is a secondary report and should be treated with care, but the direction is plausible: classification is a natural fit for machine learning, and any circumvention approach should assume it.
5.4 Satellites can be jammed and punished
Direct-to-satellite connectivity avoids the national network, but Chatham House reports that its use is criminalized in Iran and that jamming has been reported. It is a valuable tool but not a universal answer.
5.5 Mesh networking works, but few can use it
Mesh messengers deserve a short note. The Electronic Frontier Foundation's guide to circumventing shutdowns says apps such as Briar are hard for most people to use and rarely installed, while Bitchat saw some success in Iran. A Bloomsbury Intelligence and Security Institute report notes the claimed range of around 300 meters, which fits dense gatherings rather than cities, and calls the technology immature. Mesh does answer a real need in a total shutdown, but it requires nearby participants, preinstallation, and some technical comfort. For the average user, that is a high bar.
5.6 Decentralized naming and storage: great in principle, awkward in practice
It is tempting to say that blockchain naming and content-addressed storage (ENS, IPFS) solve the namespace-control problem. They help in principle, since no registry can seize a name that no registry owns. In practice, three problems appear:
- Usability and cost. Registering and managing a name means wallets, keys, and fees. The ordinary user, who wants to bypass a block, is unlikely to take on that overhead.
- Reachability. Content-addressed networks still need entry points. A 2023 study from HIIG found that HTTP gateways to IPFS are not systematically blocked, but that only about a third of them function from a vantage point in China compared with Germany. The same study found that the GFW had little measurable impact on peer-to-peer functionality, where NAT was the main obstacle, which suggests the picture is mixed rather than uniformly bad.
- Network-level attacks. A 2025 preprint on network-level censorship of IPFS simulated BGP-based attacks and found that only a small fraction of content identifiers (roughly 0.5 to 8 percent) can be blocked from all requesters, but that a single malicious network could block more than 75 percent of the sampled content for more than 57 percent of requesters. Its authors add that where an adversary controls the paths to all requesters, as a state can inside its own borders, IPFS offers no direct protection, and users would need proxies or secure tunnels.
The conclusion for design is that web3 components should be invisible to the end user. They can help operators coordinate, but they cannot be the thing the user has to understand.
5.7 Summary of pressures
Putting this together, a modern circumvention system must cope with:
- per-ISP and time-varying blocking,
- allowlists that punish collateral hiding,
- AI-assisted classification on the censor's side,
- unreliable or dangerous side channels (satellite, jamming),
- user experience that does not demand technical expertise.
6. What the Research Already Shows
Before proposing anything, it is worth stating what the literature supports. These are the design principles the rest of the article leans on.
Diversity beats mimicry. The GFW findings above show that being random is itself detectable, and the parrot-style approach of imitating another protocol tends to fail when imitation is imperfect. The robust alternative is not one clever disguise but many options, chosen according to what works.
Cheap, ephemeral endpoints. Snowflake uses temporary WebRTC proxies run by volunteers, which makes it hard to enumerate and block by address, since proxies come and go.
Hide in collateral, carefully. Conjure uses unused address space belonging to cooperating ISPs (refraction networking), so that a censor who wants to block proxies has to block address space that might hold legitimate services.
Automate strategy discovery. Geneva uses a genetic algorithm to evolve packet-manipulation strategies, and it discovered strategies effective against censors in China, India, and Kazakhstan. A follow-up, Come as You Are, found strategies applied only on the server side, helping unmodified clients, and tested against censors including Iran's at the time. These results are from 2019 and 2020 and say nothing definitive about today's systems, but they establish that strategy search can be automated and that evasion does not have to be client-only.
Distribute access with care. Lox is a bridge distribution system that combines trust levels, invitations, open entry for new users, and anonymous credentials so that the social graph of inviters stays private. Its design goal is that a censor cannot enumerate bridges just by joining. The authors also identify a scaling concern: the cost of the blockage-check protocol grows with the number of blocked bridges, which a patient censor could exploit to disrupt migrations during a critical event. Note that Lox, as published, relies on a single central authority that issues and verifies credentials, and the authors present it as a proof of concept with demonstrative parameters.
Censors have limits. As shown in Section 3.2, inspection costs compute. This is a design observation, not an attack recommendation.
7. The New Constraint: Agents and Bandwidth
Many readers will be thinking: if strategy search can be automated, why not let AI agents manage the whole thing? There is real momentum behind that idea in enterprise networks. A Cisco and Omdia survey of 1,000 IT and network operations leaders found 84% expect an AI-led operating model within 12 months, though 56% still prefer a human to approve actions before an AI takes them and 24% favor full autonomy.
But agents bring a cost that matters here. Cisco's 2026 report AI Impact on Wide Area Networks, summarized by SDxCentral, finds that an AI agent generates about 450 percent more traffic for a task than a human doing the same task, with roughly 70 percent of that traffic being inference. The report projects enterprise traffic growing about nine-fold by 2035 with widespread agent adoption, compared with about 2.5-fold without, and AI inference reaching about a quarter of total traffic.

Two cautions apply. These are vendor-produced figures for enterprise WANs, and an analyst commentary notes that the headline multiplier is not a general estimate for all agent tasks. And the traffic cited is mostly agents talking to models, not agents configuring networks. Still, the direction of the lesson is clear and it transfers to censored networks, where it bites harder:
- Bandwidth is scarce and metered.
- Unusual traffic patterns, such as large, regular flows to inference endpoints, are themselves a fingerprint.
- Every round trip to a remote model is a chance for a censor to block, delay, or observe.
This gives a set of design rules that the next section follows:
- No inference in the data path. The agent must never sit between the user and their traffic.
- Keep models local and small. Decisions about which transport to try should happen on the device, with no remote model call.
- Share summaries, not streams. Whatever the network learns collectively should be compact enough to fit in a few hundred bytes per update.
- Budget the control plane. Treat control traffic as a scarce resource with a stated cap.
8. A Design Sketch
This section describes a hypothesis, not a tested system. It assembles known components into an architecture aimed at the pressures in Section 5.
8.1 Goals and non-goals
Goals
- Keep working when blocks differ by ISP and change over time.
- Avoid static endpoints that a censor can list.
- Keep the control plane tiny.
- Give ordinary users a one-tap, VPN-like experience, without wallets, keys, or nearby peers.
- Avoid a single point of seizure.
Non-goals
- Surviving a complete physical cut of international links.
- Guaranteeing anonymity against a global adversary.
- Offering any offensive capability against censorship infrastructure.
8.2 Overview
Architecture overview: a local agent, VPN app, transport pool and anonymous credential on the user's device; sticky relay shards on the operator side; and a thin coordination layer with an on-chain registry and a findings ledger. The data path never touches the chain.

In short:
- Local agent. Chooses transports per network and interprets failures, on the device, and only when needed.
- Transport pool. A diverse set of ways to reach a relay (Snowflake-style proxies, refraction, other protocols).
- Sharded rendezvous. Gives each user a small, persistent set of relays that changes only when the shard is blocked (Lox-style buckets, trust levels, anonymous credentials).
- Thin web3 layer. Operator identity, bonds, reputation, public randomness, and the findings ledger. Users never touch it.
- Route-intelligence API. Lets any VPN app ask for a ranked list of working paths (Section 8.9).
- Degradation ladder. What happens when preferred paths fail (Section 8.7).
8.3 The local agent
The agent is a small program on the user's device. Its job is not to carry traffic, only to decide how to try. It is event-driven rather than always running (Section 8.9).
Where does AI actually help here? Honestly, a lot of the selection problem can be handled with classic online learning. The places where learned models earn their keep are:
- Failure interpretation: telling apart a reset, a timeout, a throttle, a block page, and the "connected but passes no data" pattern reported in Iran, since each implies a different next move. This is why the probe in the loop below must test real data transfer, not just a handshake.
- Strategy generation: proposing candidate evasion tweaks, as Geneva does, ideally computed offline or by a shared research process and shipped as compact updates, rather than evolved live on each phone.
- Summarization: compressing "what worked where" into tiny updates.
An illustrative control loop:
# Illustrative pseudocode, not a working implementation. def connect(network_class, transports, history): # network_class: coarse bucket derived locally, e.g. "mobile-ISP-A" ranked = rank(transports, history[network_class]) # simple bandit-style score for t in ranked: if probe(t, budget_bytes=2048): # tiny, rate-limited probe record(history, network_class, t, ok=True) return t record(history, network_class, t, ok=False) return degrade() # fall to the degradation ladder A back-of-envelope illustration of the control-plane budget (assumptions, not measurements): if the network tracks 50 transports across 20 coarse network classes with a 2-bit success bucket for each, a full status summary is 50 × 20 × 2 bits = 2,000 bits, or about 250 bytes. Even with metadata, that is orders of magnitude smaller than a single inference call. The point is to make the budget explicit and then enforce it.
8.4 Sharded rendezvous
The heart of the proposal is how users get relays. Two meanings of "sharding" are in play, and it is worth keeping them apart:
- Blockchain sharding partitions state and transaction processing across groups of validators to raise throughput.
- Relay sharding, as used here, partitions users and relays into groups so that any one user, and any censor posing as a user, sees only a small slice of the network.
The mechanism, in outline:
- Each client holds an anonymous credential with a trust level, as in Lox.
- On joining, the client is assigned to a sticky shard: a small, persistent set of relays, chosen using public randomness. The client keeps the same shard until it is blocked.
- If a shard is blocked, its clients migrate to a new shard. A client whose shards keep getting blocked loses privileges and is eventually evicted.
- A shard’s relays change only when relays retire or the shard is blocked. Epochs (for example, a day) govern key material and public randomness, not who sees which relays. Scheduled rotation of a shard’s relays would let a stationary infiltrator enumerate the pool over time, which is the same flaw as per-epoch reassignment.
An earlier version of this sketch re-assigned every client to a fresh shard each epoch. A toy simulation (Section 8.10) showed why that is a mistake: re-randomizing lets even a few quiet infiltrators see new relays every epoch and enumerate the whole pool over time. Persistent shards cap what any one identity can ever learn.
What this buys:
- Bounded enumeration per identity. A censor identity learns the relays in its shard, not the pool. Total exposure grows with the number of identities the censor can run, which is why admission control matters more than the partitioning itself.
- Blame localization. When a shard is blocked, only its few members are suspects, and repeat appearances in blocked shards separate infiltrators from honest co-members.
- Blast-radius limits. A blocked shard takes down only its members, who migrate, rather than the network.
- ISP heterogeneity. Different network classes can end up with different working subsets, and the agent's local history decides which transport to use against each.
- Parallel load spreading. Relays serve only their shard's users, so capacity can be managed by shard.
What it costs:
- Privacy leakage. If a network class is used when assigning or refreshing shards, it leaks coarse location. The classes must be coarse enough to be safe and fine enough to be useful, which is a trade-off that needs real measurement.
- Collateral and newcomers. Honest users who share a shard with an infiltrator lose service until they migrate. Trust tiers that expose new identities only to a small low-tier pool protect existing users but leave newcomers badly served during an attack (Section 8.10).
- Infiltration. Sybil attacks remain the central threat, which is why trust levels and slow reputation building are part of the design. Lox's own evaluation notes that a patient censor can try mass blockage at a critical moment.
- Poisoned summaries. If agents share "what works" data, a censor can try to inject false reports. Mitigations (thresholds, weighting by trust level, aggregation) are an open problem.
8.5 The thin web3 layer
A blockchain does not belong in the data path. Latency, cost, and transparency all count against it. What it can do well is small, slow-moving coordination:
- Operator identity and reputation. Registries for relay operators, using pseudonymous identities, bonds, and reputation. ERC-8004, a draft Ethereum standard for "trustless agents" that defines identity, reputation, and validation registries and keeps complex reputation aggregation off-chain, is a natural reference point. It was designed for AI agents rather than relays, so adapting it to operators would be an analogy that needs its own design work, and the standard is still a draft.
- Public randomness. Epoch seeds that nobody can bias.
- Capacity attestations. Signed, aggregated statements about relay capacity.
- Incentive accounting. Some way of rewarding operators.
Critically, users never interact with the chain. They see an app that connects. The earlier-discussed usability problem with wallets and naming is avoided by design. This also forces honest answers to hard questions:
- Operator endpoints must not be published on-chain, only commitments or pseudonymous handles, or the registry becomes the blocklist.
- The chain's own RPC endpoints can be blocked, so clients need out-of-band bootstrap, and the design should not rely on any single path to the ledger.
- Operators who receive payments may face sanctions and compliance exposure.
8.6 What Carries Over from Blockchain Sharding, and What Doesn't
Blockchain sharding has real deployments and also real lessons.
- Public descriptions of NEAR's Nightshade divide the chain into smaller "chunks," and MultiversX's adaptive state sharding adjusts the number of shards to demand.
- BNB Smart Chain is a useful contrast. It has pursued scaling through parallel EVM execution and a layer-2 (opBNB), and in October 2025 announced a Scalable DB architecture that plans state sharding at the database level. In other words, sharding is one route among several, and BSC's is about storage rather than consensus.
What transfers is the idea of partitioning to limit blast radius and parallelize load. What does not transfer is cross-shard consensus machinery, which this design avoids by keeping data paths off-chain and shard membership soft. The known cost of sharding, that smaller groups are easier to attack, appears here as the infiltration problem described above, and it should be stated plainly.
8.7 Graceful degradation
When preferred paths fail, the agent walks down a ladder rather than failing outright:
- Preferred transport to the assigned shard.
- Alternate transports from the pool.
- Delayed delivery: queue and send when a window opens (useful for messaging, not for browsing).
- Report the state honestly and stop, rather than leaving the user guessing.
Mesh and satellite appear only as complements, outside this design's scope.
8.8 A scenario
A user on ISP A can connect on Tuesday through one transport. On Wednesday, a block lands. The local agent sees repeated resets, classifies them as probable injection, and tries alternatives from its pool, using a few kilobytes at most. Meanwhile the same user's cousin on ISP B, where the block never appeared, keeps using the original. Neither user does anything technical, and neither sees a wallet. Both keep their shard until it is blocked. A censor operating a fake client sees only the relays in its own shard, and each identity it adds must earn trust slowly, so infiltration cannot scale quickly.
None of this has been tested in the field. The scenario shows the intended behavior, not a result.
8.9 Deployment model: route intelligence as a shared layer
The agent does not have to be a VPN. It can be a separate layer whose only product is a ranked list of paths that currently work on the user’s network, handed to a tunnel app that does the actual connecting. This is not a new pattern: the Outline SDK’s Smart Dialer already searches a configured set of strategies for one that unblocks DNS and TLS for a list of test domains, and its documentation notes that obtaining a Psiphon config may require a contract with the Psiphon team. The proposal here extends the idea with shared, sharded intelligence about what works where.
Two ways to ship it. The reference experience is the agent as a module inside the project's own VPN app. Third-party VPN apps can integrate the same layer through an API or SDK under agreed terms (the contractual and legal side is out of scope here). In both cases the interface is narrow: the agent returns ranked paths with parameters and a time-to-live, the VPN app connects, and the VPN app reports only success, failure, and coarse timing. The agent never sees user traffic.
An event-driven lifecycle, not continuous monitoring.
- First run, on the plain local connection: the agent builds a list of open paths from a candidate set shipped with the app and refreshed through the tunnel.
- Periodic light check: at jittered intervals (for example, about hourly), it re-tests only the paths on that list and replaces dead ones from the candidate pool.
- Hand-off: the VPN app connects through the best path. The agent stands down.
- Inside the tunnel: a short, low-priority sync uploads signed findings and downloads updates, so sharing never happens on the observable plain link.
- Wake-up triggers: tunnel failure (including the connected-but-no-data pattern), disconnection, or a return to the plain local network.
This keeps control-plane cost bursty and small, and it avoids a measurement problem: on Android, only one VPN connection can be active at a time, and probes sent while a tunnel is up would measure the tunnel rather than the underlying path. Measuring only when no tunnel is active sidesteps that. It does not shrink the data plane: carrying user traffic remains the VPN's job and cost. Platform limits matter, too. Android exposes network and VPN state changes to apps, while iOS gives far less background freedom, so on iOS the logic would likely live inside the VPN app's own lifecycle rather than a separate always-on app.
Guided discovery, not blind scanning. The agent should find new open paths by exploring a structured search space (fronting combinations, transport parameters, new relay candidates from its shard) with a per-run probe budget. Sweeping arbitrary third-party address space from a phone would be slow, noisy, and easy for a censor to flag.
Candidate confidentiality. Candidate lists can be distributed encrypted under per-epoch keys, with a memory-hard key-derivation step or a time-lock-style puzzle so that bulk decryption is costly. This hides lists at rest and in transit and raises the price of mass enumeration. It is not access control: a censor running a copy of the agent holds the same decryption capability as a real one, and a datacenter has far more compute than a mid-range phone. The real gate remains the trust-level credential from Section 8.4.
A shared findings ledger. Agents with credentials can sign reports of what worked on which network class. A permissioned ledger (for example, proof-of-authority, run by validators from diverse jurisdictions) can serve as an append-only log: commitments and small summaries on-chain, bulk data off-chain. A candidate is promoted only after confirmation by several independent agents from different network classes, and old confirmations decay. Two cautions apply. A small validator set is a coercion and seizure target, and a signed but malicious agent can still try to poison the log. If a chain is more than the problem needs, a Merkle-tree transparency log with signed gossip is the minimal alternative.

Permanent anchoring. One place where permanent storage fits is as a public anchor for the ledger's history. Arweave asks uploaders for a one-time, upfront contribution to a storage endowment, priced to cover roughly 200 years of replicated storage at present prices (Arweave documentation). A signed checkpoint of the ledger (a Merkle root plus validator signatures, a few kilobytes per day) can be written there by an operator outside the censored region, and the one-time fee for something that small should be modest; check the current price before relying on that. This does not stop validators from being coerced, but it makes silent rewriting of history detectable, and it gives researchers a durable archive of aggregated, anonymized results. It must not hold relay addresses, per-user reports, or credentials: data that can never be deleted would become a permanent enumeration list and a permanent record of who reported what. Nor is it a bootstrap path, since reads go through HTTP gateways that can be blocked like any other, so clients should fetch it through the tunnel.
8.10 What a toy simulation does and does not show
To check the central claims, I wrote two small simulations (code and results). They simulate a simplified model with assumed parameters. They are not measurements of any real network, and the numbers should be read as how the toy behaves, not as predictions.
Per-ISP transport selection. Six simulated ISPs block 12 transports independently and change over time. Averaged over 12 seeds, a client with one fixed transport failed to connect about 61 percent of the time. Random failover failed 7.6 percent and needed about 2.3 tries per connection. A single global ranking failed 2.6 percent. A per-ISP local agent failed 1.2 percent with 1.5 tries, and a...


