> 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/open-to-solana-users.md).

# Solanaユーザーにコントラクトを開放する

Rome（Hadrian testnet、Rubicon mainnet）にSolidityコントラクトをデプロイし、Solanaウォレットに公開する — コントラクトに必要なもの、Solanaウォレット利用者がどう呼び出すか、ネットワークごとのアドレス、および launch ch

1回のデプロイ、2種類のユーザー。Rome上のコントラクトには、MetaMaskユーザーがEVM鍵でアクセスし、Solanaウォレットユーザー（たとえばSolflare）がSolana鍵でアクセスします。アドレスは同じ、状態も同じです。このページはエンドツーエンドの手順です。デプロイし、コントラクトをSolana対応にし、アプリにSolanaルートを組み込み、mainnetに出します。

## 1. 希望するネットワークにデプロイする

Romeチェーンは標準的なEVMターゲットです。Hardhat、Foundry、viem、ethersはそのまま動作します（完全な手順は [Solidityコントラクトのデプロイ](/ja/gaido/deploy-solidity.md)).

| ネットワーク                                          | チェーンID   | RPC                                         | エクスプローラー                                                                              | ガストークン   | ガスの入手方法                                                                                                                                 |
| ----------------------------------------------- | -------- | ------------------------------------------- | ------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| [**Rubicon**](/ja/nettowku/rubicon.md) （メインネット） | `7531`   | `https://rubicon.mainnet.romeprotocol.xyz/` | [via-rubicon.mainnet.romeprotocol.xyz](https://via-rubicon.mainnet.romeprotocol.xyz/) | USDC     | Ethereum（CCTP）から、またはSolanaから、次の方法でUSDCをブリッジします [Rome Bridge](https://bridge-api.mainnet.romeprotocol.xyz/)すると、gasとして着金します               |
| **Hadrian** （テストネット）                            | `200010` | `https://hadrian.testnet.romeprotocol.xyz/` | [via-hadrian.testnet.romeprotocol.xyz](https://via-hadrian.testnet.romeprotocol.xyz/) | テスト用USDC | テストネットからテスト用USDCをブリッジする（[フォーセット](/ja/rissu/faucets.md)）か、次の中でSolana devnetウォレットからラップします [Rome App](https://app.devnet.romeprotocol.xyz) |

gasはEVM側では小数18桁のUSDCです。どのネットワークにもRomeのfaucetはありません。書き込みはEthereumの感覚より多くのgasを消費します。ほとんどのコストはSolanaアカウントの作成だからです。未使用の受取人、新しいトークンアカウント、デプロイ済みコントラクト。使用してください `eth_estimateGas`、標準的なツールはそうします。21,000をハードコードしてはいけません。Hadrianで計測したところ、10バイトのコントラクトのデプロイは見積もりでも実使用でも1,147,921 gasで、未使用アドレスへのネイティブ送金は1,086,961 gasでした。既存アドレスへの送金は21,000 gasです。Romeは実際に使われたgasだけを請求し、これらの計測では見積もりを上回ることはありませんでした。最初のデプロイ前にUSDCを少し入金してください。あとでエクスプローラーでソースを検証します（[コントラクトを検証](/ja/gaido/verify-contracts.md)；メインネットの検証ツールは `https://verify.mainnet.romeprotocol.xyz`).

Hadrianで開発し、その後、chain IDとメインネットのwrapperアドレスを入れ替えて同じ成果物をRubiconに再デプロイします。ネットワーク間でコントラクト自体は何も変わりません。Rubiconは公開レジストリにはまだ `create-rome-app` または `rome-cli` 登録されていないため、そこからチェーン値を読むツールでは対象にできません。値は手動で次から埋めてください [Rubicon](/ja/nettowku/rubicon.md)。Rubiconのgasは実USDCで、Hadrianのgas価格のおよそ10倍なので、デプロイには実費がかかります。

## 2. コントラクトをSolana対応にするもの

SolanaユーザーのEVM上のIDは **シンセティックアドレス**, `keccak256(solana_pubkey)[12:]`：通常の `msg.sender`、通常のnonceを持つものです。ほとんどのコントラクトはまったく変更不要です。重要なのは次の3点です。

* **値はERC-20として受け取ります。〜ではなく `msg.value`.** Solanaユーザーの資金はウォレット内のSPLトークンで、EVM側ではそのトークンのラッパー（`wUSDC`, `wETH`, `wSOL`）。シンセティックは平常時には何も保持せず、ユーザーの資産はラッパーとして届くため、次で引き出します `transferFrom` 後に `approve` そして〜で返します `transfer`。[一回限り：ラッパーに付与](/ja/gaido/dual-lane-app.md#one-time-grant-the-wrapper)）。 `payable` エントリポイントは、シンセティックにネイティブgasが付与された後でのみ機能します（リレールートの `rome_composeExternalDepositV1`）。しかし、fund-and-sweepモデルではそれを行いません。既存のERC-20 vault、AMM、レンディング市場はすでに適切な形を持っています。
* **標準のラッパーを使ってください。** 各チェーンには各mintにつき1つのラッパーがあり、アドレスは [Contract Addresses](/ja/rifarensu/contract-addresses.md) （Hadrianのものも公開 [registry](https://github.com/rome-protocol/rome-registry)されています）。コンストラクタはそれらのアドレスを指すようにし、自分でデプロイしないでください。
* **ウォレットが署名する箇所で、アトミック予算に収める。** SolanaウォレットはSolanaトランザクション1件に署名するため、Solanaルートの呼び出しはそれに収める必要があります。目安は約140万compute unit、64アカウント、4KB（[制約](/ja/ji-ben-gai-nian/constraints.md)）。Hadrianでの計測では、transfer、approve、Aaveのsupplyは収まりました。Uniswap V3のswapは余裕が少ないものの収まります（約124万CU）。Aaveのborrowは収まらず、次のセクションのリレールートになります。Solanaレシートの `computeUnitsConsumed`を使ってトランザクションを要求しつつ、 `maxSupportedTransactionVersion: 1` （Romeのレッグはv1トランザクションです。これがないとフィールドは0になります）。

不要なもの：Solanaプログラム、ブリッジ、2回目のデプロイ、Rome固有のSolidity。コントラクトがprecompile経由でSolanaプログラムも呼ぶなら、次を参照してください [EVMからSolanaを呼ぶ](/ja/gaido/call-solana-from-evm.md).

## 3. Solanaウォレットに呼び出させる

アプリのEVMルートは変わりません（MetaMask + `submitRomeTx`、または通常のviem/ethers）。

**SDKルート — 1回の呼び出しにつきSolana v1トランザクション1件。** [`@rome-protocol/sdk`](https://github.com/rome-protocol/rome-sdk-ts) (`submitRomeTxV1`）では、プロキシがEVM呼び出し用にSolana v1トランザクション1件を組み立てます（最大64アカウント、4KB、address lookup tableなし。コード内にComputeBudget instruction、treasure wallet、account discoveryはありません）。ウォレットは同じ鍵で2回署名します。まず可読な認可メッセージ（`Rome authorization` 1行目に `0x` 次の行にEVMトランザクションハッシュ）、それをチェーンがEd25519プログラムで検証し、その後にトランザクションを署名します。アプリは署名済みトランザクションをSolana RPCに送信し、呼び出しはEVMトランザクションハッシュとそのレシートを返します。ウォレットがトランザクションに署名する前に、SDKがそれをチェックします。payerが唯一の署名者であり、RomeプログラムとEd25519 verifierだけが実行され、Rome instructionにはユーザーが認可した呼び出しがそのまま入っており、priority feeはありません。それ以外は拒否されます。

呼び出しが1つのトランザクションに収まらない場合、composerはそれを拒否し、SDKは同じ認可署名のままプロキシに渡してリレーさせるため、ユーザーには認可プロンプトが1回だけ表示されます。その結果は `route: "relay"`。リレーされた呼び出しと長い呼び出しのルールは [リレイされた呼び出しと長時間呼び出し](/ja/gaido/call-evm-from-solana.md#relayed-calls-and-long-calls)にあります。リレーされた呼び出しはチェーンのネイティブgasで支払われるため、シンセティックにはgas残高が必要です： `fundSyntheticGas(deps, amountWei)` ウォレットのトークンアカウントからチェーンのgasトークン（HadrianとRubiconではUSDC）をその中へ移し、1回のウォレット署名付きv1トランザクションで行います。

fundレッグ（`buildFundLeg`）と、sweep前のウォレットのトークンアカウント作成は、通常のSolana instructionです。 `submitSolanaInstructionsV1` それらも同じウォレット署名者によってv1トランザクションとして送信し、プロキシは介在しません。sweep自身の呼び出し（`buildSweepLeg`, `HelperProgram.transfer_spl`）は `submitRomeTxV1` 他と同様に通り、プロキシがトークンアカウントを見つけます。 `submitRomeTxV1` は単独では新しいシンセティックのアカウントを作成しません。最初の値移動呼び出しの前に `isSyntheticProvisioned(...)` を確認し、falseなら `buildCreatePdaCall(synthetic)` を通って `submitRomeTxV1` を1回送信します。コード付きの完全なdeposit-and-withdraw手順は [デュアルレーンアプリを構築する](/ja/gaido/dual-lane-app.md)；仕組みは [SolanaからEVMを呼ぶ](/ja/gaido/call-evm-from-solana.md)でプロビジョニングされます。以前の `submitRomeTxSolanaLane`にあり、クライアント側で従来のSolanaトランザクションを組み立てるもので、SDKには旧ルートとして残っています。

**各 `deps` 値の出どころ。** SDKの `deps` オブジェクトには必須フィールドが5つあります（それ以外、例えば `fetchImpl` やタイムアウトは任意です）。

| `deps` フィールド | 由来                                                                           | レジストリ取得関数（`@rome-protocol/registry` v0.2.0）                                    |
| ------------ | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| `proxyUrl`   | チェーンのRPC URL                                                                 | `getChain(chainId).rpcUrl`                                                     |
| `chainId`    | チェーンID                                                                       | `getChain(chainId).chainId`                                                    |
| `programId`  | チェーンが実行するRome program ID                                                     | `getChain(chainId).romeEvmProgramId`                                           |
| `connection` | チェーンのクラスタ用のSolana RPC。署名済みトランザクションはそこへ送られます（Hadrianはdevnet、Rubiconはmainnet）。 | `getChain(chainId).solana.rpc` （Hadrian用の公開devnet URL）；mainnetでは自前のRPCを使ってください |
| `signer`     | ウォレットの `LaneSigner`、または `Keypair` スクリプト内の                                    | なし                                                                             |

レッグビルダーが受け取る値には、〜に含まれていないものがあります `deps`。その `トークンのラッパーを見つけるには、その` （ `usdcMint` と呼ばれるもの）は、gasトークンのSolana mintで、次から取得します `getTokens(chainId)` （ `kind: "gas"`、フィールド `mint`）。wUSDCラッパーのアドレスはレッグビルダーの入力ではありません。ERC-20の呼び出しに使い、それは次のエントリです `kind: "spl_wrapper"` およびシンボル `wUSDC` （フィールド `アドレス`）。レジストリはHadrianを対象にしています。Rubiconでは手動で入力してください： `proxyUrl` `https://rubicon.mainnet.romeprotocol.xyz/`, `chainId` `7531`, `programId` `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX`, `トークンのラッパーを見つけるには、その` `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`、次のセクションの表にあるラッパーと、Solana mainnet RPCを `connection`. [Rubicon](/ja/nettowku/rubicon.md) に使います。完全な一覧があります。

**プロキシの外部V1エンドポイント — SDKなしの同じルート。** SDKは、atomic compose、relay、gas deposit（`fundSyntheticGas`）をラップします。SDKを使わないクライアント向けには生のRPCメソッドが残っており、SDKがラップしないiterative composeも含まれます。ウォレットは呼び出し全体に対して1つのEd25519メッセージに署名します（可読形式の `Rome authorization\n0x<hash>` または生のハッシュ）、そしてプロキシはウォレットに署名させるためのSolanaトランザクションを組み立てるか（`rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1` + `rome_submitSignedV1Plan`）、またはウォレットの署名1回で実行全体を自分で走らせます（`rome_relayUnsignedV1`、 `rome_composeExternalDepositV1` （SDKの `fundSyntheticGas`）でシンセティックのgas残高を補充します。リレーされた呼び出しはそこから消費するので、少なくなったら補充してください）。 [JSON-RPCサポート](/ja/rifarensu/json-rpc.md)；認可ルールは [SolanaからEVMを呼ぶ](/ja/gaido/call-evm-from-solana.md#the-external-v1-endpoints)にあります。反復処理が必要なものはrelayを使い、収まるものはすべてSDKルートを使ってください。

どちらの場合でも、コントラクトにはシンセティックのアドレスから通常のトランザクションが見え、ユーザーがEVM鍵を持つことはありません。

## 4. ネットワーク別ラッパーアドレス

| ネットワーク           | `wUSDC` ラッパー                                 | その他のラッパー                                                                                                 |
| ---------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Rubicon (7531)   | `0x0952d233b0c254cd375f3bfb3e5869c1a906f9b3` | `wETH` `0x01e8b3573da1d4b7b4b1ce0932cf07c8af0c92e9`, `wSOL` `0xc4e29e0f726a906e93277cbbc37bf27a9848a113` |
| Hadrian (200010) | `0xbce339ba4c3a8de3bb8af1c5539e6ac11da3112d` | `wETH` `0x02aeace038269f9961c93d04dcacd6fb3adfa55f`, `wSOL` `0x39f36444fcb79b3e691544aee2a832ebef54ca9f` |

ネイティブgasトークンは次のように表示されます `0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` トークンリスト内ではそう表示されますが、ERC-20コントラクトではありません。ラッパーはSPL mintの小数桁数を引き継ぎ、18ではありません。wUSDCは6、wETHは8、wSOLは9です。

## 5. ローンチチェックリスト

1. Hadrianにデプロイ済み。EVMルートはMetaMaskから動作します。
2. 値を移動するすべてのエントリポイントはERC-20ベースで、チェーンの標準ラッパーを指しています。
3. v1トランザクションに署名するSolanaウォレット（現時点ではdevnetのSolflareは可、Phantomはまだ不可）なら、Hadrianでの完全な往復が完了します。シンセティックを用意し（`create_pda`、1回）→ fundレッグ→ grant→ approve→ call→ sweepレッグをSDKルートで実行します。呼び出しが反復的ならリレールートを使います。
4. 各Solanaルート呼び出しの `computeUnitsConsumed` はSolanaレシートから読み取られ、アトミック予算内に収まる必要があります。収まらない場合は呼び出しはrelayに回されます。
5. ラッパーのgrantは、両方のルートでアプリの初回入金フローにあります： `isEnabled(user)` を確認し、 `approve_spl` がfalseのときに1回送信されます（[一回限り：ラッパーに付与](/ja/gaido/dual-lane-app.md#one-time-grant-the-wrapper)).
6. ソースはエクスプローラーで検証済みです。
7. メインネットのラッパーアドレスでRubiconに再デプロイ済み。Rubiconはレジストリにないため、その `deps` 値は次から手動で埋めます [Rubicon](/ja/nettowku/rubicon.md)。実資金を使って同じ往復を1回実行し、mainnetでv1トランザクションに署名できることを確認済みのウォレットを使います。

## 次に何をするか

* [デュアルレーンアプリを構築する](/ja/gaido/dual-lane-app.md) — vaultの例、ステップごとに、両方のウォレット
* [SolanaからEVMを呼ぶ](/ja/gaido/call-evm-from-solana.md) — シンセティックアドレス、アカウント検出、external-V1エンドポイント
* [Solidityコントラクトのデプロイ](/ja/gaido/deploy-solidity.md) · [コントラクトを検証](/ja/gaido/verify-contracts.md) · [Contract Addresses](/ja/rifarensu/contract-addresses.md)


---

# 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/open-to-solana-users.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.