- Join Sherlock Discord
- Submit findings using the issue page in your private contest repo (label issues as med or high)
- Read for more details
Optimism
Q: 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?
Yes, we are only allowing whitelisted tokens to work with the codebase. These will be standard ERC-20 tokens. We won't be allowing any fee-on-transfer or non-standard ERC-20 tokens. We will also integrate USDC and USDT.
Q: Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
function setBlocksPerEpoch(uint64 _blocksPerEpoch) external onlyOwner {
blocksPerEpoch = _blocksPerEpoch;
emit BlocksPerEpochUpdated(_blocksPerEpoch);
}
blocksPerEpoch will not be set as something excessively large so as to make the zk proof computation too expensive per user. 6 hours - 1 day worth of blocks would be reasonable. This would be computed in blocks however.
Q: Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No
Q: For permissioned functions, please list all checks and requirements that will be made before calling the function.
- createDistribution Function Modifiers:
nonReentrant: Prevents reentrancy attacks.
Checks and Requirements:
Start Block Number: _startBlockNum > block.number Distribution Duration: (_endBlockNum - _startBlockNum) <= MAX_DISTRIBUTION_BLOCKS Distribution Amount: _amount > 0 Multiples of Blocks per Epoch: (_endBlockNum - _startBlockNum) % blocksPerEpoch == 0 Whitelisted Reward Token: isWhitelistedRewardToken[_rewardToken] == 1 Sufficient Token Allowance: IERC20(_rewardToken).allowance(msg.sender, address(this)) >= _amount Protocol Fee Recipient: protocolFeeRecipient != address(0)
- claimTest and handleProofResult Functions Modifiers: None Checks and Requirements:
Valid Verification Key Hash: vkHashes[_vkHash] Valid Claim Period: startBlock < endBlock && (endBlock - startBlock) % blocksPerEpoch == 0 Claim Period Within Distribution Range: startBlock >= params.startBlockNumber && endBlock <= params.endBlockNumber Matching Distribution Parameters:
lpTokenAddress == params.hypervisor rewardTokenAddress == params.rewardToken distributionAmountPerEpoch == params.distributionAmountPerEpoch
Non-Zero Reward: totalRewardAmount > 0 No Double Claiming: claim.amount == 0
- Governance Functions (OnlyOwner) Modifiers:
onlyOwner: Restricts function execution to the contract owner
Functions and Requirements:
addVkHash/removeVkHash: No additional checks setBlocksPerEpoch: No additional checks setProtocolFee: _protocolFee < BASE_9 toggleTokenWhitelist: No additional checks setProtocolFeeRecipient: No additional checks
Situations Where Functions May Not Be Used: claimTest: This function may be used for testing purposes. In production, handleProofResult would likely be the primary function, with claimTest being removed. claimTest was made external just for the purposes of testing.
Q: Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
ERC20 (for safe token transfers and approvals via SafeERC20)
Q: Are there any off-chain mechanisms for the protocol (keeper bots, arbitrage bots, etc.)? We assume they won't misbehave, delay, or go offline unless specified otherwise.
Yes
A prover system that generates Brevis proofs, as indicated by:
Use of BrevisApp and IBrevisProof interfaces handleProofResult and vkHash verification functionality Proof validation for claiming rewards
Q: 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?
Assumption should be that Sequencer won't misbehave
Key invariants from the contract code:
Total distributed rewards must match initial deposit minus protocol fees Users cannot claim more rewards than allocated per distribution period Same rewards cannot be claimed twice (enforced by claim tracking) Distribution parameters (hypervisor, token, amounts) must remain immutable once set
- Epoch-based distributions
- uses block numbers instead of timestamps for precision
- block times could be inconsistent with actual times, but we're using blocks for precision
- Proofs can only prove valid participation/eligibility but cannot prove non-participation. This means:
- Valid rewards can be proven and claimed
- System cannot prevent omission of eligible addresses from rewards
- Relies on off-chain prover to include all eligible addresses
Flow from the user perspective: 1.) Via offchain calls on frontend, the user calls initiates a zk-proof and sends an onchain request to Brevis App 2.) Brevis will call the callback function "handleProofResult" (claimTest is a public function which simulates this just for testing purposes, and would not be called by Brevis in production)
- System cannot prevent omission of eligible addresses from rewards
- Relies on off-chain prover to include all eligible addresses (any rpc issues are deemed acceptable)
Q: We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
No
NA
https://docs.brevis.network/developer-guide/brevis-app-workflow
NA.