This audit focuses on a USDC fee streaming upgrade to our KWENTA staking rewards contract; adding USDC as a second claimable token type on the contract.
Scope
Contest Results
On what chains are the smart contracts going to be deployed?
Contracts are going to be deployed on Optimism.
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
We are allowing only whitelisted tokens to work with the codebase (USDC & KWENTA) that follows the ERC-20 standard.
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
No.
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No.
For permissioned functions, please list all checks and requirements that will be made before calling the function.
unstakeEscrowSkipCooldown(address _account, uint256 _amount)
onlyRewardEscrow
rewardEscrow
contract.onlyRewardEscrow
modifier ensures that only the rewardEscrow
contract can call this function, providing a security layer to prevent unauthorized access._amount
is non-zero and does not exceed the caller's escrowed balance.stakeEscrowOnBehalf(address _account, uint256 _amount)
onlyOperator(address _account)
_account
.onlyOperator
modifier ensures that only approved operators can call this function on behalf of the specified _account
._amount
is non-zero and does not exceed the unstaked escrowed balance of the _account
.getRewardOnBehalf(address _account)
onlyOperator(address _account)
_account
.onlyOperator
modifier ensures that only approved operators can call this function on behalf of the specified _account
.compoundOnBehalf(address _account)
onlyOperator(address _account)
_account
.onlyOperator
modifier ensures that only approved operators can call this function on behalf of the specified _account
.notifyRewardAmount(uint256 _reward, uint256 _rewardUsdc)
onlyRewardsNotifier
rewardsNotifier
contract.onlyRewardsNotifier
modifier ensures that only the rewardsNotifier
contract can call this function, providing secure access control.setRewardsDuration(uint256 _rewardsDuration)
onlyOwner
onlyOwner
modifier ensures that only the contract owner can modify the rewards duration.setCooldownPeriod(uint256 _cooldownPeriod)
onlyOwner
onlyOwner
modifier ensures that only the contract owner can modify the cooldown period.MIN_COOLDOWN_PERIOD
and MAX_COOLDOWN_PERIOD
.pauseStakingRewards()
onlyOwner
onlyOwner
modifier ensures that only the contract owner can pause the staking rewards.unpauseStakingRewards()
onlyOwner
onlyOwner
modifier ensures that only the contract owner can unpause the staking rewards.These are the checks and requirements when calling the permissioned functions of StakingRewardsV2 contract.
Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
The codebase in scope is not expected to comply with any EIPs.
Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?
No.
Are there any hardcoded values that you intend to change before (some) deployments?
New rewardsNotifier will be set at the upgrade to match the new notifier that will also distribute USDC rewards.
If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?
Sherlock should assume that the Sequencer won't misbehave.
Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?
Any potential misbehaviour regarding staking that is not an issue right now but could pose risk in future integrations should be counted, but reported as Low issues.
Please discuss any design choices you made.
No specific design choices were made for this specific upgrade.
Please list any known issues and explicitly state the acceptable risks for each known issue.
Users trust the contract owner to exercise their upgrade and permission capabilities responsibly and to avoid actions that could harm users or the system. Similarly, users place their trust in the operators they designate to act in their best interests and to adhere to the permissions granted to them.
We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
No.
Please provide links to previous audits (if any).
A list of the previous conducted audits can be found here :
Please list any relevant protocol resources.
KIP127 - (https://gov.kwenta.eth.limo/kips/kip-127/)
Removing the staking cooldown and deprecating the threshold will be part of a future release and are not part of this upgrade.
Additional audit information.
If there are no USDC rewards to be distributed then it doesnt count as a denial of service attack.
Total Rewards
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
8,000 USDC
4,500 USDC
400 USDC
600 USDC
Status
Scope
Start Time
End Time
Judging Rules