Kripto Whitepaper Yazma: Yapı ve Yaygın Hatalar

Whitepaper'ınızın desteklemesi gereken kararla başlayın

Yararlı bir kripto whitepaper, belirli bir okuyucunun projenin ne yaptığını, nasıl tasarlandığını ve neyin belirsiz olduğunu anlamasına yardımcı olur. Taslağa başlamadan önce, birincil okuyucunun bir kullanıcı, geliştirici, token katılımcısı, ortak veya değerlendirici olup olmadığına karar verin; belge birden fazla kitleye hitap edebilir, ancak her birinin cevaplarını aramak zorunda kalmasına neden olmamalıdır.

Belge için tek cümlelik bir amaç yazın, ardından şu soruları yanıtlayın:

• Proje hangi sorunu ve kimin için ele alıyor?
• Önerilen sistemin bu sorunu ele almadaki rolü nedir?
• Bir okuyucu bugün neyi inceleyebilir veya kullanabilir ve hâlâ ne planlanmaktadır?
• Belge, ürün veya sözleşmeden anlaşılmayan hangi kararları açıklıyor?

Cevaplar kapsamı belirlemeye yardımcı olur. Yeni bir teknik tasarıma sahip bir protokol, önemli miktarda mimari detay gerektirebilir; yerleşik altyapı üzerine inşa edilmiş bir uygulama, kullanıcı akışları, bağımlılıklar ve token faydası için daha fazla alana ihtiyaç duyabilir. Alaka düzeyini açıklamanın yerine teknik derinliği kullanmayın.

Bir whitepaper ayrıca paragraflara genişletilmiş bir pitch deck değildir. Bir deck dikkat çekmek için bir durum sunar; bir whitepaper, varsayımlar ve kısıtlamalar dahil olmak üzere durumu incelenebilir kılmalıdır. Ekip her ikisine de ihtiyaç duyuyorsa, her formata kendi işini verirken temel gerçekleri uyumlu tutun. Tamamlayıcı belgenin rolü için kripto pitch deck rehberi bölümüne bakın.

Bir kripto whitepaper hangi yapıyı izlemelidir?

Bir kripto whitepaper, okuyucuları sorundan tasarıma ve sonuçlarına götüren bir sıraya ihtiyaç duyar. Aşağıdaki sıralama başlangıç ​​için bir çerçevedir, zorunlu bir içindekiler tablosu değildir; yalnızca gerçek bir okuyucu sorusunu yanıtlıyorsa bir bölümü koruyun.

Okuyuculara güvenilir bir harita vermek için genel bakışı kullanın, sıkıştırılmış bir satış konuşması olarak değil. Teknik bölümlerde, terimleri kullanmadan önce tanımlayın ve her bileşeni işlevine bağlayın. Bir diyagram bir akışı takip etmeyi kolaylaştırabilir, ancak etiketleri ve sınırları düzyazı ile uyumlu olmalıdır.

Token'ı yalnızca projenin onun için tanımlanmış bir rolü varsa açıklayın. Birinin otomatik olarak diğerini ürettiğini ima etmek yerine fayda, yönetişim ve tahsis ayrıntılarını ayırt edin. Token verilerinin daha yakından kontrolü için token arz rehberi bölümünü kullanın. Bir konu projeyle ilgisizse, kısaca belirtin veya atlayın; genel bir bölüm eklemek, ürünün yanıtlamadığı sorular yaratabilir.

Teknik ve token iddialarını nasıl güvenilir kılabilirsiniz?

Güvenilir iddialar, bir okuyucunun incelemesi için yeterince spesifik ve projenin gerçek durumuyla eşleşecek kadar ölçülüdür. Her önemli ifade için, taslağa ulaşmadan önce kaynağını, sahibini ve durumunu belirleyin.

Bir iddia incelemesi üç etiket kullanabilir:

• Mevcut: canlı bir ürün, yayınlanmış kod, belgelenmiş süreç veya onaylanmış karar tarafından desteklenmektedir.
• Planlanan: teslim edilmemiş amaçlanan bir yetenek veya kilometre taşı; bunu bir plan olarak tanımlayın.
• Varsayım: tasarımın dayandığı ancak ekibin gerçek olarak tespit etmediği bir koşul.

Ardından ifadeyi test edin. "Tamamen merkeziyetsiz" gibi geniş ifadeleri, hangi kararların dağıtıldığını, hangi rollerin yetkiyi elinde tuttuğunu ve değişikliği hangi mekanizmanın yönettiğini açıklayan bir açıklamayla değiştirin. Güvenlik çalışmalarını gerçek durumu ve kapsamıyla tanımlayın. Bir denetimin, testin veya entegrasyonun yaptığından daha fazlasını kapsadığını ima etmeyin.

Token bölümleri de aynı disiplini gerektirir. İsimlerin, birimlerin, tahsislerin, vesting açıklamalarının ve arz ifadelerinin projenin onaylanmış materyalleriyle eşleştiğini kontrol edin. Bir rakam veya politika kesinleşmemişse, boşluğu uydurulmuş bir cevapla doldurmak yerine sorumlu ekibe işaretleyin. Bir token lansman kontrol listesi, tutarlı dil kullanması gereken ilgili materyalleri belirlemeye yardımcı olabilir.

Bu inceleme yalnızca editoryal değildir. Teknik liderden sistem açıklamalarını doğrulamasını, token sahibinden token ayrıntılarını onaylamasını ve proje liderinden yol haritası veya yönetişim hakkındaki ifadeleri çözmesini isteyin. Belirli bölüme karşı imza kaydedin, böylece incelemeciler tüm belgeyi yeniden okumak yerine kararlara odaklanabilir.

Ekip taslak hazırlamadan önce neyi hazırlamalıdır?

Ekip, bir yazarın onaylanmış gerçekleri açık sorulardan ayırt etmesini sağlayacak bir kaynak paketi hazırlamalıdır. Neyin güncel olduğuna dair bir gösterge olmayan büyük bir klasörden ziyade, kısa ve iyi organize edilmiş bir materyal seti daha kullanışlıdır.

Mevcut olduğunda şunları ekleyin:

• Bir ürün tanıtımı veya amaçlanan kullanıcı akışının açıklaması.
• Mimari notları, diyagramlar ve adlandırılmış bir teknik incelemeyi yapan kişi.
• Mevcut token modeli ve bunu onaylamaya yetkili kişi.
• Yol haritası kararları, bilinen bağımlılıklar ve çözülmemiş öğeler.
• Mevcut web sitesi, pitch deck, dokümantasyon ve kamuya açık ifadeler.
• Hedef kitle öncelikleri, tercih edilen terminoloji ve herhangi bir gizlilik sınırı.

İlk çalışma oturumu kapsamı belirlemelidir: hangi kitlelerin en önemli olduğu, belgenin neyi açıklaması gerektiği, hangi kanıtların mevcut olduğu ve hangi iddiaların takip gerektirdiği. Bir yazar, sessizce varsayımlarda bulunmak yerine bir soru günlüğü döndürmelidir. Bu günlük, ekibe boşlukları gidermek için pratik bir yol verir ve her cevabı sağlamaya yetkili birine atar.

Taslak hazırlama daha sonra taslaktan bölümlere geçer ve teknik ve proje incelemesi yalnızca nihai teslimatta değil, planlanan noktalarda yapılır. Ölçülü bir düzenleme geçişi, tekrarı kaldırmalı, terimleri tutarlı bir şekilde tanımlamalı ve ürün gerçeklerini planlardan ayırt etmelidir. Whitepaper ve litepaper formatları da farklı ayrıntı düzeylerine hizmet eder; doğru seçim, okuyucuların tam bir açıklamaya mı yoksa kısa bir yönlendirmeye mi ihtiyaç duyduğuna bağlıdır. Özel yazım desteği için whitepaper ve litepaper yazımı bölümüne bakın ve kapsamı kripto whitepaper fiyatlandırması sayfasında karşılaştırın.

Hangi whitepaper hataları okuyucu güvenini zedeler?

En zarar verici whitepaper hataları genellikle uyumsuzluklardır: iddia ile kanıt, hırs ile mevcut yetenek veya token dili ile proje gerçekliği arasında. Son bir okuma, cümle ritmini cilalamadan önce bu uyumsuzlukları aramalıdır.

Yaygın sorunlar şunları içerir:

• Büyük iddialarla başlamak: Okuyucuların önce somut bir soruna ve önerilen yanıtın net bir açıklamasına ihtiyacı vardır.
• Açıklanmayan teknik dil kullanmak: Terimleri ilk kullanımda tanımlayın ve bir tasarım seçiminin neden önemli olduğunu açıklayın.
• Yol haritasına bir vaat gibi davranmak: Planlanan çalışmaları planlanmış olarak etiketleyin, bağımlılıkları belirleyin ve niyetleri tamamlanmış özellikler olarak sunmaktan kaçının.
• Token ayrıntılarını bağlam olmadan vermek: Belirtilen her işlevi açıklayın ve arz veya tahsis dilini onaylanmış proje materyalleriyle tutarlı tutun.
• Bir şablonu mekanik olarak doldurmak: Projeye uymayan bölümleri, onları doldurmak için genel iddialarda bulunmak yerine kaldırın.
• Diyagramlar ve düzyazıyı senkronize etmemek: Sistemin her iki temsilini de aynı teknik incelemeyi yapan kişiye kontrol ettirin.

Ayrıca iç çelişkileri kontrol edin. Tekrarlanan terimleri, tarihleri, arz açıklamalarını ve ürün adlarını arayın; bunları mevcut web sitesi ve dokümantasyonla karşılaştırın. Düzenlemeler sırasında kanonik gerçekleri korumak için bir kişiyi görevlendirin, çünkü bir paragrafta yapılan bir düzeltme başka bir yerde güncelliğini yitirmiş bir ifade bırakabilir.

Kısa bir belge, varsayımları gizlemeden temel soruları yanıtlıyorsa tamamlanmış olabilir. Uzunluk tek başına bir argümanı titiz yapmaz. Bir nokta henüz kanıtlanamıyorsa, sınırı açıkça belirtin veya daha sonraki bir revizyona bırakın.

Bir kripto whitepaper yayınlamadan önce nasıl incelemelisiniz?

Yayın öncesi bir inceleme, doğruluğu, tutarlılığı ve okunabilirliği bu sırayla onaylamalıdır. Temel gerçeklerden sorumlu kişilerle başlayın, ardından yabancı bir okuyucunun canlı bir brifing olmadan açıklamayı takip edip edemeyeceğini değerlendirin.

Bu inceleme sırasını kullanın:

1. Teknik geçiş: Mimarîyi, terminolojiyi, sistem sınırlarını ve diyagramları teknik sahibiyle kontrol edin.
2. Token ve operasyon geçişi: Token açıklamalarını, yönetişim dilini, rolleri ve operasyonel ayrıntıları ilgili proje sahipleriyle onaylayın.
3. Okuyucu geçişi: Taslak grubu dışındaki birinden okuduktan sonra sorunu, mekanizmayı, token rolünü ve mevcut durumu özetlemesini isteyin.
4. Tutarlılık geçişi: İddiaları web sitesi, dokümantasyon, sunum ve diğer kamuya açık materyallerle karşılaştırın; farklılıkları kaynağında çözün.
5. Kopya ve düzen geçişi: Başlıkları, tanımları, bağlantıları, tabloları, sürüm ayrıntılarını ve belgenin ekranda okunabilir kalıp kalmadığını kontrol edin.

Önemli düzenlemeler için bir değişiklik günlüğü tutun ve nihai olgusal sürümü kimin onayladığını işaretleyin. Bu, ürün, token modeli veya yol haritası değiştiğinde daha sonraki güncellemeleri kolaylaştırır. Whitepaper'a asla revize edilemeyecek kalıcı bir kayıt değil, bakımı yapılan bir referans olarak davranın.

Bir yazar, projenin bilgilerini düzenleyebilir ve netleştirebilir, ancak teknik gerçeklere ekip adına karar veremez. Ekip ayrıca belgenin kendi yasal ve ifşa yükümlülüklerini karşılayıp karşılamadığını da kontrol eder; whitepaper'ın kendisi onay, liste veya okuyucu kabulünü garanti etmez. MediaStrategy'da, adlandırılmış inceleme adımı bir iddia-ve-kaynak geçişidir: desteklenmeyen ifadeleri işaretleriz, açık soruları doğru sahibine atarız ve nihai taslağı onayladığınız materyallere karşı uyumlu hale getiririz. Mevcut dokümantasyonunuzu, token materyallerinizi ve hedef okuyucunuzu bize gönderin; taslak hazırlamadan önce kapsamlı bir taslak ve çözülmesi gereken soruları size geri göndereceğiz.

Fiyatlar

Başlangıç fiyatları USD'dir. Özel paketler ve hacim indirimleri talep üzerine. Ödeme: USDT, USDC, BTC, ETH, SOL, TON veya proje tokeniniz ile.

Nasıl çalışır

1. Belgenin işini belirleyinBirincil okuyucuyu ve whitepaper'ın cevaplaması gereken soruları adlandırın. Belgeye neyin ait olduğuna karar vermek için bu kapsamı kullanın.
2. Onaylanmış kaynakları bir araya getirinMevcut ürün, teknik, token ve yol haritası materyallerini toplayın ve her olgusal alan için bir sahip belirleyin.
3. Taslağı hazırlayınBölümleri okuyucu odaklı bir sırayla düzenleyin ve tam taslak hazırlamadan önce eksik kanıtları veya çözülmemiş kararları işaretleyin.
4. Konuya göre yazın ve inceleyinBölümleri geliştirin, ardından teknik, token ve proje iddialarını bunları doğrulamaya yetkili kişilere yönlendirin.
5. Uzlaştırın ve yayınlayınYorumları çözün, belgeyi diğer kamuya açık materyallerle uyumlu hale getirin ve nihai olgusal sürümün onayını kaydedin.