🌊

個人開発でRWAトークンを発行し、供給量の過半数（5.5億枚）をプログラムでロックするまでの技術スタック

に公開
Web3
DAO
Solana
高橋高
tech

【Solana/RWA】個人開発で5.5億枚のトークンをスマートコントラクトで完全ロックするまでの技術的知見と、メタデータ更新の沼

こんにちは、Jon & Coo Inc. のTakahashiです。
現在、Solanaブロックチェーンを活用した観光RWA（Real World Assets）プロジェクト**「Matsuri DAO」**を開発・運営しています。

本日、プロジェクトの大きなマイルストーンとして、発行したトークン（$MTC）の過半数にあたる**5.5億枚（Total Supplyの約61%）**を、スマートコントラクトを用いて2027年まで完全ロックしました。

この記事では、プロジェクトの宣伝……ではなく、そこに至るまでに直面した**「Solanaのメタデータ更新の沼（0x5eエラー）」や、「なぜArweave（Irys）で永続化する必要があったのか」**という、Solana開発者なら一度はハマるであろう技術的な知見を共有します。

Web3開発、特にSolanaでのトークン設計やRWAに興味がある方の参考になれば幸いです。

1. 作っているもの：Culture OS

技術的な話の前に、少しだけコンテキストを共有させてください。
私たちは、日本の観光資産（体験、ガイド、場所）をオンチェーン化し、トークンエコノミーで回す**「Culture OS」**という基盤を作っています。

昨今、Solanaといえば「ミームコイン」の爆発的な流行が目立ちますが、私たちが目指しているのは**「実需（観光）」と「DeFi」を接続するRWAの社会実験**です。

  • 観光客: アプリを通じて日本の文化体験（神社仏閣、ローカルな食事など）にアクセスする
  • トークン: その決済や、コミュニティへの貢献報酬として機能する

このエコシステムを、中央集権的なDBだけでなく、ブロックチェーン上で透明性高く回すための設計を行っています。

2. 技術的なハマりポイント：メタデータの検証エラーと分散型ストレージ

SPLトークン（Solanaのトークン規格）を発行した後、SolscanやPhantomウォレットなどでロゴやSNSリンクを正しく表示させるためには、Metaplex規格に準拠したメタデータを更新する必要があります。

しかし、ここで多くの開発者が遭遇する**「検証エラー（Instruction Error: 0x5e）」**に私も大いに苦しめられました。

問題：中央集権サーバーと署名の罠

当初、私はメタデータ（JSONファイル）と画像データを、自社で管理しているPaaS（Railway）上に置いて参照させていました。

// ダメだった例（自社サーバー参照）
{
  "uri": "[https://backend-api.railway.app/metadata/token.json](https://backend-api.railway.app/metadata/token.json)"
}

これでも表示されるケースはあるのですが、以下の問題が発生しました。

  1. 署名の検証エラー（0x5e）: UpdateMetadataAccountV2 などのインストラクションを送る際、クリエイターの検証フラグ（Verified）を立てようとすると、オンチェーン情報と参照先の一貫性が厳密に問われ、トランザクションが弾かれることがあります。
  2. 永続性の欠如: もしRailwayのサーバーが落ちたり、私たちがドメインの更新を忘れたりすれば、トークンのロゴは消え、ただの「Unknown Token」になってしまいます。これではRWAとしての信頼性がありません。

解決策：Arweave (Irys) への完全移行

「Web3なのだから、データもWeb3に置くべき」という基本に立ち返り、すべてのメタデータ（画像、JSON）をArweave上の分散型ストレージにアップロードし、URIを書き換える決断をしました。

アップロードには、Solana開発で標準的に使われるIrys (旧 Bundlr) を使用しています。

// 修正後のメタデータ（Arweave）
{
  "name": "Matsuri Coin",
  "symbol": "MTC",
  "description": "Real-world utility for Japan tourism...",
  "image": "[https://gateway.irys.xyz/Fn](https://gateway.irys.xyz/Fn)...", // Arweave上の不変な画像リンク
  "external_url": "[https://www.matsuri-dao.com](https://www.matsuri-dao.com)",
  "uri": "[https://gateway.irys.xyz/7F](https://gateway.irys.xyz/7F)...", // Arweave上の不変なJSONリンク
  "sellerFeeBasisPoints": 0,
  "creators": [
    {
      "address": "AzkRxt...", // デプロイヤーのアドレス
      "verified": 1,        // ここをTrueにするのが最重要
      "share": 100
    }
  ],
  "extensions": {
      "website": "[https://www.matsuri-dao.com](https://www.matsuri-dao.com)",
      "twitter": "[https://x.com/matsuri_dao_jp](https://x.com/matsuri_dao_jp)"
  }
}

Irysの採用メリット:
Arweaveへのアップロードは確実性が高く、一度書き込めば半永久的にデータが残ります。これにより「サーバーレスで永続的にデータが残るWeb3トークン」としてデプロイが完了しました。

3. なぜ5.5億枚もロックしたのか（Streamflow）

技術的には、発行したトークンを開発者のウォレット（Phantomなど）に入れておくだけでも「保有」はできます。

しかし、それでは外部（投資家やユーザー）から見て、**「開発者がいつでもDump（売り抜け）できる状態」**と区別がつきません。
「私たちは本気です」と口で言うのは簡単ですが、ブロックチェーンの世界では Code is Law です。コードで証明しなければ意味がありません。

そこで、Solana上の主要なストリーミング決済プロトコルであるStreamflowを採用し、トークンをコントラクトに預け入れました。

ロックの設計仕様

  • プロトコル: Streamflow
  • 対象枚数: 550,000,000 MTC（総供給の約61%）
  • クリフ（完全ロック）期間: 2027年6月1日まで
  • ベスティング（解放）: その後、時間経過とともにリニア（直線的）に解放

これにより、**「秘密鍵を持っていても、物理的にトークンを動かせない状態」**を強制しました。
私がもし悪意を持って売り抜けようとしても、トランザクションはコントラクトによって拒否されます。これが「トラストレスな信頼の担保」です。

4. まとめと「設計図」

Web3×観光の実装は、まだベストプラクティスがない荒野です。
メタデータ一つとっても、サーバー依存にするか分散型にするかで「資産としての強度」が変わります。
だからこそ、エンジニアとして挑戦する価値があると感じています。

今回のトークノミクスの詳細や、私たちが構築しようとしているエコシステム（Culture OS）の全貌、そしてSolanaとRWAをどう接続するかというアーキテクチャについては、ホワイトペーパーとして公開しました。

技術的な構成やロードマップに興味がある方は、ぜひ覗いてみてください。
「観光×ブロックチェーン」で世界をどうハックしようとしているか、その設計図がすべて書いてあります。

今後も、ZennではSolana開発の技術的な知見（Rustでのコントラクト開発や、インデクサ周りの話など）を共有していければと思います。

👇 ホワイトペーパー（公式サイト）
https://www.matsuri-dao.com/

👇 X (Twitter) / 開発の進捗発信
https://x.com/matsuri_dao_jp

Discussion