Fee can be front-run on deposit/withdraw
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↗.