Token utility là tập hợp chức năng mà một token đảm nhiệm trong sản phẩm hoặc hệ sinh thái blockchain. Token có thể được dùng để thanh toán phí, truy cập dịch vụ, thế chấp, nhận ưu đãi, tham gia quản trị hoặc điều phối các bên trong mạng lưới.
Tuy nhiên, việc dự án liệt kê nhiều tiện ích không đồng nghĩa token có nhu cầu sử dụng thực. Câu hỏi quan trọng hơn là: nếu loại token khỏi hệ thống, sản phẩm có còn vận hành và người dùng có mất quyền lợi thiết yếu nào không?
Token utility là gì?
Token utility, hay tiện ích token, mô tả những việc người dùng có thể hoặc phải làm với token trong một sản phẩm. Một số nhóm tiện ích thường gặp gồm:
- Thanh toán: dùng token để trả phí giao dịch, mua dịch vụ hoặc thanh toán tài nguyên.
- Truy cập: nắm giữ hoặc khóa token để sử dụng một tính năng, tham gia cộng đồng hay mở cấp dịch vụ.
- Quản trị: biểu quyết đề xuất, phân bổ ngân quỹ hoặc thay đổi tham số của giao thức.
- Bảo mật và thế chấp: khóa token để vận hành hạ tầng, bảo đảm nghĩa vụ hoặc chịu phạt khi có hành vi sai phạm.
- Khuyến khích: thưởng token cho người dùng, nhà cung cấp thanh khoản, nhà phát triển hoặc bên vận hành mạng.
- Đại diện tài sản hay quyền lợi: token phản ánh quyền đối với một tài sản, vị thế trong giao thức hoặc quyền nhận lợi ích được quy định rõ.
Cần phân biệt token utility với lời hứa về giá. Kỳ vọng token tăng giá, được niêm yết hoặc có chương trình staking lãi suất cao không tự tạo ra tiện ích. Tiện ích phải gắn với một hành động cụ thể trong sản phẩm và có thể kiểm chứng.
Tiện ích token khác nhu cầu sử dụng token thế nào?
Tiện ích token trả lời câu hỏi token có thể dùng để làm gì. Nhu cầu sử dụng token trả lời câu hỏi có bao nhiêu lý do thực tế khiến người dùng phải mua, giữ, khóa hoặc chi tiêu token.
Ví dụ, một dự án có thể cho phép thanh toán bằng token nhưng đồng thời chấp nhận stablecoin, thẻ ngân hàng hoặc tự động chuyển đổi tài sản ở phía sau. Trong trường hợp này, chức năng thanh toán tồn tại nhưng nhu cầu mua token có thể yếu.
Khi đánh giá nhu cầu, cần xem xét:
- Người dùng có bắt buộc sở hữu token hay chỉ được giảm phí khi dùng token?
- Nhu cầu đến từ người dùng sản phẩm hay chủ yếu từ người tham gia đầu cơ và nhận thưởng?
- Token được tiêu thụ, khóa dài hạn hay nhanh chóng quay lại thị trường?
- Sản phẩm có người dùng trước khi phát hành token không?
- Nhu cầu có tiếp tục tồn tại nếu chương trình thưởng token kết thúc?
- Giá trị kinh tế có đi qua token hay chỉ đi vào công ty, ngân quỹ hoặc một tài sản khác?
Một token có thể có nhiều use case trên tài liệu nhưng vẫn thiếu nhu cầu bền vững nếu người dùng không cần chạm vào token trong quá trình sử dụng.
Khung đánh giá token có thực sự cần cho sản phẩm
Có thể đánh giá use case token theo năm lớp dưới đây.
1. Xác định sản phẩm cốt lõi
Trước tiên, hãy mô tả sản phẩm bằng một câu không nhắc đến token. Sản phẩm đang giải quyết vấn đề gì, cho ai và bằng chức năng nào?
Nếu không thể xác định sản phẩm đang hoạt động hoặc giá trị mà nó cung cấp, việc phân tích tokenomics chưa đủ để kết luận token có ích. Whitepaper, lộ trình và video giới thiệu chỉ thể hiện kế hoạch; chúng không thay thế sản phẩm có thể sử dụng.
2. Xác định hành động cần token
Liệt kê từng hành động mà tài liệu dự án cho rằng cần token, chẳng hạn trả phí, bỏ phiếu, thế chấp hoặc mở quyền truy cập. Với mỗi hành động, kiểm tra bốn điểm:
- Hành động đã xuất hiện trong sản phẩm đang hoạt động chưa?
- Hợp đồng thông minh hoặc giao diện có thực sự yêu cầu token không?
- Người dùng có lựa chọn tài sản hoặc phương thức khác không?
- Quyền lợi nhận được có đủ quan trọng để tạo nhu cầu không?
Cụm từ như sẽ tích hợp, dự kiến sử dụng hoặc có thể dùng trong tương lai nên được phân loại là kế hoạch, không phải tiện ích đang hoạt động.
3. Kiểm tra tính bắt buộc
Token có mức độ cần thiết cao hơn khi nó là một phần không thể thay thế của cơ chế vận hành. Ví dụ, tài sản dùng để bảo đảm hành vi của bên vận hành mạng có vai trò khác với token chỉ dùng để nhận ưu đãi nhỏ.
Hãy thử bài kiểm tra loại bỏ: giả sử token không tồn tại, dự án có thể thay nó bằng stablecoin, điểm thưởng trong cơ sở dữ liệu hoặc quyền truy cập theo tài khoản hay không? Nếu có thể thay thế dễ dàng mà sản phẩm gần như không đổi, lý do phát hành token cần được xem xét kỹ hơn.
4. Xác định nguồn cầu và dòng token
Cần phân biệt nguồn cầu sử dụng với nguồn cầu đầu cơ:
| Nguồn cầu | Câu hỏi cần kiểm tra |
|---|---|
| Người dùng sản phẩm | Họ mua token để thực hiện hành động nào? |
| Bên vận hành mạng | Họ có phải khóa hoặc thế chấp token không? |
| Người tham gia quản trị | Lá phiếu có tác động thực tế đến giao thức không? |
| Người nhận thưởng | Họ giữ token hay bán ngay sau khi nhận? |
| Nhà đầu tư | Nhu cầu dựa trên quyền lợi hiện hữu hay kỳ vọng giá? |
Sau đó theo dõi đường đi của token: token được khóa, đốt, đưa vào ngân quỹ, trả cho nhà cung cấp dịch vụ hay quay lại thị trường. Chỉ nhìn vào lượng mua mà bỏ qua nguồn phát hành và áp lực bán có thể dẫn đến đánh giá thiếu cân bằng.
5. Kiểm tra khả năng thu giữ giá trị
Sản phẩm có doanh thu hoặc nhiều người dùng không đồng nghĩa token sẽ hưởng lợi. Cần xác định mối liên hệ cụ thể giữa hoạt động sản phẩm và quyền lợi của token:
- Phí có bắt buộc được trả bằng token không?
- Phí được phân phối cho ai?
- Token có bị đốt hoặc khóa theo cơ chế đã triển khai không?
- Người nắm giữ có quyền hợp pháp hoặc quyền trên giao thức đối với dòng tiền không?
- Cơ chế có thể bị thay đổi bởi đội ngũ hoặc biểu quyết không?
Không nên mặc định doanh thu của dự án là doanh thu của người nắm giữ token. Hai dòng giá trị này có thể hoàn toàn tách biệt.
Cách đối chiếu tài liệu dự án với hoạt động thực tế
Đánh giá token nên bắt đầu từ tài liệu chính thức nhưng không dừng ở đó. Mỗi tuyên bố cần được đối chiếu với bằng chứng có thể quan sát.
| Tuyên bố của dự án | Nội dung cần đối chiếu |
|---|---|
| Token dùng để thanh toán | Màn hình thanh toán, tài sản thực tế được chấp nhận và giao dịch liên quan |
| Token dùng để quản trị | Danh sách đề xuất, số người tham gia, quyền thực thi và cơ chế ủy quyền |
| Token cần để truy cập | Quy trình đăng nhập, điều kiện nắm giữ và các gói không cần token |
| Token dùng để staking | Mục đích staking, nguồn phần thưởng, điều kiện rút và rủi ro bị phạt |
| Token tạo giá trị từ phí | Hợp đồng thu phí, tài sản thu phí và nơi phí được chuyển đến |
| Token bảo mật mạng | Vai trò của bên xác thực, yêu cầu thế chấp và hậu quả khi vi phạm |
Nên ưu tiên kiểm tra sản phẩm công khai, ứng dụng đang hoạt động, tài liệu kỹ thuật, hợp đồng thông minh và lịch sử quản trị. Số người theo dõi mạng xã hội hoặc quy mô cộng đồng không chứng minh token đang được sử dụng.
Dữ liệu on-chain cũng có giới hạn. Một ví có thể thuộc về người dùng, sàn giao dịch, bot hoặc đội ngũ dự án; một địa chỉ hoạt động không nhất thiết tương ứng với một người dùng độc lập. Vì vậy, không nên dùng riêng số ví hoặc số giao dịch để kết luận mức độ chấp nhận sản phẩm.
Kiểm tra người dùng có thể bỏ qua token hay không
Cách nhanh nhất để đánh giá token có bắt buộc sử dụng không là tự đi qua hành trình người dùng.
Kiểm tra từ điểm bắt đầu đến kết quả cuối
Hãy quan sát người dùng cần làm gì để nhận giá trị từ sản phẩm:
- Truy cập ứng dụng hoặc giao thức.
- Kết nối ví hay tạo tài khoản.
- Chọn dịch vụ chính.
- Thanh toán hoặc cung cấp tài sản.
- Nhận kết quả cuối cùng.
Ở mỗi bước, kiểm tra token có xuất hiện hay không. Nếu giao diện tự động hoán đổi stablecoin sang token ở phía sau, người dùng có thể không tạo ra nhu cầu nắm giữ lâu dài. Nếu token chỉ cần cho tính năng phụ trong khi chức năng chính không cần token, nên ghi nhận phạm vi tiện ích bị giới hạn.
Các đường vòng thường gặp
- Thanh toán trực tiếp bằng stablecoin hoặc tiền pháp định.
- Dùng phiên bản miễn phí mà không mất phần lớn chức năng cốt lõi.
- Mua dịch vụ qua bên trung gian không yêu cầu token.
- Nhận quyền truy cập bằng NFT, tài khoản hoặc điểm thưởng.
- Sử dụng một giao thức khác có chức năng tương đương nhưng không phát hành token.
- Ủy quyền cho dịch vụ khác mua token tức thời rồi bán lại, thay vì tự nắm giữ.
Đường vòng không luôn là điểm xấu. Việc giảm ma sát có thể giúp sản phẩm dễ sử dụng hơn. Tuy nhiên, nó làm suy yếu luận điểm cho rằng tăng trưởng người dùng chắc chắn tạo ra nhu cầu mua và giữ token.
Đánh giá token quản trị và token thanh toán
Token quản trị
Token quản trị có ích khi người nắm giữ được tham gia vào các quyết định có ảnh hưởng thực tế. Khi phân tích mô hình quản trị của một giao thức như Compound Finance, cần kiểm tra ai có quyền gửi đề xuất, biểu quyết thay đổi điều gì và kết quả có được thực thi trên chuỗi hay vẫn phụ thuộc vào một nhóm kiểm soát.
Các câu hỏi quan trọng gồm:
- Phạm vi quyết định của cộng đồng là gì?
- Ngưỡng gửi đề xuất có khiến phần lớn người dùng không thể tham gia không?
- Quyền biểu quyết có tập trung vào đội ngũ, nhà đầu tư sớm hoặc một số ví lớn không?
- Người nắm giữ có thể ủy quyền phiếu bầu không?
- Quyết định được hợp đồng thực thi hay cần một bên ký xác nhận?
- Quản trị có liên quan đến sản phẩm hay chủ yếu là bỏ phiếu cho các chương trình khuyến khích?
Quyền biểu quyết chỉ có giá trị khi đối tượng được quản trị đáng kể và quy trình có khả năng tạo ra thay đổi. Một diễn đàn thảo luận không đồng nghĩa với quyền kiểm soát giao thức.
Token thanh toán
Đối với token thanh toán, hãy kiểm tra lý do sản phẩm không thể dùng một tài sản phổ biến và ổn định hơn. Token riêng có thể hợp lý khi nó đảm nhiệm thêm chức năng kỹ thuật hoặc điều phối kinh tế mà phương thức thanh toán thông thường không đáp ứng.
Ngược lại, nếu token chỉ là bước trung gian bắt buộc để mua một dịch vụ có giá niêm yết theo tiền pháp định hoặc stablecoin, người dùng phải chịu thêm thao tác và biến động giá mà chưa chắc nhận được lợi ích tương ứng.
Cũng cần phân biệt token thanh toán với đồng tiền mã hoá có mạng lưới độc lập. Chẳng hạn, việc tìm hiểu Bitcoin là gì và cách mạng lưới vận hành cần tập trung vào vai trò của tài sản gốc trong chuyển giao giá trị và bảo mật mạng, thay vì áp dụng máy móc khung đánh giá token của một ứng dụng.
Dấu hiệu token chủ yếu phục vụ huy động vốn
Không thể kết luận động cơ của dự án chỉ từ một dấu hiệu. Tuy nhiên, mức độ thận trọng nên tăng khi nhiều biểu hiện sau xuất hiện cùng lúc:
- Token được bán trước khi có sản phẩm hoặc bằng chứng về nhu cầu.
- Tài liệu dành nhiều nội dung cho phân bổ, niêm yết và lợi nhuận nhưng mô tả use case mơ hồ.
- Tiện ích chủ yếu nằm trong lộ trình, chưa có trong phiên bản đang hoạt động.
- Người dùng có thể sử dụng toàn bộ sản phẩm mà không cần token.
- Staking chỉ tạo thêm token từ phát hành mới, không gắn với bảo mật hay hoạt động kinh tế rõ ràng.
- Phần thưởng token là động lực chính kéo người dùng vào sản phẩm.
- Đội ngũ có quyền thay đổi nguồn cung, phí hoặc quyền lợi mà thiếu cơ chế kiểm soát minh bạch.
- Nguồn cung lưu hành ban đầu thấp trong khi lượng token chưa lưu hành lớn.
- Marketing nhấn mạnh giá, lợi nhuận hoặc khan hiếm hơn giá trị của sản phẩm.
- Token không có quyền rõ ràng đối với doanh thu, tài sản hay quyết định quản trị quan trọng.
Khi nguồn cung lưu hành thấp, chỉ nhìn vốn hóa hiện tại có thể đánh giá chưa đầy đủ quy mô định giá. Việc so sánh FDV và vốn hóa lưu hành giúp nhận diện phần nguồn cung chưa đi vào thị trường, nhưng FDV cũng không phải dự báo chắc chắn về giá trị tương lai.
Ngoài tổng cung, cần xem thời điểm token của đội ngũ, nhà đầu tư và ngân quỹ có thể được đưa vào lưu hành. Phân tích lịch mở khóa token giúp bổ sung góc nhìn về áp lực cung; nó không tự chứng minh bên nhận token sẽ bán.
Quy trình đánh giá use case token trước khi mua
Có thể sử dụng quy trình ngắn sau để tránh bị thuyết phục chỉ bởi danh sách tiện ích trong whitepaper.
Bước 1: Viết lại luận điểm của dự án
Tóm tắt ba nội dung: sản phẩm tạo ra giá trị gì, ai sử dụng và token tham gia vào khâu nào. Nếu không thể diễn đạt rõ ràng, nên tiếp tục nghiên cứu trước khi định giá token.
Bước 2: Phân loại trạng thái của từng tiện ích
Mỗi use case nên được xếp vào một trong các trạng thái:
- Đang hoạt động và có thể kiểm chứng.
- Đã triển khai nhưng mức sử dụng chưa rõ.
- Đang thử nghiệm.
- Chỉ có trong kế hoạch.
- Không tìm thấy bằng chứng.
Cách phân loại này tránh việc đánh đồng lời hứa tương lai với chức năng hiện tại.
Bước 3: Thực hiện bài kiểm tra loại bỏ token
Đặt câu hỏi: nếu thay token bằng stablecoin, điểm thưởng hoặc cơ sở dữ liệu thông thường, sản phẩm có mất tính năng cốt lõi không? Ghi rõ phần nào bị ảnh hưởng thay vì chỉ trả lời có hoặc không.
Bước 4: Xác định người mua tự nhiên
Người mua tự nhiên là người cần token để sử dụng, vận hành hoặc bảo vệ hệ thống, không chỉ vì kỳ vọng bán lại với giá cao hơn. Nếu không xác định được nhóm này, nhu cầu token có thể phụ thuộc nhiều vào đầu cơ hoặc phần thưởng.
Bước 5: Theo dõi cả cung và cầu
Đối chiếu nhu cầu sử dụng với phát hành mới, phần thưởng, mở khóa và lượng token do các bên lớn nắm giữ. Nhu cầu tăng không bảo đảm giá tăng nếu nguồn cung có thể bán ra tăng nhanh hơn.
Bước 6: Kiểm tra rủi ro sử dụng hợp đồng
Khi tương tác với ứng dụng, người dùng có thể phải cấp quyền cho hợp đồng chi tiêu token trong ví. Cần đọc kỹ tài sản, hạn mức và địa chỉ được cấp quyền; hướng dẫn về token approval vô hạn giúp nhận biết rủi ro khác với bản thân use case kinh tế của token.
Bước 7: Ghi rõ điều chưa xác minh
Nếu thiếu dữ liệu về người dùng, doanh thu, hợp đồng hoặc quản trị, kết luận phù hợp là chưa đủ bằng chứng. Không nên biến sự thiếu minh bạch thành giả định tích cực hoặc tiêu cực tuyệt đối.
Có thể chốt đánh giá bằng bốn mức định tính:
- Thiết yếu: token khó bị thay thế mà không làm thay đổi cơ chế cốt lõi.
- Hữu ích: token tạo lợi ích rõ ràng nhưng sản phẩm vẫn có thể vận hành nếu thiếu nó.
- Phụ trợ: token chủ yếu mang lại ưu đãi, phần thưởng hoặc quyền truy cập giới hạn.
- Chưa chứng minh: tiện ích mới nằm trong tài liệu hoặc không có dữ liệu sử dụng đủ để kiểm chứng.
Kết luận
Hiểu token utility là gì không chỉ là đọc danh sách công dụng trong whitepaper. Một đánh giá use case token đáng tin cậy phải kết nối ba yếu tố: sản phẩm đang hoạt động, hành vi người dùng có thể quan sát và vai trò không dễ thay thế của token.
Token có tiện ích thực chưa chắc là khoản đầu tư tốt; token quản trị cũng không mặc nhiên có quyền đối với doanh thu. Trước khi đưa ra quyết định, hãy kiểm tra token có bắt buộc sử dụng không, người dùng có đường vòng nào, nhu cầu đến từ đâu và nguồn cung tương lai có thể ảnh hưởng thế nào. Nếu tiện ích chưa triển khai hoặc dữ liệu không đủ, nên coi đó là một giả thuyết cần xác minh thay vì một sự thật đã được chứng minh.
