> 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-zk-evm/deposits-and-withdrawals.md).

# 예치와 출금

SOL을 Rome ZK EVM 체인으로 옮기고 그 네이티브 코인을 Solana 지갑으로 출금하세요.

v0.3.0 devnet 설정에서 체인의 네이티브 코인은 Solana 금고의 래핑된 SOL로 담보됩니다. 예치는 래핑된 SOL을 잠그고 지정된 EVM 주소에 크레딧을 부여합니다. 출금은 체인에서 그 코인을 소각하고 금고의 래핑된 SOL을 Solana 수신자에게 지급합니다. 체인의 1 gwei는 래핑된 SOL 1 lamport에 해당합니다.

그 [전체 출금 가이드](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/WITHDRAWALS.md) 에는 정확한 호출, 검사 및 거부 이름이 포함되어 있습니다. 그 [devnet 가이드](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) 예치 설정과 예치자 명령을 다룹니다.

## SOL 예치

운영자는 먼저 증명된 루트, 래핑된 SOL 금고, 브리지를 지정한 활성 출구 구성, 그리고 예치 큐가 필요합니다. 이것들이 없으면 새 체인은 예치를 받을 수 없습니다. 체인의 제네시스는 운영자가 하나의 잔액을 선언하고 담보하지 않는 한 잔액 없이 시작합니다.

예치자는 `./rollup deposit` 람포트 단위 금액, EVM 수신자, 자신의 Solana 서명자와 함께 `--wrap-sol`을 사용합니다. 이 옵션은 예치와 같은 Solana 트랜잭션에서 SOL을 래핑합니다. 이 명령은 다음이 추가되기 전까지는 드라이 런입니다 `--confirm` 이 추가됩니다. 기본 최소값은 1,000,000 람포트, 즉 0.001 SOL입니다. 기본 큐 수수료는 100,000 람포트, 즉 0.0001 SOL이며 체인 권한자에게 지급됩니다. 예치자는 트랜잭션 수수료와 예치 기록의 렌트도 지불합니다.

브리지는 해당 체인의 금고에 래핑된 SOL을 잠그고 번호가 매겨진 기록을 추가합니다. 시퀀서는 최종 확정된 Solana 예치를 읽어 새 EVM 블록들에 순서대로 크레딧을 부여합니다. 잔액은 해당 블록이 봉인되면 체인 RPC에 나타납니다. 이 크레딧은 그것을 포함한 배치가 증명되고 그 루트가 Solana에 올라가야만 최종 확정됩니다.

기본 큐 포함 마감은 12시간이며, 배치당 최대 256건, 블록당 4건의 예치가 가능합니다. 인박스는 배치가 최종 확정될 때 마감 시한을 확인합니다. 이 규칙은 운영자에게 배치를 생성하거나 증명하도록 강제하지 않습니다. 운영자는 여전히 체인을 멈춰 예치를 지연시킬 수 있습니다.

예치 기록의 렌트는 크레딧을 반영한 배치의 루트가 최종 확정되고 배치 권한자가 다음을 보낸 뒤 예치자에게 반환될 수 있습니다 `CloseBatch`. 그러면 누구나 다음을 보낼 수 있습니다 `CloseDeposit`. 예치는 담보로 금고에 남아 있습니다. v0.3.0 러너는 다음을 보내지 않습니다 `CloseBatch`따라서 기록은 자동으로 닫히지 않고 그 렌트는 잠긴 상태로 남습니다.

## Solana로 출금

출금은 체인의 네이티브 코인에만 적용됩니다. 지불 가능한 다음을 전송하세요 `initiateExit(bytes32 solRecipient)` 를 다음 위치의 출구 포털에 호출하세요 `0x4200000000000000000000000000000000000016`. value는 출금할 금액입니다. 수신자는 **32바이트로 인코딩된 Solana 지갑 주소**이며, 토큰 계정 주소가 아닙니다. 전송하기 전에 해당 주소를 확인하세요. 트랜잭션이 도착하는 즉시 코인은 소각되며, 포털의 어떤 것도 이를 되돌릴 수 없습니다. 다음에서 메시지 해시를 보관하세요 `ExitInitiated` 이벤트입니다.

해당 트랜잭션을 포함하는 증명된 루트를 기다리세요. 출구 증명기는 검증자 노드를 사용해 그 최종 루트에 대해 포털 메시지의 스토리지 증명을 만듭니다. Solana 정산은 증명, 활성 출구 구성, 포털 및 출금 한도를 확인합니다. 그런 다음 출구 증명기가 릴리스를 보냅니다. 브리지는 체인의 금고에서 금액을 가져와 수신자의 래핑된 SOL 연관 토큰 계정에 지급합니다. 필요할 때는 해당 토큰 계정을 생성할 수 있습니다.

지급은 별도의 대기 기간 없이 증명을 따릅니다. 릴리스 트랜잭션은 증명된 기록에서 수신자를 읽으므로 운영자나 다른 전송자가 이를 다른 곳으로 돌릴 수 없습니다. 프로그램은 기록을 소비하고 원자적으로 지급하여 동일한 출금에 대해 두 번째 지급이 발생하지 않게 합니다.

대기 시간의 대부분은 배치를 닫고 게시하고 증명하는 데 걸리는 시간입니다. 출구 증명기는 2초마다 폴링하며 최종 루트가 उपलब्ध해지면 곧 지급합니다. Rome의 devnet 실행에서는 블록 192에서 시작된 출금이 약 4분 후 Solana에서 지급되었습니다. 이는 하나의 측정값일 뿐, 고정된 출금 시간이 아닙니다.

출구 한도는 각 172,800-슬롯 챌린지 윈도우에서 나갈 수 있는 양을 제한합니다. 현재 윈도우에 맞지 않는 출구는 다음 윈도우를 기다립니다. 전체 한도보다 큰 단일 출구는 체인 권한자가 한도를 올려야 합니다. 출구 구성 변경은 활성화되는 데 최소 하나의 챌린지 윈도우가 필요합니다.

수신자에게 래핑된 SOL 토큰 계정이 없고 금액이 기본 0.01 SOL 임계값보다 낮다면, 지급은 증명 후에도 계속 기다릴 수 있습니다. 출구 증명기는 해당 계정을 만드는 비용을 지불하기보다 수동 릴리스를 위해 남겨 둡니다. 사용자나 운영자는 다음을 사용할 수 있습니다 `./rollup release-exit --message-hash` 를 메시지 해시와 함께 `--confirm`사용합니다. 누구나 유효한 출구를 릴리스할 수 있습니다.

## 운영자가 실행하는 것

등록 후 래핑된 SOL 금고를 생성하고 자금을 넣으세요. 담보된 제네시스 잔액의 경우, 검증 키를 요청하기 전에 동일한 금액을 잠그세요. 첫 번째 증명된 루트 이후에는 다음으로 출구 포털, 브리지 및 한도를 설정하세요 `./rollup exit-config propose`. 최소 하나의 챌린지 윈도우를 기다린 다음 다음을 실행하세요 `./rollup exit-config activate --confirm`. 체인 권한자는 다음으로 예치 큐를 엽니다 `./rollup deposit-queue init --confirm`.

설정하세요 `EXITS=on`, 그런 다음 다음을 실행하세요 `./rollup init` 및 `./rollup up` 를 실행해 출구 증명기를 시작합니다. 이것은 다음이 필요합니다 **자체 자금이 충전된 payer**, 배처의 payer와는 별개입니다. 각 출구 증명은 해당 payer에게 Solana 수수료와 기록 렌트를 발생시킵니다. 러너는 누락되었거나 공유된 출구 payer를 거부합니다. 자동 지급은 기본적으로 켜져 있으며, 출구 증명기는 재시작 후 열려 남은 증명된 기록도 다시 시도합니다.

실행하세요 `./rollup check`. 금고 담보, 예치 한도와 적체, 활성 브리지 및 출구 구성, 출구 증명기, 멈춘 출구, 로그 스캔 및 payer 잔액을 확인합니다. 기본 출구 payer 최소값은 0.1 SOL입니다. 다음을 사용하세요 `./rollup vault show` 및 `./rollup deposit-queue show` 자금과 큐 상태를 확인합니다. 위의 전체 가이드에는 금고에 자금을 넣고 큐 설정을 변경하는 명령이 나와 있습니다.


---

# 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-zk-evm/deposits-and-withdrawals.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.