Introduction
We express our gratitude to the Lingo team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The Lingo project implements a custom ERC20 token with transfer fees, whitelisting, and minting capabilities, designed to be locked until a Token Generation Event (TGE). It includes a vesting smart contract that manages token distribution to various participants using Merkle tree verification and multiple vesting schedules. Additionally, a staking contract allows users to stake tokens and earn cumulative weight over time, with locking period multipliers and off-chain tier management.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Lingo |
| Audited By | Przemyslaw Swiatowiec, Kornel Światłowski |
| Approved By | Grzegorz Trawinski |
| Website | http://lingocoin.io/→ |
| Changelog | 28/10/2024 - Preliminary Report, 13/11/2024 - Secondary Report, 19/12/2024 - Final Report |
| Platform | Base |
| Language | Solidity |
| Tags | Staking, Vesting, ERC20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Lingo
- Audited By
- Przemyslaw Swiatowiec, Kornel Światłowski
- Approved By
- Grzegorz Trawinski
- Website
- http://lingocoin.io/→
- Changelog
- 28/10/2024 - Preliminary Report, 13/11/2024 - Secondary Report, 19/12/2024 - Final Report
- Platform
- Base
- Language
- Solidity
- Tags
- Staking, Vesting, ERC20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/avicenne-studio/lingo-token-contracts→ |
| Commit | db082b4db0ec7812a2450ef0e1b6907c03784ba6 |
Review Scope
- Commit
- db082b4db0ec7812a2450ef0e1b6907c03784ba6
Audit Summary
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 provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Interactions by several users are tested.
System Overview
Lingo is an ERC-20 token project featuring transfer fees, whitelisting, and minting capabilities, along with a transfer lock until the Token Generation Event (TGE).
LingoToken provides standard ERC-20 functionalities, including managing token balances, transferring tokens between addresses, and enforcing a maximum supply. The contract includes additional features such as configurable transfer fees (up to 5%) and a whitelist mechanism that enables fee exemptions for specific addresses. It also allows designated minters to mint tokens up to the total supply cap of 1,000,000,000 LINGO.
Vesting is a smart contract that manages the distribution of tokens across various vesting schedules for participants, using Merkle tree verification to ensure eligibility. The vesting contract calculates and enforces each participant's schedule, restricting transfers until TGE and allowing users to directly stake claimed tokens to earn rewards.
Staking is a contract that enables Lingo token holders to lock tokens and accumulate cumulative weight over time. Users can choose from different locking periods, where longer durations apply higher multipliers to the weight accumulated. The contract tracks staked balances, manages locking periods, and allows the owner to pause staking operations if necessary.
Privileged roles
LingoToken Contract
Owner:
Configures the transfer fee percentage.
Manages internal and external whitelist for fee exemptions.
Sets and updates the treasury wallet address.
Assigns and removes minter roles
Minter:
Can mint new tokens up to the maximum supply of 1,000,000,000 LINGO.
Restricted to addresses designated by the owner to control token supply effectively.
Vesting Contract
Owner:
Updates the Merkle root for whitelist verification.
Manages vesting schedules and eligibility criteria.
Staking Contract
Owner:
Configures locking period options
Potential Risks
Off-Chain Reward Handling: The staking rewards mechanism is managed off-chain, meaning it lacks on-chain enforcement. This setup could lead to inconsistencies in reward distribution or create trust dependencies on the off-chain system, impacting the transparency and reliability of rewards.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-6763 | Inefficient Minting Pattern for Vesting Tokens | fixed | Low | |
| F-2024-6749 | Potential Front-Running Risk in Lock Duration Updates | fixed | Low | |
| F-2024-6747 | Potential Accounting Inconsistency Due to Fee Deduction in Staking Transactions | fixed | Low | |
| F-2024-7838 | [DualDefense] Fee Bypass Through Staking Contract Using Zero Locking Duration | fixed | Low | |
| F-2024-6770 | Lack of Minimum Stake Validation Can Lead to Array Overpopulation | fixed | Observation | |
| F-2024-6764 | delete Keyword Usage Leaves Gaps in userPositions Array After Unstake | fixed | Observation | |
| F-2024-6762 | Inconsistencies Between Project Documentation and Contract Implementation | fixed | Observation | |
| F-2024-6755 | Violation of the Checks-Effects-Interactions (CEI) pattern | fixed | Observation | |
| F-2024-6754 | Missing Two-step Ownership Transfer Process | fixed | Observation | |
| F-2024-6752 | Inefficient Gas Usage Due to addInternalAccess() Invocation in Constructor | fixed | 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://github.com/avicenne-studio/lingo-token-contracts→ |
| Commit | db082b4db0ec7812a2450ef0e1b6907c03784ba6 |
| Whitepaper | - |
| Requirements | Provided as PDF |
| Technical Requirements | Provided as PDF |
Scope Details
- Commit
- db082b4db0ec7812a2450ef0e1b6907c03784ba6
- Whitepaper
- -
- Requirements
- Provided as PDF
- Technical Requirements
- Provided as PDF
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Lingo, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry →, 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 Foundry fuzzing suite was prepared for this task, and throughout the assessment, 7 invariants were tested over 10,000,004 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant and Fuzzing | Test Result | Run Count |
|---|---|---|
| Transfer with random fee variable | Passed | 10000004 |
| Transfer with random amount | Passed | 10000004 |
| Transfer with random fee and amount | Passed | 10000004 |
| Stake random amount and staking contract not whitelisted as internal address | Passed | 10000004 |
| Stake and unstake random amount | Passed | 10000004 |
| Cannot unstake before expected stake duration | Passed | 10000004 |
| Cannot claim vesting without correct proof | Passed | 10000004 |
Invariant and Fuzzing
- Transfer with random fee variable
Test Result
- Passed
Run Count
- 10000004
Invariant and Fuzzing
- Transfer with random amount
Test Result
- Passed
Run Count
- 10000004
Invariant and Fuzzing
- Transfer with random fee and amount
Test Result
- Passed
Run Count
- 10000004
Invariant and Fuzzing
- Stake random amount and staking contract not whitelisted as internal address
Test Result
- Passed
Run Count
- 10000004
Invariant and Fuzzing
- Stake and unstake random amount
Test Result
- Passed
Run Count
- 10000004
Invariant and Fuzzing
- Cannot unstake before expected stake duration
Test Result
- Passed
Run Count
- 10000004
Invariant and Fuzzing
- Cannot claim vesting without correct proof
Test Result
- Passed
Run Count
- 10000004
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.