Quick take: when an airdrop campaign switches its points pool, the biggest trap is not missing the Migration button. It is treating your legacy LP position, the off-chain points ledger, and eligibility in the new pool as if they were the same thing. A pool can stop earning points without putting your principal at risk. Likewise, historical points on a dashboard do not prove that leaving funds in the old pool will keep earning weight. The clean playbook is to verify the cut-off and destination pool, capture a complete pre-migration evidence pack, unwind the old position correctly, enter and stake in the new pool, then confirm that the indexer is actually crediting new points.
Security warning: treat any unsolicited Discord DM offering “wallet sync,” “asset verification,” a private migration link, or a mystery Migration Contract as a scam until proven otherwise. A legitimate pool migration may require approvals and on-chain transactions. It never requires your seed phrase, private key, wallet JSON, remote desktop access, or screen sharing.
Why do projects switch pools, and why can funds remain while points stop?
Projects rotate liquidity venues for many reasons: a new underlying DEX, thin liquidity in the legacy pool, a poor bonding curve, a contract upgrade, a shift in emissions, a new oracle or bridge route, or arbitrage, depeg, and security risk in the old setup. Operationally, the team usually adds a new Gauge, Farm, Vault, or LP contract to its points indexer and removes the old contract from the eligible set.
You need to separate three ledgers:
- The asset ledger: your tokens, LP tokens, vault shares, or NFT position still exist on-chain. A points-rule change does not erase ownership;
- The position ledger: the legacy pool may still allow Withdraw, Collect Fees, or Remove Liquidity even though incentives are dead;
- The points ledger: points are often computed by a backend indexer, snapshot job, event pipeline, or private database. They may not be on-chain, real-time, or portable between pools.
In farmer speak: the old pool not being rugged does not mean it is still printing points. A dashboard that has not zeroed out does not mean you can park funds there and farm the rest of the season. Read the rules, verify the position on-chain, then check how the backend scores it.
First determine whether this is a scoring change or a mandatory liquidity migration
| Announcement language | What it usually means | What to do |
|---|---|---|
| Old pool will stop earning points | Your position remains, but no new points accrue after the cut-off | Capture pre-cut-off proof and assess migration promptly |
| Liquidity incentives migrated | Emissions, the Gauge, or the Farm moved to the new pool | Exit the old Gauge, enter the new pool, and stake again |
| Positions will be grandfathered | Legacy positions may retain historical weight or transitional treatment | Confirm whether registration, a signature, or a manual migration is required |
| Snapshot taken | Balances were recorded at a specific timestamp or block | Save the snapshot block and position proof; do not guess how later actions are treated |
| Use the migration contract | The project offers a one-click migration contract | Verify the official domain, contract, function, assets, and spender before approval |
| Withdraw immediately | There may be contract, depeg, bridge, or oracle risk | Protect principal first instead of bagholding risk for unconfirmed points |
If the post only says “the new pool now earns points” but never states when the old pool stops, do not ape into a migration and fill in the blanks yourself. Ask support four precise questions: What is the legacy-pool cut-off timestamp or block? Are historical points preserved? When does the migration window close? From which block or transaction does the new pool start accruing points?
Do not pull liquidity yet: build a legacy-position evidence pack first
A common mistake is to see “old pool no longer earns points” and immediately remove liquidity. When the project later backfills points, opens an appeal window, or asks for historical-position proof, the user has nothing except a cropped screenshot. A useful evidence pack must cover the official rule, the on-chain position, the points dashboard, and the operational timeline.
Layer 1: Preserve the official rule
- the full announcement URL, Discord message link, and official X post;
- the publication time in UTC and your local timezone;
- the legacy-pool name and contract plus the destination-pool contract;
- the cut-off, snapshot block, and migration deadline;
- whether historical points are preserved, backfilled, or converted at a ratio;
- whether the new setup requires restaking, locking, boosting, identity binding, or a form submission.
Do not crop the announcement down to one sentence. Keep the server, channel, author identity, timestamp, and message link visible. Discord posts can be edited or deleted, so save a PDF or web archive alongside screenshots when possible.
Layer 2: Freeze the old position on-chain
| Field | Example | What it proves |
|---|---|---|
| Wallet Address | 0x12…89ab | Which address owns the position and points history |
| Chain ID | 42161 | Prevents same-name pools on different networks from being mixed up |
| Old Pool / Gauge Contract | Verified contract address | Where the funds were actually deposited |
| LP Token / Vault Share / NFT ID | LP balance or Position ID | Ownership of the specific liquidity position |
| Deposit / Stake TxHash | 0xabc… | Deposit time, amount, and transaction path |
| Block Number | Block height | Alignment with the snapshot and cut-off |
| Token Amounts | Token A + Token B | Reconciliation of pre- and post-migration balances |
| Unclaimed Rewards / Fees | Pending rewards and trading fees | Prevents value from being stranded during the exit |
Screenshots make the case readable; TxHashes and contract events make it verifiable. Keep the public address, relevant transaction hashes, explorer links, and points screenshots in one folder. Use consistent filenames such as 2026-08-20_1430UTC_old-pool_position-before-migration.png.
Layer 3: Save the points breakdown, not just the headline number
- total points, season, rank, and boost;
- the contribution attributed to the specific pool;
- the full URL, connected wallet, and active network;
- capture time, browser timezone, and the timezone shown by the dashboard;
- raw exports, history, or activity records if the site provides them;
- the exact error and before/after state when the front end behaves inconsistently.
Key distinction: if points live in an off-chain ledger, an on-chain position proves that you did the work. It does not, by itself, prove how many points the project credited. Preserve both sides of the record.
Migrate by position type: not every LP position unwinds the same way
Case 1: Standard AMM LP tokens held in the wallet
- Check the LP-token balance and the estimated Remove Liquidity output;
- claim any uncollected fees or rewards;
- exit the legacy pool and verify both underlying assets arrived;
- rebalance into the ratio required by the new pool and set sane slippage;
- add liquidity to the destination pool;
- if points accrue only to staked LP, deposit the new LP token into the designated Gauge or Farm.
Many users stop after step five. Their capital is in the correct pool, but the LP token is sitting naked in the wallet while the indexer only reads the Gauge. Funds migrated; points did not.
Case 2: LP tokens deposited in a Gauge, Farm, or Vault
Unwind the layers in the correct order. A common route is:
Claim Rewards → Unstake / Withdraw Share → Remove Liquidity → Rebalance → Add New Liquidity → Stake New Receipt Token
If the vault uses asynchronous withdrawals, a cooldown, or epoch settlement, clicking Withdraw does not mean assets are back in the wallet. Record the request TxHash, claimable time, and final claim TxHash. Do not spam transactions while the withdrawal is queued.
Case 3: Concentrated-liquidity NFT positions
Uniswap V3-style positions are usually NFTs with a Token ID, not fungible ERC-20 LP tokens. The route may require Collect Fees, Decrease Liquidity, and then an optional Burn of the old NFT. Tick ranges, fee tiers, and price bands may differ in the new pool, so copying the old parameters blindly is a bad idea.
A hyper-narrow range may juice headline points, but once price moves out of range the position can stop earning fees and may lose scoring weight. Optimizing points and managing impermanent loss or one-sided inventory are separate risk decisions.
Case 4: Cross-chain pools, bridged assets, and LST/LRT receipts
Confirm whether the new pool accepts the native asset, the canonical-bridge version, or a wrapped derivative. USDC, USDC.e, ETH, wETH, and project-specific wrappers can look interchangeable in a UI while using entirely different contracts. For cross-chain migration, preserve the bridge TxHash, source and destination blocks, message ID, and destination-chain receipt transaction.
Case 5: Positions still under lock, cooldown, or withdrawal queue
If the position cannot exit immediately, do not click a stranger's “fast unlock” link just to beat the deadline. Check the contract's unlock timestamp, epoch, queue position, and claimable state. Ask the team whether locked users are automatically grandfathered, receive an extended migration window, or will be backfilled from a snapshot.
A pool-migration SOP that is hard to mess up
- Verify the notice: cross-check at least two official surfaces among the website, docs, X, and Discord announcements;
- Verify contracts: match the legacy pool, destination pool, Gauge, Router, and Migration Contract character for character;
- Record the pre-migration state: points, LP balance, NFT ID, rewards, block number, and screenshots;
- Run a small dry test: if the position is divisible, migrate a small slice through the full path first;
- Exit the old incentive layer: Claim, Unstake, or Withdraw and confirm the receipt asset returned;
- Exit the old liquidity layer: Remove or Decrease Liquidity and reconcile the underlying assets;
- Inspect approvals: verify the spender, token, allowance, and function before approving the new Router or pool;
- Enter the destination pool: use the correct asset versions, fee tier, and ratio;
- Stake again when required: if the campaign scores a Gauge or Farm, deposit the new LP token or NFT into that contract;
- Complete post-migration checks: save the new TxHashes, balances, Position ID, and first points update;
- Clean up stale permissions: review approvals to legacy routers, gauges, and suspicious spenders;
- Watch for 24-72 hours: indexers can lag, so document each update instead of repeatedly churning the position.
How to confirm you are actually farming the new pool
- On-chain check: the destination contract shows your position, LP balance, or staked balance;
- Asset check: token quantities, fees, slippage, and gas reconcile before and after migration;
- Points check: the new pool's points breakdown starts moving, or the team confirms an indexer delay;
- Operational check: the correct wallet, network, browser session, and team member were used.
If no points appear after 72 hours, do not add more capital yet. Isolate the failure: no on-chain position; position exists but is not staked; position is staked but the indexer missed it; or the front end is showing stale cache.
What evidence matters when the project does not credit historical points?
A strong appeal is not “I definitely had points.” It is a reproducible timeline:
| Time (UTC) | Action | Evidence | Expected | Observed |
|---|---|---|---|---|
| 2026-08-18 09:20 | Staked in legacy pool | Stake TxHash + block | Points continue accruing | Position existed before cut-off |
| 2026-08-20 03:00 | Read migration notice | Announcement link + screenshot | Historical points preserved | Wording was unclear |
| 2026-08-20 03:25 | Exited legacy pool | Withdraw TxHash | Assets returned | Success |
| 2026-08-20 03:41 | Entered and staked new pool | Deposit + Stake TxHash | New pool starts earning | Dashboard unchanged after 48 hours |
Do not dump dozens of unlabeled screenshots into a ticket. Use a structured template:
Subject: Points not credited after official pool migration
Wallet: public address
Chain: network name and Chain ID
Old Pool: contract / Position ID
New Pool: contract / Position ID
Cut-off / Snapshot: official timestamp or block
Timeline: legacy position → Withdraw → Add Liquidity → Stake, all in UTC
TxHashes: listed in execution order
Expected: historical points preserved; new pool credited from the stated block
Observed: missing points range and current dashboard state
Attachments: announcement, pre-migration points, old position, and new position
Ten ways farmers get cooked during a pool migration
- Following an influencer thread instead of the latest official announcement;
- mistaking historical total points for ongoing legacy-pool accrual;
- removing liquidity before collecting fees or rewards;
- adding liquidity to the new pool but forgetting to stake the LP token;
- using the wrong chain, wrapped asset, or fee tier;
- cranking slippage because of deadline FOMO and getting hit by price impact or MEV;
- granting unlimited approval to an unverified Migration Contract;
- a team member connecting the wrong wallet, profile, or session;
- saving screenshots but not TxHashes, blocks, and announcement links;
- churning Withdraw and Deposit transactions because the indexer is a few minutes behind.
Using MostLogin to manage migration evidence and team operations
MostLogin cannot restore missing points, rewrite a snapshot, bypass anti-Sybil controls, or unlock a smart contract. Its role is operational: when several projects change rules at once, separate browser profiles can keep wallet extensions, cookies, Local Storage, proxies, community accounts, and team access from bleeding into one another.
1. Create a dedicated browser profile for each project
A project-specific environment can hold the official domain, block explorer, documentation, Discord, and points dashboard. This reduces wrong-wallet errors and stale sessions reconnecting automatically. See the MostLogin website and the browser profile setup guide.
Compliance boundary: environment isolation should reduce operational mistakes and protect data. It should not be used to impersonate independent users, evade one-person-one-account rules, or bypass Sybil screening.
2. Tag every position by migration status
Use a consistent set such as Pool-Old, Migration-Pending, Pool-New, Points-Delayed, and Ticket-Open. When a team tracks dozens of campaigns, tags beat memory. MostLogin supports multiple tags for browser and cloud-phone profiles; see the MostLogin Tag System.
3. Keep a non-sensitive migration summary in the profile notes
Record the public wallet suffix, chain, legacy pool, destination pool, cut-off, final TxHash characters, and ticket status. Never store a seed phrase, private key, 2FA secret, API token, or wallet password in profile notes.
4. Use team permissions so not everyone can touch the position
Split research, execution, and review. A researcher collects announcements and contracts; an operator submits transactions; a reviewer checks addresses and permissions. MostLogin supports roles and scoped data access by profile or folder. See the team member and permission guide.
5. Maintain a standard migration ledger
Give every project one record containing the wallet, chain, old pool, new pool, snapshot, deadline, old and new TxHashes, points before, points after, owner, and ticket status. The browser profile isolates the session; the ledger preserves the audit trail. You need both when support starts asking questions.
Community lesson: rule changes can matter more than technical failures
In public Chinese-language Web3 Discord research for this project, Saturn repeatedly warned that an older USDC/sUSDat Curve pool had stopped earning points and users needed to migrate to a new FXSwap pool. The case shows why funds remaining visible and historical points staying on a dashboard are not enough. Continued accrual depends on the final eligible-contract list, cut-off, snapshot, and indexer rules.
Pool rotations also create perfect cover for fake support accounts. Use only links reached through the official site, documentation, or announcement channel. If you signed a suspicious Approval, Permit, Permit2, or setApprovalForAll request, inspect permissions and asset exposure immediately. Disconnecting the wallet is not a revocation.
Final pre- and post-migration checklist
- Official announcement, old contract, and destination contract verified;
- cut-off, snapshot, deadline, and timezone recorded;
- legacy balance, Position ID, points, and TxHashes saved;
- fees, rewards, cooldown, and withdrawal queue checked;
- asset version, network, fee tier, and destination Gauge confirmed;
- LP token or NFT staked again when required;
- new-position proof and first points update saved;
- legacy approvals and suspicious spenders reviewed;
- operator, reviewer, and ticket owner assigned;
- no seed phrase, private key, or remote access shared.
Frequently asked questions
Will historical points be wiped when the old pool stops earning?
Not necessarily. Stopping new accrual, deleting historical points, preserving them at a snapshot, and converting them at a ratio are different policies. The latest official announcement and final distribution rules control the outcome.
Can I trust a one-click Migration Contract?
Only when the official website or documentation publishes the contract, chain, function, assets, and exact steps, and the explorer shows verified source code. Before signing, inspect the spender, token, allowance, and function. Never use a “private migration link” sent through DMs.
How long should points take to appear after migration?
It depends on the indexer cadence: real-time, hourly, daily, or per epoch. Save proof of the successful on-chain position, wait through the published synchronization window, and open a structured ticket only if the update remains missing.
Does migrating guarantee an airdrop allocation?
No. Migration may be one eligibility input among many. Final allocation can depend on the snapshot, position duration, capital, genuine usage, geography, identity checks, Sybil review, and whether the project ever launches a token. DYOR and cap principal, gas, and opportunity cost so the farm does not turn into negative EV.
Disclaimer: This article provides general Web3 operations and security education, not investment, legal, or tax advice. DeFi migrations involve smart-contract, liquidity, slippage, impermanent-loss, bridge, and approval risk. Use official documentation and verified contracts.
