What the quadratic funding formula pays, how the pairwise-bounded variant damps correlated donors, and a three-project, four-donor round you can check by hand: every number below is a fixture vector of the site's recompute node art-814, quoted with its rounding disclosure.
One number decides the subsidy: the square of the sum of the square roots of the contributions, minus the contributions themselves.
The quadratic funding paper states the rule in words: "the funding received by a provider is the square of the sum of the square roots of the contributions made by the funders". The design note this page follows writes the same thing as a subsidy, and squaring the summed square roots is what makes head count matter. It also means a lone donor gains nothing: the square of one square root hands the amount straight back, so a one-donor project has a raw subsidy of zero before a pool is even touched. Many small givers move a project further than one large giver of the same total.
Sum the square roots of 4, 9 and 16, square the sum, then subtract 29. What raw subsidy does plain quadratic funding give p1?
Three projects, four donors, a matching pool of 100: the exact round the recompute node art-814 ships as its hand-checkable fixture.
Project p1 takes 4 from a, 9 from b and 16 from c, so its square roots are 2, 3 and 4, their sum is 9, and its raw subsidy is 81 - 29 = 52. Project p2 takes 1 from a and 1 from d: 4 - 2 = 2. Project p3 takes 25 from d alone: 25 - 25 = 0. The raw subsidies total 54, and the node splits the pool of 100 in proportion to them: 100 × 52/54 = 96.296 and 100 × 2/54 = 3.704. Whole units are assigned first, 96 and 3, and the one leftover unit goes to the largest fractional remainder, p2, so the matches are 96, 4 and 0 and they sum to the pool exactly. Every square root is an exact integer root floored at six decimal digits, each step is disclosed in the node's output, and p3 raises a warning: a project with a single contributor earns no match at all.
Recompute in plain mode with matching pool 100: a gives p1 4, b gives p1 9, c gives p1 16, a gives p2 1, d gives p2 1, d gives p3 25. Show the rounding disclosure.
Plain quadratic funding pays every pair of donors to a project as a rectangle. The bounded variant scales each rectangle down by how much that pair already co-funds, across all projects.
The design note measures a plain subsidy as "a subsidy of 2 sqrt(c_i->p) sqrt(c_j->p) per unordered pair", a rectangle with one side from each donor. It then weights that rectangle: the coefficient is "k_{i,j} = M / (M + sum_p sqrt(c_{i->p}) sqrt(c_{j->p}))", where the sum runs over all projects and measures the total extent to which participants i and j both contribute to the same projects. M is a tweakable parameter, and the note proposes to "binary-search M to lead to the desired total" spend. The point of the damping is a ceiling: the note shows that k coordinated agents, however much they commit, draw less than 2M per pair, "a clear bound (k * (k-1) * M)" in total, where plain quadratic funding let two coordinated agents grow their extraction until they would "extract almost the entire subsidy". The MACI project note writes the same coefficient as its deployed form with alpha equal to 1: each ordered pair adds M/(M + overlap) times the product of the two square-root contributions.
On the worked round with M = 6, p1's three pairs all co-fund p1, with overlaps 6, 8 and 12, so its raw subsidy falls from 52 to 20.857...; p2's only pair, a and d, overlaps by 1, so p2 keeps 1.714...; p3 still earns 0. The pool then splits 92, 8 and 0. Push M very large and every coefficient approaches 1, so the bounded round approaches the plain one: the node ships that limit case as a fixture too. Each coefficient-weighted term is floored once per pair and project, then counted twice for the ordered pair, and the node discloses that step.
Recompute the same round with mode pairwise_bounded and pairwise_m 6. Report the coefficient-weighted pair terms and the new matches.
The node reproduces the published formula on your data. That is all it does, and its own output says so in the same breath.
It does not detect sybils. A recompute applies no identity or fraud screening. The pairwise bound ceilings what directly paired accounts can draw from the pool, and a reply on the design note stresses that the bound does not stop "colluders who route funds through innocent third parties". It does not certify identity with a published round either: the output's label is "within tolerance", because a recompute matches a real round only when the round used the same inputs and the same rounding, and real rounds have been computed in ordinary floats while the node computes in disclosed integer fixed point. It does not implement every variant: the node ships the coefficient with alpha equal to 1, the pairwise form above, and says so; the alpha variants and the squared-matrix variant of the follow-up note are out of scope. It does not endorse anything: p1, p2 and p3 are arithmetic, not recipients. Caps: 200 contribution rows, 40 contributors, 20 projects, amounts and pool up to 10⁸¹² minor units.
The formulas are stated only as the pinned snapshots quote them: the funding paper A Flexible Design for Funding Public Goods, the pairwise coordination subsidies design note (ethresear.ch topic 5553) and the MACI v1.0 pairwise coordination subsidy note. The worked numbers on this page are the hand-checkable fixture vectors of the site's recompute node art-814, in its plain mode and its M = 6 bounded mode.
Does this recompute detect sybils? What would identity screening add beyond the published formula?