OpenFUT/docs/FIFA17_SOLD_WIRE_RE.md

FIFA 17 seller-facing SOLD state — static recovery from CardsDLL

Reverse engineering of CardsDLL_Win64_retail.dll (md5 4de3493131d7d2ff7f8b360c5ac9b655), Ghidra 12.1.2 headless via pyghidra, 13,382 functions, image base 0x180000000. Queries and raw output: docs/evidence/market-sold-re-2026-08-17/.

Confidence tags: [PE] read from the binary · [PE-PROOF] a proven negative (an exhaustive absence) · [PLAN] corpus prose, not a decompile · [UNDECIDABLE] proven not answerable from this binary.

---

1. There is no sold token, and now it is exhaustive

Both vocabularies dumped in full to their sentinels, not sampled. [PE]

tradeState table 0x180229e40 — exactly 4 rows, then a {0,0} terminator:

active=1  inactive=2  expired=3  closed=4

itemState table 0x180229cc0 — exactly 12 rows, then a {0,-1} terminator:

invalid=0  free=1  WAITING_FOR_GAME=2  inGame=2  forSale=5  offered=6
activeBadge=100  activeHomeKit=101  activeAwayKit=102  activeBall=103
activeStadium=104  active=255

Neither contains sold. So the seller's sold state must be a combination of existing atoms. This closes the question that previously rested on a partial dump.

2. What closed actually does — the complete flag computation

Decompiled from the auctionInfo deserializer 0x18013e410. local_70 is tradeState, local_40 is bidState. [PE]

if (local_70 == 4) {                              /* tradeState == closed   */
    local_3b = local_40 != 0;                     /* bidState != none       */
} else {
    local_3b = (local_40 - 1U & 0xfffffffd) == 0; /* bidState in {1,3}      */
}
local_3a = local_40 - 2U < 2;                     /* bidState in {2,3}      */

Evaluated:

	none(0)	outbid(1)	highest(2)	buyNow(3)
local_3b, tradeState==closed	0	1	1	1
local_3b, otherwise	0	1	0	1
local_3a (any tradeState)	0	0	1	1

3. The complete record → Flash mapping

From the publisher 0x1801bf030, every property it sets, with its record offset. This supersedes the previous partial list. [PE]

Flash property	record	meaning
TRADEID_LOWER / TRADEID_UPPER	+0x38	tradeId, split into two 32-bit halves
DURATION	+0x90	formatted; FUT_AUCTION_EXPIRED when the value underflows (i.e. expires == 0)
TIME_REMAINING	+0x90	expires, seconds
MIN_CREDITS	+0x78	currentBid
MAX_CREDITS	+0x70	buyNowPrice
RESERVEDPRICE	+0x74	startingBid
YOURBID	+0xb8	bidState, passed through verbatim
STATE	+0x88	tradeState, passed through verbatim
COINS_AWARDED	+0xbf	the coinsProcessed atom (0x2f4), u8
UUID_UPPER / UUID_LOWER	itemData+8
CARD_ID / FIFA_ID	itemData+0x18	FIFA_ID masks & 0xffffff
CARD_TYPE	itemData+0x4c
CARD_OFFERSTATE	itemData+0x5c	itemState
IS_WATCHED	+0xbc	watched atom
INBOX	+0xbe	local_3a — bidState ∈ {highest, buyNow}
IS_GLOW	+0xbd	local_3b — the table in §2
TRADE_DATA_AVAILABLE	—	constant 1

coinsProcessed's consumer is now traced. The corpus recorded its type and noted that no consumer had ever been found; it is published to the movie as COINS_AWARDED. That is a settlement/"you have been paid" signal, exactly as the corpus guessed but never demonstrated.

4. highest vs buyNow on a closed row is UNDECIDABLE from CardsDLL

[UNDECIDABLE], and this is a proof, not a failed search.

For tradeState == closed, §2 gives IS_GLOW = (bidState != none) and INBOX = (bidState ∈ {highest, buyNow}). Both highest(2) and buyNow(3) therefore produce IS_GLOW=1, INBOX=1 — bit-identical. No native consumer can tell them apart.

But §3 sharpens why it is undecidable: bidState is not consumed only through those flags. It is published verbatim as YOURBID, alongside STATE and COINS_AWARDED. The movie receives the raw values. So the discrimination exists — it just lives entirely in the APT/ActionScript front end, which is unread.

Consequence: no amount of further CardsDLL work can answer "which bidState does a seller see". Only an AVM1 read of external/ion_fut/screens/trading/tradepile, or a live behavioural A/B, can. This retires the question as a static target.

The corpus's own lifecycle table (fifa17-recon/docs/plan-2026-08-06-transfer-market.md:720-729) asserts the seller sees closed / highest with coinsProcessed 1, and assigns closed / buyNow to the buyer. That is [PLAN], and it contradicts the common third-party lore that a sold seller row is closed + buyNow. Given §4 the contradiction cannot be resolved statically — but note the corpus reading is the one that leaves buyNow meaning "I bought it now", which is self-consistent with YOURBID being a property about the viewer's own bid.

5. The clear-sold verb EXISTS — PE-proven

The request builder 0x1801647c0: [PE]

if (*(longlong *)(param_1 + 0x10) == 0) {
    FUN_180007f80(&local_38, 0x20, "/sold");   /* no tradeId -> bulk    */
} else {
    FUN_180007f80(&local_38, 0x20, "/%lld");   /* one specific tradeId  */
}

One builder, two forms, on route base ut/delete/%s/trade (DELETETRADE), response class RS4:FutISRemoveTradeServerResponse (0x180228bc8, with the /sold literal at 0x180228bec immediately after it):

DELETE ut/delete/{ns}/trade/{tradeId}   remove one trade
DELETE ut/delete/{ns}/trade/sold        remove ALL sold trades

Corroborated by the client's own request-name table, where RemoveAllSoldFromTradePile (0x1801efae8) sits beside RemoveFromTradePile, AddToWatchList and RemoveFromWatchList.

Architectural consequence. A bulk "remove all sold" verb only makes sense if sold rows persist in the seller's pile until explicitly cleared. That is incompatible with our current host, where a sold/cancelled listing leaves /tradePile the instant the CAS lands (the Fix A invariant). Implementing the sold path will require revisiting that invariant — and doing so needs live validation, because Fix A itself was a live-confirmed correction.

6. The seller-facing SOLD counter is real, and we hardcode it to 0

A complete chain, wire atom → struct → Flash → localised caption, with no inference at any step. [PE]

Hub tradePile sub-deserializer 0x18013ead0:

atom	id	writes	Flash slot (publisher 0x1800b1dc0, tile 0x1c0)
count	0xbc	+0x1d4	TEXT0 with caption FUT_UC_ITEMS
notification	0x1da	+0x1d6	NOTIFICATION, capped at 99
selling	0x2b8	+0x1d2 (and counts-struct +0x36)	TEXT2 with caption FUT_TF_SELLING
sold	0x2c9	+0x1d8	TEXT3 with caption FUT_TF_SOLD

The sibling tile 0x1d0 (Transfer Targets) uses FUT_TF_WINNING (+0x1c8) and FUT_TF_OUTBID. selling writing two structs independently re-confirms the corpus's counts-struct offset for selling.

So FIFA 17 renders a SOLD count to the seller, sourced from atom sold (0x2c9). Our host and the Python oracle both hardcode sold: 0, so that bucket can never populate. This is direct client evidence about sold — the thing MARKET_SOLD_SETTLEMENT.md required before touching /tradePile/counts. It establishes that sold is displayed; it does not yet establish what should be counted in it (rows awaiting clear? rows sold this session?).

7. Atom-name decoder (method note, reusable)

Atom IDs are indices into an alphabetically sorted pointer table of atom-name strings, base 0x1802d2760. Validated against all twelve known auctionInfo atoms — 12/12 agree — and cross-checked against fifa17-recon/docs/fut_atoms.tsv. [PE]

atom_id = (pointer_slot_address - 0x1802d2760) / 8

Newly resolved: sold=0x2c9, count=0xbc, offered=0x1e5, selling=0x2b8, maxAuctionsAllowed=0x1bf, credits=0xc0, auctionInfo=0x35, total=0x325, duplicateItemIdList=0xec, itemState=0x172, offers=0x1e6, coins=0x95.

Caution when using it: look up a name by finding the pointer slot inside the table range, not by taking the first matching string in the binary. Common words such as sold, offered and count appear in several unrelated tables, and taking the first hit produces confident nonsense (it initially reported sold as ABSENT and offered as a negative index).

8. An auction-outcome vocabulary exists but this client ignores it

The atom table contains a 7-value outcome vocabulary: [PE]

0x36 auctionLostBidRejected   0x39 auctionSoldBid      0x3b auctionWonBid
0x37 auctionLostOutbid        0x3a auctionSoldBuyNow   0x3c auctionWonBuyNow
0x38 auctionLostOutbidSelf

These would distinguish seller-sold-by-bid from seller-sold-by-buy-now explicitly. No CardsDLL deserializer consumes them. Every candidate function that compares against three or more of 0x36..0x3c was checked and none is an atom dispatcher (no value-SKIP 0x180135ff0, no atom loop 0x1801c7f10) — they are small-immediate coincidences. [PE-PROOF] So the vocabulary is server-side or telemetry, and it does not carry the sold state to this client.

9. The 5% fee is NOT in the client — Task B is undecidable from here

[PE-PROOF], three independent absences:

• no 0.95 or 0.05 constant, double or float, anywhere in the binary;
• no localisation key for tax/fee/net/proceeds/commission/"you will receive" — the only FUT_TF_* keys in the binary are SELLING, SOLD, WINNING, OUTBID;
• the 17 functions using both 5/95 and 100 as immediates are all unrelated (they include the item deserializer) — no fee arithmetic exists.

The client therefore never computes or displays a net. It learns the seller's balance only from credits.

This makes the rounding rule unmeasurable by experiment against our own server. Whatever we credit is what the client displays; there is no client-side expectation to compare against, so there is no oracle. The only evidence that could settle floor-the-fee (150 → 143) versus floor-the-proceeds (150 → 142) is an original EA-era capture of a seller's balance across a known-price sale, which we do not have.

Accordingly the rule stays a documented choice: fee = floor(gross × 5 / 100), proceeds = gross − fee, chosen because fee + proceeds == gross holds exactly at every input. It is pinned by regression tests at 0, 1, 19, 20, 21, 39, 40, 100, 101, 119, 120, 149, 150, 151, 199, 200, 1 000, 15 000, 15 000 000 and i64::MAX, so it cannot drift silently.

10. What would close the remaining gaps

Gap	Only remaining route
highest vs buyNow on a seller's sold row	AVM1 disassembly of tradepile.isInActiveAuction / PreCheckCardOptions, or a live behavioural A/B (the movie gets YOURBID verbatim, so the two ARE separable by the client's behaviour)
What sold should count	live observation with a real sold row
Whether sold rows persist until cleared	live: does the client issue DELETE .../trade/sold?
The 5% rounding rule	an original EA-era seller-balance capture; nothing in reach