Open sherlock-admin opened 1 year ago
Agree with this finding. We have noticed some issues with shorter than expected durations for existing markets.
Our proposed fix is to have users specify a start
timestamp and a duration
, which will be used to calculate/set the conclusion. If block.timestamp
is greater than the start
, then the txn will revert. Therefore, users must create the market before the target start time. We may allow this to be bypassed by providing a start time of zero, which would then start the market at the block.timestamp
for the provided duration
.
Given the pre-condition that the transaction needs to be in the mempool for a long time for it to have a significant impact, considering this issue as valid medium
whitehat
high
The createMarket transaction lack of expiration timestamp check
Summary
The createMarket transaction lack of expiration timestamp check
Vulnerability Detail
Let us look into the heavily forked Uniswap V2 contract addLiquidity function implementation
https://github.com/Uniswap/v2-periphery/blob/0335e8f7e1bd1e8d8329fd300aea2ef2f36dd19f/contracts/UniswapV2Router02.sol#L61
the implementation has two point that worth noting,
the first point is the deadline check
The transaction can be pending in mempool for a long time and can be executed in a long time after the user submit the transaction.
Problem is createMarket, which calculates the length and maxPayout by block.timestamp inside it.
After the market is created at wrong time, user can call purchase. At purchaseBond(),
payout value is calculated by term.scale which the market owner has set assuming the market would be created at desired timestamp. Even, maxPayout is far bigger than expected, as it is calculated by very small length.
Impact
Even though the market owner close the market at any time, malicious user can attack the market before close and steal unexpectedly large amount of payout Tokens.
Code Snippet
Tool used
Manual Review
Recommendation
Use deadline, like uniswap