# September research: methods and source ledger

Activity window: 18 August 2026 00:00:00 through 16 September 2026 16:11:50 UTC.
Run ID: `2026-09-16`. Holdings and profile fields are snapshots taken during collection on September 16; they are not restricted to the activity window. The original August 6 evidence and published story remain frozen.

## Sample and collection

The initial sample contains 59 published accounts, existing research leads, and wallets documented in the deployed Car and aenews2 cases. Public-profile resolution of the published wallet directory supplied 49 additional trading accounts, producing a sample of 108. Eleven belong to the directory's comparison group. These are existing comparison wallets, not a random sample of Polymarket users.

107 activity feeds are complete, including ten comparison feeds: 242,383 events, of which 226,717 are trades. VeryLucky888 reached the 300-page collection budget with 300,000 activity records; it is excluded from all pair statistics and the activity chart. Its partial metrics are labeled in the account table. Some position feeds also reached the page budget. Their status is recorded in `coverage.csv`.

The collector queries:

- Polymarket Data API `/v2/activity`, using cursors and a fixed start/end, for trades, redemptions, merges, rewards, splits, conversions, maker rebates, referral rewards and user transfers.
- Data API `/v2/positions`, separately for OPEN, REDEEMABLE and CLOSED positions.
- Gamma `/public-profile` for names, proxy wallets and public profile fields; Gamma and CLOB market metadata for condition IDs and outcome token IDs.
- Blockscout address histories on Polygon, Ethereum, Base and Arbitrum, followed by full transaction metadata, token-transfer pagination and decoded logs for selected cases.
- Polymarket `/v1/builders/leaderboard` for ALL, MONTH, WEEK and DAY snapshots.
- Relay request history: 17 successful routes were captured. Most v2 requests were throttled. The v3 service requires an API key, which was not configured for this run. Missing requests are recorded in coverage; they are not treated as empty histories.

Public API responses are stored with URL, HTTP status, capture time and a SHA-256 payload digest under `artifacts/research/2026-09-16/`. The capture includes unsuccessful requests. Successful responses are reused on reruns. The public download manifest hashes every exported file. Original response envelopes and transaction logs remain available in the research repository through Git LFS.

## Payment reconciliation and new recipients

`research/payroll.py` examines successful transactions from the already documented payroll operator, machine treasury and farm sender. For each token and payout contract it deduplicates logs, sums funding from the operator and sums transfers out of that contract. It uses integer token precision through Decimal and retains payments below one token. Every published batch balances exactly; failed or incomplete transaction captures cannot become reconciled batches.

The five operator batches distribute 124,999.52 USDC.e to 87 wallets. Betmoar's collection wallet receives 18,953.66 USDC.e. Sixty-seven recipients appear in the original 124-wallet, 19-batch payroll CSV; twenty do not. “New” means absent from that specific published roster, not a newly created account or a first-ever payment. Public profile labels are recorded at the receiving address. Names resembling app or company brands are the profile labels returned by Gamma.

The farm sender makes 20 batches distributing 1,766.163902 PUSD to 64 wallets, including 14 absent from the original 513-wallet CSV. Two machine-treasury batches distribute 13,754 PUSD to 277 wallets. That last recipient set is compared with the 124-wallet payroll CSV for the exported `previous_roster` field; it is a separate payment program.

The general transfer screen uses exact token contract allowlists, not symbols, and a one-token minimum. A transaction's transfer selector or an exact account/direction/amount match to a TIP event identifies a direct transfer. Other legs in a batch do not inherit the TIP classification. Transaction enrichment may include token legs outside the address-history minimum because payroll reconciliation retains all amounts.

## Correlations and market overlap

Only complete activity feeds enter comparisons. Daily UTC trade-count vectors cover 30 calendar days; the last is partial through the common cutoff. Accounts with a shared market form 158 pairs. The 117 pairs with at least five active days per account enter the correlation test family.

- Spearman correlation uses average ranks for ties, centered and normalized; constant vectors have zero correlation.
- Each pair is compared against 999 permutations of consecutive three-day blocks, using seed 20260916. The last block may be shorter. The two-sided p-value includes the observed ordering through `(1 + exceedances) / 1000`.
- Benjamini–Hochberg adjustment includes all 117 tested pairs. None has q < 0.05. These are exploratory co-activity tests on a selected sample; common market conditions can synchronize activity.
- Jaccard overlap is shared condition IDs divided by the union of traded condition IDs.
- Net-position cosine compares BUY shares minus SELL shares per token over this window. It is a flow measure, not a reconstruction of current inventory.
- Synchrony counts markets with BUYs within 60 seconds, separated into same and opposite outcomes. Shared transactions are counted separately as unclassified; an exchange batch can contain unrelated users.

## Opposite-side matches

The screen requires different accounts and transactions, the same condition ID, opposite binary outcomes, BUY direction, at most 60 seconds between trades, at least 95% agreement in shares, and combined prices between 1.005 and 1.04. It retains one event per pair/condition, choosing the smallest time difference. This produces 70 matches: two between investigation accounts and 68 involving comparison accounts.

All 70 were checked against two independent record types: market metadata giving the two outcome token IDs, and successful Polygon transactions with decoded V2 Exchange `OrderFilled` events. The checks require the observed wallet as maker, BUY side, the correct token and the observed share quantity. Both standard and negative-risk V2 Exchange addresses come from Polymarket's official deployment list. All log pages are collected before a check can pass. Maker/taker in these events are protocol event fields; they do not establish ownership links between the screened accounts.

The receipts include amounts before fees, event fees, builder codes, block timestamps, and transaction URLs. Matching trades are a screening result. The comparison results show why this screen alone cannot identify coordinated accounts.

## Oracle calls

Nine successful propose/dispute calls were decoded from transactions of the proposer wallets already documented in the published Car and aenews2 cases. Question text is extracted from `ancillaryData`. Trade joins use exact normalized full question text (case and punctuation normalized), not keyword similarity. Car has 18 distinct trade transactions in four matched questions; aenews2 has one trade in one matched question. A question with both a dispute and proposal produces two joins to each matching trade, so the 29 exported join rows are not 29 unique trades. Timestamps and both transaction receipts are exported for sequence inspection.

## Reproduce

```bash
python3 -m research.analyze --run 2026-09-16
python3 -m research.payroll --run 2026-09-16
python3 -m research.cases --run 2026-09-16
python3 -m research.receipts --run 2026-09-16
python3 build_site.py
python3 -m unittest discover -s tests -v
python3 validate_evidence.py
python3 browser_check.py
```

Analysis and payroll derivation are offline. Case verification reuses captured successful API responses and only requests missing records. A new collection needs a new run ID so cached snapshots are not mixed across research windows.

## Primary documentation

- [Account activity API](https://docs.polymarket.com/api-reference/feeds/list-account-activity)
- [Position API](https://docs.polymarket.com/api-reference/wallet/list-positions-for-a-user-or-market)
- [Polymarket V2 Exchange source and deployments](https://github.com/Polymarket/ctf-exchange-v2/)
- [Polymarket contract addresses](https://docs.polymarket.com/resources/contracts)
- [Relay v3 migration and v2 retirement](https://docs.relay.link/references/api/api_guides/migrating-to-requests-v3)