> 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/es/rome-zk-evm/deposits-and-withdrawals.md). # Depósitos y retiros Mueve SOL a una cadena Rome ZK EVM y retira su moneda nativa a una cartera de Solana. En la configuración de devnet v0.3.0, la moneda nativa de la cadena está respaldada por SOL envuelto en su bóveda de Solana. Un depósito bloquea el SOL envuelto y acredita la dirección EVM nombrada. Un retiro quema esa moneda en la cadena y paga SOL envuelto desde la bóveda a un destinatario de Solana. Un gwei en la cadena corresponde a un lamport de SOL envuelto. La [guía completa de retiros](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/WITHDRAWALS.md) tiene la llamada exacta, las comprobaciones y los nombres de rechazo. La [guía de devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) cubre la configuración del depósito y el comando del depositante. ## Depositar SOL El operador primero necesita una raíz demostrada, una bóveda de SOL envuelto, una configuración de salida activa que nombre el puente y una cola de depósitos. Sin esto, una nueva cadena no puede aceptar depósitos. El génesis de la cadena comienza sin saldo, a menos que su operador haya declarado y respaldado un saldo. Un depositante usa `./rollup deposit` con una cantidad en lamports, un destinatario EVM, su propio firmante de Solana y `--wrap-sol`. Esa opción envuelve el SOL en la misma transacción de Solana que el depósito. El comando es una simulación seca hasta que se añade `--confirm` . El mínimo predeterminado es 1.000.000 lamports, o 0,001 SOL. La tarifa predeterminada de la cola es 100.000 lamports, o 0,0001 SOL, pagada a la autoridad de la cadena. El depositante también paga la comisión de transacción y la renta por el registro del depósito. El puente bloquea el SOL envuelto en la bóveda de esa cadena y añade un registro numerado. El secuenciador lee los depósitos de Solana finalizados y los acredita en orden en nuevos bloques EVM. El saldo aparece en el RPC de la cadena cuando su bloque se sella. El crédito es definitivo solo cuando el lote que lo contiene se demuestra y su raíz llega a Solana. El plazo de inclusión predeterminado de la cola es de 12 horas, con un máximo de 256 depósitos por lote y 4 por bloque. La bandeja de entrada comprueba el plazo cuando se finaliza un lote. Esa regla no obliga al operador a producir o demostrar un lote. El operador aún puede retrasar un depósito deteniendo la cadena. La renta del registro del depósito puede volver al depositante después de que la raíz del lote que acredita sea final y la autoridad del lote envíe `CloseBatch`. Entonces cualquiera puede enviar `CloseDeposit`. El depósito permanece en la bóveda como respaldo. El ejecutor v0.3.0 no envía `CloseBatch`, por lo que los registros no se cierran automáticamente y su renta permanece bloqueada. ## Retirar a Solana Los retiros son solo para la moneda nativa de la cadena. Envía una llamada pagadera `initiateExit(bytes32 solRecipient)` al portal de salida en `0x4200000000000000000000000000000000000016`. El valor es la cantidad a retirar. El destinatario es una **dirección de cartera de Solana codificada como 32 bytes**, no la dirección de su cuenta de token. Verifica esa dirección antes de enviar. Las monedas se queman en cuanto la transacción llega, y nada en el portal puede devolverlas. Conserva el hash del mensaje del evento `ExitInitiated` . Espera una raíz demostrada que cubra esa transacción. El probador de salidas usa el nodo verificador para hacer una prueba de almacenamiento del mensaje del portal contra esa raíz final. El asentamiento de Solana comprueba la prueba, la configuración activa de salida, el portal y el límite de retiro. Luego, el probador de salidas envía una liberación. El puente toma la cantidad de la bóveda de la cadena y paga la cuenta de token asociada de SOL envuelto del destinatario. Puede crear esa cuenta de token cuando sea necesario. El pago sigue a la prueba sin un periodo de espera aparte. La transacción de liberación lee al destinatario del registro demostrado, por lo que el operador o cualquier otro remitente no puede redirigirlo. El programa consume el registro y paga de forma atómica, evitando un segundo pago para el mismo retiro. La mayor parte de la espera es el tiempo para cerrar, publicar y demostrar el lote. El probador de salidas consulta cada dos segundos y paga poco después de que haya una raíz final disponible. En la ejecución de devnet de Roma, un retiro iniciado en el bloque 192 se pagó en Solana unos cuatro minutos después. Esta es una medición, no un tiempo de retiro fijo. Un tope de salidas limita cuánto puede salir en cada ventana de desafío de 172.800 slots. Una salida que no encaja en la ventana actual espera a la siguiente. Una sola salida mayor que todo el tope necesita que la autoridad de la cadena aumente el tope. Los cambios en la configuración de salida tardan al menos una ventana de desafío en activarse. Un pago aún puede esperar después de la prueba si al destinatario le falta una cuenta de token de SOL envuelto y la cantidad está por debajo del umbral predeterminado de 0,01 SOL. El probador de salidas lo deja para una liberación manual en lugar de pagar para crear esa cuenta. El usuario o el operador puede usar `./rollup release-exit --message-hash` con el hash del mensaje y `--confirm`. Cualquiera puede liberar una salida válida. ## Lo que ejecuta el operador Cree y financie la bóveda de SOL envuelto después del registro. Para un saldo de génesis respaldado, bloquee esa misma cantidad antes de solicitar la clave de verificación. Después de la primera raíz demostrada, establezca un portal de salida, un puente y un límite con `./rollup exit-config propose`. Espere al menos una ventana de desafío y luego ejecute `./rollup exit-config activate --confirm`. La autoridad de la cadena abre la cola de depósitos con `./rollup deposit-queue init --confirm`. Establezca `EXITS=on`, luego ejecute `./rollup init` y `./rollup up` para iniciar el probador de salidas. Necesita su **propio pagador financiado**, separado del pagador del batcher. Cada prueba de salida le cuesta a su pagador una comisión de Solana y renta de registro. El ejecutor rechaza un pagador de salida ausente o compartido. El pago automático está activado de forma predeterminada; el probador de salidas también reintenta los registros demostrados que quedaron abiertos después de un reinicio. Ejecute `./rollup check`. Comprueba el respaldo de la bóveda, los límites de depósito y el retraso, el puente activo y la configuración de salida, el probador de salidas, las salidas atascadas, su análisis de registros y el saldo de su pagador. El mínimo predeterminado del pagador de salidas es 0,1 SOL. Use `./rollup vault show` y `./rollup deposit-queue show` para inspeccionar los fondos y el estado de la cola. Las guías completas anteriores dan los comandos para financiar una bóveda y cambiar la configuración de la cola. --- # 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/es/rome-zk-evm/deposits-and-withdrawals.md?ask=&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.