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, a Rust Solana auditor and security researcher. View the audit report here

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

Last updated