# What the payment network is paying for

Audit date: September 17, 2026. This analysis connects the published payment evidence to current fee settings, official incentive documentation, and explicitly classified referral rewards. It does not combine the four payment operators into one economic owner.

## Paid distribution and optional user fees

The fixed cohort is the 68 builder codes joined to actual payment addresses in the September 16 builder crosswalk. It received 81,197.18 USDC.e out of 124,999.52 USDC.e in five transactions. Identity and receipt verification remain in that source bundle. Three additional established app listings—betmoar, polymtrade and PolyHelper.io—are included for fee context, without inventing new metadata joins to their payment wallets.

For each of the 71 codes, query the public CLOB endpoint `/fees/builder-fees/{code}`. Require HTTP 200, an exact returned code and explicit maker rate, taker rate and enabled flag. Preserve each source URL, capture timestamp, body hash and response. Rates are basis points: 100 bps is 1%. The official clob-client-v2 source uses this endpoint and divides each rate by 10,000. Thirty-seven codes have an enabled nonzero rate on at least one side; 36 belong to the 68 matched paid codes.

These are settings captured on September 17, not historical fee earnings or proof that every earlier order paid that rate. Both sides can have different attribution. A zero builder fee does not mean zero platform fee or zero other revenue. The on-page calculator multiplies per-trade notional by trade count and the selected maker or taker rate; it excludes platform fees, price changes and rebates. It is an arithmetic illustration, not a revenue estimate.

## Payouts and attributed activity

Use the official v2 daily builder-volume endpoint with `interval=day&limit=90`. It returned 18,490 rows across 90 daily buckets, June 20–September 17. Require one record per code/date. Publish only the selected 68 codes. Current API documentation defines volume in shares and active users as distinct maker addresses. Summing daily active counts yields maker-days, not distinct people or newly acquired users. Never multiply share volume by a fee rate to claim fee income: fee calculations need trade notional and the applicable side and historical rate.

For the same 68 recipients, compare the five-payment total with summed share volume and maker-days. Spearman uses average ranks for ties. Report all three exploratory windows examined: August 1–September 14, August 1–31, and August 18–September 15. Volume correlations are 0.897963, 0.906345 and 0.871461; maker-day correlations are 0.529511, 0.539536 and 0.560869. The positive paid-only cohort is selected, the windows overlap, and payout dates do not identify earning epochs. These are descriptive comparisons, not independent tests, causal estimates, an exact allocation formula, or acquisition costs.

The legacy request `/v1/builders/volume?timePeriod=ALL` returned calendar-year buckets. It is not used as a daily series. The v2 documentation explains that `interval=all` means calendar years. Three complete API windows and exact per-code aggregates are exported so the comparison can be checked without relying on chart labels.

## Referral rewards

Screen the previously captured activity window, August 18–September 16 at 16:11:50 UTC. Admit only the 107 complete feeds; exclude the incomplete feed from both totals and zero-event interpretation. Retain only events explicitly labeled `REFERRAL_REWARD` by the official activity API. The result is 34 account-level events across 24 transactions and three tracked wallets.

For each event fetch the successful Polygon receipt and block. Match the exact recipient, PUSD contract `0xc011a7e12a19f7b1f670d46f03b03f3342e82dfb`, Transfer topic, timestamp and amount. The API publishes four-decimal monetary amounts, so the matcher permits at most 0.00005 PUSD difference and requires exactly one matching log. Export the precise receipt amount and log index. In these 34 observations the receipt and API values agree exactly. Only selected transfer logs are published.

Verified totals: duratio6 393.8085 PUSD in 15 events; itskkoma 95.7233 in 18; Car 3.8829 in one. Total 493.4147 PUSD. These amounts are not combined with the USDC.e builder batches. The referral classification comes from the activity service, while the receipts independently establish the actual token payments. The public events do not name the underlying referred users or establish self-referral.

## Interpretation in the existing investigation

Official rules describe volume-based builder subsidies, optional fees on routed orders, and separate fee-based referral income. The verified payee crosswalk and strong volume association fit paid app distribution. Current fee schedules establish which sampled integrations can monetize users' trading directly. The referral records establish actual affiliate earnings for three tracked accounts.

The records do not establish a network-wide scheme of fabricated users or losses transferred to the same beneficial owner. The earlier 117 co-activity tests had no adjusted significant result, and opposite-side screens also triggered on comparison wallets. Shared builder attribution identifies an integration, not common wallet ownership. The earlier 39-wallet Firefly sample and staging-wallet examples retain that interpretation.

The remaining empirical questions are specific: which users generated the rewards, whether promoters controlled those users, which historical fees were deducted, and whether any controlled counterparty captured their losses. No available public referral event resolves the first two. Payment chronology alone does not resolve them either.

## Reproduction

Run `python3 -m research.incentives`, then `python3 build_site.py`. The dated capture retains current API responses and source documents under `artifacts/research/2026-09-17-incentives`. Published normalized files and selected source extracts are under the corresponding reports and site directories. The manifest provides SHA-256 hashes. Existing project scope exclusions apply to every export, including encoded address words.