nessben
commented
1 year ago Downgraded to Low severity as this is a product design decision, not a protocol issue. There is no reason to limit this use case at the protocol level, this is something we will manage on the front end. Advanced users directly interacting with the protocol may want to keep a validity almost equal to expiry and decide to cancel the order if it does not fit them anymore.
Tajobin
medium
It is possible to match contracts that expire in the next block
Summary
There is no constraint on the difference between validity and expiry. This could lead to orders being created that have a very small time between when they are matched and expire.
Vulnerability Detail
Currently a contract could be created where expiry is 1 second from validity. This contract could be matched one block before it ends.
Impact
The impact would be that a contract can be matched by a Bull with a close to guaranteed profit for a Bull and loss of a Bear.
Code Snippet
https://github.com/sherlock-audit/2022-11-bullvbear/blob/main/bvb-protocol/src/BvbProtocol.sol#L771-L812
Tool used
Manual Review
Recommendation
Any contract where expiry-validity < minimum time is either a mistake or a result of a user not understanding what validity and expiry parameters are. I would recommend a reasonable minimum to make such contracts impossible to match.