未上場株をトークン化するには|株主名簿・譲渡承認とトークンをずらさない方法

コラム

/約19分で読めます

コラム

/約19分

未上場株をトークン化するには|株主名簿・譲渡承認とトークンをずらさない方法
目次(タップで折りたたみ)

    ある未上場の会社が、株式をトークンにして、限られた投資家のあいだで譲渡できるようにしました。しばらくして、ひとりの株主が持ち株を別の投資家へ譲ります。トークンは買い手のウォレットへ移りました。ところが株主名簿の書き換えが失敗し、名簿上は元の株主のまま。次の配当は、もう株を手放した元の株主に振り込まれてしまいました。

    食い違いは、ほかの形でも起きます。会社は譲渡を承認したのに、トークンが動かない。代金だけが支払われ、株は動いていない。どれも、トークンの移転だけで譲渡を終わらせようとしたときに起きます。

    ファンドや不動産のトークン化と比べて、未上場株に特有の事情は2つあります。

    • 法律上の株主を決める株主名簿が、トークンの台帳とは別にある
    • 譲渡制限株式では、会社が譲渡を承認しないと移転が終わらない

    では、どう作ればよいか。まず、トークンが株式そのものを表すのか、信託などを通した別の権利を表すのかをはっきりさせます。そのうえで、株主名簿、譲渡の承認、配当、議決権と、チェーン上の記録が必ず同じ内容になる仕組みを作ります。以下では、この会社が決めていく順に見ていきます。

    この記事でわかること

    • トークンを持つ人が、誰に対して何の権利を持つのかの決め方
    • 株主名簿とトークンを食い違わせない、譲渡・配当・議決・会社イベントの進め方
    • 鍵をなくしたときの復旧、流動性の限界、PoCで試すこと

    この記事で使う言葉

    • 名義書換:株を譲り受けた人の名前を、株主名簿に書き入れること
    • 対抗要件:権利を、会社やほかの人に対して主張するために必要な手続き
    • 譲渡制限株式:譲渡に会社の承認が要ると定款で決めた株式
    • SPV:株式などを持つためだけに作る会社や器
    • 正本:記録どうしが食い違ったとき、正しいとみなす記録

    トークンを持つ人は、会社の株主なのか、SPVの出資者なのか

    トークンを持つ人が手に入れるものは、次の3通りが考えられます。

    モデルトークンを持つ人が手に入れるもの発行会社の株主名簿に載るのは
    直接株式モデル発行会社の特定の種類・数の株式トークンを持つ本人か、契約で決めた名義人
    SPV・信託などの間接モデルSPV持分、信託受益権、社債などふつうはSPV・受託者などが株主として残る
    第三者による価格連動商品株価・評価額に連動する契約上の請求権などトークンを持つ人はふつう載らない

    配当と議決権の届き方も、モデルごとに違います。

    • 直接株式:発行会社から株主へ届く。トークンの記録と、会社法・定款の手続きを同じ内容に保つ
    • 間接:発行会社からSPV・信託などへ届き、その後に契約で決めた分配の順番と、意思表示のとりまとめを通る
    • 価格連動:株主としての配当・議決権ではなく、第三者との契約の条件に従う

    どれかによって、株主名簿に誰が載るか、配当と議決権が誰に届くかが変わります。会社が倒産したとき、誰に請求できるかも変わります。ですから、「1トークン=1株」と書くだけでは、トークンを持つ人が何の権利を持つのかは決まりません。

    米国証券取引委員会(SEC)の企業財務局など3部局が、2026年1月28日に出した声明も、この違いを区別しています(Statement on Tokenized Securities)。発行体やその代理人が、株主原簿そのものをチェーン上で管理するモデル。発行体と無関係な第三者が、保管する証券への間接的な権利や、価格に連動する証券を出すモデル。この2つです。

    米国法の分類を、日本にそのまま当てはめるわけではありません。ただ、名前ではなく「誰に対する、何の権利か」を確かめる物差しとして役に立ちます。

    要件定義書では、最初に次の3つを決めます。

    • 誰に対する、何の権利か(発行会社、権利の法的な名前、種類株式かSPV・信託などの権利か)
    • どの名簿が正しいか(正本、名義人、実質的な権利者)
    • 譲渡はいつ成立するか(譲渡が成り立つ条件)

    あわせて、商品の識別子、1トークンが何株に当たるか、配当の請求先、議決権を持つ人、倒産したときの請求先も書きます。この内容を、契約・定款・開示・画面・スマートコントラクトのすべてで同じにできないうちは、実装に進みません。

    トークンにしても、自由に売れるようになるわけではない

    先に、期待しすぎないための話をしておきます。未上場株には、もともと次のような事情があります。

    • 値段が決まりにくく、手に入る情報に差がある
    • 売り手と買い手が少なく、譲渡制限や投資家の範囲がある
    • 決済やカストディ(保管・管理)の対応に限りがある

    24時間動くコントラクトを置いても、審査・承認・値段・買い手がそろわなければ、売り買いは生まれません。

    金融庁の監督指針も、電子的に移転される有価証券は、上場していない有価証券に流動性を与えうるとしています。一方で、保有・移転・決済に違うリスクがありうるとも書いています。Progmatのトークン化株式WGの報告ページでも、トークン化株式の商品や制度の設計が検討され続けています。記事公開の時点で、特定の市場の形や、自由な流通ができあがったとは言えません。

    では、効果は何で測るのか。売買の回数ではありません。次のような指標です。

    • 名義書換にかかる時間、本人確認(KYC)を使い回せた割合
    • 譲渡で例外処理になった割合、配当・議決の突き合わせにかかる時間
    • 会社イベントの誤りの割合、復旧にかかる時間、監査の記録がそろっているか

    参加者を絞った中でも、これらがよくなるなら、作る価値があります。

    日本の会社法では、株主名簿と譲渡の承認がトークンとは別に動く

    e-Gov法令検索の現行会社法(平成十七年法律第八十六号)の定めは、次のとおりです。

    • 第121条:株式会社は株主名簿を作り、株主の氏名または名称・住所、持っている株式の種類・数などを記載・記録する。
    • 第130条:原則として、取得した人の氏名または名称・住所を株主名簿に記載・記録しなければ、株式の譲渡を会社やほかの第三者に主張できない。
    • 第136条以下:譲渡制限株式では、定款に加えて、譲渡等承認請求(会社に譲渡の承認を求める手続き)や承認の決定などの手続きがかかわる。

    どの記録が法的な正本か。トークンの移転が、申請・証拠・権利移転のどれの役割を持つか。これは会社ごとに、定款、株券を発行するか、契約、取得のしかた、準拠法で決まります。技術の側が「ブロックチェーン上で取引が確定した=名義書換が済んだ」と決めつけてはいけません。

    金融庁の株券電子化Q&Aは、上場株式の振替制度に未上場株式は含まれないと説明しています。上場株式と同じ口座振替や、総株主通知(振替機関が会社へ株主の情報を知らせる仕組み)が、自動で使えるわけではありません。発行会社、株主名簿管理人、証券会社、カストディアン、トークンの基盤の役割分担を、発行会社ごとに作ります。

    制度の面では、日本証券業協会が2025年4月にJ-Ships関連規則の改正を行いました。J-Shipsは、非上場株式などを特定投資家(知識や資産の多いプロの投資家)へ届ける特定投資家向け銘柄制度です。改正で、対象に受益証券発行信託の受益証券が加わり、その後も規則やQ&Aの改訂が続いています。国内でも制度の整備は進んでいます。ただ、トークンがいくらでも流通できるという意味ではありません。

    どの記録を「正」とするかを、5つの領域ごとに決める

    個人情報、会社の承認、銀行の入出金、法律で決まった帳簿には、それぞれ管理する人がいます。ですから、1つのブロックチェーンにすべてを書いても、それだけで食い違いがなくなるわけではありません。少なくとも次の5つの領域に分けて、正本と、食い違ったときの扱いを決めます。

    領域正本の候補食い違ったときの扱い
    権利・発行条件定款、株主間契約、発行決議、引受・SPVなどの文書発行・移転・会社イベントを止め、承認済みの文書を確かめる
    株主・権利者株主名簿、または契約で決めた権利者原簿法的に決めた正本に従い、差を個別の調査対象として取り置く
    本人・適格性アクセスを制限したKYC・顧客管理・資格情報のシステム個人情報をブロックチェーンへ写さず、移転を人が確かめるか断る
    トークンの保有残高トークンコントラクトと、インデクサー(チェーンの記録を読み取って整理する仕組み)の確定ブロック名簿へ自動で上書きせず、最後に一致したブロックまで移転を止める
    現金・会社イベント銀行・カストディの台帳、取締役会・株主総会などの承認記録入金・承認が確定する前に、発行、配当、株式分割を完了扱いしない

    ブロックチェーンに持たせる情報は、後半の「実装する人向けの詳細」にまとめています。

    金融庁の金融商品取引業者等向けの総合的な監督指針 IV-3-7も、電子的に記録・移転される有価証券について書いています。ネットワーク、保有、移転、決済に、ふつうの有価証券と違うリスクがありうる、という指摘です。どれが法的な正本かという判断と、システムの止まりにくさ・鍵の管理・取引の確定の判断は、別々に扱います。

    株主と、ウォレットは同じではない

    株主は人や法人です。ウォレットのアドレスそのものではありません。たとえば1人の株主が、次のような使い方をします。

    • いくつものウォレットを使う
    • カストディアンのオムニバスウォレット(複数の顧客の資産をまとめて管理するウォレット)を使う
    • 鍵をなくして、アドレスを変える

    反対に、1つのウォレットを複数の人が共同の権限で動かすこともあります。ですから、本人、ウォレット、持っている株の記録は別々のデータとして管理します。

    氏名、住所、本人確認の資料、税務上の番号、契約の本文は、アクセスを制限したブロックチェーン外のシステムに置きます。ブロックチェーンに載せるのは、必要最小限の参照ID、資格の状態、期限、ハッシュ値だけです。

    ウォレットの追加や失効は、株の移転とは別の手続きにします。本人確認、今のウォレットか別の手段での認証、起票する人と承認する人を分けた承認、監査ログが必要です。

    譲渡は、5つの段階を順に進める

    冒頭の食い違いを防ぐには、譲渡を1つの業務の取引として管理します。参加者を絞ったトークンの移転(transfer)だけで終わらせません。段階と、失敗したときの扱いは次のとおりです。

    1. 申請:売主、買主、商品、数量、値段・対価、ウォレットを受け付ける。足りない項目は直してもらい、トークンは動かさない。
    2. 適格性の確認:本人確認、投資家の区分、地域、保有上限、ロック、制裁対象かを確かめた時点を見る。だめなら断るか、人が確かめる。
    3. 会社の承認:定款・契約に沿った譲渡の承認と、社内の必要な権限を確かめる。承認の期限が切れたら審査し直す。
    4. 代金と株の受け渡し:株の側とお金の側の両方を押さえる。時間切れなら両方を解放し、片方だけを確定させない。
    5. 株主名簿への反映:トークンの取引の確定、必要な書類、取得した人の情報を確かめて名簿を更新する。うまくいかなければ、関係する残高を凍結して個別に突き合わせる。

    株主名簿・権利者原簿とトークンの残高が一致したら完了です。完了した後の訂正は、上書きせず訂正の記録として残します。

    ERC-3643仕様は、移転の条件として次の3つを決めています。

    • 受け取る人が、Identity Registry(本人・適格性の登録簿)で確かめ済みであること
    • ウォレットやトークンが、凍結・停止されていないこと
    • ComplianceコントラクトのcanTransferがtrueであること

    役に立つ部品です。ただ、会社の譲渡承認、名義書換、代金の決済、法的な判断を、コントラクトだけで置き換えるものではありません。ERC-3643の本人登録簿・コンプライアンス・強制移転を作るときの注意は、ERC-3643の設計記事で詳しく扱っています。

    事前に確かめてから実行するまでのあいだに、資格・残高・ルールは変わりえます。ですから、事前に確かめた結果は実行のときに使い回さず、実行の直前にもう一度確かめます。代金と株のトークンを同時に受け渡す方式を選ぶなら、アトミックDvPの設計も参考になります。

    配当は、基準日に誰が株主だったかを固めてから払う

    配当を受け取るのは、基準日に株主だった人です。ですから、今のトークン残高へ一斉に送金するだけでは済みません。基準日に、誰が何株の権利者だったか。それを、どの名簿の版と、どの確定ブロックで決めたか。この記録が必要です。間接モデルでは、発行会社からSPV・受託者などへの配当と、そこからトークンを持つ人への分配を、別の出来事として扱います。

    1. 配当を登録する:対象の商品、基準日、支払日、1株あたりの額、通貨、承認文書の版を固める。
    2. 基準日の株主を固める:株主名簿・権利者原簿、トークンの確定ブロック、処理中の譲渡、担保・信託・オムニバスで持っている分の扱いを突き合わせる。
    3. 受け取る額を計算する:株数、権利の区分、丸め、源泉徴収など税務に要る入力、差し引く額、端数の残りの行き先を、版を付けて管理する。
    4. 送金する:銀行・決済手段での取引の確定、返金、組戻し、受け取られていない分を、支払いの状態として管理する。
    5. 突き合わせる:総額=支払済み+保留+返金+端数の残り、となることを確かめる。

    配当をステーブルコインなどで払う場合も、通貨・決済手段の選び方、ウォレットで受け取れるか、値段・税務・会計を個別に確かめます。トークンを持つ人のウォレットへ送れることと、正しい相手へ正しい配当を払ったことは、同じではありません。

    議決権も、基準日と議案ごとに固める

    議決権にも基準日があり、議決権のない株や、代理での行使もあります。ですから、今の残高だけを使うブロックチェーン上の投票には置き換えられません。決めておくことは次のとおりです。

    • 基準日と、議決権のない種類株・自己株式・単元などの扱い
    • 代理での行使と、間接モデルでの意思表示のとりまとめ
    • 議案の版、棄権、定足数、投票の秘密

    運用では、次の5点を押さえます。

    • 投票できる数:名簿の版と確定ブロックから、議案ごとに投票できる数を作る。
    • 投票する資格:ウォレットの署名だけに頼らず、代理人、カストディアン、法人の代表者の権限と、その失効を管理する。
    • 議案の版:議案の文書のハッシュ値と版を固め、差し替えた後は、前の投票を無効にするか確かめ直す。
    • 秘密投票:株主ごとの投票内容を公開のブロックチェーンにずっと残す必要があるかを考える。先に暗号化した票を出して後で開くやり方(コミット・リビール方式)や、ブロックチェーン外での署名なども比べる。
    • 集計の記録:賛否・棄権、無効票、定足数、訂正、確定した人を、計算し直せるようにする。

    SPV・信託などの間接モデルでは、トークンを持つ人の投票が、発行会社の株主総会でそのまま1票になるとは限りません。SPV・信託などの契約に従い、指図、裁量、とりまとめ、期限、端数をはっきりさせます。

    株式分割や買戻しは、会社が承認した出来事としてだけ行う

    株式分割や買戻しを、トークンの管理者が好きに発行・焼却できる機能にしたとします。すると、会社の承認の記録とトークンの総数がずれていきます。総数を変える処理は、すべて会社が承認した出来事(会社イベント)に結び付けます。

    • 株式分割・併合:比率、基準日、効力の発生日、端数の扱いを入力に、ある時点の保有数を比率で換算する。
    • 自己株式の取得:会社の自己保有ウォレットへ移すか、ロックする。
    • 消却:承認された自己保有分だけを焼却する。
    • 種類の転換・組織再編:古いトークンをロック・焼却し、新しいトークンを出す。

    一括の処理は、途中で失敗するものとして作ります。段階ごとに区切りの記録を残し、同じ会社イベントから安全にやり直せるようにします。入力と突き合わせの項目、区切りの状態名は後半にまとめています。

    鍵をなくしたときや強制移転を、ふだんの運用として用意する

    未上場株を長く持つ間には、次のようなことが起こりえます。

    • 端末の紛失、カストディアンの変更、法人の担当者の交代
    • 相続・組織再編、裁判・行政への対応
    • 誤った相手への送付

    「秘密鍵をなくせば、株主の権利も永久に失う」という作りでは、トークンと法的な権利の関係を説明できません。

    ERC-3643には、鍵をなくしたときの復旧、強制移転、ウォレットの凍結、トークンの一部凍結、停止などの仕組みがあります。使う場合も、管理者の鍵1本で動かせるようにはしません。次の手当てをします。

    • ふだんの移転、凍結、復旧、強制移転、発行・焼却、更新の権限を分ける。
    • 本人・権限・根拠文書をブロックチェーン外で確かめ、申請IDと文書のハッシュ値を残す。
    • 複数人の署名、起票する人と承認する人の分離、必要な待ち時間、緊急時に触れる範囲の制限を組み合わせる。
    • 古いウォレットを先に凍結し、同じ投資家IDに新しいウォレットを結び付け、トークンと名簿を同じ申請IDで更新する。
    • 実行前後の残高、名簿の版、取引ハッシュ、実行者、理由、承認者を監査ログに残す。
    • 誤って実行したときに止めて直す手順を持ち、監査ログ自体は消さない・上書きしない。

    スマートコントラクトを更新する権限を持つ人は、コントラクトの中身そのものを変えられます。ですから更新にも、同じ管理のリスクがあります。更新の権限を誰が持つか、待ち時間、緊急停止、更新後もデータが壊れていないか、署名する人の交代をテストします。詳しくは後半と、次の記事で扱っています。管理権限の複数署名と待ち時間の組み方はマルチシグとタイムロックによる本番権限の設計、更新時のデータの移し替えはアップグレード可能なコントラクトのストレージ移行です。

    PoCでは、食い違いから元に戻れるかを試す

    この会社のPoCで確かめるのは、画面のデモではありません。権利・名簿・トークン・現金が、異常のときにも一致に戻れるかです。試す項目は次のとおりです。

    • 基準日の直前・直後の移転で、配当・議決が二重に付いたり、抜けたりしない。
    • 会社の承認の後にトークンの取引が失敗しても、名簿だけを完了扱いしない。
    • 株式分割の一括処理を途中で止めても、同じ会社イベントIDから安全にやり直せる。
    • 鍵をなくした後の復旧で、古いウォレットと新しいウォレットが同時に有効にならない。

    ほかにも、次の8つを試します。

    • 同じ商品ID・株式番号での重複発行を断れる。
    • 譲渡の申請の後にKYCの資格が失効したら、実行時の確認で止まる。
    • トークンの取引が確定した後に名簿のAPIが止まったら、対象の残高を取り置き、二重にならずに再開できる。
    • 名簿の総数と種類別のトークン総数、株主ごとの株数が一致する。
    • 強制移転、発行・焼却、更新を、1つの権限だけでは実行できない。
    • ブロックチェーンの停止、チェーンの再編(再編と確定性の設計を参照)、インデクサーの遅れ、時刻のずれ、重複した知らせ、順序の逆転を再現する。
    • 個人情報が、公開ブロックチェーン、イベントログ、サポート画面、スクリーンショットに漏れない。
    • 監査の担当者が、文書の版、承認、名簿の版、トークンの取引、現金までを、1つの処理IDで追える。

    実装する人向けの詳細

    ここからは、この会社で仕組みを作るアーキテクトと開発チームの話です。

    正本の領域ごとにブロックチェーンへ持つ情報

    領域ブロックチェーンへ持つ情報
    権利・発行条件商品ID、文書の版・ハッシュ値
    株主・権利者投資家ID、ウォレット、保有単位、名簿の版
    本人・適格性非可逆ID、資格状態、有効期限、ポリシーの版
    トークン保有残高残高、ロック・凍結、イベントID
    現金・会社イベント支払・会社イベントID、金額、効力発生日時

    本人・ウォレット・保有の持ち方

    要件定義書の商品識別子はinstrument_idとして持ちます。本人・ウォレット・保有は、たとえば次の形で分けます。

    {
      "investor_id": "inv_01J...",
      "instrument_id": "eq_series_b_2026",
      "legal_holder_id": "holder_483",
      "beneficial_holder_id": "beneficial_927",
      "wallets": [
        {"address": "0x...", "role": "custody", "valid_from": "2026-08-01", "status": "ACTIVE"}
      ],
      "eligibility": {
        "status": "ELIGIBLE",
        "policy_version": 12,
        "valid_until": "2027-07-31"
      },
      "register_version": 184
    }

    譲渡の状態遷移

    前半の5段階は、完了を含めて6つの状態で持ちます。

    状態確認する条件確定する証跡失敗時
    申請済み(REQUESTED)売主、買主、商品、数量、価格・対価、ウォレットtransfer_request_id、条件のハッシュ値不足項目を補正し、トークンは動かさない
    適格性確認済み(ELIGIBILITY_CHECKED)KYC、投資家区分、地域、保有上限、ロック、制裁対象確認の時点ポリシーの版、理由コード、有効期限拒否または人手確認
    承認済み(APPROVED)定款・契約上の譲渡承認、必要な社内権限承認ID、承認者、承認の有効期限と範囲期限切れなら再審査
    決済待ち(SETTLEMENT_PENDING)証券脚と資金脚のロック、ノンス、有効期限支払参照、トークン取引の実行意図時間切れで両脚を解放し、片側だけ確定させない
    名簿反映待ち(REGISTER_PENDING)トークン取引の確定、必要書類、取得者情報取引ハッシュ、確定ブロック、名簿更新申請関連する保有残高を凍結し、個別に照合
    完了(COMPLETED)株主名簿・権利者原簿とトークン残高の一致名簿の版、完了証跡完了後の訂正は上書きせず訂正イベントとして記録

    実行直前の判定では、ALLOW / DENY / REVIEW(許可・拒否・人手確認)、理由コード、ポリシーの版を保存します。各工程は同じtransfer_idと冪等性キー(同じ要求を何度送っても1回分しか処理されないようにする識別子)を使います。再送しても、二重の移転・二重の名義書換を起こさないためです。

    配当などの会社イベントは、corporate_action_id(会社イベントID)で登録します。

    会社イベントのトークン処理と照合

    会社イベント主な入力トークン処理必須の照合
    株式分割・併合比率、基準日、効力発生日、端数処理チェックポイント時点の保有単位を比率変換種類別総数、保有者別残高、端数・金銭交付
    自己株式取得対象、数量、価格、承認、決済会社の自己保有ウォレットへ移転またはロック支払、名簿、自己株式の議決・配当除外
    消却消却対象と効力発生日承認済みの自己保有残高だけを焼却発行済株式総数とトークン総数
    種類転換・組織再編旧新の商品、交換比率、条件、反対株主手続等旧トークンをロック・焼却し、新トークンを発行旧新名簿、未処理残高、端数、取消不能点

    一括処理の区切りは、PREPARED → FROZEN → REGISTER_UPDATED → TOKEN_UPDATED → RECONCILED → COMPLETED(準備済み→凍結済み→名簿更新済み→トークン更新済み→照合済み→完了)です。全保有者の残高を1つのトランザクションのループで更新しません。保有者の数に応じて、次の方法を比べます。Merkle claim(保有者が証明を添えて請求する方式)、版を付けた残高の移し替え、再開できる一括処理などです。

    鍵の復旧・強制移転・更新の部品

    ERC-3643の該当するインターフェースは、recoveryAddress、forcedTransfer、ウォレットの凍結、トークンの部分凍結、停止などです。コントラクトの更新では、プロキシ管理者(更新の権限を持つアカウント)、実装コードの許可リスト、時間遅延、緊急停止、更新後のストレージの不変条件、署名者の交代手続きをテストの対象にします。

    関連記事

    RWAトークン化全体の考え方と使われる領域は、RWAトークン化の解説で補足しています。この記事で扱ったのは、未上場株ならではの株主権、株主名簿、譲渡承認、配当・議決、会社イベントです。同じ骨組みを別の資産で掘り下げた記事として、NAV締切と償還制限を扱うトークン化ファンドの実装設計、貸付の延滞・回収を扱うプライベートクレジットのトークン化設計、物件運営費と二次流通を扱う不動産トークン化プラットフォームの設計もあわせて参照してください。

    XTELAができること

    私たちは、株主名簿・KYC・トークン・現金の正本を分けたデータモデルと、譲渡承認から名簿反映までの状態遷移を設計し、スマートコントラクトと照合処理を含むPoCで異常時の回復まで確かめます。鍵紛失時の復旧や強制移転の権限分離、株式分割などの会社イベントの一括処理も、再開できる形で実装します。法的な判断は弁護士と連携して進めます。貴社の株式や権利構成に合わせた検討はお問い合わせからご相談ください。

    主要参考資料

    資料の確認日と注意

    出典は2026年8月13日に確認しました。会社法の条文も、同じ日にe-Govの現行法令本文で確かめ直しています。日本証券業協会と米国SECの資料は、2026年9月24日に確認し直しました(J-Shipsの規則やQ&Aの改訂が続いていることも同日時点)。内容は各リンク先の一次情報にもとづく一般的な技術・業務設計の解説です。個別のトークンの法的な性質、名義書換や対抗要件が成り立つ時点、適用される規制は、定款・契約・最新の仕様をもとに専門家の判断で確定してください。

    お問い合わせ

    どんなフェーズからでも、お持ちのアイデアや企画をもとにご提案可能です。
    まずはお気軽にご相談下さい!