# Security Wick is designed with defense-in-depth, ensuring that no single point of failure can compromise user funds. This page covers the protocol's audit history, upgrade controls, and on-chain safety mechanisms. ## Audit Wick has been audited by [Frank Castle](https://x.com/0xcastle_chain), a Rust Solana auditor and security researcher. [View the audit report here](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fgoz7TrqfHhYY9ctaIA3q%2Fuploads%2FqbSjt6vUl0TgeFYFeE2U%2FWick_Final_report.pdf?alt=media\&token=54e48a53-054a-4675-afc9-53acb5ca926f) ## Upgrade Authority The Wick program's upgrade authority is held by a **5-address multisig** that requires **3-of-5 signatures** to approve any program upgrade. This means no single address can push a malicious or accidental upgrade to the protocol, a majority of keyholders must independently sign off on every change. The upgrade authority multisig has a **24-hour timelock** on transaction execution, giving users additional time to review any pending upgrade before it can be applied. **Upgrade Authority Multisig:** `3bAHFKgJx7mHeyo2VmDCGp4QmKxTbPdtF5MfPF16R19P` ## Key Hygiene All signer addresses in both the upgrade authority and admin multisigs are used exclusively for the operation of Wick. They are not shared with other protocols or used for general-purpose transactions. This reduces the risk of cross-protocol key compromise and simplifies on-chain monitoring. ## Admin Timelocks All privileged admin actions in Wick follow a **two-step propose-then-accept pattern** with enforced timelocks. This gives users advance notice and time to withdraw before any change takes effect. The admin key is also held by a **3-of-5 multisig**. **Admin Multisig:** `2oAqxeLqDe55ND3HTrkfHLurZVa4yYHRTuhHwmMHsFrs` ### Admin Key Rotation (48-hour timelock) Transferring the protocol admin role requires two separate transactions: 1. **Propose:** The current admin submits a proposal naming the new admin address. This creates an on-chain `PendingAdmin` record with a timestamp. 2. **Wait 48 hours:** The proposal cannot be accepted until 48 hours (172,800 seconds) have elapsed. 3. **Accept:** After the timelock expires, the proposed admin signs a transaction to accept the role. The current admin can **cancel** the proposal at any time before it is accepted. ### Cranker Key Rotation (24-hour timelock) Rotating the cranker (the off-chain bot that harvests yield) follows the same two-step pattern with a 24-hour timelock. The new cranker must **co-sign** the acceptance transaction to prove ownership of the proposed key. ### Fee Changes (24-hour timelock) Fee updates are proposed by the admin and can only be accepted after a 24-hour waiting period. Fees are capped at a maximum of 10% (1,000 basis points) and cannot exceed this limit regardless of the proposal. ### Harvest Limit Changes (24-hour timelock) Increases to the global harvest-per-window cap require a 24-hour timelock. Decreases take effect instantly, and any pending increase proposal is automatically invalidated when a decrease is applied. ### Stake Pool Changes (24-hour timelock) Changing the underlying stake pool is a high-impact operation that controls all yield calculations. These changes require a 24-hour timelock to give users time to evaluate and exit if needed. ### Monitoring Pending Proposals When an admin proposes a change, the program creates a temporary on-chain account at a fixed address. When the proposal is accepted or cancelled, the account is closed. You can check whether any proposal is active by looking up these addresses on any Solana explorer (e.g. Solscan, Solana Explorer): | Proposal Type | Address | | ---------------- | ---------------------------------------------- | | Admin Transfer | `AgZpzVQiCAEH9HNqBXWeRjCsYVaNhyNPc1W5auxaUzCV` | | Cranker Rotation | `5tuQNgPWFw6WnhvdDQq4euG2aAqwpcpNPvHrZkTSB11g` | | Fee Change | `59bNA3hmaTe2onF5sWQFUCBTRyX4fvz5aKFKSDeDNi8C` | | Harvest Limit | `7VN6oCXKjxm3VosuydBj2HG8JNsZWu6hm7oKQkVrKqCt` | | Stake Pool | `9urMSD9i5SJHakLJpAoCEezsmyK2LPvgdgiKbfGq4Zmb` | **If an account exists at one of these addresses, a proposal is active.** If the account does not exist, there is no pending change of that type. You can bookmark these addresses and check them periodically, or use a Solana explorer's notification feature to alert you when an account is created at any of these addresses. ## Pause Mechanisms Wick has a two-level pause system: * **Level 1: Pause:** The admin can instantly pause deposits and harvests. Withdrawals and yield claims always remain available so users can exit at any time. * **Level 2: Emergency Pause:** In the event of a critical issue the admin can activate an emergency pause that halts all operations including withdrawals. This pause **automatically expires after 24 hours** to prevent indefinite lockups, and the admin can lift it early. ## Rate Limiting The cranker can **only** extract accrued yield and has no ability to touch user principal. Yield is calculated on-chain from exchange-rate appreciation (the difference between the current stake-pool rate and the position's last-harvested rate), and the cranker cannot influence or override this calculation. Even if the cranker key were compromised, on-chain rate limits further bound the damage: * **Per-call rate increase cap:** The exchange rate can advance by at most 0.1% (10 basis points) per harvest call relative to the position's last checkpoint. This directly bounds how much yield can be extracted from any position in a single call, regardless of position size, and prevents sudden rate manipulation. * **Global rolling-window cap:** Total LST harvestable across all positions is capped within a 2-hour rolling window, limiting aggregate extraction. ## Additional Safety Measures | Mechanism | Purpose | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | | Per-position vault isolation | Limits blast radius, each position's funds are held in a separate vault | | Strict harvest-then-deposit ordering | Cranker must complete each harvest cycle before starting another | | On-chain rate reading | Exchange rate is read directly from the stake pool on-chain, not supplied by the cranker, preventing rate manipulation | | Checked arithmetic | All math uses `checked_add/sub/mul/div` with u128 intermediates to prevent overflows | | Token-2022 compatibility | All transfers use `transfer_checked` via the token interface | | Account distinctness checks | Prevents duplicate mutable account attacks | | SOL balance checks around CPI | Detects unexpected lamport drain during cross-program calls | | Comprehensive event logging | All admin and security transitions emit on-chain events for off-chain monitoring | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.lantern.one/wick/security.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.