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

# 두 레인

하나의 토큰 배포, 두 개의 지갑 세계. 두 경로 모두 다음을 실행합니다 **동일한 계약을** 다음과 **동일한 컴플라이언스 게이트를** — 차이는 누가 서명하느냐와 거래가 체인에 도달하는 방식뿐입니다.

## EVM 경로

표준 Ethereum 도구는 그대로입니다: 지갑이 EVM 트랜잭션에 서명하고, 체인의 JSON-RPC 엔드포인트가 이를 수락하며, 토큰 계약이 허용 목록을 강제합니다. 통합해야 할 Bloom 전용 요소는 없습니다.

Rome 가스는 USDC 기준이며, 쓰기 작업은 Solana 계정을 생성해야 할 때(최초 보유자, 새 토큰 계정)마다 Ethereum의 동등 작업보다 더 비쌉니다. 사용 `eth_estimateGas`, 표준 도구가 하듯이, 그리고 21,000을 절대 하드코딩하지 마십시오. 추정치에는 계정 생성이 포함되며, Rome은 실제로 사용된 가스만 청구합니다. 게이트된 전송은 허용 목록 검사 비용도 지불하므로, 같은 크기의 일반 전송보다 더 비쌉니다.

## 솔라나 경로

Solana 지갑이 동일한 EVM 계약을 구동합니다 **네이티브하게 — 어디에도 EVM 키가 존재하지 않습니다**. 모든 호출은 체인의 프록시가 지갑 서명을 위해 구성하는 Solana v1 트랜잭션입니다. 주소 조회 테이블도 없고, 구성해야 할 compute-budget 지시문도 없습니다. 프록시가 compute 및 heap 예산을 직접 설정합니다.

1. **신원.** 사용자의 EVM 측 주소는 *합성*: 다음과 같이 결정적으로 파생됩니다 `keccak256(solana_pubkey)[12..32]`. Rome EVM 프로그램은 거래의 실제 서명자로부터 이를 온체인에서 파생합니다 — 위조할 수 없고, 이를 위한 secp256k1 개인키도 존재하지 않으므로, **이 주소를 작동시킬 수 있는 것은 오직 솔라나 서명뿐입니다**.
2. **승인.** 앱은 체인에서 읽어온 nonce, gas price와 gas 추정치를 사용해 호출을 서명되지 않은 EIP-1559 페이로드로 구성합니다. 지갑은 읽을 수 있는 메시지에 서명합니다 — 다음과 같이 표시됩니다 *Rome 승인* 그 뒤에 호출의 해시가 따라오며 — 이는 Solana 키가 이 정확한 EVM 페이로드를 승인함을 증명합니다. 이것이 첫 번째 프롬프트이며, 프록시는 이것 없이는 호출을 구성하지 않습니다.
3. **구성.** 앱은 페이로드와 그 서명을 프록시로 보냅니다. 프록시는 서명을 확인하고, 호출을 에뮬레이션하여 어떤 Solana 계정을 건드리는지와 어떤 계정이 쓰기 가능한지 찾아낸 뒤, 하나의 Solana v1 트랜잭션을 반환합니다. 앱은 지갑에 서명을 요청하기 전에 반환된 메시지를 확인합니다.
4. **서명하고 제출.** 지갑이 트랜잭션 자체에 서명합니다: 두 번째 프롬프트이며, 다른 바이트 문자열에 대한 다른 서명입니다. 앱은 서명된 트랜잭션을 곧바로 Solana RPC로 전송하고; 사용자는 자신의 지갑에서 SOL로 Solana 수수료를 지불합니다.
5. **확인.** 트랜잭션은 Solana에서 확정되며; EVM 뷰는 잠시 뒤 따라오므로, 앱은 다음 호출을 보내기 전에 합성 주소의 nonce가 움직일 때까지 기다립니다.

**지갑은 Solana v1 트랜잭션에 서명해야 합니다.** 그렇지 않으면 경로는 닫힌 상태로 실패합니다: v1 트랜잭션에 서명할 수 없는 지갑은 호출을 오류로 중단하며, 앱은 더 오래된 트랜잭션 형식으로 절대 되돌아가지 않습니다. Solflare는 현재 devnet에서 v1에 서명하며; Phantom은 아직 그렇지 않습니다.

### 호출 전: 현금과 일회성 승인

Solana 경로 호출 전에 두 가지가 올 수 있으며, 각 항목은 자체 프롬프트와 함께 별도의 단계로 나타납니다:

* **현금 이동.** wUSDC를 지출하는 호출은 휴지 상태로는 아무것도 보유하지 않는 합성 주소에서 이를 가져옵니다. 합성이 호출에 필요한 양보다 적게 보유하면, 앱은 먼저 부족분을 지갑의 자체 USDC 토큰 계정에서 합성 계정으로 옮깁니다. 이는 하나의 프롬프트로 서명되는 하나의 Solana 트랜잭션이며, EVM 호출이 아닙니다: 합성의 토큰 계정을 멱등적으로 생성한 다음 Rome 프로그램의 activate-token-account 지시문이 EVM을 실행하지 않고 토큰을 이동합니다. 합성이 이미 충분히 보유하고 있으면 건너뜁니다.
* **일회성 래퍼 승인.** wUSDC는 SPL 토큰의 래퍼이며, 래퍼는 사용자의 SPL 대리인으로서 사용자의 토큰을 이동합니다. 지갑의 합성 주소가 처음으로 wUSDC를 사용할 때는 아직 승인이 마련되어 있지 않으므로, 앱은 다음을 둡니다 **wUSDC 전송 허용** 나머지보다 앞선 단계입니다. 이는 다른 호출과 다르지 않은 하나의 호출(두 번의 프롬프트)이며, 지갑당 한 번만 발생합니다. 참조하십시오 [지갑당 1회 권한 부여](/ko/core-concepts/token-interop.md#one-time-grant-per-wallet).

따라서 새 Solana 지갑으로의 매수는 짧은 순서입니다: 현금을 이동하고, wUSDC 전송을 허용하고, 스토어프런트를 승인하고, 매수합니다.

### 하나의 트랜잭션으로는 너무 큰 호출

원자적 Solana 트랜잭션에는 고정된 상한이 있습니다: 약 140만 compute unit, 64개 계정, 그리고 전송 시 4KB입니다(참조 [제약 사항](/ko/core-concepts/constraints.md)). Bloom은 항상 먼저 직접적인 지갑 서명 트랜잭션을 시도합니다. 프록시가 호출을 하나의 트랜잭션에 담을 수 없어 거부할 때만 앱은 이를 프록시에 넘겨 **릴레이**하고, 그 이전에는 절대 그렇지 않습니다:

* **그 호출에 대한 프롬프트 한 번.** 릴레이는 거부된 시도에 대해 지갑이 이미 서명한 승인 메시지를 재사용하므로, 동일한 두 번째 프롬프트도 없고 서명할 트랜잭션도 없습니다. 프록시가 호출을 구성해 Solana에 제출하고(필요한 만큼의 트랜잭션으로) Solana 수수료도 직접 부담합니다.
* **Rome 가스는 합성 계정의 잔액에서 나옵니다.** 릴레이된 호출은 체인의 네이티브 가스 단위인 wei로 합성 주소에서 지불됩니다. 그 잔액이 호출 비용에 부족하면, 앱은 먼저 지갑에서 10^12 wei 단위로 보충합니다: 승인처럼, 보통 지갑당 한 번의 추가 프롬프트입니다.
* **해시는 Rome 트랜잭션 해시입니다.** 릴레이된 호출의 결과는 Solana 서명이 아니라 프록시의 EVM 트랜잭션 해시이므로, Solana 익스플로러에서는 열리지 않습니다. 체인 자체의 익스플로러에서 조회하십시오.

릴레이는 프록시가 하나의 트랜잭션에 너무 크다고 보고하는 모든 호출에 적용되며, Credit에서는 더 큰 시장 작업도 포함될 수 있습니다. 일반 전송과 승인을 포함한 대부분의 호출은 하나의 트랜잭션에 들어가며 이 경로를 절대 사용하지 않습니다. 릴레이된 호출의 메커니즘과 그 한계는 다음에 있습니다 [릴레이된 호출 및 장시간 호출](/ko/developer-guides/call-evm-from-solana.md#relayed-calls-and-long-calls).

### 단계별 프롬프트

| 단계                            | 지갑 프롬프트                         |
| ----------------------------- | ------------------------------- |
| 현금 이동(부족할 때만)                 | 1                               |
| wUSDC 전송 허용(지갑당 한 번)          | 2                               |
| 하나의 트랜잭션에 들어가는 호출(승인, 매수, 전송) | 2: 승인 메시지, 그다음 트랜잭션             |
| 릴레이되어야 하는 호출                  | 1, 그리고 잔액이 부족하면 일회성 가스 보충에 1 추가 |

Invest 자산 페이지에서 Solana 지갑은 Buy를 누른 뒤 한 번의 실행으로 현금 이동, 승인, 허가, 매수를 거치며, 각 단계가 서명되는 동안 버튼에는 "두 번의 지갑 프롬프트"라고 표시됩니다. 이름이 붙은 단계("현금 전송")와 사전 프롬프트 수는 Trade와 Credit에 표시됩니다. EVM 지갑도 일회성 *wUSDC 전송 허용* 구매 패널의 단계를 받습니다.

### 이전 경로에서 측정한 compute

v1 트랜잭션으로 전환하기 전에, 경로는 자체 트랜잭션을 구성했고 Rome devnet에서 이 수치를 측정했습니다. 이는 두 체인에서 관찰된 범위입니다. 지금 프록시가 구성하는 v1 트랜잭션에서는 다시 측정되지 않았으므로, 예산이 아니라 대략적인 규모로 읽으십시오:

| Solana 경로 흐름                                 | CU         |
| -------------------------------------------- | ---------- |
| 게이트된 RWA 전송                                  | \~339–381K |
| wUSDC 승인                                     | \~189–191K |
| 스토어프런트 매수(승인 + 매수, 두 트랜잭션)                   | \~730–796K |
| 현금 구간 스윕을 지갑의 자체 토큰 계정으로                     | \~42–54K   |
| 일반 값 전송                                      | \~47K      |
| `TestApprover.approve` — 허용 목록 승인, **지갑 서명** | 220,794    |

Solana의 트랜잭션당 compute 상한은 140만 CU입니다. Solana 트랜잭션의 다음에서 자신의 호출을 측정하십시오 `meta.computeUnitsConsumed` (`getTransaction` Solana RPC에서; 체인의 EVM 영수증에는 그런 필드가 없으므로) 이들 중 하나라고 가정하지 마십시오.

## 수탁: RWA가 합성 계정에 머무는 이유

권한형 자산이 반드시 답해야 하는 설계 질문: *토큰이 컴플라이언스 경계를 벗어나 유출될 수 있는가?* Solana 경로에서 답은 정책이 아니라 구조에 있습니다:

* **RWA는 EVM 상태에 상주합니다.** 그 잔액은 Rome EVM 프로그램 계정 내부의 저장소입니다. 다음은 없습니다 **SPL 민트가 없습니다** 그것의, 토큰 계정 표현도 없고, 이동할 Solana 네이티브한 것도 없습니다. (이는 의도된 것입니다 — 래핑/미러 버전이 탈출구가 될 것입니다.)
* **Solana 측 플러밍은 그것을 건드릴 수 없습니다.** 경로의 자산 이동 레그(`create_ata`, SPL 전송, 스윕)는 SPL 토큰 계정에서 작동합니다. EVM 저장소 잔액에는 그런 계정이 없습니다. EVM 잔액을 Solana 토큰 계정으로 이동시키는 지시문은 없습니다.
* **오직 소유자의 Solana 서명만이 합성**, 그리고 그것이 표현할 수 있는 모든 이동은 토큰 계약 호출이며 — 그 계약이 허용 목록 게이트를 실행하므로 — 허용 목록에 없는 주소로의 전송은 EVM 키로 서명하든 Solana 키로 서명하든 동일하게 되돌려집니다.
* **현금 구간은 의도적인 예외입니다.** wUSDC(수익, 매각 대금)는 SPL 기반이며 *해야 합니다* 왕복합니다: 출구 구간(`transfer_spl`)은 이를 합성 계정에서 지갑의 자체 연동 토큰 계정으로 이동시키며, 엔드투엔드로 검증됩니다. 자산은 경계 안에 머무르고; 현금은 자유롭게 흐릅니다.

실질적인 결과 두 가지를 분명히 말하면: Solana 지갑 UI에는 RWA 보유분이 표시되지 않고(SPL 토큰으로 목록화할 것이 없기 때문입니다) — Bloom 앱이 포지션 화면입니다; 그리고 분실된 Solana 키는 발행사의 절차를 통해 복구됩니다([COMPLIANCE.md](/ko/rome/bloom/compliance.md#issuer-powers-transfer-agent-shaped)), 자산을 외부 채널로 옮기는 방식이 아닙니다 — 바로 이것이 권한형 자산이 원하는 속성입니다.


---

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