The Hacken 2025 Yearly Security ReportCovers major Web3 breaches, their root causes, prevention insights, and key regulatory trends for 2026.
Learn more

Sallar

Audit name:

[SCA] Sallar | DePIN | Aug2023

Date:

Aug 24, 2023

Table of Content

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

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Astral Holding OU team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

The Sallar ecosystem is a network of community projects that use Sallar as their payment method. With Sallar, you can pay for products and services, such as clothing, and use it as the currency on the Marketplace Community.

titlecontent
PlatformSolana
LanguageRust
TagsGameFi, Fungible Token
Timeline20/05/2023 - 23/08/2023
Methodologyhttps://hackenio.cc/sc_methodology→

    Review Scope

    Repositoryhttps://github.com/Sallar-Labs/Sallar→
    Commit787caf381e11f75151a34dac0bed5f3cce8bb8d5
    7da2425ed76895ea6a9fd9e8f44073c7318ffce9 (numbers adjustment November 2024)

    Audit Summary

    Total9.1/10
    Security Score

    10/10

    Test Coverage

    90%

    Code Quality Score

    7/10

    Documentation Quality Score

    10/10

    17Total Findings
    12Resolved
    0Accepted
    3Mitigated

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

    Document Information

    This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.

    The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.

    Document

    NameSmart Contract Code Review and Security Analysis Report for Astral Holding OU
    Audited ByHacken
    Websitehttps://sallar.io/→
    Changelog25/05/2023 – Initial Review
    12/07/2023 – Second Review
    31/07/2023 – Third Review
    23/08/2023 – Fourth Review

    • Document

      Name
      Smart Contract Code Review and Security Analysis Report for Astral Holding OU
      Audited By
      Hacken
      Website
      https://sallar.io/→
      Changelog
      25/05/2023 – Initial Review
      12/07/2023 – Second Review
      31/07/2023 – Third Review
      23/08/2023 – Fourth Review

    System Overview

    This program manages creation, emission and distribution of a fungible token. Its maximum supply is 12,000,000,000 of which:

    • 2,600,000,000 is distributed to a special “organization” account.

    • 9,400,000,000 is distributed in batches of so-called “blocks”.

    There are 470,000 blocks, which are distributed in a game-like fashion one by one in two ways: top-to-bottom (starting from block 1, aka “mining”), and bottom-to-top (starting from block 470,000, aka “staking”). Each block needs to be exhausted (for the next one to become available) by user requests, which the off-chain code posts to the contract on behalf of the users; each such request causes transferring a portion of the block tokens to the user that corresponds to the request. The rules and requests are different for the two directions - the details are in the official documentation →.

    Once all the blocks have been consumed, two distribution modes become available: “final mining” and “final staking”. Each mode has a designated account (exclusively managed by the contract) which can be funded by anybody using the previously distributed funds; funds in the special accounts are distributed according to yet new games, whose rules are described in the official documentation →. The two final distribution games are played in cycles, and there can be indefinitely many cycles - as long as there are funds in the special accounts. Like in the normal block distribution modes, the games are played with user requests, which the off-chain code posts to the contract on behalf of the users; each such request causes transferring a portion of the block tokens to the user that corresponds to the request.

    Each distribution game has a significant part of its logic outside the contract - which is out of the scope.

    The smart contract has the following API:

    • initialize — Sets up program-related accounts and performs initial mint. Can be called at most once.

    • initialtokendistribution — Distribute 2,600,000,000 tokens to the “organization” account, provided by the owner. Can be called at most once.

    • solvetopblock — The owner executes a set of user requests to play the “mining” game.

    • solvebottomblock — The owner executes a set of user requests to play the “staking” game.

    • finalmining_ — The owner executes a set of user requests to play the “final mining” game.

    • finalstaking_ — The owner executes a set of user requests to play the “final staking” game.

    • changeauthority_ — The owner changes the contract authority to the new one.

    Privileged roles

    • The only user of the program is owner - an account registered by the initialize() function and can be changed using change_authority().

    Executive Summary

    Documentation quality

    The total Documentation quality score is 10 out of 10.

    • The functional documentation covers everything in satisfactory detail.

    • Technical description is provided.

    Code quality

    The total Code quality score is 7 out of 10.

    • Redundancies are found (I-2023-0418).

    • Some confusing points are found (I-2023-0422).

    • Floating point numbers math is used.

    Test coverage

    Code coverage of the project is 90% (branch coverage).

    • final_mining and final_staking instructions are tested but their effects are not checked during testing.

    • The solve_top_block and solve_bottom_block instructions that take a lot lines of code (due to redundancies and code duplications) are successfully tested.

    Security score

    Upon auditing, the code was found to contain 1 critical, 2 high, 5 medium, and 1 low severity issues. Out of these, 6 issues have been addressed and resolved, leading to a security score of 10 out of 10.

    All identified issues are detailed in the “Findings” section of this report.

    Summary

    The comprehensive audit of the customer's smart contract yields an overall score of 9.1. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.

    Scoring Methodologyarrow right

    Risks

    Unless the smart contract is deployed with the --final flag, it could be upgraded and its functionality may be changed.

    The contract is fully centralized: \-The owner is the only user and has complete control over it. \-The token distribution claims are made exclusively by the owner, who is free to arbitrarily forge them in their favor or censor/handicap normal user claims.

    A major part of the overall system logic – that is financially relevant – is outside the contract. The contract only processes results of some off-chain computations that are out of the audit scope.

    The final_mining and final_staking APIs are designed to distribute tokens from the special contract accounts, but it is not guaranteed that the accounts will be properly funded.

    Anyone is able to initialize the program by calling initialize (can be called only once). It is recommended to perform deployment and initialization in one transaction.

    The convert_f64_to_u64 and convert_u64_to_f64 will lose precision for numbers over 2^53, however it is unlikely.

    The program performs computations in f64, whereas the token value type is u64 - which requires casting token values to f64 and back. u64 values that take more than 53 bits are likely to be not representable in f64, and have to be approximated. Moreover, f64 computations have limited precision on their own. Together, this may result in losses of portions of token values. However, the collective losses due to f64 precision are highly unlikely to be significant in USD equivalent.

    The deployment code should not be compiled with the bpf-tests feature.

    Findings

    Code
    ―
    Title
    Status
    Severity
    F-2023-1594Incorrect Value
    fixed

    Critical
    F-2023-159Stuck Funds
    mitigated

    High
    F-2023-159 Unset Or Unsettable Token Metadata
    fixed

    High
    F-2023-160 Missing Validation & Corrupted Data
    mitigated

    Medium
    F-2023-1600Denial Of Service State
    mitigated

    Medium
    F-2023-159Missing Validation
    fixed

    Medium
    F-2023-159Immutable Ownership
    fixed

    Medium
    F-2023-159Invalid Hardcoded Value
    fixed

    Medium
    F-2023-1602 Inconsistent Data
    fixed

    Low
    I-2023-042 Unused Code
    fixed

    Observation
    1-10 of 17 findings

    Identify vulnerabilities in your smart contracts.

    Appendix 1. Severity Definitions

    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.

    Appendix 2. Scope

    The scope of the project includes the following smart contracts from the provided repository:

    Scope Details

    Repositoryhttps://github.com/Sallar-Labs/Sallar→
    Commit787caf381e11f75151a34dac0bed5f3cce8bb8d5
    7da2425ed76895ea6a9fd9e8f44073c7318ffce9 (numbers adjustment November 2024)
    ConceptProvided→
    RequirementsProvided→
    Technical RequirementsProvided→

    Contracts in Scope

    programs
    sallar
    src
    account.rs - programs › sallar › src › account.rs
    context.rs - programs › sallar › src › context.rs
    error.rs - programs › sallar › src › error.rs
    lib.rs - programs › sallar › src › lib.rs
    token_math.rs - programs › sallar › src › token_math.rs
    utils.rs - programs › sallar › src › utils.rs

    Disclaimer

    Sallar audit by Hacken