UnchainedLab Info
Pick products, upload your art, launch in minutes. Accept crypto payments, ship worldwide. Built for Web3 communities.
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 renounced
The contract does not include owner functions that allow post-deployment modifications.
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.
Smart Contract Analysis Statement
Contract Analysis
The Unchained Lab contract implements an ERC20 token with a fixed supply that is minted in full to the deployer at the moment of deployment, together with a burn capability for holders, and with no owner, no minting after deployment, no transfer fees, and no proxy.
Ownership Privileges
The ownership of the contract has been omitted entirely by design. The contract was deployed without an owner, an administrator, or any privileged function, so there is no key whose compromise could harm holders, and there is nothing to renounce because no control ever existed. In practice this means the following powers are absent:
- There is no ability to mint new tokens after deployment - the supply is set once by the initial mint and cannot grow.
- There is no ability to pause, freeze, or lock transfers.
- There is no ability to blacklist, allow-list, or otherwise restrict any address.
- There is no ability to set or change a transfer fee or tax.
- The total supply can only ever decrease, and only through voluntary burning by holders.
- Every transfer moves the exact amount that was sent, with no fee, reflection, or rebasing.
- The contract is not upgradeable, so its logic can never be replaced or altered.
- Transfers are always enabled, so the contract cannot be turned into a honeypot.
Security Features
The contract implements several positive security features:
- It is built directly on a widely used and well-reviewed token implementation, which lowers the risk of subtle accounting mistakes.
- It makes no external calls and exposes no callback hooks, which removes reentrancy and related cross-contract risks by construction.
- All arithmetic relies on the compiler's built-in overflow and underflow protection, and the few unchecked sections are provably safe.
- The core properties were confirmed through symbolic analysis and extensive fuzzing: the sum of all balances always equals the total supply, the supply can never grow beyond the initial mint, and a burn reduces the supply by exactly the amount burned.
One low severity observation is noted for completeness: the token uses the standard ERC20 approval method, which carries the well-known allowance race condition that affects most ERC20 tokens. It does not allow anyone to move more than an approved amount and does not affect supply, and users can avoid it by setting an allowance to zero before changing it. A small number of informational items relate to the housekeeping of the flattened source, such as a confusing combined compiler version line, unused declarations brought in by flattening, brief documentation, and the concentration of the whole supply in a single address. None of these affect the safety of the token.
Note - This Audit report consists of a security analysis of the Unchained Lab smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Unchained Lab 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
optimization Issues | 2 findings
Pending
#1 optimization Issue
Constructor not marked payable
Marking the constructor as payable removes the compiler's non-payable value check and saves a small amount of deployment gas. For a token this is not worth the loss of clarity and the ability to accidentally send ether at deployment.
Pending
#2 optimization Issue
Compound assignment on a storage variable
Updating the total supply with a compound assignment can be marginally more expensive than an explicit addition on some compiler versions. The occurrence is in the inherited library update function that handles mint, burn, and transfer.
informational Issues | 5 findings
Pending
#1 informational Issue
Flattened source with a complex multi-version pragma
The pragma combines several version constraints that were merged during flattening. Their intersection is exactly 0.8.34, so the contract is in practice pinned to a single compiler and compiles correctly, but the form is confusing to readers and to analysis tools.
Pending
#2 informational Issue
Dead code and unused declarations from flattening
Two context helper functions are never used, and the error interfaces for non-fungible and multi-token standards plus several fungible-token error entries are declared but unused by this token (fifteen unused error declarations in total). They do not reach the deployed bytecode and pose no security risk, but they enlarge the source and add review overhead.
Pending
#3 informational Issue
Sparse, mixed-language documentation and a generic contract name
The only project-specific documentation is a comment written in Italian on the token contract, and the public functions rely on inherited library documentation. The contract is named generically while the file is named after the ticker. None of this affects behavior, but it makes the contract harder to read for a broad audience.
Pending
#4 informational Issue
License not published on the verified contract page
The source header declares the MIT license, but the block explorer shows the license as not available. This is a metadata inconsistency with no security impact.
Pending
#5 informational Issue
Entire supply held by a single address
The constructor mints the full supply to the deployer, and the explorer shows a single holder. The contract grants no special power over other holders, so this is not a code-security defect, but the concentration of the entire supply in one address is a market and distribution consideration that holders and integrators should be aware of.