Fixed Staking Rewards

The current implementation, where contract first accumulates rewards and then rebalances based on SNX price, works well when the token price is falling — as users receive fewer SNX tokens for the same USD value from time A to B.

However, this behavior backfires when SNX price appreciates. For example:

• The rewardRate is updated when SNX is priced at $1.
• One week later, SNX appreciates to $2.
• A user stakes a minimal amount (dust) to trigger an accumulation update.
• The accumulation still assumes SNX is worth $1, resulting in the user receiving double the intended USD value in SNX rewards.

This discrepancy breaks the protocol’s intended 50% APY invariant. Worse, a malicious actor could exploit this to consistently earn more than 50% APY.

In edge cases, if the protocol funds rewards precisely for 50% APY, this mismatch could also cause denial of service (DoS) for new stakers or claimers due to insufficient SNX.

Bias Reward Accounting in Favor of the Protocol

To mitigate this:

• Track the last recorded SNX price.
• If the current price is higher, perform a rebalance first, then accumulate.
• If the current price is lower, accumulate first, then rebalance.

This ensures the reward distribution errs on the side of the protocol, preventing over-rewarding in volatile or upward-trending price conditions.

As per the documentation in the README, SNX expects FixedStakingRewards to be pausable:

Readme:
Pausable : Can be paused in emergency situations

However, the contract inherits from a standard ERC20, not ERC20Pausable, making pause functionality unavailable.

Consider inheriting from ERC20Pausable (or the appropriate pausable base) instead of the standard ERC20, to align with the intended design and allow emergency response via pause.

The contract is expected to ensure that at least 2 weeks’ worth of rewards are available before allowing a deposit:

Currently, the check compares requiredRewards against the full balance of the reward token:

if (requiredRewards > rewardsToken.balanceOf(address(this))) {

This includes unclaimed rewards already allocated to stakers, which can lead to false positives. For example, if some users claim rewards immediately after the stake is accepted, the contract may no longer have enough tokens for the promised 2-week coverage.

Exclude already accrued (but unclaimed) rewards from the balance check.

Could be approximated by subtracting the yield accrued for the pre-stake total supply. (This is an approximation since the rate itself is not constant (in terms of SNX Tokens), and in the past there could have been a different rate than the current one.)

The staking contract is permissionless, anyone is able to stake. As this contract is not made public and the amount of users is expected to be very limited, it might be beneficial to think about adding a whitelist here.

This could be handled easily when the amount of users is very limited and prevents malicious actors from interacting with the system, which decreases the risk of an exploit drastically.

Consider adding a whitelist.

The SNX chainlink price feed on Ethereum has a deviation value of 1% this could lead to the user receiving 1% too much or too less rewards.

Be aware and consider rounding up to 1% against the user.

The SNX chainlink price feed on Ethereum has a heartbeat of 1 day but prices up to 1 day and 1 hour old are accepted. Therefore stale prices are accepted.

Consider reducing buffer from 1 hour to few minutes (10 for example)