Nondominium - A Coordination Layer for Parallel Infrastructure Governance-as-Operator on Agent-Centric Infrastructure

Executive Summary

Critical infrastructure no longer behaves like a set of separate sectors. Energy, communications, finance, transport, manufacturing, supply chains, water, and public governance now operate as a tightly coupled system of systems. Failures in one layer increasingly propagate into the others, turning local disturbances into systemic shocks (Buldyrev et al., 2010; Helbing, 2013; CISA, 2025; DOE, 2023).

This is not a small market problem. Global supply chains alone account for over $10 trillion in annual intermediate goods trade, while infrastructure investment requirements exceed $3.3 trillion annually and rise toward $7 trillion when climate-adjusted needs are included (McKinsey, 2020; Woetzel et al., 2016; OECD, 2017). Yet recent evidence suggests that the binding constraint is often not capital itself, but coordination: the ability to govern interdependent assets, actors, and processes across fragmented institutional boundaries (World Bank, 2020).

Peer-to-peer technologies have historically entered systems from the edge and then become infrastructure. File sharing reshaped internet traffic. Internet-native voice eroded telecom monopolies. Blockchain introduced peer-to-peer value transfer. DeFi, decentralized storage, and emerging DePIN systems are now moving into finance, communications, and energy-adjacent sectors. The pattern matters: once peer-to-peer coordination proves cheaper, faster, or more resilient than centralized alternatives, it stops looking marginal and starts becoming part of the substrate.

Nondominium should be understood in that trajectory. It is not another tokenization scheme. It is a coordination layer for real assets and real economic processes, built on Holochain and grounded in hREA and Valueflows. Its core innovation is the NDO primitive: a governance-bearing economic object that can encode access, permissions, obligations, accountability, and traceable contribution around shared resources.

For impact investors, the thesis is straightforward. If critical systems are becoming more interdependent, and if peer-to-peer architectures are moving inward from the margins toward infrastructure, then governance and coordination become high-value layers. Nondominium is positioned as a cross-sector coordination substrate that can support energy, manufacturing, logistics, healthcare-adjacent production, and other distributed infrastructures at the same time.

         To reserve your front-seat to this endeavor find the Finance button here.

Critical Infrastructure Is a System of Systems

Governments and infrastructure planners increasingly describe critical infrastructure in terms of dependencies and interdependencies rather than isolated sectors. Energy depends on communications networks for monitoring and control. Communications depends on electricity. Payments and finance depend on telecoms, timing infrastructure, and reliable computation. Transport depends on energy, digital routing, and finance. Manufacturing depends on transport, power, water, and supply chain coordination. Water systems depend on energy and industrial supply. Governance and emergency response sit across all of them (CISA, 2025; DOE, 2023).

The economic consequence of this interdependence is clear: disruptions no longer stay local. McKinsey estimates that severe supply chain disruptions threaten up to $5 trillion in global economic losses, while the World Bank continues to identify governance and coordination failures as primary barriers to infrastructure performance (McKinsey, 2020; World Bank, 2020).

In such an environment, infrastructure advantage increasingly comes from the ability to coordinate across boundaries:

• between organizations
• between sectors
• between local and global processes
• between physical assets and digital rules

This is why coordination itself is becoming infrastructure.

How P2P Creeps Into Infrastructure

The history of peer-to-peer technology follows a familiar arc. It begins in places dismissed as peripheral, experimental, or unsanctioned. Then it solves a real coordination problem better than incumbents. Finally, it becomes invisible infrastructure.

Early peer-to-peer systems optimized distribution and resilience in data exchange. Later, blockchain extended peer-to-peer coordination into value transfer by reducing verification and trust costs (Catalini & Gans, 2016). More recently, peer-to-peer architectures have moved into applied infrastructure domains:decentralized storage and compute in information infrastructure
stablecoins, tokenized assets, and on-chain settlement in finance
peer-to-peer energy trading and prosumer markets in electricity systems
distributed hardware provisioning through DePIN models

The significance is not that all of these systems have already replaced incumbents. They have not. The significance is that they have opened a path. Once peer-to-peer architectures demonstrate credible performance in one infrastructure layer, they tend to spread into adjacent layers.

That pattern is especially visible in energy and communications. Reviews of peer-to-peer energy systems show growing deployment across multiple countries, as distributed generation forces markets to adapt from one-way centralized distribution toward many-to-many coordination (Parag & Sovacool, 2016; Review of P2P Energy Trading, 2024). At the same time, digital infrastructure has already normalized distributed coordination at internet scale.

The question is no longer whether peer-to-peer systems can enter critical infrastructure. It is where they will become most strategic next.

The Missing Layer: Coordination Infrastructure

The modern economy has capital, assets, sensors, software, and institutions. What it lacks is a scalable coordination layer for shared resources operating across many actors and many contexts.

Traditional coordination mechanisms are limited. Firms coordinate hierarchically. Markets coordinate through price. States coordinate through regulation and public administration. Platforms coordinate through centralized ownership of data, rules, and interfaces. Each model has strengths, but all struggle when coordination must be:

• multi-actor
• cross-organizational
• real-time
• privacy-sensitive
• adaptable to local context

As Benkler (2006) argued, organizational forms break down when information-processing demands outgrow their structure. That insight is even more relevant in an era of interdependent infrastructures.

Blockchain addresses one part of this problem by creating shared truth across distrustful actors. But its reliance on global consensus makes it expensive or rigid for many real-world coordination tasks. Physical infrastructure often requires local validation, local governance, selective disclosure, and high transaction frequency. These are not edge cases. They are the norm.

This is where Nondominium diverges from most blockchain-native approaches.

Why Nondominium Is Different

Nondominium is built on an agent-centric architecture rather than a global ledger. On Holochain, each participant maintains their own state and validates the interactions they are part of, while shared rules preserve network integrity. The result is a form of distributed coordination that does not require universal synchronization for every event.

Economically, this matters for three reasons.

First, it changes the scaling model. Coordination does not bottleneck around a shared chain, a sequencer, or a globally priced transaction space.

Second, it makes governance more granular. Rules can operate at the level of specific interactions, resources, and processes rather than being imposed as one uniform logic across the entire network.

Third, it aligns better with how real economies work. Production, maintenance, logistics, usage rights, and contribution accounting are relational and context-dependent. They are not just token transfers.

At the application layer, Nondominium uses Valueflows and hREA to model economic reality in terms of resources, events, agents, processes, and commitments. This is a critical distinction. Most blockchain-based systems start from tokenized representation. Nondominium starts from economic coordination itself.

That makes it less useful for speculation and more useful for infrastructure.

The NDO Primitive as Economic Infrastructure

The strongest way to understand Nondominium is through the NDO primitive.

An NDO is not simply a digital wrapper around an asset. It is a governance-bearing economic object. It can define who may access a resource, under what conditions, with what obligations, how usage is recorded, how contributions are recognized, and how disputes or exceptions are handled.

This is important because most infrastructure coordination problems are not primarily about ownership transfer. They are about governed use of shared or interdependent resources:

• who can use a tool, machine, vehicle, panel, or facility
• when access is allowed
• what maintenance or compliance obligations attach to use
• how contributions are tracked across multiple actors
• how rules change over time without recentralizing the system

In this sense, the NDO primitive turns governance itself into infrastructure. It creates a programmable yet context-sensitive way to coordinate real assets without collapsing back into a centralized platform operator or forcing everything into token logic.

This is also why Nondominium is better understood as a coordination substrate than as an application in one vertical.

Cross-Sector Leverage

Critical infrastructure investors typically look for systems with leverage across sectors. Nondominium fits that profile because it operates at the layer where sectors increasingly converge: governed coordination of distributed assets and processes.

In energy, the rise of distributed generation, prosumer markets, and local storage creates a need for fine-grained coordination around shared equipment, rights, obligations, and transactions (IEA, 2021; Parag & Sovacool, 2016).

In manufacturing, shared tooling, open hardware, collaborative production, and distributed quality assurance all require coordination mechanisms that are more flexible than enterprise silos and more grounded than token speculation.

In supply chains and transport, the challenge is not only provenance but process synchronization across many organizations, jurisdictions, and asset classes.

In healthcare-adjacent production, including medical instruments, the challenge becomes even sharper: traceability, permissions, accountability, compliance, and collaboration must coexist without placing every activity inside a single centralized owner.

This is the economic logic behind Nondominium's relevance. It is a layer that can improve several systems at once because those systems increasingly share the same underlying coordination problem.

For an investor, that means the opportunity is not confined to one narrow market. It is exposure to a coordination architecture that can move with the broader shift toward distributed infrastructure.
8. Nondominium and the P2P Infrastructure Stack

Nondominium should not be framed as anti-blockchain. It is better framed as complementary to the broader peer-to-peer stack.

Blockchains are well suited to final settlement, tokenization, external market interfaces, and globally visible states. DePIN systems can mobilize hardware and create incentive layers for physical provisioning. Nondominium addresses a different problem: local coordination, governed use, process accountability, and context-sensitive rules around real resources.

This complementarity matters. The next generation of infrastructure is unlikely to be built from one technology alone. It will be layered:blockchain where settlement, liquidity, or external finality matter
DePIN where hardware provisioning and incentive bootstrapping matter
agent-centric systems like Nondominium where governance, privacy, and high-frequency coordination matter

In that architecture, Nondominium occupies a strategic position. It can prevent distributed systems from collapsing back into centralized coordination simply because the governance layer was missing.

Economic Thesis for Investors

The core investment thesis is that Nondominium is not just a software project. It is a candidate coordination layer for parallel infrastructure.

Why does that matter now?

Because the world is entering a period in which peer-to-peer systems are no longer confined to digital subcultures. They are moving into the operating layers of critical infrastructure. Finance has already shown the pattern. Communications is deep into it. Energy is moving in that direction. Manufacturing, logistics, and regulated collaboration are close behind.

If that historical movement continues, the valuable positions will not only be in assets or capital pools. They will also be in the systems that govern interaction across those assets and actors.

Under conservative adoption assumptions, even a very small share of cross-sector infrastructure flows would imply tens of billions in coordinated throughput. At greater maturity, the relevant scale becomes much larger, because the same coordination substrate can be reused across multiple sectors rather than rebuilt separately in each one. In that sense, Nondominium has the profile of infrastructure that can lift many boats at once.

This does not require immediate displacement of incumbents. The more plausible path is progressive insertion:

• first in shared labs, collaborative production, and pilot networks
• then in sector-specific production and logistics systems
• later as a reusable coordination substrate across interdependent infrastructures

That is a serious infrastructure thesis, not a speculative token thesis.

Adoption Path and Maturity

The likely path is evolutionary, but the endpoint could still be transformative.

Near term, Nondominium can prove itself in environments where coordination is already the bottleneck: shared manufacturing, open hardware networks, distributed energy-adjacent systems, and pilot logistics or medical production environments.

Medium term, the strategic objective is not one dominant application but a series of production-grade networks in different sectors that validate the same core architecture.

Longer term, as peer-to-peer infrastructure continues to mature, the value of Nondominium increases because it becomes reusable across domains. A common coordination layer across energy, manufacturing, transport, and healthcare-adjacent production is economically more powerful than a point solution in any single one of them.

This is why the project deserves attention from impact investors and critical infrastructure funds. The opportunity is not simply to support a better app. It is to back an infrastructure component that could matter wherever distributed systems need trustworthy, scalable, context-sensitive coordination.

Conclusion

The defining infrastructure problem of the coming decade may not be asset scarcity. It may be the inability of existing institutions to coordinate increasingly interdependent systems with sufficient speed, granularity, and resilience.

Nondominium addresses that problem directly. By combining agent-centric infrastructure, Valueflows-based economic modeling, distributed accounting, and governance-as-operator, it offers a coordination architecture that fits the direction in which critical infrastructure is already moving.

If peer-to-peer technology continues its historical movement from edge use cases into foundational systems, then Nondominium is well positioned. It is not a universal replacement for legacy institutions. It is something potentially more important: a missing layer that can sit across sectors and make parallel infrastructure workable at scale.

         You can monitor development closely and even influence it
          by investing in this endeavor. Find the Finance button here.

References

Benkler, Y. (2006). The Wealth of Networks. Yale University Press.

Buldyrev, S. et al. (2010). Catastrophic cascade of failures in interdependent networks. Nature, 464, 1025–1028. https://doi.org/10.1038/nature08932

Catalini, C., & Gans, J. (2016). Some Simple Economics of the Blockchain. https://doi.org/10.2139/ssrn.2874598

CISA (2025). Infrastructure Dependency Primer. Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/topics/critical-infrastructure-security-and-resilience/resilience-services/infrastructure-dependency-primer/learn

DOE (2023). Electric Power and Telecommunications Interdependencies. U.S. Department of Energy.

Helbing, D. (2013). Nature, 497, 51–59. https://doi.org/10.1038/nature12047

IEA (2021). Net Zero by 2050. https://www.iea.org/reports/net-zero-by-2050

McKinsey (2020). Risk, resilience, and rebalancing in global value chains.

OECD (2017). Investing in Climate, Investing in Growth.

Parag, Y., & Sovacool, B. K. (2016). Electricity market design for the prosumer era. Nature Energy.

Parker, G., Van Alstyne, M., & Choudary, S. (2016). Platform Revolution.

PwC (2020). Time for Trust: Blockchain Report.

Review of P2P Energy Trading (2024). Review of peer-to-peer energy trading: Advances and challenges.

Woetzel, J. et al. (2016). McKinsey Global Institute.

World Bank (2020). Infrastructure Governance Report.

From Digital Commons to Coordinated Commons: How Web3 Solves Open Source Fragmentation

The open-source movement is founded on the principle of sharing. Developers are granted the freedom to view, use, modify, and distribute code, a pool of shared knowledge known as digital commons. This freedom, however, carries an inherent paradox: the ease of copying code often leads to unwanted proliferation or project fragmentation, draining resources and creating chaos for users.

This post explores the governance, social, and economic failures inherent in traditional open-source development and presents a new paradigm: using Web3 primitives like blockchain, NFTs, and DAOs to enforce coordination, accountability, and sustainable development.

The Problem of Proliferation: The Fragmented Digital Commons

The fundamental challenge stems from Web 1.0’s core mechanism: when you download a file, you get a copy. This makes it difficult to verify two critical factors:

• Provenance and Integrity: Is this file an exact, unmodified copy of the original (the canonical version)? Where did it originate?
• Resource Consolidation: If a developer makes a copy (a fork) and continues development in isolation, their effort is lost to the main project, leading to two parallel, weaker versions.

This tension between the freedom to fork and the necessity of consolidation has defined the history of collaborative software development. The problem of project fragmentation (unwanted proliferation) is often framed against the "Tragedy of the Commons" theory, which describes a situation where individual users, acting independently and rationally according to their self-interest, deplete or degrade a shared resource.

In the open-source context:

• The "commons" is the shared code, community attention, and collective development effort.
• The "tragedy" occurs when individual developers copy the code (a non-rivalrous act) to pursue their own interests (a new feature, a different direction, or an escape from conflict). While legally permissible, if many do this, the collective attention and development resources become fragmented, weakening the original project and making it difficult for users to know which version is the canonical, well-maintained one.

Reasons and Motivations for Forking Open-Source Projects

Developers and users adopt the behavior of copying a project (forking) and developing in isolation for several key reasons, often stemming from an inability or unwillingness to continue collaboration within the original project's context.

Philosophical and Directional Conflicts

These are disagreements about the fundamental nature, goals, or future of the software.

• Diverging Goals or Vision: A group of developers or a major user may have a different direction they want to take the project that doesn't align with the core maintainers' vision. They fork to implement their specialized feature set or use case, leading to specialization or a focus on a niche market/need.
• Schism or Disagreement on Strategy: The core developer community may experience a philosophical schism or fail to reach a consensus on major design decisions, roadmap, or technical choices (e.g., framework, dependencies).
• Preventing a Perceived Negative Future: Developers may fork proactively if they fear a change in project ownership, licensing (e.g., a move toward proprietary control), or a direction they believe will harm the project's utility or community.

Governance and Social Issues

These relate to the management and human dynamics within the original project.

• Rejection of Contributions (Patches/Features): A primary motivation is when the original project's core developers refuse to accept a developer's proposed changes (patches, bug fixes, or new features), leaving the contributor with forking as the only way to get their desired functionality.
• Dissatisfaction with Project Leadership/Management: Developers may be unhappy with the style, speed, or perceived inactivity of the project's maintainers (e.g., slow bug-fix responses, lack of clear decision-making, or an autocratic "benevolent dictator" model).
• Personality Clashes and Acrimony: Interpersonal conflicts or hostile project environments can lead to a breakdown in communication and collaboration, making a fork an escape from the toxic social dynamics.
• Bureaucracy and Process Overhead: Some contributors may fork to avoid the time-consuming bureaucracy of consensus-driven processes, allowing them to work and iterate at a faster, unhindered pace.

Technical and Practical Needs

These are practical requirements that the original project is failing to meet.

• Stagnant or Discontinued Development: If the original project has lost momentum, is abandoned, or is no longer maintained by the original authors, a fork is created to continue its progress and provide essential maintenance, bug fixes, and security updates for its user base.
• Need for Major Technical Overhaul: Sometimes, a fork is initiated to implement a radical, breaking change or a major architectural rewrite (like porting to a new platform or removing a fundamental dependency) that the original project is unwilling or unable to accommodate.
• Simplification or Pruning (Leaner Version): Developers may fork to create a simpler, leaner version of the project by removing features they consider "bloat," complexity, or "garbage," aiming for a more focused or smaller codebase.
• Experimentation: Forking is a default workflow in platforms like Git/GitHub for non-core contributors to safely experiment with new ideas or features without risking the stability of the main project. While many of these forks aim to merge back, some may diverge permanently.

Solutions for Coordinated Diversity and Managed Proliferation

Culture & Social Solutions

• Promote a "Merge-First" Ethos: Cultivate a community culture where forking is seen as a temporary exploration tool rather than a permanent path. Developers should be encouraged to make a good-faith effort to reintegrate (merge) their work into the main project before deciding on a hard fork.
• Decouple Criticism from Identity: Foster an environment where technical critique is separated from personal attacks or identity. This reduces the social friction and personal acrimony that often drives developers to fork simply to escape a hostile environment.
• "Feeder Project" Recognition: Officially recognize and give credit to forks that serve as testbeds for new features. The main project can publicly list these "feeder projects," acknowledging their valuable role in experimentation and signaling to users which forks are likely to feed back into the canonical version.

Governance Solutions

• Clear and Transparent Decision-Making: Implement a well-documented governance model that clarifies how decisions are made (e.g., voting, consensus, BDFL-dictated) and who holds the power. This prevents forks driven by confusion or the feeling of being shut out.
• Formalize the Project Split/Fork Process: Establish clear, agreed-upon criteria for when a legitimate hard fork is warranted (e.g., philosophical schism, major technical divergence). A formal process can help the community recognize and support two distinct projects rather than a confusing, fragmented mess.
• Establish a Technical Review Board (TRB): Create a rotating group of trusted, senior contributors from various factions to mediate technical disputes that often lead to forking. The TRB's role is to objectively assess and recommend integration strategies for controversial features.

Infrastructure & Methods Solutions

• Modular Architecture and Microservices: Encourage developers to design the project with a highly modular architecture. This allows developers to fork or replace only the specific component (or module/microservice) they want to modify, rather than the entire codebase. This minimizes the scope of the diverging code.
• Standardized API/Interfaces (Contract-First): Enforce strict interfaces (APIs) between project components. As long as a developer's fork maintains compliance with the main project's established API, the original codebase can safely integrate the forked component, lowering the barrier to merging.
• Canonical Artifact Hash Registry (Web3 Concept): Borrowing from the Web3 concept of provenance, the core project could maintain a public, immutable, and easily verifiable registry of cryptographic hashes for all official releases (the digital commons). This allows developers and users to quickly and automatically verify if a file they obtained is the canonical version or a modified copy, directly addressing the integrity and provenance issue you raised.

Economic Solutions

• Sponsor Coordination Efforts: Encourage and fund third-party organizations or individuals whose explicit role is coordinating development between the main project and major, active forks. This formalizes the relationship and resources for merging.
• Bounties for Integration: Offer financial bounties specifically for contributors who successfully merge features developed in a fork back into the main project. This incentivizes the reconciliation of parallel development efforts.
• Incentivize Tooling for Diffing and Merging: Fund the development of advanced tooling that automatically highlights, compares, and suggests merge strategies for deeply divergent codebases. Reducing the technical cost of merging makes it a more attractive option than continued isolated development.

These solutions aim to use social pressure, clear rules, and technical tools to channel parallel development efforts back towards a central, canonical stream, maximizing the collective benefit of open-source freedom.

Case Studies in Fragmentation: Success and Failure

The way projects handle this tension dictates their long-term health:

Case Study	Fragmentation Driver	Outcome & Lessons
Linux Kernel	Technical & Scale (Tens of thousands of developers)	Success in Consolidation. Maintained unity through strong BDFL (Benevolent Dictator for Life) governance and the Git infrastructure, which was specifically designed to make merging code from distributed "forks" fast and efficient. The solution was governance plus tooling.
MySQL vs. MariaDB	Economic & Governance Fear (Oracle acquisition)	Successful Fragmentation. The new project (MariaDB) maintained high technical compatibility (a "drop-in replacement"). This reduced the market confusion and switching costs, turning a destructive split into a competitive one that ultimately benefited the open-source user base.
The UNIX Wars	Corporate Self-Interest	Unsuccessful Fragmentation. Competing corporate alliances (OSF vs. UI) created multiple, incompatible versions of UNIX to gain proprietary hardware advantage. The failure to standardize caused massive market confusion, dissipated developer resources on constant porting, and ultimately cleared the path for Microsoft Windows NT.

The lesson is clear: Coordination is key. When social, economic, or governance disputes cannot be resolved, the project suffers a devastating loss of consolidated effort.

The Web3 Solution: Incentivizing Cooperation via Code

Web3 offers a framework to solve these failures by making governance and economic incentives algorithmic and transparent through its core primitives. Blockchain technology moves the power from institutions and social consensus into the code itself.

Solving Provenance and Integrity: The Immutable Ledge

The blockchain's immutability directly solves the problem of "Was this file modified?"

• Canonical Artifact Registry: Instead of relying on trust, the main project publishes the cryptographic hash (digital fingerprint) of every official source code release to an immutable blockchain. Any developer or user can instantly and trustlessly verify that their downloaded file is an exact, canonical copy simply by checking its hash against the on-chain record.
• Code-Identity Tokens (SBTs): Soulbound Tokens (SBTs)—non-transferable NFTs tied to a developer’s identity—can certify specific contributions. If a library is forked, the code’s original, authenticated components remain verifiable via the SBT, granting immutable credit and provenance to the original author.

Solving Economic and Governance Conflicts: DAOs and Tokens

The biggest forks (like MariaDB) happen when developers feel shut out or financially misaligned. Decentralized Autonomous Organizations (DAOs) and Governance Tokens align financial self-interest with the project's success.

Web3 Primitive	Fragmentation Problem Solved	Mechanism for Coordination
Governance Tokens	Economic Misalignment (No financial reason to merge)	Treasury and Bounty Incentives: The project’s funds are controlled by a DAO smart contract. Tokens are issued to core contributors. This mechanism can issue bounties specifically for merging features from forks back into the canonical project. It creates a financial incentive to coordinate rather than developing in isolation.
Decentralized Autonomous Organizations (DAOs)	Governance Schism (The "UNIX Wars" problem)	Transparent, Code-Enforced Governance: The rules for project evolution (e.g., funding allocation, feature approval) are written into a smart contract. This provides a transparent, dispute-resistant voting mechanism, reducing the arbitrary rejections or personality clashes that often trigger permanent forks.
Reputation NFTs (Dynamic)	Social Friction (Rejection of contributions)	Verifiable Merit: Non-financial incentives, like Dynamic NFTs whose metadata levels up with every successfully merged pull request, formalize a public ledger of merit and reputation. This channels developer effort back to the canonical branch to accrue verifiable clout.

Web3 as the Operating System for Collaboration

Web3 is not just about digital money; it is about providing the infrastructure for transparent, incentivized, and coordinated collaboration on digital assets.

By using the core properties of blockchain, immutability, transparency, and programmable incentives, open-source communities can move beyond the inherent limitations of copying files. They can transform the freedom to fork from a risk of debilitating fragmentation into a strategy for diversified exploration that is financially and socially incentivized to merge back into the canonical common. This new era promises to maximize the accumulated effort of developers worldwide, ushering in the age of the Coordinated Digital Commons.

-----------------------

Sensorica is implementing its OVN model for material peer production. You can donate to support the amazing people who have sacrificed for the past 15 years to refine peer production.

NOTE: This post has been produced by Tibi with the help of AI, encapsulating Sensorica's 15 years of uninterrupted experience with material peer production, embracing complexity, leveraging emergence.