TOKEN DESIGN

トークンの設計思想

hazBaseでは、お金だけでは捉えにくい支援・利用・実績・参加も、権利や記録として扱います。何に価値を見いだし、誰と共有し、どのように使い続けるか。その考え方を、トークンの種類と運用ルールへ落とし込むためのガイドです。

価値と参加の関係から考える

トークンは、それだけで新たな価値や収益を生むものではありません。保有すると何ができるか、誰がその約束を支えるか、利用や活動の結果をどう確かめるかを具体的にすることで、継続的な支援や参加につながります。hazBaseでは、次の四つを設計の出発点としています。

支援したことを記録し、その後の活動報告や参加の機会につなげる。

地域活動への支援を記録し、支援者向けの報告会への参加資格と結び付ける。

使えるもの・回数・期間を明確にし、サービスの利用と権利の消費を対応づける。

施設の利用券を5回分発行し、1回利用するごとに残りの回数を更新する。

実績を誰が確認したかを明らかにし、参加条件や資格の確認に使う。

設備の点検実績を、確認者・対象設備・確認日時と対応づける。

意見を出す、投票する、実行を承認するなど、関われる範囲を定義する。

地域施設の運営方針について、参加資格と投票の集計方法を決める。

業務側で決める条件と、システムで実行するルールをそろえます。最初は一つの権利・一つの処理を対象にすると、必要な機能を選びやすくなります。

何を1単位として表すか
対象の資産や活動と、保有者が持つ権利を分けて定義します。同じ設備でも、設備の識別票、利用権、契約上の持分では必要な構成が異なります。
例：設備そのものではなく、契約で定めた権利を1,000単位に分けて表す。
誰が受け取り、誰へ移せるか
本人にひも付く資格と、他者に移せる権利を区別します。移転を認める場合も、相手の参加条件や承認が必要かを整理します。
例：契約が成立した取引先を承認対象とし、許可済みの宛先間で移転できる構成を選ぶ。
数量と終了条件をどう扱うか
発行上限、小数桁、追加発行の条件を決めます。利用による消費、期限切れ、償還、誤発行の訂正は、それぞれ別の処理として整理します。
例：回数券は利用時に1回分を消費する。契約の終了時は、残高と業務上の精算結果を照合する。
誰が発行・変更・停止を行うか
発行担当、設定の管理者、業務上の承認者を対応づけます。停止が必要な操作と、停止中も継続する業務を分けておくと、障害時の判断が明確になります。
例：追加発行は業務承認後に実行し、停止・再開の判断者と履歴を残す。

RWAでは、対象の資産・契約と、チェーン上の保有や移転を対応づけます。トークンの移転をどの権利の変更として扱うかは、業務上の取り決めと照合して確認します。

業務システム

資産台帳・契約原本・本人確認・承認・点検や稼働の記録。必要な人が参照できる権限で管理します。

スマートコントラクト

発行数・保有者・残高・移転・利用による消費など。必要な操作と参照範囲に合わせて構成します。

対応づける情報

資産ID・契約ID ↔ chainId・コントラクトアドレス・必要に応じたtokenId。操作ID ↔ 取引ハッシュ・イベント。

透明性は、すべての情報を公開することではありません。何を誰が検証できるかを決め、個人情報や契約原本はアクセス制御した保管先に置きます。記録が正しく送信されたことと、現実の資産や実績が正しいことを分け、確認者と証拠も残します。

一つずつ識別するものと、同じ単位を数量で扱うものでは、適したコントラクトが異なります。次は構成を選ぶための目安です。名前から仕様ページへ進むと、主要な操作とSDK・ソースコードを確認できます。

表したいもの	構成の候補	選ぶときの確認点
同じ権利を数量・口数で扱う	FlexibleToken	発行上限、小数桁、追加発行、移転の条件。設備に関する権利やポイントなど。
条件・発行単位の異なる債権	BondToken	条件をclass、発行単位をnonceで区別。利払い・償還はDebtManagerと組み合わせて設計。
一つずつ識別する資産・資格	PrivilegeNFT	tokenIdごとの保有者と情報。設備の識別票や個別の会員資格など。
種類ごとに複数ある利用券・特典	PrivilegeEdition	種類ごとの数量と利用時の消費。回数券やランク別の特典など。
評価指標・資格情報	MultiTrustCredential	更新できる主体と証明の条件。評価の根拠は業務記録と対応づける。