> 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/rome-uzerindeki-uygulamalar/bloom/lanes.md).

# İki şerit

Tek bir token dağıtımı, iki cüzdan dünyası. Her iki şerit de şu işlemi yürütür **aynı sözleşmeleri** ile **aynı uyumluluk kapısından** — yalnızca kimin imzaladığı ve işlemin zincire nasıl ulaştığı bakımından farklıdırlar.

## EVM şeridi

Standart Ethereum araçları, değişmeden: cüzdan bir EVM işlemini imzalar, zincirin JSON-RPC uç noktası bunu kabul eder, token sözleşmesi izin listesini uygular. Entegre edilecek Bloom'a özgü bir şey yok.

Rome gazı USDC cinsinden belirlenir ve bir yazma işlemi, Solana hesapları oluşturması gerektiğinde (ilk kez tutan biri, yeni bir token hesabı) Ethereum eşdeğerinden daha pahalıya mal olur. Kullanın `eth_estimateGas`, standart araçların yaptığı gibi, ve asla 21.000'i sabitlemeyin; tahmin hesap oluşturmayı içerir ve Rome yalnızca gerçekten kullanılan gazı ücretlendirir. Korumalı bir transfer de izin listesi kontrolü için ödeme yapar, bu yüzden aynı boyuttaki düz bir transferden daha pahalıdır.

## Solana hattı

Bir Solana cüzdanı aynı EVM sözleşmelerini çalıştırır **yerel olarak — hiçbir yerde EVM anahtarı yoktur**. Her çağrı, zincirin proxy'sinin cüzdanın imzalaması için oluşturduğu bir Solana v1 işlemidir. Oluşturulacak adres arama tabloları ve compute-budget talimatları yoktur: proxy, compute ve heap bütçesini kendisi belirler.

1. **Kimlik.** Kullanıcının EVM tarafındaki adresi *sintetik*: deterministik olarak şu şekilde türetilir `keccak256(solana_pubkey)[12..32]`. Rome EVM programı bunu işlemin gerçek imzalayıcısından zincir üzerinde türetir — taklit edilemez ve bunun için hiçbir secp256k1 özel anahtarı mevcut değildir, dolayısıyla **bu adresi yalnızca Solana imzası yönlendirebilir**.
2. **Yetkilendir.** Uygulama, zincirden okuduğu nonce, gaz fiyatı ve gaz tahminini kullanarak çağrıyı imzasız bir EIP-1559 yükü olarak oluşturur. Cüzdan okunabilir bir mesajı imzalar — bu şu şekilde görünür *Rome yetkilendirmesi* ardından çağrının bir karması gelir — bu da Solana anahtarının tam olarak bu EVM yükünü yetkilendirdiğini kanıtlar. Bu ilk istemdir ve proxy bunu olmadan çağrıyı oluşturmaz.
3. **Oluştur.** Uygulama yükü ve bu imzayı proxy'ye gönderir. Proxy imzayı doğrular, çağrıyı hangi Solana hesaplarına dokunduğunu ve hangilerinin yazılabilir olduğunu bulmak için simüle eder ve tek bir Solana v1 işlemi döndürür. Uygulama, cüzdandan imzalamasını istemeden önce döndürülen mesajı kontrol eder.
4. **İmzala ve gönder.** Cüzdan işlemin kendisini imzalar: ikinci istem, farklı bir bayt dizisi üzerinde farklı bir imza. Uygulama imzalı işlemi doğrudan bir Solana RPC'ye gönderir; kullanıcı Solana ücretini kendi cüzdanından SOL ile öder.
5. **Onayla.** İşlem Solana'da onaylanır; EVM görünümü biraz sonra yetişir, bu yüzden uygulama bir sonraki çağrıyı göndermeden önce sentetik adresin nonce'unun değişmesini bekler.

**Cüzdanın Solana v1 işlemlerini imzalaması gerekir.** Bunun yokluğunda şerit kapalı şekilde başarısız olur: bir v1 işlemi imzalayamayan cüzdan çağrıyı bir hatayla durdurur ve uygulama asla daha eski bir işlem biçimine geri dönmez. Solflare bugün devnet'te v1 imzalıyor; Phantom henüz imzalamıyor.

### Çağrıdan önce: nakit ve tek seferlik izin

Bir Solana şeridi çağrısından önce iki şey olabilir ve her biri kendi istemleriyle ayrı bir adım olarak görünür:

* **Nakit içeri taşınır.** wUSDC harcayan bir çağrı, dinlenimde hiçbir şey tutmayan sentetik adresten onu çeker. Sentetik, çağrının gerektirdiğinden daha az tutuyorsa, uygulama önce eksik miktarı cüzdanın kendi USDC token hesabından sentetik olana taşır. Bu, tek bir istemle imzalanan tek bir Solana işlemidir, bir EVM çağrısı değil: sentetik token hesabının idempotent oluşturulması, ardından EVM'i çalıştırmadan tokenları taşıyan Rome programının activate-token-account talimatı. Sentetik zaten yeterli miktarı tutuyorsa bu adım atlanır.
* **Tek seferlik sarıcı izni.** wUSDC, bir SPL tokenının sarıcısıdır ve bir sarıcı, kullanıcının tokenlarını o kullanıcının SPL delegesi olarak taşır. Bir cüzdanın sentetik adresi ilk kez wUSDC harcadığında, izin henüz verilmemiştir ve uygulama bir **wUSDC transferlerine izin ver** adımı diğerlerinin önüne koyar. Bu, diğerleri gibi tek bir çağrıdır (iki istem), cüzdan başına bir kez. Bkz. [Cüzdan başına tek seferlik izin](/tr/temel-kavramlar/token-interop.md#one-time-grant-per-wallet).

Bu nedenle yeni bir Solana cüzdanından yapılan bir satın alma kısa bir dizidir: nakdi içeri taşı, wUSDC transferlerine izin ver, mağaza vitrinini onayla, satın al.

### Tek bir işlem için fazla büyük çağrılar

Atomik bir Solana işleminin sabit üst sınırları vardır: yaklaşık 1,4M compute birimi, 64 hesap ve 4 KB hatta (bkz. [Kısıtlamalar](/tr/temel-kavramlar/constraints.md)). Bloom her zaman önce doğrudan, cüzdan tarafından imzalanmış işlemi dener. Yalnızca proxy çağrıyı tek bir işleme sığmadığı için reddettiğinde uygulama onu proxy'ye **iletmek**, ve bundan önce asla:

* **O çağrı için tek bir istem.** İletim, cüzdanın reddedilen deneme için zaten imzaladığı yetkilendirme mesajını yeniden kullanır, bu yüzden ikinci, aynı istem ve imzalanacak bir işlem yoktur. Proxy çağrıyı oluşturur, onu Solana'ya gönderir (gerektiği kadar işlemde) ve Solana ücretlerini kendisi öder.
* **Rome gazı sentetiğin bakiyesinden gelir.** İletilmiş bir çağrı, zincirin yerel gazıyla, wei cinsinden, sentetik adresten ödenir. Eğer bu bakiye çağrının maliyetini karşılamıyorsa, uygulama önce bunu cüzdandan 10^12 wei'lik tam birimler halinde tamamlar: izin gibi, normalde cüzdan başına bir kez olan bir istem daha.
* **Karma, bir Rome işlem karmasıdır.** İletilmiş bir çağrının sonucu, Solana imzası değil, proxy'nin EVM işlem karmasıdır; bu nedenle bir Solana gezgininde açılmaz; zincirin kendi gezgininde arayın.

İletim, proxy'nin tek bir işleme sığamayacak kadar büyük olarak bildirdiği her çağrı için geçerlidir; Credit'te bu daha büyük piyasa eylemlerini de içerebilir. Düz bir transfer ve bir onay da dahil olmak üzere çoğu çağrı tek bir işleme sığar ve hiçbir zaman bu yolu kullanmaz. İletilmiş çağrıların mekaniği ve sınırları şurada yer alır [Yönlendirilen çağrılar ve uzun çağrılar](/tr/gelistirici-kilavuzlari/call-evm-from-solana.md#relayed-calls-and-long-calls).

### Adım başına istemler

| Adım                                                           | Cüzdan istemleri                                               |
| -------------------------------------------------------------- | -------------------------------------------------------------- |
| Nakit içeri taşı (yalnızca eksikse)                            | 1                                                              |
| wUSDC transferlerine izin ver (cüzdan başına bir kez)          | 2                                                              |
| Tek bir işleme sığan bir çağrı (onayla, satın al, transfer et) | 2: yetkilendirme mesajı, ardından işlem                        |
| İletilmesi gereken bir çağrı                                   | 1, eğer bakiye yetersizse tek seferlik gaz tamamlaması için +1 |

Yatırım varlık sayfasında, bir Solana cüzdanı Satın Al'a bastıktan sonra tek bir akışta nakit yatırma, izin, onay ve satın alma adımlarından geçer ve her adım imzalanırken düğmede "iki cüzdan istemi" notu görünür. Adlandırılmış adımlar ("Nakitinizi aktarma") ve önceden istem sayıları Trade ve Credit'te gösterilir. Bir EVM cüzdanı da tek seferlik bir *wUSDC transferlerine izin ver* satın alma panelinde bir adım.

### Önceki şeritten ölçülen compute

v1 işlemlerine geçişten önce, şerit kendi işlemini oluşturdu ve bu rakamları Rome devnet üzerinde, iki zincir boyunca gözlenen aralıklarda ölçtü. Proxy'nin şimdi oluşturduğu v1 işlem üzerinde yeniden ölçülmediler, bu yüzden bunları bir bütçe değil, bir büyüklük mertebesi olarak okuyun:

| Solana şeridi akışı                                                             | CU         |
| ------------------------------------------------------------------------------- | ---------- |
| Korumalı RWA transferi                                                          | \~339–381K |
| wUSDC onayı                                                                     | \~189–191K |
| Vitrin satın alma (onay + satın alma, iki işlem)                                | \~730–796K |
| Nakit ayağını cüzdanın kendi token hesabına toplama                             | \~42–54K   |
| Düz değer transferi                                                             | \~47K      |
| `TestApprover.approve` — izin listesine kabul, **cüzdan tarafından imzalanmış** | 220,794    |

Solana'nın işlem başına compute üst sınırı 1,4M CU'dur. Kendi çağrınızı Solana işleminin `meta.computeUnitsConsumed` (`getTransaction` üzerinden bir Solana RPC'de ölçün; zincirin EVM makbuzunda böyle bir alan yoktur) bunlardan birini varsaymak yerine.

## Emanet: RWA neden sentetikte kalır

Her izinli varlığın cevaplaması gereken tasarım sorusu: *token uyumluluk sınırının dışına sızabilir mi?* Solana şeridinde yanıt yapısaldır, politikaya değil, yapısaldır:

* **RWA, EVM durumunda ikamet eder.** Bakiyeleri, Rome EVM programının hesapları içindeki depolamadır. Burada **hiçbir SPL basımı** ona ait bir token hesabı temsili yoktur, taşınacak Solana-yerel hiçbir şey yoktur. (Bu kasıtlıdır — sarılmış/ayna bir sürüm kaçış yolu olurdu.)
* **Solana tarafındaki altyapı buna dokunamaz.** Şeridin varlık taşıyan ayakları (`create_ata`, SPL transferleri, toplama işlemleri) SPL token hesapları üzerinde çalışır; EVM depolama bakiyelerinin böyle bir hesabı yoktur. Bir EVM bakiyesini Solana token hesabına taşıyan hiçbir talimat yoktur.
* **Sentetiği yalnızca sahibinin Solana imzası yönlendirir**ve ifade edebildiği her hareket token sözleşmesine bir çağrıdır — bu da izin listesi kapısını çalıştırır — bu yüzden beyaz listede olmayan bir adrese yapılan transfer, EVM anahtarıyla ya da Solana anahtarıyla imzalanmış olmasına bakılmaksızın aynı şekilde geri döner.
* **Nakit ayağı kasıtlı istisnadır.** wUSDC (getiri, satış gelirleri) SPL desteklidir ve *olmalıdır* gidiş-dönüş yapmalıdır: çıkış ayağı (`transfer_spl`) onu sentetikten cüzdanın kendi ilişkili token hesabına taşır; uçtan uca doğrulanır. Varlık sınır içinde kalır; nakit serbestçe akar.

Açıkça söylenen iki pratik sonuç: bir Solana cüzdan arayüzü RWA tutarını göstermez (listeleyecek bir SPL token yoktur) — pozisyonlar yüzeyi Bloom uygulamasıdır; ve kaybolan bir Solana anahtarı, ihraççının süreciyle ([COMPLIANCE.md](/tr/rome-uzerindeki-uygulamalar/bloom/compliance.md#issuer-powers-transfer-agent-shaped)), varlığı bant dışına taşıyarak değil — ki izinli bir varlığın tam da istediği özellik budur.


---

# 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/rome-uzerindeki-uygulamalar/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.