Revenue Sharing | LPM.dev Docs

The LPM.dev Registry Pool allocates each settled subscriber contribution among the eligible Pool packages recorded for that subscriber during the billing period.

Settled contributions

A successful personal subscription or assigned organization seat creates a contribution for its beneficiary. The LPM.dev Registry divides the net paid Pool line after discounts and pre-tax credits:

Recipient	Share	Standard $12 contribution
Package authors	80%	$9.60
LPM.dev Registry	20%	$2.40

The standard dollar amounts assume a full-price payment. Failed or incomplete payments do not enter the author fund. Applicable tax is separate from the Pool line, and refunds create adjustments against earnings that have not yet been paid.

Package observations

The Registry records Pool use only when download authorization succeeds through a Pool entitlement.

For revenue accounting, each subscriber and package can produce at most one observation in a billing period:

subscriber + package + billing period = one observation

Repeated CI runs, reinstalls, downloads on another machine, or appearances in multiple dependency trees do not create additional observations for the same package.

A direct download records the requested package at depth 0. The published dependency analysis supplies eligible Pool dependencies at deeper positions.

Depth weights

Depth	Weight	Meaning
0	1.00	Directly downloaded package
1	0.70	First-level Pool dependency
2	0.49	Second-level Pool dependency
3	0.34	Third-level Pool dependency

Depths 0 through 3 are the four tracked positions. Dependencies beyond depth 3 do not receive an observation for revenue sharing.

Dependency adjustments

Two rules adjust dependency observations before a subscriber's contribution is allocated.

Minimum adoption

A dependency observation at depth 1, 2, or 3 receives weight only after that package has at least two unique installers in the billing period.

This threshold does not apply to depth 0. A directly downloaded Pool package keeps its direct weight even when it has only one installer.

Same-owner multiplier

When a dependency and the directly downloaded Pool package have the same owner, the dependency receives 30% of its normal depth weight:

Normal depth weight	Same-owner weight
0.70	0.21
0.49	0.15
0.34	0.10

The Registry rounds adjusted weights to two decimal places. The comparison is against the directly downloaded root package, not every immediate edge inside its dependency tree.

Per-subscriber calculation

For a subscriber with eligible observations:

package allocation =
  subscriber author contribution
  × package weight
  ÷ total eligible weight for that subscriber

Suppose a full-price subscriber has one direct package and one eligible first-level dependency:

@lpm.dev/acme.app       1.00
@lpm.dev/shared.helper  0.70

total weight            1.70

Assuming the packages have different owners and the dependency meets the two-installer rule, the standard $9.60 author contribution is allocated approximately as follows:

Package	Calculation	Allocation
`@lpm.dev/acme.app`	`$9.60 × 1.00 ÷ 1.70`	$5.65
`@lpm.dev/shared.helper`	`$9.60 × 0.70 ÷ 1.70`	$3.95

The Registry allocates whole cents so the package allocations add back to the subscriber's exact author contribution.

Subscribers without eligible observations

If a settled subscriber contribution has no eligible package observations for its billing period, the contribution is divided equally among all Pool packages.

This includes subscribers with no recorded Pool downloads and cases where all recorded observations receive zero weight after dependency adjustments.

Refunds

Refunds reduce the author portion associated with the original settled contribution.

If the original subscriber had eligible observations, the adjustment is applied proportionally to those packages where unsettled earnings remain.
If an adjustment cannot be recovered from unsettled package earnings, the LPM.dev Registry absorbs the remaining amount.
Pending refund adjustments block payout processing until the accounting state is resolved.

Paid-out earnings are not silently rewritten by a later monthly calculation.

Calculation and payouts

The monthly sequence is:

On the 1st, the LPM.dev Registry calculates the previous billing period from settled contributions, observations, weights, and refund adjustments.
Earnings below the payout threshold carry forward.
On the 5th, the Registry attempts eligible Stripe payouts.
Payouts waiting for setup or affected by a recoverable transfer failure remain pending and are retried automatically.

The payout threshold is $10 across the owner's combined pending Pool earnings, including earnings from multiple packages. It is not a separate $10 requirement for each package.

Payouts require an active, enabled Stripe account:

Personal packages: Dashboard > Settings > Payout Settings
Organization packages: Organization > Settings > Payout Settings

Payouts are made in USD. Connecting Stripe is not required before a package begins earning; it is required before pending earnings can be transferred.

Inspect current estimates

Authors can inspect the active billing period with LPM CLI:

lpm pool

The command reports weighted downloads, estimated earnings, and per-package values. These are estimates until the billing period is calculated. See the LPM CLI pool reference for the output contract.