Assessment reports>Pye>High findings>Fee can be front-run on deposit/withdraw
Category: Business Logic

Fee can be front-run on deposit/withdraw

High Impact
High Severity
Low Likelihood

Description

When a user deposits into a bond, principal tokens (PTs) and YTs are minted. Some fraction of these tokens are distributed to the fee account, and this percentage is controlled by the deposit_fee_bps setting. This setting is controlled by the fee admin, and they can change it at any moment via the update_fee_settings instruction.

A malicious fee admin could wait for a user to deposit into a bond and then front-run their transaction to set the fees to the maximum. While the update_fee_settings instruction validates that the fee must be under 10_000 BPS, the malicious fee admin could set the fee to 9_999, which would steal most of the tokens from the user.

A similar issue exists when redeeming PTs/YTs for SOL in a solo validator bond, as some amount of SOL is taken as a fee upon withdrawing based on the counter_party_fee_bps setting.

Impact

When depositing, a malicious fee admin could steal pool tokens from an unsuspecting user, receiving almost the full value of their deposit.

When redeeming PTs/YTs for SOL in a solo validator bond, a malicious fee admin could steal almost all of their yield.

Recommendations

For depositing, add instructions that allow users to specify slippage, where they can specify the minimum amount of tokens they expect to receive on deposit.

For withdrawing, require that fee changes only apply after some period of time, so that users cannot be front-run by any changes.

These recommendations are based on the Solana Program Library (SPL) stake-pool implementation.

Remediation

This issue has been acknowledged by Pye in the Sky Labs Ltd., and a fix was implemented in commit 26bd837c.

Zellic © 2025Back to top ↑