Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →

Audit name:

[SCA] Obsydian | Obsydian-Contracts | Aug2024

Date:

Sep 9, 2024

Table of Content

→Introduction
→Audit Summary
→System Overview
→Risks
→Findings
→Appendix 1. Severity Definitions
→Appendix 2. Scope
→Disclaimer

Want a comprehensive audit report like this?

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

NameSmart Contract Code Review and Security Analysis Report for Obsydian
Audited ByTurgay Arda Usman
Approved ByPrzemyslaw Swiatowiec
Websitehttps://obsydian.app/→
Changelog27/08/2024 - Preliminary Report
09/09/2024 - Final Report
PlatformEthererum
LanguageSolidity
TagsEVM, Wallet
Methodologyhttps://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
    Changelog
    27/08/2024 - Preliminary Report
    09/09/2024 - Final Report
    Platform
    Ethererum
    Language
    Solidity
    Tags
    EVM, Wallet

Review Scope

Repositoryhttps://github.com/Obsydian-app/contracts→
Initial CommitShared as file
Final Commitdb795212ce86c52475a484acabd80dea0834f334

Audit Summary

14Total Findings
9Resolved
3Accepted
2Mitigated

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

F-2024-5575Funds Lock During Cancellation
Status
mitigated
Severity

High
F-2024-5558Reentrancy Vulnerability During Transfer to backupWallet Address
Status
fixed
Severity

Medium
F-2024-5555Inaccurate Transfer Cost Calculation in transferAssets() Function
Status
mitigated
Severity

Medium
F-2024-5553 Inaccurate Transfer Cost Calculation in calculateTransferCosts() Function
Status
fixed
Severity

Medium
F-2024-5551Unchecked Transfer
Status
fixed
Severity

Low
F-2024-5557Unused Inheritance
Status
fixed
Severity

Observation
F-2024-5556Operator Can Frontrun Registration Fee
Status
accepted
Severity

Observation
F-2024-5554Magic Numbers in Calculations
Status
fixed
Severity

Observation
F-2024-5552 Unnecessary Payable Modifier
Status
accepted
Severity

Observation
F-2024-5550 Use of transfer() Instead of call() to Send Native Tokens
Status
accepted
Severity

Observation
Code
―
Title
Status
Severity
F-2024-5575Funds Lock During Cancellation
mitigated

High
F-2024-5558Reentrancy Vulnerability During Transfer to backupWallet Address
fixed

Medium
F-2024-5555Inaccurate Transfer Cost Calculation in transferAssets() Function
mitigated

Medium
F-2024-5553 Inaccurate Transfer Cost Calculation in calculateTransferCosts() Function
fixed

Medium
F-2024-5551Unchecked Transfer
fixed

Low
F-2024-5557Unused Inheritance
fixed

Observation
F-2024-5556Operator Can Frontrun Registration Fee
accepted

Observation
F-2024-5554Magic 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
1-10 of 14 findings

Identify vulnerabilities in your smart contracts.

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:

Contracts in Scope

File: Factory.sol - File: Factory.sol
ProtectionDelegate.sol - ProtectionDelegate.sol
ProtectionSlim.sol - ProtectionSlim.sol
NFTProtectionDelegate.so - NFTProtectionDelegate.so
NFTProtectionSlim.sol - NFTProtectionSlim.sol

Disclaimer