Introduction
We express our gratitude to the Obsydian team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Obsydian is a decentralized platform focused on simplifying asset protection for dormant wallets, ensuring user control without requiring custodial solutions or hardware devices. It offers a user-friendly interface and plans to provide optional non-private key backups for easier access to secondary wallets.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Obsydian |
| Audited By | Turgay Arda Usman |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://obsydian.app/→ |
| Changelog | 27/08/2024 - Preliminary Report |
| 09/09/2024 - Final Report | |
| Platform | Ethererum |
| Language | Solidity |
| Tags | EVM, Wallet |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Obsydian
- Audited By
- Turgay Arda Usman
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://obsydian.app/→
- Changelog
- 27/08/2024 - Preliminary Report
- 09/09/2024 - Final Report
- Platform
- Ethererum
- Language
- Solidity
- Tags
- EVM, Wallet
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Obsydian-app/contracts→ |
| Initial Commit | Shared as file |
| Final Commit | db795212ce86c52475a484acabd80dea0834f334 |
Review Scope
- Initial Commit
- Shared as file
- Final Commit
- db795212ce86c52475a484acabd80dea0834f334
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided.
Technical description is partially provided.
Code quality
The code mostly follows best practices and style guides.
See informational issues and observations for more details.
The development environment is configured.
Test coverage
Code coverage of the project is 92.25% (branch coverage), .
Deployment and basic user interactions are covered with tests.
Negative cases coverage is missed.
Interactions by several users are not tested thoroughly.
System Overview
Obsydian is a decentralized platform focused on simplifying asset protection for dormant wallets, ensuring user control without requiring custodial solutions or hardware devices. It offers a user-friendly interface and plans to provide optional non-private key backups for easier access to secondary wallets. It has the following contracts:
NFTProtectionSlim — The NFT Protection (slim) makes significant gas savings by delegating most calls to this contract (and keeping the slim contract size small). NFTProtectionDelegate — An NFT protection contract designed to be a compromise between on chain storage and backend independent features. Once deployed the list of protected tokens is updatable (as well as the timelapse). ProtectionDelegate — An ERC20 protection contract designed to be a compromise between on chain storage and backend independent features. Once deployed the list of protected ERC20 tokens is not updatable. ProtectionSlim — The Protection (slim) makes significant gas savings by delegating most calls to this contract (and keeping the slim contract size small). Factory — The entry point for deploying and managing protection contracts.
Privileged roles
The owner can deploy both ERC20 and NFT protection contracts for asset management and security.
The owner can trigger the transfer of assets from the primary wallet to the backup wallet for both ERC20 and NFT assets.
The owner can update the registration fee and withdraw the accumulated fees from the contract balance.
The primary wallet can add, update, or remove protected NFT assets, set the timelapse for asset protection, and cancel the protection to recover the deposited assets.
The backup wallet can recover the assets once the timelapse has elapsed.
The owner can deploy new contracts and manage system-level configurations.
Risks
The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.
Making external calls within loops increases the risk of gas exhaustion, potentially leading to failed transactions and reduced contract reliability, especially when processing large datasets.
The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.
The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases and emergency withdrawals.
The token ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.
The implemented project logic highly depends on external off-chain parts that are not covered by the audit. This reliance introduces risks if these external contracts are compromised or contain vulnerabilities, affecting the audited project's integrity.
The project expects the users to access via EOAs. The implement, however, allows for contract access too, more information can be found here. →
This report was modified on September 4th, 2025 at the client’s request to update its original content by project name change, updating the repository link, and project name change in the resolution quote of the finding [F-2024-5550 →]. While these changes aim to align the report with the most current information provided by the client, it is important to note that modifying previously published content may affect the integrity and continuity of the original audit findings. Hacken has reviewed the modifications to confirm they reflect only the requested updates, but any future changes involving substantial updates or new code commits should be accompanied by a re-assessment to ensure no new risks compromise the security posture.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-5575 | Funds Lock During Cancellation | mitigated | High | |
| F-2024-5558 | Reentrancy Vulnerability During Transfer to backupWallet Address | fixed | Medium | |
| F-2024-5555 | Inaccurate Transfer Cost Calculation in transferAssets() Function | mitigated | Medium | |
| F-2024-5553 | Inaccurate Transfer Cost Calculation in calculateTransferCosts() Function | fixed | Medium | |
| F-2024-5551 | Unchecked Transfer | fixed | Low | |
| F-2024-5557 | Unused Inheritance | fixed | Observation | |
| F-2024-5556 | Operator Can Frontrun Registration Fee | accepted | Observation | |
| F-2024-5554 | Magic Numbers in Calculations | fixed | Observation | |
| F-2024-5552 | Unnecessary Payable Modifier | accepted | Observation | |
| F-2024-5550 | Use of transfer() Instead of call() to Send Native Tokens | accepted | Observation |
Appendix 1. Severity Definitions
Appendix 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, do not affect security score but can affect code quality score. |
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, do not affect security score but can affect code quality score.
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/Obsydian-app/contracts→ |
| Initial Commit | Shared as file |
| Final Commit | db795212ce86c52475a484acabd80dea0834f334 |
| Whitepaper | https://obsydian.gitbook.io/obsydian-litepaper/smart-contracts→ |
| Requirements | https://obsydian.gitbook.io/obsydian-litepaper/smart-contracts→ |
| Technical Requirements | https://obsydian.gitbook.io/obsydian-litepaper/smart-contracts→ |
Scope Details
- Initial Commit
- Shared as file
- Final Commit
- db795212ce86c52475a484acabd80dea0834f334
- Technical Requirements
- https://obsydian.gitbook.io/obsydian-litepaper/smart-contracts→