Quantstamp reviewed Rara on 21 Apr 2022: 13 findings, 0 critical; 8 marked fixed, 4 acknowledged, 1 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 | 1 | 4 | 7 |
Executing `info.totalCuratorLiability -= info.referrerCut` in `ReactionVault._spendReaction()` before computing `takerAmount` reduces the taker value.
The rewards for `takers` whenever reactions are spent are stored in the `nftOwnerRewards` mapping. This is a mapping from `rewardsIndex` to the rewards. Since the `rewardsIndex` does not include any information about the address owner, the address that is currently registered as the owner of the NFT will be able to claim the rewards.
The design plan document states: > If an NFT is already registered, trying to re-register will fail. The owner will need to de-register before the register call can be made again. However, the `_registerForOwner` function in `MakerRegistrar` does not check if the NFT is already registered. It simply overwrites the `sourceToDetailsLookup` mapping with the new information.
Many contracts are implemented using the proxy pattern to be upgradeable. As a result, some address that owns the proxy is able to upgrade the contract and completely change its code. Since the new code could be anything, it is important to implement good security practices around the address that is capable of upgrading the contracts.
The report names a repository or files. Open the report to see its scope.
Repository and files the report names (28)
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