{ "note": "Committed provenance for U1 (UNRECONCILED.md) -- swisstony's decode-index.json row rebuild. Raw fetch files (hundreds of MB to low GB) stay outside this repo in scratchpad-msr/; this file is the record of how the published numbers were derived, so the claim is checkable without the raw files. Written by the U1 agent, 2026-07-18.", "wallet": { "handle": "swisstony", "address": "0x204f72f35326db932158cba6adff0b9a1da95e14" }, "window": { "lo": "2026-06-15T00:00:00Z", "hi": "2026-07-15T00:00:00Z", "note": "matches boards_scorecard.json's profit_30d fetch timestamp (2026-07-15T05:44:29Z, engine repo) -- the 30-day window Polymarket's own displayed profit figure covers." }, "rebuiltDate": "2026-07-18", "unreconciledRef": "UNRECONCILED.md U1", "originalPublished": { "date": "2026-07-15 (engine run) / found truncated 2026-07-16", "nFills": 15410, "nMarkets": 434, "avgBuyPrice": 0.804, "source": "engine repo swisstony_v2.json (decode_v2.py's per-market /activity bypass, capped-source cid discovery)" }, "step1_tradesEndpointRefetch": { "method": "Recursive time-window subdivision against /trades?user=...&start=...&end=... (scratchpad-msr/11_window_counts.py, 2026-07-16). No conditionId enumeration is used, so this cannot inherit the capped-enumeration failure mode suspected in the original run.", "rawFile": { "path": "scratchpad-msr/win_2026-06-15_2026-07-15.json (outside this repo)", "sha256": "31a22b6010b60a498eb2625f3d81bde8220076642896db5d014af6637db58636", "sizeBytes": 423087161 }, "independentRecount_2026-07-18": { "method": "Freshly-written streaming JSON-array parser (not the fetch script's own printed numbers) -- re-derives every count from the raw bytes.", "nRawRows": 539113, "nDedupRows": 539113, "nDuplicatesFound": 0, "rowsOutOfWindowBounds": 0, "wrongWalletRows": 0, "sideCounts": { "BUY": 539113 }, "nUniqueConditionIds": 15122, "timestampMin": "2026-06-15T00:00:03Z", "timestampMax": "2026-07-14T23:59:49Z", "result": "Exactly matches the 2026-07-16 session record (539,113 fills / 15,122 markets / ALL WINDOWS CLEAN). Confirmed independently, but see step 2 below: this endpoint was then found to itself be incomplete." } }, "step2_tradesVsActivityDiscrepancy": { "summary": "MAJOR FINDING, 2026-07-18: /trades (step 1's source, and the source cited throughout the prior U1 record as 'measured'/'ALL WINDOWS CLEAN') is itself missing a large fraction of this wallet's real trades relative to /activity?type=TRADE, for the IDENTICAL wallet and window. This is a different failure mode from the original problem (which was about capped market ENUMERATION) -- both endpoints' own pagination/cap signals read clean; the gap is between what the two endpoints' underlying indices contain.", "evidence": [ "1-hour spot-check (2026-06-20 12:00-13:00 UTC): /trades returned 355 rows (355 unique transactionHashes); /activity?type=TRADE returned 556 rows (552 unique transactionHashes).", "Every transactionHash /trades returned also appears in /activity (0 hashes only-in-/trades). 197 transactionHashes appear ONLY in /activity.", "For hashes present in both, the per-hash row count matches exactly (0 mismatches) -- so this is not a case of /trades collapsing multiple activity rows into one; the 197 transactions are simply absent from /trades.", "Directly queried /trades with market= (the per-market bypass approach) for one of the missing transactions, same window: 0 rows returned, hash absent. The gap is not a pagination artifact reachable by a different query shape -- /trades does not have this data under any tested query.", "The 197 only-in-/activity rows are ordinary BUY trades across normal markets (soccer, tennis) at plausible sizes ($0.06-$3,735 usdcSize) and prices -- nothing exotic (no negRisk/conversion markers) that would explain a deliberate exclusion by /trades.", "Verified the /activity `type=TRADE` server-side filter is not itself lossy: unfiltered /activity for the same hour returned 569 rows (556 TRADE + 7 REDEEM + 6 MERGE); client-side filtering to type==TRADE gives the identical 556-row, identical-hash set as the server-side type=TRADE query." ], "conclusion": "/activity is a strict superset of /trades for this wallet+window (0 rows only-in-/trades, 197+ only-in-/activity in the sample). /activity is therefore the more complete of the two, but completeness beyond /activity has NOT been proven either -- this file makes an 'at least' claim, not an exact one. See UNRECONCILED.md U1 for the standing disclosure, and the note to the coordinator about implications for U2 and the engine's own cid-discovery (decode_v2.py uses /trades as one of its three cid-discovery sources)." }, "step3_activityEndpointRefetch": { "method": "Same recursive time-window subdivision, retargeted to /activity?user=...&type=TRADE&start=...&end=..., swept one calendar day at a time with 4-way concurrency. CORRECTED METHOD NOTE: a first attempt used /trades' page size (limit=1000, stop when a page returns <1000) and silently under-fetched to exactly 500 rows on all 30 days -- /activity hard-caps every response at 500 rows regardless of the `limit` parameter requested (verified: limit=100/500/1000/2000/5000 all return <=500), unlike /trades which honors `limit=1000`. This is exactly the 'capped response read as end-of-data' failure mode named in SPEC_agent_briefs_2026-07-18.md's U2 section. Fixed: page size 500 (matches decode_v2.py's own default for non-/trades endpoints), split trigger before /activity's ~3,500-row/window cap (offset >= 3500). Discarded; not used for any published number.", "rawFile": { "path": "scratchpad-msr/u1/act_trade_2026-06-15_2026-07-15.json (outside this repo)", "sha256": "dc62ed8d5959d69f66b04a4fb81fcae44e26a0097669415d005529e6708a6741", "sizeBytes": null }, "perDayCounts": "scratchpad-msr/u1/act_trade_fetch.log (per-day fetched counts and clean=True per day; all 30 days clean)", "independentRecount_2026-07-18": { "method": "Same streaming parser as step 1, pointed at this file.", "nRawRows": 888820, "nDedupRows": 888820, "nDuplicatesFound": 0, "rowsOutOfWindowBounds": 0, "wrongWalletRows": 0, "sideCounts": { "BUY": 888820 }, "nUniqueConditionIds": 16258, "timestampMin": "2026-06-15T00:00:00Z", "timestampMax": "2026-07-14T23:59:49Z", "result": "Matches the fetch script's own printed summary exactly (888,820 / 16,258)." } }, "published": { "nFills": { "value": 888820, "framing": "at least -- the most complete measurement obtained as of 2026-07-18, not asserted as an exact/final count. Supersedes both the original 15,410 and the intermediate /trades-based 539,113 (itself found incomplete, step 2)." }, "nMarkets": { "value": 16258, "framing": "at least, same basis as nFills" }, "avgBuyPrice": { "value": 0.710, "formula": "sum(price*usdcSize) / sum(usdcSize) over BUY fills with 0.02 price*size -- so price*size was rejected as a proxy and the full /activity fetch (step 3) was used instead.", "denominatorUsd": 396376765.24 }, "topMarket": { "conditionId": "0x20fac1c925b7a2fed6b3b2736f47a800b4d0d4001b9deaeb7b918868eb63d081", "title": "Will France win on 2026-07-14?", "usdVolume_real": 2262187.07, "note": "Unchanged from the previously-published topMarket. Independently re-derived from the complete /activity data and confirmed #1 by real usdcSize volume across all sides. The rebuilt figure ($2,262,187.07) matches the originally-published engine figure ($2,262,187) almost exactly -- this wallet's entire real volume in this one market appears to have been captured within whatever slice the original (broken) 15,410-fill sample drew from." }, "dedupeKey": "(transactionHash, timestamp, asset, side, price, size) for /trades; (transactionHash, timestamp, asset, side, price, size, usdcSize) for /activity" }, "notRecomputed": { "fields": ["reconstructed", "reconPct", "realized", "openValue", "bilateralPct", "postresPct", "directionalPct"], "reason": "These require the engine's (decode_v2.py, C:/Official Predict Here/trueedge-wallet-intel/) dollar-weighted /activity cashflow reconstruction (realized = sell+redeem+merge+reward+reb+conv-buy-split, plus Polymarket's live /value mark). The engine only fetches LIVE data via HTTP with no parameter or code path to ingest a local/pre-fetched fill set, and it cannot be re-pointed at a past window -- full_activity() always pulls the wallet's CURRENT activity (verified by reading decode_v2.py in full, 2026-07-18). It therefore cannot be re-run against this window's complete re-fetch. Re-implementing the formulas independently, outside the engine, was considered and rejected: ENGINE_FINDINGS_cid_enumeration_2026-07-15.md (engine repo) documents that directly summing cashflow components over-corrects for wallets with negative-risk (negRisk) conversions -- the 'obvious fix' for a related wallet (maz26) overshot the true figure by millions of dollars -- and swisstony's negRisk exposure across its now-known 16,258 markets has not been checked. Publishing a second, unaudited implementation of 'reconstructed' risked exactly the failure DOCTRINE rule 4 exists to prevent.", "additionalScopeNote": "The original published reconstructed/realized/openValue/bilateralPct/postresPct/directionalPct were never actually scoped to the 2026-06-15..07-15 window in the first place: swisstony_v2.json's own date0/date1 fields show the underlying fetch spanned 2026-03-05 to 2026-07-15 (~4.3 months), because decode_v2.py's capped-source bypass fetches full per-market history for whatever markets it manages to enumerate, not a time-boxed slice. So even if the engine could be re-run, 'the 30-day-window version of reconstructed' was never a well-defined historical quantity to rebuild -- the 21.9%/etc figures are a 4.3-month-scoped computation being compared against a 30-day 'displayed' figure, a scope mismatch independent of the fetch's completeness." }, "verdictRecheck": { "attempted": true, "result": "no change possible or made", "note": "strict_classify() needs fills, recon_pct, bilateral_pct, postres_pct, subcent_pct and avg_buy_price together, in that order, first match wins. fills >= 25 was already true before this rebuild (15,410) and remains true (888,820) -- rule (1) never applied either way. recon_pct/bilateral_pct/postres_pct/subcent_pct remain unavailable (see notRecomputed above), so rules (2)-(7) cannot be evaluated from complete data at all. No verdict can be affirmatively computed; the classifier's own design (an unresolved input falls through to the final else) maps that onto Insufficient evidence, which is unchanged. No escalation triggered under SPEC_agent_briefs_2026-07-18.md §0 (verdict, copyable, the 6-of-25 count, and the frozen headline set are all untouched)." }, "engineMechanismNote": { "status": "verified in the engine repo 2026-07-18 (read-only), not a speculative cause -- see SPEC_agent_briefs_2026-07-18.md §0's carve-out ('unless you verify it in the engine repo and say so with evidence')", "text": "decode_v2.py's full_activity() cid-discovery (the per-market bypass path) unions conditionIds from exactly three sources, each independently capped, and never expands beyond them: (a) a single paginated /activity pull that stops when a non-200 response arrives past offset ~3400; (b) a single paginated /trades pull (page=1000); (c) a single paginated /positions pull (page=500). None of these recursively subdivide by time, so for a wallet whose true lifetime market count is 132,786 (measured 2026-07-16, scratchpad-msr/lifetime_fetch.log), these three capped sources can structurally discover only a small fraction of that set -- consistent with the shape of the originally-published 434-market figure. This is offered as an engine-repo-verified structural finding, not a claim about which specific markets were missed, why enumeration order favoured the 434 it found, or a full causal account of the original 15,410-fill number specifically. It does not appear on any published customer-facing surface (why/log/scorecard); it is confined to this artifact and UNRECONCILED.md, per DOCTRINE rule 4.", "citedFiles": [ "C:/Official Predict Here/trueedge-wallet-intel/decode_v2.py, function full_activity() (lines 24-47)", "C:/Official Predict Here/trueedge-wallet-intel/swisstony_v2.json (n_markets: 434, market_capped: false, bypassed: true)" ] } }