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

# Sözleşmenizi Solana kullanıcılarına açın

Rome'da (Hadrian testnet, Rubicon mainnet) bir Solidity sözleşmesi dağıtın ve onu Solana cüzdanlarına açın — sözleşmenin neye ihtiyacı olduğu, bir Solana cüzdanı kullanıcısının onu nasıl çağırdığı, ağ başına adresler ve bir başlatma ch

Tek bir dağıtım, iki tür kullanıcı. Rome üzerindeki bir sözleşmeye, MetaMask kullanıcıları EVM anahtarlarıyla; Solana cüzdanı kullanıcıları (örneğin Solflare) ise Solana anahtarlarıyla ulaşır — aynı adres, aynı durum. Bu sayfa uçtan uca akıştır: dağıt, sözleşmeyi Solana’ya hazır hale getir, uygulamanızda Solana hattını bağla ve ana ağda yayınla.

## 1. İstediğiniz ağda dağıtın

Rome zincirleri standart EVM hedefleridir: Hardhat, Foundry, viem ve ethers değişmeden çalışır (tam rehber için [Solidity Sözleşmelerini Dağıtma](/tr/gelistirici-kilavuzlari/deploy-solidity.md)).

| Ağ                                           | Zincir Kimliği | RPC                                         | Gezgin                                                                                | Gaz tokeni | Gas nasıl alınır                                                                                                                                                                    |
| -------------------------------------------- | -------------- | ------------------------------------------- | ------------------------------------------------------------------------------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [**Rubicon**](/tr/aglar/rubicon.md) (ana ağ) | `7531`         | `https://rubicon.mainnet.romeprotocol.xyz/` | [via-rubicon.mainnet.romeprotocol.xyz](https://via-rubicon.mainnet.romeprotocol.xyz/) | USDC       | USDC’yi Ethereum’dan (CCTP) veya Solana’dan şu araçla köprüleyin: [Rome Köprüsü](https://bridge-api.mainnet.romeprotocol.xyz/); gas olarak gelir                                    |
| **Hadrian** (test ağı)                       | `200010`       | `https://hadrian.testnet.romeprotocol.xyz/` | [via-hadrian.testnet.romeprotocol.xyz](https://via-hadrian.testnet.romeprotocol.xyz/) | test USDC  | Test USDC’yi bir testnet’ten köprüleyin ([Faucets](/tr/kaynaklar/faucets.md)) ya da şu yerdeki bir Solana devnet cüzdanından sarın: [Rome App](https://app.devnet.romeprotocol.xyz) |

Gas, EVM tarafında 18 ondalıklı USDC’dir; hiçbir ağda Rome faucet’i yoktur. Yazmalar, Ethereum sezgisinin önerdiğinden daha fazla gas maliyeti oluşturur; çünkü maliyetin çoğu Solana hesapları oluşturmaya gider: daha önce hiç kullanılmamış bir alıcı, yeni bir token hesabı, dağıtılmış bir sözleşme. Kullanın `eth_estimateGas`; standart araçlar bunu yapar ve 21.000’i asla sabitlemeyin. Hadrian üzerinde ölçüldüğünde, 10 baytlık bir sözleşme dağıtımı tahmini olarak 1.147.921 gas kullandı ve kullandı; hiç kullanılmamış bir adrese yerel transfer 1.086.961 gas, mevcut bir adrese transfer ise 21.000 gas gerektirdi. Rome, gerçekte kullanılan gas kadar ücret alır; bu ölçümlerde bu miktar hiçbir zaman tahminin üstüne çıkmadı. İlk dağıtımdan önce birkaç USDC fonlayın. Sonrasında kaynak kodunu gezginde doğrulayın ([Sözleşmeleri Doğrula](/tr/gelistirici-kilavuzlari/verify-contracts.md); ana ağ doğrulayıcısı `https://verify.mainnet.romeprotocol.xyz`).

Hadrian üzerinde geliştirin, sonra aynı artefaktları zincir kimliği ve ana ağ sarıcı adresleri değiştirilmiş halde Rubicon’a yeniden dağıtın; sözleşmede ağlar arasında hiçbir şey değişmez. Rubicon genel kayıt defterinde henüz `create-rome-app` veya `rome-cli` yer almıyor, bu yüzden zincir değerlerini onlardan okuyan araçlar onu hedefleyemez; değerleri şu kaynaktan elle doldurun: [Rubicon](/tr/aglar/rubicon.md). Rubicon’daki gas gerçek USDC’dir ve gas fiyatı Hadrian’ın yaklaşık on katıdır; bu yüzden orada bir dağıtım gerçek para tutar.

## 2. Bir sözleşmeyi Solana’ya hazır yapan şey nedir

Bir Solana kullanıcısının EVM kimliği şudur: **sentetik adresidir**, `keccak256(solana_pubkey)[12:]`: sıradan bir `msg.sender`ve sıradan bir nonce ile. Çoğu sözleşmede hiç değişiklik gerekmez. Önemli olan üç şey:

* **Değeri ERC-20 olarak alın, `msg.value`.** Bir Solana kullanıcısının fonları cüzdanındaki SPL token’larıdır; EVM tarafında bunlar token’ın sarıcı hali olarak görünür (`wUSDC`, `wETH`, `wSOL`). Sentetik sözleşme boşta hiçbir şey tutmaz ve kullanıcının varlıkları sarıcı olarak gelir; bu yüzden çekimi `transferFrom` bir `approve` sonra yapın ve `transfer`ile iade edin. Her kullanıcı, ilk çekimden önce sarıcıya SPL delege hakkını bir kez verir ([Tek seferlik: sarmalayıcıya yetki verin](/tr/gelistirici-kilavuzlari/dual-lane-app.md#one-time-grant-the-wrapper)). Bir `ödenebilir` giriş noktası yalnızca sentetiğe yerel gas verildikten sonra çalışır (iletme yolunun `rome_composeExternalDepositV1`), ki fonla-ve-süpür modeli bunu yapmaz. Mevcut bir ERC-20 kasa, AMM ya da borç verme piyasası zaten doğru yapıya sahiptir.
* **Kanonik sarıcıları kullanın.** Her zincirde her mint için bir sarıcı vardır; adresler [Sözleşme Adresleri](/tr/referans/contract-addresses.md) içindedir (Hadrian’ınki ayrıca genel [registry](https://github.com/rome-protocol/rome-registry)). Kurucuları bu adreslere yönlendirin; kendinizinkini dağıtmayın.
* **Cüzdanın imza attığı yerde atomik bütçeye sığdırın.** Bir Solana cüzdanı tek bir Solana işlemi imzalar; bu yüzden Solana hattındaki bir çağrı buna sığmalıdır: yaklaşık 1,4M compute unit, 64 hesap, 4 KB ([Kısıtlamalar](/tr/temel-kavramlar/constraints.md)). Hadrian üzerinde ölçüldüğünde: bir transfer, bir approve ve bir Aave supply sığar; bir Uniswap V3 swap çok az boşlukla sığar (yaklaşık 1,24M CU); bir Aave borrow sığmaz ve bir sonraki bölümdeki iletme yolunu kullanır. Solana makbuzunun `computeUnitsConsumed`alanını kullanarak ölçün; işlemi `maxSupportedTransactionVersion: 1` ile isteyin (Rome bacakları v1 işlemleridir; bu olmadan alan 0 olarak okunur).

Gerekmeyenler: bir Solana programı, bir köprü, ikinci bir dağıtım ya da Rome’a özgü herhangi bir Solidity. Sözleşme ön-derlemeler aracılığıyla Solana programlarını da çağırıyorsa, bkz. [EVM'den Solana'yı çağırma](/tr/gelistirici-kilavuzlari/call-solana-from-evm.md).

## 3. Bir Solana cüzdanının bunu çağırmasına izin verin

Uygulamanızın EVM yolu değişmez (MetaMask + `submitRomeTx`, ya da düz viem/ethers). Solana yolu için iki yapı vardır.

**SDK hattı — çağrı başına bir Solana v1 işlemi.** [`@rome-protocol/sdk`](https://github.com/rome-protocol/rome-sdk-ts) (`submitRomeTxV1`) proxy’nin, EVM çağrınız için bir Solana v1 işlemi oluşturmasını sağlar (en fazla 64 hesap ve 4 KB; address lookup table yoktur; kodunuzda ComputeBudget talimatı, treasure wallet ya da hesap keşfi yoktur). Cüzdan aynı anahtarla iki kez imzalar: önce okunabilir bir yetkilendirme mesajı (`Rome yetkilendirmesi` tek satırda, `0x` ve bir sonraki satırda EVM işlem karması), zincir bunu Ed25519 programı üzerinden denetler, ardından işlemi imzalar. Uygulama imzalanmış işlemi Solana RPC’sine gönderir; çağrı EVM işlem karmasını ve fişini döndürür. Cüzdan işlemi imzalamadan önce SDK onu kontrol eder: ödeyen tek imzacı olmalıdır, yalnızca Rome programı ve Ed25519 doğrulayıcısı çalışmalıdır, Rome talimatı kullanıcının yetkilendirdiği çağrıyı birebir taşımalıdır ve öncelik ücreti olmamalıdır. Bunun dışındaki her şey reddedilir.

Bir çağrı tek bir işleme sığmıyorsa, oluşturucu onu reddeder ve SDK onu aynı yetkilendirme imzasıyla proxy’ye iletir; böylece kullanıcı yine tek bir yetkilendirme istemi görür. Sonuçta `route: "relay"`bulunur. İletilen çağrılar ve uzun çağrılar için kurallar [Yönlendirilen çağrılar ve uzun çağrılar](/tr/gelistirici-kilavuzlari/call-evm-from-solana.md#relayed-calls-and-long-calls)içindedir. İletilen bir çağrı zincirin yerel gas’ı ile ödenir; bu yüzden sentetiğin bir gas bakiyesi olmalıdır: `fundSyntheticGas(deps, amountWei)` zincirin gas token’ını (Hadrian ve Rubicon üzerinde USDC) cüzdanın token hesabından tek bir cüzdan-imzalı v1 işleminde içine taşır.

Fonlama bacağı (`buildFundLeg`) ve süpürme öncesi cüzdan token hesabı oluşturma, düz Solana talimatlarıdır; `submitSolanaInstructionsV1` bunları da aynı cüzdan imzacısının imzaladığı v1 işlemleri olarak gönderir; proxy devrede değildir. Süpürmenin kendi çağrısı (`buildSweepLeg`, `HelperProgram.transfer_spl`) `submitRomeTxV1` üzerinden `submitRomeTxV1` diğerleri gibi geçer ve proxy token hesaplarını bulur. `ilk değer taşıyan çağrıdan önce` false ise, `buildCreatePdaCall(synthetic)` içinden `submitRomeTxV1` bir kez gönderin. Kodla tam bir yatırma-çekme rehberi [Çift hatlı bir uygulama oluşturma](/tr/gelistirici-kilavuzlari/dual-lane-app.md)içindedir; mekanik ayrıntılar [Solana'dan EVM'yi çağırma](/tr/gelistirici-kilavuzlari/call-evm-from-solana.md). Daha önceki `submitRomeTxSolanaLane`içindedir; bu, istemci tarafında eski tarz bir Solana işlemi oluşturur ve SDK içinde hâlâ eski yol olarak yer alır.

**Her bir `deps` değerin nereden geldiği.** SDK’nın `deps` nesnesinde zorunlu beş alan vardır (diğerleri, örneğin `fetchImpl` ve zaman aşımı değerleri, isteğe bağlıdır). Dördü zincirden, biri cüzdandan gelir:

| `deps` alan  | Nereden geldiği                                                                                                    | Kayıt defteri alıcısı (`@rome-protocol/registry` v0.2.0)                                                          |
| ------------ | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| `proxyUrl`   | zincirin RPC URL’si                                                                                                | `getChain(chainId).rpcUrl`                                                                                        |
| `chainId`    | zincir kimliği                                                                                                     | `getChain(chainId).chainId`                                                                                       |
| `programId`  | zincirin üzerinde çalıştığı Rome program kimliği                                                                   | `getChain(chainId).romeEvmProgramId`                                                                              |
| `connection` | zincirin kümesi için bir Solana RPC’si; imzalı işlem buraya gönderilir (Hadrian için devnet, Rubicon için mainnet) | `getChain(chainId).solana.rpc` (Hadrian için herkese açık bir devnet URL’si); ana ağ için kendi RPC’nizi kullanın |
| `signer`     | cüzdanın `LaneSigner`’ı veya bir `Keypair` betiklerde                                                              | yok                                                                                                               |

Bacak oluşturucuları `deps`içinde olmayan değerleri alır. Bunların `mint` (adı `usdcMint` olanı, anlatımda) gas token’ının Solana mint’idir; `getTokens(chainId)` içindeki `kind: "gas"`olan giriş, alan `mintId`). wUSDC sarıcı adresi bir bacak-oluşturucu girdisi değildir; onu ERC-20 çağrıları için kullanırsınız ve bu giriş `kind: "spl_wrapper"` ve sembol `wUSDC` olan `address`alanıdır. Kayıt defteri Hadrian’ı kapsar. Rubicon için bunları elle doldurun: `proxyUrl` `https://rubicon.mainnet.romeprotocol.xyz/`, `chainId` `7531`, `programId` `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX`, `mint` `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`, bir sonraki bölümdeki tablodan alınan sarıcı ve `connection`. [Rubicon](/tr/aglar/rubicon.md) için bir Solana mainnet RPC.

**Proxy’nin SDK’sız aynı hat olan dış V1 uç noktaları.** SDK, atomik birleştirme, iletme ve gas yatırma işlemini sarar (`fundSyntheticGas`). Ham RPC yöntemleri SDK kullanmayan istemciler için kalır ve SDK’nın sarmadığı yinelemeli birleştirmeyi de içerir. Cüzdan çağrı üzerinde tek bir Ed25519 mesajı imzalar (okunabilir biçim `Rome authorization\n0x<hash>` ya da ham karma), ve proxy ya cüzdanın imzalaması için Solana işlemini/işlemlerini oluşturur (`rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1` + `rome_submitSignedV1Plan`) ya da tek bir cüzdan imzasıyla tüm yürütmeyi kendi başına çalıştırır (`rome_relayUnsignedV1`, bir `rome_composeExternalDepositV1` (SDK’nın `fundSyntheticGas`) sonrasında; bu, sentetiğin gas bakiyesini fonlar; iletilen çağrılar buradan harcar, bu yüzden azaldığında doldurun). Yöntem biçimleri [JSON-RPC Desteği](/tr/referans/json-rpc.md)içindedir; yetkilendirme kuralları [Solana'dan EVM'yi çağırma](/tr/gelistirici-kilavuzlari/call-evm-from-solana.md#the-external-v1-endpoints)içindedir. Yinelemeli olan her şey için iletme yolunu, sığan her şey için SDK hattını kullanın.

Her iki durumda da sözleşme sentetik adresten gelen normal bir işlem görür ve kullanıcı hiçbir zaman bir EVM anahtarı tutmaz.

## 4. Ağa göre sarıcı adresleri

| Ağ               | `wUSDC` sarıcı                               | Diğer sarıcılar                                                                                          |
| ---------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Rubicon (7531)   | `0x0952d233b0c254cd375f3bfb3e5869c1a906f9b3` | `wETH` `0x01e8b3573da1d4b7b4b1ce0932cf07c8af0c92e9`, `wSOL` `0xc4e29e0f726a906e93277cbbc37bf27a9848a113` |
| Hadrian (200010) | `0xbce339ba4c3a8de3bb8af1c5539e6ac11da3112d` | `wETH` `0x02aeace038269f9961c93d04dcacd6fb3adfa55f`, `wSOL` `0x39f36444fcb79b3e691544aee2a832ebef54ca9f` |

Yerel gas token’ı şu şekilde görünür: `0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` token listelerinde; bu bir ERC-20 sözleşmesi değildir. Sarıcılar SPL mint’inin ondalıklarını taşır, 18’i değil: wUSDC 6, wETH 8, wSOL 9.

## 5. Yayın kontrol listesi

1. Hadrian’da dağıtıldı; EVM yolu MetaMask’tan çalışıyor.
2. Değer taşıyan her giriş noktası ERC-20 tabanlıdır ve zincirin kanonik sarıcısına yönlendirilmiştir.
3. V1 işlemlerini imzalayan bir Solana cüzdanı (Solflare bugün devnet’te bunu yapıyor; Phantom henüz yapmıyor) Hadrian’da tam gidiş-dönüşü tamamlar: sentetiği provision et (`create_pda`, bir kez) → fonlama bacağı → grant → approve → çağrı → süpürme bacağı; SDK hattını kullanarak, ya da çağrı yinelemeliyse iletme yolunu kullanarak.
4. Her Solana-hattı çağrısının `computeUnitsConsumed` Solana fişinden okunur ve atomik bütçenin altındadır; aksi halde çağrı iletme üzerinden yönlendirilir.
5. Sarıcı izni her iki hat için de uygulamanızın ilk mevduat akışındadır: `isEnabled(user)` kontrol edilir ve `approve_spl` false olduğunda bir kez gönderilir ([Tek seferlik: sarmalayıcıya yetki verin](/tr/gelistirici-kilavuzlari/dual-lane-app.md#one-time-grant-the-wrapper)).
6. Kaynak, gezginde doğrulandı.
7. Ana ağ sarıcı adresleriyle Rubicon’a yeniden dağıtıldı. Rubicon kayıt defterinde olmadığından `deps` değerleri elle şuradan doldurulur: [Rubicon](/tr/aglar/rubicon.md). Aynı gidiş-dönüş, ana ağda v1 işlemlerini imzaladığını doğruladığınız bir cüzdan kullanılarak gerçek fonlarla bir kez çalıştırılır.

## Sırada ne var

* [Çift hatlı bir uygulama oluşturma](/tr/gelistirici-kilavuzlari/dual-lane-app.md) — kasa örneği, adım adım, her iki cüzdan
* [Solana'dan EVM'yi çağırma](/tr/gelistirici-kilavuzlari/call-evm-from-solana.md) — sentetik adresler, hesap keşfi, dış V1 uç noktaları
* [Solidity Sözleşmelerini Dağıtma](/tr/gelistirici-kilavuzlari/deploy-solidity.md) · [Sözleşmeleri Doğrula](/tr/gelistirici-kilavuzlari/verify-contracts.md) · [Sözleşme Adresleri](/tr/referans/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/tr/gelistirici-kilavuzlari/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.
