Hết hạn stake nhưng tài sản vẫn bị khóa: Cách kiểm tra contract, thời gian unlock và cổng rút

Trả lời nhanh: hết kỳ lock mà tiền vẫn bị “giam” chưa chắc là contract có vấn đề. Thường là đồng hồ trên front end lệch cách tính với thời gian on-chain; hết kỳ stake nhưng vẫn phải tự Unstake; contract còn Cooldown hoặc Withdrawal Delay; token trả dần theo lịch Vesting; cổng rút đã chuyển sang contract khác; hoặc front end đọc sai Proxy, RPC hay state của ví. Đừng chỉ nhìn ngày trên website rồi kết luận dự án “om tiền”. Hãy check theo đúng flow: tiền đang nằm ở contract nào → contract lấy mốc thời gian nào → releasable/claimable hiện có lớn hơn 0 không → phải rút ở cổng nào → tx đã thật sự lên chain chưa.

Cảnh báo bảo mật: lúc không thấy nút unlock hoặc withdraw là lúc admin dỏm dễ nhảy vào inbox nhất. Trang migrate giả, link “sync ví” và dịch vụ “mở khóa hộ” đều là bài scam quen thuộc. Ai xin seed phrase, private key, quyền remote máy hoặc bắt nhập thông tin khôi phục ví lên web lạ thì block ngay. Kể cả khi tự thao tác qua block explorer, bạn vẫn phải check network, contract chính chủ, quan hệ Proxy và tham số hàm. Đừng thấy một tấm ảnh trong group rồi lao vào bấm Write Contract.

Hết hạn stake nhưng vẫn bị khóa: trước tiên phải phân biệt 5 trạng thái

Trong Web3, “hết hạn”, “đã mở khóa”, “có thể nhận”, “đã nhận” và “có thể giao dịch” là năm trạng thái khác nhau. Rất nhiều ca chẩn đoán sai bắt nguồn từ việc gộp chúng thành một.

Nói theo kiểu dân on-chain: ngày trên UI chỉ để tham khảo; timestamp, balance, state và event trong contract mới là source of truth.

Tại sao hết hạn rồi mà tài sản vẫn bị khóa? 10 nguyên nhân phổ biến

1. Hết hạn chỉ dừng tính reward, không tự trả tiền gốc

Một số Staking Contract tách “kết thúc tính reward” và “rút tiền gốc” thành hai thao tác. Sau khi periodFinish, endTime hoặc lockEnd đã tới, reward ngừng cộng nhưng người dùng vẫn phải gửi giao dịch unstake, withdraw, exit hoặc redeem. Front end hiện Matured không có nghĩa contract sẽ tự đẩy tài sản về ví.

2. Phải Unstake trước rồi mới chờ hết Cooldown

Nhiều giao thức dùng quy trình rút hai bước: giao dịch đầu chỉ đăng ký số lượng muốn rút và bắt đầu thời gian chờ; hết Cooldown mới thực hiện withdraw hoặc claim lần hai. Các trường thường gặp gồm cooldownStart, cooldownEnd, withdrawalDelay, requestTime và unlockAt. Nếu mới hoàn thành giao dịch đầu tiên, tài sản tiếp tục hiện Locked là trạng thái bình thường.

3. Token mở khóa theo Cliff hoặc Vesting tuyến tính, không mở toàn bộ một lần

Cliff có nghĩa là trước một mốc nhất định, số lượng có thể nhận bằng 0. Sau Cliff, contract có thể trả một phần ngay hoặc bắt đầu mở khóa tuyến tính. VestingWallet của OpenZeppelin tách riêng start, duration, released và releasable, đồng thời dùng release để thực hiện chi trả. Kể cả schedule đã chạy, người dùng chỉ nhận được phần đã vested nhưng chưa released.

4. Front end hiển thị giờ địa phương, còn contract dùng Unix UTC

Contract EVM thường dùng block.timestamp, tức Unix timestamp tính bằng giây của block hiện tại. Front end có thể chuyển nó sang giờ Việt Nam, múi giờ của trình duyệt hoặc chỉ hiện ngày mà bỏ giờ, phút, giây. Vì vậy, “mở khóa ngày 30/8” có thể thực tế là 23:59 UTC ngày 30/8, chứ không phải 00:00 theo giờ Việt Nam.

5. Website nhầm timestamp giây với mili giây hoặc đang giữ cache cũ

Timestamp trong Solidity thường tính bằng giây, còn JavaScript Date thường dùng mili giây. Nếu front end quên nhân hoặc nhân thừa 1.000, ngày hiển thị sẽ sai hoàn toàn. Trường hợp phổ biến hơn là website vẫn đọc dữ liệu cũ từ API, Indexer hoặc Subgraph: contract đã unlock nhưng UI vẫn báo Locked.

6. Tiền không còn nằm trong Staking Contract mà đã sang Vesting, Queue hoặc Vault

Một sản phẩm có thể dùng đồng thời Staking Contract, Rewards Distributor, Withdrawal Queue, Vesting Wallet, Vault và Token Contract. Bạn stake trên UI cũ không có nghĩa lúc rút cũng tương tác với contract cũ. Sau khi upgrade contract, migrate pool hoặc chia reward, tiền có thể đã bị route sang một contract khác để giữ hộ.

7. Front end đã nâng cấp hoặc chuyển cổng, trang cũ chỉ còn chức năng xem

Sau khi giao thức đổi front end, domain, pool hoặc contract, trang cũ có thể vẫn connect ví và hiển thị position nhưng không còn nút rút. Nghiên cứu cộng đồng Web3 Discord nói tiếng Hoa của dự án này đã ghi nhận trường hợp “hết thời hạn khóa nhưng vẫn không unlock được, không tìm thấy cổng rút”. Lúc này cần tìm announcement, Docs, trang migrate và địa chỉ contract mới nhất từ nguồn chính thức, không dùng quảng cáo tìm kiếm hoặc link được gửi qua DM.

8. Đọc sai Proxy Contract

Giao thức có thể nâng cấp thường dùng Proxy. Tiền và state thường nằm ở địa chỉ Proxy, còn ABI logic đến từ Implementation. Nếu chỉ mở Read Contract của Implementation, bạn có thể không đọc được position của mình; nếu gửi nhầm giao dịch thẳng tới Implementation, giao dịch còn có thể fail. Trên block explorer, hãy tìm “Read as Proxy” hoặc “Write as Proxy” và đối chiếu địa chỉ Proxy được dự án công bố.

9. Contract bị Pause, có Withdrawal Window hoặc yêu cầu thêm điều kiện

Một số contract cho phép admin tạm dừng withdraw hoặc yêu cầu người dùng nhận tài sản trong một Withdrawal Window nhất định. Nếu lỡ cửa sổ đó, bạn có thể phải bắt đầu Cooldown lại. Một số dự án còn yêu cầu hoàn tất KYC, chấp nhận Terms, migrate chứng chỉ, burn receipt token hoặc chờ keeper cập nhật epoch trước khi thoát.

10. Giao dịch nhận token thất bại nhưng giao diện không báo rõ

Nếu bấm nút mà không có TxHash, giao dịch có thể chưa bao giờ được broadcast. Nếu có TxHash nhưng trạng thái Reverted, cần đọc Revert Reason, Custom Error và call bị lỗi. MetaMask khuyến nghị dùng TxHash trên block explorer của đúng network để xem thông tin lỗi của giao dịch smart contract.

12 bước thực chiến: từ địa chỉ contract đến đúng cổng nhận tài sản

Bước 1: Xác nhận đúng địa chỉ ví và đúng network

Đầu tiên, hãy đối chiếu đầy đủ địa chỉ đã dùng để stake, đừng chỉ nhìn nickname trong ví. Kiểm tra xem bạn tham gia bằng Hardware Wallet, Safe, Smart Account hay một Imported Account khác. Sau đó xác nhận Chain ID: cùng một địa chỉ trên Ethereum, Arbitrum, Base hoặc BSC có thể có position hoàn toàn khác nhau.

Bước 2: Dùng giao dịch stake ban đầu để xác định contract

Mở giao dịch Stake ban đầu trên block explorer và ghi lại:

• địa chỉ To, tức contract đã tương tác lúc đó;
• Method, chẳng hạn stake, deposit, lock hoặc createLock;
• số lượng, thời hạn, tokenId hoặc poolId trong Input Data;
• các Token Transfer liên quan;
• event như Deposit, Staked, Locked hoặc PositionCreated.

Nếu không tìm thấy trong lịch sử ví, hãy tìm giao dịch chuyển tiền gốc ra trong Token Transfers rồi truy ngược contract nhận. Đừng phụ thuộc hoàn toàn vào position hiển thị trên trang dự án.

Bước 3: Xác minh địa chỉ contract từ nguồn chính thức

Hãy đối chiếu ít nhất hai nguồn: Docs hoặc announcement chính thức của dự án, code đã verify trên block explorer hoặc lịch sử deploy trong GitHub chính thức. Kiểm tra đúng network, contract có Verified không, địa chỉ deployer có khớp hồ sơ của dự án không và đây là Proxy hay Implementation.

Bước 4: Dùng Read Contract trước, đừng vội Write

Theo hướng dẫn chính thức của Etherscan, Read Contract chỉ đọc dữ liệu public của contract, không thay đổi state on-chain và không tốn gas. Write Contract gửi giao dịch thay đổi state, cần ví ký và trả gas. Khi troubleshoot, luôn đọc trước rồi mới ghi.

Tên hàm thay đổi theo từng giao thức, nhưng nên tìm các nhóm sau:

• start, startTime, lockStart;
• endTime, unlockTime, lockEnd, maturity;
• cliff, duration, periodFinish;
• cooldownEnd, withdrawalTime, requestTime;
• balanceOf, stakes(address), userInfo, positions;
• releasable, claimable, withdrawable, earned;
• released, claimed, withdrawn;
• paused, emergencyMode, withdrawalsEnabled.

Bước 5: Đổi timestamp on-chain sang UTC và giờ Việt Nam

Tài liệu Solidity định nghĩa block.timestamp là số giây tính từ Unix Epoch. Trước khi đổi, hãy nhìn số chữ số:

Khoảng 10 chữ số: thường là giây, ví dụ 1788048000
Khoảng 13 chữ số: thường là mili giây, ví dụ 1788048000000

Giờ UTC = kết quả đổi từ Unix timestamp theo giây
Giờ Việt Nam = UTC + 7 giờ

Ví dụ thực tế: contract trả về unlockTime = 1788048000, tương ứng 2026-08-30 00:00:00 UTC, tức 2026-08-30 07:00:00 theo giờ Việt Nam. Nếu trang chỉ ghi “30/8”, việc kiểm tra lúc rạng sáng và vẫn thấy Locked không hề mâu thuẫn.

Bước 6: Xác nhận contract dùng thời gian block, không dùng đồng hồ trên website

Điều kiện thực thi thường có dạng:

require(block.timestamp >= unlockTime, "Still locked");

Điều kiện được đánh giá bằng thời gian của block khi giao dịch được đưa vào chain, không phải giờ trên máy tính, điện thoại hay đồng hồ đếm ngược trong trình duyệt. Nếu block chưa tới mốc, đổi giờ hệ thống, xóa Cookie hay đổi trình duyệt cũng không thể unlock sớm.

Bước 7: Phân biệt unlock một lần và Vesting tuyến tính

Khóa một lần thường mở toàn bộ sau unlockTime. Vesting tuyến tính lại tăng vestedAmount dần theo thời gian. Có thể kiểm tra sơ bộ bằng công thức:

Số lượng đã vested = Tổng allocation × (Thời gian hiện tại - Thời gian bắt đầu) ÷ Tổng thời hạn
Số lượng có thể nhận hiện tại = Số đã vested - Số đã nhận

Ví dụ bằng số: tổng allocation là 10.000 token, bắt đầu lúc 2026-06-01 00:00 UTC, thời hạn 90 ngày. Đến ngày thứ 75, số đã vested theo lý thuyết là 10.000 × 75 ÷ 90 = 8.333,33. Nếu trước đó đã nhận 5.000 token, releasable hiện tại vào khoảng 3.333,33 token, không phải toàn bộ 5.000 token còn lại. Kết quả thực tế vẫn phụ thuộc cách làm tròn và vesting curve riêng của contract.

OpenZeppelin VestingWallet tách start, duration, released, releasable và release, cho thấy “đã vested” và “đã chuyển về ví” là hai trạng thái khác nhau.

Bước 8: Kiểm tra xem quy trình cần một, hai hay ba giao dịch

Các flow thoát phổ biến gồm:

1. Một bước: gọi thẳng withdraw hoặc exit;
2. Hai bước: requestUnstake → chờ Cooldown → withdraw;
3. Ba bước: unstake → finalizeWithdrawal → claim;
4. Theo hàng đợi: requestWithdraw → chờ epoch/keeper xử lý → claim;
5. Position dạng NFT: withdraw(tokenId) → burn receipt NFT → nhận lại tiền gốc.

Ví dụ: người dùng bấm Unstake ngày 1/8 nhưng contract chỉ ghi requestTime; rule yêu cầu Cooldown 7 ngày. Đến sau ngày 8/8, withdraw mới chạy được. Nếu còn có Withdrawal Window 48 giờ, bỏ lỡ cửa sổ này có thể phải bắt đầu Cooldown lại. Chỉ nhìn ngày hết kỳ stake không đủ để suy ra ngày rút tiền.

Bước 9: Tìm đúng Claim, Withdraw hoặc Release Contract

Dùng Docs, announcement mới nhất và event của giao dịch gốc để xác định tiền hiện đang nằm ở đâu. Khi cần, hãy kiểm tra:

• Staking Contract có chuyển tiền vào Vault không;
• event Unstake có tạo Withdrawal Request ID không;
• beneficiary trong Vesting Contract có đúng là địa chỉ của bạn không;
• Rewards Distributor chỉ trả reward hay trả cả tiền gốc;
• pool cũ đã migrate sang pool mới chưa;
• Implementation của Proxy đã được nâng cấp chưa.

Tên hàm chỉ là manh mối, không phải chỉ dẫn thao tác. Nếu chưa có hướng dẫn chính thức hoặc ABI đầy đủ, đừng thử bừa các hàm trông giống emergencyWithdraw, rescue hoặc migrate.

Bước 10: Đọc số lượng có thể nhận trước khi gửi giao dịch

Nếu contract có releasable, claimable hoặc withdrawable, hãy truyền địa chỉ của bạn hoặc Token Contract để đọc trước. Nếu trả về 0, tiếp tục kiểm tra Cliff, số đã nhận, token parameter và số dư contract. Nếu lớn hơn 0, mới thao tác từ front end chính thức hoặc cổng Write as Proxy đã được xác minh.

Đồng thời kiểm tra contract có đủ balance để chi trả không. Có allocation trên lý thuyết không có nghĩa Vesting Contract đã được nạp tiền. Tài liệu OpenZeppelin cũng cho thấy logic releasable liên quan tới lượng tài sản contract thực sự đang giữ.

Bước 11: Dựa vào TxHash để biết giao dịch đã chạy đến đâu

Bước 12: Gom bằng chứng và mở Ticket chính thức

Nếu dữ liệu on-chain cho thấy đã có thể rút nhưng cổng chính thức vẫn không hoạt động, hãy gửi:

Vấn đề: hết hạn stake nhưng vẫn hiện Locked
Địa chỉ ví công khai: 0x...
Network và Chain ID: ...
Stake TxHash ban đầu: ...
Unstake/Request TxHash: ...
Withdraw/Claim TxHash bị lỗi: ...
Staking/Proxy Contract: ...
Vesting/Queue Contract: ...
unlockTime on-chain: ...
Thời gian đã đổi sang UTC và giờ địa phương: ...
Giá trị releasable/claimable: ...
Revert Reason hoặc Custom Error: ...
URL trang chính thức: ...
Thời gian xảy ra: YYYY-MM-DD HH:MM UTC
Tệp đính kèm: ảnh đã che dữ liệu nhạy cảm

Không gửi seed phrase, private key, mật khẩu ví, Cookie, Discord Token hoặc quyền điều khiển từ xa trong Ticket.

Ba case hoàn chỉnh: tìm đúng nguyên nhân từ trạng thái “vẫn bị khóa”

Case 1: Ngày trên trang đã tới nhưng on-chain vẫn còn thiếu 7 giờ

Hiện tượng: website ghi mở khóa ngày 30/8. Người dùng kiểm tra lúc rạng sáng ngày 30/8 theo giờ Việt Nam nhưng vẫn thấy Locked.

Kiểm tra: Read Contract trả về unlockTime = 1788048000. Sau khi đổi, mốc này là 2026-08-30 00:00 UTC, tức 07:00 theo giờ Việt Nam. Điều kiện contract đọc thời gian block.

Kết luận: contract không lỗi; website chỉ hiện ngày mà không ghi múi giờ và giờ cụ thể. Sau 07:00 giờ Việt Nam, hãy đọc trạng thái lại. Không cần xóa trình duyệt hoặc reconnect ví.

Case 2: Kỳ khóa đã hết nhưng vẫn phải chờ Cooldown

Hiện tượng: kỳ stake 90 ngày đã kết thúc, nút Stake đổi thành Unstake. Người dùng bấm xong nhưng balance vẫn hiện Locked.

Kiểm tra: giao dịch đầu chỉ phát event UnstakeRequested, contract ghi cooldownEnd và không có Token Transfer. Sau bảy ngày, withdrawable trong Read Contract mới chuyển từ 0 thành số tiền gốc.

Kết luận: hết kỳ stake chỉ cho phép bắt đầu thoát. Muốn nhận tiền thật sự cần giao dịch withdraw thứ hai. Không có Token Transfer sau giao dịch đầu là đúng thiết kế.

Case 3: Front end không còn nút nhưng Vesting Contract đã cho Release

Hiện tượng: sau khi dự án nâng cấp website, Dashboard cũ vẫn hiển thị allocation nhưng không có nút Claim.

Kiểm tra: Docs mới nhất công bố Vesting Proxy. Trong Read as Proxy, beneficiary đúng bằng địa chỉ người dùng, releasable(token) lớn hơn 0 và released(token) nhỏ hơn vestedAmount. Announcement chính thức xác nhận cổng mới dùng release(token).

Xử lý: ưu tiên front end chính thức mới. Nếu dự án xác nhận có thể thao tác trên block explorer, hãy kiểm tra Proxy, network, Token Contract và kết quả simulation trước khi dùng Write as Proxy. Đừng dùng “trang sửa lỗi Claim phiên bản cũ” xuất hiện trong quảng cáo tìm kiếm.

Front end vẫn hiện Locked nhưng on-chain đã unlock: loại trừ lỗi trình duyệt thế nào?

Chỉ khi Read Contract xác nhận unlockTime đã tới và releasable lớn hơn 0 mà trang chính thức vẫn báo Locked, lỗi mới có khả năng nằm ở trình duyệt, RPC hoặc lớp dữ liệu front end. Hãy thử đối chiếu theo thứ tự:

1. ngắt quyền kết nối ví của dApp;
2. đóng các tab khác của cùng dự án;
3. chỉ xóa Cookie, Local Storage và cache của đúng domain đó;
4. chỉ bật một wallet extension để tránh xung đột Provider;
5. chuyển sang RPC ổn định được dự án hỗ trợ;
6. kiểm tra lỗi 403, 429, CORS, RPC và Indexer trong Console và Network;
7. tái hiện trong Browser Profile riêng rồi lưu ảnh, thời gian và lỗi.

MostLogin phù hợp để tạo môi trường cô lập và tái hiện lỗi trong trường hợp này: tạo Profile riêng cho từng dự án, tách Session và Wallet Extension, ghi lại cấu hình Proxy/RPC và giữ operation log cho team. Nó giúp xác nhận tình huống “on-chain đã unlock nhưng front end đọc sai”, nhưng không thể sửa unlockTime, bỏ qua Cooldown, gỡ trạng thái Pause hoặc ép contract của dự án trả tiền.

Dùng MostLogin để tạo Profile riêng cho việc troubleshoot stake Web3

Danh sách thao tác rủi ro: đừng thử các “cách mở khóa” này

• không cấp quyền điều khiển từ xa hoặc chia sẻ màn hình cho “admin” chủ động nhắn DM;
• không nhập seed phrase vào trang Sync Wallet hoặc Validate Wallet;
• không gọi emergencyWithdraw, rescue hoặc migrate chỉ dựa vào tên hàm;
• không gửi giao dịch tới Implementation trong khi bỏ qua Proxy thật;
• không ký Unlimited Approval hoặc Permit không hiểu rõ chỉ để “unlock”;
• không dùng proxy để lách giới hạn khu vực hoặc identity mà dự án công bố;
• không tin dịch vụ lạ hứa “khôi phục allocation” hoặc mở vesting sớm;
• không coi thông báo Success trên front end là thành công on-chain nếu chưa kiểm tra TxHash.

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

Hết hạn stake rồi, token có tự quay về ví không?

Không phải lúc nào cũng vậy. Nhiều contract chỉ dừng tính reward hoặc cho phép thoát sau khi hết hạn; người dùng vẫn phải chủ động gọi unstake, withdraw, exit, release hoặc claim. Có tự chi trả hay không phải xem logic contract, event và hướng dẫn chính thức.

Ngày unlock trên front end khác unlockTime trong contract thì tin cái nào?

Việc thực thi on-chain phụ thuộc vào state của contract và thời gian block. Front end có thể sai do chuyển múi giờ, nhầm giây với mili giây, cache hoặc Indexer chậm. Hãy đọc trường thời gian trong contract rồi đổi sang UTC và giờ Việt Nam.

Tại sao Unstake thành công rồi mà vẫn hiện Locked?

Unstake có thể chỉ tạo yêu cầu thoát và bắt đầu Cooldown, chưa chuyển tiền gốc. Hãy kiểm tra event, cooldownEnd, withdrawalTime và withdrawable, đồng thời xác nhận có cần giao dịch withdraw hoặc claim thứ hai không.

releasable trả về 0 có nghĩa là tài sản đã mất không?

Chưa thể kết luận. Giá trị 0 có thể do chưa tới Cliff, đã nhận hết, truy vấn nhầm Token Contract, contract chưa được nạp tiền, địa chỉ không phải beneficiary hoặc giao thức dùng flow nhận khác. Cần xem cùng balance, released, vestedAmount và event.

Có thể rút trực tiếp bằng Write Contract trên Etherscan không?

Chỉ nên cân nhắc sau khi đã xác nhận địa chỉ contract chính thức, đúng network, quan hệ Proxy, tham số hàm và hướng dẫn thao tác từ dự án. Trước hết phải dùng Read Contract để kiểm tra state và chạy simulation. Đừng gọi bất kỳ hàm nào bạn không hiểu.

Giao dịch bị Reverted nhưng trang không ghi lý do thì làm gì?

Dán TxHash vào block explorer của đúng network rồi kiểm tra Status, Revert Reason, Custom Error, Input Data và event. Các lỗi thường gặp gồm StillLocked, CooldownNotFinished, NothingToClaim, Paused, InvalidPosition và NotBeneficiary.

Đổi trình duyệt hoặc dùng MostLogin có unlock sớm được không?

Không. Browser Profile chỉ giúp loại trừ lỗi Session trên front end, xung đột extension, RPC và cấu hình môi trường. Nó không thể thay đổi điều kiện block.timestamp, Cooldown, Vesting Curve hoặc trạng thái admin trong contract.

Token đã unlock nhưng tại sao vẫn không bán được?

Unlock chỉ có nghĩa token được phép rời contract lưu ký. Không bán được còn có thể do giới hạn Transfer, blacklist/whitelist, thiếu thanh khoản, nhầm Token Contract, chưa mở giao dịch hoặc tài sản vẫn nằm trong Vesting/Staking Contract khác.

Kết luận: đừng chỉ hỏi “đã tới ngày chưa”, hãy hỏi “contract hiện cho phép làm gì”

Khi hết hạn stake nhưng tài sản vẫn Locked, cách hiệu quả nhất không phải refresh trang liên tục mà là dựng đủ chuỗi bằng chứng on-chain: Stake TxHash ban đầu, contract đang giữ tiền, quan hệ Proxy, unlockTime, thời gian block hiện tại, releasable, các bước thoát và Claim TxHash cuối cùng. Chỉ cần trả lời được bốn câu hỏi “tiền ở đâu, khi nào được release, hàm nào release và giao dịch đã thực thi chưa”, phần lớn lỗi khóa tài sản đều có thể được phân loại rõ.

Trong nghiên cứu các cộng đồng Web3 Discord nói tiếng Hoa vào tháng 8/2026, dự án này thực sự ghi nhận các phản ánh như hết hạn khóa nhưng không unlock được, không tìm thấy cổng rút và token không bán được. Điều đó cho thấy công cụ có giá trị không phải thứ hứa “tự động unlock”, mà là công cụ giúp cô lập môi trường, kiểm tra state on-chain, lưu lịch sử thao tác và gửi bằng chứng có thể tái hiện cho support.

Tài liệu kỹ thuật chính thức: Solidity: block.timestamp và đơn vị thời gian, OpenZeppelin: VestingWallet, Etherscan: sử dụng Read/Write Contract an toàn, MetaMask: xử lý giao dịch contract thất bại.

Đọc thêm: Ví kết nối thành công nhưng không Claim được Airdrop, Airdrop báo Eligible nhưng không Claim được: 12 bước xử lý