17 September / The incentives behind the engine
The strongest explanation is paid distribution and trading activity that generates income. The payout record connects money to apps. Fee settings and referral receipts show how activity can pay. The remaining question is whether the users are independent.
01 / Put the funding in context
The engine investigation identifies the funding accounts and approvals. It does not put a commercial label on each transfer. Official program rules and the paid-app crosswalk explain the economic incentives.
Promotional links and trading interfaces can direct activity toward an integration.
The executed order credits the app with activity. A separate signup relationship can credit a referrer.
Program subsidies, optional builder fees and referral rewards are distinct sources of revenue.
Program-funded
Approved builders can receive weekly USDC rewards linked to integration volume. In five reviewed batches, 68 matched apps received 81,197.18 USDC.e. The recipient overlap and activity comparison fit this program model; the transfers do not label their earning weeks.
Inspect the paid-app crosswalk ↗User-funded
An integration can charge a percentage of routed trade notional in addition to platform fees. A user’s profit is not the input to that calculation. A code may also charge zero.
Read the fee mechanism ↗Share of platform fees
Current terms pay 10% of net fees for direct referrals and 5% for indirect referrals, ending after 30 days or at Platinum, whichever comes first. The documented reward comes from fees, not a percentage of the trader’s losses.
Read the current referral terms ↗02 / Current rates, exact builder codes
Bagel currently lists 0.5% maker / 1% taker. Firefly lists 0% / 1%. Betmoar and PolyHelper list 0% / 0%. These are September 17 settings, not a reconstruction of historical fees collected.
Inspect the incentive
Choose an app and a side. Change the notional per trade or the number of trades. The calculation uses the app’s captured API percentage. Bagel’s app terms also impose a $0.05 minimum on market orders; calculate its full app fee here.
10 × 1,000 pUSD × 1%
API percentage only; app minimums are not included. Platform fees, rebates and changes in market price are outside this calculation.71 fee schedules
No apps match these filters.
“No direct ID join” refers to the strict metadata crosswalk, not zero payments. The 71-code sample includes 68 matched paid builders and three additional established app listings. Rates attach to exact codes, not every product with a similar name.
03 / The payout pattern
For the same 68 matched apps, five-batch payouts have a Spearman correlation of 0.898 with share volume and 0.530 with maker-days over August 1–September 14. All three examined windows show the same ordering.
Spearman ρ = 0.898 · 68 apps
| Activity window | Payout / share volume ρ | Payout / maker-days ρ |
|---|---|---|
| 2026-08-01 → 2026-09-15 exclusive | 0.898 | 0.530 |
| 2026-08-01 → 2026-09-01 exclusive | 0.906 | 0.540 |
| 2026-08-18 → 2026-09-16 exclusive | 0.871 | 0.561 |
Official rewards are volume-based. Larger payouts tend to go to apps with more attributed activity. The paid-only sample and unknown earning epochs do not reveal the exact reward formula or prove that volume caused each transfer.
The API defines volume as shares and active users as distinct maker addresses. Summed daily counts are maker-days. Neither measure tells us how many new independent people arrived, how much fresh capital entered, or whether those people profited.
Inspect the metric definitions ↗04 / Recorded affiliate earnings
The official activity API explicitly labels these entries REFERRAL_REWARD. All 34 account-level payments match exact PUSD transfer logs across 24 transactions. The screen covers 107 complete tracked feeds from August 18 through September 16 at 16:11:50 UTC.
| Account | Payments | PUSD received | Observed payment dates |
|---|---|---|---|
| duratio6 | 15 | 393.8085 | 2026-08-20 → 2026-09-07 |
| itskkoma | 18 | 95.7233 | 2026-08-20 → 2026-09-14 |
| Car | 1 | 3.8829 | 2026-09-07 → 2026-09-07 |
The event type identifies the program; the receipt verifies the money. These events do not reveal which referred users generated it. No referral-ownership graph is exposed by this dataset.
Download every verified referral payment ↓05 / What the evidence supports
If “farming users” means earning from their repeated activity, the incentive exists and current fee schedules show it directly. If it means fabricated users, controlled losing counterparties or stolen balances, those are different claims requiring different evidence.
The builder crosswalk, funding receipts, current fee settings and referral payments are inspectable records. Some integrations can earn on routed activity even when the trader loses money.
The observed payout pattern fits builder incentives. The financial interest is in attracting and retaining trading activity. Receiving payment or using an app does not establish control of that app’s other users.
To establish that loop, connect the reward to specific referred users, prove their common control, and reconstruct the fees or losses reaching the same beneficiary. The public records reviewed here do not complete those links.
The earlier farm sample and staging-wallet fills carry Firefly attribution. Its current 1% taker setting is now visible. Shared attribution alone identifies the integration, not who owns its users or what historical fees they paid.
Inspect the exact builder-code evidence ↗None of the earlier 117 co-activity tests passed the adjusted threshold. Opposite-side screens also triggered on comparison accounts. Those results do not establish coordinated control of the sampled users.
Read the comparison results ↗06 / Follow the evidence
Current fee snapshots, the exact payment cohort, all three comparison windows and selected referral receipts. The funding engine, paid apps and Kate/Wincy payment routes remain linked to their own source records.