The functions that update the period (via update_profit_max_unlock_time
) do not implement any explicit replay protection.
An attacker might resubmit an old valid proof to force repeated updates, potentially disrupting the intended update cadence.
High
Manual
You can introduce a private mapping (processedBlockNumbers) that records the block number for which a proof has already been accepted. Both external functions (verifyPeriodByBlockHash and verifyPeriodByStateRoot in ScrvusdVerifierV2 contract) check that the block number hasn’t been processed before proceeding and mark it once processed. Here is the code
// Replay protection: mapping to track block numbers that have already been processed.
mapping(uint256 => bool) private processedBlockNumbers;
- All proof generated within `_proof_rlp` is generated via the off-chain prover, so there is no concrete proof that this proofs are non-unique. - All state roots and proofs must be verified by the OOS `StateProofVerifier` inherited as `Verifier`, so there is no proof that manipulating proofs can successfully pass a price update
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.