> 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/de/rome-zk-evm/deposits-and-withdrawals.md). # Ein- und Auszahlungen Verschiebe SOL in eine Rome-ZK-EVM-Chain und hebe ihre native Coin in eine Solana-Wallet ab. Im v0.3.0-Devnet-Setup ist die native Münze der Chain durch Wrapped SOL in ihrem Solana-Tresor gedeckt. Eine Einzahlung sperrt Wrapped SOL und schreibt der genannten EVM-Adresse gut. Eine Auszahlung verbrennt diese Münze auf der Chain und zahlt Wrapped SOL aus dem Tresor an einen Solana-Empfänger aus. Ein Gwei auf der Chain entspricht einem Lamport Wrapped SOL. Der [vollständige Auszahlungsanleitung](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/WITHDRAWALS.md) enthält den exakten Aufruf, die Prüfungen und die Ablehnungsnamen. Der [Devnet-Anleitung](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) deckt die Einrichtung der Einzahlung und den Einzahlungsbefehl ab. ## SOL einzahlen Der Betreiber benötigt zunächst einen bewiesenen Root, einen Wrapped-SOL-Tresor, eine aktive Exit-Konfiguration, die die Bridge benennt, und eine Einzahlungswarteschlange. Ohne diese kann eine neue Chain keine Einzahlungen annehmen. Der Genesis-Block der Chain startet ohne Guthaben, sofern der Betreiber nicht ein Guthaben deklariert und hinterlegt hat. Ein Einzahler verwendet `./rollup deposit` mit einem Betrag in Lamports, einem EVM-Empfänger, einem eigenen Solana-Signer und `--wrap-sol`. Diese Option verpackt das SOL in derselben Solana-Transaktion wie die Einzahlung. Der Befehl ist ein Trockenlauf, bis `--confirm` hinzugefügt wird. Das Standardminimum beträgt 1.000.000 Lamports bzw. 0,001 SOL. Die Standard-Warteschlangengebühr beträgt 100.000 Lamports bzw. 0,0001 SOL und wird an die Chain-Authority gezahlt. Der Einzahler zahlt außerdem die Transaktionsgebühr und die Miete für den Einzahlungsdatensatz. Die Bridge sperrt das Wrapped SOL im Tresor dieser Chain und hängt einen nummerierten Datensatz an. Der Sequencer liest finalisierte Solana-Einzahlungen aus und schreibt sie in neuen EVM-Blöcken der Reihe nach gut. Der Saldo erscheint bei der Chain-RPC, wenn ihr Block versiegelt wird. Die Gutschrift ist erst endgültig, wenn der Batch, der sie enthält, bewiesen ist und sein Root auf Solana landet. Die standardmäßige Frist für die Aufnahme in die Warteschlange beträgt 12 Stunden, mit höchstens 256 Einzahlungen pro Batch und 4 pro Block. Der Inbox prüft die Frist, wenn ein Batch finalisiert wird. Diese Regel zwingt den Betreiber nicht, einen Batch zu erzeugen oder zu beweisen. Der Betreiber kann eine Einzahlung dennoch verzögern, indem er die Chain stoppt. Die Miete des Einzahlungsdatensatzes kann an den Einzahler zurückkehren, nachdem der Root des gutschreibenden Batches final ist und die Batch-Authority sendet `CloseBatch`. Dann kann jeder `CloseDeposit`. Die Einzahlung verbleibt als Deckung im Tresor. Der v0.3.0-Runner sendet nicht `CloseBatch`, sodass Datensätze nicht automatisch geschlossen werden und ihre Miete gesperrt bleibt. ## Nach Solana auszahlen Auszahlungen gelten nur für die native Münze der Chain. Sende einen zahlbaren `initiateExit(bytes32 solRecipient)` Aufruf an das Exit-Portal unter `0x4200000000000000000000000000000000000016`. Der Wert ist der auszuzahlende Betrag. Der Empfänger ist eine **als 32 Bytes codierte Solana-Wallet-Adresse**, nicht die Adresse seines Token-Kontos. Prüfe diese Adresse vor dem Senden. Die Coins werden verbrannt, sobald die Transaktion landet, und nichts im Portal kann sie zurückgeben. Bewahre den Nachrichten-Hash aus dem `ExitInitiated` Ereignis. Warte auf einen bewiesenen Root, der diese Transaktion abdeckt. Der Exit-Prover verwendet den Verifier-Knoten, um einen Speichernachweis der Nachricht des Portals gegen diesen finalen Root zu erstellen. Das Solana-Settlement prüft den Nachweis, die aktive Exit-Konfiguration, das Portal und das Auszahlungslimit. Der Exit-Prover sendet dann eine Freigabe. Die Bridge entnimmt den Betrag aus dem Tresor der Chain und zahlt ihn auf das zugehörige Wrapped-SOL-Tokenkonto des Empfängers aus. Sie kann dieses Tokenkonto bei Bedarf anlegen. Die Auszahlung folgt dem Nachweis ohne separate Wartezeit. Die Freigabetransaktion liest den Empfänger aus dem bewiesenen Datensatz aus, sodass der Betreiber oder jeder andere Absender sie nicht umleiten kann. Das Programm verbraucht den Datensatz und zahlt atomar aus, wodurch eine zweite Auszahlung für dieselbe Auszahlung verhindert wird. Der Großteil der Wartezeit entfällt auf das Schließen, Veröffentlichen und Beweisen des Batches. Der Exit-Prover fragt alle zwei Sekunden ab und zahlt kurz nachdem ein finaler Root verfügbar ist. Im Devnet-Lauf von Rome wurde eine in Block 192 gestartete Auszahlung etwa vier Minuten später auf Solana ausgezahlt. Dies ist eine Messung, keine feste Auszahlungszeit. Ein Exit-Limit begrenzt, wie viel in jedem 172.800-Slot-Challenge-Fenster herausgehen kann. Ein Exit, der nicht in das aktuelle Fenster passt, wartet auf das nächste. Ein einzelner Exit, der größer ist als das gesamte Limit, erfordert, dass die Chain-Authority das Limit anhebt. Änderungen an der Exit-Konfiguration benötigen mindestens ein Challenge-Fenster, um aktiv zu werden. Eine Auszahlung kann nach dem Nachweis dennoch warten, wenn der Empfänger kein Wrapped-SOL-Tokenkonto besitzt und der Betrag unter dem Standard-Schwellwert von 0,01 SOL liegt. Der Exit-Prover lässt sie für eine manuelle Freigabe liegen, statt für die Erstellung dieses Kontos zu zahlen. Der Nutzer oder Betreiber kann `./rollup release-exit --message-hash` mit dem Nachrichten-Hash und `--confirm`. Jeder kann einen gültigen Exit freigeben. ## Was der Betreiber ausführt Erstelle und finanziere den Wrapped-SOL-Tresor nach der Registrierung. Für einen gedeckten Genesis-Saldo sperre denselben Betrag, bevor du den Verifizierungsschlüssel anforderst. Nach dem ersten bewiesenen Root setze ein Exit-Portal, eine Bridge und ein Limit mit `./rollup exit-config propose`. Warte mindestens ein Challenge-Fenster, dann führe `./rollup exit-config activate --confirm`. Die Chain-Authority öffnet die Einzahlungswarteschlange mit `./rollup deposit-queue init --confirm`. Setze `EXITS=on`, dann führe `./rollup init` und `./rollup up` um den Exit-Prover zu starten. Er benötigt seinen **eigenen aufgeladenen Zahler**, getrennt vom Zahler des Batchers. Jeder Exit-Beweis kostet seinen Zahler eine Solana-Gebühr und Datensatzmiete. Der Runner lehnt einen fehlenden oder gemeinsam genutzten Exit-Zahler ab. Die automatische Auszahlung ist standardmäßig aktiviert; der Exit-Prover versucht nach einem Neustart auch bewiesene, offen gelassene Datensätze erneut. Führe `./rollup check`. Es prüft die Deckung des Tresors, Einzahlungsobergrenzen und Rückstau, die aktive Bridge- und Exit-Konfiguration, den Exit-Prover, festhängende Exits, seinen Log-Scan und sein Zahlerguthaben. Der Standard-Mindestbestand für den Exit-Zahler beträgt 0,1 SOL. Verwende `./rollup vault show` und `./rollup deposit-queue show` um Mittel und Warteschlangenstatus zu prüfen. Die vollständigen Anleitungen oben enthalten die Befehle zum Auffüllen eines Tresors und zum Ändern der Warteschlangeneinstellungen. --- # 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/de/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.