# Kate / Wincy: the routes reconnect

Captured September 16, 2026. Run `python3 -m research.circle_evidence` and `python3 -m research.circle_withdrawals` to repeat the receipt and balance checks against the saved explorer histories and public API responses. `python3 -m research.circle` refreshes the wider screen.

## Source and identity rules

The supplied X handles are matched to the `xUsername` field of Polymarket's public-profile API. Kate is `katelv`, proxy `0xefbde971ee0122381e91a3c21a5337d0ae9065fa`; Wincy is `lolxdkek`, proxy `0xd95f1679197a707cb93e36345f2d329e00e6adfd`. These are public account associations. Kate's `users[0].communityMod` field is true at capture. `getOwners()` and `getThreshold()` are checked at the blocks immediately before three cited payments, establishing the sole Safe owner and threshold at those times.

The ring loader, farm sender and staging-wallet labels carry forward their roles in the existing investigation. New hub `0x8e50…18887`, route `0x2b1f…62ab3` and intermediary `0xa51e…ac3b` are transaction-based labels; no new human identity is assigned to them.

## Selection and coverage

The wider refresh examines 114 published address / chain pairs from August 1 and 38 profile responses. 113 explorer feeds reach the start date or end of history. One partial feed is explicitly marked in circle_coverage.csv. When unfiltered token history hits its budget, the collector retries using an exact contract filter for supported stablecoins. This screen generates leads, not an exhaustive census of every connected account.

The five focused Polygon histories (hub, recurring payer, two-payment route, withdrawal endpoint, August intermediary) reach their end. The published transfer set includes: 13 hub inflows from the exact ring-loader address, one inflow from a previously recorded farm recipient, selected hub outflows, the payer's complete normalized token record, all four second-route transfers, the four operator endpoint payments and their onward sweeps, and the August intermediary's complete history. Small lookalike-address transfers in the hub's history are excluded from connection claims. Hub connection selections require at least one token and an exact known address.

## Raw receipt checks

51 Polygon Transfer logs across 49 successful transactions are verified against the transaction hash, exact token contract, exact sender, exact recipient, amount and log index. Block hashes and timestamps are independently fetched. USDC, USDC.e, PUSD and Polygon USDT0 all use six decimals. Token names are display labels; token contracts define inclusion. Polygon USDT0 is the token historically labeled USDT in earlier files. Duplicate logs are counted once.

All four operator-to-endpoint transactions have the same outer transaction sender, `0x3986…a3f84`. The two direct calls additionally require ERC-20 transfer calldata naming the exact endpoint and amount. The two batch calls target ClipperPayout. The June 10 payment to Kate's owner is log 156; the endpoint payment is log 157 of that same successful transaction.

## Flow and balance analysis

28 historical balance reads bracket the claimed movements. The second route's native USDC balances are exactly zero, 200, 200, zero around its May 30 input/output and zero, 650, 650, zero around its June 12 pair. It has four token transfers in its complete explorer history. This supports a complete pass-through of 850 USDC.

The hub paid Kate's recurring payer 2,200.005037 USDC in four payments. Of this, the July 9 payment of 1,000 USDC is followed by a July 20 payment of 1,000 USDC to Kate's Safe owner, with no intervening USDC transfers and equal balances at the relevant boundaries. The other hub receipts led to payments of 999.895271 and 199.974384 USDC to a different recipient. Therefore 2,200.005037 is an amount received by the payer wallet, not an amount assigned in full to Kate.

For August 28, the payer's USDC balance reconciles: 0.025616 opening + 1,136.29 converted staging funds + 1.974561 separate receipt = 1,138.290177 paid to Kate's Safe owner; closing balance zero. The staging-wallet input is PUSD. The intermediary redeems to USDC.e and converts through Relay to native USDC. The successful Relay request must explicitly match sender, recipient, input/output contracts, chain IDs, amounts and both verified transaction hashes. Amount-and-time coincidence alone does not establish the conversion. Reserve and solver wallets represent redemption and settlement services.

Each operator endpoint payment is followed within five minutes by an equal-token, equal-amount onward transfer. Pinned balances read zero before each deposit, its exact amount after, and zero after the onward sweep. August 19's delay is 163 seconds.

## Wincy's endpoint evidence

Four successful Relay requests from the exact publicly named `lolxdkek` profile are selected by an exact destination address and Base native-USDC output. Each input Transfer on Polygon and output Transfer on Base is verified from a successful raw receipt. The four Base outputs total 2,066.875670 USDC. One additional request pays another token on BNB Chain and is outside this four-request check.

The hub and operator payments arrive at `0x720191fcd3c1802a303173732ea9d165d8c2e2d5` on Polygon. The four public-profile withdrawals arrive at the identical EVM address on Base. Address reuse is the reported connection. It does not independently identify an exchange customer or establish common human control of the sending wallets. Current smart-account implementation matches, common bundlers, common solvers and common exchange hot wallets are excluded as ownership evidence.

## Interpretation

The new evidence extends the recorded payment network: a previously unlisted hub connects the ring loader, Kate's recurring payer and the endpoint; the original operator's endpoint payment record expands from one cited 150-USDT0 batch leg to four payments totaling 850 USDT0; and a newly traced intermediary continues the staging-to-Kate funding route on August 28. Receipts establish money movement and contract control at specified blocks. They do not record the commercial purpose of a payment.

The page preserves this distinction in its labels, amounts and source links. Previously tested trading correlations remain on the Research page with their multiple-testing results; this route finding relies on exact transaction matches and historical balances rather than a new correlation claim.