Introduction
We express our gratitude to the Universal team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Universal is a wrapped asset protocol designed to enable trading for any token, on any chain. The Protocol provides uAssets, wrapped cross-chain compatible tokens that allow developers to integrate deep liquidity and broad asset support into their protocols.
Document | |
---|---|
Name | Smart Contract Code Review and Security Analysis Report for Universal |
Audited By | Stepan Chekhovskoi |
Approved By | Ataberk Yavuzer |
Website | https://universal.xyz→ |
Changelog | 29/04/2025 - Preliminary Report |
08/05/2025 - Final Report | |
Platform | Solana |
Language | Rust |
Tags | Automation, Centralization, Fungible Tokens |
Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Universal
- Audited By
- Stepan Chekhovskoi
- Approved By
- Ataberk Yavuzer
- Website
- https://universal.xyz→
- Changelog
- 29/04/2025 - Preliminary Report
- 08/05/2025 - Final Report
- Platform
- Solana
- Language
- Rust
- Tags
- Automation, Centralization, Fungible Tokens
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
---|---|
Repository | https://github.com/Alongside-Finance/universal-solana→ |
Initial Commit | 459430a11b039a03d77e72e45e7f93b28dd9ff65 |
Remediation Commit | 5c5a8a304b00a44d80409ec4cec99a77b3dea81e |
Review Scope
- Initial Commit
- 459430a11b039a03d77e72e45e7f93b28dd9ff65
- Remediation Commit
- 5c5a8a304b00a44d80409ec4cec99a77b3dea81e
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
The smart contract overview is provided.
The Protocol key roles and features are deeply documented.
Technical requirements such as project setup and build instructions are not provided.
Code quality
The code follows best practices of Solana Programs implementation.
The development environment is configured.
Test coverage
Code coverage of the project is 42% (function coverage).
The program basic scenarios are tested.
Some functions are not covered with tests.
Some negative scenarios are covered.
System Overview
Universal is a wrapped asset protocol designed to enable trading for any token, on any chain. The Protocol provides uAssets, wrapped cross-chain compatible tokens that allow developers to integrate deep liquidity and broad asset support into their protocols.
The audit covers Solana Minting Controller implementation. The Universal Solana program is a program designed to act as a mint authority for Universal Wrapped Assets.
The main features of this program are:
Apply a restriction so Universal tokens can only be minted if the transaction is signed by both an authorized merchant account and an authorized attestation service account
Apply restrictions over the value in USD of tokens that can be minted over the last epoch (12 hours)
Handle roles, add or remove merchants and attestation service accounts, update mint limit, pause operations for specific actors
Token whitelisting, add or remove token support for controlled minting
Token pricing, in order to calculate the USD value of the tokens minted the program needs to know their price, the price is set manually by the owner of the program
Privileged roles
The system Owner is able to upgrade the program.
The system Admin is able to add or remove merchants and attestation service accounts, update mint limit, reset the mint epoch and pause operations for specific actors.
The system Admin is able to whitelist tokens, add or remove token support for controlled minting.
The system Admin is able to set tokens price used to validate the max minted USD value per epoch constraint.
Pair of Merchant and Attestation Service are able to mint arbitrary registered token to any account in bounds of the specified USD mint limit per epoch.
Potential Risks
Arbitrary Tokens Minting: Merchants and Attestation Service are not restricted to mint specific tokens and are able to mint arbitrary registered tokens in the specified USD per epoch mint limits.
Third-Party Freeze Authority: While the Mint Authority is required to be transferred to the program PDA for performing the minting operations, the Freeze Authority might be still controlled by a third-party account posing a risk of user funds freeze.
Centralized Oracles as Data Sources: The protocol utilizes centralized data sources for external info inputs. Dependence on a singular or limited set of data sources can introduce accuracy and manipulation risks, potentially affecting the system operations and decision-making processes.
Single Points of Failure and Control: The project is mostly centralized, introducing single points of failure and control. 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 upgradable, 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.
Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Code out of the audit scope may introduce vulnerabilities indirectly impacting the smart contract security.
Findings
Code ― | Title | Status | Severity | |
---|---|---|---|---|
F-2025-1007 | Mint Limit Bypass due to Unsafe Downcasting | fixed | High | |
F-2025-1021 | Lack of Zero Price Prevention | fixed | Low | |
F-2025-1008 | Mutable Reference of Readonly Structure | fixed | Observation | |
F-2025-1008 | Redundant Deadline & Nonce Functionality | fixed | Observation | |
F-2025-1008 | Redundant State Field | fixed | Observation | |
F-2025-1008 | Missing Account is Writable Constraint | fixed | Observation | |
F-2025-1008 | Instruction Contexts Duplication | fixed | Observation | |
F-2025-1007 | Redundant Account is Writable Constraints | fixed | Observation | |
F-2025-1007 | Immutable Ownership | accepted | Observation |
Identify vulnerabilities in your smart contracts.
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/Alongside-Finance/universal-solana→ |
Initial Commit | 459430a11b039a03d77e72e45e7f93b28dd9ff65 |
Remediation Commit | 5c5a8a304b00a44d80409ec4cec99a77b3dea81e |
Whitepaper | N/A |
Requirements | https://docs.universal.xyz→ |
Technical Requirements | N/A |
Scope Details
- Initial Commit
- 459430a11b039a03d77e72e45e7f93b28dd9ff65
- Remediation Commit
- 5c5a8a304b00a44d80409ec4cec99a77b3dea81e
- Whitepaper
- N/A
- Requirements
- https://docs.universal.xyz→
- 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.