코인 백서 작성법: 구조와 흔한 실수

암호화폐 백서는 독자가 무엇을 결정하는 데 도움이 되어야 하나요?

암호화폐 백서는 특정 독자가 프로젝트가 제안하는 것을 이해하고 다음에 무엇을 검토할지 결정하도록 도와야 합니다. 제품 문서, 피치덱 또는 법적 조언을 대체하지 않습니다. 초안을 작성하기 전에 독자의 결정을 한 문장으로 작성하세요: 예를 들어, 프로토콜을 연구할지, 토큰 설계를 평가할지, 제안된 사용 사례를 평가할지 여부입니다.

그런 다음 청중의 질문을 매핑하세요. 개발자는 아키텍처, 종속성 및 구현 상태가 필요할 수 있습니다. 토큰 보유자는 공급, 효용 및 거버넌스를 찾을 수 있습니다. 잠재적 파트너는 더 넓은 생태계에서 제품의 역할이 필요할 수 있습니다. 하나의 문서가 여러 독자를 제공할 수 있지만, 관련 없는 세부 사항을 뒤지게 해서는 안 됩니다.

짧은 브리프를 사용하여 다음을 설정하세요:

• 문제와 그것을 경험하는 사람.
• 제안된 솔루션과 현재 존재하는 것.
• 문서의 의도된 독자와 다음 조치.
• 어떤 주장이 확인되었는지, 계획되었는지, 아직 연구 중인지.

프로젝트가 초기이고 간결한 소개가 주요 필요라면, 개요를 작성하기 전에 암호화폐 피치덱과 백서를 비교하세요. 덱은 프레젠테이션을 지원하고, 백서는 독자에게 더 완전하고 참조 가능한 설명을 제공합니다.

어떤 구조가 코인 백서 작성법을 평가하기 쉽게 만드나요?

유용한 구조는 독자의 문제에서 프로젝트의 제안된 답변으로 이동한 다음 시스템이 어떻게 작동하는지와 무엇이 불확실한지 보여줍니다. 핵심 설명을 앞부분에 두세요. 독자는 제품이 무엇을 위한 것인지 알기 전에 토큰 분배나 기술 용어를 이해할 필요가 없어야 합니다.

실용적인 개요는 다음과 같습니다:

1. 요약: 문제, 제안 및 현재 상태.
2. 문제 및 맥락: 영향을 받는 사람과 기존 접근 방식이 해결하지 못한 것.
3. 제품 및 시스템: 사용자 흐름, 핵심 구성 요소 및 상호 작용 방식.
4. 아키텍처: 관련 계약, 체인 선택, 종속성 및 보안 고려 사항.
5. 토큰 설계(해당되는 경우): 목적, 공급, 할당, 해제 규칙 및 거버넌스.
6. 로드맵 및 팀: 출시된 작업과 계획된 작업을 구분하고 책임 소유자를 식별하세요.
7. 위험 및 참조: 제한 사항을 설명하고 지원 자료를 가리키세요.

기본적으로 모든 제목을 채우기보다는 프로젝트에 맞게 개요를 조정하세요. 프로토콜 문서는 더 깊은 아키텍처가 필요할 수 있고, 애플리케이션은 더 많은 사용자 흐름 설명이 필요할 수 있습니다. 상호 작용을 명확히 할 때 다이어그램을 추가하고, 전문 지식 없이도 주요 요점을 이해할 수 있도록 캡션을 추가하세요. 각 핵심 개념에 하나의 용어를 사용하고, 첫 사용 시 정의하고, 섹션 이름을 설명적으로 유지하세요. 독자가 제목을 훑어보고 문서의 논증을 이해할 수 있어야 합니다.

토큰 경제와 프로젝트 주장은 어떻게 설명해야 하나요?

토큰 메커니즘을 독자가 추적할 수 있는 규칙으로 설명하고, 고립된 수치나 홍보 언어로 설명하지 마세요. 토큰이 무엇을 하는지, 누가 받거나 사용할 수 있는지, 공급이 어떻게 변하는지, 어떤 행동이 코드, 정책 또는 미래 결정에 의해 관리되는지 명시하세요. 프로젝트에 토큰이 없으면 추측성 토큰 섹션을 추가하는 대신 명확히 말하세요.

모든 공급 또는 할당 진술에 대해 단위, 관련 주소 또는 수신자 범주, 정보가 현재 상태 또는 제안된 계획을 설명하는지 여부를 지정하세요. 베스팅, 언락, 배출, 소각 또는 기타 공급 변경이 적용되는 경우에만 명확히 하세요. 내러티브, 차트 및 표에서 합계와 용어를 일관되게 유지하세요. 온체인 세부 사항의 경우 사용 가능한 경우 관련 탐색기 또는 계약 참조에 연결하세요.

게시 전에 토큰 및 재무 소유자가 각 수치와 표현의 출처를 확인하도록 하세요. 문장, 출처, 소유자 및 상태가 포함된 주장 로그를 유지하세요. 백서가 상장 또는 프로필 업데이트와 함께 준비되는 경우 CoinGecko 공급 검증에 사용된 자료와 공급 언어를 조정하세요. 문서는 프로젝트의 설계를 설명해야 하며, 토큰의 사용, 수요 또는 가치가 보장된다는 것을 암시해서는 안 됩니다.

기술적 세부 사항을 신뢰할 수 있고 읽기 쉽게 만들려면 어떻게 해야 하나요?

기술적 세부 사항은 지식이 있는 검토자가 설명을 증거로 추적할 수 있고 일반 독자가 시스템의 역할을 이해할 수 있을 때 신뢰할 수 있습니다. 제품을 설명하는 데 필요한 수준에서 아키텍처를 설명하세요: 구성 요소, 데이터 흐름, 계약 책임, 외부 종속성 및 중요한 신뢰 가정. 계획되었거나 감사되지 않은 작업을 완료되었거나 독립적으로 검증된 것으로 제시하지 마세요.

관계를 보여주기 위해 다이어그램을 사용하고, 페이지를 장식하지 마세요. 각 다이어그램에 제목을 지정하고, 구성 요소에 레이블을 지정하고, 화살표가 의미하는 바를 설명하세요. 기술 용어를 첫 사용 시 평이한 언어 정의와 짝지으세요. 개발자에게만 유용한 구현 세부 사항은 부록이나 기술 문서로 이동하고, 핵심 논증은 본문에 유지하세요.

초안 작성이 완료되기 전에 검토 추적을 구축하세요:

• 기술 소유자에게 아키텍처 및 구현 상태를 확인하도록 요청하세요.
• 보안 소유자에게 감사, 통제 및 알려진 제한 사항에 대한 설명을 확인하도록 요청하세요.
• 각 사실 주장에 출처 또는 명명된 검토자를 첨부하세요.
• 확신 있는 표현으로 공백을 채우는 대신 해결되지 않은 질문을 표시하세요.

프로젝트가 제3자 프로토콜, 오라클, 브리지 또는 체인에 의존하는 경우 해당 종속성을 명명하고 역할을 설명하세요. 시스템이 의존하는 것에 대한 명확한 설명은 실제 신뢰 가정을 보여주지 않고 무신뢰로 설명하는 것보다 더 유용합니다.

출시 전에 잡아야 할 암호화폐 백서 실수는 무엇인가요?

가장 해로운 백서 실수는 불분명한 주장, 상충되는 세부 사항, 문서가 말하는 것과 프로젝트가 구축한 것 사이의 불일치입니다. 문서가 배포된 후가 아니라 검토 중에 잡으세요. 검토자에게 문법이나 시각적 다듬기뿐만 아니라 의미와 증거를 확인하도록 요청하세요.

일반적인 문제를 주의하세요:

• 불분명한 상태: 계획된 기능이 마치 라이브인 것처럼 작성되었습니다. 출시된, 진행 중인, 제안된 작업을 별도로 레이블하세요.
• 지지되지 않는 확신: 언어가 조건이나 증거를 설명하지 않고 결과를 암시합니다. 메커니즘의 정확한 설명으로 대체하세요.
• 일관되지 않은 토큰 세부 사항: 공급, 할당 또는 해제 설명이 섹션마다 다릅니다. 승인된 하나의 소스와 대조하세요.
• 청중 과부하: 밀도 높은 구현 세부 사항이 제품의 목적을 숨깁니다. 전문가 자료를 명확히 연결된 부록으로 이동하세요.
• 누락된 제한 사항: 종속성, 열린 질문 또는 위험이 없습니다. 독자가 관련성을 평가할 수 있는 곳에 추가하세요.
• 오래된 콘텐츠: 로드맵 또는 계약 참조가 더 이상 프로젝트와 일치하지 않습니다. 출시 전에 확인할 소유자를 지정하세요.

별도의 기술, 토큰, 편집 및 디자인 검토를 실행하세요. 카피에디팅 전에 모순을 해결하세요. 두 개의 상충되는 버전을 다듬는 것은 시간 낭비입니다. 버전 기록을 유지하고 한 사람이 최종 파일 및 연결된 자료를 승인하도록 하세요.

백서는 무엇을 확립할 수 있으며, 통제 밖에 있는 것은 무엇인가요?

백서는 프로젝트의 설계를 문서화하고, 증거를 설명하고, 가정을 검사하기 쉽게 만들 수 있습니다. 거래소, 데이터 플랫폼, 규제 기관 또는 독자가 프로젝트를 평가하는 방식을 결정할 수 없습니다. 특히, 게시된 문서 자체가 상장, 프로필 변경, 승인 또는 특정 시장 반응을 보장하지 않습니다. 각 플랫폼은 자체 검토 기준을 적용하며, 그 결정과 프레젠테이션은 작성자의 통제 밖에 있습니다.

게시를 버전 관리된 프로젝트 자산으로 취급하세요. 출시 전에 승인된 텍스트, 작성자 또는 조직 귀속, 문서 날짜, 접근 가능한 파일 형식 및 연결될 대상을 확인하세요. 웹사이트의 요약이 문서와 일치하는지 확인하세요. 토큰 세부 사항이 변경되면 업데이트해야 할 섹션, 차트 및 지원 페이지를 식별하고 문서 소유자를 지정하세요. 상장 준비를 위해 관련 상장 프로세스를 통해 제출된 정보와 백서를 일치시키세요.

간단한 출시 체크리스트:

• 사실, 용어, 링크 및 문서 버전을 확인하세요.
• 기술, 토큰 및 필요한 법적 검토를 받으세요.
• 데스크톱과 모바일에서 파일을 테스트하고 접근성을 확인하세요.
• 승인된 버전을 게시하고 향후 업데이트를 소유할 사람을 기록하세요.

작성 능력이 제약이라면 백서 및 라이트페이퍼 작성의 범위를 검토하거나 백서 가격 가이드와 산출물을 비교하세요. 올바른 범위는 준비된 소스 자료의 양과 검토해야 할 기술 소유자의 수에 따라 달라집니다.

가격

USD 기준 시작 가격입니다. 맞춤 번들 및 볼륨 할인은 요청 시 제공됩니다. USDT, USDC, BTC, ETH, SOL, TON 또는 프로젝트 토큰으로 결제 가능합니다.

이용 방법

1. 문서의 역할 설정주요 독자, 그들의 결정 및 문서가 지원해야 할 행동을 명명하세요. 문서가 대체하지 않을 것을 합의하세요.
2. 소스 자료 수집 및 검증제품, 아키텍처, 토큰 및 로드맵 정보를 수집하세요. 확인이 필요한 주장에 대한 소유자와 증거 출처를 기록하세요.
3. 개요 구축독자가 필요로 하는 순서로 섹션을 배열하세요. 프로젝트의 설명이나 청중에 도움이 되지 않는 제목을 제거하세요.
4. 초안 작성 및 검토주요 논증을 작성한 다음 기술 및 토큰 소유자에게 사실과 가정을 확인하도록 요청하세요. 카피에디팅 전에 상충되는 세부 사항을 해결하세요.
5. 승인 및 유지 관리승인된 소스에 대해 최종 파일, 링크 및 버전을 확인하세요. 프로젝트 세부 사항이 변경될 때 업데이트할 소유자를 지정하세요.