Quantstamp reviewed Parity Finance Liquid Staking & Early Purchase (Parity Finance) on 27 Sep 2024: 8 findings, 0 critical; 7 marked fixed, 1 acknowledged.
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 | 0 | 1 | 6 |
The `parity-issuance` and `parity-staking` programs effectively track certain token-related changes locally in state variables such as `total_collateral` and `base_balance`. While there is nothing inherently wrong with tracking these values for program logic, they should not be relied upon as the authoritative source of truth for the actual token balances in vault accounts. Discrepancies may occur because users can transfer tokens directly to vaults, resulting in a mismatch between the tracked state and the actual vault balance. For example: 1. **`deposit_funds.rs` and `withdraw_funds.rs`**: The `total_collateral` field is updated locally in the `token_manager` account, but this value may diverge from the actual vault balance if tokens are transferred directly to the vault. 2. **`unstake.rs`**: The `base_balance` field in the `pool_manager` account is updated via a local variable, but it may not accurately reflect the true balance of the vault. 3. **`initialize_withdraw_funds.rs`**: Withdrawal validations are performed using the stored `total_collateral` value instead of the actual balance in the token account. While local state tracking is beneficial for efficiency and logic within the program, it is important to recognize that these values do not always reflect the real-time balance of vaults and should not be considered definitive for account balances.
When a new slot is encountered, the `current_slot_volume` is updated twice: once in the `check_block_limit` function and again at the end of the handler function. This could lead to incorrect accounting of the current slot volume.
Several token management functions in the parity-issuance program exhibit inconsistencies between the implemented admin checks and the documented behavior. Specifically, these functions are using `token_manager.owner` for admin verification, while the documentation states that `token_manager.admin` should be responsible for these operations. This discrepancy affects the following functions: 1. Adding gatekeepers 2. Removing gatekeepers 3. Updating token manager admin
Several functions across the parity-contracts codebase lack comprehensive input validation for critical parameters. This includes missing checks for non-zero values, absence of bounds validation for numerical inputs such as fees, and lack of verification for account authorities and states. The affected areas span various operations such as staking, unstaking, minting, configuration updates, and token management. Several explicit examples: 1. `parity_staking` doesn't check if the quantity is 0 in the following functions 1. `stake()` 2. `unstake()` 2. `pt_staking` doesn't check if the quantity is 0 in the following functions 1. `pt_stake()` 2. `pt_unstake()` 3. `parity_issuance` doesn't check if the quantity is 0 in the following functions: 1. `deposit_funds()` 2. `withdraw_funds()` 3. `mint_admin()` 4. `mint()` 5. `redeem()`
The `mint` account in the `WithdrawFunds` struct lacks proper validation of its address. This allows an admin to pass in any mint account with an inflated supply, potentially bypassing withdrawal limits.
If a withdrawal is initiated twice before the first one is processed, the second one would overwrite the first one's pending withdrawal amount.
The `new_deposit_cap` can be set to a value less than the existing deposit amount in the vault account, potentially leading to inconsistencies.
The report names a repository or files. Open the report to see its scope.
Repository and files the report names (48)
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