# Gate Wallet Attribution — 2026-09-22 > **September 23, 2026 figure audit (controlling):** The migration and Nottingham data were rebuilt > on exact per-transfer V1 rates and on Support's "Buys/Inflow" / "Sells/Outflow" worksheet rules. > Figures in this document that differ from the controlling table in `SESSION-HANDOFF.md` are > superseded, including 1.190T → **1.195T**, 2,595/363 → **2,593/365**, featured entitlement > 104.850B → **103.867B**, featured amount still supported at review 64.873B → **63.890B**, > over-allocation 69.732B → **70.715B**, settled formula 704.805B → **636.803B**, settled > difference 1.211T → **1.279T**, final formula 609.697B → **546.049B**, final gross below > 1.094T → **1.157T**, purchase-time share 1.222938% → **1.222671%**, purchase cost $236,772 → > **$237,426**, and still-restricted addresses 40 → **37**. Regenerate rather than hand-copy: > run `research/scripts/audit-page-figures.py`. ## September 22 multi-root accounting overlay The Gate-service classification in this file is unchanged, but the Nottingham formula totals were regenerated after a separate multi-root case audit. The prior root-summed formula double-counted internal V1 transfers between migration roots belonging to the same accepted holder/case. Controlling service-clean totals after that correction: - 55 settled non-Gate cases: **704.804555251B** reconstructed Nottingham formula, **1.211386265733T** net timing-neutral-minus-formula; - 42 final linked non-Gate cases: **609.697231468B** reconstructed Nottingham formula, **1.070257965016T** net timing-neutral-minus-formula; - final gross below timing-neutral: **1.093804048597T** across 38 cases. The Gate exclusion itself does not cause this change. It is a separate correction to how the Nottingham formula is applied within multi-root holder/case positions. ## Status This is the controlling correction for Nottingham wallet linkage after FLOKI's Gate attribution was reconciled. The earlier **61-case settled model** and **48-case final model** are now provenance only. They treated several Gate exchange wallets as if token-flow linkage made them holder-controlled wallets. The service-clean models below supersede that interpretation. The underlying transfer history remains valid. What changed is the identity layer applied to those transfers. ## Public attribution discovered FLOKI's August 30, 2024 post: https://blog.floki.com/important-update-about-recent-floki-transfers-to-gate-exchange-5f8c8d912e6c states that the listed inbound transactions are transfers **from multiple Gate wallets to the FLOKI multisig** and says the affected wallets had been caught in the FLOKI blacklist before the blacklist function was renounced. The post lists 15 inbound transfers, 12 on Ethereum and 3 on BSC. Mapping those transaction hashes back through the exact V4 transfer caches identifies **12 unique Gate-attributed wallets**: - `0x5fc132b0a7027773da9d825728d1a2dc59137165` - `0x41a14a3905a6827964a1ed9359e686ef768e2996` - `0x6eaa9db4ac9def1297365e1b79b965058f641f69` - `0x256568c0f9079f5ae96add3d49517e6f13b7ea6c` - `0xaaefa74e6d545f3487beec39a3f78c49dd3ffb5d` - `0x8271267cec8c994418776862d7ef30fb05d20ff1` - `0xbe496d6e541344d7bdb91055cdb5fc260c73d5a8` - `0x7acab48d2ecedd6bfd8e187f0ea520da76a04662` - `0x2f0c47a2217582b0744cdc51e32596b81c1e1531` - `0x698725516b6759a1511482846a0d27bc872e3906` - `0x1a9472443a990bed5d03c1370de48f54d6a538cd` - `0x5778bc9f6b80a05bddb43cf7ed3356d83a84043d` All 12 are in the final 79-address blacklist. Eleven are in the settled 106-address population. The twelfth, `0xbe496...`, is one of the two addresses present in the January 29 list of 108, removed from the January 30 settled 106, then reintroduced into the final 79. ## Impact on the pre-correction reconstruction Before the service-clean rebuild, the 12 Gate-attributed final addresses appeared in the reconstruction as follows: - **10 were linked to migration positions** in the pre-correction final-79 model. - **2 were unresolved**: `0x5fc132...` and `0x698725...`. - In the settled-106 model, Gate-attributed addresses touch **9 of the 61 reconstructed cases**. - **6 settled cases are represented only by a Gate-attributed blacklist address**. - In the final-79 model, Gate-attributed addresses touch **10 of the 48 linked cases**. - **6 final cases are represented only by a Gate-attributed blacklist address**. The six Gate-only settled cases are: - `settled-case-06` - `settled-case-11` - `settled-case-20` - `settled-case-46` - `settled-case-53` - `settled-case-57` The corresponding final case IDs are: - `position-04` - `position-09` - `position-16` - `position-36` - `position-41` - `position-44` These six cases contributed approximately: - timing-neutral allocation: **172.255B V2** - actual 2021 V2 received by the migration roots: **311.324B V2** - Nottingham formula recognized: **83.896B V2** - timing-neutral minus Nottingham: **88.359B V2** Those six Gate-only cases were subsequently removed from the holder/case aggregate. The figures above are retained only to show exactly what changed between the pre-Gate and service-clean models. ## Post-run case triage The committed Gate-wallet audit confirms that the nine settled cases touched by Gate wallets are not all equally affected. ### Three cases remain independently anchored These cases contain a non-Gate settled-blacklist address or the migration root itself in addition to the Gate-attributed wallet: - `settled-case-16` - `settled-case-21` - `settled-case-48` The Gate attribution changes how the Gate wallet inside those cases should be described, but it does not remove the case's independent link to the underlying migration position. ### Six cases were suspended and excluded These six settled cases are represented only by a Gate-attributed blacklist address: - `settled-case-06` - `settled-case-11` - `settled-case-20` - `settled-case-46` - `settled-case-53` - `settled-case-57` Their pre-correction linkage evidence was: - `settled-case-06`: one-intermediary FLOKI token flow into the Gate wallet - `settled-case-11`: direct FLOKI token flow into the Gate wallet - `settled-case-20`: accepted forensic link based on material FLOKI flow through a low-degree bridge into the Gate wallet - `settled-case-46`: direct FLOKI token flow into the Gate wallet - `settled-case-53`: direct FLOKI token flow into the Gate wallet - `settled-case-57`: accepted forensic link based on FLOKI flow plus a direct native-coin interaction with the Gate wallet None of those six has a second non-Gate settled-blacklist address anchoring the case. The Gate attribution therefore removes the assumption that token flow into the target address is enough, by itself, to identify one holder/case. `settled-case-57` had stronger interaction evidence than the other five, but a native transfer to or from an exchange-controlled address is still not common-ownership proof. The completed prehistory audit did not justify restoring it as a holder-controlled case, so all six Gate-only cases remain excluded from the service-clean model. ### Two formerly "unresolved" addresses are now known service infrastructure The settled addresses: - `0x5fc132b0a7027773da9d825728d1a2dc59137165` - `0x698725516b6759a1511482846a0d27bc872e3906` should no longer be described merely as unexplained holder wallets. FLOKI later identified both as Gate wallets. Their relationship to any underlying customer/migration position remains unresolved, but the address type itself is now known. This is important because it disproves the earlier inference that inclusion in the Nottingham blacklist necessarily meant FLOKI had linked the address to a particular holder/migration position. FLOKI's own later explanation says exchange wallets were caught in the blacklist and that the team had attempted to remove CEX wallets before blacklist renouncement. ### Final accounting impact of excluding the six Gate-only cases Removing the six Gate-only cases changes the settled holder/case comparison from the historical pre-Gate model: - **61 cases / 63 roots** - **56 below / 5 above** - timing-neutral allocation: **2.088446T V2** - actual 2021 V2 received: **2.492532T V2** - reconstructed Nottingham formula: **788.700B V2** - timing-neutral minus Nottingham formula: **1.299746T V2** to the controlling service-clean model: - **55 cases / 57 roots** - **52 below / 3 above** - timing-neutral allocation: **1.916191T V2** - actual 2021 V2 received: **2.181209T V2** - reconstructed Nottingham formula: **704.805B V2** - timing-neutral minus Nottingham formula: **1.211386T V2** The six excluded cases account for approximately **88.359B V2** of the old 1.280T net gap. ### Deterministic prehistory audit completed `research/scripts/audit-nottingham-gate-prehistory.mjs` tested the six Gate-only case wallets plus the two formerly unresolved Gate wallets using evidence available by the January 22, 2022 snapshot. It inspected: - every pre-Nottingham V3 transfer involving the address; - inbound and outbound V3 counterparties; - direct inflow from assigned and competing migration roots; - broader pre-snapshot native/ERC-20 activity; - pre-snapshot interaction with the Gate hot-wallet destination recovered from FLOKI's 2024 disclosed return transactions. The audit recovered Gate's hot wallet and showed that multiple affected blacklist addresses were already interacting with Gate infrastructure before Nottingham. That resolved the methodological question in favor of classifying the addresses as service infrastructure rather than holder-controlled wallets. ## Service-clean conclusion The pre-Nottingham history audit resolves the methodological question. The Gate attribution is not merely a 2024 label. The audit recovered Gate's hot-wallet address `0x0d0707963952f2fba59dd06f2b425ace40b492fe` from FLOKI's disclosed 2024 return transactions, and multiple affected blacklist addresses were already sending FLOKI/USDT to it or receiving ETH from it before the January 22, 2022 Nottingham snapshot. Accordingly, Gate-attributed addresses must be treated as **exchange infrastructure**, not as holder-controlled wallets. This changes the canonical holder/case model as follows: - Historical enforcement counts remain **106 settled addresses** and **79 final addresses**. - The **11 Gate addresses inside the settled 106** remain part of that historical blacklist count, but are excluded from holder-wallet identity. - The **12 Gate addresses inside the final 79** remain part of that historical final enforcement count, but are excluded from holder-facing accounting. - A case survives only where there is an independent non-Gate anchor. - The six Gate-only settled/final cases are excluded from the holder/case comparison. - The two formerly unresolved Gate addresses, `0x5fc132...` and `0x698725...`, are no longer counted as unresolved holder wallets. They are known Gate service infrastructure whose underlying customer provenance is not established. - Gate addresses are stripped from current-balance and treasury-flow totals even when a case survives through a separate non-Gate anchor. ### Settled service-clean model The settled holder/case comparison is now: - **95 non-Gate addresses** inside the historical 106 - **88 linked non-Gate addresses** - **7 unresolved non-Gate addresses** - **57 migration roots** - **55 holder/case positions** - **52 below / 3 above** timing-neutral - timing-neutral allocation: **1.916190821T V2** - actual 2021 V2 received: **2.181208609T V2** - reconstructed Nottingham formula: **704.804555B V2** - timing-neutral minus Nottingham formula: **1.211386266T V2** For the fixed 7.034T migration cohort: - the 57 migration roots represented by those 55 cases received **113.83%** of their timing-neutral allocation in 2021; - the other **2,901 on-time migration addresses** received **94.82%** in aggregate; - the reconstructed Nottingham formula produces **36.78%** of timing-neutral allocation for the 55 reconstructed cases. These figures supersede the 61-case / 63-root / 1.280T holder comparison. ### Final service-clean model The final holder-facing model is now: - historical final enforcement set: **79** - Gate service addresses in that set: **12** - non-Gate final addresses: **67** - linked non-Gate final addresses: **62** - unresolved non-Gate final addresses: **5** - migration roots: **43** - holder/case positions: **42** - **38 below / 4 above** timing-neutral - timing-neutral allocation: **1.679955196T V2** - actual 2021 V2 received: **1.993781346T V2** - reconstructed Nottingham formula: **609.697231B V2** - timing-neutral minus Nottingham formula: **1.070257965T V2** Current non-Gate final-state quantities: - positive restricted non-Gate addresses: **40** - current restricted balance: **376.836483192B FLOKI** - net transferred to treasury addresses from non-Gate final addresses: **1.015464958T FLOKI** The current restricted total changes only by Gate dust because the disclosed Gate balances were moved out through the multisig in 2024. ### Gate treasury-flow correction Across all 12 Gate-attributed final addresses, the raw address-level history records **257.878626998B FLOKI** sent to the whitelisted treasury addresses. FLOKI's August 30, 2024 post explicitly documents **257.128626417B FLOKI** of those Gate balances being routed through the whitelisted multisig and then returned in exact amounts to Gate's requested hot wallet. That documented Gate rescue must not be described as unresolved holder value retained by FLOKI. An additional approximately **750.000581M FLOKI** of Gate-address-to-treasury flow predates the documented August rescue and remains a separate historical flow. The holder-facing model excludes all Gate infrastructure flow rather than treating exchange-service transfers as holder confiscation. ### Canonical service-clean files - `research/data/nottingham-service-clean-settled-case-model.csv` - `research/data/nottingham-service-clean-settled-case-model-summary.json` - `research/data/nottingham-service-clean-final-case-model.csv` - `research/data/nottingham-service-clean-final-case-model-summary.json` - `research/data/nottingham-gate-service-disposition-summary.json` - `research/scripts/build-nottingham-service-clean-models.mjs` These now control holder/case accounting. The earlier 61-case and 48-case files remain useful as historical reconstruction provenance but must not drive live holder-facing totals. ## Analytical consequence A direct token path into a Gate-attributed wallet can establish **token provenance**. It does **not**, by itself, establish that the Gate wallet and the sending migration address were controlled by the same holder. Exchange deposit and operational wallets can receive tokens from unrelated customers. The controlling rule is therefore: > service-mediated token flow may support provenance, but not holder identity For Gate-attributed targets, a holder/case link survives only when independent non-Gate evidence anchors the migration position. This is why three Gate-touched settled cases remain while the six Gate-only cases are excluded. The two Gate wallets formerly classed as unresolved are not assigned to migration positions. Their address type is resolved as Gate infrastructure; their underlying customer provenance is not. ## Important nuance FLOKI's August 2024 post establishes the public Gate attribution and says the affected addresses had been caught in the old blacklist. The pre-Nottingham audit adds independent timing evidence: multiple affected addresses were already interacting with the recovered Gate hot-wallet infrastructure before the January 22, 2022 snapshot. That supports classifying the addresses themselves as exchange infrastructure for the holder/case model. It still does not identify the beneficial owner of every token balance passing through those Gate wallets. The service-clean model therefore does not attempt to assign the Gate balances to underlying customers unless separate holder-level evidence exists. ## Reproduction Run the attribution and prehistory audits: ```bash node research/scripts/audit-nottingham-gate-wallets.mjs node research/scripts/audit-nottingham-gate-prehistory.mjs ``` Then rebuild the controlling service-clean models: ```bash node research/scripts/build-nottingham-service-clean-models.mjs ``` Key outputs: - `research/data/nottingham-gate-wallet-audit.json` - `research/data/nottingham-gate-wallet-audit.csv` - `research/data/nottingham-gate-prehistory-audit.json` - `research/data/nottingham-gate-prehistory-audit.csv` - `research/data/nottingham-service-clean-settled-case-model.csv` - `research/data/nottingham-service-clean-settled-case-model-summary.json` - `research/data/nottingham-service-clean-final-case-model.csv` - `research/data/nottingham-service-clean-final-case-model-summary.json` - `research/data/nottingham-gate-service-disposition-summary.json` The live Chapter 9 now uses the service-clean outputs.