An attacker can exploit the system, causing receivers of pointTokens to receive fewer tokens than expected.
When Tadle wants to wrap up trading activities for a marketplace, the owner calls SystemConfig::updateMarket
, which updates the marketplaceInfo for the target marketplace.
Among the variables set is tokenPerPoint
, which determines how many pointTokens a Bidder can receive.
The Issue:
When this variable is set, the amount of pointTokens to be created at the token generation event of the launching protocol is established. However, because the protocol doesn't cease the creation of new offers (i.e., users can still call PreMarket::createOffer
) before the marketplace status updates to AskSettling, new points that weren't factored into the tokenPerPoint
determination are created. These new points are not part of the allocation plans for the launching protocol, making their creation counterproductive to Tadle's operations.
The getMarketPlaceStatus
function clearly shows that the marketplace is still online after SystemConfig::updateMarket
is called.
This situation is problematic because it is not always the intention of an offer maker to create these phantom points that they won't be able to settle. However, regardless of their intentions, someone must bear the inevitable loss if the offer is traded. This issue is similar to the scenario discussed in the submission titled "A Malicious Maker Can Game the System for Risk-Free Profit at the Expense of the Protocol," where a malicious maker causes the protocol to incur losses by leaving the trader of the offer unsettled. These losses fall on the last withdrawers of a specific token in Tadle.
Manual
Once the TGE is set, cease the creation of new offers in the market. No user should be able to call PreMarket::createOffer
after this point.
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.