コントラクト移行でトークンのアイデンティティを明確に保つ

移行は単なる新しいトークンラベル以上のもの

コントラクト移行サポートは、人々が参照するプロファイル全体で古いトークン詳細と新しいトークン詳細を結びつけます。プロジェクトが名前、ティッカー、ロゴを変更する際に、コミュニティがどのコントラクトが最新かを認識するのに役立ちます。

最初の有用なタスクは、何が変わり、何が変わらないかを決定することです。両方のコントラクトアドレスとチェーンを記録し、名前、ティッカー、ロゴ、公式プロジェクトリンクを確認します。トークンのアイデンティティが同じままである場合は、その関係を平易に説明します。プロジェクトがコントラクト以上のものを変更している場合は、各変更を個別に明確に記述します。

チームがロゴとティッカーを変更しても同じコントラクトを維持するとします。その場合、移行の説明ではなく、焦点を絞ったプロファイル更新が必要です。コントラクトも変更される場合、リクエストは新旧のアドレスを結びつけ、移行を説明する必要があります。どちらの種類の更新も調整可能で、作業は確認したいプラットフォームと詳細に基づきます。DEXToolsとDEXScreenerでのその他のプロファイル変更については、DEXToolsおよびDEXScreenerプロファイル更新を参照してください。

承認済み移行記録から始める

共有記録により、すべてのプラットフォームリクエストに同じソース事実が提供されます。提出前にレビューするため、不足している詳細は推測ではなくチームと解決できます。

1. 変更を確認する。 新旧のコントラクトアドレス、チェーン名、移行段階を追加します。ユーザーが最新として扱うべきコントラクトと、計画に移行期間が含まれる場合はその変更時期を明記します。
2. トークンのアイデンティティを承認する。 表示用の正確な名前とティッカーを記述します。現在のロゴファイル、プロジェクトウェブサイト、公式ソーシャルリンクを追加します。記録と公開資料全体でスペルを一貫させます。
3. 関連性を示す。 利用可能な場合は公開移行説明と、事実を確認したり質問に回答できるプロジェクト担当者を含めます。循環供給量情報も変更される場合は、それを別のタスクとして特定します。循環供給量検証がその作業をカバーします。

各アドレスを承認済みプロジェクト記録と一文字ずつ照合します。次に、ウェブサイト、アナウンス、エクスプローラーの詳細を記録と比較します。この単純な比較を使用して、リクエストが送信される前に不一致を特定します。チームが最終事実を承認し、その承認バージョンから各プラットフォームリクエストを作成します。

トラッカーとスクリーナーの更新はどう違うのか？

CoinMarketCap、CoinGecko、DEXTools、DEXScreenerには個別のプロファイルと更新ルートがあります。1つのアナウンスですべての公開表示が変更されるとは想定せず、合意された各遷移先に対してリクエストを作成します。

CoinMarketCapとCoinGecko

これらのプロファイルについては、要求された名前、ティッカー、ロゴ、コントラクトコンテキストを、変更を説明するプロジェクト資料とともに整理します。移行更新以外のサポートも必要な場合は、CoinMarketCap上場サポートとCoinGecko上場サポートを参照してください。

DEXToolsとDEXScreener

どのトークンまたはペアの詳細が表示されているかを確認し、注意が必要なプロファイル情報を特定します。プロファイル編集と移行アナウンスは異なるタスクであるため、リクエスト内で明確に区別します。

各遷移先を個別に追跡します。これにより、チームは何が提出され、何が表示され、何がまだ返信を必要としているかを把握しやすくなります。より広範なトラッカーカバレッジについては、他の暗号トラッカーへの上場を別途検討できます。プラットフォームが異なるタイミングで変更を表示しても、更新記録は有用です。

リクエスト送信後も引き継ぎを明確に保つ

作業には、リクエストの記録と公開プロファイルに表示される内容の確認が含まれます。これにより、チームはコミュニティメッセージと移行サポートを調整する際に使用できる具体的な成果物を得られます。

良いスレッドで新しい顔ぶれが来た直後に、投稿ではなくドキュメントを書く開発者を想像してください。開発者は、新しいユーザーが古いメッセージを検索しなくても正しいコントラクトを見つけられるようにしたいと考えています。私たちは承認済み移行事実を確認し、プロファイルリクエストを作成し、その後表示されている内容を報告します。

引き継ぎには以下を含めることができます：

• 合意された作業に含まれるプラットフォームとプロファイル詳細。
• 提出されたリクエストとプラットフォームフォローアップの記録。
• 表示された変更、未解決項目、プロジェクト側のアクションのメモ。

各プラットフォームは、自身のプロファイル変更の可否、タイミング、方法を決定し、説明を求める場合があります。合意された準備、調整、確認を提供できますが、プラットフォームの審査時間を設定したり承認を約束することはできません。質問に回答できる担当者を1名用意し、関連する公開プロファイルを確認した後にのみ変更を完了として説明してください。

同じトークン事実を広範なロールアウトに反映させる

プロファイル更新は、残りの移行資料が同じストーリーを伝える場合に最も効果的です。ウェブサイト、アナウンス、エクスプローラー情報、コミュニティ返信は、同じ最新コントラクトを指し、承認された名前とティッカーを使用する必要があります。

コミュニティモデレーターが、あるプロファイルにまだ以前の詳細が表示されている間に質問を受けたとします。共有移行記録は、承認された説明と最新のプロジェクトリンクで回答するのに役立ちます。また、プロダクトリード、コミュニケーションリード、プラットフォーム担当者が変更の異なるバージョンを送信するのを防ぎます。

この作業は、エクスプローラートークン情報とロゴ更新やウォレットロゴとトークンリストへの掲載と並行して調整できます。より広範な上場と検証計画もロールアウトの一部にできます。これらは別個のタスクであるため、適合する場合のみ含めます。

開始するには、新旧のコントラクトアドレス、チェーン、対象プラットフォーム、承認済みトークン詳細、移行アナウンスまたはドラフトをお送りください。Brand Communityが記録を確認し、不足している事実を指摘し、承認のためにプラットフォームリクエストをマッピングします。

仕組み

1. 変更が必要なプロファイルを合意するプラットフォームと要求されたコントラクト、ティッカー、名前、ロゴの更新をリストアップします。チームが承認済みソース事実を確認します。
2. 移行資料を収集する説明、プロジェクトリンク、ロゴファイル、質問用の担当者を共有します。リクエスト作成前に不一致を指摘します。
3. 各プラットフォームリクエストを作成するリクエストを変更されるプロファイル詳細に合わせ、事実をチームと共有して承認を得ます。
4. 提出と返信を調整する合意されたリクエストを該当ルートを通じて調整し、フォローアップの質問と回答を記録します。
5. 公開プロファイルを確認するどの変更が表示され、どの項目が保留中で、チームが対応する必要があるかを記録します。