BitSov: A Composable Bitcoin-Native Architecture for Sovereign Internet Infrastructure

BitSo v: A Composable Bitcoin-Nati v e Architecture for So v ereign Internet Infrastructure Oli ver Aleksander Larsen SDU Software Engineering Univ ersity of Southern Denmark Odense, Denmark olar@mmmi.sdu.dk Rasmus Thorsen Larsen Mindlink AI Odense, Denmark rtl@mindlink.tech Mahyar T . Moghaddam SDU Software Engineering Univ ersity of Southern Denmark Odense, Denmark mtmo@mmmi.sdu.dk Abstract —T oday’ s internet concentrates identity , payments, communication, and content hosting under a small number of corporate intermediaries, creating single points of failur e, enabling censorship, and extracting economic rent fr om par- ticipants. W e pr esent BitSov , an architectural framework f or sover eign internet infrastructure that composes existing decen- tralized technologies (Bitcoin, Lightning Network, decentralized storage, federated messaging, and mesh connectivity) into a unified, eight-layer protocol stack anchored to Bitcoin’ s base layer . The framework introduces three architectural patterns: (1) payment-gated messaging , where every transmitted message requir es cryptographic proof of a Bitcoin payment, deterring spam through economic incentives rather than moderation; (2) timechain-locked contracts , which anchor subscriptions and licenses to Bitcoin block height (the timechain ) rather than calendar dates; and (3) a self-sustaining economic flywheel that con verts service revenue into infrastructure growth. A dual settlement model supports both on-chain transactions f or perma- nence and auditability and Lightning micropayments for high- frequency messaging. As a position paper , we analyze the quality attributes, discuss open challenges, and propose a research agenda f or empirical v alidation. Index T erms —blockchain architecture, Bitcoin, Lightning Net- work, layered settlement, sov ereign infrastructure, payment- gated messaging, decentralized identity I . I N T R O D U C T I O N Despite the internet’ s decentralized origins, its critical in- frastructure has consolidated under a small number of corpo- rate intermediaries. Three cloud providers control over 60% of cloud infrastructure spending [24]; a small number of identity providers mediate billions of digital identities; and payment processors can unilaterally freeze funds across entire indus- tries. This concentration is not merely a policy concern; it is an ar chitectur al problem. Identity , payments, communication, and content hosting are each mediated by centralized chokepoints where a single corporate decision or regulatory directiv e can rev oke identity , freeze funds, erase content, and silence voice simultaneously . 0 © 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collecti ve works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Accepted at BlockArch 2026 (6th W orkshop on Blockchain-Based Architectures), co-located with IEEE ICSA 2026. These pressure points manifest as four architectural single points of failure: (a) identity is rented from platform operators and can be rev oked; (b) payments flow through intermediaries that impose fees and restrictions; (c) content persists only at the discretion of hosting pro viders; and (d) communication depends on proprietary platforms that surv eil conv ersations and can deplatform users without recourse. Sev eral decentralized technologies address individual as- pects of this problem. Nostr [8] provides relay-based messag- ing with Bitcoin-keypair identity; IPFS [11] enables content- addressed storage; the W3C Decentralized Identifiers (DID) standard [3] specifies self-sovereign identity primitiv es; and the Lightning Network [2] provides instant of f-chain pay- ments. Ho wev er , these solutions remain fragmented : no uni- fied architectural framework composes them into a coherent, self-sustaining stack [12], [13]. Moreov er , many blockchain- based architectures introduce ne w tokens or chains rather than building on Bitcoin’ s proven security and network effects. Our position. W e argue that Bitcoin’ s layered settle- ment model, combining on-chain finality with off-chain pay- ment channels, provides a particularly suitable foundation for composing sov ereign internet infrastructure, and that payment-gated communication offers a promising alternativ e to moderation-based abuse prev ention. This paper makes the following contributions: 1) An eight-layer composable architectural framework for Bitcoin-nativ e sovereign internet infrastructure (Sec- tion III). 2) Three architectural patterns (payment-gated messaging, timechain-locked contracts, and a self-sustaining eco- nomic flywheel) that emerge from this composition (Section III-C). 3) Analysis of quality attributes and honest discussion of architectural trade-offs (Section IV). 4) A research agenda identifying open challenges for em- pirical validation (Section V). I I . B AC K G RO U N D A N D R E L A T E D W O R K Self-sover eign identity . Allen [4] articulated the founda- tional principles of self-sovereign identity (SSI), which the W3C DID specification [3] later formalized. ION [5], a Bitcoin-anchored DID network dev eloped by Microsoft, is the closest existing approach to Bitcoin-based decentralized identity . Howe ver , existing SSI systems typically treat identity in isolation; our framework integrates identity as the foun- dational layer of a complete infrastructure stack, with the Bitcoin ke ypair as the cryptographic root from which all other capabilities deriv e. Payment channels and economic spam pr evention. The idea of using computational cost to deter spam originates with Dwork and Naor [6] and was refined by Back’ s Hash- cash [7]. The Lightning Network [2] enables instant off-chain Bitcoin payments through bidirectional payment channels. Whatsat [19] demonstrated Lightning-based messaging by routing TL V payloads through payment channels with minimal fees, using payment primarily as a transport mechanism. Our framew ork elev ates payment from a transport detail to a foundational architectural principle: every message requires a cleared payment whose cost is calibrated for spam deterrence. Decentralized communication. Nostr [8] combines Bitcoin-keypair identity with relay-based messaging and optional “zaps” (tips via NIP-57), but does not mandate payment for message deliv ery; W ei and T yson [20] note that some relays have introduced admission fees as a barrier against spam, underscoring the need for economic mechanisms. Matrix [9] provides federated messaging with serv er-dependent infrastructure and no economic layer . Briar [10] supports mesh-capable P2P messaging but is limited in scalability . None of these architectures integrate payments at the protocol lev el as a spam prevention mechanism; they all treat communication and economics as separate concerns. I I I . A R C H I T E C T U R A L F R A M E W O R K A. Design Principles The BitSov architecture is gov erned by fi ve in variant de- sign principles that constrain all protocol decisions. T able I summarizes each principle and its architectural implication. These principles are hierarchically ordered: P1 (Sovereign Identity) is the non-negotiable root from which P2–P5 deriv e. Any protocol decision that conflicts with a higher -ranked principle must yield. Notably , P2 deliberately trades usability for spam resistance (a trade-off analyzed in Section IV -B), and P4 ensures that data publication is alw ays an explicit, opt-in action. K ey loss under P1 implies total identity loss; social- recov ery schemes and multi-signature key management can mitigate this risk while preserving sovereignty . B. Layered Ar chitectur e BitSov composes existing decentralized technologies into an eight-layer stack (Fig. 1) where each layer depends only on those below it, enabling independent ev olution while pre- serving system-wide coherence. The Base Layer (Bitcoin L1) is the canonical source of o wn- ership, truth, and time [1], anchoring identity and pro viding the timechain reference. The Connectivity Layer deli vers transport through mesh, satellite, and ISP routes, ensuring reachability when individual providers fail. The Identity Layer roots iden- tity in a Bitcoin keypair , with a proposed Bitcoin Name System T ABLE I C O RE D E SI G N P R I N CI P L E S Principle Architectural Implication P1: Sover eign Iden- tity The Bitcoin keypair is the user . All authority (au- thentication, payment capability , messaging iden- tity , content authorship) deriv es from it. No inter- mediary holds credentials. P2: P ayment Gate Every transmission requires a cleared Bitcoin pay- ment (on-chain or Lightning), providing crypto- graphic proof of economic commitment. P3: Composable Modularity Each layer depends only on layers below it. Any component can evolve or be replaced without compromising the integrity of the whole. P4: Data Sover eignty Data lives only on sender and recei ver nodes. Publishing to decentralized storage is the user’ s explicit choice, ne ver a system default. P5: T imechain Eco- nomics Subscriptions and contracts are anchored to Bit- coin block height. Revenue funds infrastructure growth through a self-sustaining flywheel. L1: Base – Bitcoin Layer 1 (ownership, truth, time) L2: Connecti vity – Mesh / Satellite / ISP / Hybrid L3: Identity – Bitcoin ke ypair + Name System (.btc) L4: P ayment – On-Chain + Lightning + Timechain Pricing L5: Storage – IPFS / Arweave + Per-Node Local L6: Communication – Payment-Gated / Federated / Broadcast L7: Go vernance – Decentralized Protocol Ev olution L8: Application – Clients / SDKs / Plugin Ecosystem Fig. 1. BitSov layered architecture. Each layer depends only on layers below it. Bitcoin L1 pro vides the trust anchor; on-chain and Lightning jointly provide the economic layer . (.btc) providing human-readable, on-chain names that are sov ereign, portable, and verifiable without certificate author- ities. The P ayment Layer supports dual settlement: on-chain transactions for high-assurance operations and Lightning [2] micropayments for high-frequency interactions, plus timechain pricing via Schnorr -authenticated [18] block-height-locked contracts. The Storage Layer combines decentralized hosting (IPFS [11] or Arweave) with per -node local storage. The Com- munication Layer supports payment-gated direct messaging, federated group messaging, asynchronous mail, and broad- cast relay , all end-to-end encrypted. The Governance Layer coordinates protocol ev olution through a BIP-style proposal process where changes are drafted, revie wed, and adopted via rough consensus among node operators, bounded by the design principles. The Application Layer provides clients, SDKs, and a plugin ecosystem composing lower layers. A key property is composable modularity : each layer ex- poses well-defined interfaces and depends only downward, so the storage backend, settlement path, or connectivity layer can each be substituted without cascading changes [14], consistent with the layer-two design philosophy described by Gudgeon et al. [23]: anchor trust on L1, interact via off-chain channels, with on-chain always av ailable as fallback. C. Arc hitectural P atterns W e identify three architectural patterns that distinguish BitSov from existing blockchain-based systems [21]. 1) P ayment-Gated Messaging: Pr oblem. Decentralized communication systems face persistent spam and abuse. Tra- ditional countermeasures (centralized moderation, proof-of- work challenges [6], [7], reputation systems) are respectively centralizing, computationally wasteful, or gameable. Nostr’ s empirical data highlights that free relays lack effecti ve spam countermeasures [8], [20]. Mechanism. In BitSov , e very message transmission requires a cleared Bitcoin payment cryptographically bound to the mes- sage content. The framework supports two settlement paths: (a) Lightning micropayments for real-time messaging, where the sender pays an in voice encoding the message content hash and the receiv er v erifies settlement via channel state; and (b) on-chain transactions for high-value or archi val messages, where settlement is verified against confirmed blocks. In both paths, the receiver extracts the payment hash, validates the cryptographic signature binding payment to content, and de- liv ers the message only upon successful verification. Payment and message are inseparable regardless of settlement path. Quality attributes. This pattern provides spam r esistance through economic cost rather than computational cost; r eceiver compensation since every message pays the recei ver; sender accountability through economic commitment as an identity signal; and Sybil r esistance since creating fake identities carries a real cost per message. Unlike Whatsat [19], where payment serves primarily as a transport mechanism, BitSov treats payment as an economic spam deterrent, making com- munication and economics inseparable at the protocol lev el. Thr eat model. Payment gating assumes rational attackers for whom per-message cost e xceeds the expected benefit of spam. It does not eliminate abuse by well-funded adversaries willing to pay above-market rates; ho wev er , it bounds the attack surface economically and makes sustained spam cam- paigns quantifiably expensi ve. Fee volatility may temporarily shift this cost–deterrence equilibrium, motiv ating RQ1 in our research agenda. 2) T imechain-Loc ked Contracts: Problem. Calendar-based subscriptions depend on trusted third parties for time mea- surement and enforcement. Software licensing is gated by corporate decisions and is opaque, rev ocable, and extractiv e. Mechanism. Contracts specify a start block, end block, price in satoshis, and a Schnorr signature [18] ov er all fields. Lev er- aging Bitcoin’ s absolute timelocks [17], a subscription paid via Lightning or directly on-chain provides access for a defined block range. On-chain settlement is preferred for contracts because it provides permanent public verifiability of terms by any third party . Upon reaching the end block, the code transitions to open source. Contracts are cryptographically signed and anchored: tamper-proof and self-enforcing without intermediaries. Quality attributes. Timechain-lock ed contracts provide transpar ency (all terms are public and verifiable), immutabil- ity (signed terms cannot be altered post-hoc), and self- T ABLE II Q UA L IT Y A T T R I BU T E S A N D A R C H IT E C TU R A L M E C H AN I S M S Quality Attribute Architectural Mechanism Censorship resis- tance No central storage; Bitcoin-anchored identity; decen- tralized content hosting Spam resistance Payment-gated messaging (economic, not computa- tional) Scalability Layered composition; dual settlement (on-chain + Lightning); modular component replacement Resilience Mesh topology; satellite fallback; node div ersity; re- dundant paths Priv acy E2E encryption; no central data stores; data sovereignty principle Sovereignty Bitcoin keypair identity; no intermediaries; user- controlled publishing Sustainability Economic flywheel; productiv e-use funding enfor cement (no third party is needed to adjudicate access). The open-source transition at contract e xpiry creates a self- r enewing commons where commercial sustainability and open access coexist. 3) Self-Sustaining Economic Flywheel: Pr oblem. Decen- tralized networks typically depend on token speculation, ven- ture capital, or altruistic participation for growth [16], creating misaligned incentiv es and unsustainable economics. Mechanism. Users pay for productiv e services on the plat- form. Revenue margin is con verted into new sovereign nodes. More nodes strengthen the mesh and improve service quality , which attracts more participants, generating more re venue. Unlike DePIN architectures [16] that rely on protocol-specific tokens, BitSov’ s flywheel operates entirely in satoshis, in- heriting Bitcoin’ s liquidity and avoiding token speculation dynamics. Quality attributes. The flywheel provides sustainability through productive-use funding, incentive alignment between participants and infrastructure, and or ganic gr owth that does not depend on external capital. Infrastructure growth is en- dogenous: the network’ s economic model is integral to the architecture. I V . A N A L Y S I S A N D D I S C U S S I O N A. Quality Attributes T able II maps ke y quality attributes to their architectural mechanisms. Following Bass et al. [15], these properties are emer gent : they arise from the composition of architectural decisions rather than being retrofitted as separate features. For instance, censorship resistance is not a single mechanism but emerges from the combination of Bitcoin-anchored identity (no rev ocable credentials), decentralized storage (no deletable content), and payment-gated messaging (no blockable relay). Six et al. [21] catalog 120 blockchain software patterns; BitSov’ s payment-gated messaging and timechain-locked con- tracts are not among them. Ahmadjee et al. [22] map blockchain design decisions to security threats; BitSov ad- dresses these attack surfaces through economic rate-limiting and the absence of central data stores, identity providers, and interceptable relays. B. T rade-of fs and Limitations W e identify fiv e key trade-offs that warrant honest acknowl- edgment: P ayment friction. Payment-gated messaging introduces fric- tion for casual communication. The cost per message must be calibrated carefully: too high excludes legitimate users, too low fails to deter spam. Mitigations include pre-funded channel balances, trusted-contact whitelists, and community- subsidized channels. Settlement trade-offs. The dual settlement model introduces a latency versus assurance trade-of f. Lightning enables sub- second messaging but inherits channel management complex- ity and routing failures; on-chain settlement provides stronger finality and public auditability b ut incurs higher fees and ∼ 10 min confirmation latency . P3 allows per -use-case path selection, with on-chain as resilient fallback [23]. Onboar ding complexity . Sov ereign identity requires ke y management sophistication that may e xceed typical user ca- pability . Loss of a pri vate key means loss of identity , funds, and all associated data; this is an inherent trade-of f of self- sov ereignty versus managed identity . Social-recovery schemes and multi-signature arrangements can mitigate key-loss risk without fully compromising sov ereignty . Scalability uncertainty . The framew ork’ s scalability has not been empirically validated. Messaging throughput depends on Lightning Network capacity and channel liquidity; on- chain throughput is constrained to ∼ 7 TPS globally , and the flywheel’ s dynamics at scale are unmodeled. Governance bootstrapping. Decentralized governance re- quires a critical mass of participants. The cold-start problem (how to govern before the community exists) is not fully addressed by the current framew ork. V . R E S E A R C H A G E N DA The follo wing open questions in vite collaborati ve in v estiga- tion by the BlockArch community: RQ1 (L4, L6) What micropayment threshold maximizes spam deterrence while minimizing legitimate user friction? RQ2 (L2, L4) Ho w does the architecture perform under adver - sarial conditions (Eclipse, Sybil, state-lev el censorship), and ho w effecti v ely does on-chain fallback mitigate Lightning-layer failures? RQ3 (L4) Can timechain-locked contracts be formally ver - ified, and what are the implications of block time variance? RQ4 (L1–L8) What patterns enable graceful degradation when individual layers experience partial failures? RQ5 (L4, L7) How can the economic flywheel be modeled to identify equilibrium conditions and failure modes? V I . C O N C L U S I O N W e presented BitSov , an eight-layer architectural frame work composing Bitcoin settlement, Lightning micropayments, de- centralized storage, federated messaging, and mesh connec- tivity into a sov ereign internet stack with dual settlement. Three architectural patterns emerge from this composition: payment-gated messaging, timechain-locked contracts, and a self-sustaining economic flywheel. As a position paper, BitSo v proposes architectural patterns and design principles rather than reporting on a deployed system. Empirical validation should proceed through simulation of payment-gated messag- ing under adversarial load, prototyping on Bitcoin testnets, and formal verification of timechain-locked contracts. W e in vite the BlockArch community to collaborate on these open challenges. R E F E R E N C E S [1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system, ” 2008. [2] J. Poon and T . Dryja, “The Bitcoin Lightning Network: Scalable off- chain instant payments, ” Draft v0.5.9.2, Jan. 2016. [Online]. A vailable: https://lightning.network/lightning- network- paper .pdf [3] W3C, “Decentralized Identifiers (DIDs) v1.0, ” W3C Recommendation, Jul. 2022. [Online]. A vailable: https://www .w3.or g/TR/did- core/ [4] C. Allen, “The path to self-sovereign identity , ” Apr . 2016. [Online]. A vailable: https://www .life withalacrity .com/article/ the- path- to- self- soverereign- identity/ [5] D. Buchner et al. , “ION – Identity Overlay Network, ” Decentral- ized Identity Foundation, 2021. [Online]. A v ailable: https://github .com/ decentralized- identity/ion [6] C. Dwork and M. Naor, “Pricing via processing or combatting junk mail, ” in Pr oc. CRYPTO , LNCS 740, Springer, 1993, pp. 139–147. [7] A. Back, “Hashcash – A denial of service counter-measure, ” T ech. Report, Aug. 2002. [Online]. A vailable: http://www .hashcash.org/papers/ hashcash.pdf [8] Fiatjaf, “NIP-01: Basic protocol flo w description, ” Nostr Imple- mentation Possibilities, 2023. [Online]. A vailable: https://github .com/ nostr- protocol/nips/blob/master/01.md [9] The Matrix.org Foundation, “Matrix Specification v1.8, ” 2023. [Online]. A vailable: https://spec.matrix.org/ [10] The Briar Project, “Briar Protocol Specifications, ” 2022. [Online]. A v ail- able: https://code.briarproject.org/briar/briar- spec [11] J. Benet, “IPFS – Content addressed, versioned, P2P file system, ” arXiv:1407.3561 , Jul. 2014. [12] X. Xu et al. , “ A taxonomy of blockchain-based systems for architecture design, ” in Pr oc. IEEE ICSA , 2017, pp. 243–252. [13] A. C. Ordonez-Guerrero et al. , “Blockchain architectural concerns: A systematic mapping study , ” in Pr oc. IEEE ICSA Companion (BlockAr ch) , 2022, pp. 183–192. [14] F . W essling et al. , “How much blockchain do you need? T o wards a concept for building hybrid DApp architectures, ” in Proc. IEEE/ACM 1st Intl. W orkshop on Emer ging T r ends in Softwar e Engineering for Blockc hain (WETSEB) , 2018, pp. 44–47. [15] L. Bass, P . Clements, and R. Kazman, Software Ar chitectur e in Practice , 4th ed. Addison-W esley , 2021. [16] Z. Lin, T . W ang, L. Shi, S. Zhang, and B. Cao, “Decentralized ph ysical infrastructure networks (DePIN): Challenges and opportunities, ” IEEE Network , vol. 39, no. 2, pp. 91–99, 2025. [17] P . T odd, “BIP-65: OP CHECKLOCKTIMEVERIFY , ” Bitcoin Improve- ment Proposal, Oct. 2014. [18] P . W uille, J. Nick, and T . Ruffing, “BIP-340: Schnorr signatures for secp256k1, ” Bitcoin Improv ement Proposal, Jan. 2020. [19] J. Jager , “Whatsat: End-to-end encrypted, onion-routed, censorship- resistant, peer -to-peer instant messaging o ver Lightning, ” 2019. [Online]. A vailable: https://github.com/joostjager/whatsat [20] Y . W ei and G. T yson, “ An empirical analysis of the Nostr social network: Decentralization, availability , and replication overhead, ” Proc. ACM on Networking , vol. 3, no. CoNEXT4, art. 47, 2025. [21] N. Six, N. Herbaut, and C. Salinesi, “Blockchain software patterns for the design of decentralized applications: A systematic literature re view , ” Blockc hain: Resear ch and Applications , vol. 3, no. 2, 2022. [22] S. Ahmadjee, C. J. Mera-G ´ omez, R. Bahsoon, and R. Kazman, “ A study on blockchain architecture design decisions and their security attacks and threats, ” A CM T rans. Softw . Eng . Methodol. , vol. 31, no. 2, art. 36e, 2022. [23] L. Gudgeon, P . Moreno-Sanchez, S. Roos, P . McCorry , and A. Gervais, “SoK: Layer-two blockchain protocols, ” in Pr oc. F inancial Cryptogra- phy and Data Security (FC) , LNCS 12059, Springer, 2020, pp. 201–226. [24] Synergy Research Group, “Cloud market share trends – Big three together hold 63%, ” Nov . 2025. [Online]. A vailable: https://www . srgresearch.com/