How the allocation works

The mechanism follows the public description of the Survival and Flourishing Fund's S-process: recommenders describe marginal value, funders delegate by trust, and an algorithm turns that into grants. This is an independent implementation built from that description, not their software.

1. Marginal value curves

For each application a, recommender r draws a curve m_r,a(x): how much value one more dollar creates once x dollars are already granted. Curves are piecewise-linear and non-increasing. The first dollars are the most valuable, which is how diminishing returns show up. The total value of granting x is the area under the curve:

V(x) = ∫₀ˣ m(t) dt

Because m never increases, V is concave. That one property is what makes everything below well-behaved.

2. Delegation by trust

Funder f with budget B_f gives each recommender a trust weight w_f,r. The funder's budget is split in proportion:

D(f, r) = B_f · w(f, r) / Σ_r′ w(f, r′)

Trust weights are private to each funder (and the round owner). Everyone else sees only the total each recommender directs.

3a. Round-robin (S-process style)

Recommenders take turns. On each turn a recommender places a small step (e.g. $800) on whichever application has the highest marginal value to them, given everything granted so far by anyone. They stop when nothing they value is left. Because every turn looks at the shared running total, one recommender's funding lowers the next dollar's value for everyone. Overlapping priorities share the cost instead of double-funding.

3b. Pooled (exact water-filling)

The alternative treats the group as one decision-maker whose curve is the delegation-weighted average of the recommenders' curves. For concave values, the optimum puts every partly funded application at the same marginal value λ, the “water level”:

Σ_a min(cap_a, m_a⁻¹(λ)) = B

The left side only decreases as λ rises, so bisection finds λ. Ties on flat stretches of a curve are split in proportion to how many dollars each application has at that exact level.

Why both?

With a single recommender, round-robin converges to the same total value as water-filling as the step shrinks. With several, they differ. Pooling lets intense preferences dominate: one recommender who values a program 10× can pull the whole budget toward it. Round-robin guarantees each recommender's delegated share gets spent on what they value. The gap between the two views, and the “what if we didn't have…” counterfactuals, are good things to discuss.

How it's checked

Property-based tests on random curves and budgets: budgets are conserved, caps are respected, results don't depend on input order, more budget never lowers anyone's grant, and water-filling satisfies the optimality conditions.
An independent Python implementation (NumPy, an exact breakpoint solver rather than bisection) generates fixtures that the TypeScript engine must match.
The database itself rejects invalid curves with a CHECK constraint, even if the API is bypassed.