2 Commits

Author	SHA1	Message	Date
funman300	571c5f9261	docs(market): recover the FIFA17 sold wire contract from CardsDLL (Ghidra) ... Task A, static phase. Ghidra 12.1.2 headless via the repo's own pyghidra harness over CardsDLL_Win64_retail.dll (13,382 functions). Queries and raw decompiler output committed under docs/evidence/market-sold-re-2026-08-17/. RECOVERED FROM THE BINARY 1. No sold token, now EXHAUSTIVELY: both vocabularies dumped to their sentinels rather than sampled. tradeState is exactly 4 rows; itemState is exactly 12 (invalid/free/WAITING_FOR_GAME/inGame/forSale/offered/activeBadge/ activeHomeKit/activeAwayKit/activeBall/activeStadium/active=255). A sold row MUST therefore be a combination of existing atoms. 2. What closed does, complete, from the auctionInfo deserializer 0x18013e410: IS_GLOW = (tradeState==closed) ? bidState != none : bidState in {outbid, buyNow} INBOX = bidState in {highest, buyNow} 3. The full record -> Flash map from the publisher 0x1801bf030, superseding the partial list. The prize: record +0xbf is published as COINS_AWARDED, fed by the coinsProcessed atom 0x2f4. The corpus had recorded that atom's type and noted its consumer was never found; it is now traced. DURATION also renders the localised FUT_AUCTION_EXPIRED when expires underflows. 4. highest vs buyNow on a closed row is UNDECIDABLE from CardsDLL, by proof: both yield IS_GLOW=1/INBOX=1, bit-identical. But bidState is ALSO published verbatim as YOURBID alongside STATE and COINS_AWARDED, so the movie does receive the raw values - the discrimination exists and lives entirely in unread ActionScript. This retires the question as a static target, and it contradicts the third-party lore that a seller's sold row is closed+buyNow (the corpus's own lifecycle table says closed+highest and assigns buyNow to the buyer). 5. The clear-sold verb EXISTS. Builder 0x1801647c0 emits "/sold" when the tradeId field is zero and "/%lld" otherwise, on route base ut/delete/%s/trade, response class RS4 FutISRemoveTradeServerResponse. Confirmed by the client's own request-name table entry RemoveAllSoldFromTradePile. A BULK clear-sold verb only makes sense if sold rows PERSIST in the seller's pile until cleared, which is incompatible with our Fix A invariant - so the sold path will require revisiting it under live validation. 6. The seller's SOLD counter is real, proven end to end with no inference: the hub tradePile sub-deserializer 0x18013ead0 writes atom sold 0x2c9 to +0x1d8, and the tile publisher 0x1800b1dc0 renders +0x1d8 as Flash TEXT3 under the localised caption FUT_TF_SOLD. Siblings: selling -> +0x1d2 -> FUT_TF_SELLING, count -> +0x1d4 -> FUT_UC_ITEMS, plus FUT_TF_WINNING/FUT_TF_OUTBID on the Transfer Targets tile. We and the Python oracle both hardcode sold:0, so that bucket can never fill. 7. Reusable method: an atom id is the INDEX into the alphabetical atom-name pointer table at base 0x1802d2760. Validated 12/12 against the known auctionInfo atoms and cross-checked against fifa17-recon/docs/fut_atoms.tsv. Documented gotcha: resolve a name by the pointer slot INSIDE the table, never by the first matching string in the binary, or you get confident nonsense. 8. An auction-outcome vocabulary exists (auctionSoldBid 0x39, auctionSoldBuyNow 0x3a, auctionWon*/auctionLost*) but NO deserializer consumes it - every candidate function was checked for the value-SKIP/atom-loop signature and none qualifies. Server-side or telemetry only; it does not carry sold state here. TASK B IS UNDECIDABLE FROM THE CLIENT, and this is a proof of absence: no 0.95 or 0.05 constant of either width, no tax/fee/net/proceeds caption, and no fee arithmetic anywhere. The client never computes or displays a net, so no experiment against our own server can measure the rounding - whatever we credit is what it displays, and there is no oracle. Only an original EA-era seller-balance capture could settle it. The rule stays an explicit CHOICE (floor the fee, so fee + proceeds == gross exactly) and is now pinned at the requested boundaries 100/101/119/120/149/150/151/199/200 plus 15,000 and i64::MAX. Settlement NOT promoted. No production process, port or database was touched.	2026-08-18 01:32:02 +00:00
funman300	f6606accb3	feat(market): FIFA 5% transfer fee policy, host settle_sale capability, isolated staging harness ... Core gains the generic settlement (gitlink 31ab4a6); the FIFA-specific parts live here. FEE (openfut-adapter-fifa17/src/fut/economy_policy.rs), beside pack_price and match_reward_total because 5% is a game policy constant and Core must stay game-neutral — Core only validates 0 <= fee <= gross and never computes a rate: TRANSFER_MARKET_FEE_PERCENT = 5 transfer_market_fee(gross) = floor(gross * 5 / 100), i128 intermediate seller_proceeds(gross) = gross - fee Integer only. Floating point is never used for coin settlement: 0.05 is not representable in binary and a f64 round trip can create or destroy a coin at large prices. Widening to i128 makes overflow unreachable for any i64 price, so no price ceiling has to be assumed. ROUNDING IS A CHOICE AND IT IS NOT CONFIRMED. The fee is floored, so the seller keeps the fractional coin, chosen because it makes fee + proceeds == gross hold exactly at every input — the property the accounting invariant rests on. The discriminating case against flooring the seller's 95% instead is a gross of 150: this rule pays 143, the alternative 142. Nothing in the corpus or the client binary settles which the real server did (the client is only ever told the gross; no tax/netPrice/sellerProceeds wire field exists). Pinned at 0/1/19/20/21/39/40/100/ 150/200/1_000/15_000/15_000_000/i64::MAX plus a fee+proceeds==gross sweep. HOST: CoreEconomy gains settle_sale + EconomySale/EconomySaleReceipt, implemented on HttpCoreClient as POST /economy/settle-sale. Request field names were checked against Core's actual SettleSaleRequest/SaleReceipt rather than assumed. Absent club ids are OMITTED from the body (not null), which is what Core's Outside/active-club defaults depend on, so a unit test pins that body shape. handle_market_buy is deliberately untouched: the synthetic buy path has no counterparty, so minting there is correct. HARNESS: scripts/settlement-staging.py, stdlib only, drives a REAL Core over real HTTP on an ephemeral port against a throwaway DB (production 8099/8199/18080 in a hard deny-list checked in three places), seeds the canonical two-party fixture, prints BEFORE/PURCHASE/AFTER with PASS-FAIL lines, cleans up in a finally. 31/31 pass. It found the rejection-precedence bug fixed in Core, and that Core's content preflight aborts startup on an owned card whose CardDefinitionId no pack defines. Gates: Core 194, adapter 217, host 127, harness 31/31, clippy clean, new code fmt-clean. Nothing deployed; no production process, port or database was touched.	2026-08-18 00:51:37 +00:00