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

# الإيداعات والسحوبات

انقل SOL إلى سلسلة Rome ZK EVM واسحب عملتها الأصلية إلى محفظة Solana.

في إعداد شبكة التطوير v0.3.0، تكون العملة الأصلية للسلسلة مغطاةً بـ SOL المغلف في خزينة سولانا الخاصة بها. يَحجز الإيداعُ SOL المغلف ويُسجِّل الرصيد لصالح عنوان EVM المُسمّى. ويَحرق السحبُ تلك العملة على السلسلة ويدفع SOL المغلف من الخزينة إلى مستلم على سولانا. ويتوافق غيغاواحد (gwei) واحد على السلسلة مع لامبورت واحد من SOL المغلف.

الـ [دليل السحب الكامل](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/WITHDRAWALS.md) يحتوي على الاستدعاء الدقيق وأسماء الفحوصات والرفض. و [دليل شبكة التطوير](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) يغطي إعداد الإيداع وأمر المُودِع.

## إيداع SOL

يحتاج المشغّل أولًا إلى جذر مُثبَت، وخزينة SOL مغلف، وإعداد خروج نشط يَذكر الجسر، وطابور إيداع. من دون هذه العناصر، لا يمكن للسلسلة الجديدة قبول الإيداعات. يبدأ التأسيس (genesis) للسلسلة بلا رصيد ما لم يكن مشغّلها قد أعلن عن رصيد واحد وغطّاه.

يستخدم المُودِع `./rollup deposit` مع مقدار باللامبورت، ومستلم EVM، وموقّعه على سولانا الخاص، و `--wrap-sol`‎. يَلتف هذا الخيار بـ SOL في معاملة سولانا نفسها مثل الإيداع. يكون الأمر تشغيلًا تجريبيًا حتى تُضاف `--confirm` ‎. الحد الأدنى الافتراضي هو 1,000,000 لامبورت، أو 0.001 SOL. ورسوم الطابور الافتراضية هي 100,000 لامبورت، أو 0.0001 SOL، وتُدفَع إلى سلطة السلسلة. كما يدفع المُودِع أيضًا رسوم المعاملة وإيجار سجل الإيداع.

يقوم الجسر بحجز SOL المغلف في خزينة تلك السلسلة ويُلحق سجلًا مرقّمًا. ويقرأ المُسلسِل إيداعات سولانا النهائية ويُسجّلها بالترتيب في كتل EVM الجديدة. يظهر الرصيد عند RPC الخاص بالسلسلة عندما تُختَم كتلتها. ولا يصبح الائتمان نهائيًا إلا عندما تُثبَت الدفعة التي تحتويه ويصل جذرها إلى سولانا.

الموعد النهائي الافتراضي لإدراج الطابور هو 12 ساعة، وبحد أقصى 256 إيداعًا لكل دفعة و4 لكل كتلة. يتحقق صندوق الوارد من الموعد النهائي عند نهائية الدفعة. هذه القاعدة لا تُلزم المشغّل بإنتاج دفعة أو إثباتها. ويمكن للمشغّل مع ذلك تأخير الإيداع بإيقاف السلسلة.

يمكن أن يعود إيجار سجل الإيداع إلى المُودِع بعد أن يصبح جذر دفعة الائتمان نهائيًا ويرسل مشغّل الدفعة `CloseBatch`‎. عندها يمكن لأي شخص إرسال `CloseDeposit`‎. يبقى الإيداع في الخزينة كغطاء. ولا يرسل المشغّل في v0.3.0 `CloseBatch`، لذا لا تُغلَق السجلات تلقائيًا ويظل إيجارها مقفولًا.

## السحب إلى سولانا

السحوبات مخصّصة للعملة الأصلية للسلسلة فقط. أرسِل استدعاءً قابلًا للدفع `initiateExit(bytes32 solRecipient)` إلى بوابة الخروج عند `0x4200000000000000000000000000000000000016`‎. تمثّل القيمةُ مقدارَ السحب. والمستلم هو **عنوان محفظة سولانا مُرمَّز كـ 32 بايت**، وليس عنوان حساب الرموز الخاص به. تحقّق من العنوان قبل الإرسال. تُحرَق العملات فور وصول المعاملة، ولا يمكن لأي شيء في البوابة إرجاعها. احتفِظ بتجزئة الرسالة من حدث `ExitInitiated` .

انتظر جذرًا مُثبَتًا يغطي تلك المعاملة. يستخدم مُثبِت الخروج عقدة المُتحقِّق لإنشاء برهان تخزين لرسالة البوابة مقابل ذلك الجذر النهائي. وتتحقق التسوية على سولانا من البرهان، وإعداد الخروج النشط، والبوابة، وسقف السحب. ثم يرسل مُثبِت الخروج عملية تحرير. يأخذ الجسر المبلغ من خزينة السلسلة ويدفع إلى حساب الرموز المرتبط بـ SOL المغلف الخاص بالمستلم. ويمكنه إنشاء حساب الرموز هذا عند الحاجة.

يتبع الدفع البرهانَ من دون فترة انتظار منفصلة. تقرأ معاملة التحرير المستلم من السجل المُثبَت، لذا لا يستطيع المشغّل أو أي مُرسِل آخر إعادة توجيهه. يستهلك البرنامج السجل ويدفع المبلغ ذريًا، ما يمنع دفعًا ثانيًا للسحب نفسه.

معظم وقت الانتظار هو الوقت اللازم لإغلاق الدفعة ونشرها وإثباتها. يستعلم مُثبِت الخروج كل ثانيتين ويدفع بعد توفر جذر نهائي بقليل. في تشغيل شبكة التطوير لروما، بدأ سحب في الكتلة 192 ودُفع على سولانا بعد نحو أربع دقائق. هذا قياس واحد، وليس زمن سحب ثابتًا.

يحدّ سقف الخروج من مقدار ما يمكن أن يغادر في كل نافذة تحدٍ مدتها 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` لبدء مُثبِت الخروج. وهو يحتاج إلى **المدفوع الخاص به**، منفصلًا عن المدفوع الخاص بالمُجمِّع. وتكلف كل عملية إثبات خروج المدفوعَ الخاص بها رسومًا على سولانا وإيجار سجل. يرفض المشغّل وجود مدفوع خروج مفقود أو مشترك. يكون الدفع التلقائي مُفعّلًا افتراضيًا؛ كما يعيد مُثبِت الخروج المحاولات للسجلات المُثبَتة التي تُركت مفتوحة بعد إعادة التشغيل.

شغّل `./rollup check`‎. وهو يتحقق من تغطية الخزينة، وحدود الإيداع والمتأخرات، والجسر النشط وإعداد الخروج، ومُثبِت الخروج، والخروج العالق، وفحص السجل، ورصيد المدفوع الخاص به. الحد الأدنى الافتراضي لمدفوع الخروج هو 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/ar/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.