한국 거래소가 토큰 상장 전 검토하는 사항

한국 거래소는 상장 전 무엇을 확인하나요?

한국 암호화폐 거래소 상장 심사는 일반적으로 프로젝트의 주장, 기록 및 운영 세부 정보를 검토하고 이해할 수 있는지 확인하는 것을 의미합니다. 아래 카테고리를 모든 거래소가 공유하는 공식 체크리스트가 아닌 준비 지도로 간주하세요.

1. 프로젝트 신원: 법인명, 책임 연락처, 프로젝트 이력 및 공식 커뮤니케이션 채널.
2. 토큰 설계: 목적, 네트워크, 계약 세부 정보, 공급량, 할당 및 릴리스 일정.
3. 기술 및 보안: 계약 문서, 가능한 경우 감사 자료, 알려진 사고 또는 변경 사항.
4. 시장 및 운영: 토큰이 거래되는 곳, 사용자 접근 방식, 지원 및 공개를 담당하는 사람.
5. 위험 커뮤니케이션: 중요한 제한 사항, 종속성 및 정보 보유자가 추론하지 않아도 되는 사항.

각 항목에 대해 단일 진실 공급원(진실 공급원)으로 시작하세요. 웹사이트, 프레젠테이션, 토큰 문서 및 공개 게시물이 서로 다른 공급량이나 책임을 설명하는 경우, 접촉 전에 불일치를 해결하세요. 검토자는 주장에서 이를 뒷받침하는 기록까지 명확한 경로가 필요합니다. 프로젝트 개요에는 평이한 언어를 사용하고, 필요한 경우 기술적 세부 사항은 질문에 대해 유지하세요.

어떤 프로젝트 및 토큰 기록을 준비해야 하나요?

프로젝트의 신원, 토큰 구조 및 주요 주장을 추적할 수 있는 기록을 준비하세요. 문서의 양보다 완전성이 중요합니다. 각 파일은 명확한 목적과 이에 대한 질문에 답변할 수 있는 담당자가 있어야 합니다.

1. 프로젝트 프로필: 엔티티 및 팀 정보, 공식 링크, 제품 상태 및 거래소 커뮤니케이션을 담당하는 연락처.
2. 토큰 참조: 네트워크, 계약 주소, 토큰 목적, 공급량 정의, 할당 카테고리 및 잠금 해제 일정.
3. 지원 자료: 기술 문서, 가능한 경우 보안 평가, 관련 계약 업데이트 기록.
4. 공개 세트: 알려진 위험, 종속성, 중요한 변경 사항 및 업데이트가 게시되는 채널.
5. 증거 색인: 파일 이름, 지원하는 내용, 최종 검토 날짜 및 수정 책임자.

패키지를 보내기 전에 모든 숫자와 고유 명사를 권위 있는 출처와 대조 확인하세요. 수치가 변경된 경우, 이전 파일을 조용히 교체하지 말고 무엇이 언제 변경되었는지 설명하세요. 문서가 실제로 감사를 나타내지 않는 한 평가를 감사로 표시하지 마세요. 간결하고 내부적으로 일관된 패키지는 후속 조치를 용이하게 하고 팀원들이 동일한 질문에 다르게 답변할 가능성을 줄입니다.

토큰경제학과 프로젝트 운영은 어떻게 설명해야 하나요?

토큰경제학을 검증 가능한 관계의 집합으로 설명하세요: 공급량이 어떻게 정의되는지, 각 할당을 누가 통제하는지, 어떤 이벤트가 유통 가능 공급량을 변경할 수 있는지. 검토자가 정확한 답변을 필요로 할 때 프로모션 요약에 의존하지 마세요.

1. 총 공급량을 명시하고 이 수치가 변경될 수 있는지 설명하세요.
2. 할당 카테고리와 각각을 담당하는 엔티티 또는 지갑을 식별하세요.
3. 베스팅 및 잠금 해제 조건을 기본 문서와 일치하는 언어로 설명하세요.
4. 관리 통제, 계약 권한 및 계획된 마이그레이션이나 업그레이드를 설명하세요.
5. 운영 세부 사항을 확인하거나 출처 기록을 제공할 수 있는 사람을 지정하세요.

운영 질문의 경우 각 기능을 담당자에 매핑하세요: 계약 유지보수, 보안 연락처, 사용자 지원, 공개 발표 및 사고 커뮤니케이션. 기능이 제3자에 의해 처리되는 경우, 해당 관계를 정확히 명시하고 팀이 통제하는 것을 식별하세요. 백서, 웹사이트 및 신청 자료 전반에 걸쳐 동일한 용어를 사용하세요. 거래소의 신청 절차에 대한 질문의 경우, 하나의 공개 양식이 모든 검토를 포괄한다고 가정하지 말고 지원 문서를 제공할 준비를 하세요. 관련 중앙화 거래소 상장 지원은 접촉 작업 및 제출 자료 구성을 도울 수 있습니다.

팀은 한국 거래소의 후속 질문에 어떻게 대비할 수 있나요?

답변을 추적 가능하게 만들고, 담당자를 지정하며, 확인된 사실과 미해결 항목을 분리하여 후속 조치에 대비하세요. 이를 통해 프로젝트가 모든 거래소가 동일한 신청 절차를 사용한다고 암시하지 않고 일관되게 응답할 수 있습니다.

1. 출시 사양(Launch Spec) 구축: 프로젝트, 토큰, 책임 연락처 및 지원 문서를 하나의 작업 브리핑으로 요약하세요.
2. 사양 검토(Spec Review) 실행: 브리핑을 공개 자료와 비교하고 충돌, 누락된 출처 또는 불명확한 용어를 식별하세요.
3. 질문 담당자 지정: 법률, 기술, 토큰 및 커뮤니케이션 질문을 직접 지식이 있는 사람에게 라우팅하세요.
4. 각 응답 기록: 질문, 답변, 증거 링크, 담당자 및 후속 조치를 함께 유지하세요.
5. 패키지 업데이트: 사실이 변경될 때 영향을 받는 파일을 업데이트하고 현재 버전을 명확히 표시하세요.

접촉 전에 링크가 작동하는지, 계약 세부 정보가 올바르게 복사되었는지, 프로젝트의 공식 채널이 팀에 의해 통제되고 있는지 확인하세요. 제품 상태와 사용자가 현재 할 수 있는 작업에 대한 간단한 설명을 준비하고, 사용 가능한 기능과 로드맵 계획을 구분하세요. 한국어 자료가 신청의 일부인 경우, 유창성뿐만 아니라 기술적 의미도 확인할 수 있는 검토자를 사용하세요. 현지 커뮤니케이션 계획의 경우, 한국 KOL 캠페인 지원은 별도 채널이며 정확한 신청 증거를 대체하지 않습니다.

팀이 한국 거래소에 어떤 질문을 해야 하나요?

거래소에 현재 신청 경로와 팀이 제공해야 하는 사항을 명확히 해달라고 요청하세요. 다른 프로젝트의 경험이나 오래된 체크리스트에서 요구 사항을 추론하는 것보다 직접적인 답변이 더 유용합니다.

• 현재 신청 채널이나 초기 문의를 위한 지정 연락처가 있습니까?
• 첫 번째 단계에 어떤 프로젝트, 토큰, 엔티티 및 기술 기록을 포함해야 합니까?
• 거래소는 특정 언어나 형식의 문서를 원합니까?
• 초기 패키지 이후 팀은 어떻게 수정 사항을 제출하거나 질문에 응답해야 합니까?
• 토큰, 계약 또는 프로젝트 정보가 변경될 경우 어떤 세부 정보를 최신 상태로 유지해야 합니까?

질문을 간결하고 사실적으로 유지하세요. 용어가 모호한 경우 설명을 요청하고 중요한 지침은 서면으로 확인하세요. 확인되지 않은 연락처를 통해 민감한 자료를 보내지 말고, 기밀 정보를 공유하기 전에 채널이 거래소에 속하는지 확인하세요. 프로젝트는 제출물의 정확성, 구성 및 응답성을 통제할 수 있습니다. 거래소는 자체 검토 범위, 요청, 적격성 평가 및 상장 결정을 통제합니다. 준비 서비스나 완전한 문서 패키지도 승인이나 특정 검토 결과를 보장할 수 없습니다.

실사 패키지가 준비된 후에는 어떻게 해야 하나요?

패키지가 일관되면, 일회성 신청 첨부 파일이 아닌 유지 관리되는 기록으로 사용하세요. 한 사람을 지정하여 출처 문서를 최신 상태로 유지하고 프로젝트의 사실이 변경될 때마다 답변을 조정하세요.

거래소가 프로필 불일치를 식별하는 경우, 먼저 출처 자료를 수정한 다음 영향을 받는 공개 프로필을 업데이트하세요. 상장 프로필 정정은 이러한 정리를 지원할 수 있으며, 탐색기의 토큰 정보 및 로고 업데이트는 별도의 노출 작업을 다룹니다. 이러한 서비스는 정의된 준비 또는 프로필 작업을 지원하지만 거래소 자체 평가를 대체하지는 않습니다. AEOTech에 프로젝트 개요, 토큰 참조, 현재 공개 링크 및 이미 받은 질문을 보내주세요. 자료를 검토하고 격차를 식별하며 범위가 지정된 다음 단계를 제안할 수 있습니다.