Concept · specification in progress · not deployed

Get funded by the projects that depend on you.

The Dependency Graph Funding Protocol (DGFP) is a proposal to send part of every donation down the npm dependency graph, to the packages that make each project possible. You don't apply, register or list anything. If your package is a dependency of something people fund, money flows to it.

The gap

Funding follows visibility. Donations go to the application or framework people can see. The parsers, test runners, build tools and small utilities underneath get little or nothing, even though every project above them is built on them.

The dependency graph already records who relies on whom. DGFP uses it to route money.

How it works

Someone donates to a package. Any package on npm, by name.
The package keeps two thirds. That share is paid to its maintainers' payout address.
One third goes to its dependencies. They are read from the package's published manifest, runtime and development dependencies alike. Build and test tooling is some of the least funded work in the ecosystem.
Every dependency does the same with what it receives. Value keeps spreading through the graph. Anyone can carry out a distribution and earn a small fee for doing it, so the system runs without an operator.

Example: a donation of 100 to a package with three dependencies.

your-app receives 100 · keeps 66.7 for its maintainers

↓ 33.3 split among its dependencies

dep-a

11.1

dep-b

11.1

dep-c

11.1

↓ dep-b keeps 7.4 and passes 3.7 to its own dependencies

…and so on down the graph

Real packages have dozens of dependencies, so each one's slice is thinner, but the total that moves down each level is still a third of what arrived. The packages at the edges have dependencies too; they are left out to keep the picture readable.

The graph is read, not written

No one declares their dependencies to the protocol. They are derived from what you already published to npm, by a public and deterministic rule that anyone can re-run and check.

Nothing to do to be included

If a funded project depends on your package, your package is already in the graph.

Nothing to game

A project can't steer its donations to accounts it controls by listing invented dependencies. The list comes from the registry, not from the project.

Your package may already be earning

A package doesn't need an owner to receive. What it receives accumulates, and its share for its own dependencies keeps flowing on. When you claim the package, you set where its share is paid and receive what accumulated before you arrived.

The claim process below is a working proposal. The details may change while the specification is written.

Two ways to prove you maintain a package

Through a release Strongest

Add an entry with your payout address to the funding field of your package.json and publish a version. Only someone who can publish the package can do this. Your existing funding entries stay alongside it.

"funding": [
  { "type": "github", "url": "https://github.com/sponsors/you" },
  { "type": "…", "url": "…your payout address…" }
]

Illustrative. The exact format is not final.

Without a release Fastest

Publish a small throwaway package from your npm account containing your payout address. The protocol checks that your account is listed as a maintainer of your package. It takes seconds and doesn't touch your users.

Still being verified for scoped and organisation-owned packages, whose maintainer lists may not name individuals.

Pay a team, not a person

The payout address can be a splitter or multisig contract, so a project's funding reaches everyone who maintains it.

Protected by default

A claim doesn't settle immediately. The package's listed maintainers are notified, and anyone can contest the claim during a waiting period. A hijacked account, expired domain or re-registered username can't quietly divert a package's funds.

Weaker proofs, such as a file in your repository, can get you started but unlock withdrawals gradually.

Where the money ends up

If every distribution eventually happens, each donation lands like this:

The package that received the donation

66.7%

Its direct dependencies, together

22.2%

Their dependencies, together

7.4%

One level further

2.5%

Deeper

1.2%

A package's income depends mostly on how many funded projects depend on it, and on how much those projects receive. The structure of the graph decides who gets paid.

Distribution waits until it pays for itself

Moving value costs a transaction. Small amounts accumulate in a package until one batch, covering all its dependencies at once, is worth carrying out. Packages that many funded projects depend on pass value on quickly. Packages reached only through rarely funded projects pass it on slowly, or not at all. How large that effect is, and what to do about it, is one of the open questions below.

Questions maintainers ask

Do I need to sign up for my package to be included?: No. Your package is in the graph as soon as a funded project depends on it. Claiming only decides where its share is paid.
Can I choose how my share is split among my dependencies?: No. The split follows a public rule applied to your published manifest. That is what keeps anyone from inflating their own take.
Which package ecosystems are covered?: npm only, to start.
Do I need crypto experience?: You need a payout address. Under the current proposal, anyone can carry your published proof to the protocol on your behalf, such as a tool or a service. Publishing the proof may be all you have to do.
Can I opt out?: Proposed: yes.
Is this live?: No. This is a concept and a specification in progress. Nothing is deployed and no funds are held.

Still open

These are being decided now. Where there is a current leaning it is shown, but none of these is settled.

Does value keep flowing past the first level, or is it capped? Leaning: let it flow, and let it stop on its own where moving it no longer pays.
Should the protocol help value reach rarely funded packages? For example, by settling several levels in one transaction. This is a question about who the protocol funds, not just about efficiency.
What happens to money nobody ever claims? Leaning: a long waiting period, then a public-goods destination.
Does a package's dependency list follow each new release, or is it fixed when the package first enters the graph? No leaning yet. Following releases keeps the graph accurate; fixing it keeps the accounting simple.
How are dependencies weighted against each other? Today, evenly. A cap on the combined share of development tooling is under consideration.
Can the right to receive a package's funding be transferred or sold? Leaning: no. It should follow whoever can publish the package.
Which chain, and which currency? Leaning: one low-cost chain and a single stable currency to start.
Does the protocol take a cut for itself? Leaning: no.