Audit name:
[SCA] Thena / Thena Automations / Feb2025
Date:
Feb 24, 2025
Table of Content
Introduction
We express our gratitude to the Thena team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Thena is a community-driven decentralized exchange, powered by a self-optimizing ve3,3 model, serving BNB Chain projects with their liquidity needs.
After conducting initial checks, the commit hash 21751fb was reviewed by the Hacken audit team for remediation checks.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Thena |
| Audited By | Nataliia Balashova |
| Approved By | Ataberk Yavuzer |
| Website | https://thena.fi/→ |
| Changelog | 11/02/2025 - Preliminary Report |
| 24/02/2025 - Final Report | |
| Platform | BSC |
| Language | Solidity |
| Tags | Automation |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Thena
- Audited By
- Nataliia Balashova
- Approved By
- Ataberk Yavuzer
- Website
- https://thena.fi/→
- Changelog
- 11/02/2025 - Preliminary Report
- 24/02/2025 - Final Report
- Platform
- BSC
- Language
- Solidity
- Tags
- Automation
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/ThenafiBNB/THENA-AUTOMATIONS/tree/HackenAudit→ |
| Commit | e41cb73686e7632e14db785e61ce695fd85da18a |
| Final Commit | 21751fbc3f1e4d28dc1d9e89895cd23b941c6e4f |
Review Scope
- Commit
- e41cb73686e7632e14db785e61ce695fd85da18a
- Final Commit
- 21751fbc3f1e4d28dc1d9e89895cd23b941c6e4f
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Architectural overview is provided.
Functional requirements are partially missed.
Technical description is provided.
Code quality
Several template code patterns were found.
The development environment is configured.
Test coverage
Code coverage of the project is 95.45%.
Deployment and basic user interactions are covered with tests.
Most negative cases are covered.
System Overview
THENA is a protocol with the following contracts:
VeTheAutomation — a contract is part of a decentralized automation system designed to interact with the veTHE ecosystem and perform a series of automated operations. The contract facilitates automation tasks such as claiming rewards, increasing lock durations, and voting, based on predefined operations flags. It relies on external integrations with Chainlink, a rewards distributor, and voting escrow mechanisms. Here's a breakdown of its core components and functionalities:
Automation Functions: The contract integrates with Chainlink’s automation system to perform tasks at specific intervals. The tasks are defined by the operations flag and include actions like claiming rewards, increasing lock durations, and voting.
Upkeep Management: The contract supports the management of "upkeep," a recurring task in the automation system, with functionality to pause, unpause, and cancel upkeep. It ensures the task can only be executed by authorized users and maintains a set gas limit for task execution.
Deposits and Withdrawals: It handles deposits and withdrawals of LINK tokens, ensuring that the contract has sufficient funds for upkeep operations. The tokens are swapped for the required type using an external PegSwap contract.
State Management: The contract tracks the status of the automation, which can be "Created," "Registered," "Paused," or "Canceled." The automation's state determines whether operations can proceed, with status checks required for task execution.
VeTheAutomationFactory — a contract is designed to facilitate the creation of new automation contracts that are compatible with Chainlink’s automation network, specifically for managing operations related to veTHE tokens. It allows for the registration and management of these automation contracts, enabling them to perform various tasks such as voting, claiming rewards, and modifying lock durations. The factory pattern enables the creation of multiple instances of VeTheAutomation contracts for each specific token ID, which can then be controlled and interacted with based on the token owner’s permissions.
Privileged roles
DEFAULT_ADMIN_ROLE:
The highest privilege role, typically granted to the contract deployer. Manages the contract and assigns/revokes FACTORYMANAGERROLE.
FACTORY_MANAGER_ROLE:
Role for managing the VeTheAutomationFactory. Can update the Chainlink Registrar, Voter, and RewardsDistributor addresses.
Potential Risks
Both contracts rely heavily on external systems like Chainlink Automation, PegSwap, and the Voting Escrow. If any of these external services experience downtime or issues (such as network failures or liquidity issues), the contracts may be unable to function as intended, causing potential loss of funds or halted automation.
External imports to the contract either lack proper implementation or fall outside the intended scope. This can lead to gaps in functionality, as the contract may rely on these external components to perform critical operations. If the external dependencies are not fully aligned with the contract's goals or remain unimplemented, it could result in incomplete or inconsistent behavior. This could lead to inefficiencies or unexpected outcomes, potentially complicating maintenance or future upgrades.
The getUserAutomations function loops through all token IDs associated with a user, querying external contracts (e.g., IVotingEscrow). This could be inefficient and costly in terms of gas if there are a large number of token IDs, leading to possible transaction failures or delays.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8713 | Missing Status and Cancellation Delay Checks in withdrawFunds Function | fixed | High | |
| F-2025-8696 | Token Swap in depositFunds Not Handling Failure | fixed | Medium | |
| F-2025-8695 | Invalid Timestamp Handling in setRunTimestamp Function | fixed | Medium | |
| F-2025-8715 | Uninitialized Variable newLockDuration | fixed | Low | |
| F-2025-8717 | Floating Pragma | fixed | Observation | |
| F-2025-8716 | Unused Variable | fixed | Observation | |
| F-2025-8714 | Violation of the Checks-Effects-Interactions (CEI) pattern | fixed | Observation |
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 | |
|---|---|
| Repository | https://github.com/hknio/ThenafiBNB___THENA-AUTOMATIONS→ |
| Commit | e41cb73686e7632e14db785e61ce695fd85da18a |
| Whitepaper | N/A |
| Requirements | N/A |
| Technical Requirements | N/A |
Scope Details
- Commit
- e41cb73686e7632e14db785e61ce695fd85da18a
- Whitepaper
- N/A
- Requirements
- N/A
- Technical Requirements
- N/A
Assets in Scope
VeTheAutomation/VeTheAutomation.solVeTheAutomation/VeTheAutomationFactory.solAppendix 3. Additional Valuables
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.