Chapter 01
The Crossing
A bug in the original $FLOKI contract led to an emergency migration.
The Crisis
In July 2021, FLOKI was running on its original token contract, the V1 contract. A bug in its reflection accounting had broken the relationship between the value returned by totalSupply() and its holder balances. That function still returned one trillion $FLOKI V1, while the balances across holder wallets were collectively growing far beyond one trillion.
A new team organized a migration to a replacement contract, the V2 contract. Holders who wanted to migrate were instructed to send their $FLOKI V1 to a designated migration wallet. After the migration period ended, the team would distribute the new $FLOKI V2 tokens.
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 determined that distributing $FLOKI V2 directly from the recorded $FLOKI V1 deposit amounts would not produce a fair result. The migration itself had triggered a concentrated burst of taxed $FLOKI V1 transactions as holders transferred to the migration wallet or sold. Once a holder transferred, their recorded migration deposit was fixed, while holders who had not yet transferred continued accumulating reflections before their own deposits were recorded. Two holders who began with equivalent positions could therefore have very different deposit amounts simply because one transferred later.
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.
Chapter 02
The Moving Scale
More tokens did not necessarily mean a larger position.
What the balance represented
| 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× |
| Last depositJuly 13 | 15.2 bn | 15.2× |
Internal position _rOwned |
≈ 2.1 × 1073 · never changes | |
The holder's share of the pool never changed. Only the reflection rate fell, so the same position converted into about 15 times as many tokens in nine days.
The V1 contract did not store holder balances as a simple fixed number of tokens. Instead, it stored an internal reflected amount for each holder (_rOwned). Think of this as the holder's underlying position inside the reflection system. The number of $FLOKI V1 shown in the wallet was calculated from that internal amount rather than stored directly.
Whenever a balance was read, balanceOf() converted that reflected amount into $FLOKI V1 by dividing it by the current reflection rate (currentRate, calculated by _getRate()). As that rate fell, the same internal position converted into a larger token balance. An untouched holder could therefore see their $FLOKI V1 balance increase without receiving a transfer.
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 1021tTransferAmount = tAmount - tFee - tTeam_getRValues()line 1028rTransferAmount = rAmount - rFee_takeTeam()line 998rTeam = tTeam × currentRate_rOwned[address(this)] += rTeam_reflectFee()line 1006_rTotal -= rFee_getRate()line 1035currentRate = rSupply / tSupplytokenFromReflection()line 801require(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.
More tokens, same share
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
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
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.
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.
The V2 ownership scale
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.
Chapter 03
The Brackets
The team answered the timing problem with a schedule of percentage reductions.
The published schedule
For the timing adjustment, the team assigned each deposit a payout percentage according to how long before the July 6, 2021 at 01:00 UTC 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.
The published bracket percentage was not the only reduction. FLOKI said the final distribution also reflected 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
The brackets used time before the deadline as the correction variable. 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
The published deadline gives the analysis a clear boundary. 2,958 addresses made their first migration deposit by July 6, 2021 at 01:00 UTC. Every one of those on-time migrators received $FLOKI V2. Across all seven distribution channels used by the team, those addresses received a combined 7.034T $FLOKI V2.
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
Transferinto 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
-
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
Transferhistory 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… … … -
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.
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.
Loading records…
Scroll for more
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.
The V2 payments reconstructed above establish the historical total distributed to the on-time cohort. That gives the proportionality test a fixed amount: the $FLOKI V2 actually distributed to those 2,958 migrators. The brackets were intended to divide that amount proportionally.
That proportionality can be tested against the deposits and payouts the migration actually produced.
Chapter 04
The Example
One position, held across two addresses.
We will use one position, held across two addresses, as a worked example throughout the rest of the analysis. 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.
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% |
- Purchase block
- Block mined
- Rate at deployment
- Rate at start of block
- Rate when the purchase executed
- Rate at end of block
By the migration, the position was held across 0xc1563bdf…6913d and 0x13422803…4f36. Both addresses made their first deposit at 00:59:53 UTC on July 6, 2021, seven seconds before the deadline. 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. The historical deadline comparison therefore uses the 391.582B $FLOKI V1 recorded by the cutoff. Against the 174.583B $FLOKI V2 July distribution, that is 44.584%. The timing-neutral calculation later uses the complete 397.545B migration record because cohort eligibility is determined by each address's first deposit.
Six months later, this same position would be pulled into a new review.
Chapter 05
Nottingham
The July 2021 migration distribution was reopened for review.
A seamless upgrade
On January 17, 2022, FLOKI announced another contract upgrade as part of its transition toward DAO governance. This was a later successor upgrade, separate from the July 2021 V1-to-V2 migration. Between those events, FLOKI had already replaced V2 with V3 on August 8, 2021. That transition was automatic: V2 holders received V3 1:1 based on their V2 balances.
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.
The upgrade also introduced a blacklist. Selected addresses received the same token count in V4 but were restricted while the team reviewed an earlier event: the July 2021 V1-to-V2 migration.
- V1 → V2
Migration distribution
- V2 → V3
Automatic 1:1 successor upgrade
- V3 → V4
Nottingham snapshot · 1:1
The July 2021 distribution is reopened
In January 2022, FLOKI said a recent audit of the V1-to-V2 distribution found that the earlier timing formula “wasn’t enough to account for the inflation” that occurred during the migration. The July 2021 distribution was therefore reopened.
Balances that had already been distributed in 2021 became the subject of a new review during Nottingham. The review looked back to the historical V1-to-V2 migration record to determine which recipients would be examined again.
Who entered the review
In its January 25 post explaining the Nottingham upgrade, FLOKI said the review would use how much $FLOKI V2 each wallet received during the V1-to-V2 migration to identify the largest migration recipients.
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 addresses in the example position exceeded that threshold.
FLOKI said it focused the review on the largest recipients because sales from those wallets could do the most damage to the liquidity pool. It also said reviewing thousands of smaller affected wallets was impractical.
At that stage, FLOKI described the blacklist as temporary, said inclusion was not an “indictment of crime,” and said cases would be reviewed individually.
Those reviews would determine the conditions for release from the blacklist.
How the review narrowed from 207 to 106, then became the final 79. The public review tabs, blacklist submission and later active restriction sets record successive stages of the same review.
FLOKI's public review sheet 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.
The January 29 sheet contains the same 108 addresses submitted that day in the Ethereum addToBlacklist transaction. The January 30 sheet contains the same 106 addresses that became the first active blacklist on both Ethereum and BSC.
Addresses were then released during the mutable phase. 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 present in the January 29 list of 108 but removed from the January 30 list of 106. The April 4 final handlers preserved that same 79-address set, which remains the active set on both chains today.
The review history is therefore: 207 → 157 → 108 → 106 settled and active on both chains → releases to 64 ETH / 65 BSC → identical 79-address replacement and final sets.
Chapter 06
The Terms
Return the “excess,” vest the remainder, and do it before the deadline.
February 9–11, 2022
Return before release
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
A second proposal addressed what would happen after a holder returned the amount classified as “excess.” The committee 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
In March, another DAO proposal asked whether the blacklist function should be renounced. The proposal passed and the renunciation was subsequently carried out. FLOKI presented the change as a step toward decentralization and as reassurance that future holders could not be blacklisted.
For addresses that remained on the blacklist when the blacklist-management function was renounced, the consequence was different: they could no longer be removed from it.
FLOKI kept the project multisig permanently whitelisted, allowing blacklisted holders to use it throughout the review process to return tokens and have the approved remainder vested to a different, unrestricted wallet.
July 18–20, 2022
A deadline for the review
A further proposal asked to close the review process. FLOKI said five months had provided sufficient time and that 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
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.
Together, those decisions established what would happen once the review classified tokens as “excess”. They did not explain how that classification was calculated.
How did the review calculate that “excess”?
Chapter 07
The Formula
How the 2022 review calculated the amount it called “excess.”
A second calculation
In July 2021, FLOKI reduced migration payouts according to timing brackets after V1 balance inflation accelerated during the final hours before the deadline. When blacklisted balances were reviewed again in 2022, the review used a different basis: the holder’s V1 transaction history rather than the recorded migration deposit and its timing.
FLOKI Support sent blacklisted holders calculations determining how much of their balance could remain. The email stated 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 accompanying calculation did not apply the 0.5% in the order shown by the written expression. Its arithmetic first added 0.5% of V1 Net Transactions as “V1 Reflections”. It then subtracted that recognized amount from the V2 airdrop to calculate “Excess Tokens,” and finally subtracted those excess tokens from the holder’s V4 balance.
The 0.5% labeled “V1 Reflections” was not based on the holder’s actual accumulated reflections, holding period, or the V1 contract’s reflection rate. It was a fixed percentage of net V1 transactions, and the review materials do not explain why 0.5% was chosen.
What the review calculation produced
Applied to the example 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. Subtracting the classified excess produced a −5.977B $FLOKI final balance. In other words, the calculation classified more tokens as excess than the V4 balance then contained.
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.
The review therefore recognized 44.10B, or 0.6270% of the 7.034T $FLOKI V2 distributed to on-time migrators:
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.
Was there a quantity inside the V1 contract that allowed those migration deposits to be compared directly?
Chapter 08
The Method
Putting every migration deposit on the same scale.
The contract rate
There was. V1's reflection accounting tracked a value called 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.
How the contract produced a displayed balance
_rTotal
system-wide reflected units
_tTotal
fixed 1T token accounting base
currentRate
reflected units per displayed token
_rOwned[account]
wallet's reflected units
currentRate
conversion rate at that block
_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.
100 ÷ 100 = 1 $FLOKI V1
reflected units ÷ currentRate = displayed balance
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.
The relationship established above was:
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.
Using the same example from above, 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.
- deposit
1 $FLOKI V1- currentRate when it executed
100- claim
1 × 100 = 100 reflected units
- 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.
Once every deposit is expressed in the same internal unit, they can be compared directly.
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.
The next step is to compare that claim 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 can then be applied to the 7.034T $FLOKI V2 distributed to the cohort, preserving each address's relative position after the timing distortion is removed.
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.
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 |
|---|
Inspect the V1 rate data Scrub through the recorded rate used to put migration deposits on the same internal scale.
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.
Open this record to load the rate curve.
currentRate at block start
Loading…
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.
What happens when the same calculation is applied to all 2,958 on-time migrators?
Chapter 09
The Result
This is the allocation the migration should have produced.
The Timing-Neutral Allocation
The timing-neutral calculation gives one $FLOKI V2 allocation for every on-time migration address, independent of when during the migration window it was deposited. Together, those allocations add up to the same 7.034T $FLOKI V2 that was actually distributed to the cohort.
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 |
|---|
The 2021 V2 Distribution
With the timing-neutral allocation established, the July 2021 distribution can be tested directly. The chart compares what each on-time migrator actually received with what that same position should have received. The toggle isolates the same 55 reconstructed blacklist cases examined later under Nottingham.
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.
Loading the migration comparison…
The pattern is simple: the earlier a holder deposited, the smaller the share of its timing-neutral allocation it received. July 4 holders typically received about 62 percent of their timing-neutral allocation, while holders depositing by July 6 were roughly made whole.
In practice, the brackets shifted value toward later migrators. Earlier deposits were under-allocated, while later deposits increasingly reached or exceeded their timing-neutral share.
Across 2,958 on-time addresses
The 2022 Nottingham Review
The Nottingham review revisited the same migration with a different method. The calculation did not use the migration deposit and its contemporaneous contract rate. It went back to V1 transaction history, treated net V1 transactions as the starting position, and added a fixed 0.5% allowance it called “V1 Reflections.”
That gives us a direct test. For the blacklisted cases we can reconstruct, we can compare the reconstructed Nottingham formula amount with their timing-neutral allocation. Did Nottingham correct the 2021 distortion, or push those positions even further away from the right allocation?
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.
Loading the Nottingham comparison…
Aggregate Share of Timing-Neutral Allocation
Each bar compares the group’s aggregate amount with its aggregate timing-neutral allocation.
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
Verify · settled blacklist and reconstructed cases Why the 106-address blacklist resolves into fewer historical migration positions and holder/case groups.
FLOKI later identified 11 addresses in the settled 106 as Gate exchange wallets that had been left in the blacklist. Those addresses remain part of the historical blacklist count, but they are excluded as holder wallets. The comparison above uses 55 cases with independent non-Gate support; seven non-Gate addresses remain unresolved rather than being assigned by inference.
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.
The Balances Still Restricted
The blacklist did not end with the 2022 review. It remains active on Ethereum and BSC today. Its final 79-address set includes 12 Gate exchange wallets later identified by FLOKI. Excluding those service wallets leaves 67 addresses for holder accounting; 62 can be reconstructed into 42 holder/case positions, while five remain unresolved.
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 of those 67 addresses still hold a restricted balance totaling 376.836B $FLOKI across Ethereum and BSC.
That shortfall is separate from what remains restricted today. 376.836B $FLOKI remains in blacklisted holder wallets, while those same final addresses also transferred 1.015T $FLOKI net to the whitelisted treasury addresses. The table below keeps the shortfall, current restricted balance, and treasury flow separate.
| Migration position | Linked wallets | Timing-neutral V2 | Nottingham formula | Timing-neutral − formula | Restricted now | Net to treasury |
|---|
Each row is one reconstructed final-blacklist holder/case position. The five unresolved non-Gate final addresses remain outside the position-level calculation rather than being assigned by inference.
Verify · current blacklist state Cross-chain blacklist state, reconstructed migration positions, balances and treasury transfers.
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 reads the final blacklist state and balances on both Ethereum and BSC, then links later blacklisted wallets back to the original V1-to-V2 migration addresses using documented associations and material token flows. Addresses without sufficient evidence for a specific migration link are left unresolved rather than assigned by inference.
The timing-neutral ledger does not require preserving a 2021 overpayment. It identifies the amount each position actually supports, then lets the two historical corrections be measured against that same answer.
What does the full recount look like when every stage can be reconstructed for the same position?
Chapter 10
The Recount
One position, from the July 2021 migration through the Nottingham review.
The same position
The example position began with two migration addresses. Together, they received 174.583B $FLOKI V2 in July 2021.
Over the following months, those tokens moved. By the Nottingham blacklist, the position was held across six wallets with $FLOKI V3 balances. All six were blacklisted and carried into V4.
The migration calculation therefore begins with the two addresses that received the July distribution. For Nottingham, the recount follows the six wallets holding that position when the review took place.
Two migration addresses → six blacklisted wallets → one position to recount
The corrected 2021 allocation
The two migration addresses received 174.583B $FLOKI V2. Applying the timing-neutral method to their complete migration record gives a corrected allocation of 103.867B $FLOKI V2.
174.583B actual V2 − 103.867B timing-neutral V2 = 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
The timing-neutral calculation puts the genuine 2021 overpayment at 70.715B $FLOKI.
Nottingham classified 59.767B $FLOKI more as excess than the corrected migration accounting supports.
What should have remained
On February 13, the six blacklisted wallets held 134.605B $FLOKI across Ethereum and BSC. The corrected migration accounting identifies 70.715B of that position as the genuine 2021 overpayment.
134.605B balance − 70.715B genuine overpayment = 63.890B $FLOKI
63.890B $FLOKI should have remained transferable.
The balances still locked
The same recount can be applied to the holder balances still trapped in the final blacklist. All 37 non-Gate holder addresses with at least 1 $FLOKI still restricted are linked to 22 reconstructed migration positions. None of the five unresolved non-Gate final addresses holds 1 $FLOKI or more.
For each position, the 2021 payout is compared with its timing-neutral allocation. Any amount above that allocation is the genuine 2021 overpayment. Net transfers already made from the linked blacklisted wallets to the designated blacklist receiver are credited against that overpayment, up to the amount of the overpayment. Only the corrected excess still unsatisfied is left against the balance that remains restricted.
Release supported = restricted balance − corrected excess still remaining
Still restricted · holder balances of at least 1 $FLOKI
| Blacklisted wallets | Migration position | Timing-neutral V2 | 2021 excess | Credited against excess | Restricted now | Release supported |
|---|---|---|---|---|---|---|
| Loading release calculation… | ||||||
Each row is one reconstructed migration position. Wallet balances are shown individually; timing-neutral allocation, 2021 excess and release are calculated once for the position.
The table answers what can be released from balances that are still restricted today. It does not add back legitimate holder tokens that may already have been transferred to the treasury.
277.302B $FLOKI of the holder balance still locked today should be released.
The blacklist is permanent. How can those tokens be returned?
Chapter 11
The Remedy
There is one chapter left to close.
FLOKI should reopen the Nottingham review for the holders who remain blacklisted.
The mechanism is already there. Blacklisted holders can still send $FLOKI to whitelisted wallets controlled by FLOKI. FLOKI can separate the corrected excess from the holder's rightful balance, then return that balance to a clean replacement wallet through the same review process established in 2022.
What should be returned
The recount in the previous chapter identifies 376.836B $FLOKI still restricted across 37 materially funded holder wallets representing 22 reconstructed positions.
Of that balance, 99.534B $FLOKI remains attributable to genuine 2021 overpayment under the timing-neutral calculation.
376.836B − 99.534B = 277.302B $FLOKI
That leaves 277.302B $FLOKI in rightful holder balances.
The original DAO process already established what would happen to both sides of that split. The holder's remaining balance would be vested to a new, unrestricted wallet. The tokens returned as excess were later 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 reconciles the position against the timing-neutral calculation.
- The holder's rightful balance is vested to the replacement wallet.
- The genuine excess remains with FLOKI and is handled under the destination approved by the DAO.
The same calculation has already been performed for every materially funded holder position still represented in the blacklist.
Verify the numbers
The calculations, case links and source data used here are public.
FLOKI can compare the 22 reconstructed positions with its own review records and identify any migration link, historical transfer or prior return that changes a case. Any documented correction can be applied directly to that position before its review is settled.
The original Nottingham review closed on September 12, 2022. The remaining cases can be reopened with a corrected accounting of the migration that review was created to address.
277.302B $FLOKI remains in blacklisted wallets as rightful holder balances.
Until these balances are returned, Nottingham remains an unfinished chapter in FLOKI's history.