NOTTINGHAM: FLOKI’s Dark History

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

PetaByte replies to a holder asking how the calculation works: if you had 1bn you will receive tokens on a 1:1 basis. — 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

The Crisis

By the time the migration opened on July 4, FLOKI was only 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 Promise

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.

The Adjustment

After the migration deadline, the team said the timing of each deposit had distorted the recorded $FLOKI V1 amounts. The migration had triggered a concentrated burst of taxed transfers as holders sent tokens to the migration wallet or sold. Once a holder transferred, that migration deposit was fixed. Holders who waited continued accumulating reflections before their own deposits were recorded. Two holders who began with equivalent positions could therefore arrive with very different deposit amounts depending on when they transferred.

The team addressed this by grouping deposits according to when they arrived and reducing the $FLOKI V2 distributed to later depositors, with reductions reaching as high as 50 percent. Their stated objective was to produce a fair proportional split.

Did the time-based reductions measure that difference correctly? First, we need to understand what the growing $FLOKI V1 balances represented.

What the balance 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.1 bn	7.1×
Internal position `_rOwned`	≈ 2.1 × 10⁷³ · never changes

From the opening of the migration to the deadline, the wallet's displayed balance grew from 1.0 billion to 7.1 billion $FLOKI V1. Its internal position never changed.

V1 contract ↗ verified source

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. Yet between the opening and the deadline, the balance shown in that wallet grew more than sevenfold.

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.

The bug accelerated this process far beyond the one-trillion value returned by totalSupply(). That function continued to return one trillion $FLOKI V1, while the effective V1 supply represented by holder balances was expanding 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 10 billion tokens while the effective V1 supply is 1 trillion. Their share is 10B ÷ 1T = 1%. If the reflection bug expands both tenfold, the holder has 100 billion out of 10 trillion, still 1%. The holder now has ten times as many tokens without gaining a larger share. If total market value were unchanged, their economic position would also be unchanged.

Those additional tokens are what keep the holder at 1% as the scale expands. If the system reaches 10 trillion but the holder is reduced back to their original 10 billion tokens, their share falls to 0.1%, a 90% reduction.

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.

Once a holder transferred, their recorded migration 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.5xblock 12769622
5 Jul 2021 · 20:18 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. 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 12769622 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

The V2 ownership scale

V2 contract · supply record

10 trillion $FLOKI V2 total supply

V2 contract ↗

Unlike the expanding V1 balance scale, V2 had a fixed total supply of 10 trillion $FLOKI V2. Every V2 balance could therefore be measured against the same fixed scale.

The migration still had a separate allocation problem: how to divide the portion of V2 distributed to migrators fairly among holders whose V1 deposits had been recorded at different points on the moving V1 scale.

That required separating 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 published schedule

The migration deadline passed at 01:00 UTC on July 6. Two days later, FLOKI published the schedule it had used to adjust the distribution. 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 their first migration deposit. Every one received $FLOKI V2. Across all seven distribution channels used by the team, those addresses received a combined 7.034T $FLOKI V2.

On-time migrators 2,958 addresses

$FLOKI V2 received 7.034T 7,033,850,777,434.76 exact

Distribution routes 7 team channels

On-time unpaid 0 addresses

Verify · Reconstruct the on-time cohort and payout Every deposit, payout route and address used to arrive at the 2,958-address cohort and 7.034T $FLOKI V2 total.

Methodology

How the cohort and payout were reconstructed

The two totals above come directly from $FLOKI V1 deposits and $FLOKI V2 distribution transfers. The steps below reproduce the boundary, the address set, every payout route, and the final reconciliation without relying on a workbook or a separate methodology page.

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. Once an address qualifies, its complete migration deposit record remains part of that address's cohort total.

Summing the complete deposit records of those qualifying addresses gives 10,932,248,681,372.946 $FLOKI V1. That includes 94,946,492,822.195 $FLOKI V1 in 72 follow-up transfers that landed after the deadline from addresses already in the cohort. This is an address-cohort transaction subtotal, not a supply figure or a timing-normalized claim. The live deposit table below still shows each individual transfer and whether that transfer itself landed before or after the cutoff.

03

Reconstruct every payout route

The $FLOKI V2 payout side 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 payout wallets and contracts. That process identified the seven payout 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. Today 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 and reproduces the 7,033,850,777,434.76 $FLOKI V2 distributed to them.

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

Route	Hub address	Matched transfers	Cohort recipients	$FLOKI 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 payouts 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 payments are added to that address.
05

Reconcile the result

Summing the matched $FLOKI V2 transfers produces 7,033,850,777,434.76 $FLOKI V2. The same match finds payouts for 2,958 of the 2,958 on-time addresses, leaving 0 unpaid.

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

Unique on-time addresses2,958

$FLOKI V1 deposited by cohort10.932T10,932,248,681,372.946

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

Addresses with payout2,958

On-time unpaid0

Inspect the records

The transactions behind the totals

The tables below are built in the page from the migration-wallet $FLOKI V1 transfers and the seven $FLOKI V2 distribution routes. Search, sort and switch views without leaving the record.

Search this view

Loading records…

Cohort shows one row per address whose first migration deposit landed by the deadline. $FLOKI V1 totals include that qualifying address's complete migration deposit record, including later follow-up deposits; $FLOKI V2 totals include every matched payment from the seven distribution routes.

That 7.034T $FLOKI V2 was the fixed amount the brackets had to divide among the 2,958 on-time migrators.

Did they divide it proportionally?

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, 43.881B $FLOKI V1 was acquired for $237,426. Measured against the effective V1 supply at each purchase, those buys represented 1.222671% in aggregate.

Purchases311 Jul–3 Jul 2021

$FLOKI V1 acquired43.881B43,880,929,960

Purchase consideration$237,426

Purchase-time share1.222671%sum of the 31 purchase shares

Purchase history · July 2021 · UTC

The 31 purchases

Each row values the ETH paid at the Uniswap ETH/USDC price at the start of that purchase's block, and measures the purchase against the effective V1 supply at the moment it executed. The total row shows the effective V1 supply and implied market cap across all 31 purchases.

UTC	$FLOKI V1 bought	USD spent	Effective V1 supply	Implied market cap	Share represented
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%

By the migration, the position was held across 0xc1563bdf…6913d and 0x13422803…4f36. Both made their first migration deposits at 00:59:53 UTC on July 6, just seven seconds before the deadline. Together, those two deadline-qualifying transfers totaled 391.582B $FLOKI V1. They later received 174.583B $FLOKI V2 in the July distribution.

Migration record · July 6, 2021

The two addresses

Address	First deposit time	$FLOKI V1 by deadline	Full $FLOKI V1 record	$FLOKI 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

The two first deposits landed in the final ten minutes before the deadline, placing them in FLOKI's published 50% timing bracket. Together, 391.582B $FLOKI V1 had been recorded by the cutoff. Against the 174.583B $FLOKI V2 July distribution, that is 44.584%.

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.

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

A seamless upgrade

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 Nottingham instructions were simple: no action was required. FLOKI described the process as “completely seamless.”

The V3-to-V4 upgrade began with a snapshot on January 22, 2022 at 08:00 UTC. After it was completed, FLOKI said every holder had received new V4 tokens 1:1 based on the V3 balance held when the upgrade began.

completion announcement ↗

The Nottingham upgrade also introduced a blacklist. During the V4 distribution, FLOKI began restricting selected addresses from transferring their tokens.

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

Who was blacklisted

FLOKI explains its wage-based threshold and says wallets receiving more than 7.21 billion tokens in the V1-to-V2 migration were blacklisted. — A lower balance six months later would not, by itself, place the wallet below this historical threshold.
source

The blacklist focused on the largest V2 migration recipients, which FLOKI identified as posing the greatest risk to the liquidity pool if they sold. Reviewing thousands of smaller affected wallets was considered impractical.

In its January 25 explanation of the Nottingham upgrade, FLOKI said it had used how much $FLOKI V2 each wallet received during the V1-to-V2 migration to identify those holders.

FLOKI used $43,342.29, which it identified as the 2019 average annual wage across OECD countries, and divided that figure by $FLOKI V2's opening price. That produced a threshold of 7.211B $FLOKI V2. FLOKI said wallets receiving more than that amount during the V1-to-V2 migration were selected for the blacklist. The Nottingham blacklist also includes other wallets connected to those migration positions after tokens had been moved between addresses.

Both migration addresses in the tracked position exceeded that threshold.

At that stage, FLOKI described the blacklist as temporary, said inclusion was not an “indictment of crime,” and said cases would be reviewed individually.

How the published list and blacklist changed over time. The public review tabs and the restrictions on-chain followed different timelines.

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, the 106-address handlers went live, first on BSC at 12:19 UTC and then on Ethereum at 18:15 UTC. The active restriction narrowed from 242 addresses to 106.

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 ↗

A second look at the migration

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

Three days after the V4 snapshot, FLOKI said an audit of the V1-to-V2 distribution had found that the earlier timing formula “wasn’t enough to account for the inflation” during the migration. The July 2021 distribution was reopened for review.

The review would determine the conditions for release from the blacklist.

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 ↗

The question now was what FLOKI would require before a blacklisted wallet could be released. Over the next five months, DAO votes set the terms: what had to be returned, what could remain, how it would be vested, and when the review would close.

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 cases related to the inflation bug 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.”

How did the review calculate that number?

A second calculation

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.”

Under Nottingham, FLOKI did not use the July timing brackets again. Blacklisted holders received a new calculation from FLOKI Support based on their V1 transaction histories. 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)

In the accompanying calculation, 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 itself credited 0.5% of V1 Net Transactions as “V1 Reflections,” so the calculations below follow the worksheet arithmetic rather than the formula as written in the email.

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.

What the review calculation produced

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.”

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.

The position began with 43.881B $FLOKI V1 bought across 31 purchases, each against the effective V1 supply at the time. As the reflection scale expanded, holder balances expanded with it, preserving their relative positions. By the migration, the original purchase count no longer represented the same share. Nottingham recognized 44.10B $FLOKI, almost exactly the raw number originally purchased.

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. Determining whether it was the correct share requires returning to the problem the migration was trying to solve.

The review worked backward from V1 purchases minus V1 sales to determine how many tokens the holder should retain. The migration problem was different: how to compare deposits recorded at different times on a rapidly changing V1 scale.

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

The contract rate

The V1 contract itself provided a way to make that comparison: 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.

From deposits to cohort share

Some qualifying addresses deposited only once. Others made several migration deposits at different blocks, each with a different currentRate. Cohort eligibility is fixed by the address's first deposit; once the address qualifies, each deposit in its complete migration record is converted separately and the results are added together:

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

That produces the qualifying address's total timing-neutral claim across its complete migration deposit record.

Each address's claim is then compared with the claims of every other on-time migrator:

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

The result is the address's timing-neutral share of the 2,958 on-time migrators as a group.

That share is applied to the same 7.034T $FLOKI V2 the team actually distributed to the cohort. Each timing-neutral allocation represents the holder's share of that fixed pot after deposit timing is removed from the calculation.

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.

Calculation inputs

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

View the 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	$FLOKI V1 deposited	Block	Status	Transaction

Download complete CSV ↗

Inspect the V1 rate data Scrub through the recorded rate used to put migration deposits on the same internal scale.

Recorded normalization rate

`currentRate` across the migration

The curve shows the rate at the start of each block where a migration deposit landed, as a percentage of the rate at migration opening. The scrubber snaps to those blocks.

Show late deposits through 13 Jul

Open this record to load the rate curve.

Block 12,769,622

UTC 5 Jul 2021 · 20:18

currentRate at block start Loading…

Scale across the block 10.5×

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. Together, those allocations add up to the same 7.034T $FLOKI V2 that was actually distributed to the cohort.

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

This is the baseline.

View the complete 2,958-address timing-neutral ledger Search, sort, inspect exact allocations, or download the full CSV.

Loading 2,958 timing-neutral allocations…

Address	First deposit	Timing-neutral V2	Share of 7.034T

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

The 2021 V2 Distribution

Now the July 2021 payouts can be checked against the fixed scale, 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.195T V2

Below timing-neutral 2,593 addresses

Above timing-neutral 365 addresses

The 2022 Nottingham Review

Six months later, Nottingham went back to the same migration and recalculated the blacklisted positions from their V1 transaction histories.

How did the Nottingham calculation compare with the timing-neutral allocation?

2022 review · 55 reconstructed holder/case 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…

Aggregate comparison

Aggregate Share of Timing-Neutral Allocation

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

Other 2,901 on-time migration addresses after V2 4.853T received / 5.118T timing-neutral

94.8%

55 reconstructed blacklist cases after V2 2.181T received / 1.916T timing-neutral

113.9%

55 reconstructed blacklist cases under Nottingham 636.803B formula amount / 1.916T timing-neutral

33.2%

The 55 reconstructed cases have a combined timing-neutral allocation of 1.916T V2. They received 2.181T V2 in the 2021 distribution, 265.438B V2 above their combined timing-neutral allocation. Applying the reconstructed Nottingham formula produces 636.803B V2, placing the same 55 cases 1.279T V2 below their combined timing-neutral allocation.

The shift was broad across the case population. In the 2021 distribution, 32 of the 55 cases fell below their timing-neutral allocation and 23 were above it. Under the reconstructed Nottingham formula, 52 of the 55 fell below.

Across 55 reconstructed holder/case positions

Timing-neutral allocation 1.916T V2

Reconstructed Nottingham formula 636.803B V2

Net difference 1.279T V2

Verify · settled blacklist and reconstructed cases Why the 106-address blacklist resolves into fewer historical migration positions and holder/case groups.

Fifteen of the settled 106 are exchange infrastructure. Of the remaining 91 non-exchange addresses, 88 map to the 55 reconstructed migration cases above. One was a non-migrant holder whose balance FLOKI later returned; two older addresses remain unresolved, and neither survives into the final 79.

The aggregate uses the documented Nottingham formula at holder/case level. Transfers between migration roots inside the same accepted case are excluded so moving V1 between a holder's own roots does not create fresh inflow. For the featured documented case, the recovered Support calculation controls and records 44.100B $FLOKI. The comparison is therefore a formula reconstruction, not a claim that 55 individual Support worksheets have been recovered.

Support's worksheet lists “Total V1 Buys/Inflow” and “Total V1 Sells/Outflow.” The reconstruction follows those rows: every $FLOKI V1 transfer into a case's migration addresses counts as inflow, and every transfer out counts as outflow, except migration deposits and transfers between the case's own migration addresses. The V1 history runs through each case's last migration deposit. For the documented case, these rules reproduce Support's recorded 43,880,929,960.06 $FLOKI V1 to within one token. Other readings change the result for only a few cases: counting only sales into the V1/WETH trading pair as outflow gives a 1.211T difference, and also counting four V1 transfers made after the migration closed gives 1.262T.

Gate wallet attribution audit ↗ 55-case reconciliation ↗ case-level summary ↗ FLOKI January 30 blacklist tab ↗

The Balances Still Restricted

The final blacklist is still active on Ethereum and BSC today. It contains 79 addresses. 16 are exchange infrastructure. Of the remaining 63 non-exchange addresses, 62 trace back to 42 reconstructed migration positions. The last belonged to a non-migrant holder whose full balance FLOKI later returned.

Still blacklisted · linked positions below the timing-neutral ledger 1.157T $FLOKI V2

Compared with the timing-neutral ledger, 38 holder/case positions below that allocation have a combined 1.157T V2 shortfall under the reconstructed Nottingham formula. Four other positions are above the timing-neutral allocation by 23.669B V2; they are kept separate rather than used to offset another holder/case's shortfall.

Today, 37 holder addresses still hold a restricted balance totaling 376.836B $FLOKI across Ethereum and BSC.

Migration position	Linked wallets	Timing-neutral V2	Nottingham formula	Timing-neutral − formula	Restricted now	Net to treasury

Each row is one reconstructed final-blacklist migration position. Exchange infrastructure and the classified non-migrant holder are outside the position-level calculation.

42 reconstructed migration positions linked to the final blacklist Download service-clean final case model ↗

Verify · current blacklist state Cross-chain blacklist state, reconstructed migration positions, balances and treasury transfers.

All 79 final-blacklist addresses are now classified. Across the 42 linked holder/case positions, the timing-neutral 2021 allocation totals 1.679T V2 and the reconstructed Nottingham formula amount is 546.049B V2. The reconstruction links 62 non-exchange addresses back to original V1-to-V2 migration positions using documented associations and material token flows. The 16 exchange addresses and the one classified non-migrant holder remain outside the migration-position calculation.

exchange-wallet classification audit ↗ service-clean final case summary ↗ service-clean case reconciliation ↗ cross-chain treasury-flow audit ↗ treasury returns to holders ↗ verified current state ↗

What did the two corrections do to the position we have followed since the migration?

The same 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.

Two migration addresses → six blacklisted wallets → one position to recount

The corrected 2021 allocation

On the fixed 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 103.867B $FLOKI V2.

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

174.583B actual V2 − 103.867B rightful allocation = 70.715B V2

FLOKI was right that this position received too much in the migration. The overpayment was 70.715B $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 59.767B $FLOKI more as excess than the genuine 70.715B overpayment.

What should have remained

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

134.605B balance − 70.715B genuine overpayment = 63.890B $FLOKI

63.890B $FLOKI should have been returned to the holder.

The balances still locked

Thirty-seven holder addresses on the final blacklist still hold at least 1 $FLOKI. Every one is linked to one of 22 reconstructed migration positions.

For each position, any 2021 payout above its timing-neutral allocation is the genuine overpayment. Tokens its blacklisted wallets sent to whitelisted wallets controlled by FLOKI count toward that excess, less anything FLOKI later sent back to the holder, up to the amount of the overpayment. Any genuine excess still outstanding is held back from the balance that remains restricted. What remains is the holder's rightful balance.

Rightful balance = restricted balance − genuine excess still remaining

Still restricted · holder balances of at least 1 $FLOKI

Blacklisted holder wallets 37 at least 1 $FLOKI restricted

Reconstructed positions 22

Restricted now 376.8B

Genuine excess remaining 99.5B

Rightful balance 277.3B

Blacklisted wallets	Migration position	Timing-neutral V2	2021 excess	Credited against excess	Restricted now	Rightful balance
Loading release calculation…

Each row is one reconstructed migration position. Wallet balances are shown individually; timing-neutral allocation, 2021 excess and rightful balance are calculated once for the position. This table covers balances still held in blacklisted wallets today; legitimate holder tokens already transferred to FLOKI's treasury are outside this calculation.

37 blacklisted holder wallets · 22 reconstructed positions Download balance calculation ↗

Across the 22 positions, the rightful balances still locked total 277.302B $FLOKI.

The blacklist is permanent. How can those tokens be returned?

FLOKI should reopen the Nottingham review for the holders who remain blacklisted.

Blacklisted holders can still send $FLOKI to whitelisted wallets controlled by FLOKI. That gives the remaining review cases a practical route: FLOKI can keep the genuine excess and vest the holder's rightful balance to a clean replacement wallet through the same review process established in 2022.

What should be returned

The timing-neutral allocation sets the line between genuine excess and rightful holder balance by giving every on-time migrator the same proportional treatment, regardless of deposit timing.

Across the 22 positions with at least 1 $FLOKI still restricted, 376.836B $FLOKI is still locked. The recount identifies 99.534B as genuine excess and 277.302B as rightful holder balances.

The 2022 votes already set the treatment for both amounts. The holder's balance would be vested to a new, unrestricted wallet. Returned excess was allocated by DAO vote to the FLOKI ecosystem.

Reopen the review

The holder provides a clean replacement wallet.
The blacklisted wallet or wallets send their restricted $FLOKI to a whitelisted wallet controlled by FLOKI.
FLOKI recounts the position using the timing-neutral calculation.
The holder's rightful balance is vested to the replacement wallet.
FLOKI keeps the genuine excess for the FLOKI ecosystem, as approved by the DAO.

That recount has already been completed for all 22 positions with at least 1 $FLOKI still restricted.

Verify the numbers

Every calculation, case link and source file behind these numbers is public.

FLOKI can compare the 22 positions with its own review records and correct any case where a migration link, transfer or earlier return changes the numbers.

The Nottingham review closed on September 12, 2022. The remaining 22 positions can still be settled under the corrected migration accounting.

277.302B $FLOKI remains in blacklisted wallets as rightful holder balances.

Until these balances are returned, Nottingham remains an unfinished dark chapter in FLOKI's history.

NOTTINGHAM

The Crisis

The Promise

The Adjustment

Set the cutoff

Build the on-time cohort

Reconstruct every payout route

Match payouts to the cohort

Reconcile the result