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 →
Mỗi chương trình Raydium đều có ít nhất một vai trò có quyền hạn — một khóa có thể nâng cấp chương trình, tạo cấu hình mới hoặc rút phí giao thức. Giảm thiểu những gì các vai trò này có thể làm (và đặt chúng phía sau multisig có độ trễ) là phòng thủ chính chống lại admin bị xâm phạm. Trang này liệt kê các vai trò và cách chúng được bảo mật trong thực tế.

Vai trò theo chương trình

AMM v4

CPMM

Việc thu thập phí người tạo không giới thiệu vai trò có quyền hạn. CollectCreatorFeePermissionless chấp nhận bất kỳ người trả tiền nào, ràng buộc chủ sở hữu người nhận với PoolState.pool_creator, và ràng buộc cả hai đích đến với ATA chính tắc của người tạo đó. Người gọi có thể tài trợ cho ATA bị thiếu và kích hoạt quét nhưng không thể chuyển hướng phí.

CLMM

Giữ PDA Permission cho phép quyền hạn của nó gọi CreatePermissionedPool — tạo các pool bổ sung cho một cặp đã có một pool chính tắc, mỗi cái ở một địa chỉ dẫn xuất seed_index riêng biệt. Quyền được giới hạn chỉ trong việc tạo pool: nó không thể di chuyển quỹ, thay đổi phí hoặc chạm vào bất kỳ pool hiện có nào. Thu hồi nó (ClosePermissionPda) ngăn quyền hạn tạo thêm pool nhưng để lại các pool đã tạo không bị ảnh hưởng. limit_order_admin là một vai trò hoạt động cố ý hẹp. Nó tồn tại để một keeper ngoài chuỗi có thể quét các lệnh đã điền mà không cần chủ sở hữu lệnh phải trực tuyến. Khóa keeper nóng (sống trên VM keeper) và được xoay vòng độc lập với các multisig ở trên. Cụ thể, quyền hạn keeper được giới hạn trong:
  • SettleLimitOrder — đẩy đầu ra đã điền của một lệnh đến ATA của chủ sở hữu ở giá giới hạn của lệnh.
  • CloseLimitOrder — đóng tài khoản lệnh đã giải quyết hoàn toàn để lấy lại tiền thuê (tiền thuê đi đến chủ sở hữu lệnh).
Nó không thể gọi OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, thay đổi bất kỳ trường pool nào hoặc ký cho bất kỳ lệnh nào khác — những kiểm tra này được thực thi trên chuỗi bằng các ràng buộc seed và has_one trong struct Accounts của lệnh. Một keeper bị xâm phạm có thể tệ nhất là không khả dụng (các lệnh vẫn đỗ cho đến khi chủ sở hữu giải quyết chúng) hoặc giải quyết/đóng các lệnh có thể điền hợp lệ không theo thứ tự; nó không thể di chuyển quỹ người dùng đến bất kỳ nơi nào khác ngoài nơi chủ sở hữu đã ủy quyền cho chúng.

Farm v6

Các farm riêng lẻ không có admin giao thức — mỗi người tạo farm chỉ kiểm soát farm của họ, và quyền hạn của người tạo bị giới hạn (không thể chiếm đoạt cổ phần người dùng, không thể thay đổi mint cổ phần).

LaunchLab

Danh sách cho phép admin nền tảng tự hạn chế: nó giới hạn những tài khoản GlobalConfig nào mà các launch dưới nền tảng đó có thể sử dụng. Nó không cấp quyền hạn trên các nền tảng khác hoặc quỹ launch hiện có. Các địa chỉ quyền hạn được ủy quyền chính tắc sống trong reference/program-addresses.

Quyền hạn nâng cấp chương trình

Các chương trình của Raydium sử dụng cơ chế nâng cấp BPF Loader v3 tiêu chuẩn của Solana. Quyền hạn nâng cấp cho tất cả các chương trình là multisig Squads 3/4. Tại sao 3/4: đủ người ký để một sự xâm phạm duy nhất là không đủ; ít đủ để phối hợp một bản nâng cấp hợp pháp là dễ quản lý. Bốn quyền hạn là độc lập, những người ký thiết bị lạnh được cách ly không khí được giữ bởi các thành viên nhóm cốt lõi. Ký tuần tự ngăn chặn phê duyệt song song trên cùng một giao dịch; các giao dịch mang cửa sổ hết hạn cố định. Các hoạt động multisig được xem xét định kỳ hợp tác với Chương trình STRIDE của Solana (Asymmetric Research).

Xóa quyền hạn nâng cấp

Raydium chưa đặt quyền hạn nâng cấp của bất kỳ chương trình nào thành null. Giao thức hoạt động theo nguyên tắc rằng các chương trình cần có khả năng nâng cấp (để vá lỗi, thêm tiện ích mở rộng như Token-2022, sửa chữa sự trôi dạt tích hợp). Sự đánh đổi: người dùng tin tưởng rằng multisig 3/4 sẽ chỉ triển khai các bản nâng cấp được xem xét kỹ lưỡng. Không có chương trình Raydium nào hiện đang bị đóng băng hoặc chuyển động chậm đủ để được coi là một lựa chọn thay thế bất biến — AMM v4, về mặt lịch sử là tĩnh nhất trong số chúng, chính nó đã được triển khai lại vào 2026-07-22. Slot được triển khai lần cuối cho mỗi chương trình là công khai; đọc nó trước khi giả định bất kỳ chương trình nào là không hoạt động: (Từ tài khoản ProgramData của mỗi chương trình; solana program show <PROGRAM_ID> báo cáo cùng một slot.)

Quyền hạn AmmConfig

Mỗi lần tạo AmmConfig mới được phép — multisig kho bạc 3/5 ủy quyền các tầng phí mới và khoảng cách tick. Các pool hiện có tham chiếu AmmConfig của chúng bằng PDA; tầng phí của pool là bất kỳ AmmConfig nào nói. Các admin có thể thay đổi AmmConfig hiện có không? Có, về mặt kỹ thuật. updateAmmConfig có thể được gọi bởi admin. Trong thực tế, các sửa đổi đối với AmmConfigs được triển khai được tránh vì nó thay đổi kinh tế của tất cả các pool sử dụng cấu hình đó một cách âm thầm. Chính sách giao thức là tạo AmmConfig mới cho bất kỳ thay đổi nào và di chuyển. Các admin có thể đánh cắp phí giao thức thông qua cấu hình không? Không — AmmConfig chứa các tham số phí nhưng không phải người nhận phí giao thức; đó là một địa chỉ bất biến riêng biệt cho mỗi pool.

Yêu cầu phí giao thức

Một phần của phí swap (thường là 3–12 bps của 25 bps phí swap, tùy thuộc vào cấu hình) tích lũy vào vault phí giao thức. Multisig có thể rút các phí tích lũy này. Người dùng không bao giờ thấy số dư LP của họ thay đổi từ điều này — đó là phần được phân bổ trước của giao thức, không phải tiền LP.

Quyền hạn người tạo farm

Farms v6 cấp cho người tạo quyền lực:
  • Tài trợ cho vault phần thưởng (thêm nhiều token hơn).
  • Mở rộng lịch trình (đẩy thời gian kết thúc muộn hơn).
  • Gọi withdrawReward sau thời gian kết thúc để lấy lại số dư vault chưa sử dụng.
Người tạo farm không thể:
  • Rút cổ phần LP của người dùng.
  • Thay đổi mint cổ phần.
  • Thay đổi tỷ lệ phát hành theo hướng ngược lại (chỉ hướng tới thông qua setRewards).
  • Đóng băng thu hoạch người dùng.
Một người tạo farm độc hại có thể tệ nhất là tài trợ không đủ cho vault để farm chạy hết; cổ phần chính của người dùng luôn an toàn.

Cấu hình multisig Squads

Raydium hoạt động hai multisig Squads riêng biệt cho các bề mặt rủi ro khác nhau. Cả hai đều có thể được kiểm tra trên chuỗi thông qua giao diện người dùng Squads Protocol. Các thuộc tính hoạt động của multisig nâng cấp:
  • Timelock 24 giờ trên bất kỳ giao dịch nào. Một bản nâng cấp được phê duyệt hôm nay thực thi không sớm hơn 24 giờ sau, cho người dùng thời gian để phản ứng.
  • Ký thiết bị lạnh được cách ly không khí. Các thiết bị lạnh có thẻ mạng bị loại bỏ vật lý; chúng chỉ kết nối với ví phần cứng và đọc dữ liệu giao dịch thông qua mã QR từ một thiết bị nóng riêng biệt.
  • Ký tuần tự. Chỉ sau khi một thiết bị lạnh tạo và ký một giao dịch, thiết bị lạnh tiếp theo mới có thể bắt đầu quá trình ký của nó — ngăn chặn các chữ ký xung đột hoặc song song trên cùng một giao dịch.
  • Hết hạn giao dịch. Mỗi giao dịch mang cửa sổ hết hạn cố định, vì vậy các giao dịch cũ tự động vô hiệu.
  • Thực thi TOTP + khóa vật lý trên các thiết bị nóng được sử dụng để bắt đầu giao dịch và phát sóng trên chuỗi.
  • Hàng đợi giao dịch công khai. Bất kỳ ai cũng có thể theo dõi các bản nâng cấp đang chờ xử lý trên giao diện người dùng Squads.
Multisig kho bạc không có timelock — phạm vi của nó hẹp hơn và các hoạt động thường xuyên (tạo AmmConfigs, quét phí) cần hạ cánh cùng ngày. Multisig kho bạc cũng giữ quyền hạn admin chương trình hạn chế được liệt kê trong các bảng mỗi chương trình ở trên; đây là một sắp xếp tạm thời và được xem xét định kỳ với các đối tác bảo mật của dự án.

Xác minh quyền hạn trên chuỗi

Cách đơn giản nhất để xác minh quyền hạn nâng cấp hiện tại của chương trình:
Đầu ra bao gồm:
Nếu Authority không phải là địa chỉ multisig Squads dự kiến, có điều gì đó không ổn. Raydium xuất bản các địa chỉ quyền hạn dự kiến trên reference/program-addresses. Đối với các vai trò admin AmmConfig / pool, tìm nạp tài khoản trên chuỗi và giải mã:
AmmConfig không có trường admin — admin chương trình là pubkey được biên dịch vào chương trình (crate::admin::ID), và các quyền hạn hoạt động mỗi cấu hình là protocolOwner / fundOwner. Quyền hạn nâng cấp BPF là một mối quan tâm riêng biệt ở cấp loader; đọc nó bằng solana program show.

Các thay đổi quyền hạn lịch sử

Những cân nhắc phía người dùng

Bạn nên làm gì như một người dùng/LP/tích hợp?
  1. Kiểm tra quyền hạn nâng cấp trước khi phân bổ lớn. Xác nhận nó khớp với multisig được ghi chép.
  2. Theo dõi hoạt động multisig. Giao diện người dùng Squads hiển thị các giao dịch đang chờ xử lý; một bản nâng cấp được lên lịch cho bạn 24 giờ để thoát nếu bạn không đồng ý với thay đổi.
  3. Chiến lược chuộc lại nhận thức về time-lock. Nếu bạn đang chạy một auto-compounder, hãy đảm bảo đường dẫn thoát của bạn không yêu cầu một lệnh đang được thay đổi.
  4. Đừng giả định tính bất biến của chương trình. Mỗi chương trình Raydium có thể được nâng cấp; hãy lên kế hoạch cho nó.

Những cạm bẫy cho các tích hợp

1. Caching địa chỉ quyền hạn

Nếu bạn hardcode địa chỉ quyền hạn nâng cấp hoặc multisig admin trong mã của bạn và nó sau đó xoay vòng, xác minh của bạn sẽ thất bại. Tìm nạp từ reference/program-addresses tại thời gian chạy hoặc làm mới định kỳ.

2. Giả định AmmConfigs ổn định

AmmConfig mới có thể được tạo bất kỳ lúc nào. Bộ tổng hợp/router của bạn nên tìm nạp lại danh sách cấu hình đầy đủ định kỳ (hàng giờ là được).

3. Vectơ đau khổ người tạo farm

Nếu bạn đang gửi tiền vào một farm có danh tiếng thấp, người tạo có thể kết thúc farm sớm và lấy lại vault phần thưởng (giả sử không có người dùng nào đã cổ phần). Khi người dùng đã cổ phần, các quyền lợi pro-rata được thực thi bởi chương trình; lấy lại chỉ nhận được phần dư sau khi hợp lý kết thúc.

Con trỏ

Nguồn: