• 1. The Paradox of Decentralized Development
  • 2. Dunbar’s Number and the Limits of Human Trust
    • 2.1 The Cognitive Constraint
    • 2.2 Implications for Open Source Development
    • 2.3 The 5 Core Devs Pattern
  • 3. Scaling to 12 Contributing Teams
    • 3.1 The Problem of Scale
    • 3.2 The 12 Teams Pattern
    • 3.3 Coordination Without Hierarchy
    • 3.4 The Trust Gradient
  • 4. The Global Full Node Network: Trust Through Verification
    • 4.1 The Ultimate Check on Power
    • 4.2 Proof-of-Work as Commitment Device
    • 4.3 The Dunbar Number at Global Scale
    • 4.4 Nested Trust Layers: A Summary
  • 5. Building the Core Team
    • 5.1 Identifying the Founders
    • 5.2 The Apprenticeship Model
    • 5.3 Maintaining Cohesion
  • 6. Expanding to Contributing Teams
    • 6.1 Identifying Team Domains
    • 6.2 Onboarding Team Leads
    • 6.3 Fostering Team Identity
    • 6.4 The 12-Team Limit
  • 7. Cultivating the Global Node Network
    • 7.1 Making Node Operation Easy
    • 7.2 Aligning Incentives
    • 7.3 Fostering Operator Community
    • 7.4 The 10,000 Node Milestone
  • 8. Other Breakthroughs in Scaling Trust
    • 8.1 The Web of Trust as Reputation Layer
    • 8.2 Economic Commitment Through Staking
    • 8.3 Gradual Key Rotation and Recovery
    • 8.4 Client Diversity as Resilience
    • 8.5 The Role of Foundations and Non-Profits
  • 9. Case Study: Bitcoin’s Development Evolution
    • 9.1 The Satoshi Era (2009-2011)
    • 9.2 The Gavin Andresen Era (2011-2014)
    • 9.3 The Wladimir van der Laan Era (2014-2021)
    • 9.4 The Current Era (2021-present)
  • 10. Case Study: Nostr’s Emerging Structure
    • 10.1 The Fiatjaf Era (2020-present)
    • 10.2 Emerging Teams
    • 10.3 The Node Network
    • 10.4 Future Trajectory
  • 11. Practical Guidance for Builders
    • 11.1 Starting a New Project
    • 11.2 Growing the Core
    • 11.3 Forming Teams
    • 11.4 Cultivating the Node Network
    • 11.5 Preparing for Your Own Departure
  • 12. The Shape of Things That Work
  • References

§1. The Paradox of Decentralized Development

The dream of censorship-resistant platforms contains an inherent contradiction. To resist control by any single actor, the platform must be developed and maintained by a distributed group of contributors. Yet distributed groups face well-known coordination problems: communication overhead, conflicting visions, security vulnerabilities, and the constant risk of fragmentation or capture.

How do successful projects navigate this tension? Bitcoin, now entering its second decade, has maintained coherent development through multiple generations of contributors. Nostr, though younger, shows similar patterns emerging. Both suggest that there is a natural structure to decentralized development—a structure that respects both human cognitive limits and cryptographic security requirements.

This paper proposes that censorship-resistant platforms evolve through distinct organizational phases:

1. The Core Phase: A small group of 3-7 developers who establish the foundational architecture and share deep trust.
2. The Contributing Phase: Expansion to approximately 12 teams, each focused on specific components, coordinated through rough consensus and running code.
3. The Node Phase: A global network of full node operators who enforce consensus rules, providing the ultimate check on developer power.

This progression is not arbitrary. It respects Dunbar’s number—the cognitive limit on stable social relationships—while leveraging cryptographic proof-of-work to create objective, verifiable commitment to the network.

§2. Dunbar’s Number and the Limits of Human Trust

§2.1 The Cognitive Constraint

British anthropologist Robin Dunbar proposed that primates, including humans, have a cognitive limit on the number of stable social relationships they can maintain. Based on neocortex size relative to brain volume, Dunbar calculated this limit at approximately 150—now known as Dunbar’s number.

This is not a firm boundary but a statistical observation. Below 150, relationships can be maintained through personal knowledge and direct interaction. Above 150, organizations must rely on hierarchy, written rules, and formal structures. The military uses squads of 8-10, platoons of 30-50, companies of 100-200—each level corresponding to cognitive limits on direct command and trust.

§2.2 Implications for Open Source Development

Open source software development, particularly for censorship-resistant systems, faces a trust problem that is fundamentally human. Code can be reviewed. Signatures can be verified. But who gets commit access? Who reviews the reviewers? Who decides when a change is ready for inclusion?

These questions cannot be solved by cryptography alone. They require human judgment, and human judgment is constrained by Dunbar’s number.

A core developer team of 150 would be unworkable. Communication overhead would consume all available time. Trust would become diffuse and unmanageable. Security would suffer as it became impossible to know who truly understood the system.

Conversely, a core team of 3-7 is workable. Everyone can know everyone. Trust can be earned through direct interaction. Decisions can be made through discussion, not formal process.

§2.3 The 5 Core Devs Pattern

Observation of successful censorship-resistant projects reveals a striking pattern: core development teams cluster around 3-7 individuals.

Bitcoin’s early development was driven by Satoshi Nakamoto alone, then expanded to a handful of trusted contributors. Today, Bitcoin Core has approximately 5-10 developers with merge privileges—a number that has remained stable for years despite the project’s enormous success.

Nostr, still in its early stages, shows a similar pattern. The protocol’s creator, fiatjaf, maintains ultimate authority, but a small circle of trusted contributors has emerged around specific implementations and proposals.

This is not coincidence. Five is approximately the number of people one can truly know, truly trust, and truly coordinate with in real time. It is the Dunbar number for intimate relationships—the group size where everyone can have dinner together and resolve differences face-to-face.

§3. Scaling to 12 Contributing Teams

§3.1 The Problem of Scale

A project cannot remain at five developers indefinitely. The work required to build and maintain a censorship-resistant platform exceeds the capacity of any small group. New contributors must be onboarded. New expertise must be brought in. New perspectives must be incorporated.

But how does a project scale without losing coherence? How does it expand beyond the Dunbar limit without descending into chaos?

The answer lies in nested trust layers: the core group of 5 remains the ultimate authority, but it delegates responsibility to approximately 12 contributing teams, each focused on a specific domain.

§3.2 The 12 Teams Pattern

Twelve is a number that appears repeatedly in human organization. Twelve apostles. Twelve tribes of Israel. Twelve jurors. Twelve is approximately the number of people one can comfortably know as acquaintances—not intimate friends, but trusted colleagues whose competence and character one can assess.

In the context of censorship-resistant platforms, 12 contributing teams might include:

• Core protocol development (maintaining the reference implementation)
• Relay implementation (for Nostr) or node software (for Bitcoin)
• Wallet development (user-facing applications)
• Documentation and education
• Security auditing
• Economic analysis
• Lightning Network integration
• Mobile client development
• Desktop client development
• Testing and quality assurance
• Community coordination
• Research and specification (new NIPs or BIPs)

Each team operates semi-autonomously, with its own internal structure (likely another 3-7 person core). The core group of 5 coordinates across teams, resolving conflicts and maintaining overall vision.

§3.3 Coordination Without Hierarchy

The challenge at this scale is coordination without formal hierarchy. Censorship-resistant projects cannot simply appoint managers and expect obedience. They must rely on rough consensus and running code—the Apache way, the IETF way, the open source way.

This works because the stakes are aligned. Everyone contributing to a censorship-resistant platform shares a common goal: building something that cannot be controlled by any single actor. This shared commitment creates social pressure to cooperate, even in the absence of formal authority.

The core group of 5 does not command the 12 teams. It convenes them. It synthesizes their work. It resolves disputes when consensus cannot be reached. But if a team consistently produces high-quality work that aligns with the project’s goals, it will be trusted to continue without interference.

§3.4 The Trust Gradient

Trust in this model is not binary but gradient. The core group of 5 has earned deep trust through years of demonstrated competence and commitment. The 12 teams have earned moderate trust through consistent contribution. Individual contributors within teams have trust appropriate to their role and history.

This gradient allows the project to scale while maintaining security. A malicious actor cannot simply join a team and immediately gain commit access. They must work their way up the trust gradient, earning credibility through demonstrated value over time.

§4. The Global Full Node Network: Trust Through Verification

§4.1 The Ultimate Check on Power

The core developers and contributing teams write the code. But they do not control the network. That power belongs to the global network of full node operators who choose whether to run that code.

This is the genius of Bitcoin, and it applies equally to Nostr. Full nodes (or full relays, in Nostr’s case) enforce consensus rules. If developers propose a change that node operators consider harmful, they can simply refuse to upgrade. The developers have influence, but not control.

§4.2 Proof-of-Work as Commitment Device

Proof-of-work serves a function beyond securing the blockchain. It also serves as a commitment device for node operators. Running a full node costs money—in hardware, bandwidth, electricity, and time. This cost creates skin in the game. Node operators have invested in the network. They are not passive consumers but active participants with aligned incentives.

In Nostr, the equivalent is relay operation. Running a relay costs money and effort. Relay operators have skin in the game. They are not merely users but infrastructure providers. Their investment creates commitment to the network’s health.

§4.3 The Dunbar Number at Global Scale

The global node network operates far beyond any human cognitive limit. No one can know all node operators. No one can personally trust them. Yet the network coheres through cryptographic verification and economic incentive.

This is the transition from trust in persons to trust in mathematics. The core developers are trusted because they are known. The node operators are trusted because they are verifiable—their signatures, their hashrate, their adherence to consensus rules can be checked objectively.

§4.4 Nested Trust Layers: A Summary

The complete architecture looks like this:

Each layer has its own trust dynamics, its own coordination methods, and its own relationship to the others. The system coheres because each layer checks the layers above it. Node operators can reject bad code. Contributors can fork if core becomes corrupt. Users can choose different clients if they disagree with defaults.

§5. Building the Core Team

§5.1 Identifying the Founders

Every censorship-resistant project begins with an idea and a person (or small group) capable of implementing it. Satoshi Nakamoto. Fiatjaf. These founders set the initial direction and write the first code.

But a project cannot remain a solo endeavor. The first task after establishing the basic architecture is to identify potential core team members. Who shares the vision? Who has the technical skills? Who has demonstrated commitment through contribution?

§5.2 The Apprenticeship Model

Core team members are not appointed; they emerge. They start by contributing patches, documentation, or testing. They engage in discussions, demonstrating understanding and judgment. They take on increasing responsibility over time, always earning trust through demonstrated competence.

This apprenticeship model serves two purposes. First, it ensures that core team members truly understand the system before gaining privileged access. Second, it creates a natural vetting process—time reveals character in ways that interviews cannot.

§5.3 Maintaining Cohesion

Once formed, the core team must maintain cohesion. This requires:

• Regular communication: Daily if possible, weekly at minimum. Video calls, chat, email—whatever works for the group.
• Shared values: A common understanding of the project’s goals and acceptable trade-offs.
• Conflict resolution mechanisms: Ways to resolve disagreements without fragmentation.
• Succession planning: Preparation for the eventual departure of any member.

The core team’s cohesion is the project’s most valuable asset. It cannot be bought or programmed. It must be cultivated through shared experience over time.

§6. Expanding to Contributing Teams

§6.1 Identifying Team Domains

As the project grows, natural divisions of labor emerge. Wallet development requires different expertise than relay implementation. Documentation requires different skills than security auditing. The core team’s job is to recognize these divisions and encourage capable individuals to take ownership.

Domain identification is both technical and social. Technically, the codebase should be modular enough that teams can work independently without constant coordination. Socially, there should be clear boundaries of responsibility so that contributors know where they can make a difference without stepping on toes.

§6.2 Onboarding Team Leads

Each contributing team needs a lead—someone who coordinates work, reviews contributions, and represents the team to the core group. Team leads should be chosen based on demonstrated competence and commitment, not appointed arbitrarily.

The relationship between team leads and the core group is critical. Team leads need enough autonomy to do their work effectively. The core group needs enough visibility to ensure alignment. Regular check-ins, shared roadmaps, and transparent communication channels help maintain this balance.

§6.3 Fostering Team Identity

Teams function better when members identify with the team’s mission. This means giving teams meaningful autonomy over their domain. It means celebrating team achievements publicly. It means protecting teams from excessive interference while holding them accountable for results.

Team identity should not become tribalism. The project’s overall success matters more than any team’s prestige. Core developers must model this attitude, consistently prioritizing the whole over any part.

§6.4 The 12-Team Limit

Why 12? Because that’s approximately the number of distinct domains a core group of 5 can effectively coordinate. Beyond 12, communication overhead becomes unmanageable. Relationships become too diffuse. Trust becomes too diluted.

If a project grows beyond 12 natural domains, some teams must be grouped under broader categories. For example, multiple wallet teams might coordinate through a single representative. This adds hierarchy but preserves the core group’s ability to maintain coherent oversight.

§7. Cultivating the Global Node Network

§7.1 Making Node Operation Easy

The global node network is not a development project; it’s a community of operators. To grow this network, node operation must be made as easy as possible. Clear documentation. Simple installation. Automated updates. Responsive support.

Bitcoin succeeded in part because running a full node became progressively easier. Raspberry Pi images, plug-and-play appliances, and user-friendly software lowered the barrier until anyone with a modest computer could participate.

Nostr is following a similar path. Projects like Umbrel, Start9, and Citadel make relay operation accessible to non-experts. Pyramid and other lightweight implementations reduce hardware requirements. The easier it is to run a relay, the more relays the network will have.

§7.2 Aligning Incentives

Node operators need reasons to run nodes. For Bitcoin, the reason is sovereignty—running a node means not trusting anyone else’s view of the blockchain. For Nostr, the reason is similar—running a relay means controlling access to your content and your community.

But sovereignty alone may not be enough. Economic incentives can help. Paid relays, zap-enabled services, and Lightning integrations create revenue streams for operators. These align operator interests with network health—operators profit when the network thrives.

§7.3 Fostering Operator Community

Node operators are not anonymous cogs. They are people with questions, concerns, and ideas. They need forums for discussion. They need channels for support. They need recognition for their contributions.

A healthy operator community becomes a source of feedback for developers and a source of resilience for the network. Operators who feel connected to the project are more likely to stick with it through difficult times.

§7.4 The 10,000 Node Milestone

There is no magic number at which a network becomes censorship-resistant. But every additional node makes censorship harder. Every additional jurisdiction represented makes legal attacks more difficult. Every additional operator invested makes network collapse less likely.

The goal should be continuous growth—more nodes, more diversity, more resilience. Not because a specific number guarantees safety, but because the trend toward greater distribution is itself the safety.

§8. Other Breakthroughs in Scaling Trust

§8.1 The Web of Trust as Reputation Layer

Beyond Dunbar’s number, trust must be mediated. The Web of Trust concept, implemented through NIPs like NIP-85, provides a way to scale trust algorithmically. If Alice trusts Bob, and Bob trusts Carol, Alice can reasonably extend limited trust to Carol without ever meeting her.

This is not as strong as direct trust, but it is far better than no trust at all. Web of Trust enables communities to self-govern, filtering spam and harassment without central authority.

§8.2 Economic Commitment Through Staking

Proof-of-stake models in cryptocurrency have a parallel in Nostr: staking sats to demonstrate commitment. If posting costs a tiny amount, spam becomes expensive. If operating a relay requires a bond, malicious behavior has consequences.

Economic commitment does not replace social trust, but it supplements it. It creates objective evidence of investment that can be verified without personal knowledge.

§8.3 Gradual Key Rotation and Recovery

One of the hardest problems in cryptographic identity is key loss. If you lose your private key, you lose your identity. This is unforgiving, but it is also secure.

Breakthroughs in key rotation and social recovery are changing this. Schemes that distribute key shares among trusted friends allow recovery without central authority. Multi-signature arrangements allow shared control. These mechanisms scale trust by distributing it.

§8.4 Client Diversity as Resilience

Bitcoin learned the hard way that client monoculture is dangerous. When everyone runs the same software, a single bug can affect everyone. The same applies to Nostr.

Encouraging multiple independent client implementations creates resilience. Different clients have different bugs, different priorities, different perspectives. This diversity makes the network harder to attack and more adaptable to change.

§8.5 The Role of Foundations and Non-Profits

As projects mature, they often benefit from formal organizational support. The Bitcoin Foundation, the Nostr Institute (hypothetical), or similar entities can handle legal defense, fundraising, and coordination without controlling development.

These organizations must be carefully designed to support without dominating. Their role is service, not governance. They exist to help the community do what it already wants to do, not to tell it what to do.

§9. Case Study: Bitcoin’s Development Evolution

§9.1 The Satoshi Era (2009-2011)

Bitcoin began with one developer: Satoshi Nakamoto. Early contributions came from a handful of trusted individuals—Hal Finney, Gavin Andresen, Martti Malmi. The core group numbered fewer than 10.

§9.2 The Gavin Andresen Era (2011-2014)

After Satoshi’s departure, Gavin Andresen became lead maintainer. The core team expanded to include Jeff Garzik, Pieter Wuille, and others. Contributing teams emerged around specific areas—wallet development, mining software, documentation.

§9.3 The Wladimir van der Laan Era (2014-2021)

Wladimir van der Laan took over as lead maintainer, formalizing the role. The core team stabilized at approximately 5-10 individuals with merge privileges. Contributing teams grew to encompass dozens of regular contributors across multiple domains.

§9.4 The Current Era (2021-present)

Bitcoin Core development is now managed by multiple maintainers with a formal contribution process. Hundreds of contributors participate regularly. Thousands of node operators enforce consensus. The pattern of 5 core, 12 teams, global nodes is fully realized.

This evolution was not planned. It emerged naturally from the constraints of human cognition and cryptographic security. It is the shape that censorship-resistant development takes when left to find its own form.

§10. Case Study: Nostr’s Emerging Structure

§10.1 The Fiatjaf Era (2020-present)

Nostr is still in its first era, with creator fiatjaf as the central figure. A small core of trusted contributors has emerged around specific implementations—the Gossip client, the Coracle client, the Pyramid relay.

§10.2 Emerging Teams

Natural teams are forming around:

• Relay implementation (Pyramid, strfry, etc.)
• Client development (multiple independent teams)
• NIP specification (protocol improvements)
• Documentation and education
• Lightning integration (zaps, NWC)

These teams are not formally organized, but they coordinate through shared channels and overlapping contributors.

§10.3 The Node Network

Nostr’s relay network is already diverse, with hundreds of relays operating worldwide. Relay operators include individuals, communities, and commercial entities. This diversity provides the foundation for censorship resistance.

§10.4 Future Trajectory

As Nostr matures, we can expect the core group to formalize, contributing teams to multiply, and the relay network to grow. The pattern observed in Bitcoin will likely repeat, because it is the pattern that works.

§11. Practical Guidance for Builders

§11.1 Starting a New Project

If you are building a censorship-resistant platform, start small. Write the first code yourself. Recruit the first contributors personally. Build trust through direct interaction before formalizing anything.

§11.2 Growing the Core

When you have a working prototype, identify potential core team members. Look for people who contribute meaningfully, demonstrate understanding, and share your values. Bring them in gradually, giving increasing responsibility as trust develops.

§11.3 Forming Teams

As the project grows, recognize natural divisions of labor. Encourage capable individuals to take ownership of domains. Support them with resources and recognition, but give them autonomy to do their work.

§11.4 Cultivating the Node Network

Make node operation easy. Document everything. Support operators. Celebrate the network. The nodes are not just infrastructure; they are the ultimate check on developer power. Treat them with respect.

§11.5 Preparing for Your Own Departure

Every founder eventually leaves. Plan for this from the beginning. Cultivate successors. Distribute responsibility. Build systems that don’t depend on any single person. The project must outlive you.

§12. The Shape of Things That Work

Censorship-resistant platforms are not just technical artifacts. They are social systems. They are organizations of human beings trying to coordinate toward common goals while resisting control by any single actor.

The shape these systems take is not arbitrary. It is constrained by human cognitive limits—Dunbar’s number—and by cryptographic possibilities—proof-of-work, digital signatures, consensus rules. The successful projects will be those that respect these constraints, building nested trust layers that scale from intimate core to global network.

Five core developers. Twelve contributing teams. Thousands of full nodes. Millions of users. This is not the only possible shape, but it is the shape that has worked. It is the shape that emerges when you let the problem define the solution.

Build with this shape in mind. Trust your core. Empower your teams. Respect your nodes. The architecture of trust is not a design choice; it is a discovery. Find it, and your project may last long enough to matter.

§References

1. Dunbar, R.I.M. (1992). “Neocortex size as a constraint on group size in primates.” Journal of Human Evolution, 22(6), 469-493.

2. Nakamoto, S. (2008). “Bitcoin: A Peer-to-Peer Electronic Cash System.” Available at: https://bitcoin.org/bitcoin.pdf

3. fiatjaf. (2020). “Nostr: Notes and Other Stuff Transmitted by Relays.” Available at: https://github.com/nostr-protocol/nostr

4. NIP-01: Basic Protocol Flow. Available at: https://github.com/nostr-protocol/nips/blob/master/01.md

5. NIP-65: Relay List Metadata. Available at: https://github.com/nostr-protocol/nips/blob/master/65.md

6. NIP-85: Trusted Assertions (Draft). Available at: https://github.com/nostr-protocol/nips/pull/85

7. Raymond, E.S. (1999). “The Cathedral and the Bazaar.” O’Reilly Media.

8. Weber, S. (2004). “The Success of Open Source.” Harvard University Press.

9. Antonopoulos, A.M. (2017). “Mastering Bitcoin: Programming the Open Blockchain.” O’Reilly Media.

10. Dilger, M. (2023). “The Gossip Model.” Available at: https://mikedilger.com/gossip-model/