Phương pháp nghiên cứu

Ai có quyền phát hành thêm token? Cách kiểm tra quyền mint

Lịch vesting không cho biết ai có thể tạo thêm token mới. Bài viết hướng dẫn tự kiểm tra quyền mint của một token trên Solana qua trường mint authority và trên chuỗi EVM qua lớp kiểm soát truy cập của hợp đồng, kèm ba câu hỏi phải trả lời trước khi kết luận nguồn cung đã cố định.

Ai có quyền phát hành thêm token? Cách kiểm tra quyền mint

Lịch vesting chỉ nói về số token đã tồn tại trên giấy tờ. Nó không trả lời một câu hỏi khác, thường quan trọng hơn: liệu có ai đó có thể tạo ra token hoàn toàn mới, ngoài mọi bảng phân bổ bạn vừa đọc hay không. Đó là quyền mint, và nó được ghi trong hợp đồng chứ không nằm trong tài liệu marketing.

Bài này mô tả cách tự kiểm tra quyền mint của một token trên Solana và trên các chuỗi EVM, cùng những câu hỏi phải trả lời trước khi kết luận "nguồn cung cố định". Bài không dự báo giá và không coi việc tồn tại quyền mint là dấu hiệu xấu — nhiều loại token buộc phải có quyền này để hoạt động.

Quyền mint khác lịch mở khóa ở chỗ nào

Mở khóa là chuyển token đã được tạo từ trạng thái bị khóa sang trạng thái có thể chuyển nhượng. Tổng cung không đổi, chỉ phần lưu hành thay đổi. Mint là tạo thêm token mới: tổng cung tăng, và phần sở hữu của mọi người nắm giữ hiện tại bị pha loãng theo tỷ lệ tương ứng.

Hai việc này do hai cơ chế khác nhau kiểm soát. Lịch vesting nằm trong hợp đồng vesting hoặc trong ví của đội ngũ; quyền mint nằm trong chính hợp đồng token. Một dự án có lịch vesting rất đẹp vẫn có thể giữ quyền mint không giới hạn, và ngược lại.

Trên Solana: đọc trường mint authority

Solana thuận lợi cho việc kiểm tra này vì Token Program định nghĩa sẵn một cấu trúc chuẩn. Tài liệu chính thức mô tả mint account gồm các trường cố định, trong đó có mint_authority.

Tài liệu Solana mô tả cấu trúc Mint với trường mint_authority, supply, decimals và freeze_authority

Ảnh chụp trang Create a Token Mint trên solana.com ngày 13/10/2026.

Phần chú thích trong mã nguồn nói rõ: mint_authority là quyền tùy chọn dùng để mint token mới, chỉ có thể được gán khi tạo mint, và nếu mint account không có mint authority thì nguồn cung là cố định, không thể mint thêm token nữa. Cùng cấu trúc đó còn có freeze_authority — quyền đóng băng tài khoản token, một quyền khác cũng đáng ghi lại.

Cách kiểm tra trong thực tế:

  1. Lấy địa chỉ mint của token. Đây là định danh duy nhất của token trên Solana; ví dụ tài liệu dùng chính USDC với mint EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v.
  2. Mở địa chỉ mint đó trên trình duyệt chuỗi, hoặc gọi RPC getAccountInfo với tham số jsonParsed. Kết quả hiển thị mintAuthority, freezeAuthority, supply và decimals.
  3. Nếu mintAuthority là null, nguồn cung đã bị chốt ở cấp hợp đồng. Nếu có một địa chỉ, đó chính là địa chỉ có thể in thêm token bất cứ lúc nào.
  4. Khi thấy một địa chỉ, công việc chưa xong: tra tiếp địa chỉ đó là ví đơn, multisig hay chương trình. Ba trường hợp này có mức độ ràng buộc hoàn toàn khác nhau.

Lưu ý thêm: quyền mint có thể được chuyển hoặc gỡ bỏ bằng lệnh SetAuthority của Token Program, nên kết quả bạn thấy hôm nay là trạng thái tại thời điểm kiểm tra. Hãy ghi lại ngày kiểm tra. Với token dùng chuẩn Token-2022, cần kiểm tra thêm phần extension vì nó có thể bổ sung hành vi không có trong Token Program gốc.

Trên EVM: không có trường chuẩn, phải đọc hợp đồng

Chuẩn ERC-20 không định nghĩa hàm mint. Vì vậy trên Ethereum và các chuỗi EVM, không tồn tại một ô dữ liệu cố định để tra. Quyền mint, nếu có, là do người viết hợp đồng tự thêm vào, và nó gần như luôn đi kèm một lớp kiểm soát truy cập.

Trang tài liệu Access Control của OpenZeppelin giải thích kiểm soát truy cập quyết định ai được phép mint token

Ảnh chụp docs.openzeppelin.com ngày 13/10/2026; trang mở đầu bằng đúng câu hỏi "ai được phép làm việc này".

Tài liệu OpenZeppelin nêu thẳng rằng kiểm soát truy cập của hợp đồng có thể quyết định ai được mint token, bỏ phiếu đề xuất hay đóng băng chuyển khoản. Hai mô hình phổ biến nhất là Ownable — một tài khoản owner duy nhất làm mọi việc quản trị — và AccessControl theo vai trò, nơi quyền mint thường được gắn vào một vai trò riêng.

Trình tự kiểm tra trên trình duyệt chuỗi:

  1. Mở tab mã nguồn của hợp đồng token. Nếu mã chưa được xác minh, dừng lại: bạn không có cách nào đọc được logic, và riêng điều đó đã là một kết luận.
  2. Tìm trong mã các hàm có thể làm tăng tổng cung — tên thường gặp là mint, _mint, issue. Đọc modifier đi kèm để biết ai gọi được: onlyOwner, onlyRole(...) hay một điều kiện khác.
  3. Dùng tab đọc hợp đồng để lấy giá trị thực tế: owner() trả về địa chỉ đang nắm quyền, hasRole() cho biết một địa chỉ có vai trò hay không.
  4. Kiểm tra xem có trần cung hay không. Phần mở rộng dạng capped đặt một giới hạn cứng cho tổng cung, và đây là khác biệt lớn giữa "có thể mint" và "có thể mint vô hạn".
  5. Kiểm tra hợp đồng có phải proxy nâng cấp được không. Nếu có, logic hôm nay không ràng buộc logic ngày mai, nên quyền quản trị proxy cũng là một dạng quyền mint tiềm năng.
  6. Tra địa chỉ đang nắm quyền: ví đơn, multisig bao nhiêu chữ ký, hay hợp đồng timelock có độ trễ.

Quy trình đọc hợp đồng chi tiết hơn, gồm cách lần ra hợp đồng liên quan từ địa chỉ token, nằm trong bài cách đọc hợp đồng vesting trên blockchain explorer.

Ba câu hỏi trước khi viết "nguồn cung cố định"

Ai giữ quyền? Một ví đơn do một người kiểm soát, một multisig 5/9 và một timelock 48 giờ cho ra ba mức rủi ro vận hành khác nhau, dù trên giấy đều là "có quyền mint".

Quyền đó có thể đổi chủ không? Chuyển quyền sở hữu hoặc gán lại authority thường chỉ là một giao dịch. Kết luận của bạn luôn gắn với một ngày cụ thể.

Việc dùng quyền có cần công bố trước không? Nếu dự án có quản trị trên chuỗi, mỗi lần tăng cung sẽ để lại dấu vết đọc được từ trước; cách lần theo dấu vết đó được mô tả trong bài cách đọc đề xuất quản trị để biết nguồn cung token sắp thay đổi. Nếu không, bạn chỉ biết sau khi việc đã rồi.

Có quyền mint không đồng nghĩa với dự án xấu

Stablecoin được bảo chứng bắt buộc phải mint và burn liên tục để khớp với lượng tài sản dự trữ; token của giao thức có phần thưởng staking cũng cần phát hành đều đặn theo quy tắc. Vấn đề không nằm ở sự tồn tại của quyền mint, mà ở chỗ quyền đó có bị ràng buộc bởi trần cung, quy trình quản trị và độ trễ hay không — và dự án có công bố đúng như những gì hợp đồng cho phép hay không.

Khi ghi kết quả, hãy tách thành ba cột riêng: quyền có tồn tại không, ai giữ, và ràng buộc nào đang áp lên nó. Ba cột này ghép với lịch vesting mới thành bức tranh nguồn cung đầy đủ; phần còn lại của việc rà soát trước khi mua nằm trong danh sách 12 mục cần kiểm tra trước khi mua token.

Cuối cùng, kiểm tra quyền mint không dự báo được giá và cũng không nói trước rằng quyền đó sẽ được dùng. Nó chỉ cho bạn biết điều gì có thể xảy ra mà không cần xin phép bạn.