Q1 2025 Web3 Security ReportAccess control failures led to $1.63 billion in losses
Discover report insights
  • Hacken
  • Audits
  • margarita-finance-by-obligate-ag
  • [SCA] Obligate / Instruct / Sep2024
Margarita Finance by Obligate AG logo

Margarita Finance by Obligate AG

Audit name:

[SCA] Obligate / Instruct / Sep2024

Date:

Oct 2, 2024

Table of Content

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

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the margarita.finance powered by Obligate AG team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

margarita.finance powered by Obligate AG is a facilitation platform for establishing automated self-settling financial contracts between issuers and investors.

Document

NameSmart Contract Code Review and Security Analysis Report for margarita.finance powered by Obligate AG
Audited ByStepan Chekhovskoi, Nataliia Balashova
Approved ByPrzemyslaw Swiatowiec
Websitehttps://margarita.finance→
Changelog18/09/2024 - Initial Report, 26/09/2024 - Final Report
PlatformSolana
LanguageRust (Anchor)
TagsFinancial Product / Derivative, Vault
Methodologyhttps://hackenio.cc/sc_methodology→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for margarita.finance powered by Obligate AG
    Audited By
    Stepan Chekhovskoi, Nataliia Balashova
    Approved By
    Przemyslaw Swiatowiec
    Website
    https://margarita.finance→
    Changelog
    18/09/2024 - Initial Report, 26/09/2024 - Final Report
    Platform
    Solana
    Language
    Rust (Anchor)
    Tags
    Financial Product / Derivative, Vault
    Methodology
    https://hackenio.cc/sc_methodology→

Review Scope

Repositoryhttps://github.com/FQX-AG/instruct→
Initial Commit1ab835877ac12cad60dddabc88adc5904a086e88
Final Commitc5f5825f5711f627e9470b89f32c4d72086a3a85

Audit Summary

14Total Findings
11Resolved
0Accepted
3Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional Overview and Technical Description are provided.

  • Technical Description lacks the required tool versions specification.

  • The account restrictions and roles are not documented.

Code quality

  • The code is not covered with comments.

  • The code is clear and follows Rust coding best practices.

Test coverage

Code coverage of the project is high.

  • Unit Test coverage is 5% (region coverage).

  • All the functions are executed withing the Integration Tests.

  • Various negative test cases are covered with Integration Tests.

System Overview

The projects consist of 3 programs deployed on Solana:

  • Treasury Wallet: The program operates as vault for user funds. The program allows to authorize another user or program for the funds withdrawal.

  • Instruct: The program manages the financial product issue and close. Initially the product is proposed for confirmation to the issuer and investor. As soon as the product is accepted, the investor performs the issue payment to the issuer, then the issuer performs several payments back to the investor stretched out over a period of time. The payment amounts might be fixed or dynamic: fixed payments have the accurate amount specified at the creation and dynamic payments are fixed by the specified authority after a certain timestamp passes.

  • Payment Authority BRC: The program operates as the authority for fixing dynamic payments of the products issued by the Instruct program. If the current price is lower than the specified barrier price, the dynamic payment amount is recalculated, otherwise it is the same as initially specified.

Privileged roles

  • The system does not pose any centralized ownership or governance. However, appropriate users specified at the financial product initialization are able to perform actions restricted to their accounts such as fix of a dynamic payment, accept and issue the product, etc.

Potential Risks

Payment Default: Investors should be aware of the risk of a particular financial product default. The smart contracts does not guarantee all the payments promised to the investor are executed. Consider checking the products history of the selected issuer before concluding an agreement.

Centralized Oracles as Data Sources: The protocol utilizes centralized oracles for external data inputs. Dependence on a singular or limited set of data sources can introduce accuracy and manipulation risks, potentially affecting the smart contract's operations and decision-making processes.

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.

Findings

Code
―
Title
Status
Severity
F-2024-6125Unauthorized Treasury Wallet Withdrawal due to Lack of Signer Validation
fixed

Critical
F-2024-6180Invalid Dynamic Payment Currency Set due to Lack of Mint Accounts Validation
fixed

Critical
F-2024-6135Inability to Issue Product due to Token Account Closure Block
fixed

High
F-2024-6226Unexpected Product Closure due to Lack of Time Validation
fixed

High
F-2024-6170Invalid Payment Amount due to Unchecked Type Cast
fixed

Medium
F-2024-6162Product Misconfiguration due to Lack of Authority Verification
fixed

Medium
F-2024-6227Unauthorized Treasury Wallet Withdrawal due to Lack of Wallet Owner Verification
mitigated

Medium
F-2024-6195Inconsistent Price Calculaton due to Potential Price Feed Exponent Change
fixed

Medium
F-2024-6056Immutable Ownership
fixed

Low
F-2024-6023Invalid Accounts Space Allocation
fixed

Low
1-10 of 14 findings

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, 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

Repositoryhttps://github.com/FQX-AG/instruct→
Initial Commit1ab835877ac12cad60dddabc88adc5904a086e88
Final Commitc5f5825f5711f627e9470b89f32c4d72086a3a85
Whitepaperhttps://docs.obligate.com→
RequirementsREADME.md
Technical RequirementsREADME.md

Contracts in Scope

programs
instruct
src
lib.rs - programs/instruct/src/lib.rs
payment-authority-brc
src
lib.rs - programs/payment-authority-brc/src/lib.rs
treasury-wallet
src
lib.rs - programs/treasury-wallet/src/lib.rs

Disclaimer