Quantstamp reviewed NeoSwap on 13 Dec 2022: 15 findings, 0 critical; 12 marked fixed, 3 open.
Report hosted on certificate.quantstamp.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 0 |
| Medium | 0 | 0 | 1 |
| Low | 3 | 0 | 11 |
In the function `claim_sol()`, an error can be raised with a message that does not describe the situation accurately: * the error `SumNotNull` is raised instead of an error mentioning that there is an insufficient amount of lamports in the escrow. * the error `NotReady` is raised instead of the error `NoSend`. Additionally, the message of the error `UnexpectedState` (`"The status given is not correct"`) is not always aligned with the situation when that error is raised. It is accurate in the function `init_initialize()` when it describes an object sent by the user. However, it can also describe objects currently stored in the swap data account. In that case, the status is not "given" by the user but is already stored on-chain. This is also the case in the functions `initialize_add()`, `initialize_add()`, `cancel_sol()`, `deposit_nft()`, `deposit_sol()` and `validate_deposit()`. These discrepancies could negatively affect troubleshooting.
It is important to validate inputs, even if they only come from trusted addresses, to avoid human error. In particular: 1. the addresses `owner` and `destinary` of a new item can be the same in the functions `init_initialize()` and `initialize_add()`. 1. items can be accepted with an amount of `0` in the functions `init_initialize()` and `initialize_add()`, because the functions `is_positive()` and `is_negative()` return `false` for a value of `0`. 1. negative `amount` values are accepted in `init_initialize()` in case `is_nft` is `true`. 1. since the `sent_data.items[0]` entry in the `init_initialize()` function is supposed to be the swap fee, Sol deposits with a positive `amount` should probably not be allowed.
Properly verifying the input accounts is one of the most important steps when trying to secure a Solana program. Anchor enforces this by requiring a `/// CHECK:` annotation with the reason for why an account does not use a checked type. The code base uses many unchecked accounts without providing a reason for why no checks are required or what checks are performed manually, requiring to build with the `--skip-lint` flag.
The report names a repository or files. Open the report to see its scope.
Repository and files the report names (1)
236 projects reviewed · 332 reports · latest Oct 2026
See Quantstamp’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us