NOTTINGHAM: FLOKI’s Dark History

Cropped migration message explaining that the swap would move liquidity into a new contract. — source

PetaByte replies that it will all be proportional, with some deductions made due to extreme inflation at the end of the snapshot period. — source

By the time the migration opened on July 4, FLOKI was less than nine days old. The token had already built a sizable community, even as a bug in its reflection mechanism was multiplying holder balances far beyond anything the contract's reported supply could account for.

A new team formed to attempt an emergency rescue. Their plan was to move the liquidity, replace the flawed contract, and carry the community into a new version of FLOKI. Holders were asked to send their $FLOKI V1 to a migration address and wait for the new tokens to be distributed.

The announced rate was 1:1. Holders were told that $FLOKI V1 sent to the migration wallet before the July 6, 2021 deadline would be matched with the same number of $FLOKI V2 tokens.

After the deadline, the 1:1 plan changed. FLOKI introduced timing-based reductions to account for the rapidly growing $FLOKI V1 balances recorded during the migration, cutting some V2 payouts by as much as 50 percent. The stated goal was a fair proportional split.

source

Did those timing reductions produce a fair proportional split? First, we need to understand what the growing $FLOKI V1 balances represented.

V1 contract · one wallet that never moved

A holder with 1 billion $FLOKI V1 when the migration opened, who never sent or received a token
Moment	Wallet shows	Growth
Migration opensJuly 4	1.0 bn	1×
Half the deposits inJuly 5	1.9 bn	1.9×
Migration deadlineJuly 6	7.0 bn	7.0×
Internal position `_rOwned`	≈ 2.1 × 10⁷³ · never changes

V1 contract verified source

The changing balance

The clearest way to see what was happening is to follow a wallet that never moved. It made no buys, sales or transfers during the migration. Even so, the balance shown in the wallet kept changing.

The V1 contract stored each holder's position as an internal reflected amount (_rOwned). Whenever a balance was read, balanceOf() divided that amount by the current reflection rate (currentRate, calculated by _getRate()) to produce the $FLOKI V1 balance shown in the wallet. As the rate fell, the same internal position converted into a larger token balance.

By the migration deadline, that unchanged position was showing about seven times as many $FLOKI V1 as it had when the migration opened.

The same balance expansion was happening across V1. totalSupply() still returned one trillion $FLOKI V1, while the effective supply represented by holder balances was growing far beyond it.

Deep dive · How the V1 reflection bug inflated balances Contract-level explanation of the fee mismatch, reflection rate and expanding balances.

Technical view · V1 contract transfer accounting

Ordinary token calculation: tTransferAmount = tAmount - reflection fee - team fee
Reflected calculation: rTransferAmount = rAmount - reflection fee
Then separately: _takeTeam(team fee)credits the team fee to the contract in reflected units
For the books to balance: rTransferAmount = rAmount - reflection fee - team feethe team fee is never subtracted on the reflected side

Verified source · relevant functions

_getTValues()line 1021: tTransferAmount = tAmount - tFee - tTeam
_getRValues()line 1028: rTransferAmount = rAmount - rFee
_takeTeam()line 998: rTeam = tTeam × currentRate_rOwned[address(this)] += rTeam
_reflectFee()line 1006: _rTotal -= rFee
_getRate()line 1035: currentRate = rSupply / tSupply
tokenFromReflection()line 801: require(rAmount <= _rTotal, "Amount must be less than total reflections")balance = rAmount / currentRate

The contract keeps two sets of books for every transfer: token amounts, prefixed t, and reflected amounts, prefixed r. A balance is stored in reflected units and converted to tokens on read.

On a taxed transfer, the V1 contract calculated two fees: a reflection fee (tFee) and a team fee (tTeam). The ordinary token calculation subtracted both. The reflected calculation subtracted only the reflection fee, while the team fee was credited separately to the contract through _takeTeam().

With a 10% reflection fee, a 10% team fee, and a 100-token transfer, the ordinary calculation sends 80 tokens to the recipient. The reflected calculation credits the recipient with 90 tokens' worth of reflected units, while _takeTeam() credits another 10 tokens' worth to the contract.

The sender loses 100 tokens' worth of reflected units. The recipient and the contract together are credited with 100 tokens' worth. _reflectFee() then reduces _rTotal by the reflected value of the 10-token reflection fee.

Normally the recipient is credited rAmount - rFee and nothing offsets it, so the total of _rOwned falls by exactly rFee, in step with _rTotal. The extra _takeTeam() credit breaks that. Here the sender's debit is matched exactly by the credits to the recipient and the contract, so the total of _rOwned is unchanged while _rTotal falls.

currentRate is calculated as rSupply / tSupply, where rSupply tracks _rTotal. As _rTotal falls, currentRate falls with it, and the balance reported by balanceOf(), _rOwned / currentRate, converts into more $FLOKI V1.

That is how reflections are meant to pay out: the fee reduces the reflected total, the rate falls, and holder balances increase. Here the team portion was credited back to the contract in reflected units instead of being removed from the reflected accounting, so _rTotal fell without a matching reduction in the reflected balances credited through the transfer.

Repeated taxed transfers compounded the mismatch. As _rTotal and currentRate fell without a corresponding reduction in the reflected balances credited through this path, the token balances produced by _rOwned / currentRate continued to expand while totalSupply() kept returning 1 trillion.

Eventually some balances became impossible to compute. _rTotal only ever falls, while a wallet that keeps receiving accumulates _rOwned. As those transfers accumulated, the migration wallet eventually crossed that threshold. A balanceOf() call on the migration wallet reverts with Amount must be less than total reflections because its stored reflected amount now exceeds the contract's remaining _rTotal.

V1 contract verified source

Suppose a holder has 1 billion FLOKI while the effective supply is 1 trillion. The holder owns 0.1% of the supply.

Now suppose a liquidity pool holds 100 billion FLOKI and 100 ETH. At that balance ratio, 1 billion FLOKI corresponds to 1 ETH.

A liquidity pool is itself an address holding FLOKI. When that address participates in reflections, the FLOKI it holds expands with the same reflection scale as other holders. The ETH side does not.

If reflections double the scale, the holder's balance grows to 2 billion FLOKI, the effective supply grows to 2 trillion, and the pool's FLOKI balance grows to 200 billion. The ETH side of the pool is still 100 ETH.

The holder still owns 0.1% of the supply. But the pool ratio has changed: it now takes 2 billion FLOKI to correspond to 1 ETH. The holder has twice as many FLOKI, but those 2 billion FLOKI still correspond to the same 1 ETH.

As the V1 inflation bug expanded balances, more tokens did not make the holder's position larger. The additional tokens preserved the holder's share as the scale expanded.

If the scale has doubled but the holder is reduced back to the original 1 billion FLOKI, the holder no longer owns 0.1%. They own 0.05%. At the illustrated pool ratio, their position falls from 1 ETH to 0.5 ETH, a 50% reduction.

A raw FLOKI count therefore did not represent the same share at every point on the changing V1 scale. As that scale expanded over time, the same number of FLOKI represented a smaller share of the effective supply than it had earlier.

Reflections during the migration

Cropped published explanation saying token distributions were reduced because of accelerating V1 inflation. — source

Before the migration, reflections were generated by baseline economic activity: buys, sells and transfers. The migration concentrated thousands of taxed transfers and sales into a short period, generating a burst of additional reflections.

As far as the migration was concerned, once a holder transferred, their recorded deposit was fixed. Holders who had not yet transferred continued accumulating reflections until their own deposits were recorded.

During the on-time migration window, the effective V1 supply increased about sevenfold in less than two days.

Because the reflection rate was changing so quickly, raw $FLOKI V1 deposit counts recorded at different times were not directly comparable.

Effective V1 supply relative to the 1T totalSupply() value

Migration opens5.5xblock 12758076
4 Jul 2021 · 01:18 UTC

Half the deposits in10.3xblock 12769455
5 Jul 2021 · 19:41 UTC

Deadline38.9xblock 12770867
6 Jul 2021 · 00:59:53 UTC

Verify · Reproduce the effective V1 supply at any block Each multiple is derived from the V1 reflection rate at that block.

Each multiple is the reflection rate at deployment divided by the rate at that block. “Half the deposits in” is the block by which half of the 3,761 on-time migration deposits had landed. The rate is returned by reflectionFromToken(1, false) on the V1 contract.

Calldata

Field	Value
to	`0xb1f4b66104353ec63d8d59d3da42c0b4fb06e7f3` ↗
data	`0x4549b03900000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000`
block	any past block, including the ones under each figure above
rate at deployment	`115792089237316195423570985008687907853269984665640564039`
multiple	rate at deployment ÷ rate returned

The same call at the deadline block, ready to paste:

curl -s https://eth.drpc.org \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0xb1f4b66104353ec63d8d59d3da42c0b4fb06e7f3","data":"0x4549b03900000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000"},"0xc2de33"]}'

Divide the rate at deployment by the value it returns. Change 0xc2de33 to read any other block.

Run that call now, against any block.

Block

12758076migration opens4 Jul 2021 01:18 UTC 12769455 12819418last deposit13 Jul 2021 14:49 UTC

The same call was read at the block before each of the 2,621 blocks in which a deposit landed, which gives the rate in effect when that block began. Where other $FLOKI V1 transfers came first in the same block, the rate moved again before the deposit executed. The rate at each deposit is published separately; it replays each block transfer by transfer, and every replay ends on the state the chain reports for the end of that block.

reflection rate at the start of every deposit block reflection rate at every deposit

V2 contract · supply record

10T $FLOKI V2 total supply

7.034T On-time migrators 70.34% · 2,958 addresses

666B Initial ETH liquidity 6.66% · 8 Jul 2021

2.300T Other V2 supply 23.00%

V2 contract on-time distribution initial ETH liquidity

The V2 ownership scale

Unlike the expanding V1 balance scale, V2 had a fixed total supply of 10 trillion $FLOKI V2. Of that supply, 7.034 trillion was sent by the distribution hubs to the 2,958 on-time migration addresses, while 666 billion seeded the initial Ethereum liquidity pool.

The 2,958 on-time migrators received 7.034T $FLOKI V2 in total. Their V1 deposits, however, had been recorded at different points on the moving V1 scale.

A fair comparison had to separate two things:

01

The reflections already embedded in each holder’s balance when the migration opened. These had accumulated through the baseline economic activity before the migration and were already part of the holder’s V1 position when the migration opened.

02

The additional reflections accumulated after the migration opened, before that holder transferred. These depended on how long the holder waited before transferring while migration-driven transaction activity was rapidly increasing balances.

The first was part of the position the holder brought into the migration. The second depended on when that holder happened to migrate and had to be normalized for timing.

FLOKI Blog · published distribution schedule · July 8, 2021

12+ hours 100%0% reduction

12–9 hours 90%10% reduction

9–6 hours 80%20% reduction

6–1 hour 70%30% reduction

1 hour–30 min 60%40% reduction

30–10 min 60%40% reduction

Final 10 min 50%50% reduction

source

Cropped FLOKI explanation stating that distributions were also reduced for the 20 percent $FLOKI V1 transfer tax and a 10 percent BulkSender charge. — source

The payout

The migration closed at 01:00 UTC on July 6. With the V1 deposits now recorded, FLOKI calculated the V2 payouts and began distributing them two days later. On July 8, 2,957 of the 2,958 on-time migrators received $FLOKI V2. FLOKI also published the timing schedule it said it had used to adjust each payout according to when the holder's deposit arrived.

The Brackets

Each deposit was assigned a payout percentage according to how long before the deadline it arrived. Earlier deposits received a larger percentage of their recorded $FLOKI V1 count. The percentage stepped down as the deadline approached, reaching 50 percent for deposits made during the final ten minutes.

The team attributed the reductions to accelerating $FLOKI V1 balance inflation during the final hours before the deadline. Their stated objective was to keep the resulting supply at a sensible level while treating holders fairly.

FLOKI also said the final distribution reflected two additional reductions: the 20% $FLOKI V1 transfer tax incurred when holders sent their tokens to migrate, and a further 10% associated with sending the airdrop through BulkSender.

What the brackets were meant to do

Each bracket was defined by time before the deadline. Every deposit within a given time band received the same payout percentage.

The intended result was a proportional distribution. Two holders who entered the migration with equivalent positions should ultimately have received equivalent shares of the $FLOKI V2 distributed to migrators, regardless of when their deposits were recorded.

Migration window · July 4–6, 2021

Deposits over time by timing cohort

The bars show how much $FLOKI V1 was recorded as deposited during each part of the migration. The shaded bands mark FLOKI's published timing cohorts. Deposits inside each band were subject to the cut shown at the top of that cohort.

Loading deposit activity…

The on-time distribution

By the July 6, 2021, 01:00 UTC deadline, 2,958 addresses had made at least one migration deposit. Every one received $FLOKI V2. Through five of the seven distribution hubs the team used, those addresses received a combined 7.034T $FLOKI V2.

On-time migrators 2,958 addresses

$FLOKI V2 received 7.034T 70.34% of the 10T supply

Distribution hubs 7 traced · 5 paid the cohort

On-time unpaid 0 addresses

Verify · Reconstruct the on-time cohort and V2 distribution Every qualifying deposit and matched V2 transfer used to reproduce the 2,958-address cohort and the 7.034T sent to it.

Methodology

How the cohort and V2 distribution were reconstructed

To reconstruct the on-time distribution, we started with every $FLOKI V1 deposit that reached the migration wallet before the deadline, grouped them by sender, and then traced $FLOKI V2 transfers from the seven distribution hubs to those same addresses. That reconstructs the 2,958-address cohort and the 7.034T $FLOKI V2 the traced hubs sent to it.

01

Set the cutoff

The announced migration deadline was July 6, 2021 at 01:00 UTC. The deposit side of the reconstruction begins with every $FLOKI V1 Transfer into the migration wallet and records the first deposit from each sending address. An address enters the on-time cohort when that first deposit lands at or before the cutoff.

Migration wallet

0x4D9f4B051f35367A78427fb6C8093C79B39DB612 ↗

Cutoff

6 Jul 2021 · 01:00 UTC

Original migration instructions ↗
02

Build the on-time cohort

Group the migration transfers by sending address and classify each address by its first deposit. That produces 2,958 unique on-time addresses. Across the complete migration there were 3,080 depositing addresses, with 122 whose first deposit landed after the cutoff. Only migration transfers that themselves landed by the deadline count toward the on-time cohort's V1 deposit total.

Summing the 3,761 deposits that landed by the deadline from those qualifying addresses gives 10,837,302,188,550.752 $FLOKI V1. This is a transaction subtotal, not a supply figure or a timing-normalized claim. The live deposit table below still shows every migration transfer and whether it landed before or after the cutoff.

03

Trace the V2 distribution routes

The $FLOKI V2 distribution cannot be reconstructed from the main BulkSender alone. Route discovery began by indexing the complete $FLOKI V2 Transfer history from contract deployment for offline graph tracing. The transfer graph was then traced around the main BulkSender, the distribution funder and the connected wallets and contracts. That process identified the seven distribution sources listed below.

The audit then collected every outgoing $FLOKI V2 transfer from each of those seven sources and matched the recipients against the on-time cohort. All 10 trillion $FLOKI V2 were minted to the distribution funder, one of these seven hubs. As of September 26, 2026 (Ethereum block 26,063,549), the seven hubs hold 4.059B $FLOKI V2 combined, 4.049B of it in contract 0x6b5b. The cohort match reaches all 2,958 on-time migrators: five of the seven hubs sent V2 to at least one cohort address, totaling 7,033,850,777,434.76 $FLOKI V2.

Complete $FLOKI V2 transfer collector ↗ Transfer-graph tracer ↗ Seven-route collector ↗

Route	Hub	Transfers	Recipients	V2 to cohort
BulkSender	`0xd1917932A7Db6Af687B523D5Db5d7f5c2734763F`	…	…	…
Disperse	`0xd152f549545093347a162dce210e7293f1452150`	…	…	…
Funder direct	`0x04e019F6a7cd5b2F64bB8f6A1142dAb7fc95fe38`	…	…	…
Shuttle 0x7275	`0x7275052f1ae220b3d8e97c724920e7ffc02c4c88`	…	…	…
Contract 0x6b5b	`0x6b5b71dfa3fcbb5ad755ab90466e1a8cbc0dbc14`	…	…	…
Operator 0xa99c	`0xa99c602037f8E85A44bbe88f3C0EE3Af60345B9b`	…	…	…
Wallet 0x6117	`0x6117d5b0f51f43407b3bd66908d040902bd35d9f`	…	…	…

$FLOKI V2 transfer record ↗

04

Match V2 transfers to the cohort

Each outgoing $FLOKI V2 transfer is tested against the 2,958-address cohort. Transfers to an on-time migrator are included regardless of which distribution route sent them. If one address received $FLOKI V2 in multiple transfers or through multiple routes, all of those transfers are added to that address.
05

Verify the observed distribution

Summing the matched $FLOKI V2 transfers produces 7,033,850,777,434.76 $FLOKI V2. The same match finds at least one V2 transfer for 2,958 of the 2,958 on-time addresses, leaving 0 with no matched V2 transfer.

Open this verifier to load the underlying transfer records and run the check.

Unique on-time addresses2,958

$FLOKI V1 deposited by cohort10.837T10,837,302,188,550.752

$FLOKI V2 received7.034T7,033,850,777,434.76

Addresses receiving V22,958

On-time with no matched V20

Inspect the records

The transactions behind the totals

The reconstruction can be followed through the records below, from the $FLOKI V1 deposits into the migration wallet to the matched $FLOKI V2 transfers from the seven traced distribution routes.

Search this view

Loading records…

Cohort shows one row per address with at least one migration deposit by the deadline. $FLOKI V1 totals include only deposits that themselves landed by the deadline; $FLOKI V2 totals include every matched transfer from the seven traced distribution routes.

V2 received above 1:1

2,734 of the 2,958 on-time migrators received $FLOKI V2 at or below the total $FLOKI V1 they deposited. A group of 224 received more. Together, those additional receipts totaled 553.008B V2 above 1:1.

FLOKI’s published brackets reduced migration payouts; they do not explain why these 224 addresses received more V2 than the V1 they deposited. Nothing we found in FLOKI’s migration communications or in the bracket calculations explains the difference. We include these addresses here because they appeared in the on-chain distribution record. The reason for the additional V2 remains unresolved.

Find an address or V2 source

Loading 224 addresses…

Address	V1 deposited	V2 received	V2 / V1	Above 1:1	V2 sources

Download complete CSV

That 7.034T $FLOKI V2, the total the distribution hubs sent to the 2,958 on-time migrators, is treated here as the fixed amount the brackets had to divide among them.

Did they divide it proportionally?

Building the position

We will follow one position, held across two addresses, from the July migration through the Nottingham review. It was built through 31 $FLOKI V1 purchases between July 1 and July 3, 2021, before the migration opened.

Across the 31 purchases, the position acquired 43.881B $FLOKI V1 for $237,426. Measured against the effective V1 supply at the time of each purchase, those purchases represented a combined 1.222671% share of the effective V1 supply.

Purchases31

$FLOKI V1 acquired43.881B

Purchase consideration$237,426

Purchase-time share1.222671%

UTC	V1 bought	USD spent	Effective supply	Implied cap	Supply share
1 Jul · 06:16	798,248,828	$11,128	3,143,470,828,017	$43.82M	0.025394%
1 Jul · 06:41	698,075,830	$10,753	3,145,040,287,470	$48.45M	0.022196%
1 Jul · 07:07	680,723,659	$10,819	3,149,146,853,426	$50.05M	0.021616%
1 Jul · 07:21	447,204,395	$6,957	3,151,562,024,035	$49.02M	0.014190%
1 Jul · 07:23	468,406,708	$7,640	3,151,968,686,844	$51.41M	0.014861%
1 Jul · 07:31	444,597,891	$7,426	3,154,824,646,290	$52.70M	0.014093%
1 Jul · 07:33	182,217,022	$3,019	3,155,198,369,024	$52.28M	0.005775%
1 Jul · 07:43	498,593,498	$8,629	3,156,572,367,441	$54.63M	0.015795%
1 Jul · 07:51	295,006,352	$5,028	3,158,125,422,128	$53.83M	0.009341%
1 Jul · 07:56	445,035,014	$6,860	3,159,777,434,083	$48.70M	0.014084%
1 Jul · 10:14	855,257,106	$10,519	3,200,416,233,741	$39.36M	0.026723%
1 Jul · 10:20	897,015,124	$10,557	3,203,501,667,773	$37.70M	0.028001%
1 Jul · 10:22	922,736,889	$10,557	3,204,604,494,124	$36.66M	0.028794%
1 Jul · 10:24	893,297,898	$10,535	3,205,833,156,036	$37.81M	0.027865%
1 Jul · 10:25	176,274,049	$2,104	3,206,554,650,396	$38.27M	0.005497%
1 Jul · 10:27	372,547,845	$4,208	3,207,224,483,656	$36.22M	0.011616%
1 Jul · 19:44	872,013,778	$6,630	3,451,741,257,855	$26.25M	0.025263%
1 Jul · 20:02	663,031,726	$4,860	3,471,238,392,415	$25.44M	0.019101%
1 Jul · 20:06	873,804,371	$6,589	3,472,816,826,502	$26.19M	0.025161%
1 Jul · 20:07	788,084,292	$6,339	3,474,204,938,644	$27.94M	0.022684%
1 Jul · 20:13	172,448,218	$1,286	3,476,953,174,105	$25.94M	0.004960%
1 Jul · 20:30	3,012,581,085	$12,575	3,514,594,097,116	$14.67M	0.085716%
1 Jul · 20:31	3,245,535,069	$12,538	3,521,221,516,126	$13.60M	0.092171%
1 Jul · 20:39	1,657,652,467	$8,456	3,549,046,172,871	$18.11M	0.046707%
1 Jul · 20:40	843,305,103	$4,229	3,550,560,422,351	$17.80M	0.023751%
1 Jul · 20:52	9,444,189,878	$12,612	3,680,348,115,214	$4.91M	0.256611%
1 Jul · 20:55	5,761,383,509	$8,458	3,741,372,329,898	$5.49M	0.153991%
1 Jul · 21:00	1,640,052,414	$6,355	3,799,906,452,879	$14.72M	0.043160%
1 Jul · 21:15	2,447,841,900	$8,458	3,909,740,195,178	$13.51M	0.062609%
1 Jul · 21:27	1,253,131,110	$5,089	3,938,643,750,520	$15.99M	0.031816%
3 Jul · 01:34	2,130,636,933	$6,213	4,940,337,734,577	$14.41M	0.043127%
31 purchases	43,880,929,960	$237,426	3,588,939,342,917	$19.42M	1.222671%

The migration

By the migration, the position was held across 0xc1563bdf…6913d and 0x13422803…4f36. Both made their on-time migration deposits at 00:59:53 UTC on July 6. Together, those two deadline-qualifying transfers totaled 391.582B $FLOKI V1.

Those first deposits landed in the final ten minutes before the deadline, placing both addresses in FLOKI's published 50% timing bracket. FLOKI later sent the two addresses a combined 174.583B $FLOKI V2 in the July distribution, equal to 44.584% of the 391.582B $FLOKI V1 recorded by the cutoff.

Address	First deposit	V1 by deadline	Full V1	V2 received
`0xc1563bdf…6913d`	6 Jul 2021 · 00:59:53	269,263,862,848.08	270,652,079,077.41	120,150,000,000.00
`0x13422803…4f36`	6 Jul 2021 · 00:59:53	122,318,007,598.44	126,892,948,595.85	54,432,679,027.46
Combined		391,581,870,446.52	397,545,027,673.26	174,582,679,027.46

Published timing bracket50%payout

By deadline391.582B$FLOKI V1

Actual payout44.584%of V1 recorded by deadline

July distribution174.583B$FLOKI V2 received

Six months later, the wallets holding this position would be blacklisted.

January 17–22, 2022

A seamless upgrade

FLOKI's upgrade announcement says the process is completely seamless and tells ordinary wallet holders that no action is required. — source

Six months after the July migration, FLOKI was preparing another upgrade. V2 had already become V3 on August 8, 2021, with holders receiving V3 automatically 1:1. On January 17, 2022, FLOKI announced the next move, from V3 to V4, as part of its transition toward DAO governance. FLOKI called it the Nottingham upgrade.

V3 upgrade announcement

For ordinary wallet holders, the instructions were simple: no action was required. The upgrade was described as “completely seamless.” Holders were told to “just hold and relax.”

The V3-to-V4 snapshot was taken at 08:00 UTC on January 22. V4 was distributed 1:1 from the V3 balances recorded at that snapshot.

completion announcement

July 2021V1 → V2
Migration distribution
August 8, 2021V2 → V3
Automatic 1:1 successor upgrade
January 22, 2022 · 08:00 UTCV3 → V4
Nottingham snapshot · 1:1

FLOKI's Nottingham explanation says its review revisited the V1-to-V2 migration distribution. — source

The migration reopened

During preparations for Nottingham, FLOKI's lead developer audited the earlier contracts and the V1-to-V2 distribution.

The July migration had already tried to compensate for V1 inflation with the timing brackets described earlier. The audit concluded that those cuts had not gone far enough. It also concluded that the airdrop calculation itself had widened the difference between earlier and later migrators.

The balances entering V4 had already moved through V2 and V3. The July distribution was now being recalculated.

FLOKI explains its wage-based threshold and says wallets receiving more than 7.21 billion tokens in the V1-to-V2 migration were blacklisted. — source

Who was blacklisted

Restrictions began while V4 was still being distributed. The published selection rule started with the amount of V2 each wallet had received in the V1-to-V2 migration.

FLOKI used $43,342.29, the 2019 average annual wage across OECD countries, and divided it by $FLOKI V2's opening price. That produced a cutoff of 7.211B $FLOKI V2. Wallets that had received more than that amount during the V1-to-V2 migration were selected for the blacklist. The published blacklist also included wallets connected to those migration positions after tokens had moved between addresses.

Both migration addresses in the tracked position exceeded the cutoff. The position was now inside Nottingham.

Blacklist timeline · January to April 2022 How the restricted addresses changed through the Nottingham review.

FLOKI published several versions of the blacklist as the review progressed. The restrictions enforced on-chain did not always change at the same time.

The published review list began with 207 addresses, narrowed to 157 on January 28, then 108 on January 29, and 106 on January 30. No addresses were added as the sheet narrowed; each revision only removed addresses.

On Ethereum, restrictions began on January 23 with a handler containing 706 addresses. The following day, FLOKI replaced it with a 242-address restriction containing all 207 published addresses and 35 additional addresses that were never published. The same 242-address set became active on BSC on January 25.

When the published list narrowed to 157 on January 28, those addresses remained restricted within the active 242-address set. On January 29, FLOKI loaded the 108 addresses shown on that day's sheet into new mutable blacklist handlers on both chains. The 242-address restriction remained active while those new handlers were prepared.

Two addresses were removed from those handlers on January 30, leaving the same 106 addresses shown on the January 30 sheet. On January 31, BSC switched from the 242-address restriction to the 106-address handler at 12:19 UTC. On Ethereum, the 242-address handler came off at 17:01 UTC, transfers were halted for 73 minutes, and the 106-address handler went live at 18:15 UTC.

Addresses were released from the 106-address blacklist during February and March. Immediately before the April 3 handler replacement, 64 remained blacklisted on Ethereum and 65 on BSC. The BSC set was the same 64 plus 0xf81d4e…326d.

The April 3 replacement handlers then contained 79 addresses on each chain, and the two sets were identical. Those 79 included every address still restricted at the end of the mutable phase plus additional addresses, including addresses that had previously been released. They also included 0xbe496d…d5a8 and 0xcd38dc…3cf8, the two addresses removed between the 108 and 106. Both had been restricted under the earlier 242-address set, were released when the 106 became active, and were blacklisted again in the final 79. The April 4 final handlers preserved that same 79-address set, which remains the active set on both chains today.

The blacklist itself was enforced outside the V4 token contracts. V4 passed transfers through a replaceable tax handler, and the active handler could block transfers from listed addresses. The handler changes make each stage of the restriction visible on-chain.

The published list narrowed 207 → 157 → 108 → 106. On-chain restrictions began earlier and more broadly: 706 addresses on Ethereum, then 242 across the published population, followed by the 106-address blacklist, releases to 64 on Ethereum and 65 on BSC, and the final 79 on both chains.

published-sheet history settled-106 audit cross-chain enforcement closeout address-by-stage audit

The new calculation

The 7.211B cutoff selected the wallets. FLOKI then calculated how much of each selected wallet's balance it considered “excess,” based on when the holder had migrated.

A committee was created to review positions individually and hear appeals.

For each blacklisted position, the calculation now drew the line between what Nottingham called excess and what the holder could keep.

What did a holder have to do to get their wallet released?

Over the next five months, DAO voters were presented with proposals setting the terms: what had to be returned, how the remaining balance would be released, and when the review would close.

February 9–11, 2022

Return before release

Snapshot proposal and vote on whether blacklisted wallets should return tokens classified as excess before release. — source announcement

By the first DAO vote on February 9, the selected wallets were already restricted. The vote made returning the amount classified as “excess” a condition for having a wallet removed from the blacklist.

The alternative presented by the vote was to clear the blacklisted wallets without requiring that return. Voters approved the return requirement. The destination of the returned tokens would be decided separately.

February 18–19, 2022

The remainder would be vested

Snapshot proposal and vote on vesting the remaining balance over six months. — source

A second proposal addressed what would happen after a holder returned the amount classified as “excess.” The committee set up to review affected holders estimated that approximately 1.3 trillion tokens were to be returned and approximately 346 billion tokens it classified as “legitimately owned” would remain with the affected wallets.

The proposal called for that remaining balance to vest over six months in monthly releases, which FLOKI said was intended to reduce the risk of a coordinated sell-off.

March–April 2022

Renunciation and the multisig route

Snapshot proposal and vote on renouncing FLOKI's blacklist functions. — source

FLOKI's Discord FAQ says existing wallets will remain blacklisted after renunciation, while the multisig remains permanently whitelisted so affected holders can return excess tokens and have the approved remainder vested to another wallet. — source renunciation announcement

In March, voters approved renouncing the blacklist functions. FLOKI presented the change as a step toward decentralization and as reassurance that future holders could not be blacklisted. Once those functions were renounced, addresses still on the blacklist could no longer be removed.

FLOKI kept the project multisig permanently whitelisted, allowing those holders to return tokens and have the approved remainder vested to a different, unrestricted wallet.

July 18–20, 2022

A deadline for the review

The July deadline proposal sets September 12, 2022 as the last date for returning tokens and states that noncompliant wallets will remain blacklisted permanently. — source

In July 2022, FLOKI proposed closing the review. It said five months had provided sufficient time and maintaining the process indefinitely was impractical.

The proposal set September 12, 2022 as the final deadline to return the required tokens. After that date, wallets that had not complied would remain permanently blacklisted.

July 18–20, 2022

Where the returned tokens would go

The July 2022 proposal explains FLOKI's treasury needs and asks voters to choose between burning returned tokens and allocating them to Valhalla and the ecosystem. — source

During the same July 2022 voting window, a separate proposal returned to the question deferred in February 2022: what should happen to the returned tokens.

Rather than burn them, voters approved allocating them to Valhalla and the FLOKI ecosystem. FLOKI said the tokens would be used for project development, citing its limited treasury.

Every one of those decisions depended on the amount FLOKI classified as “excess.” That number determined what a blacklisted holder had to surrender before the remaining balance could be released.

How did the review calculate it?

Floki Support email stating the written expression V4 minus the quantity V2 Airdrop minus V1 Net Transactions plus 0.5 percent Reflections. The accompanying calculation applies the 0.5 percent allowance differently. — From a 2022 holder-review email sent by Floki Support. source

July 2021 cuts vs. 2022 blacklist review

July 2021 Recorded V1 deposit Timing bracket V2 payout

2022 review V1 buys − V1 sells Add 0.5% of that amount as “V1 Reflections” Amount recognized

In 2022, FLOKI moved from a timing-based adjustment to a calculation that took V1 buys minus V1 sells, then added 0.5% of that net amount as “V1 Reflections,” while treating the remainder of the V2 airdrop above that amount as “excess.”

February 13, 2022

The review calculation

Under Nottingham, FLOKI did not use the July timing brackets again. Blacklisted holders received a new calculation from FLOKI Support. It determined how much of each holder's balance the review would recognize and how much it would classify as “excess.”

The calculation used the holder's V1 buys and sells rather than the migration deposit and its timing. FLOKI Support gave the formula as:

V4 − ((V2 Airdrop − V1 Net Transactions) + 0.5% Reflections)

FLOKI Support also included a worksheet showing how the formula was applied to the holder’s position. In that worksheet, V2 Airdrop referred to the holder’s July 2021 $FLOKI V2 migration distribution, while V1 Net Transactions meant V1 buys minus V1 sells.

The worksheet credited 0.5% of V1 Net Transactions as “V1 Reflections.” That differs from the formula as written in the email, so the calculations below follow the worksheet arithmetic.

The “V1 Reflections” allowance was a fixed 0.5% of net V1 transactions. The review materials give no reason for choosing 0.5%, and the calculation did not use the holder's accumulated reflections, holding period, or the V1 contract's reflection rate.

The review result

Review calculation · tracked position

1 · Amount recognized 43.881B + 0.219B = 44.10B

2 · “Excess Tokens” 174.583B − 44.10B = 130.482B

3 · Final balance 124.505B − 130.482B = −5.977B

The arithmetic shown in the accompanying 2022 review calculation.

Applied to the tracked position, Support recorded 43.881B $FLOKI V1 in buys, no V1 sales, and added 219.4M $FLOKI as its fixed 0.5% “V1 Reflections” allowance. That produced 44.10B $FLOKI as the amount recognized by the review.

The table then subtracted that 44.10B from the 174.583B $FLOKI V2 migration distribution. It classified the remaining 130.482B $FLOKI as “Excess Tokens.”

Under the release terms FLOKI had already established, that classification carried a direct consequence: returning the amount classified as “excess” was a condition of release from the blacklist.

The calculation listed a V4 balance of 124.505B $FLOKI. After subtracting the 130.482B classified as excess, the worksheet ended at −5.977B $FLOKI.

Against the 7.034T $FLOKI V2 distributed to on-time migrators, the 44.10B recognized by the review represents 0.6270%:

44.10B ÷ 7.034T = 0.6270%

That was the share produced by the 2022 review formula.

Review detail · The worksheet missed 10.100B $FLOKI The worksheet used 124.505B $FLOKI; the complete cross-chain balance was 134.605B.

FLOKI Support's calculation used 124.505B $FLOKI as the position's V4 balance.

The complete position was held across six blacklisted wallets. On February 13, 2022, those wallets held 134.605B $FLOKI across Ethereum and BSC, the same balance they still hold today.

134.605B − 130.482B = 4.123B $FLOKI

Using the complete balance with FLOKI's own Nottingham calculation leaves 4.123B $FLOKI, rather than the negative balance shown in the Support worksheet.

The 4.123B figure corrects only the balance FLOKI used in its own calculation. It does not resolve the broader question of how much the position was rightfully entitled to retain, which is addressed later.

What the calculation missed

As the More tokens, same share example showed, the reflection tokens were preserving the holder's position as the scale expanded. As the effective supply increased and the value represented by each raw FLOKI unit decreased, the holder needed more tokens simply to keep the same share and the same position value.

Nottingham then measured the holder against roughly the number of FLOKI originally purchased at earlier points on the expanding V1 scale and classified much of the larger balance that had accumulated as the scale continued to expand as “Excess Tokens.” Holders were required to surrender that amount before release from the blacklist.

Those tokens were not giving the holder more value. They were preventing the value loss caused by the expanding scale. Nottingham treated them as excess anyway.

How could deposits recorded at different points on the moving V1 scale be compared fairly?

The contract rate

The V1 contract itself provided the rate needed to compare deposits recorded at different points on the moving scale: currentRate. A wallet's displayed balance was its internal reflected balance divided by that rate, so currentRate tells us how many reflected units one displayed $FLOKI V1 represented at a given block.

During the migration, that rate was changing rapidly. Equivalent underlying positions could therefore appear as different token counts depending on when they deposited. The same rate that produced that moving display also lets us reverse it.

Technical view · Why currentRate reverses the displayed balance The contract accounting, rate movement and a numerical example.

V1 balance accounting

How the contract produced a displayed balance

System-wide conversion

_rTotal system-wide reflected units

_tTotal fixed 1T token accounting base

currentRate reflected units per displayed token

Wallet conversion

_rOwned[account] wallet's reflected units

currentRate conversion rate at that block

$FLOKI V1 displayed wallet balance

_getRate() starts from _rTotal and _tTotal and adjusts for excluded accounts before calculating the rate.

V1 did not store a wallet's balance directly as a number of $FLOKI V1 tokens. For each wallet, the contract stored an internal balance called _rOwned[account]. The code measures that balance in reflected units, which are simply the contract's internal bookkeeping units. Holders did not see this number in their wallets.

The contract also tracked a system-wide total of those reflected units, _rTotal, and a fixed token accounting total, _tTotal, set at 1 trillion $FLOKI V1. The contract's _getRate() function used those system-wide values to calculate currentRate.

currentRate answered a specific question: how many reflected units currently corresponded to one displayed $FLOKI V1 token?

The contract then used that rate to turn a wallet's stored internal balance into the token balance the holder actually saw:

displayed balance = _rOwned[account] ÷ currentRate

currentRate could change. When a taxed transfer generated a reflection fee, _reflectFee() reduced _rTotal. The fixed _tTotal value did not fall with it. As _rTotal fell relative to that fixed token accounting base, currentRate moved downward.

Because the displayed balance divided _rOwned by currentRate, a lower rate produced more displayed $FLOKI V1 from the same internal wallet balance.

Earlier 100 ÷ 100 = 1 $FLOKI V1 reflected units ÷ currentRate = displayed balance

After the rate falls 100 ÷ 50 = 2 $FLOKI V1 reflected units ÷ currentRate = displayed balance

The wallet's internal balance is still 100 in both examples. The displayed token balance doubles because the conversion rate has fallen.

The V1 bug accelerated this process, driving currentRate down unusually quickly while displayed balances expanded. During the migration, this mattered because a holder's deposit became fixed when they transferred it. A holder who waited longer before transferring continued accumulating reflections while currentRate fell, so their eventual deposit could contain substantially more displayed $FLOKI V1 even if the underlying position had not increased proportionally.

Putting the deposits on the same scale

A migration deposit was recorded in displayed $FLOKI V1. That means its token count depended on the currentRate at the moment the deposit arrived.

displayed balance = reflected units ÷ currentRate

We can reverse that operation. Because the contract obtained the displayed balance by dividing reflected units by currentRate, multiplying the displayed deposit by currentRate converts it back into the reflected units it represented:

claim = deposit × currentRate(deposit)

For each deposit, the calculation uses the currentRate in effect when that deposit executed. As currentRate continued falling, later deposits were being recorded on a different token scale from earlier ones. Multiplying each deposit by its own rate converts them back into the same internal unit.

Suppose one holder deposits while currentRate is 100. Their displayed balance is 1 $FLOKI V1, so multiplying that deposit by the rate gives 100 reflected units.

Another holder with the same underlying position waits until currentRate has fallen to 50. Their displayed balance has grown to 2 $FLOKI V1. Multiplying that larger deposit by the lower rate still gives 100 reflected units.

Earlier deposit

deposit: 1 $FLOKI V1
currentRate when it executed: 100
claim: 1 × 100 = 100 reflected units

Later deposit

deposit: 2 $FLOKI V1
currentRate when it executed: 50
claim: 2 × 50 = 100 reflected units

The recorded deposits are different, but both represent the same underlying amount.

That is the fair comparison the migration required: equivalent positions receive equal weight, regardless of when their deposits were recorded.

Once every deposit is expressed in the same internal unit, every on-time migrator is back on the same footing. Deposit timing can no longer increase or reduce the weight of the position.

The migration wallet was not exempt from V1 transfer fees. The deposit record uses the post-fee amounts recorded by the V1 Transfer events. Because the same transfer-fee schedule applied to migration deposits, that common haircut scales the claims together and cancels when each address is measured as a share of the cohort.

The timing-neutral share

Some qualifying addresses deposited only once. Others made several migration deposits before the deadline at different blocks, each with a different currentRate. Each on-time deposit is converted separately and the results are added together:

address claim = Σ (deposit × currentRate(deposit))

That produces the address's timing-neutral claim from the migration deposits received by the deadline. Each address's claim is then compared with the claims of every other on-time migrator:

cohort share = address claim ÷ Σ all on-time claims

Once every deposit is converted to the same reflected-unit scale, each address's claim can be measured against the claims of all 2,958 on-time migrators. That comparison gives each migrator its share of the cohort, which determines its share of the same 7.034T $FLOKI V2 the team actually distributed.

That gives us the baseline needed to separate genuine migration excess from the value that still belonged to the holders Nottingham blacklisted.

Verify · Stress-test the timing-neutral calculation Reference scale, transfer fees and a repaired-V1 replay.

The reconstruction starts with the migration as FLOKI described it: V1 would be migrated 1:1, with a proportional adjustment for the distortion that accumulated while deposits were arriving.

From there, the accounting is straightforward: identify the $FLOKI V2 actually distributed to the on-time migrators, put their migrated $FLOKI V1 positions on the same scale, remove the effect of deposit timing, and divide that fixed V2 pot proportionally.

The first check was the scale itself. The V1 position can be expressed at the migration-opening rate, at the deadline rate, or directly in the contract's reflected units. We recalculated the full cohort using common opening and deadline reference rates. Both produced exactly the same holder shares as the timing-neutral calculation. The maximum share difference was zero.

reference-scale verifier reference-scale results

The next check was the migration transfer fee. The deposit record contains the post-fee amount received by the migration wallet, so we reconstructed the gross amount sent for every qualifying deposit and compared three versions of the same position: the sender's gross reflected debit, the emitted post-fee amount, and the reflected amount credited to the migration wallet. All 3,761 qualifying deposits match the V1 fee formula, and the three measurements produce the same allocation apart from microscopic Solidity integer rounding.

migration-fee verifier transaction-level fee evidence historical fee-state data fee-basis results

The calculation also has to choose the rate for each deposit. Several V1 transfers could execute inside the same Ethereum block, and each fee-bearing transfer could move currentRate before the next one executed. We therefore replayed those blocks transfer by transfer and used the rate in effect when each deposit actually ran. Of 2,652 replayed blocks, 2,650 finish on the exact end state stored by the chain and the remaining two finish inside the proven rounding bound.

per-transfer rate data rate reconstruction verifier

The final check went back before the migration and asked whether the V1 history itself could simply be replayed with the reflection accounting repaired. We first reconstructed the actual history across 55,705 Transfer logs and validated it against the chain. Then we applied the natural code-level repair and replayed the same transactions. After only 15 transfers, a sender no longer had enough reflected units to make a transfer that actually occurred. From that point onward, a complete repaired history would require assumptions about transactions that never happened.

repaired-V1 verifier V1 transfer history historical contract state replay result full robustness record

The result does not depend on where the common scale is set, how the migration fee is measured, or an approximation of the rate. The same holder shares come out of the contract record.

The calculation inputs

Every input needed for the timing-neutral allocation is in the historical record: each migration deposit, the V1 rate when it executed, the on-time cohort, and the 7.034T $FLOKI V2 actually distributed. The records below let each part of the calculation be checked directly.

01 Deposit amount + block Migration deposit record ↗ 02 V1 rate at each deposit Recorded rate data ↗ 03 On-time cohort Deadline reconstruction ↗ 04 V2 distributed to cohort Seven-route payout reconstruction ↗

Inspect the migration inputs Deposit record and V1 rate at each deposit.

Migration deposit record

Every inbound $FLOKI V1 migration transfer, with sender, time, block, amount and transaction.

Open this record to load the migration transfers.

UTC	Sender	V1 deposited	Block	Status	Transaction

Download complete CSV

V1 rate at each deposit

The curve shows the currentRate at each migration deposit, putting deposits recorded at different points on the same internal scale.

Open this record to load the rate curve.

Block 12,769,455

UTC 5 Jul 2021 · 19:41

currentRate at block start Loading…

Scale across the block 10.3×

12,758,076migration opens 12,770,867deadline

For each of the 2,621 blocks where migration deposits landed, the same reflectionFromToken(1, false) call used in the verifier was read at the block before it, giving the rate when the block began, and at the block itself, giving the rate when it ended. Where several $FLOKI V1 transfers landed in one block, each fee-paying transfer lowered the rate for the ones after it. The calculation uses the rate at each deposit, reconstructed by replaying the block transfer by transfer; every replay ends on the state the chain reports for the end of that block. Any block's start and end can be checked independently with the full verifier.

Open the full contract verifier ↑ Rate at each block start Rate at each deposit

What happens when the same calculation is applied to all 2,958 on-time migrators?

The Timing-Neutral Allocation

The timing-neutral calculation puts all 2,958 on-time migrators on the same footing. It preserves the weight of each underlying position while removing the advantage or disadvantage created by deposit timing. The 7.034T $FLOKI V2 actually distributed to the cohort is the fixed pot. The calculation asks how that same distribution would have been divided if deposit timing had carried no weight.

That is the same timing problem FLOKI said Nottingham was meant to correct.

That is what timing-neutral means: deposit timing can neither help nor hurt a holder.

This is the baseline.

The 2021 V2 Distribution

Now each July 2021 payout can be checked against its timing-neutral allocation, address by address.

July 2021 · 2,958 on-time addresses

V2 Payout vs. Timing-Neutral Allocation

1.00 marks the timing-neutral allocation. Points below the line received less than that amount; points above it received more.

Below timing-neutral Above timing-neutral 1.00 = timing-neutral

Loading the migration comparison…

Earlier depositors generally received less of their timing-neutral allocation. July 4 depositors typically received about 62 percent; by July 6, the typical depositor was roughly made whole. Across the cohort, the brackets shifted value toward later migrators.

Across 2,958 on-time addresses

V2 allocated differently 1.199T

Below timing-neutral 2,591 addresses

Above timing-neutral 367 addresses

View the complete 2,958-address migration ledger Actual V2 received, timing-neutral allocation, difference and cohort share.

Loading 2,958 migration records…

Address	First deposit	V2 received	Timing-neutral	Difference	Cohort share

2,958 addresses · timing-neutral allocations sum to 7,033,850,777,434.76 V2 Download complete ledger

The 2022 Nottingham Review

Now let's check the 56 blacklisted positions against the timing-neutral allocation.

Why 56 blacklisted positions?

The January 30 Nottingham blacklist contained 106 addresses, but those addresses did not represent 106 independent positions. Fifteen were exchange infrastructure. Of the remaining 91 non-exchange addresses, 90 map to 56 migration positions. Some positions include more than one connected address or more than one migration address. The final non-exchange address belonged to a non-migrant holder whose balance FLOKI later returned.

In 38 of the 56 positions, a migration address was itself blacklisted. The other 18 are linked through token flows or other documented associations. One of those positions is linked through multi-hop FLOKI flow to the same migration root plus a combined treasury send that matches FLOKI's June claimant report to within 0.009 $FLOKI. These links support the accounting reconstruction; they are not proof of legal ownership.

2022 review · 56 blacklisted positions

Nottingham Review vs. Timing-Neutral Allocation

1.00 marks the timing-neutral allocation. Points below the line have a Nottingham formula amount below that allocation; points above it have a formula amount above it.

Below timing-neutral Above timing-neutral 1.00 = timing-neutral

Loading the Nottingham comparison…

When V2 was first distributed in 2021, the blacklisted positions were spread across both sides of the timing-neutral line. Taken together, they received 113.5% of their timing-neutral allocation. In aggregate, the group received slightly more than its rightful allocation.

The Nottingham calculation produced a much starker result. 53 of the 56 positions ended below timing-neutral, and together they were left with just 34.5% of their rightful allocation. The review turned a modest aggregate over-allocation into a severe shortfall across nearly the entire blacklisted group.

Aggregate comparison

Aggregate Share of Timing-Neutral Allocation

Each bar compares the group’s aggregate amount with its aggregate timing-neutral allocation.

Other 2,900 on-time migration addresses after V2 4.834T received / 5.097T timing-neutral

94.9%

56 blacklisted positions after V2 2.199T received / 1.937T timing-neutral

113.5%

56 blacklisted positions under Nottingham 669.202B formula amount / 1.937T timing-neutral

34.5%

Verify · How the Nottingham calculation was reconstructed How the formula was applied across the 56 blacklisted positions.

The calculation

The comparison applies FLOKI's Nottingham calculation to each of the 56 blacklisted positions. Where a position used more than one migration address, transfers between those addresses are treated as internal movements rather than new inflow. For the tracked position, FLOKI Support's recovered worksheet controls and records 44.100B $FLOKI. For the other 55 positions, the same calculation is reconstructed from the on-chain record.

Inflow and outflow

Support's worksheet uses two inputs: “Total V1 Buys/Inflow” and “Total V1 Sells/Outflow.” The reconstruction follows the same approach. V1 transferred into a position's migration addresses counts as inflow; V1 transferred out counts as outflow, except migration deposits and transfers between addresses belonging to the same position.

The cutoff

Every position is measured over the same period, from V1's launch through block 12,770,867, the last block before the published 01:00 UTC migration deadline. That cutoff can include V1 received after a position made its final migration deposit, as long as it arrived before the deadline.

For the tracked position, this method reproduces Support's recorded 43.881B $FLOKI V1 to within one token. If outflow is limited only to sales into the V1/WETH pair, the aggregate shortfall falls from 1.268T to 1.225T V2.

Gate wallet attribution audit 56-position accounting position summary FLOKI January 30 blacklist tab

How much did Nottingham take beyond the genuine excess?

The tracked position

The position began with two migration addresses, which together received 174.583B $FLOKI V2 in July 2021. Over the following six months, those tokens moved between addresses. By the Nottingham blacklist, the position was held across six wallets with $FLOKI V3 balances. All six were blacklisted and carried into V4.

The genuine overpayment

On the timing-neutral scale, the two migration addresses are measured on the same footing as every other on-time migrator. Their timing-neutral share of the fixed 7.034T pot is 102.759B $FLOKI V2.

That 102.759B is the position's rightful 2021 allocation.

174.583B actual V2 − 102.759B rightful allocation = 71.824B V2

FLOKI was right that this position received too much in the migration. The overpayment was 71.824B $FLOKI V2.

What Nottingham called excess

The Nottingham calculation recognized 44.100B $FLOKI from the position's V1 history. Against the 174.583B V2 migration payout, it classified the remainder as “Excess Tokens”:

174.583B − 44.100B = 130.482B $FLOKI

Nottingham classified 130.482B $FLOKI as excess. The genuine overpayment was 71.824B $FLOKI V2, meaning Nottingham overstated the excess by 58.658B.

What should have remained

On February 13, 2022, the six blacklisted wallets held 134.605B $FLOKI V4 across Ethereum and BSC.

134.605B V4 balance − 71.824B genuine overpayment = 62.781B V4

62.781B $FLOKI V4 belonged to the holder.

The other Nottingham positions

The same recount can be applied across the other Nottingham positions. They fall into two groups: value already sent to FLOKI, and value still locked in blacklisted wallets.

The value already sent to FLOKI

The treasury record contains 41 holder positions that sent $FLOKI V4 to FLOKI; two of them sent only dust.

For each position, the recount first calculates how much V4 FLOKI retained after crediting any V4 later sent back to the holder. It then subtracts the position's genuine 2021 excess.

Net V4 retained by FLOKI = V4 sent to FLOKI − V4 later sent back to the holder

V4 belonging to holder = net V4 retained by FLOKI − genuine 2021 excess

Across the 41 positions, the recount identifies 605.967B $FLOKI V4 of holder value retained by FLOKI.

Wallets	Migration	Share · V1	Buys − Sells · V1	Sent · V4	Returned · V4	2021 excess · V2	Belonged to holder · V4
Loading historical recount…

Each row is one holder position. V4 belonging to holder = V4 retained by FLOKI after credited returns − genuine 2021 excess. The V2→V3 and V3→V4 upgrades were 1:1, so that excess carries forward token-for-token.

41 holder positions Download historical recount Every transfer Purchase share Every purchase

Verify · The 605.967B belonging to holders Holder returns and position links behind the 605.967B figure.

How holder returns were checked

The recount credits every holder return identified through FLOKI's vesting report, direct and linked return routes, and the on-chain treasury history. A final closure scan compared every position where the recount found V4 belonging to the holder, including all 28 material positions, against 2,798 still-unattributed treasury outflows on Ethereum and BSC.

The scan surfaced six recipient groups for review. Shared recipients, burn transfers, relationships that began only after the treasury payment, and the remaining Position 04 cross-chain treasury pattern did not support another holder return. No additional treasury outflow could be attributed to a Nottingham holder position from the public chain record.

Every credited return is a verifiable treasury transfer, but some recipients are matched to holders by inference rather than direct claimant proof: the paired vesting series credited to two positions, and one return matched by a unique amount and date. If any of those inferred recipient matches did not belong to the holder, the historical figure would rise. Separately, about 42.045B $FLOKI V4 of later treasury transfers to Wintermute, FLOKI's market-making counterparty, remain unexplained. FLOKI's June 2022 report describes Wintermute as a route for returning tokens to holders, and its first 7.032B transfer is already credited. If any of the rest reached Nottingham holders, the historical figure would fall by that amount. A payment to a new wallet with no public link to a holder cannot be identified from chain data.

return-closure review

How positions were linked

Wallet-to-position links come from token flows and documented associations, not proof of ownership. Two positions outside the published 106, carrying 115.295B $FLOKI V4 together, are included because their February 13, 2022 sends match Nottingham's calculated excess to within 0.3%. One further position, carrying 13.708B $FLOKI V4, rests on a multi-hop token path and a match to FLOKI's claimant report. The ledger marks these conclusions as inferences and gives the evidence for every row.

The largest positive row in the historical recount traces to migration root 0xb4705f…641f. Before Nottingham, that root sent 367.737B $FLOKI V3 to 0x032f94…2892.

The same intermediary then sent 187.394B $FLOKI V3 to 0xc56644…f6bc and 187.394B $FLOKI V3 to 0xde5ad4…15e9. Those are the two wallets later blacklisted in this position.

The position assignment follows those V3 token paths from the migration root through the same intermediary to both Nottingham wallets. The exact transfers, blocks and transaction hashes are published below.

This position carries 269.120B $FLOKI V4, about 44% of the historical figure. Its link to the migration root runs through that one intermediary wallet.

position-link evidence

22 migration positions · 37 holder wallets

The balances still locked

The historical settlements are one part of the recount. Other holders still have rightful $FLOKI V4 trapped in blacklisted wallets.

As of September 26, 2026, the final blacklist remains active on Ethereum and BSC. It contains 79 addresses. Sixteen are exchange infrastructure, one belonged to a non-migrant holder whose full balance FLOKI later returned, and the remaining 62 trace back to 42 migration positions.

Thirty-seven holder addresses across 22 of those positions still hold at least 1 $FLOKI V4.

For each position, we first compare the $FLOKI V2 actually received in the 2021 migration with its timing-neutral V2 allocation. If the position received more, the difference is its genuine 2021 excess.

We then credit the $FLOKI V4 already recovered by FLOKI, after subtracting anything FLOKI later returned to the holder, against that excess. Any genuine excess still remaining is deducted from the V4 balance still restricted today. What remains is the holder's rightful balance.

Ethereum and BSC balances are added together. V4 was issued on both chains 1:1 against each wallet's V3 balance on that chain, so a token on either chain counts toward the same position.

Rightful balance = restricted V4 balance − genuine excess still remaining

Still restricted · holder balances of at least 1 $FLOKI V4

Blacklisted holder wallets 37

Migration positions 22

Restricted now 376.8B

Genuine excess remaining 100.2B

Rightful balance 276.6B

Wallets	Migration	Share · V1	Buys − Sells · V1	Timing-neutral	2021 excess	Excess credit	Restricted now	Rightful balance
Loading release calculation…

Each row is one migration position. Wallet balances are shown individually; timing-neutral allocation, 2021 excess and rightful balance are calculated once for the position.

37 blacklisted holder wallets · 22 migration positions Download balance calculation Download purchase share

Verify · Final blacklist scope and current state Address classification, position links, cross-chain balances and treasury flows.

Of the 79 addresses on the final blacklist, 16 are exchange infrastructure and one belonged to a non-migrant holder whose full balance FLOKI later returned. The remaining 62 trace back to 42 V1-to-V2 migration positions through documented associations and material token flows. The 37 holder addresses that still contain at least 1 $FLOKI V4 belong to 22 of those positions.

Across all 42 linked positions, the timing-neutral 2021 allocation totals 1.683T V2 and the Nottingham formula amount totals 576.685B V2. Of those 42 positions, 38 fall below their timing-neutral allocation by a combined 1.131T V2. Four are above it by 24.862B V2 and are kept separate rather than used to offset another holder's shortfall. These are 2021 accounting differences, not the amount of $FLOKI still frozen today.

Restricted balances and blacklist status are as of September 26, 2026 (Ethereum block 26,063,549; BSC block 124,192,358). BSC accounts for under 1% of the treasury flows; each BSC transfer used in the recount is verified on chain.

exchange-wallet classification audit final blacklist position summary final blacklist position ledger cross-chain treasury-flow audit treasury returns to holders verified current blacklist state

Together, the recount identifies 882.557B $FLOKI V4 that belonged to holders, not genuine excess.

The corrected accounting gives FLOKI a clear path to return what belonged to each affected holder.

FLOKI keeps the genuine excess. What belonged to holders goes back to them.

The balances still locked

The 276.589B $FLOKI V4 belonging to holders is still locked in blacklisted wallets and can be resolved immediately.

These tokens already exist in the affected wallets. The holders can send the restricted balances to whitelisted wallets controlled by FLOKI, and the rightful balances can be returned to clean replacement wallets.

The holder provides a clean replacement wallet.
The blacklisted wallet or wallets send their restricted $FLOKI V4 to a whitelisted wallet controlled by FLOKI.
FLOKI applies the timing-neutral recount to the position.
FLOKI retains any genuine excess still outstanding.
The holder's rightful balance is vested to the replacement wallet.

The value already sent to FLOKI

The historical positions are different. The recount identifies 605.967B $FLOKI V4 that belonged to those holders and was retained by FLOKI.

In 2022, FLOKI's DAO voted to allocate returned Nottingham “excess” to Valhalla and the FLOKI ecosystem.

FLOKI could dedicate a percentage of profits, revenues and fees from the ecosystem initiatives that received that allocation to making these holders whole over time. A holder-by-holder ledger can establish how much each holder is due, with payments continuing until that value has been restored.

The Choice

The record can be checked. The recount can be reproduced.

What was unclear in 2022 is clear now. The genuine excess is known. So is the value that belonged to holders.

882.557B $FLOKI remains unresolved: 605.967B was surrendered to FLOKI, while another 276.589B remains restricted in blacklisted wallets.

FLOKI’s dark chapter began with decisions made then; members of its community are still carrying the cost today.

How it ends depends on what FLOKI chooses to do now.

Netflix Night

NOTTINGHAM

Set the cutoff

Build the on-time cohort