# Timing-neutral calculation robustness checks

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

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

## The reference scale

The first check was the scale itself. The V1 position can be expressed at the migration-opening rate, at the deadline rate, or directly in the contract's reflected units. The full cohort was recalculated using common opening and deadline reference rates.

Both produced exactly the same holder shares as the timing-neutral calculation. The maximum share difference was zero.

Verification:

- `record/scripts/verify-fixed-scale-equivalence.py`
- `record/data/fixed-scale-robustness.json`

## The migration transfer fee

The next check was the migration transfer fee. The deposit record contains the post-fee amount received by the migration wallet, so the audit reconstructed the gross amount sent for every qualifying deposit and compared three versions of the same position:

- the sender's gross reflected debit;
- the emitted post-fee amount;
- the reflected amount credited to the migration wallet.

All 3,761 qualifying deposits match the V1 fee formula. The three measurements produce the same allocation apart from microscopic Solidity integer rounding.

Verification:

- `record/scripts/verify-fixed-scale-fees.py`
- `record/data/fixed-scale-fee-evidence.csv`
- `record/data/fixed-scale-fee-state-cache.jsonl`
- `record/data/fixed-scale-robustness.json`

## The rate at each deposit

Several V1 transfers could execute inside the same Ethereum block, and each fee-bearing transfer could move `currentRate` before the next one executed. The calculation therefore replays those blocks transfer by transfer and uses the rate in effect when each deposit actually ran.

Of 2,652 replayed blocks, 2,650 finish on the exact end state stored by the chain. The remaining two finish inside the proven rounding bound.

Verification:

- `record/data/v1-rates-per-tx.json`
- `record/scripts/verify-fixed-scale-equivalence.py`

## Replaying V1 with the reflection accounting repaired

The final check went back before the migration and asked whether the V1 history itself could simply be replayed with the reflection accounting repaired.

The verifier first reconstructs the actual V1 history across 55,705 Transfer logs and validates it against the chain. It then applies the natural code-level repair:

```text
rTransferAmount = rAmount - rFee - rTeam
```

After only 15 transfers, a sender no longer has enough reflected units to make a transfer that actually occurred. From that point onward, a complete repaired history would require assumptions about transactions that never happened.

Verification:

- `record/scripts/verify-v1-bug-corrected-counterfactual.py`
- `record/data/v1-counterfactual-transfer-cache.jsonl`
- `record/data/v1-counterfactual-transfer-progress.json`
- `record/data/v1-counterfactual-block-state.json`
- `record/data/fixed-scale-robustness.json`

## Result

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