トークンの設計思想 https://docs.hazbase.com/know-overview/ TOKEN DESIGN トークンの設計思想 hazBaseでは、お金だけでは捉えにくい支援・利用・実績・参加も、権利や記録として扱います。何に価値を見いだし、誰と共有し、どのように使い続けるか。その考え方を、トークンの種類と運用ルールへ落とし込むためのガイドです。 価値と参加の関係から考える トークンは、それだけで新たな価値や収益を生むものではありません。保有すると何ができるか、誰がその約束を支えるか、利用や活動の結果をどう確かめるかを具体的にすることで、継続的な支援や参加につながります。hazBaseでは、次の四つを設計の出発点としています。 応援 支援したことを記録し、その後の活動報告や参加の機会につなげる。 地域活動への支援を記録し、支援者向けの報告会への参加資格と結び付ける。 構成例を見る 利用 使えるもの・回数・期間を明確にし、サービスの利用と権利の消費を対応づける。 施設の利用券を5回分発行し、1回利用するごとに残りの回数を更新する。 構成例を見る 信用 実績を誰が確認したかを明らかにし、参加条件や資格の確認に使う。 設備の点検実績を、確認者・対象設備・確認日時と対応づける。 構成例を見る 参加 意見を出す、投票する、実行を承認するなど、関われる範囲を定義する。 地域施設の運営方針について、参加資格と投票の集計方法を決める。 構成例を見る 実装の前に整理する四つのこと 業務側で決める条件と、システムで実行するルールをそろえます。最初は一つの権利・一つの処理を対象にすると、必要な機能を選びやすくなります。 1 何を1単位として表すか 対象の資産や活動と、保有者が持つ権利を分けて定義します。同じ設備でも、設備の識別票、利用権、契約上の持分では必要な構成が異なります。 例：設備そのものではなく、契約で定めた権利を1,000単位に分けて表す。 2 誰が受け取り、誰へ移せるか 本人にひも付く資格と、他者に移せる権利を区別します。移転を認める場合も、相手の参加条件や承認が必要かを整理します。 例：契約が成立した取引先を承認対象とし、許可済みの宛先間で移転できる構成を選ぶ。 3 数量と終了条件をどう扱うか 発行上限、小数桁、追加発行の条件を決めます。利用による消費、期限切れ、償還、誤発行の訂正は、それぞれ別の処理として整理します。 例：回数券は利用時に1回分を消費する。契約の終了時は、残高と業務上の精算結果を照合する。 4 誰が発行・変更・停止を行うか 発行担当、設定の管理者、業務上の承認者を対応づけます。停止が必要な操作と、停止中も継続する業務を分けておくと、障害時の判断が明確になります。 例：追加発行は業務承認後に実行し、停止・再開の判断者と履歴を残す。 現実の権利と、チェーンの記録を結ぶ RWAでは、対象の資産・契約と、チェーン上の保有や移転を対応づけます。トークンの移転をどの権利の変更として扱うかは、業務上の取り決めと照合して確認します。 業務システム 約束と根拠を管理する 資産台帳・契約原本・本人確認・承認・点検や稼働の記録。必要な人が参照できる権限で管理します。 スマートコントラクト 定めたルールで記録する 発行数・保有者・残高・移転・利用による消費など。必要な操作と参照範囲に合わせて構成します。 対応づける情報 資産ID・契約ID ↔ chainId・コントラクトアドレス・必要に応じたtokenId。操作ID ↔ 取引ハッシュ・イベント。 透明性は、すべての情報を公開することではありません。何を誰が検証できるかを決め、個人情報や契約原本はアクセス制御した保管先に置きます。記録が正しく送信されたことと、現実の資産や実績が正しいことを分け、確認者と証拠も残します。 表したいものからトークンを選ぶ 一つずつ識別するものと、同じ単位を数量で扱うものでは、適したコントラクトが異なります。次は構成を選ぶための目安です。名前から仕様ページへ進むと、主要な操作とSDK・ソースコードを確認できます。 表したいもの 構成の候補 選ぶときの確認点 同じ権利を数量・口数で扱う FlexibleToken 発行上限、小数桁、追加発行、移転の条件。設備に関する権利やポイントなど。 条件・発行単位の異なる債権 BondToken 条件をclass、発行単位をnonceで区別。利払い・償還はDebtManagerと組み合わせて設計。 一つずつ識別する資産・資格 PrivilegeNFT tokenIdごとの保有者と情報。設備の識別票や個別の会員資格など。 種類ごとに複数ある利用券・特典 PrivilegeEdition 種類ごとの数量と利用時の消費。回数券やランク別の特典など。 評価指標・資格情報 MultiTrustCredential 更新できる主体と証明の条件。評価の根拠は業務記録と対応づける。 例えば、設備の識別票と、その設備に関する契約上の権利は別々に表せます。必要な役割を分けて組み合わせることで、利用券・評価・投票などを同じトークンに詰め込まずに設計できます。 保有・承認・実行の権限を分ける トークンを持つ人、業務を承認する人、コントラクトを操作できる人は、必ずしも同じではありません。画面上の承認とチェーン上の権限を対応づけると、担当者が変わっても運用を引き継げます。 参加と移転 本人確認や審査の結果を、参加許可の更新へつなげます。Whitelistを使う場合は、参照するトークン側の設定と、許可の追加・解除が既存の保有や移転へ与える影響を確認します。 Whitelist 投票と実行 投票できることと、可決された操作を実行できることを分けて設計します。議決条件、集計時点、実行までの待機期間、実行権限を確認します。 ガバナンスの実装パターン 停止と再開 停止対象と権限を事前に設定します。停止要求後も各コントラクトの状態を確認し、業務台帳との照合を終えてから再開を判断します。停止は過去の取引を取り消す操作ではありません。 EmergencyPauseManager 具体例：設備の権利を1,000単位で表す 配送ロボットROBOT-A-001に関する契約上の権利をFlexibleTokenで表し、取引先へ最初の10単位を割り当てる設計例です。以下は設計項目の整理で、APIの入力形式ではありません。 対象と権利 ROBOT-A-001／契約AGR-2027-001。1単位が表す権利と、その権利を履行する主体を契約で定める。 数量 上限1,000単位、小数桁0。初回は10単位を新規発行し、発行済み総数と相手の残高はいずれも10になる。 受取先と承認 契約成立を確認した宛先を対象とする。資産・契約・数量・宛先の承認後、発行権限を持つアカウントが実行する。 完了と記録 確定した発行結果と台帳の10単位を照合し、操作IDから契約・承認・取引ハッシュを追跡できる状態にする。 数量と収益の計算は、別に定義する この例では、10単位は発行上限1,000単位の1%ですが、それだけで設備収益の1%を受け取るとは決まりません。収益分配を設ける場合は、対象収益、費用、計算の基準日、対象残高、支払方法を別途定義し、発行処理と分配処理を対応づけます。 設備・ロボットの構成例 割当から照合までの運用 設計を実装につなげる ここまでで整理した権利、数量、参加条件、権限、記録をもとに、必要な機能を組み合わせます。各実装パターンには、データモデル・処理手順・SDKのコード例を掲載しています。 近い用途から構成を考える 設備、利用券、会員資格、地域活動などの具体例から、業務の流れとトークンの役割を確認できます。 ユースケースを見る 必要な機能から実装する 資産管理、利用権、ガバナンス、証明などの構成とコードを、自社のアプリケーションへ組み込めます。 実装パターンを見る サンプルから始める コントラクト仕様を確認する