トークン作成デプロイ：ERC-20、BEP-20、SPL、Jetton対応

どのトークン規格があなたのプロダクトに適していますか？

適切なトークン規格とは、アプリケーション、ユーザー、運用モデルに合ったものです。まずトークンがどこで使用され、何を行う必要があるかを確認し、その後、要求されたデプロイに対してERC-20、BEP-20、SPL、Jettonのいずれが適切かを判断します。

有用なキックオフ概要は、以下の質問に答えるものです：

• どのネットワークとアプリケーションがトークンを認識する必要がありますか？
• 供給量はデプロイ時に固定ですか、それとも後で承認されたアカウントが供給量を追加または削除できる必要がありますか？
• 転送制限、管理ロール、その他のカスタム動作は必要ですか？
• どのウォレット、エクスプローラー、プロダクト画面でトークン情報を表示する必要がありますか？

これらはエンジニアリングの選択であると同時にプロダクトの判断でもあります。コントラクトの範囲、テスト、デプロイの調整、そしてチームがその後管理すべきことに影響します。要件が確定していない場合は、開発を始める前に、暗黙の前提をコントラクト動作に変換するのではなく、未決定の事項を特定します。

実装オプションの詳細については、Web3開発およびスマートコントラクト開発をご覧ください。トークンがアプリケーションの一部である場合は、dApp開発と併せて範囲を定義できます。構築パスを推奨する前に、トークンの意図された役割と依存関係を確認します。

デプロイと検証はどのように行われますか？

デプロイは、合意されたトークン実装を選択したネットワークに配置することです。検証は、該当するエクスプローラーが対応しており、かつ範囲に含まれている場合の、別個の引き継ぎタスクです。レビュー済みのコントラクト仕様に基づいて両方を計画するため、デプロイされたバージョンをプロジェクトが承認したものと照合できます。

作業の順序は意図的に決められています。規格と動作を確認し、実装を準備し、デプロイ可能なバージョンをレビューし、デプロイアクセスを調整し、結果のアドレスと関連する参照情報を記録します。チームは、デプロイの認証情報と管理権限を誰が管理するかを事前に決定する必要があります。合意されたデプロイを完了するために、プロジェクトアカウントの恒久的な管理権限は必要ありません。

メタデータは、後付けの飾りとしてではなく、合意された要件に従って準備されます。概要には、表示名、ティッカー、精度または表示規則、対象となる画面で必要なロゴや説明資料を含める必要があります。SPLおよびJettonのリクエストについては、すべてのネットワークが同じように情報を表示するとは想定せず、スコープ定義時に該当するトークン固有のメタデータとデプロイの期待値を確認します。

引き継ぎでは、デプロイされたコントラクトまたはトークンの参照情報、ネットワーク、選択された動作、検証作業の状況を特定します。プロダクトにユーザー向けインターフェースも必要な場合は、公開前にトークンの詳細をWeb3ウェブサイトおよびランディング開発と調整してください。

トークン納品には何が含まれますか？

トークン納品は定義されたエンジニアリング範囲であり、ローンチに関連するすべての機能を構築するという無制限の約束ではありません。作業開始前に、規格、コントラクト動作、デプロイ責任、引き継ぎ項目を合意し、その範囲に対する変更を追跡します。

典型的なプロジェクト範囲には以下が含まれます：

• 要件レビューと文書化されたトークン仕様
• 合意された規格と要求された動作に対するコントラクト実装
• 承認された仕様に対するレビューとテスト
• デプロイ調整とデプロイ参照情報
• 合意されたプロダクト画面のためのメタデータ準備
• 対応しており範囲に含まれる場合の検証作業
• コントラクトアドレス、ネットワーク、制御、未処理のオーナーアクションをカバーする引き継ぎノート

最も重要な成果物は、コントラクトが何を行い、誰がそれを操作できるかについての明確さです。プロジェクトがミント、バーン、一時停止、管理権限を要求する場合、どの動作が含まれ、どの役割が責任を持つかを文書化します。仕様で承認されていない機能は、黙って追加されることはありません。

別個のアプリケーション、ウォレットフロー、またはコントラクトシステムを必要とする作業は、別個のコンポーネントとして範囲を定義する必要があります。トークン構築をdApp開発やTelegramボットおよびミニアプリ開発と連携させることは、それがプロダクト計画の一部である場合に可能です。キックオフ前に、合意された範囲とチームが提供すべき項目の明確なリストをお受け取りいただきます。

トークンプロジェクトは概要から引き継ぎまでどのように進みますか？

トークンプロジェクトは、文書化された判断とレビューゲートを通じて進むため、デプロイは単一の技術的な引き継ぎとして扱われません。MediaStrategyのシニアプロジェクト担当者が範囲レビューを担当し、未解決のプロダクト判断が実装に影響を与える前に可視化します。

キックオフチェックリストは、対象の規格、ネットワーク、供給動作、管理権限、メタデータ、デプロイアクセス、検証の期待値をカバーします。これを使用して、確定した要件とお客様の判断が必要な項目を分離します。その後、仕様は両チームに実装とレビューのための共通の参照を提供します。

開発中、レビューは作業がその仕様に一致しているかに焦点を当てます。チームはデプロイ前に提案された動作をレビューでき、デプロイ自体はキックオフで合意されたアカウントアクセスと承認に基づいて調整されます。その後、引き継ぎは参照情報とオーナーアクションを記録し、プロジェクトが何が稼働中で何が未完了かを把握できるようにします。

スケジュールは、要件とレビュー責任が明確になった後に設定されます。標準的な実装と追加動作のあるカスタムコントラクトでは、レビューの必要性が異なります。より広範なローンチ作業を計画しているプロジェクトは、技術的な引き継ぎをTGEサポートやトークノミクス計画と別個の範囲として調整してください。

トークンデプロイ前に何を確認すべきですか？

デプロイ前に、仕様、アクセス計画、プロジェクトメタデータがレビューの準備ができていることを確認してください。短いデプロイ前チェックにより、チームが実装を承認した後に、コントラクト範囲や公開トークン詳細への回避可能な変更を防ぐことができます。

プロジェクトオーナーは、選択したネットワークと規格、初期供給動作、要求された管理権限、デプロイ認証情報の責任者、準備する正確なメタデータを確認できる準備をしておく必要があります。また、デプロイ可能なバージョンを誰がレビューし、誰が引き継ぎ資料を受け取るかも決定してください。トークンの詳細がまだ変更中の場合は、プロジェクトに安定した意思決定者と承認された仕様ができるまで、デプロイをクリティカルパスから外しておいてください。

範囲は合意されたトークン作業のためであり、外部プラットフォームの成果を約束するものではありません。ネットワーク状況はトランザクションが確認されるタイミングに影響を与える可能性があり、エクスプローラーの検証や表示処理は該当プラットフォームによって制御されます。合意されたデプロイ作業を提供することはできますが、それらのレビューや表示判断を制御することはできません。

技術作業後の上場準備については、上場と検証をご確認ください。開始するには、目的のネットワーク、トークン動作、メタデータ要件、未解決の決定事項をお送りください。MediaStrategyが範囲計画を返送し、実装前に承認が必要な事項を特定します。

料金

開始価格はUSD表示です。カスタムバンドルやボリュームディスカウントはご相談ください。USDT、USDC、BTC、ETH、SOL、TON、またはプロジェクトトークンでのお支払いが可能です。

仕組み

1. プロジェクト概要を共有使用目的、対象ネットワーク、希望する規格、既存の技術資料をお送りください。供給量や権限について仮定せず、未解決の質問も含めてください。
2. 仕様を確認トークン動作、メタデータ、デプロイ責任、検証の期待値を文書化します。チームが実装前に範囲をレビューし承認します。
3. 実装とレビュー合意されたコントラクトを準備し、承認された仕様に照らして確認します。要求された変更は、組み込む前に範囲への影響をレビューします。
4. デプロイを調整合意されたアカウントアクセスとプロジェクト承認に基づいてデプロイをスケジュールします。引き継ぎのためにネットワークとデプロイされたトークン参照情報を記録します。
5. 引き継ぎを完了合意されたデプロイとメタデータ参照情報、範囲に含まれる場合は検証状況、制御とオーナーアクションに関する簡潔なノートをお受け取りいただきます。