Skip to main content
Trang này được dịch tự động bằng AI. Phiên bản tiếng Anh là bản chính thức.Xem bản tiếng Anh →
Rent là một khoản ký quỹ có thể hoàn lại, không phải một khoản phí. SIMD-0437 giảm khoản ký quỹ mà mỗi tài khoản phải giữ, qua năm bước độc lập. Các tài khoản được tạo trước một bước giữ lại số dư mà chúng được tài trợ, vì vậy mỗi bước để lại chúng bị tài trợ quá mức. Các chương trình SPL Token và Token-2022 có thể trả lại sự khác biệt đó thông qua WithdrawExcessLamports mà không cần đóng tài khoản hoặc chạm vào số dư token. Không có gì hết hạn — phần dư nằm trong các tài khoản của bạn cho đến khi bạn chọn di chuyển nó.
Hãy đọc Account model trước nếu bạn mới làm quen với cách các tài khoản Solana được tài trợ.

Rent thực sự là gì

Mỗi tài khoản trên Solana giữ một khoản ký quỹ SOL được định kích thước theo không gian mà nó chiếm dụng. Nó không bị chi tiêu — nó được trả lại đầy đủ khi tài khoản được đóng. Công thức là:
ACCOUNT_STORAGE_OVERHEAD là 128 byte cố định mà mỗi tài khoản phải trả bất kể nội dung của nó. lamports_per_byte là hằng số toàn mạng mà SIMD-0437 thay đổi. Một tài khoản token SPL tiêu chuẩn 165 byte do đó luôn có chi phí (128 + 165) × 6,960 = 2,039,280 lamports — khoảng ~0.00203928 SOL mà bạn thấy bị khấu trừ bất cứ khi nào ví mở một tài khoản token liên kết.

SIMD-0437 thay đổi gì

SIMD-0437 giảm lamports_per_byte từ 6,960 xuống 696 — giảm 90% — được triển khai qua năm cổng tính năng riêng biệt để các trình xác thực có thể hấp thụ hiệu ứng tăng trưởng trạng thái từng bước một. Bước 1 được kích hoạt trên mainnet vào ngày 3 tháng 9 năm 2026. Bước 2 đạt testnet cùng ngày và dự kiến sẽ có trên mainnet vào giữa tháng 9 năm 2026; các bước 3–5 được giữ cho Agave 4.4, dự kiến vào khoảng tháng 11 năm 2026. Hãy coi lịch trình có thể thay đổi — Quỹ đã nói rằng nó sẽ tạm dừng việc triển khai nếu tăng trưởng trạng thái hoạt động không tốt — và đọc giá trị trực tiếp từ cụm thay vì mã hóa cứng nó.
SIMD-0437 phụ thuộc vào SIMD-0194, cái mà loại bỏ ngưỡng miễn phí rent “để tránh toán học dấu phẩy động không cần thiết khi đặt các tham số rent khi kích hoạt tính năng”. Trong thực tế, sysvar Rent hiện mang lamports_per_byte_year = 6,333 với exemption_threshold = 1.0, thay vì phân chia 3,480 × 2 cũ tạo ra 6,960. Đừng nhân hai trường đó với nhau — gọi getMinimumBalanceForRentExemption và để cụm trả lời.

Tại sao các tài khoản hiện tại giữ quá nhiều

Giảm hằng số thay đổi những gì một tài khoản cần. Nó không thay đổi những gì một tài khoản có. Một tài khoản được tài trợ ở 6,960 lamports trên byte giữ lại số dư đó sau khi bước 1 được kích hoạt, vì vậy nó bị tài trợ quá mức bởi:
Đối với tài khoản token SPL 165 byte sau bước 1, đó là 293 × (6,960 − 6,333) = 183,711 lamports, hoặc ~0.000184 SOL trên mỗi tài khoản. Một tài khoản Token-2022 mang các tiện ích mở rộng lớn hơn, vì vậy nó giữ tương ứng nhiều hơn — một tài khoản 182 byte bị tài trợ quá mức bởi 310 × 627 = 194,370 lamports. Riêng lẻ đó là bụi. Một ví đã tương tác với một vài trăm token qua các năm đang giữ một bội số có ý nghĩa của nó, và theo bước 5, mỗi tài khoản 165 byte có 1,835,352 lamports (~0.00184 SOL) nằm trên mức tối thiểu của nó.

Những tài khoản nào có thể trả lại nó

Lamports dư thừa trong một tài khoản do chương trình sở hữu chỉ có thể được di chuyển bởi chương trình đó. Liệu bạn có thể hoàn lại rent mà không cần đóng tài khoản hay không do đó hoàn toàn phụ thuộc vào chương trình nào sở hữu nó.

SPL Token và Token-2022

Cả hai đều công khai WithdrawExcessLamports. Tài khoản vẫn mở, giữ lại số dư token của nó, và chỉ đơn giản là giảm xuống mức tối thiểu hiện tại.

Mọi thứ khác

Không có hướng dẫn tương đương. Rent chỉ được phát hành khi tài khoản được đóng — một hoạt động phá hủy với các điều kiện tiên quyết riêng của nó, không phải một lần quét rent.
Cụ thể, đối với các loại tài khoản mà người dùng Raydium giữ: Các tài khoản SOL được bao bọc là một ngoại lệ của chương trình token: số dư lamport của chúng là số dư token của chúng, vì vậy cả hai chương trình từ chối chúng với TokenError::NativeNotSupported. Cả hai chương trình thay vào đó công khai UnwrapLamports (discriminant 45) cho trường hợp đó — nó nằm trong spl-token-interface cùng với WithdrawExcessLamports, vì vậy chương trình kế thừa cũng có nó, không chỉ Token-2022 — và @solana/spl-token vận chuyển createUnwrapLamportsInstruction cho nó kể từ 0.4.15. Bỏ qua các tài khoản gốc trong một lần quét rent đơn giản và xử lý chúng một cách cố ý; mẫu để làm điều đó một cách an toàn là mẫu mà các chương trình của Raydium sử dụng, bên dưới.

Hướng dẫn WithdrawExcessLamports

Discriminant 38 trong enum hướng dẫn của cả hai chương trình token. Từ spl-token-interface:
Ba thuộc tính làm cho nó an toàn để kích hoạt trên mỗi tài khoản trong một ví:
  • Nó không lấy số tiền. Chương trình tính toán source.lamports − rent.minimum_balance(source.data_len()) chính nó, vì vậy nó không bao giờ có thể lấy một tài khoản dưới mức tối thiểu hiện tại, và nó vẫn chính xác khi các bước sau được kích hoạt.
  • Nó không đóng bất cứ điều gì. Tài khoản giữ lại dữ liệu, chủ sở hữu và số dư token của nó.
  • Nó là idempotent. Chạy nó trên một tài khoản đã ở mức tối thiểu di chuyển không lamports và thành công.
Một tài khoản token bị đóng băng vẫn đủ điều kiện: đóng băng hạn chế chuyển động token, không phải lamports.

Xây dựng hướng dẫn

@solana/spl-token không xuất một trình xây dựng cho nó. Kể từ 0.4.15, mục nhập enum vẫn bị bình luận — và lưu ý upstream đánh vần định danh WithdrawalExcessLamports, với “al” thêm, vì vậy grep cho cái đó:
Mã hóa nó trực tiếp. Tải trọng là một byte discriminant duy nhất:
Chuyển programId của mỗi tài khoản. Các hướng dẫn SPL Token và Token-2022 có thể chia sẻ một giao dịch, nhưng mỗi hướng dẫn phải được gửi đến chương trình sở hữu tài khoản nguồn của nó. Được đo lường trên mainnet, hướng dẫn chi phí 270 đơn vị tính toán trên chương trình SPL Token và 1,414 trên Token-2022 — không đáng kể bằng cách nào. Ràng buộc thực sự là kích thước giao dịch, không phải tính toán.

Tìm kiếm các tài khoản có thể hoàn lại

Đừng lấy phần dư từ một tỷ lệ được mã hóa cứng. Hỏi cụm những gì mỗi tài khoản cần ngay bây giờ, vì vậy mã tương tự vẫn hoạt động qua tất cả năm bước:
getMinimumBalanceForRentExemption(0) là một kênh phụ hữu ích: nó trả về chính xác 128 × lamports_per_byte, vì vậy chia cho 128 cho bạn biết cụm đang ở bước triển khai nào mà không cần phân tích sysvar Rent.

Ghép nối: bao nhiêu vừa vặn trong một giao dịch

Mỗi hướng dẫn WithdrawExcessLamports đóng góp một khóa tài khoản có thể ghi duy nhất — 32 byte trong thông báo được biên dịch — cộng với khoảng 7 byte mã hóa hướng dẫn. Đích đến, quyền hạn và người trả phí đều là cùng một ví, vì vậy chúng chi phí một khóa giữa chúng. Chống lại giới hạn giao dịch 1,232 byte, khoảng 25 hướng dẫn vừa vặn một khi các hướng dẫn ngân sách tính toán và blockhash được tính. Hai mươi trên mỗi giao dịch là con số làm việc an toàn, và đó là những gì triển khai của Raydium sử dụng. Một ví có 116 tài khoản có thể hoàn lại do đó quét trong sáu giao dịch, ở mức phí cơ sở 5,000 lamports mỗi cái. Lưu ý kinh tế: phí được tính trên mỗi giao dịch, không phải trên mỗi tài khoản. Hoàn lại ít tài khoản hơn không chi phí ít hơn, đó là lý do tại sao một lần quét một phần hiếm khi đáng giá các chuyến tròn bổ sung.

Hoàn lại thông qua Raydium

Trang raydium.io/reclaim-rent quét các tài khoản SPL Token và Token-2022 của ví được kết nối, hiển thị tổng số được chia theo chương trình, và quét mọi thứ trong các giao dịch được ghép nối. Quét là chỉ đọc — không có chữ ký cho đến khi bạn nhấn Reclaim all rent. Trang này cố ý chỉ bao gồm các tài khoản token. Các loại tài khoản chỉ có thể phát hành rent bằng cách đóng được loại trừ thay vì được liệt kê là không khả dụng, vì đóng một tài khoản là một hành động khác, phá hủy.

Hoàn lại từ bản demo SDK

Biểu ngữ phiên bản. Các bản demo này nhắm mục tiêu @raydium-io/raydium-sdk-v2@0.2.64-alpha chống lại Solana mainnet-beta, được xác minh 2026-09; kho raydium-sdk-V2-demo hiện tại cài đặt 0.2.62-alpha, và hai cái này có thể hoán đổi ở đây. WithdrawExcessLamports được mã hóa bằng tay và độc lập với phiên bản SDK — SDK chỉ được sử dụng để xây dựng và ghép nối giao dịch.
Hai tập lệnh trong raydium-sdk-V2-demo/src/rent:
reclaimRent.ts ghép nối ở 20 tài khoản trên mỗi giao dịch và ký tất cả các lô trong một lần:
Mô phỏng trước khi bạn gửi. simulateTransaction với accounts.addresses trả về số dư lamport sau khi thực thi, đó là cách rẻ nhất để xác nhận số học khớp với những gì cụm sẽ thực sự làm.

Những gì các chương trình Raydium quét ở phía của chúng

Ví của bạn không phải là nơi duy nhất mà việc giảm giải phóng lamports. Mỗi pool giữ rent quá — vaults, LP mints, và các tài khoản trạng thái do chương trình sở hữu đều được tài trợ ở tỷ lệ cũ. Rent đó thuộc về giao thức, không phải LPs: nó được trả bởi bất cứ ai tạo tài khoản, nó không phải là một phần của bất kỳ dự trữ pool nào, và nó không bao giờ nhập đường cong. Ba chương trình đã có một hướng dẫn quản trị viên vào ngày 2026-09-09 để trả lại nó, và CLMM theo sau vào ngày 2026-09-30: Địa chỉ nằm trong reference/program-addresses. Stable AMM không có tương đương. Không có gì ở đây ảnh hưởng đến một LP hoặc một nhà giao dịch. Các hướng dẫn này di chuyển lamports và chỉ lamports. Số dư token, dữ liệu tài khoản, chủ sở hữu, trạng thái pool, cung cấp LP, bộ đếm phí và đường cong đều không bị chạm, và không có cái nào trong số chúng có thể đóng một tài khoản. Báo giá của một pool cho một swap giống hệt nhau trước và sau một lần quét. Không có hành động phía người dùng, không có lựa chọn tham gia, và không có thời hạn.

Ba hình dạng tài khoản mà mỗi chương trình xử lý

Tất cả bốn đều tuân theo cùng một điều phối, trên chủ sở hữu tài khoản nguồn:
  • Một tài khoản token hoặc mint do một PDA quyền hạn chương trình sở hữu: chương trình CPIs hướng dẫn WithdrawExcessLamports của chương trình token (discriminant 38), ký như PDA đó. Trong CLMM, PDA đó là PoolState chính nó, vì vậy một cuộc gọi bao gồm vaults của một pool.
  • Một vault SOL được bao bọc — WithdrawExcessLamports từ chối các tài khoản gốc, vì vậy chương trình SyncNative trước tiên (cái mà gấp phần dư được quyên góp vào amount được bao bọc), đo lường chính xác bao nhiêu số tiền được bao bọc tăng lên, UnwrapLamports cho delta đó, và sau đó khẳng định số dư được bao bọc quay lại giá trị trước khi đồng bộ hóa của nó. Nếu kiểm tra đó không thành công, toàn bộ hướng dẫn hoàn nguyên với LamportsCalculateError. Đây là lý do tại sao một vault pool phía SOL giữ lại thanh khoản đầy đủ của nó qua một lần quét.
  • Một tài khoản trạng thái do chương trình sở hữu — AmmInfo, PoolState, AmmConfig, ObservationState, một PlatformConfig, một CLMM TickArrayState, v.v. Một chương trình có thể ghi nợ các tài khoản của riêng nó trực tiếp, vì vậy nó di chuyển số dư xuống rent.minimum_balance(data_len) mà không có CPI nào cả.
Các tài khoản do bất cứ điều gì khác sở hữu được bỏ qua im lặng, vì vậy chuyển một tài khoản không liên quan là vô hại thay vì chết. Chuỗi SOL được bao bọc đáng để sao chép nếu bạn giữ các tài khoản gốc của riêng bạn: đó là cách duy nhất để lấy phần dư ra khỏi một tài khoản wSOL mà không thay đổi những gì tài khoản báo cáo là số dư token của nó.
Các đường dẫn này phụ thuộc vào chương trình token được triển khai, không phải phiên bản crate. Tất cả bốn chương trình mã hóa tay các hướng dẫn token — một byte 38 duy nhất cho WithdrawExcessLamports, 45 cộng với COption<u64> cho UnwrapLamports — và gửi chúng đến chương trình token bất kỳ sở hữu tài khoản nguồn. Cả hai hướng dẫn đều tồn tại trong các chương trình SPL Token và Token-2022 hiện tại trên mainnet. Một trình xác thực cục bộ hoặc bộ kiểm tra chạy một bản SPL Token được gói cũ hơn không triển khai chúng, và một lần quét chống lại nó không thành công trên một discriminator không xác định thay vì bất cứ điều gì trong chương trình Raydium. Kiểm tra các đường dẫn này chống lại một chương trình token được sao chép từ mainnet.

Những gì vẫn không thể được hoàn lại tại chỗ

Bạn vẫn không thể hoàn lại rent của một vị trí CLMM tại chỗ. Nó quay lại khi vị trí được đóng, như bảng trên nói. CollectExcessLamports của CLMM không kiểm tra ai tài trợ một tài khoản, vì vậy nó có thể lấy phần dư ra khỏi một PersonalPositionState hoặc LimitOrderState. Tài khoản vẫn ở mức tối thiểu rent của nó, và đó là mức tối thiểu mà close hoàn lại. Tương tự đối với mint cơ sở LaunchLab: hướng dẫn khởi tạo thu hồi MintTokens trong cùng cuộc gọi mà nó mint cung cấp, vì vậy không có khóa nào có thể bao giờ ký một WithdrawExcessLamports cho mint đó và rent của nó bị mắc kẹt bằng thiết kế.

Bạn nên hoàn lại ngay bây giờ hay chờ đợi?

Cả hai đều tốt, và sự khác biệt là nhỏ bằng cách nào:
  • Phần dư không đi đâu. Nó nằm trong các tài khoản của bạn. Không có gì hết hạn, không có gì bị quét, không có thời hạn nào áp dụng.
  • Chờ đợi kép. Mỗi bước phát hành thêm từ các tài khoản tương tự, và một lần quét sau bước 5 chi phí tương tự trong phí như một lần quét hôm nay.
  • Hoàn lại ngay bây giờ không từ bỏ các bước sau. Một tài khoản bạn quét hôm nay chỉ đơn giản là ở mức tối thiểu hiện tại; bước tiếp theo làm cho nó bị tài trợ quá mức lại và bạn có thể quét nó lại.
Chi phí thực sự duy nhất của việc hoàn lại sớm là phí cơ sở, và chi phí thực sự duy nhất của việc chờ đợi là lamports vẫn bất động lâu hơn một chút.

Đọc thêm

SIMD-0437

Đề xuất chính nó — năm cổng tính năng và lý do cho việc bước giảm.

Giảm rent

Trang triển khai của Solana: bước hiện tại, lịch trình, và những gì thay đổi cho các tài khoản mới.

Giảm rent: một phân tích được hỗ trợ bởi dữ liệu

Kinh tế, và rủi ro tăng trưởng trạng thái mà triển khai từng bước được thiết kế để quản lý.

Account model

Cách các tài khoản Solana được tài trợ, sở hữu, và đóng — nền tảng cho mọi thứ ở trên.