The function SystemConfig::updateUserPlatformFeeRate
is an owner controlled function.
Assuming the owner is trusted, due to the ways transactions are ordered in the blocks, there is a possible scenario that users have to transfer unexpected token amount to capital pool when they create their taker account by calling PreMarkets::createTaker
function.
Function SystemConfig::updateUserPlatformFeeRate
that update base platform fee rate for a specific user account.
Then when users create their Taker accounts by calling PreMarkets::createTaker
function, the amount of token they have to deposit into capital pool will be calculated based on their platformFeeRate
by calling SystemConfig::getPlatformFeeRate
function.
User A (or a multiple of users) queue up a transaction for creating new Taker account.
The owner queues a transaction to update the platform fee for user A.
User A who transaction get executed after the owners transaction, due to network conditions or miners etc, will have to deposit unexpected amount of token to capital pool.
Manual review.
In the SystemConfig::updateUserPlatformFeeRate
function, we should add new check that user's platform fee rate is zero or not. This will help the owner to make sure that the user already created his Taker account before the update platform fee rate transaction.
The following issues and its duplicates are invalid as admin errors/input validation/malicious intents are1 generally considered invalid based on [codehawks guidelines](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid). If they deploy/set inputs of the contracts appropriately, there will be no issue. Additionally admins are trusted as noted in READ.ME they can break certain assumption of the code based on their actions, and
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.