Token Design là gì? #6

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Token Design là việc thiết kế purpose, actors, rights, dòng token và quyền kiểm soát thành một hệ thống hoàn chỉnh. Nó trả lời token dùng để phối hợp hành vi nào, được tạo và sử dụng ra sao, ai sửa được luật và hệ thống có thể hỏng ở đâu; ticker, tổng cung hay burn riêng lẻ chưa đủ.

Đọc xong, bạn sẽ hiểu:

• Vì sao token standard không phải token design.
• Cách nối purpose, actors, rights, source, sink và permissions.
• Cách điền Token Design Canvas và stress-test một hệ thống giả mà không dùng tiền thật.

1. Token Design bắt đầu từ hệ thống, không từ ticker

a. Token là một mảnh của hệ thống

Một token là bản ghi on-chain hoạt động theo rules của smart contract hoặc protocol. Nó có thể được chuyển, dùng để yêu cầu một dịch vụ, biểu quyết hoặc đại diện một claim tùy thiết kế. Bản thân chuỗi ký hiệu và số dư chưa nói token hữu ích cho ai.

Token Design rộng hơn việc chọn tên, ticker, logo và tổng cung. Nó phải chỉ ra mối nối giữa năm phần:

1. Purpose: vấn đề phối hợp nào cần giải?
2. Actors + rights: ai tham gia và mỗi nhóm được làm gì?
3. Source + sink: token đi vào, lưu thông và rời vòng lặp thế nào?
4. Permissions: ai có quyền mint, pause, upgrade hoặc đổi rule?
5. Failure modes: mechanism hỏng, bị game hoặc mất cân bằng ở đâu?

Thiếu một phần, bức tranh có thể đẹp nhưng chưa vận hành được. Có utility ghi trên website cũng chưa chứng minh có người cần dùng utility đó.

Hình 1 — Token Design bắt đầu từ hệ thống quyền và dòng hành vi; ticker, logo và giá không thay thế năm câu hỏi cốt lõi.

b. Purpose phải là một việc cụ thể

Purpose là vấn đề phối hợp cụ thể token được giao giải quyết. “Xây community” quá rộng. “Phân phối quyền yêu cầu review cho learner và trả reward cho review đã được xác minh” cụ thể hơn: có actor, action và outcome.

Actor là người hoặc hệ thống có hành động và quyền riêng. Trong nền tảng học giả định LEARN, actors gồm learner, reviewer, treasury và admin multisig. Learner cần review; reviewer cung cấp công sức; treasury nhận một phần phí; admin giữ quyền vận hành nhạy cảm.

Purpose tốt không bắt đầu bằng “làm token khan hiếm”. Khan hiếm là thuộc tính supply, không phải vấn đề của người dùng. Câu hỏi đầu tiên là hệ thống tạo hoặc phân phối dịch vụ nào.

c. Remove-token test

Hãy bỏ token khỏi sơ đồ và hỏi: sản phẩm có chạy y hệt bằng database points hay thanh toán thông thường không? Đây là remove-token test.

Nếu câu trả lời là có, token có thể chỉ thêm độ phức tạp, phí và rủi ro permission. Điều đó không tự kết luận dự án xấu; nó buộc team nêu lợi ích riêng của token, chẳng hạn composability, quyền tự giữ, settlement chung giữa nhiều bên hoặc governance có thể kiểm chứng.

Ví như vé giữ xe: tờ vé hữu ích vì bãi xe, quy trình giao nhận và quyền lấy đúng xe tồn tại. In vé đẹp hơn không tạo thêm chỗ đậu. Token cũng vậy: nó mang rule của hệ thống, không tự sinh sản phẩm hay nhu cầu.

2. Token standard không phải economic design

a. Standard trả lời app gọi token thế nào

Token standard là giao diện chung để ví, app và contract biết cách tương tác. EIP-20 định nghĩa các method như totalSupply, balanceOf, transfer, approve, allowance và các events liên quan (EIP-20).

Nhờ interface chung, một wallet có thể đọc balance và một app có thể gọi transfer mà không học lại API riêng của từng token. Ethereum.org mô tả ERC-20 là standard cho fungible tokens và nhấn mạnh interoperability với sản phẩm khác (Ethereum.org).

Fungible nghĩa mỗi đơn vị cùng loại thay thế được cho đơn vị khác trong balance/interface. Nó không có nghĩa mọi token ERC-20 có cùng rủi ro, quyền hoặc economic value.

Allowance là hạn mức owner cho một spender dùng thay mình. Đây là permission ở cấp sử dụng balance, không phải quyền admin của cả protocol.

b. Standard không quyết định supply mechanism

Hai token có thể cùng ERC-20 nhưng khác hoàn toàn:

• Token A fixed supply, không có minter sau deploy.
• Token B có role mint thêm theo reward schedule.
• Token C cho phép admin pause transfer.
• Token D gắn voting snapshots và delegation.

EIP-20 cho biết totalSupply() trả về supply, nhưng không bắt buộc supply được tạo theo lịch nào, ai nhận allocation hoặc ai có quyền mint sau này. Standard cũng không định nghĩa vesting, revenue, burn route, governance quorum hay product demand.

Ví như chuẩn ổ cắm: nó giúp thiết bị cắm vừa, nhưng không quyết định căn nhà dùng điện cho tủ lạnh hay máy đào, ai trả hóa đơn và cầu dao tổng nằm trong tay ai.

Hình 2 — Standard tạo khả năng tương tác kỹ thuật; Token Design bổ sung các rule kinh tế, quyền và kiểm soát mà interface không quyết định.

c. Implementation cũng chưa phải outcome

Implementation là code cụ thể hiện thực standard và extensions. Code có thể cho phép mint, burn, pause hoặc vote. Tuy nhiên, một function tồn tại chưa nói actor sẽ dùng nó thế nào hoặc outcome có tốt không.

Ví dụ, function burn có thể giảm total supply khi được gọi. Nhưng muốn biết mechanism có ý nghĩa, ta còn phải hỏi token burn đến từ ai, đổi lấy việc gì, tần suất nào và ai chịu cost. “Có burn” không tự chứng minh demand hoặc value capture.

Tương tự, token có voting extension chưa đủ để gọi hệ thống community-governed. Cần biết voting power đến từ đâu, ai tạo proposal, quorum bao nhiêu, execution đi qua contract nào và admin có đường tắt không.

3. Ghép purpose, actors, rights và value flow

a. Đi từ outcome ngược về token rule

Một chuỗi thiết kế dễ kiểm tra là:

Problem → Actor action → Token rule → Measurable outcome

Với LEARN giả định:

• Problem: learner chờ lâu vì thiếu review có chất lượng.
• Action: learner gửi request; reviewer hoàn tất review đã được xác minh.
• Token rule: request cần 10 LEARN; reviewer nhận reward theo quality gate.
• Outcome: review hoàn tất trong SLA và đạt quality score.

Right là việc holder được phép yêu cầu hoặc làm trong system. Giữ 10 LEARN có thể cho quyền mở một request, nhưng không mặc nhiên là quyền sở hữu doanh nghiệp, lợi nhuận hoặc tài sản ngoài chain.

Mỗi right cần đối tác thực hiện. Nếu holder có “quyền review” nhưng không reviewer nào nhận việc, token balance không tạo dịch vụ. Vì vậy, design phải mô tả cả payer lẫn provider.

b. Source, circulation và sink

Source là nơi token đi vào circulation: initial allocation, reward issuance, treasury distribution hoặc purchase route. Issuance là rule tạo/phát hành token theo thời gian.

Sink là cơ chế rút token khỏi circulation hoặc khỏi use loop. Burn là một sink vĩnh viễn; lock, fee-to-treasury hoặc stake có thể là sink tạm thời/tái lưu thông, tùy rule.

Trong LEARN:

• Reviewer reward tối đa 1.000 LEARN mỗi tuần.
• Learner dùng 10 LEARN để mở một review request.
• Trong 10 đó, 5 bị burn và 5 vào treasury.

Đây là flow rule, chưa phải bằng chứng hệ thống cân bằng. Nếu chỉ có 20 requests/tuần, sink/burn là 100 và treasury nhận 100, trong khi reward source có thể đưa 1.000 vào circulation. Net flow giả định là +800 trước các route khác.

Net flow = Sources - Sinks khỏi circulation

Phải tách stock (balance đang tồn tại) khỏi flow (amount đi qua mỗi kỳ). Tổng cung tối đa 1 triệu không nói tuần này supply thay đổi bao nhiêu.

Hình 3 — Source-flow-sink map buộc design chỉ ra token đến từ đâu, phục vụ hành động nào và kết thúc ở route nào.

c. Người trả, người hưởng và metric

Token loop cần nêu đủ ba vai:

• Người trả cost: learner mất 10 LEARN/request.
• Người tạo service: reviewer dùng thời gian và nhận reward.
• Người hưởng system benefit: learner nhận review; treasury có resource vận hành.

Nếu reward tính theo số review, actor có thể chia nhỏ hoặc tạo review rác. Metric gaming là tối ưu con số đo thay vì outcome thật. Chuyển reward sang “review verified + quality score + SLA” giảm một lối game, nhưng lại tạo câu hỏi ai xác minh và người xác minh có incentive gì.

Không có mechanism miễn phí. Mỗi guardrail thêm permission, cost hoặc delay. Token Design tốt không che trade-off; nó ghi rõ trade-off để test.

4. Permissions, governance và failure modes

a. Ai giữ các chìa khóa nhạy cảm?

Access control là rule xác định ai gọi được chức năng nhạy cảm. OpenZeppelin nêu các quyền như mint, freeze transfer và upgrade là ví dụ điển hình cần kiểm soát bằng owner hoặc roles (OpenZeppelin Access Control).

Một permission map cần liệt kê:

• Ai mint và cap được enforce ở code hay policy?
• Ai pause/unpause?
• Ai grant/revoke minter, admin và guardian?
• Ai upgrade contract hoặc đổi address phụ thuộc?
• Ai chuyển treasury?
• Có delay, multisig, monitoring và emergency path nào?

Minter là role có thể tạo token theo function cho phép. Admin là role quản lý permissions hoặc system settings. Một multisig yêu cầu nhiều chữ ký có thể giảm rủi ro một khóa, nhưng các signer vẫn có thể thông đồng hoặc bị compromise. Nó là control, không phải nhãn “decentralized”.

b. Governance là cả pipeline

Governance không dừng ở “1 token = 1 vote”. Một pipeline đầy đủ gồm:

Voting power → Proposal threshold → Voting delay/period → Quorum → Counting → Queue → Execution

Quorum là mức tham gia tối thiểu để proposal hợp lệ. Timelock là độ trễ giữa queue và execution, cho cộng đồng thời gian quan sát hoặc phản ứng. OpenZeppelin Governor tách voting source, quorum, settings và timelock thành modules riêng; điều đó cho thấy governance cần nhiều quyết định thiết kế, không chỉ token balance (OpenZeppelin Governance).

Voting snapshot giúp lấy voting power tại một timepoint, giảm chuyện chuyển cùng token để vote lặp; hướng dẫn on-chain governance của OpenZeppelin giải thích ERC20Votes giữ historical balances cho mục đích này (Governance Guide).

Vẫn phải hỏi execution cuối do Governor/Timelock thực hiện hay admin có thể bypass. Nếu vote chỉ mang tính tham khảo còn một key quyết định mọi thay đổi, quyền thực tế nằm ở key đó.

Hình 4 — Permission map theo action và execution path hữu ích hơn nhãn decentralized chung chung.

c. Failure modes cần viết trước

Failure mode là cách mechanism có thể hỏng hoặc bị game. Với LEARN:

1. Token unnecessary: database points tạo outcome tương đương với ít rủi ro hơn.
2. Circular reward: reviewer kiếm token chỉ để tiếp tục kiếm token, không có service demand ngoài vòng.
3. Weak sink: request demand thấp hơn reward emission, balance tích lũy.
4. Quality gaming: review nhiều nhưng chất lượng thấp.
5. Privilege concentration: multisig có thể tăng cap hoặc đổi logic quá nhanh.
6. Governance apathy: quorum hiếm đạt, execution quay lại admin.

Viết failure mode trước giúp chọn metric và stress test. Nó không bảo đảm tránh sự cố; nó làm assumption lộ ra để theo dõi.

5. Checklist và bài tập Token Design Canvas

a. Checklist mười ô

Dùng Google Docs, Sheets hoặc giấy. Không cần wallet, không deploy contract và không dùng tiền thật. Trong 20 phút, điền:

1. Problem cụ thể.
2. Actors và việc mỗi nhóm làm.
3. Rights/claims gắn với token.
4. Remove-token test.
5. Sources và issuance rule.
6. Sinks/routes và người chịu cost.
7. Permissions/admin/upgrade surface.
8. Success metrics gắn outcome.
9. Failure modes và cách game.
10. Invalidation: khi nào bỏ hoặc redesign token.

Nếu không điền được problem, actors hoặc rights, dừng trước supply math. Nếu permissions mù, không gọi system trust-minimized.

b. Mẫu Canvas tham khảo đã điền

Hình 5 — Filled Canvas nối từng token rule với actor, outcome và điều kiện khiến thiết kế phải xem lại.

c. Ba stress tests

Demand shock: request demand về 0 trong bốn tuần nhưng reward vẫn phát tối đa 1.000/tuần. Circulation có thể tăng 4.000 mà use sink bằng 0. Cần hỏi reward có tự giảm theo verified demand hay không.

Contribution shock: số reviewer giảm 50%. Nếu reward tăng để bù, cost/emission thay đổi; nếu không, SLA xấu đi. Metric phải theo cả service quality lẫn token flow.

Permission shock: một signer bị compromise. Multisig còn threshold an toàn không? Timelock có áp cho đổi cap/upgrade không? Guardian có thể cancel nhưng có quyền quá rộng không?

Sau mỗi shock, viết: observation, rule bị tác động, người chịu cost, guardrail và invalidation. Nếu cách sửa chỉ là “tăng reward” hoặc “burn thêm” mà không giải thích actor behavior, design chưa đủ.

6. Tổng kết và bản đồ PHASE 2

a. Năm ý chính

• Token Design là hệ thống purpose, actors/rights, flows, permissions và failure modes.
• Token standard tạo interface chung nhưng không quyết định supply, utility, demand hoặc governance.
• Source-flow-sink phải nối với hành động và outcome đo được, không chỉ tổng cung.
• Governance cần cả proposal, quorum, delay và execution; admin paths phải được map.
• Remove-token test, Canvas và stress tests giúp lộ assumption trước khi dùng tiền thật.

b. Câu hỏi tự kiểm tra

• Token standard khác Token Design ở đâu?
• Vì sao có burn chưa đủ chứng minh value capture?
• Một permission map tối thiểu phải hỏi những action nào?
• Khi nào remove-token test khiến bạn phải dừng?

c. Gợi ý đáp án

Xem gợi ý câu 1

Standard định nghĩa interface; design định nghĩa purpose, rights, flows, permissions và outcomes. Xem lại mục 2.

Xem gợi ý câu 2

Cần biết token burn đến từ ai, đổi lấy demand nào và benefit về đâu. Xem lại mục 3.

Xem gợi ý câu 3

Hỏi ai mint, pause, grant role, upgrade, chuyển treasury và execute governance. Xem lại mục 4.

Xem gợi ý câu 4

Dừng khi database points tạo cùng outcome mà token không thêm lợi ích kiểm chứng được. Xem lại mục 1.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• EIP-20 — Token Standard
• Ethereum.org — ERC-20 Token Standard
• OpenZeppelin — Access Control
• OpenZeppelin — Governance API
• OpenZeppelin — How to set up on-chain governance

Điều hướng PHASE 2: Bài trước là SOPR là gì? #5. Bài tiếp theo là Inflation và Deflation trong Tokenomics #7. Sau đó, series lần lượt tách sâu Value Capture #8, Governance Token #9 và Advanced Tokenomics #10.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.