Risk of Developer Capture

[BitcoinErrorLog]

BCAP should also consider the potential risks of developer capture. Bitcoin's development community is diverse, but with Bitcoin Core acting as the de facto reference client, the power dynamics around its maintainers can become problematic. There is an implicit centralization risk if a small group of maintainers becomes the gatekeepers of what is included or excluded from Bitcoin’s codebase.

This obviously poses a problem with engineer-driven speculative changes.

A system that relies on a single code repository or a limited group of maintainers inherently risks influence from centralized entities—either through coercion, corruption, or misaligned incentives. Encouraging multiple implementations reduces this risk and distributes decision-making power, thus supporting the anti-capture ethos of Bitcoin.

[moneyball]

BCAP currently addresses this topic in these ways:

1. Describes the importance of having the option for alternative clients to change consensus rules
2. Points out that a developer incentive may be that they're paid by someone

What are other ways to address this?

[BitcoinErrorLog]

Coordinated Collusion:
Developers can introduce seemingly minor changes that set the stage for later, more disruptive alterations, such as how RBF progressed thru mempoolfullrbf, then =0 to =1 undermining 0-conf transactions and its users. This staged approach risks reshaping Bitcoin in ways beneficial to a small group but detrimental to broader user interests.

Elite Complexity & Code Gatekeeping:
Developers may create overly complex systems, effectively gatekeeping parts of Bitcoin’s codebase. They may establish "fiefdoms" where only insiders fully understand and control critical components, reducing accountability and transparency.

Infiltration by State Actors:
Developers could build trusted reputations, only to later push for changes, and maintainer appointments, favorable to state interests.

Narrative Capture:
Beyond code, developers can distort & manipulate technical narratives— overstating importance, promoting niche speculative ideas that pave the way for special interests, ultimately neglecting and compromising broader user interests.

Mitigations:

Multiple Implementations:
Supporting alternative compatible clients reduces the control currently held by Bitcoin Core maintainers. Competition makes coordinated malicious soft forks harder and increases transparency.

Simplicity & Scrutiny:
Cultivate a culture where complex changes face higher scrutiny. Changes that aren't simple should have a higher bar to prove their necessity, ensuring no unnecessary or speculative complexity is used to gatekeep or subvert Bitcoin or its development.

Incentive Transparency:
As a culture, developers should be expected to be open about their funding sources. Transparency around incentives reduces hidden biases and keeps decision-making accountable; lack of transparency is a red flag here, despite no enforceable requirements to be transparent.

Default to "No":
Reinforce that Bitcoin's default is "No." Any change must display obvious overwhelming value; otherwise, it should be rejected. Developer capture succeeds when changes are assumed necessary.

It could be argued Bitcoin Core is already captured in various ways, and that would certainly be a useful perspective to write BCAP from.

[lynalden]

Perhaps a tangible starting point to add this to the paper, is that the protocol developer stakeholder group could be given an extra power that says something along the lines of "can add subtle code changes that are not understood by other stakeholder groups but that might be impactful to them regardless"