Cách viết whitepaper crypto: cấu trúc, nội dung và sai lầm

Whitepaper dùng để làm gì và ai sẽ đọc nó?

Whitepaper cần thiết để cung cấp cho độc giả một giải thích có thể kiểm chứng về dự án: vấn đề nó giải quyết, cách thức thực hiện và những gì đã biết về triển khai. Đây không phải là tài liệu quảng cáo, cũng không thay thế tài liệu kỹ thuật, bài thuyết trình hoặc tài liệu pháp lý. Trước khi viết, hãy xác định quyết định mà độc giả cần đưa ra sau khi đọc: hiểu sản phm, đánh giá mô hình kỹ thuật hoặc nghiên cứu cấu trúc token.

Xác định các đối tượng chính riêng biệt. Người dùng cần hiểu kịch bản sử dụng; nhà phát triển cần kiến trúc và giới hạn; đối tác cần sự phụ thuộc và các giai đoạn tích hợp. Một tài liệu có thể phục vụ nhiều nhóm, nhưng không nên buộc tất cả phải vượt qua cùng một mức độ chi tiết. Tóm tắt ngắn giúp hiểu nhanh, trong khi các phần chuyên sâu cung cấp chiều sâu cho những ai cần.

Trước khi lập kế hoạch, hãy trả lời các câu hỏi:

• Độc giả đã biết gì về sản phẩm và blockchain?
• Những tuyên bố nào có thể được xác nhận bằng sản phẩm hiện tại, mã hoặc tính toán?
• Thuật ngữ nào cần được định nghĩa khi sử dụng lần đầu?
• Tài liệu sẽ liên kết với trang web, tài liệu kỹ thuật và tài liệu ra mắt như thế nào?

Nếu cần một tổng quan ngắn cho lần đầu tiếp cận, nó có thể là phần bổ sung, nhưng không được che giấu các điều kiện quan trọng. Để có kế hoạch chuẩn bị rộng hơn, hãy sử dụng danh sách kiểm tra ra mắt token.

Cấu trúc whitepaper nào giúp hiểu dự án?

Cấu trúc hiệu quả dẫn dắt độc giả từ vấn đề đến giải pháp, sau đó trình bày cơ chế và giới hạn. Thứ tự có thể thay đổi theo sản phẩm, nhưng mỗi phần phải trả lời một câu hỏi cụ thể, không lặp lại luận điểm chung bằng từ khác.

Khung tài liệu hữu ích:

• Tóm tắt ngắn: sản phẩm, đối tượng, vấn đề và giải pháp đề xuất.
• Bối cảnh và vấn đề: nơi các phương pháp hiện tại không đáp ứng và ai bị ảnh hưởng.
• Mô tả sản phẩm: kịch bản người dùng, chức năng chính và trạng thái phát triển.
• Kiến trúc: thành phần, luồng dữ liệu, mạng lưới sử dụng và phụ thuộc bên ngoài.
• Token và kinh tế: mục đích, phân bổ, cơ chế khả dụng và điều kiện, nếu token được thiết kế.
• Bảo mật và giới hạn: mô hình mối đe dọa, biện pháp đã áp dụng, đánh đổi đã biết và câu hỏi mở.
• Lộ trình phát triển và quản trị: giai đoạn, phụ thuộc, quyết định chịu trách nhiệm và cách cập nhật tài liệu.

Cho mỗi phần, hãy lập luận điểm và danh sách xác nhận: đặc tả, tính toán, sơ đồ hoặc nhận xét của người phụ trách. Nếu chưa có dữ liệu, hãy đánh dấu là câu hỏi mở hoặc kế hoạch, không lấp đầy bằng tuyên bố tự tin. Nội dung phải phản ánh cấu trúc thực tế của sản phẩm, không phải là mẫu chung. Nếu dự án cần tài liệu để trình bày ý tưởng bằng lời, hãy so sánh với định dạng pitch deck.

Làm thế nào để mô tả tokenomics và cơ chế kỹ thuật?

Phần về token phải giải thích vai trò của nó trong sản phẩm và quy tắc lưu hành bằng ngôn ngữ dễ hiểu. Nếu token không cần thiết cho kịch bản mô tả hoặc chức năng chưa được xác định, đừng che giấu sự không chắc chắn bằng các sơ đồ phức tạp: hãy ghi nhận quyết định là mở và thống nhất với đội ngũ.

Mô tả mục đích của token thông qua hành động của người dùng hoặc giao thức. Làm rõ nơi và điều kiện sử dụng, quyền hoặc chức năng liên quan, và các hạn chế áp dụng. Nếu cung cấp thông tin về nguồn cung, phân bổ, mở khóa hoặc phát hành, hãy thống nhất với mô hình hiện tại và sử dụng thuật ngữ nhất quán trong toàn tài liệu. Không trộn lẫn tỷ lệ phân bổ, khả năng khả dụng và lưu thông thực tế: đây là các khái niệm khác nhau.

Đối với phần kỹ thuật, hữu ích để trình bày:

• các thành phần chính của hệ thống và tương tác của chúng;
• điều gì xảy ra trong kịch bản người dùng thông thường;
• hành động nào do smart contract thực hiện và phần nào ngoài chuỗi;
• dịch vụ hoặc mạng lưới bên ngoài nào ảnh hưởng đến hoạt động;
• các giả định và đánh đổi của kiến trúc đã chọn.

Thêm sơ đồ nếu nó giúp theo dõi luồng tài sản hoặc dữ liệu, và chú thích rõ ràng. Mỗi biểu đồ phải khớp với văn bản và triển khai hiện tại. Tokenomics không chứng minh giá trị tương lai của tài sản: hãy mô tả cấu trúc và điều kiện, không đưa ra kết luận về lợi nhuận.

Làm thế nào để đi từ tài liệu nguồn đến văn bản hoàn chỉnh?

Whitepaper dễ chuẩn bị hơn khi dữ liệu được thu thập trước khi viết và việc kiểm tra được phân bổ cho các chủ sở hữu phần. Đừng bắt đầu với việc trau chuốt câu chữ: trước tiên tìm lỗ hổng trong mô hình, thống nhất thuật ngữ và xác nhận rằng các thành viên trong nhóm mô tả cùng một sản phẩm.

Quy trình làm việc thực tế:

• Thu thập tài liệu nguồn: mô tả sản phẩm, đặc tả, tokenomics, sơ đồ, trạng thái phát triển và danh sách quyết định mở.
• Chỉ định người chịu trách nhiệm: mỗi tuyên bố kỹ thuật, sản phẩm và kinh tế phải có chủ sở hữu có thể xác nhận.
• Thống nhất nội dung: lập kế hoạch các phần và đánh dấu dữ liệu đã xác nhận so với kế hoạch.
• Viết và kiểm tra bản nháp: trước tiên logic và đầy đủ, sau đó phong cách, thuật ngữ, tham chiếu chéo và yếu tố trực quan.
• Ghi nhận phát hành: chỉ định phiên bản và ngày cập nhật, giao người chịu trách nhiệm cho các thay đổi sau.

Thời gian chuẩn bị không được xác định bởi số trang, mà bởi sự sẵn sàng của chuyên gia, tính đầy đủ của tài liệu và tốc độ phê duyệt. Giảm chậm trễ bằng cách thu thập nhận xét trong một tài liệu và phân loại góp ý thành thực tế, kỹ thuật và biên tập. Biên tập viên có thể cải thiện cấu trúc và sự rõ ràng, nhưng đội ngũ dự án phải xác nhận cấu trúc sản phẩm.

Những sai lầm nào làm whitepaper yếu?

Một whitepaper yếu thường không giải thích cách giải pháp đã hứa hoạt động trong thực tế. Độc giả thấy thuật ngữ, kế hoạch và tuyên bố hấp dẫn, nhưng không thể kiểm tra mối liên hệ giữa vấn đề, sản phẩm và cơ chế đã nêu.

Kiểm tra bản nháp với các lỗi điển hình:

• Luận điểm quá rộng về vấn đề. Chỉ rõ người dùng cụ thể, kịch bản và thiếu sót của phương pháp hiện tại.
• Thuật ngữ kỹ thuật không định nghĩa. Giải thích thuật ngữ khi sử dụng lần đầu và dùng nhất quán trong tất cả các phần.
• Kế hoạch được trình bày như chức năng đang hoạt động. Tách biệt triển khai hoàn chỉnh, phát triển hiện tại và hướng tiềm năng.
• Tokenomics mô tả tách rời sản phẩm. Cho thấy token giải quyết nhiệm vụ gì, hoặc trung thực nói rằng vai trò vẫn đang được xác định.
• Giá trị và thuật ngữ không nhất quán. Đối chiếu văn bản, bảng, biểu đồ và tài liệu công khai với một nguồn dữ liệu duy nhất.
• Không thảo luận về giới hạn. Chỉ ra phụ thuộc và đánh đổi có thể ảnh hưởng đến việc sử dụng hệ thống.

Một kiểm tra biên tập hữu ích rất đơn giản: yêu cầu người ngoài nhóm tóm tắt mục đích dự án và một kịch bản chính sau khi đọc tóm tắt. Nếu họ thay thế dữ kiện bằng giả định của riêng họ, hãy làm rõ văn bản và thêm các kết nối còn thiếu. Đừng thêm nội dung chỉ để gây ấn tượng: mỗi tuyên bố phải giúp hiểu hệ thống.

Cần kiểm tra gì trước khi xuất bản whitepaper?

Trước khi xuất bản, hãy kiểm tra tài liệu như một nguồn thông tin về dự án: độc giả phải phân biệt thực tế với ý định, hiểu thuật ngữ và tìm thấy xác nhận cho các tuyên bố quan trọng. Việc kiểm tra không chỉ dành cho biên tập viên — mà có sự tham gia của những người chịu trách nhiệm về sản phẩm, phát triển, mô hình kinh tế và truyền thông công khai.

Hoàn thành danh sách cuối cùng:

• Đối chiếu tất cả mô tả kỹ thuật với kiến trúc hiện tại và trạng thái phát triển.
• Kiểm tra rằng mô hình token trong văn bản khớp với tính toán và quyết định đã được thông qua.
• Đánh dấu dự đoán và kế hoạch là kế hoạch, không phải sự thật đã xảy ra.
• Đảm bảo bảng và hình minh họa dễ đọc và không mâu thuẫn với văn bản.
• Kiểm tra ngày tháng, phiên bản, liên kết, cách viết tên và định nghĩa thuật ngữ.
• Chỉ định nơi báo cáo sửa đổi và nơi tìm phiên bản mới nhất.

Whitepaper tự nó không xác nhận chất lượng dự án và không thay thế việc kiểm tra smart contract, sản phẩm hoặc mô hình pháp lý. Việc xuất bản tài liệu không kiểm soát quyết định của các nền tảng: listing và moderators của CoinMarketCap hoặc CoinGecko tuân theo tiêu chí và quy trình riêng của họ. Không thể hứa hẹn sự chấp thuận listing, sự chú ý của khán giả hoặc kết quả thị trường dựa trên văn bản. Đội ngũ có thể chịu trách nhiệm về tính chính xác và cập nhật kịp thời tài liệu, nhưng không chịu trách nhiệm về quyết định của nền tảng bên ngoài. Nếu sau khi thay đổi sản phẩm, thông tin công khai được cập nhật, hãy thống nhất với các tài liệu khác, bao gồm đơn xin listing CoinMarketCap.

Bảng giá

Giá khởi điểm bằng USD. Gói tùy chỉnh và chiết khấu theo số lượng theo yêu cầu. Thanh toán bằng USDT, USDC, BTC, ETH, SOL, TON hoặc token dự án của bạn.

Cách hoạt động

1. Thu thập dữ kiệnYêu cầu đặc tả, sơ đồ, thông số token hiện tại và mô tả kịch bản người dùng. Ghi chú riêng các câu hỏi mà đội ngũ chưa có quyết định.
2. Xác định độc giảChọn các đối tượng chính và quyết định giải thích nào cần cho mỗi nhóm. Xác định mục tiêu của tài liệu để không trộn lẫn với bài thuyết trình hoặc tài liệu kỹ thuật.
3. Thống nhất cấu trúcSắp xếp các phần từ vấn đề và sản phẩm đến kiến trúc, kinh tế và giới hạn. Cho mỗi luận điểm, chỉ định chuyên gia kiểm tra tính chính xác.
4. Chuẩn bị bản nhápViết dựa trên tài liệu đã xác nhận và tách biệt chức năng hiện tại với kế hoạch. Kiểm tra rằng định nghĩa và giá trị không thay đổi giữa các phần.
5. Kiểm tra và phát hànhĐối chiếu dữ kiện với đội ngũ, biên tập văn bản, sơ đồ và liên kết. Chỉ định phiên bản tài liệu và giao người chịu trách nhiệm cập nhật.