TRUST Summit | Nov 3, 2025 | NYCWhere decision-makers define the next chapter of secure blockchain adoption.
Learn more

Audit name:

[SCA] Farcana | Token | Nov2024

Date:

Dec 4, 2024

Table of Content

Introduction
Audit Summary
System Overview
Potential Risks
Findings
Appendix 1. Definitions
Appendix 2. Scope
Appendix 3. Additional Valuables
Disclaimer

Want a comprehensive audit report like this?

Introduction

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

The Farcana Token Ecosystem consists of multiple interconnected smart contracts enabling the migration, staking, vesting, and management of Farcana (FAR) tokens. It provides functionality for token holders to participate in staking, migrate to updated systems, and vest tokens with predefined schedules.

Document

NameSmart Contract Code Review and Security Analysis Report for Farcana
Audited ByKaan Caglan
Approved ByAtaberk Yavuzer
Websitehttps://www.farcana.com
Changelog20/11/2024 - Preliminary Report
Changelog27/11/2024 - Final Report
PlatformEVM
LanguageSolidity
TagsStaking, Vesting, ERC20
Methodologyhttps://hackenio.cc/sc_methodology
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Farcana
    Audited By
    Kaan Caglan
    Approved By
    Ataberk Yavuzer
    Changelog
    20/11/2024 - Preliminary Report
    Changelog
    27/11/2024 - Final Report
    Platform
    EVM
    Language
    Solidity
    Tags
    Staking, Vesting, ERC20

Audit Summary

15Total Findings
11Resolved
3Accepted
0Mitigated

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

Documentation quality

  • Functional requirements are missed.

  • Technical description is not provided.

  • NatSpec is sufficient.

Code quality

  • The code is Gas-efficient.

  • The development environment is configured.

Test coverage

Code coverage of the project is 0% (branch coverage)

  • Deployment and basic user interactions are not covered with tests.

System Overview

The Farcana Token Ecosystem consists of multiple interconnected smart contracts enabling the migration, staking, vesting, and management of Farcana (FAR) tokens. It provides functionality for token holders to participate in staking, migrate to updated systems, and vest tokens with predefined schedules.

Contracts

FarcanaMigration.sol

  • Functionality:

    • Facilitates migration of staking and vesting data to new contracts.

    • Allows token claims for staking, vesting, and holder distributions.

    • Implements Merkle proof validation for secure data verification during migration.

  • Core Components:

    • Migration Settings: migrationActive, migrationEndTime, Merkle roots for data validation.

    • Role Management: bank, pendingBank for fund control.

    • Events: Emitted on migration, fund transfer, or claim actions.

FarcanaToken.sol

  • Functionality:

    • ERC20-compliant token representing the Farcana (FAR) token.

    • Implements token burning and full initial supply minting to the deployer.

  • Core Attributes:

    • Name: Customizable during deployment.

    • Symbol: Customizable during deployment.

    • Decimals: Fixed at 18.

    • Initial Supply: 5,000,000,000 FAR.

FarcanaVesting.sol

  • Functionality:

    • Manages token vesting schedules for investors.

    • Locks tokens until release conditions are met (cliff and duration).

    • Allows vesting migration and beneficiary address changes.

  • Core Components:

    • Vesting Schedule Structure:

      • cliff, duration, start, totalAmount, released.

    • Statistics:

      • Total Value Locked (TVL), beneficiary-specific schedules.

    • Events: Notifications on vesting schedule creation, token release, and address changes.

FARStakingContract.sol

  • Functionality:

    • Enables staking of FAR tokens with rewards proportional to duration.

    • Tracks staking positions and provides reward calculations.

    • Supports emergency withdrawal and staking position migration.

  • Core Components:

    • Stake Position Structure:

      • amount, startTime, endTime, rateAtStakeTime, claimed, reservedReward.

    • Staking Rates: Configurable by staking period.

    • Reward Pool: Tracks available rewards.

Token Attributes

Attribute

Value

Token NameUser-defined at deployment
Token SymbolUser-defined at deployment
Decimals18
Initial Supply5,000,000,000 FAR
  • Attribute

    Token Name

    Value

    User-defined at deployment

    Attribute

    Token Symbol

    Value

    User-defined at deployment

    Attribute

    Decimals

    Value

    18

    Attribute

    Initial Supply

    Value

    5,000,000,000 FAR

Privileged Roles

Owner:

  • Manages contract settings, including reward rates, migration toggles, and vesting schedules.

  • Assigns migration contracts and other administrative tasks.

Bank (FarcanaMigration):

  • Handles fund withdrawals and transfers within the migration contract.

Migration Contract:

  • Authorizes migration of data (staking and vesting) from legacy systems.

Whitelist Managers (FARStakingContract):

  • Adds special staking rates for specific users.

Potential Risks

Fixed Total Supply Post-Deployment: The token’s total supply is determined at deployment and cannot be verified beforehand, potentially limiting the project’s adaptability and economic model flexibility.

Single Points of Failure and Control: The project is fully or partially 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.

Administrative Key Control Risks: 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.

Findings

Code
Title
Status
Severity
F-2024-7227Lack of Update Functionality for Merkle Root Variables
accepted

Low
F-2024-7226Potential User Fund Lock Due to Insufficient Reward Pool in withdraw Function
fixed

Low
F-2024-7225Missing Validation in Migration Functions for Stake and Vesting Contracts
fixed

Low
F-2024-7214Missing checks for address(0)
fixed

Low
F-2024-7242Redundant Balance Check in burn Function
fixed

Observation
F-2024-7224isBank Modifier Can Be Added
fixed

Observation
F-2024-7223Public Functions That Should Be External
accepted

Observation
F-2024-7222Unneeded initializations of uint256 and bool variable to 0/false
fixed

Observation
F-2024-7221Redundant State Variable Getters in Solidity
fixed

Observation
F-2024-7220Avoid Using State Variables Directly in emit for Gas Efficiency
unfixed

Observation
1-10 of 15 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.
  • 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

Repositoryhttps://gitlab.farcana.com/farcanaplatform/blockchain/farcanamigration
Commitd16f193c001fb0087cdd423cdbf506d439835352
WhitepaperN/A
RequirementsN/A
Technical RequirementsN/A

Assets in Scope

FarcanaMigration.sol - FarcanaMigration.sol
FarcanaToken.sol - FarcanaToken.sol
FarcanaVesting.sol - FarcanaVesting.sol
MerkleFatcanaClaiming.sol - MerkleFatcanaClaiming.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Farcana contracts, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Echidna , a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 7 invariants were tested over 50,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

withdraw should not fail unexpectedlyPassed50k+
acceptBank should set the bank correctlyPassed50k+
extendMigrationTime must extend correctlyPassed50k+
deposit must handle valid amounts correctlyPassed50k+
setContracts should set staking/vesting correctlyPassed50k+
toggleMigration should correctly toggle statePassed50k+
transferBank should correctly set pendingBankPassed50k+
  • Invariant

    withdraw should not fail unexpectedly

    Test Result

    Passed

    Run Count

    50k+

    Invariant

    acceptBank should set the bank correctly

    Test Result

    Passed

    Run Count

    50k+

    Invariant

    extendMigrationTime must extend correctly

    Test Result

    Passed

    Run Count

    50k+

    Invariant

    deposit must handle valid amounts correctly

    Test Result

    Passed

    Run Count

    50k+

    Invariant

    setContracts should set staking/vesting correctly

    Test Result

    Passed

    Run Count

    50k+

    Invariant

    toggleMigration should correctly toggle state

    Test Result

    Passed

    Run Count

    50k+

    Invariant

    transferBank should correctly set pendingBank

    Test Result

    Passed

    Run Count

    50k+

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.

Disclaimer