> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/ja/romenoapuri/bloom/lanes.md).

# 2つのレーン

1つのトークン展開、2つのウォレット世界。両方のレーンが実行するのは **同じコントラクト** 同じ **コンプライアンスゲート** — 違いは、誰が署名するかと、トランザクションがどのようにチェーンへ届くかだけです。

## EVMレーン

標準の Ethereum ツールをそのまま使います。ウォレットが EVM トランザクションに署名し、チェーンの JSON-RPC エンドポイントがそれを受け取り、トークンコントラクトが許可リストを強制します。統合する Bloom 固有の要素はありません。

Rome のガスは USDC 建てで、Solana アカウントを作成する必要がある場合（初回保有者、新しいトークンアカウント）、書き込みコストは Ethereum 相当より高くなります。使用 `eth_estimateGas`、標準ツールと同様に、21,000 をハードコードしてはいけません。見積もりにはアカウント作成が含まれており、Rome は実際に使用したガスだけを請求します。ゲート付き転送では許可リストのチェックにも料金がかかるため、同じサイズの単純な転送より高くなります。

## Solana レーン

Solana ウォレットが同じ EVM コントラクトを駆動します **ネイティブに — EVM キーはどこにも存在しません**。すべての呼び出しは Solana v1 トランザクションで、チェーンのプロキシがウォレットに署名させるために組み立てます。アドレス参照テーブルも、組み立てるべき compute-budget 指示もありません。プロキシ自身が compute と heap の予算を設定します。

1. **識別情報。** ユーザーの EVM 側アドレスは *synthetic*：決定論的に次のように導出されます `keccak256(solana_pubkey)[12..32]`。Rome の EVM プログラムは、トランザクションの実際の署名者からオンチェーンでそれを導出します — 偽装はできず、それ用の secp256k1 秘密鍵も存在しないため、 **このアドレスを動かせるのは、Solana署名だけです**.
2. **承認。** アプリは、チェーンから読み取った nonce、gas price、gas 見積もりを使って、呼び出しを未署名の EIP-1559 ペイロードとして組み立てます。ウォレットは可読なメッセージに署名し、それは次のように表示されます *Rome authorization* その後に呼び出しのハッシュが続きます — これにより、Solana キーがこの特定の EVM ペイロードを承認していることが証明されます。これが最初のプロンプトであり、これがなければプロキシは呼び出しを組み立てません。
3. **組み立て。** アプリはそのペイロードと署名をプロキシに送ります。プロキシは署名を検証し、どの Solana アカウントに触れ、どれが書き込み可能かを調べるために呼び出しをエミュレートし、1つの Solana v1 トランザクションを返します。アプリは返されたメッセージを確認してから、ウォレットに署名を求めます。
4. **署名して送信。** ウォレットがトランザクション自体に署名します。2回目のプロンプトで、別のバイト列に対する別の署名です。アプリは署名済みトランザクションをそのまま Solana RPC に送信し、ユーザーは自分のウォレットから SOL で Solana 手数料を支払います。
5. **確認。** トランザクションは Solana 上で確定します。EVM の表示は少し遅れて追いつくため、アプリは次の呼び出しを送る前に synthetic アドレスの nonce が進むのを待ちます。

**ウォレットは Solana v1 トランザクションに署名できなければなりません。** それがなければレーンはフェイルクローズします。v1 トランザクションに署名できないウォレットでは呼び出しはエラーで停止し、アプリが古いトランザクション形式にフォールバックすることはありません。Solflare は現在 devnet で v1 に署名できますが、Phantom はまだできません。

### 呼び出し前：資金の移動と一度きりの許可

Solana レーンの呼び出しの前には2つのことがあり、それぞれが独自のプロンプトを持つ個別のステップとして表示されます：

* **資金を移動する。** wUSDC を消費する呼び出しは、静止時には何も保持していない synthetic アドレスからそれを引き出します。synthetic の残高が呼び出しに必要な額より少ない場合、アプリはまず不足分をウォレット自身の USDC トークン口座から synthetic の口座へ移します。これは1回のプロンプトで署名する1つの Solana トランザクションであり、EVM 呼び出しではありません。synthetic のトークン口座を冪等に作成し、その後に Rome プログラムの activate-token-account 命令で EVM を実行せずにトークンを移します。synthetic にすでに十分な残高がある場合は省略されます。
* **一度きりのラッパー許可。** wUSDC は SPL トークンのラッパーであり、ラッパーはユーザーの SPL デリゲートとしてそのユーザーのトークンを移動します。ウォレットの synthetic アドレスが初めて wUSDC を使うとき、この許可はまだ設定されておらず、アプリは **wUSDC転送の許可** 他の処理の前に1ステップを挿入します。これは他と同じ1回の呼び出し（2回のプロンプト）で、ウォレットごとに1回だけです。参照： [ウォレットごとの一回限りの許可](/ja/ji-ben-gai-nian/token-interop.md#one-time-grant-per-wallet).

したがって、新しい Solana ウォレットからの購入は短い手順になります。資金を移し、wUSDC 転送を許可し、ストアフロントを承認し、購入します。

### 1つのトランザクションには大きすぎる呼び出し

アトミックな Solana トランザクションには固定の上限があります。おおよそ 140 万 compute unit、64 アカウント、そして送信時 4 KB です（参照： [制約](/ja/ji-ben-gai-nian/constraints.md)）。Bloom は常に、ウォレット署名の直接トランザクションを最初に試します。プロキシが、1つのトランザクションに収まらないために呼び出しを拒否した場合にのみ、アプリはそれをプロキシに引き渡して **中継**し、それ以前には決して行いません：

* **その呼び出しに対するプロンプトは1回。** 中継は、ウォレットが拒否された試行で既に署名した認可メッセージを再利用するため、同じ内容の2回目のプロンプトも、署名するトランザクションもありません。プロキシが呼び出しを組み立て、必要な数のトランザクションで Solana に送信し、Solana 手数料は自ら支払います。
* **Rome の gas は synthetic の残高から支払われます。** 中継された呼び出しは、チェーンのネイティブ gas を wei で synthetic アドレスから支払います。その残高が呼び出しコストに足りない場合、アプリはまずウォレットから 10^12 wei の整数単位で補充します。これはもう1回のプロンプトで、通常は許可と同様にウォレットごとに1回です。
* **ハッシュは Rome のトランザクションハッシュです。** 中継された呼び出しの結果は、Solana の署名ではなくプロキシの EVM トランザクションハッシュなので、Solana エクスプローラーでは開けません。チェーン専用のエクスプローラーで確認してください。

中継は、プロキシが1つのトランザクションには大きすぎると報告した呼び出しに適用されます。Credit では、より大きな市場アクションがこれに含まれることがあります。単純な転送や承認を含むほとんどの呼び出しは1つのトランザクションに収まり、この経路は使いません。中継された呼び出しの仕組みと制限については、 [リレイされた呼び出しと長時間呼び出し](/ja/gaido/call-evm-from-solana.md#relayed-calls-and-long-calls).

### ステップごとのプロンプト

| ステップ                          | ウォレットのプロンプト                     |
| ----------------------------- | ------------------------------- |
| 資金を移動する（不足している場合のみ）           | 1                               |
| wUSDC 転送を許可する（ウォレットごとに1回）     | 2                               |
| 1つのトランザクションに収まる呼び出し（承認、購入、転送） | 2：認可メッセージ、その後トランザクション           |
| 中継が必要な呼び出し                    | 1、加えて残高が不足している場合は一度きりの gas 補充に1 |

Invest の資産ページでは、Solana ウォレットは Buy を押した後、1回の実行で資金移動、許可、承認、購入を行います。各ステップで署名しながら、ボタンには「2回のウォレットプロンプト」と表示されます。名前付きのステップ（「Transferring your cash」）と事前のプロンプト数は Trade と Credit に表示されます。EVM ウォレットにも一度きりの *wUSDC転送の許可* 購入パネル上のステップがあります。

### 以前のレーンでの計測済み compute

v1 トランザクションへの移行前、このレーンは独自にトランザクションを組み立て、Rome devnet でこれらの数値を計測しました。2つのチェーンにわたって観測された範囲です。現在プロキシが組み立てる v1 トランザクションでは再計測されていないため、予算ではなく桁感として読んでください：

| Solana レーンのフロー                                    | CU         |
| ------------------------------------------------- | ---------- |
| ゲート付き RWA 転送                                      | \~339–381K |
| wUSDC 承認                                          | \~189–191K |
| ストアフロント購入（承認 + 購入、2つのトランザクション）                    | \~730–796K |
| キャッシュ部分をウォレット自身のトークン口座へスイープ                       | \~42–54K   |
| 単純な値転送                                            | \~47K      |
| `TestApprover.approve` — 許可リストへの受け入れ、 **ウォレット署名** | 220,794    |

Solana のトランザクションごとの compute 上限は 140 万 CU です。自分の呼び出しは、Solana トランザクションの `meta.computeUnitsConsumed` (`getTransaction` を、Solana RPC の getTransaction で測定してください。チェーンの EVM レシートにはそのようなフィールドはないため、ここにある値のどれかだと決めつけないでください。

## 保管：RWA が synthetic に留まる理由

すべての許可制資産が答えなければならない設計上の問い： *トークンはコンプライアンスの境界外に漏れ出すことができるのか？* Solana レーンでは、その答えはポリシーではなく構造にあります：

* **RWA は EVM ステート上に存在します。** その残高は Rome の EVM プログラムのアカウント内のストレージです。そこには **SPLミントはありません** それのトークン口座表現もなく、Solana ネイティブで移動できるものも何もありません。（これは意図的です — ラップ/ミラー版が逃げ道になってしまうためです。）
* **Solana 側の配管はそれに触れません。** レーンの資産移動部分（`create_ata`、SPL 転送、スイープ）は SPL トークン口座上で動作します。EVM ストレージ残高にはそのような口座はありません。EVM 残高を Solana のトークン口座へ移す命令はありません。
* **所有者の Solana 署名だけが synthetic を駆動します**、そしてそれが表現できるあらゆる移動はトークンコントラクトへの呼び出しです — そのコントラクトが許可リストのゲートを実行するため、ホワイトリストにないアドレスへの転送は、EVM キー署名でも Solana キー署名でも同一にリバートします。
* **キャッシュ部分は意図的な例外です。** wUSDC（利回り、売却代金）は SPL に裏付けられており、 *〜すべきです* 往復します：出口側（`transfer_spl`）はそれを synthetic からウォレット自身の関連トークン口座へ移し、エンドツーエンドで検証されます。資産は境界内にとどまり、キャッシュは自由に流れます。

実務上の結果を率直に2つ述べると、Solana ウォレット UI は RWA 保有を表示しません（一覧に載せる SPL トークンがないためです）— Bloom アプリがポジション表示の表面です。また、紛失した Solana キーは発行者のプロセスで復旧されます（[COMPLIANCE.md](/ja/romenoapuri/bloom/compliance.md#issuer-powers-transfer-agent-shaped)）、資産を別経路で移動するのではありません — それこそが許可制資産に求められる性質です。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/ja/romenoapuri/bloom/lanes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.