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 | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Farcana |
| Audited By | Kaan Caglan |
| Approved By | Ataberk Yavuzer |
| Website | https://www.farcana.com→ |
| Changelog | 20/11/2024 - Preliminary Report |
| Changelog | 27/11/2024 - Final Report |
| Platform | EVM |
| Language | Solidity |
| Tags | Staking, Vesting, ERC20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Farcana
- Audited By
- Kaan Caglan
- Approved By
- Ataberk Yavuzer
- Website
- https://www.farcana.com→
- Changelog
- 20/11/2024 - Preliminary Report
- Changelog
- 27/11/2024 - Final Report
- Platform
- EVM
- Language
- Solidity
- Tags
- Staking, Vesting, ERC20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://gitlab.farcana.com/farcanaplatform/blockchain/farcanamigration→ |
| Commit | d16f193 |
Review Scope
- Commit
- d16f193
Audit Summary
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,pendingBankfor 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 Name | User-defined at deployment |
| Token Symbol | User-defined at deployment |
| Decimals | 18 |
| Initial Supply | 5,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-7227 | Lack of Update Functionality for Merkle Root Variables | accepted | Low | |
| F-2024-7226 | Potential User Fund Lock Due to Insufficient Reward Pool in withdraw Function | fixed | Low | |
| F-2024-7225 | Missing Validation in Migration Functions for Stake and Vesting Contracts | fixed | Low | |
| F-2024-7214 | Missing checks for address(0) | fixed | Low | |
| F-2024-7242 | Redundant Balance Check in burn Function | fixed | Observation | |
| F-2024-7224 | isBank Modifier Can Be Added | fixed | Observation | |
| F-2024-7223 | Public Functions That Should Be External | accepted | Observation | |
| F-2024-7222 | Unneeded initializations of uint256 and bool variable to 0/false | fixed | Observation | |
| F-2024-7221 | Redundant State Variable Getters in Solidity | fixed | Observation | |
| F-2024-7220 | Avoid Using State Variables Directly in emit for Gas Efficiency | unfixed | Observation |
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 | |
|---|---|
| Repository | https://gitlab.farcana.com/farcanaplatform/blockchain/farcanamigration→ |
| Commit | d16f193c001fb0087cdd423cdbf506d439835352 |
| Whitepaper | N/A |
| Requirements | N/A |
| Technical Requirements | N/A |
Scope Details
- Commit
- d16f193c001fb0087cdd423cdbf506d439835352
- Whitepaper
- N/A
- Requirements
- N/A
- Technical Requirements
- N/A
Assets in Scope
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 unexpectedly | Passed | 50k+ |
acceptBank should set the bank correctly | Passed | 50k+ |
extendMigrationTime must extend correctly | Passed | 50k+ |
deposit must handle valid amounts correctly | Passed | 50k+ |
setContracts should set staking/vesting correctly | Passed | 50k+ |
toggleMigration should correctly toggle state | Passed | 50k+ |
transferBank should correctly set pendingBank | Passed | 50k+ |
Invariant
withdrawshould not fail unexpectedlyTest Result
- Passed
Run Count
- 50k+
Invariant
acceptBankshould set the bank correctlyTest Result
- Passed
Run Count
- 50k+
Invariant
extendMigrationTimemust extend correctlyTest Result
- Passed
Run Count
- 50k+
Invariant
depositmust handle valid amounts correctlyTest Result
- Passed
Run Count
- 50k+
Invariant
setContractsshould set staking/vesting correctlyTest Result
- Passed
Run Count
- 50k+
Invariant
toggleMigrationshould correctly toggle stateTest Result
- Passed
Run Count
- 50k+
Invariant
transferBankshould correctly setpendingBankTest 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.