Manually reviewed
Proof of Concept (PoC) Implementation:
This PoC includes the following components:
MaliciousBlockHashOracle.sol: A malicious implementation of IBlockHashOracle that always returns a pre-defined stale state root.
MockScrvusdOracle.sol: A mock implementation of IScrvusdOracle to observe the updated parameters.
ScrvusdVerifierV1.sol: The original verifier contract (provided in the initial files).
StaleDataInjectionPoC.sol: A test contract to deploy and execute the PoC, and to easily retrieve the last updated parameters from the MockScrvusdOracle.
poc-script.js: A Hardhat Javascript script to deploy the contracts, execute the PoC, and print the results.
Copy Contract Files: Copy the following Solidity files into the respective directories:
contracts/scrvusd/verifiers/ScrvusdVerifierV1.sol (from the original files)
contracts/scrvusd/verifiers/ScrvusdVerifierV2.sol (from the original files)
contracts/scrvusd/oracles/ScrvusdOracleV2.vy (from the original files - note: Vyper contract, not used directly in PoC but kept for context)
Create contracts/MaliciousBlockHashOracle.sol:
Prioritize Decentralization & Oracle Elimination: Explore on-chain state root verification or decentralized state root aggregation with robust consensus mechanisms.
Implement Decentralized State Root Aggregation: If full on-chain verification is infeasible, utilize multiple independent, decentralized oracles and implement a Byzantine Fault Tolerant consensus mechanism for data aggregation.
Investigate Zero-Knowledge Proofs: Research the application of Zero-Knowledge Proofs to validate state transitions without revealing state data to external oracles.
Develop Economic Incentives & Oracle Game Theory: Design economic incentives and game-theoretic mechanisms to penalize malicious oracles and reward honest behavior within a multi-oracle system.
- Anything related to the output by the `BLOCK_HASH_ORACLE` is OOS per \[docs here]\(<https://github.com/CodeHawks-Contests/2025-03-curve?tab=readme-ov-file#blockhash-oracle>). - The PoC utilizes a mock `BLOCK_HASH_ORACLE`which is not representative of the one used by the protocol - Even when block hash returned is incorrect, the assumption is already explicitly made known in the docs, and the contract allows a subsequent update within the same block to update and correct prices - All state roots and proofs must be verified by the OOS `StateProofVerifier` inherited as `Verifier`, so there is no proof that manipulating block timestamp/block number/inputs can affect a price update - There seems to be a lot of confusion on the block hash check. The block hash check is a unique identifier of a block and has nothing to do with the state root. All value verifications is performed by the OOS Verifier contract as mentioned above
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.