Tôi từng tin rằng một giao thức blockchain, để tồn tại lâu dài, nhất định phải giữ một triết lý đủ phức tạp và đủ "đẹp". Giống như NEAR với cơ chế Gas Rebate dành cho developer — tôi cho rằng đó là một sự đền đáp xứng đáng cho những người xây nhà. Nhưng tuần trước, một提案 (HSP-027) được thông qua, và triết lý đó chính thức bị đập tan.
Tôi đã dành gần 20 năm quan sát thị trường này. Và bài học đắt giá nhất tôi học được là: Sự giản hóa không bao giờ là vô hại. Nó luôn là một canh bạc — một cuộc đánh đổi giá trị giữa các nhóm người trong cùng một hệ sinh thái.
Đây là câu chuyện về NEAR, và tại sao quyết định "đơn giản hóa" này lại khiến tôi vừa phấn khích vừa lạnh sống lưng.
Bối cảnh: Giấc mơ "Developer-first" bị vứt bỏ
Khi NEAR ra đời, nó mang một lời hứa rất khác biệt: 30% phí giao dịch (execution fee) sẽ được trả lại cho developer của smart contract. Đó không chỉ là một ưu đãi. Đó là một tuyên ngôn: "Chúng tôi xây dựng hạ tầng, các bạn xây dựng ứng dụng, và chúng ta cùng chia sẻ doanh thu."
Nhưng giờ đây, với HSP-027, tuyên ngôn đó đã bị xóa bỏ. 100% phí thực thi sẽ được đốt (burn). Developer sẽ không còn nhận được đồng nào từ phí giao dịch nữa. Bản nâng cấp nearcore v2.14, dự kiến vào tháng 8 năm 2026, sẽ là ngày chôn vùi giấc mơ "phân phối lại giá trị cho người tạo ra nội dung".
Phân tích cốt lõi: Từ "đẹp" đến "hiệu quả" một cách tàn nhẫn
Nhìn bề ngoài, đây là một chiến thắng cho các holder. Một mô hình đơn giản: phí giao dịch tăng → token bị đốt nhiều → giá trị cho holder tăng. Nó giống như Ethereum với EIP-1559. Nó sạch sẽ, dễ hiểu, và dễ bán cho các nhà đầu tư tổ chức.
Nhưng tôi, với tư cách là một người đã từng audit 5 dự án ICO năm 2017 và phát hiện ra 12 điểm bất thường, tôi thấy một vấn đề sâu xa hơn. Đây không chỉ là thay đổi cơ chế. Đây là sự chuyển giao quyền lực.
Bản chất của sự thay đổi: Từ một cơ chế khuyến khích "sản xuất" (developer tạo ra dApp) sang một cơ chế khuyến khích "nắm giữ" (holder găm giữ token).
Trong phân tích của tôi về tokenomics của 10 giao thức lớn, tôi nhận thấy một quy luật: Bất kỳ giao thức nào loại bỏ incentive trực tiếp cho developer đều phải đối mặt với một cuộc khủng hoảng "ái tình" trong vòng 6-12 tháng. Developer sẽ cảm thấy bị phản bội. Họ không còn là "đối tác" nữa, họ chỉ là "người thuê nhà" trên mảnh đất của NEAR.
Điều mỉa mai là, lập luận cho sự thay đổi này lại rất logic: "Developer nên kiếm tiền từ ứng dụng của họ, không phải từ phí giao thức." Nghe có vẻ đúng. Nhưng hãy nhìn vào thực tế: trong một thị trường gấu, khi dApp của bạn không có doanh thu, 30% Gas Rebate đó chính là "lương cơ bản" giúp bạn sống sót để phát triển sản phẩm. Bỏ nó đi, bạn đang nói với họ: "Hãy tự bơi, hoặc chết."
Góc nhìn phản trực giác: Kẻ mất mát lớn nhất lại là... holder
Đây là phần mà tôi cho là mọi người thường bỏ qua. Bạn nghĩ rằng đốt token là tốt cho holder? Sai.
Hãy nhìn vào NEAR như một nền kinh tế. Nền kinh tế này có 2 nhóm sản xuất chính: validator (bảo vệ mạng) và developer (tạo ra giá trị). Khi bạn cắt giảm thu nhập của developer, bạn đang cắt giảm động lực sản xuất ra "hàng hóa" (dApp, ứng dụng) trên nền tảng này.
Nếu không có dApp mới, không có người dùng mới. Nếu không có người dùng mới, phí giao dịch không tăng. Nếu phí giao dịch không tăng, lượng token bị đốt là không đáng kể. Kết quả? Bạn kết thúc với một token deflationary về mặt lý thuyết, nhưng inflationary về mặt giá trị thực tế, bởi vì không có ai muốn sử dụng nó.
Tôi đã chứng kiến điều này với rất nhiều giao thức. Họ nghĩ rằng "burn = price go up". Nhưng thực tế, "utility = price go up". NEAR vừa hy sinh utility (bằng cách làm cho developer khó khăn hơn) để theo đuổi một câu chuyện burn đẹp đẽ. Đây là một canh bạc rất lớn.
Takeaway: Sự giản hóa là một sự lựa chọn, không phải một chân lý
Sau 5 năm xây dựng ChainWise Academy và chứng kiến hàng trăm dự án lên voi xuống chó, tôi có một kết luận đơn giản: Các giao thức tồn tại lâu dài nhất không phải là những giao thức có tokenomics đơn giản nhất, mà là những giao thức có cộng đồng gắn kết nhất. Cộng đồng đó bao gồm cả nhà đầu tư và nhà phát triển.
NEAR đã chọn phe của nhà đầu tư. Họ đặt cược rằng sự đơn giản hóa này sẽ thu hút đủ vốn để bù đắp cho sự ra đi của các developer.
Tôi không nói rằng nó sẽ thất bại. Nhưng tôi biết rằng, trong 22 năm qua, tôi chưa bao giờ thấy một canh bạc nào dựa trên sự giản hóa lại không để lại những vết sẹo.
Hãy tự hỏi mình: Khi bạn nhìn vào một giao thức, bạn có đang yêu thích sự đơn giản của nó, hay bạn đang tin vào giá trị mà nó tạo ra cho tất cả các bên tham gia? Câu trả lời sẽ quyết định sự sống còn của danh mục đầu tư của bạn.