> 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/id/aplikasi-di-rome/bloom/lanes.md).

# Dua jalur

Satu deployment token, dua dunia dompet. Kedua jalur mengeksekusi **kontrak yang sama** dengan **gerbang kepatuhan yang sama** — keduanya berbeda hanya pada siapa yang menandatangani dan bagaimana transaksi mencapai chain.

## Jalur EVM

Tooling Ethereum standar, tanpa perubahan: dompet menandatangani transaksi EVM, endpoint JSON-RPC chain menerimanya, kontrak token menegakkan allowlist. Tidak ada yang spesifik Bloom untuk diintegrasikan — biaya terukur untuk transfer yang dibatasi adalah \~3,1M gas (gas Rome didenominasi USDC; transfer native biasa \~1,48M sebagai pembanding).

## Jalur Solana

Dompet Solana menggerakkan kontrak EVM yang sama **secara native — tidak ada kunci EVM di mana pun**:

1. **Identitas.** Alamat sisi EVM milik pengguna adalah *sintetis*: diturunkan secara deterministik sebagai `keccak256(solana_pubkey)[12..32]`. Program Rome EVM menurunkannya on-chain dari penandatangan aktual transaksi — tidak dapat dipalsukan, dan tidak ada private key secp256k1 untuknya, jadi **tanda tangan Solana adalah satu-satunya hal yang pernah dapat menggerakkan alamat ini**.
2. **Penemuan.** Klien meminta RPC chain (`rome_emulateCallAccounts`) akun Solana mana yang akan disentuh oleh panggilan EVM; emulasi juga menentukan mana yang dapat ditulis (nilai `nilai` harus disertakan — writable pada akun saldo penerima bergantung padanya).
3. **Pengiriman.** Klien membuat `DoTxUnsigned` instruksi — sebuah *tidak ditandatangani* payload EIP-1559 yang diotorisasi oleh tanda tangan Solana — plus instruksi compute-budget (heap 250KB, 1,35M CU) dan yang tidak disertakan oleh penemuan akun fee-pool. Dompet menandatangani satu transaksi Solana; selesai.

   **Ukuran, diukur pada deployment ini 2026-07-30:** pembelian storefront menghasilkan **22 akun** dan terserialisasi menjadi **1.061 byte** terhadap batas legacy 1232-byte — ruang tersisa 171 byte, sekitar lima akun lagi. Jadi saat ini TIDAK memerlukan lookup table. Sebuah state yang menyentuh lebih banyak — associated token account yang masih perlu dibuat, holder pertama kali — masih bisa melampauinya, dan setelah 1232 byte klien kembali ke transaksi v0 melalui address lookup table yang DIBUATnya untuk tujuan itu.

   **Fallback itu mahal bagi dompet:** setiap chunk ALT-extend dan pengiriman ulang v0 adalah `signTransaction`, jadi satu Buy menjadi tiga atau empat prompt. Hadrian sudah memiliki tabel dApp persisten yang menyimpan akun-akun kontrak ini — mereferensikannya sebagai gantinya adalah perbaikan, yang belum bisa dilakukan klien jalur ini.
4. **Konfirmasi.** Transaksi terkonfirmasi di Solana; tampilan EVM menyusul sedikit kemudian (tooling melakukan polling nonce sebelum mengirim panggilan berikutnya).

### HANYA ATOMIK — batas keras jalur ini

`DoTxUnsigned` adalah **satu transaksi EVM yang dieksekusi di dalam satu transaksi Solana** oleh VM atomik Rome. VM iteratif — yang menjalankan satu eksekusi EVM melalui beberapa transaksi Solana — belum dapat dijangkau melalui jalur ini, jadi **panggilan yang tidak muat secara atomik sama sekali tidak dapat memakai jalur ini.** Tidak ada fallback yang bisa dipakai dan tidak boleh ditambahkan; perbaikan untuk panggilan yang tidak muat adalah panggilan yang lebih kecil.

Dua hal sering disalahartikan sebagai itu, padahal bukan:

* **Fallback v0 + lookup-table** adalah envelope *yang lebih besar*, bukan eksekusi yang berbeda: instruksi tunggal yang sama, dibawa dalam format transaksi dengan ruang untuk jauh lebih banyak kunci akun. Diukur hari ini pembelian storefront tidak membutuhkannya (1.061 byte dari 1232), dan panggilan yang membutuhkannya pun tetap atomik.
* **Perjalanan multi-langkah bukan eksekusi multi-leg.** Bloom `Run` menyebut langkah-langkahnya *leg* — approve, lalu buy — dan masing-masing adalah **satu transaksi utuh, ditandatangani terpisah, atomik pada dirinya sendiri**. Rome juga menyebut potongan-potongan dari SATU eksekusi yang dibagi sebagai leg. Aplikasi ini memiliki yang pertama dan tidak pernah boleh meminta yang kedua. Kata itu bentrok; mekanismenya tidak.

Setiap alur dalam tabel di bawah ini adalah satu transaksi atomik, dan yang paling berat hanya menggunakan sedikit di atas setengah dari batas komputasi per transaksi — jadi batasnya tidak dekat untuk apa pun yang dilakukan Bloom hari ini.

Diukur di devnet Rome, satu tanda tangan masing-masing — rentang yang diamati di dua chain:

| Alur jalur Solana                                                             | CU         |
| ----------------------------------------------------------------------------- | ---------- |
| Transfer RWA yang dibatasi                                                    | \~339–381K |
| wUSDC approve                                                                 | \~189–191K |
| Pembelian storefront (approve + buy = total 2 tanda tangan)                   | \~730–796K |
| Penyapuan leg kas ke akun token milik dompet sendiri                          | \~42–54K   |
| Transfer nilai biasa                                                          | \~47K      |
| `TestApprover.approve` — penerimaan allowlist, **ditandatangani oleh dompet** | 220,794    |

Sebagai perbandingan, batas komputasi per transaksi Solana adalah 1,4M CU — alur Bloom yang paling berat hanya menggunakan sedikit di atas setengahnya.

## Penahanan: mengapa RWA tetap di sintetis

Pertanyaan desain yang harus dijawab setiap aset berizin: *apakah token bisa bocor keluar dari perimeter kepatuhan?* Pada jalur Solana jawabannya bersifat struktural, bukan kebijakan:

* **RWA berada di state EVM.** Saldonya adalah penyimpanan di dalam akun program Rome EVM. Tidak ada **mint SPL** untuknya, tidak ada representasi akun token, tidak ada yang native Solana untuk dipindahkan. (Ini disengaja — versi yang dibungkus/dicerminkan akan menjadi celah pelarian.)
* **Infrastruktur di sisi Solana tidak bisa menyentuhnya.** Leg pemindahan aset jalur ini (`create_ata`, transfer SPL, sweep) beroperasi pada akun token SPL; saldo storage EVM tidak punya akun semacam itu. Tidak ada instruksi yang memindahkan saldo EVM ke akun token Solana.
* **Hanya tanda tangan Solana milik pemilik yang menggerakkan sintetis**, dan setiap perpindahan yang dapat diekspresikannya adalah panggilan ke kontrak token — yang menjalankan gerbang allowlist — jadi transfer ke alamat yang tidak ada di whitelist akan revert dengan cara yang sama baik ditandatangani oleh kunci EVM maupun kunci Solana.
* **Leg kas adalah pengecualian yang disengaja.** wUSDC (imbal hasil, hasil penjualan) didukung SPL dan *seharusnya* bolak-balik: leg keluar (`transfer_spl`) memindahkannya dari sintetis ke associated token account milik dompet sendiri, diverifikasi end-to-end. Aset tetap di dalam perimeter; kas mengalir bebas.

Dua konsekuensi praktis, dinyatakan dengan jelas: UI dompet Solana tidak akan menampilkan kepemilikan RWA (tidak ada token SPL untuk dicantumkan) — aplikasi Bloom adalah permukaan posisi; dan kunci Solana yang hilang dipulihkan melalui proses penerbit ([COMPLIANCE.md](/id/aplikasi-di-rome/bloom/compliance.md#issuer-powers-transfer-agent-shaped)), bukan dengan memindahkan aset di luar jalur — yang persis merupakan sifat yang diinginkan aset berizin.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/id/aplikasi-di-rome/bloom/lanes.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.