There is an issue of frontrunning in the protocol. In the contract ProxyFactory, there are public functions that can deploy the proxy and distribute the tokens in the protocol, when this function is triggered by a transaction via owner or organizer, it can be frontrun by the attacker before the transaction is mined in the block.
Ethereum nodes pool transactions and form them into blocks. The transactions are only considered valid once a miner has solved a consensus mechanism. The miner who solves the block also chooses which transactions from the pool will be included in the block, this is typically ordered by the gasPrice of a transaction. Here lies a potential attack vector. An attacker can watch the transaction pool for transactions that may contain solutions to problems. The attacker can then get the data from this transaction and create a transaction of their own with a higher gasPrice and get their transaction included in a block before the original. E.g This can happen with functions like
This can potentially distribute the funds to the wrong addresses stipulated by the attacker.
Manual Analysis
Create logic in the contract that places an upper bound on the gasPrice. This prevents attackers from increasing the gasPrice and getting preferential transaction ordering beyond the upper-bound. Secondly, Implement a commit-reveal scheme, whenever possible. Such a scheme dictates users send transactions with hidden information (typically a hash). After the transaction has been included in a block, the user sends a transaction revealing the data that was sent (the reveal phase). This method prevents both miners and attackers from frontrunning transactions as they cannot determine the contents of the transaction.
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.