> 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/gaido/from-home.md).

# ホームから：別のチェーンからRomeにアクセス

他チェーンのユーザーが、家を離れずにあなたのRomeアプリにアクセスできるようにします — 資産を持ち込み、操作し、また持ち出します。

ユーザーは Rome へ移動する必要はありません。自分のホームチェーン――Arbitrum や Monad のような L2、または Solana――から資産を持ち込み、あなたの Rome アプリを使って、資産を再び持ち出します。ブリッジはオンチェーンで、ユーザー自身の署名によって承認されます。あなたは 1 つの API を通じてアプリをそれにつなげます。

## 仕組み

* **インバウンド（ホーム → Rome）：** CCTP 上のガストークン USDC ルートでは、 `settle_inbound_bridge_v2` 命令によって、署名済みの **EIP-712** `SettleAuthorization`で、特権的な決済者は存在しません。その他のインバウンドルートでは、その命令や署名は使いません。ラッパー USDC、Wormhole 経由の ETH、SOL は、ユーザーのアカウントにラッパートークンとして直接着地します。ガストークンが USDC のチェーン上の Solana USDC では、ラッパーをガスに変えるために、ユーザー署名済みの追加トランザクションが 1 回必要です。見積もりには、ルートごとに必要な署名が示されます。
* **アウトバウンド（Rome → ホーム）：** `RomeBridgeWithdraw` （in [`rome-solidity`](https://github.com/rome-protocol/rome-solidity)）で、Rome 上の資産が焼却されます。その後ユーザーは、自分のトランザクションでホームチェーン上でそれを請求します。
* **輸送：** Circle **CCTP** による USDC と、 **Wormhole** による ETH のトークンブリッジです。Solana をホームチェーンにする場合は、単純な SPL 転送で入金し、Rome の引き出しで出金します。Wormhole は ETH のみのインバウンド経路です。汎用の Wormhole ルートはアウトバウンド専用で存在し、そこで扱える各資産は事前に Rome のオペレーターによって有効化されていなければなりません。
* **オーケストレーション：** オフチェーンの [`rome-bridge-api`](https://github.com/rome-protocol/rome-bridge-api) がルートを見積もり、ソースチェーンのトランザクションを検証し、決済手数料を負担します。資金も鍵も保持しません。ユーザーがすでに署名した内容しか実行できません。

## 実装する

API は devnet 上で公開されています： `https://bridge-api.devnet.romeprotocol.xyz`. `GET /v1/routes` は稼働中のすべてのルート（資産、経路、方向、ソースチェーン、Rome チェーン、速度）を一覧します。以下の呼び出しは、SDK が `@rome-protocol/sdk/bridge` (`requestQuote`, `registerTransfer`, `getTransfer`, `reportStep`でラップしている 4 つと同じです）。CLI は次のように全体のフローを実行します： `rome fund` および `rome bridge` は送金用、 `rome verify --path from-home` は往復用です。詳細は [Rome CLI](/ja/zhi-pin/rome-cli.md) ページにあります。

### 資産を持ち込む

1. **ルートを見積もります。** ユーザーのソースチェーン、資産、金額、アドレスを送信します。チェーンは CAIP-2 ID として、たとえば `eip155:84532`; `romeChainId` があなたの Rome チェーンです。古い名前の `ethereum` および `solana` もまだ受け付けられますが非推奨で、API はそれらのレスポンスに `Sunset` ヘッダーを付けます。完全なリクエストとレスポンスの形は [API reference](https://github.com/rome-protocol/rome-bridge-api/blob/main/docs/API.md).

   ```bash
   curl -X POST https://bridge-api.devnet.romeprotocol.xyz/v1/quote \
     -H 'Content-Type: application/json' \
     -d '{
       "asset": "USDC",
       "direction": "to-rome",
       "sourceChain": "eip155:84532",
       "romeChainId": "200010",
       "amount": "1000000",
       "sender": { "ethereum": "0xUSER" },
       "recipient": "0xUSER"
     }'
   ```

   金額は文字列のベース単位整数です（`"1000000"` は 1 USDC です）。ETH の金額は wei で表し、出金時には 10,000,000,000 wei の倍数でなければなりません（ラッパーは 8 桁です）。API はそれより細かい値を拒否します。レスポンスには `ステップ`が一覧されます。ユーザーは、 `userSigns: true`とマークされた各ステップのトランザクションに、ステップ順に署名します。EVM トランザクションは `unsignedTxs`に、Solana 命令は `unsignedTx`に入っています。返されたとおりにそのまま署名してください。署名不要のステップは、Circle または Wormhole が転送を証明した後、スポンサーによって実行されます。アウトバウンドの請求は例外で、以下に説明するようにユーザーが作成します。
2. **ユーザーに署名させます。** CCTP の見積もりでは、それはソースチェーン上での USDC 承認とバーンです。見積もりに `signatureRequests`へのエントリがある場合、ユーザーはその EIP-712 `SettleAuthorization` にも署名します。バーンハッシュが分かったら、その値を埋めて、結果を次の呼び出しの `userSettleSig` として渡します。これを持つのはガストークン CCTP ルートだけです。Wormhole ETH、ラッパー意図の USDC、Solana ルートにはありません。
3. **転送を登録します。** `POST /v1/transfers` に完全な見積もりと `step1TxHash`を添えて送ります。これは最初のステップ（バーン）の最後のトランザクションのハッシュです。API はソースチェーン上のトランザクションが見積もりと一致することを確認し、transfer `id`.
4. **ポーリングします** `GET /v1/transfers/{id}` を数秒ごとに `結果` は `complete`になるまで繰り返します。その後、ユーザーは Rome 上で資金を受け取り、あなたのアプリを使えるようになります。

Solana のホームチェーンでも、形は同じでステップが異なります。ユーザーは SPL 転送を自分の Rome アカウントのトークンアカウントへ送ります。その 1 回の転送の後、SOL はラップされた SOL として届きます。Hadrian のようにガストークンが USDC のチェーンでは、USDC には 2 つ目のステップが必要です。ユーザーが署名する Rome トランザクションで、着地したラッパーをネイティブガスに変えます。それ以外の SPL トークンは `spl-solana-to-rome` ルートを通ります。これは `splAsset`.

### 資産を再び持ち出す

出金は、インバウンドの流れを逆にしたものではありません。複数の署名があり、ユーザーはホームチェーン上で最後まで完了させます。見積もりでは `direction` を `from-rome`. `に設定し、` sourceChain `destinationChainId` がユーザーの請求先チェーンを選びます。両方を渡してください： `destinationChainId` が請求チェーンを決めるもので、これがない見積もりはデフォルトで Ethereum Sepolia になります。 `に設定し、` は次のようになります：

```bash
curl -X POST https://bridge-api.devnet.romeprotocol.xyz/v1/quote \
  -H 'Content-Type: application/json' \
  -d '{
    "asset": "USDC",
    "direction": "from-rome",
    "sourceChain": "eip155:84532",
    "destinationChainId": 84532,
    "romeChainId": "200010",
    "amount": "1000000",
    "sender": { "rome": "0xUSER" },
    "recipient": "0xUSER"
  }'
```

CCTP 経由の USDC では、見積もりは 2 ステップを返し、ユーザーはその両方に署名します：

1. **Rome 上では、順番に 2 つのトランザクション。** 最初のものは `RomeBridgeWithdraw` Solana 上のユーザーの wUSDC に対する委任権を付与します（`approve_spl`）。この付与はちょうどこのバーンの金額を対象にするので、見積もりには毎回含まれ、ユーザーは各バーンの前にそれへ署名します。2 つ目は `RomeBridgeWithdraw`を通じて wUSDC をバーンし、CCTP 転送を開始します。バーンのハッシュで転送を登録します。バーンで使うのは、見積もりで `burnToken`と示されたトークン、つまりネイティブガスの USDC ではありません。ガスとして入ってきた資金は焼却対象ではないので、往復するなら USDC は `intent: "wrapper"`.
2. **にして持ち込んでください。** ポーリングします `GET /v1/transfers/{id}` がステップ 2 の `ready`になるまで。そこで `message` および `attestation`を運びます。ユーザーは `receiveMessage(message, attestation)` を、宛先チェーン上の Circle の message transmitter で呼び出します（見積もりには transmitter と CCTP domain が示されます）。ここではスポンサーされないため、ユーザーにはそのチェーンでガスが必要です。請求ハッシュは `POST /v1/transfers/{id}/steps/2`.

Wormhole 経由の ETH も同じ形です。ユーザーは同じ委任権を wETH に対して付与し、Rome 上で wETH をバーンし、Wormhole の guardians が署名するのを待ちます。その後ユーザーは自分のトランザクションで Ethereum 上で償還します： `completeTransferAndUnwrapETH` 見積もりに示されたトークンブリッジ（`claimTokenBridge`）上で、ステップ 2 の署名済みメッセージ（`vaa`）を使って。

Solana アドレスへの出金には請求ステップがありません。USDC は、ユーザーの Solana アカウントへ出金する 1 回の Rome トランザクションです。SOL は 3 つのトランザクションを含む 1 つの Rome ステップです。同じ wSOL に対する委任付与、Solana 上の受取人の wSOL トークンアカウントを必要に応じて作成する処理（すでに存在する場合は省略）、そして `RomeBridgeWithdraw`.

**最初のアウトバウンド転送には有効化済みアカウントが必要です。** CCTP のバーンは Solana 上に message アカウントを作成し、Rome 上のユーザーアカウントにはそれを支払うのに十分な lamports が必要です。新しいウォレットにはそれがないため、ユーザーが 1 度有効化するまで最初のアウトバウンド転送は失敗します。確認は、アカウントが少なくとも 15,000,000 lamports を持っていることです。次で読み取れます： `account_lamports(bytes32)` を CPI precompile の `0xff00000000000000000000000000000000000008`で呼び出し、Solana 上のユーザーの外部認証アカウントを渡します（CLI はこの読み取りを自動で行います）。有効化は `activate()` を `SimpleActivator` で呼び出します。 [registry](https://github.com/rome-protocol/rome-registry) にある、あなたのチェーン用に सूचीされたコントラクト上で行われ、呼び出しにはチェーンのガストークンでの支払いが伴います。Hadrian では 2 USDC です。CLI ではこれを `rome activate <chain>`、そして `rome bridge --to` が止まり、アカウントが準備できていない場合は実行するよう指示します。準備金は 1 回のバーンを賄い、rent は Circle がバーンを証明した後に戻ってきます。これには約 30 分かかります。それより前に 2 回目のバーンを行う場合、または有効化後に資金が使い果たされたアカウントでは、 `topUpUserPda(lamports)` を同じコントラクト上で行う必要があります。なぜなら `activate()` アカウントが有効化されると revert するからです。 `rome activate` が適切な呼び出しを選びます。インバウンド転送には有効化は不要です。見積もりには有効化がステップとして含まれていないため、あなたのアプリは最初のアウトバウンド見積もりの前にアカウントを確認し、それを案内する必要があります。

## コードを読む

* [appia](https://github.com/rome-protocol/appia) — ホームからのアプリ：ユーザーはホームチェーンから USDC を持ち込み、Rome 側の DeFi をそこから離れずに使います。
* [rome-bridge-api](https://github.com/rome-protocol/rome-bridge-api) — オーケストレーター（見積もり → 検証 → スポンサー）。

## 次に何をするか

* [資金を受け取る](/ja/rissu/faucets.md) — 同じブリッジ経路で新しい dev ウォレットに資金を入れます。
* [Solidity をデプロイ](/ja/gaido/deploy-solidity.md) — あなたのアプリを Rome に置きます。


---

# 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/gaido/from-home.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.
