QTM Finance Info
Quantum Finance is a next-generation DeFi protocol on Sonic Chain that reinvents yield farming with advanced AI and dynamic tokenomics. We overcome traditional tomb fork challenges through AI-powered trading, deflationary mechanisms, and robust governance—delivering diversified rewards in Sonic tokens, stablecoins, and more. With a sharp focus on revenue generation and backed by experts in market trading and algorithm development, Quantum Finance is built for long-term stability and sustainable growth in today’s evolving DeFi landscape.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is upgradeable
The contract uses a proxy pattern or similar mechanism, enabling future upgrades. This can introduce risks if the upgrade mechanism is not securely managed.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Ownership Privileges
Masonry.sol
- The operator can transfer and renounce the operator.
- The operator can update the withdrawLockup, reward lockup, and claim reward burn epoch.
- The operator can update the claim fees to not more than 15%.
- The operator can update the quantOracle contract address.
- The operator can toggle claim fee settings.
- The operator can update the minimum claim threshold value.
- The operator can transfer ETH to the treasury address.
- The operator can distribute new rewards (seigniorage) to stakers in the protocol.
- The operator can recover unsupported tokens from the contract, excluding the quant and share tokens.
Note - This Audit report consists of a security analysis of the QTM Finance smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited the mentioned contract for the QTM Finance team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
medium Issues | 2 findings
Pending
#1 medium Issue
Missing 'isContract' check.
The contract lacks a validation check to ensure that specific parameters are contract addresses. Without this check, there is a risk that non-contract addresses (such as externally owned accounts, or EOAs) could be mistakenly set for parameters intended to reference other contracts. This could lead to failures in executing critical interactions within the contract, as EOAs do not support contract-specific functions. To mitigate this, Implement a validation check to ensure that parameters designated as contract addresses are verified as such. This can be done using Solidity’s Address library function isContract, which checks if an address has associated contract code.
Pending
#2 medium Issue
Reliance on a Custom onlyOneBlock Modifier for Anti-Reentrancy
The custom modifier uses mappings keyed by block.number, tx.origin, and msg.sender to block multiple calls in a single block. This approach can be overly restrictive by preventing legitimate multi-call interactions. It also relies on non-standard helper functions (checkSameOriginReentranted and checkSameSenderReentranted) whose correctness is critical, and the use of tx.origin may cause issues in multi-contract scenarios. To mitigate this, Adopt a standard, well-tested reentrancy guard (e.g., OpenZeppelin’s ReentrancyGuard) to manage reentrancy protection, and carefully audit and test the custom logic if it must be used to ensure it doesn’t block valid behavior or allow reentrancy exploits.
low Issues | 4 findings
Pending
#1 low Issue
Remove safemath library
The compiler version above 0.8.0 has the ability to control arithmetic overflow/underflow. It is recommended to remove the unwanted code in order to avoid high gas fees.
Pending
#2 low Issue
Missing emit.
It is recommended to emit all the critical parameter changes.
Pending
#3 low Issue
Order of Operations and State Consistency
In the stake function, the sequence of operations is critical to ensure that the contract’s state remains consistent. The function first calls super.stake(amount), which handles the core staking logic (updating total supply, individual balances, and performing token transfers), and then it resets the user’s epochTimerStart by calling treasury.epoch(). This ordering poses a potential risk: if any external call or state change (e.g., within super.stake(amount) or via the treasury contract) occurs between these operations, the recorded epoch timestamp might not accurately reflect the actual moment of staking. This could lead to inconsistencies in how lockup periods are enforced, thereby affecting when a user is permitted to withdraw or claim rewards. To mitigate this, Reduce or eliminate external calls between critical state updates to ensure that all changes occur atomically. Also, Consider capturing the epoch value before making any external calls (or within the same execution context) to ensure that the state reflects the precise moment of staking.
Pending
#4 low Issue
Missing Non-reentrant check.
Although the function updates state (resetting rewardEarned and updating epochTimerStart) before making external calls (token transfer and refund), the use of a low-level call for refund could potentially open a reentrancy vector if not carefully controlled. In this case, reentrancy is limited since the state is already cleared, but it’s still a non-standard pattern compared to well-audited reentrancy guards. While the current ordering minimizes reentrancy risk (state is updated before external calls), it is still advisable to include a standard reentrancy guard (e.g., OpenZeppelin’s ReentrancyGuard) to provide extra protection.
informational Issues | 1 findings
Pending
#1 informational Issue
Floating pragma solidity version
Adding the constant version of solidity is recommended, as this prevents the unintentional deployment of a contract with an outdated compiler that contains unresolved bugs.