The Serverless Sovereign App: A White Paper on Embedded I2P as a Zero-Infrastructure Paradigm for Privacy-Native Mobile Applications
Authors: Techducat Limited
Version: 1.0
Date: April 2026
Status: Proposal
Abstract
This paper presents the architectural case for Embedded I2P — the practice of integrating an I2P (Invisible Internet Project) router directly inside a mobile application — as a foundational paradigm for the next generation of decentralised, privacy-native software. Drawing from the real-world implementation of the Verzus, Ajo, and Scrowit applications developed at Techducat Limited, we demonstrate that this approach eliminates server infrastructure costs, removes single points of failure, delivers strong anonymity guarantees, and enables the construction of full financial and social applications with zero ongoing hosting dependencies. We enumerate the technical, economic, operational, and ethical advantages of this model, address its limitations honestly, and propose it as a compelling alternative to conventional client-server and even conventional blockchain-based architectures for builders operating under constraints common to the Global South and privacy-sensitive domains.
Table of Contents
- Introduction
- The Problem with Conventional Architectures
- What is the Embedded I2P Paradigm?
- Core Architecture Overview
-
Advantages of the Paradigm
- 5.1 Zero Infrastructure Cost
- 5.2 Unconditional Privacy by Design
- 5.3 Censorship Resistance
- 5.4 Elimination of Single Points of Failure
- 5.5 No Registration, No KYC, No Identity Leakage
- 5.6 End-to-End Encrypted Transport as Default
- 5.7 DDoS Resistance by Architecture
- 5.8 Sovereign Data Ownership
- 5.9 Regulatory Resilience
- 5.10 Economic Inclusion for Builders in the Global South
- 5.11 Composability with Privacy Currencies
- 5.12 Permanence without Maintenance
- Real-World Instantiation: The Techducat Suite
- Honest Assessment of Limitations
- Comparison with Competing Paradigms
- Recommended Use Cases
- Security Considerations
- Conclusion
- References
1. Introduction
The dominant model for mobile application development in 2024 is, without exception, the client-server model: a thin application on a user's device that sends data to, and retrieves data from, a centralised server operated by its creator. This model is convenient for developers and familiar to users, but it carries a constellation of structural liabilities that are increasingly difficult to justify:
- The server is a permanent cost centre.
- The server is a target for state-level censorship.
- The server is a honeypot for user data.
- The server is a single point of failure.
- The server owner occupies a position of irrevocable trust over user activity.
Even "decentralised" alternatives — blockchain-based applications, federated protocols — typically retain at least one centralised chokepoint: a bootstrap node, an RPC provider, a smart contract deployer, a package registry.
The Embedded I2P paradigm, as developed and deployed in the Techducat application suite, takes a different position. It holds that a truly sovereign application can be built such that the network is the users — that every device running the application is simultaneously a client, a server, a router, and a peer. No one entity bootstraps the network. No one entity can shut it down. No one entity bears its cost except the individuals who derive value from it.
This white paper articulates the full case for this paradigm.
2. The Problem with Conventional Architectures
2.1 Centralised Client-Server
The classical web/mobile backend model concentrates risk at the server layer:
| Risk | Consequence |
|---|---|
| Server breach | All user data exposed simultaneously |
| Legal order | Operator compelled to surveil or shut down |
| Financial failure | Application disappears when billing stops |
| Scaling failure | Service degrades under load |
| Geoblocking | Users in disfavoured jurisdictions cut off |
| Domain seizure | Traffic flow severed at DNS layer |
Cloud providers (AWS, GCP, Azure) reduce operational burden but amplify these risks by concentrating infrastructure across millions of applications into a handful of providers subject to a single jurisdiction's legal reach.
2.2 Federated Models (ActivityPub, Matrix)
Federated models improve resilience but still depend on individual operators running publicly addressable servers. Each server becomes a partial honeypot for its users' data and a partial target for legal or financial pressure. Small operators often lack the security expertise to run these safely.
2.3 Blockchain and Smart Contract Platforms
Public blockchains achieve some decentralisation of state but introduce their own liabilities:
- Transaction fees are non-trivial and variable.
- All on-chain state is permanently public unless explicitly encrypted.
- Smart contract logic is immutable after deployment (or requires expensive upgradeability patterns).
- RPC providers (Infura, Alchemy) reintroduce a centralised dependency for most practical applications.
- The legal and regulatory status of token-based interactions is unsettled globally.
2.4 The Need for a Different Paradigm
None of these models achieves the combination of zero ongoing cost, strong privacy, and censorship resistance simultaneously. The Embedded I2P paradigm targets exactly this intersection.
3. What is the Embedded I2P Paradigm?
I2P (Invisible Internet Project) is an anonymous overlay network in which all traffic is routed through a series of encrypted unidirectional tunnels. Unlike Tor, which is designed primarily to provide anonymous access to the clearnet, I2P is optimised for internal network services — services that exist only within the I2P network, reachable only by other I2P participants, with no exposure to the public internet.
The Embedded I2P Paradigm refers to the architectural pattern of bundling an I2P router directly inside a mobile application, rather than relying on a separately installed I2P client. The key distinction from conventional I2P usage is:
| Conventional I2P Usage | Embedded I2P Paradigm |
|---|---|
| User installs I2P separately | I2P router lives inside the APK |
| Developer runs a server on I2P | No developer-operated server exists |
| App points to a server destination | App creates its own I2P destination at runtime |
| Network survives developer | Network survives developer AND developer's infrastructure |
In this model, each running instance of the application is a fully autonomous network node. The application generates its own I2P cryptographic destination on first run, maintains its own tunnels, participates in peer discovery gossip, and routes messages to and from other instances — all without any centralised intermediary.
4. Core Architecture Overview
The following describes the canonical architecture as implemented in the Techducat suite, specifically the Verzus application:
┌──────────────────────────────────────────────────────┐
│ Android Application │
│ │
│ ┌─────────────┐ ┌──────────────────────────┐ │
│ │ UI Layer │────>│ I2PMessengerClient │ │
│ │ Activities │ │ localhost:8880 │ │
│ └─────────────┘ └────────────┬─────────────┘ │
│ │ │
│ ┌────────────▼─────────────┐ │
│ │ I2PMessengerService │ │
│ │ (Background Service) │ │
│ │ │ │
│ │ Port 8880: Local IPC │ │
│ │ Port 8881: I2P Inbound │ │
│ └────────────┬─────────────┘ │
│ │ │
│ ┌────────────▼─────────────┐ │
│ │ I2PNetworkManager │ │
│ │ SAM Bridge (7656) │ │
│ │ HTTP Proxy (4444) │ │
│ └────────────┬─────────────┘ │
└───────────────────────────────────┼──────────────────┘
│
┌──────────▼──────────┐
│ I2P Network │
│ (Encrypted Tunnels) │
│ │
│ Other App Instances │
└─────────────────────┘
Key components:
- I2PSetupManager — Detects the I2P router state, configures the application's destination, stores it persistently.
- I2PMessengerService — Dual-server background service: one port for local IPC with the UI layer, one port as the inbound I2P tunnel endpoint.
- I2PMessengerClient — Thin client library giving Activities a clean API to the service, with automatic reconnection and message queuing.
- I2PNetworkManager — Low-level SAM bridge interactions: tunnel creation, health monitoring, direct message dispatch.
- Gossip Protocol — Epidemic peer discovery running every 30 seconds, enabling network self-assembly without any bootstrap server being required after the first peer exchange.
5. Advantages of the Paradigm
5.1 Zero Infrastructure Cost
This is the most immediately quantifiable advantage. A conventionally architected equivalent of Verzus — a multi-user, real-time, transactional application with chat, gaming, and financial settlement — would require:
| Component | Estimated Monthly Cost (USD) |
|---|---|
| Application servers (2x) | $100–$400 |
| Database (managed PostgreSQL) | $50–$200 |
| Message broker (Redis/Kafka) | $30–$100 |
| CDN / file storage | $20–$100 |
| Load balancer | $20–$80 |
| Monitoring & logging | $20–$50 |
| Total | $240–$930/month |
Under the Embedded I2P paradigm, this cost is zero. The network is the users' devices. The storage is the users' local databases. The compute is the users' CPUs. The developer pays nothing beyond the one-time cost of writing the software.
This is not merely an economic convenience — it is an enabling condition for certain classes of applications. An application providing financial infrastructure in a low-income market cannot economically justify $500/month in server costs against a user base earning $200/month. The Embedded I2P model removes this barrier entirely.
5.2 Unconditional Privacy by Design
I2P provides layered garlic routing — a variant of onion routing optimised for internal network traffic. Each message is wrapped in multiple layers of encryption and routed through a sequence of volunteer routers, none of which can see both the origin and the destination of a message simultaneously.
This provides:
- Origin anonymity: No peer can determine the real IP address of any other peer.
- Traffic analysis resistance: Encrypted tunnel traffic is statistically difficult to distinguish from background I2P relay traffic.
- Content confidentiality: No router in the path can read message content.
- Unlinkability: The same user connecting from different network sessions cannot be linked without the user's cryptographic identity.
When combined with Monero (XMR) as the financial layer — which provides sender, receiver, and amount privacy at the protocol level through ring signatures, stealth addresses, and RingCT — the complete application stack provides end-to-end privacy that no server-based application can match.
5.3 Censorship Resistance
The I2P network has no central domain name to seize, no central IP address to block, and no central certificate authority to revoke. Blocking I2P traffic requires:
- Identifying I2P traffic on a network (difficult due to traffic obfuscation).
- Blocking all traffic to/from all known I2P routers (a large, dynamic, and geographically distributed set).
- Preventing new users from ever bootstrapping (requires blocking the I2P reseed servers, a set that grows over time).
Even if one jurisdiction successfully blocks I2P reseed access, the network remains accessible to users who have already bootstrapped or who obtain peer addresses through alternative channels (direct peer exchange, USB, QR codes).
For applications in politically sensitive domains — financial privacy tools, communications for journalists or activists, betting markets in jurisdictions where such markets are legally restricted — this property is not a luxury. It is a survival requirement.
5.4 Elimination of Single Points of Failure
In a conventional application, a database failure, a DDoS attack, a misconfigured deployment, or an unpaid hosting bill can take the entire application offline for every user simultaneously. This is a fundamental property of centralised systems, not a correctable bug.
Under the Embedded I2P paradigm:
- There is no central database to fail.
- There is no central server to go down.
- Network degradation is graceful: if some nodes disappear, others continue operating. The gossip protocol naturally routes around missing peers.
-
Reconnection is automatic: the
I2PMessengerClientimplements exponential backoff reconnection; the message queue preserves messages across disconnection events.
The only realistic scenario that degrades the entire network is one in which the I2P network itself degrades — an event that would require simultaneous failure of thousands of independent volunteer routers across dozens of countries.
5.5 No Registration, No KYC, No Identity Leakage
Conventional applications require registration — at minimum an email address, often a phone number, increasingly a government ID for financial applications. This data becomes a liability: it can be subpoenaed, hacked, or sold.
The Embedded I2P paradigm requires none of this. A user's identity is their I2P cryptographic destination — a key pair generated on the device, stored in local encrypted storage, never transmitted to any central authority. In the Techducat implementation, identity is further hardened through RandomIdManager, which generates a 64-character AES-256-GCM-protected user ID bound to the device's hardware-backed Android Keystore.
This means:
- No email address is required.
- No phone number is required.
- No government document is required.
- No operator can produce a user's real identity in response to a legal demand, because no operator possesses it.
5.6 End-to-End Encrypted Transport as Default
I2P's transport layer provides encryption for all tunnelled traffic. This is not optional or configurable — it is the baseline. Every message between any two application instances travels through multiple layers of asymmetric and symmetric encryption.
The Verzus architecture documents an additional application-layer RSA-OAEP encryption scheme for message content, meaning that even a compromised I2P router could not read message payloads. The combination provides:
- Transport security: I2P tunnel encryption.
- Content security: Application-layer message encryption.
- Forward secrecy: I2P session keys are rotated, limiting the impact of any future key compromise.
5.7 DDoS Resistance by Architecture
Traditional servers can be taken offline by flooding them with traffic. The Embedded I2P paradigm resists this structurally:
- There is no IP address to flood. The application's I2P destination is a cryptographic identifier, not an IP address.
- To reach a specific node, an attacker must route traffic through I2P tunnels, which imposes natural rate limits and latency that make volumetric attacks impractical.
- The I2P protocol includes built-in flood protection: the
I2PNetworkManagerin the Verzus implementation includes per-peer rate limiting, which throttles any peer sending excessive messages. - Even if individual nodes were successfully attacked, the network as a whole continues operating.
5.8 Sovereign Data Ownership
All persistent data in the Embedded I2P paradigm lives on the user's device:
- Chat history is local.
- Transaction records are local.
- Peer reputation is local.
- Wallet state is local.
The application developer has no access to this data. No data broker can purchase it. No regulator can compel its disclosure from a central operator, because no central operator holds it.
This is a structural property of the architecture, not a privacy policy. Privacy policies can be changed. Architecture cannot.
5.9 Regulatory Resilience
Applications operating in legally uncertain domains — financial betting, privacy-preserving payments, cross-border value transfer — face regulatory risk that can materialise suddenly: a single order to a cloud provider can take an application offline globally within hours.
The Embedded I2P paradigm mitigates this risk through structural decentralisation. The developer cannot be compelled to "take down" a network they do not host. Existing users continue to operate even if the developer is enjoined from further distribution. The network persists even if the app is removed from app stores, because existing APKs continue to function and can be distributed through alternative channels (direct download, F-Droid, side-loading).
This is not a recommendation to operate outside the law. It is an observation that the architecture provides meaningful resilience against overreach, error, and the unpredictability of regulatory environments in emerging markets.
5.10 Economic Inclusion for Builders in the Global South
A developer in Lagos, Nairobi, Accra, or Karachi faces the same $240–$930/month server cost as a developer in San Francisco — but against a significantly different revenue environment and banking infrastructure. The Embedded I2P paradigm levels this playing field completely. The barrier to running a production application with thousands of users is the cost of writing the software, not the cost of sustaining its infrastructure indefinitely.
This has compounding implications for the African tech ecosystem. Applications can be built, released, and sustained by sole developers or small teams without venture capital to cover server costs. Applications can continue operating even when the developer loses access to payment infrastructure or banking services. Applications can serve users in markets too small to justify conventional infrastructure costs.
5.11 Composability with Privacy Currencies
The Embedded I2P paradigm composes naturally with Monero (XMR) to produce a complete privacy stack:
| Layer | Technology | Property |
|---|---|---|
| Network | I2P | IP address anonymity, traffic confidentiality |
| Identity | Cryptographic destination + RandomIdManager | Pseudonymous, unlinkable |
| Financial | Monero XMR | Sender, receiver, amount privacy |
| Escrow | Monero multisig (2-of-3) | Trustless fund locking |
| Application logic | On-device Kotlin/Android | No server required |
This stack produces applications where: neither the developer nor any third party can identify users, surveil transactions, freeze funds, or shut down the network. No combination of server-based, blockchain-based, or federated architectures achieves all of these properties simultaneously.
5.12 Permanence without Maintenance
Server-based applications require active maintenance to remain operational: dependency updates, security patches, certificate renewals, database migrations, capacity management. When this maintenance lapses — due to funding shortfall, developer illness, loss of interest, or regulatory shutdown — the application dies.
An Embedded I2P application, once released and distributed, continues to operate on users' devices indefinitely. The network continues to exist as long as any two users run the application simultaneously. There are no certificates to expire, no servers to patch, no databases to migrate. The application is, in the fullest sense, maintenance-free after initial distribution.
6. Real-World Instantiation: The Techducat Suite
The Techducat Limited application suite provides a real-world proof of concept across three distinct application domains:
Verzus — Peer-to-Peer Betting Platform
A multi-user betting application supporting sports, politics, cryptocurrency, and custom events. Features: I2P-native peer discovery, Monero XMR multisig escrow for bet funds, multiple card games (Draughts, Whot, Cassino, Élẹ́wẹ̀njẹ́wẹ́wẹ̀) as engagement mechanisms, real-time gossip-based peer discovery, and a complete dispute resolution system with manual and oracle-based arbitration. Zero server infrastructure. Zero hosting cost.
Ajo — ROSCA Savings Application
A rotating savings and credit association (ROSCA) application, implementing the traditional West African "ajo" cooperative savings model in a privacy-preserving peer-to-peer architecture. Features: Monero-based contribution and payout, I2P-anonymous peer communication, Android Keystore-backed identity without Firebase or Google authentication, and fully local data storage. Zero server infrastructure. Zero Google/Firebase dependency.
Scrowit — Monero Multisig Escrow
A general-purpose escrow application using Monero's native 2-of-2 and 2-of-3 multisig capabilities. Features: no-arbitrator 2-of-2 trades, optional third-party arbitration, I2P-anonymous counterparty communication, biometric-gated transaction authorisation, and per-peer rate limiting for spam protection. Zero server infrastructure. Zero trust in any third party.
All three applications share a common I2P networking library under the com.techducat namespace, demonstrating the paradigm's reusability across application domains.
7. Honest Assessment of Limitations
Intellectual honesty requires acknowledging the paradigm's genuine weaknesses:
7.1 Latency
I2P introduces 1–5 seconds of latency for message delivery, compared to sub-100ms for conventional server-based applications. This makes the paradigm unsuitable for applications requiring real-time low-latency interaction (live video, competitive multiplayer gaming at the millisecond level, live audio communication). It is acceptable for chat, financial transactions, turn-based games, and asynchronous collaboration.
7.2 Initial Bootstrap Time
A new I2P node requires 3–5 minutes on first startup to integrate with the I2P network and establish tunnels. This is a significant UX friction point that must be managed through appropriate loading screens and user education.
7.3 Battery and Resource Usage
An embedded I2P router participates in routing traffic for other network participants, consuming CPU, memory, and battery beyond what a conventional HTTP client would use. On constrained hardware, this may be noticeable. Mitigation strategies include pausing the router when the application is backgrounded, reducing gossip frequency, and implementing aggressive connection pooling.
7.4 Android Background Restrictions
Android 8+ aggressively kills background services to conserve battery. This requires careful use of START_STICKY services, foreground service notifications, and battery optimisation whitelist guidance for users. The I2P router being killed in the background can interrupt peer availability.
7.5 Bootstrap Peer Discovery
While the gossip protocol enables network self-assembly once two peers have found each other, the first connection requires at least one known peer address. This bootstrap problem can be addressed through QR code exchange, pre-seeded peer lists in the APK, or a lightweight, expendable bootstrap list that does not need to be trusted or permanent.
7.6 Tested Scale
The architecture has been tested at up to approximately 50 concurrent peers. Behaviour at larger scales (hundreds to thousands of peers) has not been empirically validated, though the gossip protocol's design is theoretically scalable to much larger networks.
8. Comparison with Competing Paradigms
| Property | Centralised Server | Federated (Matrix/ActivityPub) | Blockchain (Ethereum/Solana) | Embedded I2P |
|---|---|---|---|---|
| Hosting cost | High (ongoing) | Medium (per-operator) | Medium (gas fees) | Zero |
| Privacy (network) | Operator-visible | Operator-visible | Public | Anonymous |
| Privacy (financial) | Fully traceable | Fully traceable | Pseudonymous (public) | Fully private (XMR) |
| Censorship resistance | Low | Medium | Medium | High |
| Single point of failure | Yes | Partial | No | No |
| User registration required | Yes | Yes | Wallet required | No |
| Latency | Low | Low–Medium | Medium–High | Medium |
| Scalability | High (with cost) | High | Medium | Medium |
| Maintenance required | High | Medium | Medium | Very low |
| Legal surface area | High | Medium | Medium | Low |
| Works without internet (LAN) | No | No | No | Possible |
9. Recommended Use Cases
The Embedded I2P paradigm is best suited to applications where two or more of the following conditions hold:
- Privacy is a primary user requirement — financial tools, health data, communications under surveillance.
- The developer cannot sustain infrastructure costs — solo developers, NGO projects, early-stage products with no revenue.
- Censorship is a realistic threat — applications operating in or targeting users in jurisdictions with restrictive internet policies.
- The user base is self-sovereign by preference — users who explicitly do not wish their data held by any third party.
- The application domain is legally uncertain — cross-border payments, prediction markets, grey-area financial instruments.
- The application targets the unbanked or underbanked — populations with limited access to formal identity infrastructure, for whom KYC requirements are exclusionary.
- Long-term availability without maintenance is required — archival applications, community tools expected to outlast their original developers.
Specific domains: peer-to-peer lending, cooperative savings (ROSCAs), prediction markets, anonymous messaging, secure document exchange, community governance, privacy-preserving health records, cross-border remittance.
10. Security Considerations
The following security properties require explicit implementation attention:
10.1 Key Storage
I2P destination keys and application identity keys must be stored in the Android Keystore with hardware-backed protection where available. Keys must never be stored in SharedPreferences without AES-256-GCM encryption.
10.2 Message Authentication
All peer-to-peer messages must carry digital signatures verifiable against the sender's known public key. Without this, peers can impersonate each other within the encrypted tunnel. Application-layer message signing is distinct from and in addition to I2P transport encryption.
10.3 Peer Verification
Cryptographic destination addresses should be treated as self-certifying identities: a peer who controls a destination can prove they control it by signing a challenge. First-contact peer verification (akin to SSH known_hosts) should be implemented to prevent later impersonation.
10.4 Rate Limiting
Per-peer rate limiting must be implemented at the application layer to prevent any single peer from flooding the local service with messages. The Scrowit implementation's payload size guard and per-peer rate limiter provide a reference implementation.
10.5 Sensitive Data Logging
Debug logs must not contain message content, user IDs, or I2P destination addresses in production builds. Log scrubbing and release-mode log suppression must be enforced at build time.
11. Conclusion
The Embedded I2P paradigm represents a genuine architectural inflection point. It is not merely a privacy feature layered onto a conventional architecture — it is a wholesale reconception of where a networked application lives, who bears its costs, and who controls its fate.
By embedding the network inside the application, the developer exits the hosting business entirely. By routing all traffic through I2P, the application exits the surveillance economy entirely. By integrating Monero as the financial layer, the application exits the traceable payment infrastructure entirely. The result is a class of application that is simultaneously free to operate, private by default, resilient to censorship, and permanent beyond any single actor's control.
This is not a theoretical ideal. The Techducat suite — Verzus, Ajo, and Scrowit — demonstrates that production-grade, feature-rich applications with real financial operations can be built on this foundation today, on Android, with existing open-source tooling, by a small team without institutional resources.
We propose this paradigm as a serious candidate for adoption by any team building in privacy-sensitive domains, financial inclusion contexts, or markets where infrastructure costs and regulatory risk are material concerns. The question is not whether the Embedded I2P paradigm can sustain sophisticated applications. The question is why we have built so many applications without it.
12. References
- I2P Project: https://geti2p.net/
- I2P Technical Documentation: https://geti2p.net/en/docs
- I2P Android: https://geti2p.net/en/download/android
- SAM (Simple Anonymous Messaging) Bridge Protocol: https://geti2p.net/en/docs/api/sam
- Monero Project: https://www.getmonero.org/
- Monero Multisig Documentation: https://www.getmonero.org/resources/user-guides/multisig-messaging-system.html
- Android Keystore System: https://developer.android.com/training/articles/keystore
- Gossip Protocols: Demers, A. et al. Epidemic Algorithms for Replicated Database Maintenance. ACM PODC, 1987.
- Verzus ARCHITECTURE.md: Techducat Limited Internal Documentation, 2024
- Kotlin Coroutines: https://kotlinlang.org/docs/coroutines-overview.html
- Android Background Execution Limits: https://developer.android.com/about/versions/oreo/background
This white paper is a living document. Contributions, rebuttals, and extensions are welcome.
© 2026 Techducat Limited. Licensed under CC BY 4.0.
Top comments (0)