> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
> Use this file to discover all available pages before exploring further.

# الإيجار والإيجار القابل للاسترجاع

> تقلل Solana الحد الأدنى المعفى من الإيجار بنسبة 90% عبر خمس خطوات بموجب SIMD-0437. الحسابات الممولة قبل كل خطوة تحتفظ بأكثر مما تحتاج — ما هو هذا الفائض، وأي البرامج تعيده، وكيفية العثور عليه واسترجاعه.

<Info>
  **هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.**

  [عرض النسخة الإنجليزية →](/solana-fundamentals/rent-and-reclaimable-rent)
</Info>

<Info>
  الإيجار هو وديعة قابلة للاسترجاع، وليس رسماً. يقلل SIMD-0437 الوديعة التي يجب أن يحتفظ بها كل حساب، في خمس خطوات مستقلة. الحسابات المنشأة قبل خطوة ما تحتفظ بالرصيد الذي تم تمويله به، لذا تترك كل خطوة الحسابات مفرطة في التمويل. يمكن لبرامج SPL Token و Token-2022 إرجاع هذا الفرق من خلال `WithdrawExcessLamports` دون إغلاق الحساب أو لمس رصيد الرموز. لا شيء ينتهي — الفائض يبقى في حساباتك الخاصة حتى تختار نقله.
</Info>

اقرأ [نموذج الحساب](/ar/solana-fundamentals/account-model) أولاً إذا كنت جديداً على كيفية تمويل حسابات Solana.

## ما هو الإيجار فعلياً

كل حساب على Solana يحتفظ بوديعة SOL بحجم المساحة التي يشغلها. لا يتم إنفاقها — يتم إرجاعها بالكامل عند إغلاق الحساب. الصيغة هي:

```
minimum_balance(data_len) = (ACCOUNT_STORAGE_OVERHEAD + data_len) × lamports_per_byte
```

`ACCOUNT_STORAGE_OVERHEAD` هو 128 بايت ثابت يدفعه كل حساب بغض النظر عن حمولته. `lamports_per_byte` هو الثابت على مستوى الشبكة الذي يغيره SIMD-0437.

حساب SPL token قياسي بحجم 165 بايت كان يكلف دائماً `(128 + 165) × 6,960 = 2,039,280` lamports — حوالي 0.00203928 SOL الذي تراه مخصوماً كلما فتحت محفظة حساب رمز مرتبط.

## ما يغيره SIMD-0437

يقلل SIMD-0437 `lamports_per_byte` من 6,960 إلى 696 — تخفيض بنسبة 90% — يتم طرحه عبر خمس بوابات ميزات منفصلة حتى يتمكن المدققون من امتصاص تأثير نمو الحالة خطوة تلو الأخرى.

| الخطوة     | `lamports_per_byte` | تخفيض من الأصلي | الإيجار لحساب رمز 165 بايت |
| ---------- | ------------------- | --------------- | -------------------------- |
| — (الأصلي) | 6,960               | —               | 2,039,280 lamports         |
| 1          | 6,333               | 9%              | 1,855,569 lamports         |
| 2          | 5,080               | 27%             | 1,488,440 lamports         |
| 3          | 2,575               | 63%             | 754,475 lamports           |
| 4          | 1,322               | 81%             | 387,346 lamports           |
| 5          | 696                 | 90%             | 203,928 lamports           |

تفعلت الخطوة 1 على mainnet في 3 سبتمبر 2026. وصلت الخطوة 2 إلى testnet في نفس اليوم ومن المتوقع أن تصل إلى mainnet في منتصف سبتمبر 2026؛ الخطوات 3–5 محتفظ بها لـ Agave 4.4، المتوقع حوالي نوفمبر 2026. تعامل مع الجدول الزمني على أنه قابل للتغيير — قالت المؤسسة إنها ستوقف الطرح إذا ساء نمو الحالة — واقرأ القيمة المباشرة من الكتلة بدلاً من ترميزها بشكل ثابت.

<Note>
  يعتمد SIMD-0437 على SIMD-0194، الذي يستبدل عتبة الإعفاء من الإيجار «لتجنب الرياضيات العائمة غير الضرورية عند تعيين معاملات الإيجار عند تفعيل الميزة». في الممارسة العملية، يحمل sysvar `Rent` الآن `lamports_per_byte_year = 6,333` مع `exemption_threshold = 1.0`، بدلاً من الانقسام القديم `3,480 × 2` الذي أنتج 6,960. لا تضرب هذين الحقلين بنفسك — استدعِ `getMinimumBalanceForRentExemption` واترك الكتلة تجيب.
</Note>

## لماذا الحسابات الموجودة تحتفظ بأكثر مما تحتاج

تغيير الثابت يغير ما يحتاجه الحساب *فعلياً*. لا يغير ما يملكه الحساب *بالفعل*. حساب ممول بـ 6,960 lamports لكل بايت يحتفظ برصيده بعد تفعيل الخطوة 1، لذا فهو مفرط في التمويل بمقدار:

```
excess = (128 + data_len) × (old_rate − new_rate)
```

لحساب SPL token بحجم 165 بايت بعد الخطوة 1، هذا هو `293 × (6,960 − 6,333) = 183,711` lamports، أو حوالي 0.000184 SOL لكل حساب. حساب Token-2022 يحمل امتدادات أكبر، لذا يحتفظ بنسبة أكثر — حساب بحجم 182 بايت مفرط في التمويل بـ `310 × 627 = 194,370` lamports.

بشكل فردي هذا غبار. محفظة تفاعلت مع بضع مئات من الرموز على مدار السنين تحتفظ بمضاعف معنوي منه، وبحلول الخطوة 5 كل حساب 165 بايت يحتفظ بـ 1,835,352 lamports (حوالي 0.00184 SOL) فوق الحد الأدنى.

## أي الحسابات يمكنها إرجاع الفائض

لا يمكن نقل lamports الفائضة في حساب مملوك للبرنامج إلا من قبل هذا البرنامج. ما إذا كان يمكنك استرجاع الإيجار دون إغلاق الحساب يعتمد بالكامل على البرنامج الذي يملكه.

<CardGroup cols={2}>
  <Card title="SPL Token و Token-2022" icon="circle-check">
    كلاهما يعرض `WithdrawExcessLamports`. يبقى الحساب مفتوحاً، ويحتفظ برصيد الرموز، وينخفض ببساطة إلى الحد الأدنى الحالي.
  </Card>

  <Card title="كل شيء آخر" icon="circle-xmark">
    لا توجد تعليمات مكافئة. يتم إطلاق الإيجار فقط عند إغلاق الحساب — عملية مدمرة لها شروطها الخاصة، وليست كنس إيجار.
  </Card>
</CardGroup>

بشكل ملموس، لأنواع الحسابات التي يحتفظ بها مستخدمو Raydium:

| الحساب                     | المالك                                        | هل يمكن إرجاع الفائض في المكان؟                                  |
| -------------------------- | --------------------------------------------- | ---------------------------------------------------------------- |
| حساب رمز SPL               | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` | نعم — `WithdrawExcessLamports`                                   |
| حساب رمز Token-2022        | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | نعم — `WithdrawExcessLamports`                                   |
| حساب رمز SOL المغلف (أصلي) | أي برنامج رمز                                 | لا — انظر أدناه                                                  |
| موضع CLMM                  | Raydium CLMM                                  | لا — يعود الإيجار عند إغلاق الموضع                               |
| أوامر OpenBook v1 المفتوحة | OpenBook v1                                   | لا — `CloseOpenOrders` فقط                                       |
| أوامر OpenBook v2 المفتوحة | OpenBook v2                                   | لا — `close_open_orders_account` فقط                             |
| حساب الرهن                 | برنامج الرهن                                  | لا — يثبت SIMD-0490 `rent_exempt_reserve` عند 2,282,880 lamports |

حسابات SOL المغلفة هي الاستثناء الوحيد لبرنامج الرمز: رصيد lamport الخاص بهم *هو* رصيد الرمز الخاص بهم، لذا يرفضهما كلا البرنامجين مع `TokenError::NativeNotSupported`. بدلاً من ذلك، يعرض **كلا** البرنامجين `UnwrapLamports` (discriminant 45) لهذه الحالة — إنه في `spl-token-interface` جنباً إلى جنب مع `WithdrawExcessLamports`، لذا يمتلكه البرنامج القديم أيضاً، وليس فقط Token-2022 — و `@solana/spl-token` يشحن `createUnwrapLamportsInstruction` له اعتباراً من 0.4.15. تخطَّ الحسابات الأصلية في كنس إيجار عادي وتعامل معها بشكل متعمد؛ النمط الآمن للقيام بذلك هو الذي تستخدمه برامج Raydium الخاصة، [أدناه](#what-the-raydium-programs-sweep-on-their-own-side).

## تعليمات `WithdrawExcessLamports`

Discriminant **38** في تعدادات التعليمات لكلا برنامجي الرموز. من `spl-token-interface`:

```rust theme={null}
/// This instruction is to be used to rescue SOL sent to any TokenProgram
/// owned account by sending them to any other account, leaving behind only
/// lamports for rent exemption.
///
/// 0. `[writable]` Source Account owned by the token program
/// 1. `[writable]` Destination account
/// 2. `[signer]` Authority
/// 3. `..3+M` `[signer]` M signer accounts
WithdrawExcessLamports,
```

ثلاث خصائص تجعلها آمنة للتشغيل على كل حساب في محفظة:

* **لا تأخذ مبلغاً.** يحسب البرنامج `source.lamports − rent.minimum_balance(source.data_len())` بنفسه، لذا لا يمكنه أبداً أخذ حساب أقل من الحد الأدنى الحالي، ويبقى صحيحاً مع تفعيل الخطوات اللاحقة.
* **لا تغلق أي شيء.** يحتفظ الحساب ببيانات، ومالكه، ورصيد الرموز الخاص به.
* **إنها عملية idempotent.** تشغيلها على حساب بالفعل عند الحد الأدنى ينقل صفر lamports وينجح.

حساب رمز مجمد لا يزال مؤهلاً: التجميد يقيد حركة الرموز، وليس lamports.

### بناء التعليمات

`@solana/spl-token` لا يصدر منشئ لها. اعتباراً من `0.4.15` إدخال التعداد لا يزال معلقاً — ولاحظ أن المصدر الأصلي يهجئ المُعرِّف `WithdrawalExcessLamports`، بحرفَي "al" الزائدين، فابحث عنه بهذا الهجاء:

```ts theme={null}
// packages/spl-token/src/instructions/types.ts
export enum TokenInstruction {
    // ...
    TransferHookExtension = 36,
    // ConfidentialTransferFeeExtension = 37,
    // WithdrawalExcessLamports = 38,   // ← not exposed
    MetadataPointerExtension = 39,
    // ...
}
```

قم بترميزها مباشرة. الحمولة هي بايت discriminant واحد:

```ts theme={null}
import { PublicKey, TransactionInstruction } from "@solana/web3.js";

export function createWithdrawExcessLamportsInstruction(params: {
  source: PublicKey;        // the token account holding excess lamports
  destination: PublicKey;   // where the excess goes — usually the wallet itself
  authority: PublicKey;     // owner of `source`, or the multisig account
  multiSigners?: PublicKey[];
  programId: PublicKey;     // TOKEN_PROGRAM_ID or TOKEN_2022_PROGRAM_ID
}): TransactionInstruction {
  const { source, destination, authority, multiSigners = [], programId } = params;
  return new TransactionInstruction({
    programId,
    keys: [
      { pubkey: source, isSigner: false, isWritable: true },
      { pubkey: destination, isSigner: false, isWritable: true },
      { pubkey: authority, isSigner: !multiSigners.length, isWritable: false },
      ...multiSigners.map((pubkey) => ({ pubkey, isSigner: true, isWritable: false })),
    ],
    data: Buffer.from([38]),
  });
}
```

مرر `programId` الخاص بكل حساب. يمكن لتعليمات SPL Token و Token-2022 مشاركة معاملة، لكن يجب معالجة كل واحدة من قبل البرنامج الذي يملك حساب المصدر الخاص به.

تم قياسه على mainnet، التعليمات تكلف 270 وحدة حساب على برنامج SPL Token و 1,414 على Token-2022 — مهمل بأي حال. القيد الحقيقي هو حجم المعاملة، وليس الحساب.

## العثور على الحسابات القابلة للاسترجاع

لا تشتق الفائض من معدل مرمز بشكل ثابت. اسأل الكتلة ما يحتاجه كل حساب الآن، حتى يبقى نفس الكود يعمل عبر جميع الخطوات الخمس:

```ts theme={null}
const [tokenResp, token2022Resp] = await Promise.all([
  connection.getTokenAccountsByOwner(owner, { programId: TOKEN_PROGRAM_ID }),
  connection.getTokenAccountsByOwner(owner, { programId: TOKEN_2022_PROGRAM_ID }),
]);
const raw = [...tokenResp.value, ...token2022Resp.value];

// one lookup per distinct account size — a wallet normally has two or three
const spaces = Array.from(new Set(raw.map(({ account }) => account.data.length)));
const minimums = new Map(
  await Promise.all(
    spaces.map(async (space) => [space, await connection.getMinimumBalanceForRentExemption(space)] as const),
  ),
);

const reclaimable = raw.filter(({ account }) => {
  // wrapped SOL carries its token balance as lamports — both programs refuse it.
  // The `is_native` COption tag sits at offset 109 in the token account layout,
  // which Token-2022 preserves before its extension data.
  if (account.data.readUInt32LE(109) === 1) return false;
  return account.lamports > minimums.get(account.data.length)!;
});
```

`getMinimumBalanceForRentExemption(0)` هو قناة جانبية مفيدة: تعيد بالضبط `128 × lamports_per_byte`، لذا القسمة على 128 تخبرك بأي خطوة طرح تكون الكتلة عليها دون تحليل sysvar `Rent`.

## التجميع: كم عدد التعليمات التي تناسب معاملة واحدة

كل تعليمة `WithdrawExcessLamports` تساهم بمفتاح حساب قابل للكتابة فريد واحد — 32 بايت في الرسالة المترجمة — بالإضافة إلى حوالي 7 بايت من ترميز التعليمات. الوجهة والسلطة ودافع الرسوم كلهم نفس المحفظة، لذا يكلفون مفتاح واحد بينهم.

مقابل حد المعاملة 1,232 بايت، تناسب حوالي 25 تعليمة مرة واحدة بعد حساب تعليمات الميزانية والـ blockhash. **عشرون لكل معاملة** هو رقم العمل الآمن، وهو ما تستخدمه تطبيق Raydium الخاص به. محفظة بـ 116 حساب قابل للاسترجاع تكنس إذاً في ست معاملات، برسم أساسي 5,000 lamports لكل واحدة.

لاحظ الاقتصاديات: يتم فرض الرسم لكل معاملة، وليس لكل حساب. استرجاع حسابات أقل لا يكلف أقل، وهذا هو السبب في أن الكنس الجزئي نادراً ما يستحق الرحلات الإضافية.

## الاسترجاع من خلال Raydium

تقوم صفحة [raydium.io/reclaim-rent](https://raydium.io/reclaim-rent) بمسح حسابات SPL Token و Token-2022 للمحفظة المتصلة، وتعرض الإجمالي مقسم حسب البرنامج، وتكنس كل شيء في معاملات مجمعة. المسح للقراءة فقط — لا توقيع حتى تضغط على **استرجاع كل الإيجار**.

تغطي الصفحة بشكل متعمد حسابات الرموز فقط. أنواع الحسابات التي يمكنها إطلاق الإيجار فقط بالإغلاق يتم استبعادها بدلاً من إدراجها كغير متاحة، لأن إغلاق حساب هو إجراء مختلف ومدمر.

## الاسترجاع من عرض توضيحي SDK

<Info>
  **لافتة الإصدار.** تستهدف هذه العروض التوضيحية `@raydium-io/raydium-sdk-v2@0.2.64-alpha` مقابل Solana mainnet-beta، تم التحقق منها في سبتمبر 2026؛ مستودع `raydium-sdk-V2-demo` نفسه يثبت حالياً `0.2.62-alpha`، والاثنان قابلان للتبديل هنا. يتم ترميز `WithdrawExcessLamports` يدوياً وهو مستقل عن إصدار SDK — يتم استخدام SDK فقط لبناء المعاملات والتجميع.
</Info>

نصان برمجيان في [`raydium-sdk-V2-demo/src/rent`](https://github.com/raydium-io/raydium-sdk-V2-demo/tree/master/src/rent):

```bash theme={null}
# read-only: what can this wallet reclaim, and what would it be worth after all five steps
yarn dev src/rent/checkReclaimableRent.ts
yarn dev src/rent/checkReclaimableRent.ts <any wallet address>

# build, simulate (DRY_RUN = true by default), then send the batched sweep
yarn dev src/rent/reclaimRent.ts
```

يجمع `reclaimRent.ts` عند 20 حساب لكل معاملة ويوقع جميع الدفعات في ممر واحد:

```ts theme={null}
const batches = chunk(report.accounts, ACCOUNTS_PER_TX);

const builtTxs = await Promise.all(
  batches.map(async (batch) => {
    const builder = new TxBuilder({
      connection,
      feePayer: owner.publicKey,
      cluster: raydium.cluster,
      owner: raydium.owner,
    });
    builder.addInstruction({
      instructions: batch.map((account) =>
        createWithdrawExcessLamportsInstruction({
          source: account.pubkey,
          destination: owner.publicKey,
          authority: owner.publicKey,
          programId: account.programId,
        }),
      ),
    });
    return builder.versionBuild({ txVersion });
  }),
);

// versionMultiBuild puts the calling builder's transaction first and appends
// extraPreBuildData after it, so batch 1 drives and batches 2..n follow in order
const [firstTx, ...restTxs] = builtTxs;
const { execute } = await firstTx.builder.versionMultiBuild({ txVersion, extraPreBuildData: restTxs });
const { txIds } = await execute({ sequentially: true });
```

محاكاة قبل الإرسال. `simulateTransaction` مع `accounts.addresses` يعيد أرصدة lamport بعد التنفيذ، وهي أرخص طريقة للتأكد من أن الحسابات تطابق ما ستفعله الكتلة فعلياً.

## ما تكنسه برامج Raydium على جانبهم الخاص

محفظتك ليست المكان الوحيد الذي يحرر فيه التخفيض lamports. كل مجموعة تحتفظ بإيجار أيضاً — الأقبية، وسك LP، وحسابات الحالة المملوكة للبرنامج التي تم تمويلها جميعاً بالمعدل القديم. هذا الإيجار ينتمي للبروتوكول، وليس لـ LPs: تم دفعه من قبل من أنشأ الحساب، وليس جزءاً من احتياطيات أي مجموعة، ولم يدخل أبداً المنحنى.

اكتسبت ثلاثة برامج تعليمات إدارية في 2026-09-09 لإرجاعها:

| البرنامج  | التعليمات                         | الموقّع                                    |
| --------- | --------------------------------- | ------------------------------------------ |
| AMM v4    | `WithdrawExcessLamports` (tag 18) | محفظة جمع lamports مخصصة فقط               |
| CPMM      | `CollectExcessLamports`           | مسؤول البرنامج أو محفظة جمع lamports مخصصة |
| LaunchLab | `CollectExcessLamports`           | مسؤول البرنامج أو محفظة جمع lamports مخصصة |

العناوين موجودة في [`reference/program-addresses`](/ar/reference/program-addresses#excess-lamports-collection-wallets). لم تكن CLMM و Stable AMM جزءاً من هذا الإصدار.

**لا شيء هنا يؤثر على LP أو متاجر.** تنقل هذه التعليمات lamports فقط. أرصدة الرموز، بيانات الحساب، المالكون، حالة المجموعة، إمداد LP، عدادات الرسوم والمنحنى كلها لم تتغير، ولا يمكن لأي منها إغلاق حساب. عرض أسعار المجموعة للمبادلة متطابق قبل وبعد الكنس. لا توجد إجراءات من جانب المستخدم، لا اختيار، ولا موعد نهائي.

### أشكال الحسابات الثلاثة التي يتعامل معها كل برنامج

جميعها تتبع نفس الإرسال، على مالك حساب المصدر:

* **حساب رمز أو سك مملوك لـ PDA سلطة برنامج** — يقوم البرنامج بـ CPI لـ `WithdrawExcessLamports` (discriminant 38) لبرنامج الرمز، موقعاً كـ PDA.
* **قبو SOL مغلف** — يرفض `WithdrawExcessLamports` الحسابات الأصلية، لذا يقوم البرنامج بـ `SyncNative` أولاً (الذي يطوي الفائض المتبرع به في `amount` المغلف)، يقيس بالضبط كم نما المبلغ المغلف، `UnwrapLamports` لهذا الدلتا، ثم يؤكد أن الرصيد المغلف عاد إلى قيمته السابقة للمزامنة. إذا فشل هذا الفحص، تعود التعليمات بأكملها مع `LamportsCalculateError`. هذا هو السبب في أن قبو مجموعة جانب SOL يحتفظ بسيولته الكاملة من خلال الكنس.
* **حساب حالة مملوك للبرنامج** — `AmmInfo`، `PoolState`، `AmmConfig`، `ObservationState`، `PlatformConfig`، وما إلى ذلك. يمكن للبرنامج خصم حساباته الخاصة مباشرة، لذا ينقل الرصيد إلى `rent.minimum_balance(data_len)` بدون CPI على الإطلاق.

يتم تخطي الحسابات المملوكة لأي شيء آخر بصمت، لذا تمرير حساب غير ذي صلة آمن بدلاً من أن يكون قاتلاً.

تسلسل SOL المغلف يستحق النسخ إذا كنت تحتفظ بحسابات أصلية خاصة بك: إنها الطريقة الوحيدة لأخذ الفائض من حساب wSOL دون تغيير ما يبلغ عنه الحساب كرصيد رمز.

<Note>
  **تعتمد هذه المسارات على برنامج الرمز المنشور، وليس على إصدار crate.** تقوم جميع البرامج الثلاثة بترميز تعليمات الرمز يدوياً — بايت `38` واحد لـ `WithdrawExcessLamports`، `45` بالإضافة إلى `COption<u64>` لـ `UnwrapLamports` — وترسلها إلى أي برنامج رمز يملك حساب المصدر. كلا التعليمات موجودة في برامج SPL Token و Token-2022 الحالية على mainnet. محاكي محلي أو اختبار يشغل بناء SPL Token قديم مجمع لا ينفذهما، والكنس ضده يفشل على discriminator غير معروف بدلاً من أي شيء في برنامج Raydium. اختبر هذه المسارات مقابل برنامج رمز مستنسخ من mainnet.
</Note>

### ما لا يزال لا يمكن استرجاعه في المكان

إيجار موضع CLMM لم يتغير من كل هذا — يعود عند إغلاق الموضع، كما تقول الجدول أعلاه. نفس الشيء بالنسبة لـ LaunchLab base mint: تعليمات التهيئة تلغي `MintTokens` في نفس الاستدعاء الذي يسك الإمداد، لذا لا يمكن لأي مفتاح أبداً توقيع `WithdrawExcessLamports` لهذا السك وإيجاره عالق بالتصميم.

## هل يجب عليك الاسترجاع الآن أم الانتظار؟

كلاهما جيد، والفرق صغير على أي حال:

* **الفائض لا يذهب إلى أي مكان.** يجلس في حساباتك الخاصة. لا شيء ينتهي، لا شيء يتم كنسه، لا موعد نهائي ينطبق.
* **الانتظار يركب.** كل خطوة تحرر المزيد من نفس الحسابات، وكنس واحد بعد الخطوة 5 يكلف نفس الرسوم مثل كنس واحد اليوم.
* **الاسترجاع الآن لا يتنازل عن الخطوات اللاحقة.** حساب تكنسه اليوم هو ببساطة عند الحد الأدنى الحالي؛ الخطوة التالية تجعله مفرط التمويل مرة أخرى ويمكنك كنسه مرة أخرى.

التكلفة الحقيقية الوحيدة للاسترجاع المبكر هي الرسم الأساسي، والتكلفة الحقيقية الوحيدة للانتظار هي أن lamports تبقى ثابتة لفترة أطول.

## قراءة إضافية

<CardGroup cols={2}>
  <Card title="SIMD-0437" icon="file-code" href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0437-incremental-rent-reduction.md">
    الاقتراح نفسه — بوابات الميزات الخمس والمنطق الكامن وراء تدرج التخفيض.
  </Card>

  <Card title="تخفيض الإيجار" icon="book" href="https://solana.com/upgrades/reduced-rent">
    صفحة طرح Solana: الخطوة الحالية والجدول الزمني وما يتغير للحسابات الجديدة.
  </Card>

  <Card title="تخفيض الإيجار: تحليل مدعوم بالبيانات" icon="chart-line" href="https://solana.com/news/rent-reduction-deep-dive">
    الاقتصاديات، وخطر نمو الحالة الذي يهدف الطرح المتدرج إلى إدارته.
  </Card>

  <Card title="نموذج الحساب" icon="database" href="/ar/solana-fundamentals/account-model">
    كيف يتم تمويل حسابات Solana وملكيتها وإغلاقها — الخلفية لكل ما سبق.
  </Card>
</CardGroup>
