# ImgnaiPaymentHandler Review

I was engaged by the Imgnai team to review the payments handler contract which they developed. This payments handler allows users to send funds in a subset of approved tokens to a payment address while also emiting an event which allows the offchain tracking of payments.

The codebase was reviewed over the course of 1 working day and has around 100 lines of solidity code. It is intended to run on multiple EVM compatible networks. The code review was preformed on commit hash 6d409311.

### Findings

Findings are presented chronologically:

No security issues were identified. This does not imply none are present but rather that under best effort review none were observed.

### Notes

Very low severity, gas notes, or other non-issue comments

* Both block timestamp and also block number are emitted by the contract, since the block's timestamp is constant throughout the block they can be costlessly mapped one to one offchain and so only emitting one would save gas. The savings are marginal.
* The lack of other inputs than the uuid such as the msg.sender enables many possible formats of griefing:
* A user who sends a transaction paying some non trivial amount to a uuid for an order may, depending on the offchain infrastructure, may be front run by a user paying a trivially small amount such as 1 wei. If not accounted for this could cause a non payment error in the offchain system.
* A user could send a uuid on one network (eg mainnet) and then a second user could send some amount of funds to the same uuid on a second network in attempt to intentionally trigger a bug.
* If the order identification string contains some data which identifies users and is parsable users can construct uuids which are parsable by the offchain system but trigger some unintended effect offchain. EG: if the format for the order id is like \{user id\}\{prompt id\} then a user could trigger the offchain generation of some unpleasant image in another user's account.
* The lack of minimum payments is likely going to create a situation where users spam low cost networks in hopes of an airdrop or other benefit. This pattern is quite common and would have to be filtered in the offchain infrastructure that the team runs and would likely increase node costs.
* The withdrawToken and withdrawETH are actually secure without having the only owner modifier because they always send funds into the owner controlled paymentsWallet, having functions which may be used more frequently locked to a single admin key with more security critical functions can encourage bad key management, as it needs to be used more.