Dự án airdrop đổi pool tính điểm: cách migrate vốn cũ và lưu bằng chứng

Tóm tắt nhanh: khi dự án airdrop đổi pool tính điểm, cú trượt chân phổ biến nhất không phải là “không biết bấm nút Migration”, mà là đánh đồng vị thế LP cũ, sổ point và điều kiện của pool mới. Pool cũ ngừng cộng point không có nghĩa vốn tự biến mất; dashboard vẫn hiện point lịch sử cũng không đồng nghĩa cứ nằm im trong pool cũ là còn được tính trọng số. Quy trình đúng là: xác nhận Cut-off và pool đích từ kênh chính thức, chụp lại đầy đủ bằng chứng của vị thế cũ, rút theo đúng loại vị thế, vào pool mới rồi stake lại, sau đó kiểm tra point mới có thực sự chạy hay chưa.

Cảnh báo an toàn: bất kỳ ai nhắn riêng trên Discord, bảo bạn “sync ví”, “verify tài sản”, nhập Seed Phrase hoặc gọi một Migration Contract lạ đều nên được xem là scam trước khi có bằng chứng ngược lại. Migrate pool bình thường chỉ cần approve và gửi giao dịch on-chain; không bao giờ cần seed phrase, private key, file JSON của ví, quyền điều khiển máy từ xa hay share màn hình.

Vì sao dự án đổi pool? Tại sao vốn vẫn nằm đó nhưng point không chạy nữa?

Dự án đổi pool thường vì chuyển DEX nền, thanh khoản pool cũ quá mỏng, đường cong giá không còn hợp lý, nâng cấp contract, dời ngân sách incentive, thay oracle hoặc route bridge, hay pool cũ phát sinh arbitrage, depeg hoặc rủi ro bảo mật. Khi đó team sẽ thêm Gauge, Farm, Vault hoặc LP Contract mới vào Points Indexer, đồng thời gỡ contract cũ khỏi whitelist tính điểm.

Phải tách rõ ba “cuốn sổ”:

• Sổ vốn: token, LP Token, Vault Share hoặc NFT Position của bạn vẫn tồn tại on-chain. Việc đổi rule point không tự động xóa quyền sở hữu;
• Sổ vị thế: contract cũ có thể vẫn cho Withdraw, Collect Fees hoặc Remove Liquidity, chỉ là không còn incentive mới;
• Sổ point: point thường do Indexer phía backend, Snapshot, event log hoặc database riêng của dự án tính. Nó không nhất thiết on-chain, cập nhật real-time hay tự chuyển sang pool mới.

Nói theo kiểu dân cày: pool cũ chưa rug không có nghĩa vẫn còn “nhả point”. Dashboard chưa reset cũng không có nghĩa cứ nằm im là ăn trọn Season. Đọc rule trước, soi on-chain sau, cuối cùng mới đối chiếu cách backend ghi điểm.

Phân biệt: dự án chỉ đổi cách tính point hay bắt buộc phải migrate vị thế?

Nếu thông báo chỉ nói “pool mới bắt đầu tính point” nhưng không nói rõ lúc nào pool cũ dừng, đừng lao vào làm “scientist” rồi tự đoán. Hãy hỏi support bốn câu: Cut-off của pool cũ là lúc nào hoặc block bao nhiêu? Point lịch sử có được giữ không? Migration Window đóng khi nào? Pool mới bắt đầu ghi point từ giao dịch hay block nào?

Khoan rút LP: hãy đóng gói bằng chứng của vị thế cũ trước

Không ít người vừa thấy “pool cũ không còn point” là Remove Liquidity ngay. Đến khi dự án backfill point, mở Appeal hoặc đòi chứng minh vị thế lịch sử thì chỉ còn một ảnh chụp mờ. Bộ bằng chứng có giá trị phải bao phủ đủ rule chính thức, vị thế on-chain, dashboard point và timeline thao tác.

Lớp 1: Lưu nguyên văn rule chính thức

• URL đầy đủ của thông báo, Discord Message Link và bài đăng X chính thức;
• thời gian đăng theo cả UTC và giờ Việt Nam;
• tên và contract của pool cũ, contract của pool mới;
• Cut-off, block Snapshot và Migration Deadline;
• team có cam kết giữ, backfill hay chuyển tỷ lệ point lịch sử hay không;
• có phải stake lại, lock, boost, bind identity hay gửi form không.

Đừng chỉ crop mỗi nội dung. Ảnh cần có tên server, channel, danh tính người đăng, thời gian và message link. Tin Discord có thể bị sửa hoặc xóa; ngoài screenshot, nên lưu thêm PDF hoặc bản archive của trang.

Lớp 2: Cố định trạng thái vị thế cũ trên chain

Screenshot giúp support đọc nhanh; TxHash và event của contract mới giúp họ kiểm chứng. Hãy gom địa chỉ ví, TxHash, link block explorer và ảnh point vào cùng một thư mục, đặt tên thống nhất, chẳng hạn 2026-08-20_1430UTC_old-pool_position-before-migration.png.

Lớp 3: Lưu dashboard point, không chỉ ghi mỗi tổng điểm

• tổng Points hiện tại, Season, Rank và Boost;
• chi tiết point do chính pool đó đóng góp;
• URL đầy đủ, địa chỉ ví đang connect và network;
• thời gian chụp, timezone của trình duyệt và timezone hiển thị trên trang;
• nếu có Export, History hoặc Activity thì tải bản gốc;
• khi front end lỗi, ghi nguyên văn error và khác biệt trước/sau khi refresh.

Điểm mấu chốt: nếu Points là sổ cái backend, vị thế on-chain chỉ chứng minh “bạn đã làm thật”, chứ chưa chứng minh “dự án đã ghi đúng bao nhiêu point”. Vì vậy phải giữ cả hai nhóm bằng chứng.

Migrate theo loại vị thế: đừng coi mọi LP là một loại tài sản

Trường hợp 1: LP Token AMM thông thường đang nằm trong ví

1. Kiểm tra số dư LP Token và lượng tài sản ước tính khi Remove Liquidity;
2. claim toàn bộ fee hoặc reward chưa nhận;
3. rút pool cũ và kiểm tra hai token nền đã về đủ;
4. cân lại tỷ lệ cho pool mới, đặt Slippage hợp lý;
5. Add Liquidity vào pool mới;
6. nếu pool mới chỉ tính point cho LP đã stake, phải stake LP Token thêm một lần.

Nhiều người làm đến bước 5 rồi tưởng xong. Kết quả là LP Token nằm “trần” trong ví, trong khi hệ thống chỉ index số dư ở Gauge; vốn đã chuyển nhưng point vẫn bằng 0.

Trường hợp 2: LP đã nằm trong Gauge, Farm hoặc Vault

Phải rút đúng thứ tự. Luồng phổ biến là:

Claim Rewards → Unstake / Withdraw Share → Remove Liquidity → Rebalance → Add New Liquidity → Stake New Receipt Token

Nếu Vault dùng Withdraw bất đồng bộ, Cooldown hoặc quyết toán theo Epoch, bấm Withdraw chưa có nghĩa tiền về ví ngay. Hãy lưu Request TxHash, Claimable Time và Final Claim TxHash; đừng spam giao dịch trong trạng thái chờ.

Trường hợp 3: Vị thế thanh khoản tập trung dạng NFT

Vị thế kiểu Uniswap V3 thường là NFT có Token ID, không phải LP ERC-20 thông thường. Bạn có thể phải Collect Fees, Decrease Liquidity rồi mới cân nhắc Burn NFT cũ. Tick Range, fee tier và khoảng giá của pool mới có thể khác, không nên copy máy móc.

Nếu vì muốn cày point mà đặt range quá hẹp, giá chạy ra ngoài range thì vị thế ngừng kiếm fee, thậm chí trọng số point cũng bị ảnh hưởng. “Tối đa point” và “kiểm soát impermanent loss/rủi ro lệch một phía” là hai bài toán khác nhau.

Trường hợp 4: Pool cross-chain, tài sản bridge hoặc receipt LST/LRT

Phải xác nhận pool mới dùng native asset, canonical bridge asset hay wrapped token. USDC, USDC.e, ETH, wETH và token bọc của dự án nhìn giống nhau nhưng contract khác hẳn. Nếu migrate qua chain khác, cần lưu thêm Bridge TxHash, block nguồn/đích, Message ID và giao dịch nhận tài sản ở chain đích.

Trường hợp 5: Vốn còn bị Lock, Cooldown hoặc nằm trong Withdrawal Queue

Nếu chưa thể rút ngay, đừng vì sợ lỡ Deadline mà bấm link “unlock nhanh” từ người lạ. Hãy kiểm tra Unlock Timestamp, Epoch, Queue Position và trạng thái Claimable, rồi hỏi team xem user đang lock có được tự động giữ point, gia hạn cửa sổ migrate hay backfill theo Snapshot không.

SOP migrate pool ít lỗi nhất

1. Xác thực thông báo: đối chiếu ít nhất hai nơi giữa website, docs, X và channel Announcement chính thức;
2. Kiểm tra contract: Old Pool, New Pool, Gauge, Router và Migration Contract phải khớp từng ký tự;
3. Chụp trạng thái trước migrate: Points, số dư LP, NFT ID, reward, block và screenshot;
4. Dry run bằng số vốn nhỏ: nếu tách được vị thế, migrate một phần để test toàn bộ luồng;
5. Thoát lớp incentive cũ: Claim, Unstake, Withdraw và kiểm tra Receipt Token về ví;
6. Rút thanh khoản cũ: Remove/Decrease Liquidity, đối soát tài sản và hao hụt;
7. Kiểm tra approval: xác nhận Spender của Router/Pool mới, không approve unlimited cho contract mập mờ;
8. Vào pool mới: dùng đúng asset, fee tier và tỷ lệ mà docs yêu cầu;
9. Stake lần hai: nếu Points tính ở Gauge/Farm thì phải stake LP/NFT vào đúng contract;
10. Nghiệm thu sau migrate: lưu TxHash, số dư, Position ID và lần cập nhật point đầu tiên;
11. Dọn quyền cũ: đánh giá revoke approval của Router, Gauge hoặc Spender không còn dùng;
12. Theo dõi 24-72 giờ: Indexer có thể trễ; ghi lại từng lần cập nhật thay vì spam giao dịch.

Làm sao biết đã “lên tàu” thật, chứ không chỉ chuyển tiền sang chỗ khác?

• On-chain: contract pool mới hiển thị Position, LP Balance hoặc Staked Balance của bạn;
• Tài sản: đối soát được số token, fee, slippage và gas trước/sau migrate;
• Point: chi tiết pool mới bắt đầu tăng, hoặc team xác nhận Indexer đang delay;
• Vận hành: không connect nhầm ví, nhầm network, nhầm browser session hoặc bị thành viên khác ghi đè.

Nếu sau 72 giờ vẫn không có point, đừng vội bơm thêm vốn. Hãy xác định lỗi thuộc một trong bốn nhánh: vị thế on-chain không tồn tại; vị thế có nhưng chưa stake; đã stake nhưng Indexer chưa đọc; hoặc front end chỉ đang cache dữ liệu cũ.

Khi dự án không ghi nhận point lịch sử, bằng chứng nào có trọng lượng?

Một Appeal tốt không phải câu “em chắc chắn có point”, mà là timeline có thể kiểm tra:

Khi mở Ticket, đừng quăng hàng chục ảnh không tên. Dùng mẫu sau:

Subject: Points not credited after official pool migration

Wallet: địa chỉ công khai

Chain: tên network và Chain ID

Old Pool: contract / Position ID

New Pool: contract / Position ID

Cut-off / Snapshot: thời gian hoặc block chính thức

Timeline: vị thế cũ → Withdraw → Add Liquidity → Stake, theo UTC

TxHashes: liệt kê theo đúng thứ tự

Expected: giữ point lịch sử và tính point pool mới từ block quy định

Actual: khoảng point bị thiếu và trạng thái dashboard

Attachments: thông báo, Points trước migrate, ảnh vị thế cũ và mới

10 lỗi khiến dân cày dễ “ăn hành” nhất

1. Chỉ đọc thread của KOL mà không mở announcement mới nhất;
2. nhìn tổng point lịch sử rồi tưởng pool cũ vẫn đang chạy;
3. rút LP trước khi claim fee hoặc reward;
4. đã add pool mới nhưng quên stake vào Gauge;
5. migrate sai chain, sai wrapped token hoặc sai fee tier;
6. kéo Slippage quá cao vì FOMO Deadline, bị price impact hoặc MEV “gặm” vốn;
7. approve unlimited cho Migration Contract chưa xác minh;
8. thành viên team dùng nhầm ví, nhầm Profile hoặc ghi đè session;
9. chỉ giữ screenshot, không giữ TxHash, block và link thông báo;
10. Indexer trễ vài phút đã Withdraw/Deposit liên tục, làm timeline rối tung.

Dùng MostLogin để quản lý bằng chứng và vận hành migrate

MostLogin không thể tự khôi phục Points, sửa Snapshot, bypass anti-Sybil hay unlock contract. Giá trị của nó nằm ở lớp vận hành: khi nhiều dự án đổi rule cùng lúc, bạn có thể tách wallet extension, Cookie, Local Storage, proxy, tài khoản cộng đồng và quyền của từng thành viên để tránh lẫn session hoặc thao tác nhầm.

1. Tạo Browser Profile riêng cho từng dự án

Mỗi dự án có thể dùng một môi trường riêng, lưu domain chính thức, block explorer, docs, Discord và dashboard Points. Cách này giảm nguy cơ mở nhầm ví hoặc bị session cũ tự reconnect. Xem thêm tại website MostLogin và hướng dẫn tạo Browser Profile.

Ranh giới tuân thủ: tách môi trường để giảm lỗi thao tác và bảo vệ dữ liệu, không phải để giả làm nhiều người dùng độc lập, lách rule một người một tài khoản hoặc né Sybil detection.

2. Dùng tag để theo dõi trạng thái vốn

Có thể thống nhất các tag như Pool-Old, Migration-Pending, Pool-New, Points-Delayed và Ticket-Open. Khi theo dõi vài chục kèo cùng lúc, tag đáng tin hơn trí nhớ. MostLogin hỗ trợ gắn nhiều tag cho Browser Profile và Cloud Phone Profile; xem MostLogin Tag System.

3. Ghi tóm tắt migrate không nhạy cảm trong phần Remark

Có thể ghi đuôi địa chỉ ví công khai, chain, pool cũ/mới, Cut-off, vài ký tự cuối của TxHash và trạng thái Ticket. Tuyệt đối không lưu seed phrase, private key, 2FA Secret, API Token hoặc mật khẩu ví trong Remark.

4. Phân quyền team để tránh tình trạng “ai cũng có thể động vào tiền”

Tách vai trò: researcher thu thập announcement và contract; operator gửi giao dịch; reviewer kiểm tra địa chỉ và quyền approve. MostLogin hỗ trợ role và phạm vi truy cập dữ liệu theo Profile hoặc folder; xem hướng dẫn thành viên và phân quyền team.

5. Duy trì một ledger migrate cố định

Mỗi Profile tương ứng một dòng: dự án, ví, chain, pool cũ, pool mới, Snapshot, Deadline, TxHash cũ/mới, Points Before, Points After, người phụ trách và trạng thái Ticket. Browser Profile giải quyết session; ledger giải quyết chuỗi bằng chứng. Thiếu một trong hai thì lúc Appeal rất dễ “toang”.

Bài học từ cộng đồng: đổi rule thường nguy hiểm hơn lỗi kỹ thuật

Trong mẫu Discord Web3 tiếng Trung mà dự án này theo dõi, Saturn từng liên tục nhắc pool USDC/sUSDat cũ trên Curve đã ngừng cộng point và người dùng phải migrate sang pool mới trên FXSwap. Case này cho thấy vốn vẫn còn trong pool và dashboard vẫn hiển thị Points lịch sử không thể thay thế rule mới nhất. Thứ quyết định bạn còn được “cày point” hay không là contract whitelist cuối cùng, Cut-off, Snapshot và cách Indexer ghi nhận.

Một rủi ro khác: ngay sau thông báo migrate, fake support thường nhảy vào DM và gửi “Migration Link riêng”. Chỉ đi từ website, docs và announcement chính thức. Nếu đã ký Approval, Permit, Permit2 hoặc setApprovalForAll đáng ngờ, cần kiểm tra quyền và rủi ro tài sản ngay; Disconnect ví không đủ.

Checklist cuối cùng trước và sau khi migrate

• Đã đối chiếu announcement, contract pool cũ và pool mới;
• đã ghi Cut-off, Snapshot, Deadline và timezone;
• đã lưu số dư, Position ID, Points và TxHash của vị thế cũ;
• đã kiểm tra Fees, Rewards, Cooldown và Withdrawal Queue;
• đã xác nhận asset version, network, fee tier và Gauge của pool mới;
• đã stake lại sau khi Add Liquidity;
• đã lưu bằng chứng vị thế mới và lần cập nhật Points đầu tiên;
• đã kiểm tra approval cũ và Spender đáng ngờ;
• team đã chỉ định operator, reviewer và người phụ trách Ticket;
• không cung cấp seed phrase, private key hoặc quyền điều khiển máy cho bất kỳ ai.

Câu hỏi thường gặp

Pool cũ ngừng tính điểm thì Points lịch sử có bị xóa không?

Không nhất thiết. Ngừng cộng point mới, xóa point cũ, giữ theo Snapshot và chuyển theo tỷ lệ là bốn kịch bản khác nhau. Phải xem announcement mới nhất và rule phân phối cuối cùng.

Dự án có Migration Contract một chạm, có nên bấm luôn không?

Chỉ dùng khi website hoặc docs chính thức công bố rõ contract, network, function và quy trình, đồng thời block explorer cho thấy contract đã verify. Trước khi ký phải đọc Spender, Token, hạn mức và function; tuyệt đối không dùng link “riêng” do người lạ gửi trong DM.

Migrate sang pool mới bao lâu thì point cập nhật?

Tùy nhịp Indexer: real-time, theo giờ, theo ngày hoặc theo Epoch. Hãy lưu bằng chứng giao dịch thành công trước, chờ đúng chu kỳ team công bố rồi mới mở Ticket nếu vẫn chưa cập nhật.

Migrate pool có đảm bảo nhận airdrop không?

Không. Migrate chỉ có thể là một điều kiện. Kết quả cuối cùng còn phụ thuộc Snapshot, thời gian duy trì vị thế, số vốn, mức độ sử dụng thật, giới hạn khu vực, xác minh danh tính, Sybil review và việc dự án có thật sự phát token hay không. DYOR và quản lý vốn, gas cùng chi phí cơ hội để tránh “cày xong bị phản kèo”.

Tuyên bố miễn trừ trách nhiệm: Nội dung này chỉ phục vụ mục đích giáo dục về vận hành và an toàn Web3, không phải tư vấn đầu tư, pháp lý hay thuế. Migrate DeFi có rủi ro contract, thanh khoản, slippage, impermanent loss, bridge và approval. Luôn ưu tiên docs chính thức và contract đã verify.