MICHIGAN FUNDING AND CONTROL WITHOUT A RELAY API KEY
November 2, 2026

We verified a technical owner address for the Michigan trading account. We did not identify a person or organization behind that address, and we did not connect the two funding payments to an originating deposit. The result advances the account-control investigation but adds no evidence of political funding or manipulation.

VERIFIED TECHNICAL CONTROL

Trading account: 0x4477ef21f461de7b73a9982e14832591704034cf
Historical contract owner: 0x9bdf52642943d9b5b665de67c39c50c31d1e1dd2

The correct owner() call returned that owner at the end of five Polygon blocks: 96609205, 96609758, 96609772, 96611254 and 96611312. These cover the first buy, the large purchase's preceding funding block, the large buy, the first sale and the final sale. The same implementation address appeared in the proxy's implementation slot at each sampled block. Its historical runtime matches the explorer's published verified deployed bytecode, whose source and ABI define this owner interface. The earlier getOwners() failure used the wrong interface and did not indicate an ownerless account.

The immediate conversion/funding address, 0x6f4a53d86921d443c6c6d8e82a1a625120dda6cd, is different from the owner. The verified sessionSignerAuthorizedUntil(address) call returned zero for that funding address at the same five endpoints. Under the matched source, it was not an authorized session signer at those end-of-block states. The contract permits other session signers; we did not identify who signed the seven orders, enumerate all signers, or prove exclusive control. An upgrade requires a wallet self-call and an implementation authorized by the factory; factory approval alone does not establish unilateral upgrade authority.

These are native technical-role observations, not personal identity or beneficial ownership. Two different addresses may share a human or organizational controller. End-of-block checks do not exclude intra-block changes or prove continuous ownership between observations. Historical state came from one archive RPC provider; the explorer runtime comparison independently checks code identity, not the historical state itself. The older withdrawn implementation-name attribution for the separate conversion account remains withdrawn.

FUNDING ORIGIN REMAINS UNRESOLVED

Prior evidence establishes that a solver-labelled address sent 1,000 and 98,999 USDC.e to the conversion account, followed six seconds later by matching collateral credits to the trading wallet. This round tested a genuinely new public route without retrying the key-gated API.

Each retained transferFrom transaction contains one extra 32-byte value after its standard arguments. We tested those values as candidate request identifiers against Relay's documented status endpoint, which permits calls without a key. Both returned HTTP200 with status unknown and no transaction hashes. The values' meanings are not authenticated; the responses do not prove that Relay has no corresponding records.

Public transaction-page attempts returned429, and Polygon Blockscout requests returned403. These are access results, not proof of absent transactions. No credentials, API key, registration, client impersonation or access bypass were used. No unique connection to an originating deposit, source chain, sender or ultimate funder was found, so we did not follow unrelated transfers into the shared solver as if they belonged to this customer.

WHAT THIS MEANS FOR THE STORY

The technical owner gives us a precise address for any future authenticated public attribution. It is a meaningful result, not a name. It cannot be described as a Democrat, campaign account or source of the funds. The funding address's lack of owner/session authority at these observations likewise does not prove an outside donor or separate beneficial owner.

The tested keyless routes have not crossed the funding-service boundary. A meaningful next upgrade would require an exact public request/deposit mapping, properly authorized access to the service's corresponding record, or independently verifiable public attribution of the technical owner. Generic clustering of the solver's other customers would not answer the question. This round does not justify Cardone's allegation, and no absence of public linkage disproves it.

FILES AND REVIEW

control/FINDINGS.md links the verified implementation, official Polymarket documentation and SDK. It contains the historical request ledger, raw responses, runtime comparison and reproduction scripts. origin/FINDINGS.md links the optional-key status documentation and public transaction help, and preserves decoded calldata, request records, failures and response hashes.

The independent reviewer re-read the raw ownership/implementation/session results, matched runtime bytecode to the captured explorer source, and checked the funding calldata and failed lookup results. review/FINDINGS.txt states the qualifications. Root separately reparsed the historical results and status responses: all17 checks passed in ROOT_VERIFICATION.json. These checks are not blind or an independent second historical-state provider.

Earlier evidence remains unchanged. No outreach, publication, payment, registration, account change or trading occurred.