How the migration works

NFD becomes BIC at exactly one for one, and BIC becomes NFD again at exactly one for one. There is no fee, no spread and no price impact, because nothing is being priced — the contract hands back the same number of tokens it took. The rate is not a setting. It cannot be changed by anyone, including the people who wrote it.

This page is the long version. The migration page is where you actually do it, and it is short on purpose.

What happens when you migrate

1. You approve. Your wallet grants the migration contract permission to take exactly the number of NFD you typed. Not more, and not an unlimited allowance unless you go out of your way to grant one.
2. You migrate. In a single transaction, that NFD moves into escrow and the same number of BIC comes back to you.

Going back is the same two steps in reverse. At no point does the Bureau hold your tokens, and at no point is there a moment where you have given up one side without receiving the other — both legs happen inside one transaction, so either the whole thing succeeds or none of it does.

Why it is a Uniswap pool and not a button

The migration is a Uniswap v4 pool with a hook — a contract the pool calls on every swap, which is allowed to answer with its own terms instead of the usual curve. This one always answers one for one.

Building it this way rather than as a bespoke migration widget has one practical consequence: the migration composes. Any aggregator, router or wallet that can route a Uniswap v4 swap can route through it without anyone integrating anything special, and a migrator who never visits this site can still get the same rate through the interface they already use. It also means the migration is not dependent on this website continuing to exist.

The hook is built on Uniswap Labs’ own BaseTokenWrapperHook, the base of their production WETH and wstETH hooks, treating BIC as a one-for-one wrapper over NFD. It was inherited with three one-word changes, none of which alter behaviour.

Where your NFD actually goes

Migrated NFD is held by the hook as its own claim on the Uniswap PoolManager ↗, the contract that custodies every Uniswap v4 token balance. It is not sent to the treasury, not sent to a multisig, and not sent to any address a person controls.

There is no privileged function that reaches the escrow. The only way NFD ever leaves is a reverse swap, and a reverse swap is something anyone can call. That is not a policy the Bureau has adopted; it is the absence of any code that would let it do otherwise.

The escrow is shared, and that is deliberate

The escrow is one pool, first come, first served. Any BIC holder can redeem against it — not only the accounts that migrated, and not in any particular order.

This is the part most worth understanding, so it is worth being blunt about it. The shared escrow is what holds the rate: because anyone can move value in either direction at one for one, any market price that drifts away from the peg is something a stranger can profit from correcting. Take that away and the two tokens can trade apart. The migration treasury, which funded the BIC inventory in the first place, is the largest holder able to redeem — on exactly the same permissionless terms as everybody else, with no priority and no reserved allocation.

Why the maximum is sometimes smaller than your balance

Each direction is bounded by what the contract is actually holding at that moment. Forward migration is limited by the BIC inventory; going back is limited by the NFD in escrow. A swap that asks for more than the remaining capacity reverts rather than filling at a worse rate — you get an error and your tokens stay where they were, instead of quietly receiving less than you expected.

There is a second, less obvious limit. Feisty Doge is a fractionalised vault token, and the vault keeps a count of how many tokens have voted on a reserve price. If you have ever set a reserve price, your tokens are part of that count, and moving them anywhere makes the vault subtract them from it. That count is global — every voting holder draws from the same total — and it only ever goes down. If the remaining total is smaller than the amount you are moving, the transfer fails.

You do not have to think about any of this. The migration page reads both limits live and caps the amount it will let you enter, so the Max button always gives you a figure that will actually go through. It is only described here so that a maximum lower than your balance is not mysterious when you meet it.

What the owner can and cannot do

The hook is owned by the community multisig, 0x8569FCa4fb54CE58228992CDA60bc920A574cf39 ↗.

It can pause forward migration — for example while the Feisty Doge vault is in an auction, when moving tokens is hazardous for reasons that have nothing to do with this contract — and it can withdraw BIC inventory that has not been migrated into.

It cannot pause redeeming, change the rate, reach the escrow, upgrade the contract or replace it. The reverse direction has no pause to call: the ability to turn it off was never written. BIC itself has no owner at all — no mint function, no admin, no proxy.

The hook was deployed with CREATE2 at a mined address, with no proxy and no upgrade path. The code that is there is the code that will be there.

The odd little liquidity position

The pool contains exactly one liquidity position, in a narrow band around the one-for-one price, and no more can ever be added — the hook rejects them. It exists for a dull reason: several listing sites and price trackers ignore pools that report no liquidity at all, and without it the migration would be invisible to them.

It earns nothing, because swaps never touch the curve — the hook answers first, every time. It cannot be moved into a position where it would affect anyone’s rate. The real depth is published by the contract itself, through the same interface Uniswap’s own tooling reads, so anything looking properly sees the actual escrow and inventory rather than the decorative position.

One pool, not several

The hook will only initialise a single, canonical pool. A second pool pointing at the same hook — which would otherwise be able to draw on the same inventory and escrow — cannot be created. The hook also reads no custom swap data, so there is no extra parameter anyone can pass it to make it behave differently.

What was reviewed, and what was not

There is no external audit, and none is planned. That is a real limitation and it is stated here rather than buried.

What can be said: the Uniswap v4, Solady and OpenZeppelin code the contracts are built on is byte-identical to upstream at pinned commits, so it is the same code those projects ship and it carries whatever review they have had. BaseTokenWrapperHook was audited by OpenZeppelin at an earlier revision and has been restructured since. There is a test suite, and the deployment was rehearsed against a fork of mainnet before it was run for real.

What has not been reviewed by any third party is the escrow logic written specifically for this migration — which is, unavoidably, the part that holds your tokens. Waiting, watching the contract for a while, or migrating a small amount first are all reasonable things to do, and nothing about the design penalises you for it. The rate does not get worse for arriving late.

Only the Ethereum mainnet NFD

One token, at one address, on one chain: 0xDFDb7f72c1F195C5951a234e8DB9806EB0635346. The Base and Solana versions of Feisty Doge are different tokens and cannot be migrated here. The contract does not know they exist.

Checking it yourself

None of the above has to be taken on trust. The two numbers that matter are published by the hook as plain read-only calls, and you can make them from a block explorer without a wallet:

• escrowedA() — the NFD currently held in escrow, which is the most that can ever be redeemed back out.
• inventoryB() — the BIC available to migrate into right now.
• paused() — whether forward migration is currently stopped. There is no equivalent call for the reverse direction, because there is nothing to report.

Every migration and redemption emits an event, so the full history is on chain and anyone can total it independently. The two figures above should always reconcile against that history.

The contracts

• BIC token ↗0xB1cDa04D7cD5584048ab48B42b629aEC34D3b562 — no owner, no mint function, fixed supply.
• Migration hook ↗0x78d1A97a9239443070BE0353C68762CCCF64a888 — holds the escrow and the inventory.
• NFD token ↗0xDFDb7f72c1F195C5951a234e8DB9806EB0635346 — Feisty Doge, the token being migrated.
• Community multisig ↗0x8569FCa4fb54CE58228992CDA60bc920A574cf39 — the hook’s owner, and the treasury.
• Uniswap v4 PoolManager ↗0x000000000004444c5dc75cB358380D2e3dE08A90 — where the escrowed NFD is custodied.

Further reading

• The migration page →Where the migration actually happens.
• Feisty Doge →The token being migrated, in the Bureau’s own records.
• Feisty Doge on DeVamp ↗The authenticity review behind it. DeVamp is at devamp.it (site ↗).
• Contracts sourcePublished once the deployment records have been separated from the operational ones. Until then the deployed bytecode is verified on Etherscan and can be read there.