Hyperliquid API の接続と認証── API ウォレットと nonce で発注の権限を設計する
API キーの代わりに、出金できない署名専用の鍵を発注プロセスごとに割り当てます。鍵の分け方と nonce の扱いを最初に決めておけば、本番で原因の分からない拒否に悩まされません。

令和元年の金融商品取引法改正で「電子記録移転有価証券表示権利等」という区分が設けられ、2020年5月1日に施行されました。それ以降、国内のデジタル証券は不動産や社債を裏付けとする案件を中心に積み上がっています。技術的な目新しさで語られる段階は過ぎ、いまは既存の証券インフラとどう共存させるかが実装上の主題です。
本稿では、法制度が権利をどう捉えているかを確認したうえで、その制約のもとでスマートコントラクトに何を担わせられるのかを整理します。移転制限の実装、権利者名簿との関係、そして二次流通の設計が中心になります。市場規模と流通の実態については 不動産トークン化が変える「投資の民主化」 で数字とともに扱っています。
この改正が実装に効いてくるのは、規制の区分が動いた点です。従来は第二項有価証券として扱われていた信託受益権や集団投資スキーム持分が、電子情報処理組織を用いて移転できるトークンとして表示される場合には、第一項有価証券に相当する規制が及ぶことになりました。開示や販売勧誘の規律が株式や社債と同じ水準で求められるということです。
ここから導かれる実装上の帰結は明確です。取得者の適格性確認を経ない移転が技術的に可能な設計は、制度と整合しません。したがって、実装の出発点は移転制限をどこに置くかの選択になります。

実務では、コントラクト側に許可リストを持たせつつ、判定ロジックを差し替え可能な外部へ委譲する折衷が多く採られます。チェーン上で拒否できることに意味があり、同時に判断ロジックは可変であるべきだからです。拒否したときに理由コードを返す設計にしておくと、業務側で原因を切り分けられます。
許可の粒度も設計事項です。アドレス単位で持つと、保有者が鍵を変更するたびに更新が要ります。投資家の識別子を別に持ち、アドレスとの対応表を管理する構成にすると、鍵の変更を対応表の更新だけで吸収できます。権利の主体と暗号鍵を分けて扱うことが、運用の柔軟性につながります。
移転制限には期間的な要素も含まれます。譲渡制限期間、投資家区分ごとの保有上限、募集後の一定期間における制限といった条件は、単純な許可リストでは表現できません。判断を外部に委譲する構成にしておくと、こうした条件を後から追加できます。
ここが設計でもっとも誤解されやすい部分です。チェーン上の残高が法的な権利の所在を直接決めるわけではなく、多くのスキームでは権利者名簿が正として位置づけられます。

この前提を置くと、実装の焦点は整合性の担保に移ります。名簿とチェーンが食い違った場合にどちらを優先し、どう修正するかを事前に決めておかないと、障害時に権利関係が宙に浮きます。実務的には、名簿側を単一の真実の源とし、チェーンへの反映が失敗した場合は再送で追いつかせる設計が扱いやすくなります。
この方針は鍵管理にも効いてきます。名簿を正とする設計であれば、保有者が鍵を失っても鍵の再割当てで復旧できます。チェーン上の残高だけを真実とする設計では、鍵の紛失がそのまま権利の凍結になります。
配当や利払いの分配をコントラクトで自動化する構想はよく語られますが、実装では注意が要ります。分配の原資は法定通貨で保有されることが多く、チェーン上の処理だけでは完結しません。またコントラクトはデプロイ後の修正が難しいため、税制や約款の変更に追随しにくいという性質があります。

アップグレード可能なコントラクトを採る場合も、誰がどの手続きで更新できるかを明示し、更新権限の管理を運用設計に含めます。更新できることは同時に改ざんできることでもあるため、権限分掌と多重署名が前提になります。
デジタル証券の価値提案として流動性の向上が挙げられますが、実際に二次流通が機能するには複数の条件が揃う必要があります。取引の場が用意されていること、価格形成に足る参加者がいること、そして決済が確実に完了することです。
技術面では、資金と証券の受け渡しを同時に成立させるDVP 決済の実現方式が論点になります。資金側が法定通貨のまま銀行口座を経由する場合、証券の移転と資金の移動を原子的に結びつけられません。この場合はエスクローや条件付き移転で近似することになり、その分だけ処理の状態管理が複雑になります。資金側もチェーン上に載せられれば同時決済に近づきますが、その場合は資金の性質と規制上の扱いを別途整理する必要があります。
取引の場としては、私設取引システムを介する方式と、相対取引を仲介する方式があります。前者は価格の透明性が高い一方で参加者を集める必要があり、後者は少数の参加者でも成立しますが価格形成が働きにくくなります。裏付け資産の性質と想定する保有者層から、どちらが適しているかを先に決めておくと、システムの設計方針が定まります。
いずれの方式でも、約定から決済までの状態遷移を明示的に管理する必要があります。約定済みで未決済の状態、決済処理中の状態、失敗して差し戻された状態を区別できないと、障害時にどこまで戻すべきかが判断できません。
発行時には見えにくく、運用開始後に効いてくる要素がいくつかあります。第一にチェーンの選定です。移行の可能性を考えると、特定チェーンの機能に深く依存した実装は避け、コントラクトのインターフェースと業務システムの境界を明確にしておく価値があります。手数料の変動も運用コストに直結するため、移転のたびに発生する手数料を誰が負担するかを決めておきます。発行者が肩代わりする設計にする場合、手数料が高騰した局面で処理が滞らないよう、上限と待機の方針を組み込んでおきます。
第二に監査で、移転履歴とその判断根拠を長期保存できる形で残しておく必要があります。コントラクトの監査も、デプロイ前の一度きりで終わりにはできません。依存しているライブラリに脆弱性が見つかることがあり、アップグレード可能な設計であればその適用手順が、そうでなければ移行手順が要ります。発行時に運用終了までの手順を書いておくことが、長期の商品を扱ううえでは実務的です。
制度面では、日本STO協会が自主規制機関として規則を整備しており、実務の細部はここを起点に確認することになります。法令だけを読んでも運用の水準は決まらないため、自主規制規則と実際の案件で採られている構成を突き合わせる作業が要ります。
国内のデジタル証券は、技術的な可能性を制度の枠にどう収めるかという実装の段階にあります。第一項有価証券に相当する規制が及ぶ以上、移転が自由なトークンにはできません。
移転制限を差し替え可能な形で持たせ、権利者名簿を正としてチェーンを記録として使い、変更頻度の高いロジックは業務システムに残す。この構成が、現行制度のもとでは扱いやすい落としどころになります。
金融テクノロジー総合研究所では、デジタル証券基盤の設計、スマートコントラクトの監査、実世界資産のトークン化に関する調査・実装を受託しています。スキームの検討段階からご相談いただけます。お問い合わせよりご連絡ください。
FTL の技術スタックと受託開発の進め方は FTLの技術とは? にまとめています。