テンプレート概要
CORP-PRIVATE-STDは、複数オーナーのチーム向けにdCorpsで標準となるプライベート会社セットアップです。公開会社プロフィール、コアのウォレットセット、そして管理・トレジャリー・承認権限を分離するロール紐付けを作成します。重要なアクションは複数オーナーの共同署名で実行されるため、単一ウォレットがすべてを支配する状態を避けつつ、公開ビューはシンプルで、オンチェーンで検証しやすい形を保てます。
テンプレートコード
テンプレートコード: CORP-PRIVATE-STD。このラベルにより、アプリ、リンク、公開ビューでテンプレートが一貫します。
共有権限
1つのエンティティIDに対し、複数のオーナーウォレットが権限を共有します。保護アクションには共同署名の承認が必要です。
共有ユニット
所有ユニットは複数の保有者に分割され、移転は設計上、承認ルールに従います。
標準ウォレット種別
収益、支出、リザーブを標準種別で分離し、権限ウォレットがトレジャリー承認に署名します。
タグ付きフロー
支払いにはタグを付け、資金が動いた理由と、どの承認経路が使われたかを示します。
テンプレートの位置づけ
CORP-PRIVATE-STDは、単独テンプレートと高度なガバナンステンプレートの中間に位置します。構造をシンプルに保ちつつ、共有承認と職務分離を追加します。コントロールが1人のオーナーに集約されたらCORP-SOLOへ簡素化し、ガバナンスが拡張するならCORP-VENTUREまたはCORP-COMPLEX-PRIVATEへ移行します。
単独テンプレート
承認が1人のオーナーで完結し、共同サインオフが不要になったらCORP-SOLOに簡素化します。
ベンチャーテンプレート
理事会ガバナンス、投資ラウンド、複数クラスのエクイティが必要ならCORP-VENTUREへ移行します。
複合プライベート
委員会、重要事項の保護、またはマルチエンティティの保有構造が必要ならCORP-COMPLEX-PRIVATEへ移行します。
最適な対象
CORP-PRIVATE-STDは、2名以上のオーナーを持ち、定常的な運用支出があるプライベート会社に適します。創業者チーム、スタジオ、同族企業など、明確なロール、定常承認、ステーブルコインネイティブの支払いを求める組織に向きます。日常の作業は素早く進めつつ、影響の大きいアクションは共同署名で制御できます。
共有承認
保護アクションは少なくとも2名の署名を必要とし、意思決定を共有しつつ説明責任を保てます。
ステーブルコインネイティブ
入出金は銀行レールではなくステーブルコインで行い、フローをオンチェーンに保ちます。
職務分離
管理とトレジャリーのロールを分離し、同一ウォレットが同じアクションを作成して承認することを防ぎます。
運用チーム
定常支出と承認があるチーム向けに、重い運用負担を増やさず、ロールを明確化します。
不向きなケース
このテンプレートは、承認が不要な単独オーナー構造には向きません。また、ベンチャー型の理事会運用や複数クラスのエクイティにも対応する設計ではありません。定常承認を前提とした共有コントロールのため、より複雑なガバナンスが必要な場合は上位テンプレートを選ぶべきです。寄付主導の団体は、資金調達と配分に設計された非営利テンプレートに適合します。
単独構造
すべてを1つのウォレットでコントロールし、承認を設けないならCORP-SOLOが適合します。
ベンチャー構造
理事会主導の資金調達ラウンドや複数クラスのエクイティにはCORP-VENTUREが適合します。
非営利モデル
非営利は寄付と配分のワークフローで運用されるため、資金調達に設計された非営利テンプレートに適合します。
所有権とユニット
複数の保有者がいても比率が分かるように、持分をベースユニットで表現します。ユニットの移転や発行は承認アクションを経由するため、所有権の変更は制御され、オンチェーンで追跡できます。将来、精度が必要になれば、既存の比率を変えずにベースユニット数を増やせます。
デフォルトのベースユニット
開始は10,000ベースユニットで、複数保有者でも持分の分割が読みやすくなります。
1ユニット=1票
デフォルトではユニット保有に応じて投票し、ガバナンスで変更しない限り、各保有者の票数はユニット比率に一致します。
精度の拡張
後からベースユニットを追加して精度を上げても、各保有者の割合は同じままです。
権限とガバナンス
管理、トレジャラー、承認者のロールを分離し、単一のウォレットが同じアクションを作成して承認できないようにします。保護アクションは共同署名の承認を必要とし、各意思決定は可視のトレイルとして残ります。ロール変更や鍵のローテーションもオンチェーンに記録されるため、現在の権限が明確です。
ロール分離
管理、トレジャラー、承認者のロールをウォレット間で分離し、コントロールと実行を切り分けます。
承認レイヤー
承認者ロールが、保護対象のトレジャリー/ポリシーアクションに共同署名し、説明責任を共有します。
鍵ローテーション
ガバナンスアクションで鍵を更新できるため、アクセス変更は公開され、追跡可能になります。
保護アクション
機微なアクションは、資金移動やポリシー変更の前に複数の承認が必要です。
従業員ロールウォレット
ロールウォレットを使えば、承認は指定された承認者に残したまま、作業を委任できます。オペレーターは請求書の準備、支払いのタグ付け、支出の下準備を行い、資金が動く前に承認者が署名します。作業は進めつつ、説明責任は共有されたままです。
ロール種別
チームの役割に応じて、オペレーター、会計、承認者、支払い実行者などのロールウォレットを設定できます。
スコープ付き権限
請求、タグ付け、支払い準備は許可しつつ、必要な承認が署名するまで実行はブロックする、といった設計ができます。
受領者の分離
受領者ウォレットは資金を受け取り、会社が両者を紐付けない限り、ロールウォレットが権限を担います。
委任と承認上限
承認上限を設定して、自動で走るものと共同署名が必要なものを定義します。二重統制の閾値により、大きな移転は承認者の署名を待ち、定常支払いは素早く通せます。上限はウォレットやカテゴリごとに変えられるため、チームや活動に合わせたガードレールを適用できます。
ロールのスコープ
各ロールには明確なスコープがあり、準備・承認・実行できるアクションが定義されます。
承認閾値
金額やリスクレベルに応じて、共同署名の承認を発火させる条件を定めます。
ウォレット/カテゴリ別上限
ウォレット種別や支出カテゴリごとに上限を調整し、活動ごとに異なるガードレールを適用できます。
ウォレット構造
目的別に資金を分け、活動を追いやすくします。顧客支払いを受け取るウォレット、運用支出を担うウォレット、貯蓄を保持するリザーブウォレットを用意できます。権限ウォレットは承認に署名し、支払いウォレットが受領と送金を行います。コントロールをキャッシュから分離することで、活動を検証しやすくなります。
マーチャントウォレット
ウォレット種別 MERCHANT は、顧客収益が入る公開支払いウォレットです。
運用トレジャリー
ウォレット種別 OPERATING_TREASURY は、日常の事業支出と、ベンダー/委託先への支払いを扱います。
リザーブウォレット
ウォレット種別 RESERVES は、バッファや長期資金など、取り分けたい資金を保持します。
権限の分離
権限ウォレットには承認のために複数のオーナー署名者を含められます。支払いウォレットが受領/送金を行うため、コントロールを資金から分離できます。
運用資産
レポーティングの合計はUSDCで表示し、値を安定させて比較しやすくします。トレジャリーウォレットには、ガス用途や長期保有のためにDCHUBを保持することもできます。これらの保有はタグ付けされ、サマリーで運用キャッシュと混ざらないようにします。
レポート単位
v0.1のレポーティングはUSDC合計を用い、時間やツールを跨いでもビューが安定するようにします。
トレジャリー保有
ネットワークへのエクスポージャーが必要な場合、トレジャリー/リザーブウォレットにステーブルコインと並べてDCHUBを保有できます。
資産タグ
DCHUB残高には asset_tag と BAL_DCHUB を付け、エクスプローラーが運用キャッシュと分離できるようにします。
ガス支払い
トランザクションを送信するたびに、署名ウォレットがDCHUBで手数料（ガス）を支払います。
コマースと支払いモード
CORP-PRIVATE-STDは直接支払いと請求書の両方をサポートし、顧客が都合の良い方法で支払えます。継続プランはオンチェーンのスケジュール支払いでサブスクリプション請求を扱います。各請求書にはステータスがあり、未払い/支払済み/キャンセルを一目で確認できます。
直接支払い
金額が事前に確定している場合、顧客はマーチャントウォレットへ直接支払えます。
請求書リクエスト
請求書はエンティティに紐づくオンチェーンの支払いリクエストで、金額、期日、支払者参照を含みます。
継続プラン
継続課金をスケジュール化し、サブスクやリテイナーを手動再入力なしで運用できます。
ステータス更新
請求書は未払いから支払済み/キャンセルへ遷移し、ステータスが更新されるため、フォローが明確になります。
カタログアイテム
提供する商品・サービスを一度定義しておけば、事業が成長しても請求と支払いを整理できます。各アイテムには名称、価格、IDがあり、請求書やタグで再利用できます。毎回詳細を打ち直さずに、売上を一貫したビューで把握できます。
アイテム参照
明確なラベルと価格を持つ item_id を作成し、商品・サービスを再利用しやすくします。
コスト基準
任意でコスト基準を追加し、後から推測で埋め戻さずにマージンを見積もれるようにします。
請求書の紐付け
請求書とタグで item_id を使用し、販売活動を合計とビューへ紐付けます。
給与と業務委託フロー
給与や業務委託の支払いにタグを付け、権限ロールと混同せずに報酬を可視化します。受領者ウォレットが資金を受け取り、承認ロールが支払いタイミングを制御します。アプリは給与サイクルに合わせて支払いのスケジュールや一括処理も行えます。
受領者ウォレット
受領者ウォレットが給与や業務委託の支払いを直接受け取り、権限ロールとは分離されます。
タグ付き支払い
支払いに給与/業務委託タグを付け、サマリーで報酬を識別しやすくします。
任意のスケジュール
継続支払いやまとめ払いが必要な場合、アプリまたはSDKでスケジュール/一括処理ができます。
タグ付けとエビデンス
タグは各支払いに付与するシンプルなラベルで、時間が経っても活動を理解しやすくします。重要な取引では、請求書、領収、契約への安全な参照をアンカーして証明を紐付けられます。私的ファイルを公開せずに、明確なトレイルを残します。
必須（コア）
これらのタグはすべてのフローに必須で、ビューの一貫性を保ちます。reference_type は reference_id と組で使用します。
運用コンテキスト
任意タグで、チーム、商品、プロジェクト、チャネルごとに活動を分割し、追跡を明確にします。
エクイティ文脈
クラス、プール、ベスティングなど、後からエクイティのワークフローを追加する場合にのみ適用します。
エビデンスアンカー
文書自体を公開せずに、請求書、領収、契約へリンクします。
マテリアリティ閾値
大きな項目ほどエビデンスが必要になるように閾値を設定します。デフォルトは1,000 USDCです。
取引先ディレクトリとプライバシー
繰り返し取引する顧客やベンダーは、実名ではなく私的なニックネームでラベル付けできます。実世界の対応表は組織の管理下でオフチェーンに保持され、機微なデータを保護します。公開ビューに出るのはタグとウォレットだけで、基礎の身元は露出しません。身元を公開せずに、誰が支払い、誰が受け取ったかの履歴を一貫して追えます。
仮名ID
counterparty_tag を使い、法的名称をオンチェーンに出さずに取引先をラベル付けできます。
オフチェーンの対応表
実名の対応表はオフチェーンに保持し、チームだけが参照できるようにします。
繰り返し取引先
個人情報や事業詳細を公開せずに、請求と支払いを跨いで取引先を追跡できます。
運用フロー
セットアップから本番活動へ、シンプルな順序で移行します。セットアップは、複数のオーナーウォレット、エンティティ名、保護アクションの承認閾値から始まります。エンティティを登録し、ウォレットを接続し、支払いを受け取り、起きたことにタグを付けてビューの一貫性を保ちます。各ステップはオンチェーン履歴に書き込まれ、チームと確認者にとって運用が明瞭になります。
登録とオーナー紐付け
エンティティを登録し、オーナーウォレットに加えて、管理・トレジャラー・承認者ロールを紐付けます。
ウォレットと閾値を設定
標準ウォレットを接続し、承認閾値を設定して、上限を超えるトレジャリーアクションには共同署名が必要になるようにします。
ロールを委任
従業員ロールウォレットと受領者ウォレットを追加し、チームが署名なしで作業準備できるようにします。
収益を受領
請求書を発行するか直接支払いを受け、収益をマーチャントウォレットへ着金させます。
タグ付けとアンカー
入出金にタグを付け、証明が必要な重要項目にはエビデンスをアンカーします。
確認とクローズ
ライブビューを確認し、後で比較できる固定スナップショットが必要なら期間をクローズします。
オンチェーンのライブビュー
エクスプローラーは、タグ付きトランザクションからライブ集計を表示し、手動エクスポートを待ちません。活動に応じて残高、直近の活動、タグのカバレッジを確認できます。第三者も同じ数値を確認できるため、公開可視性が同期します。
ウォレット残高
トランザクションがオンチェーンで確定するたびに残高が更新され、数値が最新のまま保たれます。
期間ビュー
手動のクローズを待たずに、一定期間の活動を集計できます。
カバレッジ比率
どのフローが完全にタグ付けされ、どれが追加文脈を要するかを示します。
データエクスポート
オフライン分析やバックアップなど、チェーン外のファイルが必要な場合にのみ任意で使用します。
レジストリ、ログ、証明
レジストリとガバナンスログで、アイデンティティ、ステータス、公式ウォレット、承認、ロール変更を検証できます。後で証明が必要な文書は、タイムスタンプ付きの安全な参照をアンカーできます。これらを合わせると、書き換えが難しい耐久的な履歴になります。
レジストリエントリ
アイデンティティ、ステータス、公式ウォレットの紐付けを掲載し、誰でも現在のセットアップを検証できます。
ガバナンスログ
承認、投票、ロール変更を時系列に表示し、説明責任を明確にします。
アンカーされた証明
領収や契約にタイムスタンプ付きの参照をアンカーし、ファイルを公開せずに後から存在を検証できます。
ライフサイクルとステータス
シグナルは、会社が稼働中か、一時停止中か、終了しているかを示し、支払いを通すべきか判断できるようにします。アプリは安全の手がかりとしてステータスを自動表示できます。これにより混乱を減らし、非稼働のエンティティへ資金が送られることを防ぎます。
ステータス
一定の配色で、支払いに安全かどうかを含む状態を表示します。
支払いエンドポイント
支払いエンドポイントはエンティティIDとウォレット種別から解決されるため、ユーザーは生のアドレスをコピーする必要がありません。
インターフェース警告
エンティティが停止または解散している場合、インターフェースは警告を表示できるため、支払者が資金を送ってしまうことを避けられます。
アップグレードパス
会社が成長したり、逆に簡素化したりする場合でも、継続性を失わずに別のテンプレートへ移行できます。アップグレードは理事会ワークフロー、投資家条件、複雑なガバナンスを追加し、簡素化では単独オーナー構造へ戻せます。移行後も、同じエンティティ履歴が保たれます。
ベンチャーテンプレート
テンプレートコード CORP-VENTURE は、投資条件、理事会ワークフロー、エクイティタグ付けを追加し、ベンチャー投資向け構造を支えます。
複合プライベート
テンプレートコード CORP-COMPLEX-PRIVATE は、複雑な保有構造、委員会、重要事項の保護など、高度なガバナンスを支えます。
単独テンプレート
テンプレートコード CORP-SOLO は、所有が1人のコントローラに集約され、承認を最小化したい場合に適合します。
運用と検証の場所
公式アプリは、登録、請求、承認などの日常アクションを扱います。公開ツール（レジストリ、エクスプローラー、公式インデクサー）により、誰でもアイデンティティ、ステータス、ウォレット紐付けを検証できます。これにより、組織が行うことと第三者が見るものがネットワーク全体で一致します。
公式アプリ
登録、請求書発行、支払いのタグ付け、アクション承認を行う主要インターフェースです。
レジストリ
アイデンティティ、ステータス、公式ウォレットを確認でき、相手が誰に支払っているかを検証できます。
エクスプローラー
公式インデクサーを基盤に、トランザクション、残高、公開履歴をひとつのビューで表示します。
公式インデクサー
エクスプローラーの集計とレポーティングビューを支える参照データサービスです。
dApps & SDKs
サードパーティのdAppsとSDKsで、カスタムフローの構築や製品への支払い統合が可能です。
マニフェスト
"私の目標はシンプルです。世界のどこにいても、誰もが、信頼性と継続性を備え、現実の金融レールで運用できるエンティティを立ち上げられるようにすること。ステーブルコイン・ネイティブな運用のために設計しています。"
マニフェストを読むNicolas Turcotte
創設者兼リードエンジニア
参加する
テストネットは、Hubを公開環境で検証したいビルダー、オペレーター、ガバナンスの担い手のためのものです。
プロトコルエンジニア
カーネル定義、メッセージスコープ、不変条件の設計。
インデクサー / データエンジニア
イベントスキーマと、再現可能なビュー入力の定義。
初期オペレーター
テストネットのルール下で、シーケンサー、バッチ投稿、運用スコープを検証。
インフラ志向の投資家
スコープ、リスク、進捗の追跡（リターンの約束はありません）。
法務アドバイザー
境界方針、ノンカストディアルの範囲、ドキュメント構成のレビュー。
ガバナンスの担い手
カーネル/アダプター分離と、アップグレード方針の設計。
Testnetアクセス
開発用テストネットでHubを探索し、リファレンスUIを試し、プロトコルの挙動をエンドツーエンドで検証するには、アクセスを申請してください。申請は誰でも可能ですが、ローカル/開発環境のオペレーター権限はより厳格に審査します。
アクセスは制限されています。承認が必要です。
Testnet 英語のみ
Testnetアクセス
開発用テストネットでHubを探索し、リファレンスUIを試し、プロトコルの挙動をエンドツーエンドで検証できます。申請は誰でも可能ですが、ローカル/開発環境のオペレーター権限はより厳格に審査します。
Testnetアクセスを申請ニュースレター 英語のみ
最新情報を受け取る
テストネットの準備状況、リリース、ガバナンスの節目を簡潔にお届けします。