Teirrax Info
Teirraxlabs provides research, tools and technology to help you understand the markets, build your own trading strategies and manage risk more confidently. We do not offer guaranteed returns or financial advice; all trading involves risk and you should only trade with capital you can afford to lose.
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.
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 not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
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
- The owner can set the burn fees to not more than 5%.
- The owner can set the extra tax percentage to not more than 5%.
- The owner can exclude/include wallets in burn fees.
- The owner can request to update the maximum transfer amount.
- The owner can update the maximum transfer amount value.
- The owner can emergency withdraw all BNB (native currency) held by the contract.
- The owner can recover any BEP20 tokens sent to the contract, except for the contract's own TXT tokens.
- The owner can transfer or renounce ownership of the contract.
Note - This Audit report consists of a security analysis of the TXT smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the Teirrax 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
Findings and Audit result
high Issues | 1 findings
Resolved
#1 high Issue
Dysfunctional Blacklist Logic Due to Invalid Timestamp Validation and Missing State Update
The addToBlacklist function contains two critical logic errors that render it unusable. First, the condition require(block.timestamp < daysCount, ...) incorrectly compares the current Unix timestamp (a very large number) with the input daysCount (capped at 365). This condition will always evaluate to false, causing every call to this function to revert. Second, the function calculates the unblock time but fails to actually set the isBlock boolean flag to true in the _blacklisted mapping. Since the notBlacklisted modifier relies on checking isBlock to enforce restrictions, the blacklisting mechanism would remain ineffective even if the timestamp validation were fixed.
medium Issues | 3 findings
Resolved
#1 medium Issue
Sell Tax Logic Violates Supply Floor Guarantee
The contract explicitly guarantees a minimum token supply via the remainingSupply variable. While the standard burn fee logic correctly stops burning when this limit is reached, the "Extra Tax" (applied on sell transactions) is calculated and burned independently without checking this floor. Consequently, sell transactions continue to destroy tokens even after the supply limit is hit, allowing the total supply to decrease indefinitely below the promised minimum.
Resolved
#2 medium Issue
Permanent Inflation of Token Holder Count
The contract initializes the tokenHolder counter to 1 in the constructor logic. Subsequently, when the initial supply is minted to the recipient address, the _update function detects that the recipient's previous balance was zero and increments the tokenHolder counter again. This results in the counter starting at 2 despite there being only 1 actual token holder. This off-by-one error persists for the lifetime of the contract, rendering the holder count metric permanently inaccurate.
Resolved
#3 medium Issue
Governance Bypass via Redundant Administrative Functions
The contract implements a specific timelock mechanism (requestPause, executePause) intended to provide a delay before critical administrative actions like pausing transfers can be executed, enhancing user trust. However, the contract retains the standard, instant pause() and unpause() functions that are also accessible to the owner. This redundancy effectively nullifies the security guarantees of the timelock, as the owner can simply choose to call the instant functions to bypass the waiting period entirely, rendering the timelock logic deceptive or effectively "dead code."
low Issues | 2 findings
Pending
#1 low Issue
Local variables shadowing (shadowing-local)
Rename the component that shadows another component.
Resolved
#2 low Issue
State Modification in Read-Only Function (Broken Composability)
The isBlacklisted function is designed as a query to check a user's status, but it executes a state change by calling the internal _autoUnblock function (which updates storage and emits events). Because it modifies the state, it cannot be declared as view, making it incompatible with standard integrations where other contracts or interfaces expect a gas-free, read-only mechanism to check blacklist status. This breaks composability and forces external callers to pay gas for simple status checks.
informational Issues | 3 findings
Resolved
#1 informational Issue
Function that are not used (Dead code).
It is recommended to remove the unused code from the contract.
Resolved
#2 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.
Pending
#3 informational Issue
Unused event
It is recommended to remove the unused code from the contract.