Comment on CFTC-2026-1453, CFTC-2026-1453-0001, MSR Decode

Comment of MSR Decode on Data Reporting Requirements for Certain Event Contracts, RIN 3038-AF73. Full comment letter attached (5 pages). I am the founder of MSR Decode, an independent forensic research desk for prediction-market wallets, operated by Main Street Research LLC and based in Hong Kong. We reconstruct a prediction-market trader's record from complete public fill data and state whether a publicly claimed profit survives that reconstruction. The method and its measured error, a pre-registered append-only forecast ledger, and a running log of our own corrections are all public. Disclosure of interests: I traded prediction markets on Polymarket myself from 2024 to 2026. I hold no open prediction-market positions today and operate no automated trading. MSR Decode sells research and does not route trades, earn commission on volume, or hold customer funds. No party has compensated me for submitting this comment. This comment responds primarily to Question (10): whether DCMs listing Covered Event Contracts should be required to publish transaction data elements beyond execution timestamp, contract ticker symbol, trade quantity, and price. My answer is yes. Those four elements are sufficient to publish a price tape and insufficient to verify a performance claim. Public claims about event-contract traders' results are widespread, are acted upon by retail participants, and cannot be checked against a four-element anonymous tape. The stakes are current: in the week of this filing, event contracts on the July 29 FOMC decision traded roughly $144 million on a single venue, about $25 million of it on decision day — a tape of that size, published as four anonymous elements, supports no verification of any claim made afterward about who profited from it. The attached letter ties each recommendation below to a specific published failure that is independently recomputable, including one instance in which our own published finding was wrong and was retracted. Recommendations: 1. A persistent pseudonymous participant identifier per execution. Not identity. A one-way derivative of the account identifier the DCM already holds would let the public determine that a set of executions belongs to one participant, and nothing more. Without it, no public performance claim about a participant on a registered DCM can be checked by anyone outside the Commission. 2. Explicit representation of both sides of each execution, so that every execution appears in the published tape exactly once and in a form comparable across DCMs. A rule that enumerates which fields to publish, without specifying execution completeness and side representation, permits two DCMs to publish fully compliant tapes that are not comparable. In one case we measured, a single undisclosed default parameter on a public data interface concealed 6,154 of a wallet's 8,115 fills — 75.8% — and produced a confident, published, and false conclusion, which we retracted. 3. A settlement key joining each contract to its resolution outcome and resolution timestamp, publicly joinable to the Section 16.03(f) tape by ticker. In binary-payout markets, holdings redeemed at face value after resolution are not trading gains, and a record lacking resolution timestamps cannot separate the two. This is a recurring source of public error and costs the DCM nothing beyond what proposed Section 16.01 already requires. 4. An express requirement that the published tape be complete and retrievable in full — retained for a specified period, obtainable in bulk rather than only through a rate- or offset-limited interface, with any default filter, pagination limit or retention window disclosed in the venue's public documentation. Public interfaces that stop paginating at a fixed offset and end silently return truncated records that appear complete. On Question (12), narrowly: I take no position on surveillance scope. I note only that the identifier collected under proposed Section 16.03(g) is the same identifier from which a privacy-preserving public key can be derived. The Commission need not expand collection to achieve public verifiability. I am not asking that any trader's identity, address, account number or personal information be published, and I would oppose that. The underlying fill-level files, per-market fetch logs and reconciliation outputs behind every figure cited are available to Commission staff on request at no cost. Respectfully submitted, Chris Park Founder, MSR Decode