The offerId global variable is used in both the CreateOffer and createTaker functions to generate unique addresses and assign IDs to offerInfoMap and stockInfoMap. However, due to the incorrect sequencing of operations, both an offer and its corresponding taker may end up sharing the same offerId, leading to duplicate IDs and potential conflicts within the system.
The offerId variable is used to generate unique addresses for makerAddr, offerAddr, and stockAddr in the CreateOffer function. After generating these addresses, the offerId is incremented by 1 and stored as the ID in offerInfoMap[offerAddr].id and stockInfoMap[stockAddr].id.
However, in the createTaker function, the offerId is used before being incremented, which results in the same offerId being assigned to both the stock associated with the offer and the stock associated with the taker
This creates a scenario where the stockInfoMap for both the offer and the taker have the same ID, which can lead to conflicts and mismanagement within the protocol.
Same id to different stocks.
Manual Code Review
The offerId should be incremented before or after it is assigned in both the createOffer and createTaker functions.
I believe this is valid low severity, although there is inconsistency here when using the correct `offerId` for assigning offerIds and generating the unique addresses as seen [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L67-L69), this is purely an accounting error for offerIds. If we generate the offerId using current `offerId - 1`, the appropriate listing/taker orders can still be created against those offers.
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.