3つのプロダクト形式に対応する仮想通貨ウォレット開発

3つのウォレット画面、1つのキックオフチェックリスト

3つのウォレット画面が検討対象です：ブラウザ拡張、モバイルアプリ、Telegramミニアプリ。まずユーザーニーズと主要な責任範囲を確定します。

実装の予約前に、以下の7つの入力をお送りください：

• ユーザー：誰がウォレットを必要とし、どのようなタスクで利用するか？
• カストディ：カストディアル、ノンカストディアル、または未定か？
• キー管理：各キー関連操作を誰が制御するか？
• ネットワーク：最初のリリースで必要なチェーンとアセットは？
• アクション：送金、スワップ、またはその両方か？
• 形式：ブラウザ拡張、モバイルアプリ、Telegramミニアプリ、または組み合わせか？
• 既存作業：デザイン、統合、バックエンドコンポーネント、セキュリティノートは？

これらの回答により、最初のリリースの焦点が定まります。決定なしに機能リストが拡大するのを防ぎます。入力を明確なプロダクト境界に変換します。後回しにする内容も含みます。

ウォレット操作がdAppに接続する場合は、dApp開発と要件を整合させてください。ウォレットがプロジェクトアセットに依存する場合は、トークン作成とデプロイを同じプロダクト検討に追加してください。

どのカストディモデルがウォレットユーザーに適していますか？

2つのカストディモデルは異なるプロダクト責任を生みます：カストディアルとノンカストディアルです。画面、アカウントフロー、運用タスクを承認する前に、キー管理を誰が制御するかを決定してください。

カストディアルウォレットは、キー管理をプロダクトの運用モデル内に置きます。これは、チームがユーザーアクセスと関連業務を管理するサービスに適しています。

ノンカストディアルウォレットは、キー管理をユーザーに委ねます。そのインターフェースは、その責任を明確に示す必要があります。また、復元体験もわかりやすくする必要があります。

以下の3つの判断で方向性を選択してください：

• 制御：キー関連操作の責任者は誰か？
• 復元：ユーザーがアクセスを失った場合、何を理解すべきか？
• 運用：リリース後、チームがサポートすべきことは？

次に、各ウォレット操作をエントリーから確認までマッピングします。送金とスワップについては、ユーザーが確認前に見る内容を定義します。また、操作が完了できない場合に表示される状態も定義します。決定事項を平易なプロダクト言語で記録します。

コントラクト作業も必要な場合は、ウォレット要件をスマートコントラクト開発に接続してください。より広範なプロダクト内のウォレットは、Web3開発とともに計画できます。

3つの形式、異なるウォレット作業

3つの形式は、異なるインターフェースと統合ニーズを形成します。ユーザーの主要タスクに基づいて最初のリリースを選択してください。その後、サポートするネットワークとアクションを正確に指定します。

マルチチェーン対応は、広範な主張ではなく、名前付きのネットワークリストとして扱います。各ネットワークについて、ユーザーが必要とするウォレット操作を指定します。スワップは別のフローとして保持します。ユーザー向けの手順、必要な統合、確認詳細を特定します。これにより、最初のリリースの決定が容易になります。

モバイルファーストのプロダクトについては、Web3プロダクト向けモバイルアプリ開発で関連ニーズを比較してください。ウォレットインターフェース以外のTelegram機能については、Telegramボットとミニアプリ開発を確認してください。

プロダクト概要から納品までの5つの段階

5つの段階でウォレット構築をレビュー可能にします：プロダクト入力、リリース決定、設計、実装、納品です。構築作業開始前に作業内容を確認します。

1. プロダクト入力： 対象ユーザー、カストディの方向性、形式、ネットワーク、主要アクションを共有します。
2. リリース決定： 必須機能と後日追加機能を分離します。未解決の質問に対する統合と担当者を記録します。
3. 設計： アカウント、トランザクション、スワップの手順をマッピングします。ユーザーが確認すべき内容を含みます。
4. 実装： 合意されたインターフェースとウォレット機能を構築します。必要なバックエンドまたはモニタリングコンポーネントを追加します。
5. レビューと納品： 合意された要件に対して構築内容を確認します。未完了項目と次のアクションをリスト化します。

プロダクト詳細を確認後、2営業日以内に書面の見積書をお送りします。入金確認から24時間以内に作業を開始できます。キックオフ前に、DigitalMedia1はカストディ、対象形式、ネットワークリスト、ユーザー操作、レビュー担当者を1つの短いチェックリストで確認します。

納品期間中は、合意された機能に対する進捗を記録します。変更は追加前に報告します。納品時には、完了した作業、未解決の質問、セキュリティレビューの準備状況が明確に記録されます。既存のデザインと統合ノートをお持ちください。最初のリリースをより迅速に特定するのに役立ちます。

ウォレットリリース前に決定すべきことは？

4つのリリースチェックが重要です：キー責任、サポートアクション、運用担当、レビューステータス。それぞれを、ユーザーが操作するウォレットに対して確認してください。

リリース前に、以下を確認します：

• インターフェースがカストディモデルとユーザー責任を説明していること。
• トランザクションとスワップの手順が承認されたプロダクト動作と一致していること。
• チームが運用するバックエンドとモニタリングタスクを把握していること。
• セキュリティレビューの質問に担当者とフォローアップアクションが割り当てられていること。

カストディアルプロダクトの場合、リリース前に顧問弁護士が規制上の分類を確認する必要があります。開発には、合意されたセキュリティレビューと監査準備を含めることができます。外部監査プロバイダーは独自の所見を管理します。ネットワーク状況やサードパーティ統合の可用性も、構築チームの管理範囲外です。

ウォレットがより大規模なアプリケーションの一部である場合は、次のリリースをdApp開発と整合させてください。また、Web3開発でより広範な構築を計画することもできます。プロダクト概要、希望するカストディモデル、対象形式、最初のリリースのネットワークをお送りください。チェックリストを確認し、書面の構築計画を返送します。

仕組み

1. ウォレット入力を送信対象ユーザー、カストディの方向性、納品形式、ネットワーク、必須アクションを共有します。
2. 最初のリリースを設定トランザクションとスワップのニーズ、統合、バックエンド作業、モニタリングの期待値を確認します。
3. ユーザーフローをマッピング実装前に画面、主要操作、確認状態を合意します。
4. 構築とレビュー合意された機能を実装し、記録された要件に対する進捗を確認します。
5. 納品準備完了した作業、未完了項目、顧問弁護士や監査プロバイダーへの質問をレビューします。