Table 3 lists the top nodes that, on average, lie “closest” to all others in the DeSci token–infrastructure network. Overall, we can see that DeSci relies heavily on a small set of wallets, analytics tools, and social platforms that are both highly connected and structurally central. Besides the key findings mentioned in Part IV.a reinforced by the results in this table, I highlight the fact that GitHub (0.468927) showing up in the table reflects the central role of code hosting and open-source collaboration across projects.

When centralities are averaged by node type (Figure 3), social platforms and tokens have the highest average degree and between-ness, with tokens and social nodes also exhibiting the highest average closeness, indicating that they tend to sit near the structural centre of the network. So, does the network actually split into communities?

Community detection identifies five structural communities comprising 24, 21, 18, 13, and 8 nodes, respectively (Figure 4). Each cluster contains a mixture of node types—tokens, networks, wallets, auditors, social platforms, and explorers—rather than a single homogeneous category. Visually, there is no “Ethereum-only” or “wallet-only” community; instead, tokens tend to cluster with the particular combinations of infrastructure services they use.

The layout also highlights that communities are not isolated components. Edges connect nodes across community boundaries, and several tokens and infrastructure nodes sit near the interfaces between clusters. This is consistent with the global statistics reported earlier in Part IV.a (single connected component, short average path length): communities represent regions of relatively denser connection, not disconnected subgraphs. Next, we will find out what’s inside each community.

Figure 5 summarizes the size and composition of each community. In absolute terms, C0 and C1 are the largest groups, with 24 and 21 nodes respectively, whereas C2, C3, and C4 contain 8, 18, and 13 nodes. Tokens are concentrated in C0 and C1 (11 and 10 tokens), with the remaining communities each containing four tokens. This means that most projects in this snapshot fall into two large token-dense communities, while a smaller number of tokens populate three more specialized clusters.

When node types are normalized to percentages, C0 and C1 remain strongly token-oriented—roughly half of their nodes are tokens—but they also include multiple wallets, explorers, and at least one network apiece. In contrast, the smaller communities have more distinctive profiles. C2, despite containing four tokens, has relatively few supporting nodes overall (one network, one wallet, one explorer, and a single social platform) (Figure 5). C3 and C4 show higher shares of infrastructure relative to tokens: C3 combines tokens with a notable presence of auditors and social platforms, whereas C4 is characterized by many wallets and explorers but no social nodes (Figure 5).

These patterns support the interpretation of communities as “infrastructure bundles” rather than purely chain-specific groupings. The tokens in C0 and C1 appear to use a broad, relatively standard set of services; whereas the tokens in C2–C4 tend to rely on narrower or more specialized combinations of infrastructure.

The per–node-type community breakdown (Figure 6) clarifies how the five detected communities differ in composition.

• Tokens. Communities C0 and C1 contain the largest numbers of tokens (11 and 10, respectively), while the remaining communities each contain four tokens.

• Networks. Every community contains one to two blockchain network(s). Networks are broadly distributed and do not by themselves determine community boundaries.

• Wallets. Wallet nodes are more unevenly distributed. C1 and C4 each contain five wallets, whereas C0 has three, and C2 and C3 only one wallet each. This suggests that communities C1 and C4 represent infrastructure bundles where user-access options are relatively diversified, while C2 and C3 are anchored around a smaller set of wallets.

• Auditors. Auditors show a pronounced skew. C3 contains three auditor nodes, C0 and C4 contain one each, and C1 and C2 contain none. Thus, any publicly signalled audit activity in this snapshot is concentrated in a subset of communities, with C3 standing out as relatively “audit-heavy.”

• Social platforms. Social nodes are present only in C0 (4), C2 (1), and C3 (4). C1 and C4 contain no social nodes. Combined with the earlier centrality results, this implies that active, linked social infrastructure (e.g., project accounts on X or Telegram) is unevenly distributed: some communities appear much more socially connected than others.

• Explorers. Explorers are relatively frequent in C0, C1, and C3 (each with 4 explorers), but less common in C2 and C4 (one explorer each). This hints that observability and analytics tooling are richer in the larger communities and in C3, while tokens in C2 and C4 rely on a narrower set of explorer integrations.

Taken together, these distributions show that each community has a characteristic profile:

• C0 and C1 are token-dense and broadly provisioned with wallets and explorers.

• C2 is small and relatively sparse, with minimal supporting infrastructure.

• C3 is audit- and social-intensive.

• C4 is wallet- and explorer-heavy but socially thin.

No single node type dominates community membership; instead, communities correspond to different combinations of services that tokens tend to adopt together.
These community assignments should be treated as structural groupings driven by connection patterns, not as definitive categorizations of project type, quality, or function.

Part IV has treated the DeSci token–infrastructure ecosystem as a single heterogeneous network and shown that it is neither a flat marketplace of interchangeable tools nor a set of neatly separated silos. Instead, a small group of wallets, explorers, analytics platforms, and social channels sit at the structural centre, while tokens cluster into distinct infrastructure bundles with uneven levels of social visibility, observability, and security signalling. Read through a governance lens, this means that “infrastructure choice” is already a form of soft coordination: by plugging into a particular bundle, projects implicitly co-locate with specific intermediaries, norms, and failure modes, and shocks to a few central nodes—whether from outages, policy changes, censorship, or business model shifts—are likely to propagate through many tokens at once.

In Part V, I reinterpret infrastructure choice as a system design problem, treating these structural patterns as inputs to questions of governance (“who effectively has power over whom?”), security (“which correlated failures are we implicitly accepting?”), and architecture (“how might we rewire the system to reduce single points of failure and audit deserts?”). The aim is not to prescribe a single “correct” stack, but to extract practical design lessons—checklists, stress tests, and alternative patterns—that DeSci projects, ecosystem funders, and even traditional funding agencies (which may never touch a token directly but do underwrite digital platform development) can use to understand how their choices shape the infrastructure available to participants in this emerging market.

This analysis is subject to several important limitations:

• Snapshot design. It is based on a single snapshot dataset and does not consider network evolution over time. The reported network structure reflects the ecosystem state at the time of data collection and may not predict future trends.

• Binary relationships. All network relationships are treated as binary (present/absent) without weighting by importance or frequency.

• Undirected graph assumption. The network graph assumes symmetric relationships; directionality (e.g., flows of value or information) is not modelled.

• Equal edge weight. All edges have equal weight, regardless of metrics outside the working dataset such as token market capitalization or transaction volume.

• Independence between entity types. The analysis implicitly assumes that relationships between different entity types (e.g., network–wallet) are independent of each other beyond what is encoded in the observed connections.

• Artificial “no auditor” node. Tokens without audits are connected to an auditor_none node, which is an artificial construct that may affect network metrics (e.g., centrality and community structure).

• Multipartite structure. The network is a multi-partite graph (tokens connect to other entity types, but entities of the same type do not directly connect to each other). This means that if two tokens interact with each other, this information is not included. This limitation arises from data availability on CoinMarketCap, because token listings do not report token–token interactions.

• Small sample size. With only a few dozen tokens (≈35) used to map the network, the sample is relatively small, which may limit the generalization of findings.

• Approximate community detection. Community detection is based on the Louvain algorithm, which is approximate and may not find the globally optimal partition.

These limitations should be kept in mind when interpreting the structural patterns described above and when considering any governance or design implications drawn from them.