Introduction
We express our gratitude to the Palladium team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Palladium is a stablecoin protocol that is operated and scaled upon Bitcoin. PUSD is a censorship-resistant USD-pegged cryptocurrency that is backed by security and robustness of Bitcoin.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Palladium |
| Audited By | Stepan Chekhovskoi, Ali Ashar |
| Approved By | Ataberk Yavuzer, Olesia Bilenka |
| Website | https://palladiumlabs.org→ |
| Changelog | 17/06/2025 - Preliminary Report |
| 25/06/2025 - Final Report | |
| Platform | Botanix |
| Language | Solidity |
| Tags | ERC-4626 Vault, Decentralized Finance |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Palladium
- Audited By
- Stepan Chekhovskoi, Ali Ashar
- Approved By
- Ataberk Yavuzer, Olesia Bilenka
- Website
- https://palladiumlabs.org→
- Changelog
- 17/06/2025 - Preliminary Report
- 25/06/2025 - Final Report
- Platform
- Botanix
- Language
- Solidity
- Tags
- ERC-4626 Vault, Decentralized Finance
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/PalladiumLabs/palladium-stability-vault→ |
| Initial Commit | 98c6f3ae9b496697a7e9822917f3dd7d60893bcc |
| Remediation Commit | ba711bcb2d625b1bebed2dc7626407a1dac37271 |
Review Scope
- Initial Commit
- 98c6f3ae9b496697a7e9822917f3dd7d60893bcc
- Remediation Commit
- ba711bcb2d625b1bebed2dc7626407a1dac37271
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements covers basic contract functionality without detailed explanations.
Project setup instructions are not provided.
NatSpec comments are missing for most of the code.
Code quality
Commented code lines identified.
Development dependency
forge-std/console.solfound.The code does not use power of modifiers and use functions instead (
_checkOwner,onlyVault,onlyManager).The contracts lack storage gaps for upgrade functionality.
Missing events for certain configuration functions.
Contracts separation does not held for abstraction layers.
Typos, inconsistencies in
internalfunctions naming found.The repository mixes Hardhat and Foundry development environments.
Floating
openzeppelin-contracts-upgradeabledependency version.
Test coverage
Code coverage of the project is 15% (branch coverage).
Few tests covering deployment and basic interactions by a single user are provided.
System integrations with external protocols are not thoroughly tested.
System Overview
Palladium, at its core, is a collateralized debt protocol. Anyone can mint PUSD using their BTC and get instant access to interest-free liquidity.
The following contracts are included in the audit scope:
Rivera Auto Compounding Vault V2 - ERC-4626 Vault, which delegates all the deposited funds to external Strategy. Strategy is expected to be part of the system and be controlled by the same team. The contract delegates the manager setup and pause functionality to the Strategy. Strategy update mechanism is implemented in two steps with a guaranteed time window between the new Strategy proposition and the upgrade.
Stability Vault - Strategy contract allowing unlimited deposits and withdrawals for the registered Vault. Any deposited funds are converted to a certain token in two steps and then deposited into the Stability Pool, which is expected to produce incentives. Most of actions require a trigger from the system manager. The contract is upgradeable and pausable.
Fee Manager - Support contract providing a few state variables over Abstract Strategy V2.
Abstract Strategy V2 - Support contract providing manager setup functionality.
The contracts do not include an incentive-earning mechanism; therefore, the mechanism is not covered by the audit.
Privileged roles
The Owner of the Stability Vault is allowed to upgrade the contract.
The Manager of the Stability Vault is allowed to set the new manager, pause/unpause the contract, set the oracle address, set the allowed collaterals, trigger earning in the Stability Pool, set the pool for on-chain swaps, and withdraw stuck tokens.
The Owner of the Rivera Auto Compounding Vault V2 is able to set the total deposit cap, propose the new Strategy, and trigger the upgrade, withdraw stuck tokens.
The Manager of the Strategy used in the Rivera Auto Compounding Vault V2 is able to propose the new Strategy.
Potential Risks
Single Points of Failure and Control: The project is mostly centralized, introducing single points of failure and control. Authorized actors are able to change various parameters including critical configuration which may cause denial of the system. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.
Flexibility and Risk in Contract Upgrades: The project's contracts are upgradeable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.
Arbitrary Oracle Address Setting by Admin: Allowing the admin to set oracle addresses without constraints or verification mechanisms introduces the risk of incorrect or malicious oracle selection, affecting the accuracy of data and potentially leading to financial losses.
System Reliance on External Contracts: The functioning of the Stability Vault significantly relies on out of the audit scope Stability Pool contract and several external DeFi protocols. The functioning of the Rivera Auto Compounding Vault V2 significantly relies on Strategy contract which might be in-scope Stability Vault or alternative out of the audit scope Strategy. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.
Potential Race Conditions: The both Rivera Auto Compounding Vault V2 Owner and Strategy Manager are able to propose the new Strategy candidate. In case of decision making fault, the Strategy Manager is able to effectively block Strategy update continuously providing new candidates within the Strategy candidate approve time window.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1102 | Inability to Upgrade Contract due to Uninitialized Owner | fixed | High | |
| F-2025-1096 | Users Lose Deposits due to Inflation Attack | fixed | High | |
| F-2025-1103 | Inconsistent Shares Rate due to Invalid Strategy Balance Calculations | accepted | Medium | |
| F-2025-1103 | EIP-4626 Violation | accepted | Medium | |
| F-2025-1103 | Lack of ERC20 Operation Success Validation | fixed | Medium | |
| F-2025-1102 | Storage Collision due to Lack of Storage Gaps | fixed | Medium | |
| F-2025-1101 | Inability to Update Strategy due to Strategy API Incompliance | fixed | Medium | |
| F-2025-1090 | Possible Invalid Swap Rate due to Lack of Oracle Output Validation | fixed | Medium | |
| F-2025-1103 | Lack of Initializers Disable in Upgradeable Contracts | fixed | Low | |
| F-2025-1103 | Initializer in Non-Upgradeable Contract | accepted | Observation |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/PalladiumLabs/palladium-stability-vault→ |
| Initial Commit | 98c6f3ae9b496697a7e9822917f3dd7d60893bcc |
| Remediation Commit | ba711bcb2d625b1bebed2dc7626407a1dac37271 |
| Litepaper | https://docs.palladiumlabs.org→ |
| Requirements | https://github.com/PalladiumLabs/Palladium-SmartContracts/blob/main/README.md→ |
| https://github.com/PalladiumLabs/palladium-stability-vault/blob/main/README.md→ | |
| Technical Requirements | N/A |
Scope Details
- Initial Commit
- 98c6f3ae9b496697a7e9822917f3dd7d60893bcc
- Remediation Commit
- ba711bcb2d625b1bebed2dc7626407a1dac37271
- Litepaper
- https://docs.palladiumlabs.org→
- Technical Requirements
- N/A
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.