# Review Info Reviewer: Maciej Zielinski Reviewed repositories: * `uniswap-v2-core-casper` at `de4cefcbdca96091eae59659d584747d416e717e` hash. * `uniswap-v2-router-casper` at `9f464a634d50d4ab30a25effed636b27efbb80bf` hash. # Issues ## [Low] 1. Repository size. The `uniswap-v2-core-casper` repository is 1GB large. It should be squashed. ## [Medium] 2. Duplicated `utils` in the code of the smart contract. The whole core repository has a lot of duplicated code in utils. My strong recommendation is to merge that into a single crate. ## [Low] 3. The test code is hard to work with. Each crate implements its own testing suit. It is difficult to define complex scenarios using existing code. All the test code should be refactored to be usable between crates, or moved into one testing crate. ## [High] 4. `wcspr` crate is missing tests. The `wcspr` crate is missing tests for CSPR withdrawal and deposit. It is also lacking a reference code that shows how to interact with the contract to withdraw and deposit CSPR tokens. ## [High] 5. Use `unwrap_or_revert`. All the occurrences of `unwrap()` method in a smart contract code is incorrect. `unwrap_or_revert` should be used instead. ## [High] 6. Missing events. Smart contracts are missing events, which are essential in understanding the blockchain state. Casper doesn't come with built-in events, but those can be implemented using dictionaries. An example of such is [cep47] (https://github.com/casper-ecosystem/casper-nft-cep47/pull/19). ## [High] 7. Missing factory pattern. Factory contract takes the Pair contract address as an argument. Instead, the Pair contract should be deployed from within the Factory contract. Right now it's possible to trick users into calling arbitrary contracts and that's a security issue. The Pair contract could expose one additional entrypoint (eg. `new_instance`) that creates a new instance of contract package hash and returns its package hash and access token for the Factory contract to handle. # Summary In the current state, the code is not yet production-ready. All the `high` issues must be fixed and then the code should be reviewed again. All the `medium` and `low` issues can be treated as a suggestion for code quality improvement.