Networks with no owner still require developers, and the arrangements funding that work vary substantially and matter.

Volunteer contribution

The original model, with developers working unpaid.

Which does not scale and produced maintainer burnout that is documented across open-source generally.

Critical infrastructure maintained by unpaid individuals is a recognised systemic risk.

Foundations

Non-profit entities holding assets and funding development.

Which is the most common arrangement for larger networks.

Governance of these foundations is itself a concentration of influence.

Corporate sponsorship

Firms employing developers who work on the protocol.

Which funds substantial work and raises questions about direction.

Employer interests and protocol interests are not always aligned.

Grant programmes

Funding specific work from treasury or foundation resources.

Which requires evaluation and accountability.

Milestone-based disbursement produces better outcomes than upfront payment, which the record supports.

Protocol revenue

Fees directed to a treasury funding development.

Which aligns funding with usage.

Deciding how much to take and who allocates it is a governance question.

Token allocations

Developers holding tokens whose value depends on the network.

Which aligns incentives and creates pressure toward decisions that support price.

Vesting arrangements are intended to extend the alignment.

Retroactive funding

Rewarding work after it has demonstrated value.

Which avoids the problem of assessing proposals in advance.

Several networks have run programmes on this model with published results.

Why this matters

Who funds development influences what gets built and what does not.

Funding arrangements are generally published and are worth reading for any network you depend on.

Security research funding

Audits, bounties and formal verification require sustained expenditure.

Which is generally funded from foundation or treasury resources.

Underfunding here is a recognised systemic risk across open-source infrastructure.

Public goods funding experiments

Mechanisms directing funds to widely used but unmonetised infrastructure.

Which include quadratic funding rounds and retroactive reward programmes.

Results have been published and are mixed but genuinely informative.

Conflicts and disclosure

Developers holding tokens, employed by interested parties, or funded by foundations they influence.

Which is generally disclosed and is worth knowing.

Governance processes with published participation records make this checkable.

Contributor sustainability

Burnout and turnover among maintainers is documented across open source.

Which affects protocol continuity directly.

What to check

Who funds the developers of anything you rely on, and whether that funding is disclosed.

Foundation governance

Who controls a foundation and how it allocates resources.

Which is a concentration of influence in nominally decentralised networks.

Governance documents and accounts are published by the more transparent ones.

Client team diversity

Multiple independent implementations require multiple funded teams.

Which is expensive and is what produces resilience against implementation bugs.

Underfunded minority clients are a documented risk.

Grants versus employment

Project-based funding produces different incentives from salaried work.

Which affects long-term maintenance of unglamorous infrastructure.

Maintenance is consistently harder to fund than new development.

Transparency practices

Published budgets, spending reports and grant decisions.

Which vary enormously between networks.

The question worth asking

If the current funding source stopped, who would maintain this and for how long.

Why this is worth attention

Networks are described as having no owner, and someone is paying the people writing the code.

Who that is, and what happens if they stop, is a dependency worth understanding for anything you rely on.

The information is generally published and is rarely read.

What to look for

Published budgets, grant decisions, contributor affiliations and treasury holdings.

Which the better-run networks publish routinely.

Opacity here is itself informative about how a network is actually governed.

The structural tension

A network with no owner still needs sustained, funded, skilled work, and every arrangement for providing it creates some concentration of influence.

Foundations, corporate employers, treasuries and grant committees all shape what gets built.

There is no arrangement that avoids this entirely, and the practical question is whether it is disclosed and accountable.

Comparison with conventional open source

Critical infrastructure maintained by underfunded volunteers is a documented problem well beyond this field.

Which produced foundations, corporate funding and sponsorship programmes there too.

The difference here is the availability of protocol revenue and token treasuries as funding sources.

Accountability mechanisms

Published spending, milestone reporting and community review of grants.

Which the better-governed networks operate and many do not.

Grant programmes without accountability have consistently produced poor outcomes.

A closing note

The people writing the code that secures billions are employed by someone, and who that is shapes what gets prioritised.

For any network you depend on, the funding arrangement is generally published, and reading it once tells you more about the project's direction than any roadmap.

The dependency nobody lists

Every risk assessment covers contract risk, oracle risk and custody risk, and almost none covers whether the people maintaining the code will still be paid next year.

That is a real dependency with a real failure mode, and it is checkable.