Time of Times Info
Time of Times is built around a simple but powerful idea: every day, the world produces one piece of news that defines the moment. We turn that moment into art — one piece created by artificial intelligence, and one by a human artist from our community. The best human-made artwork is chosen through open voting, and both works become rare NFTs, forever capturing that day in digital history.
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 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 ADMIN_ROLE can update the price per TIMES token.
- The ADMIN_ROLE can update the beneficiary address.
- The ADMIN_ROLE can set the max buy limit.
- The PAUSER_ROLE can pause/unpause the contract functionalities.
- The ADMIN_ROLE can mint new tokens not more than the max supply.
- The ADMIN_ROLE can rescue the stuck tokens and ETH from the contract.
- The ADMIN, PAUSER, and DEFAULT ADMIN can renounce roles from the contract.
Note - This Audit report consists of a security analysis of the TimesSeed 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 Time of Times 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 | 3 findings
Resolved
#1 medium Issue
No Refund of Excess ETH Payment in buy Function
The buy function calculates the requiredPayment based on the token price and the requested amount. However, it blindly transfers the entire msg.value (the total ETH sent by the user) to the beneficiary address (line 180). If a user sends more ETH than strictly required for the requested tokens (e.g., accidentally sending 1.5 ETH for 1 ETH worth of tokens), the contract does not refund the difference. The excess ETH is transferred to the beneficiary, causing the user to overpay without receiving extra tokens or their change back.
Resolved
#2 medium Issue
Centralized Control over Token Transfers via Pauser Role
The contract inherits from Pausable and overrides the _update function (lines 242-248) to enforce the whenNotPaused modifier. This allows any account with the PAUSER_ROLE to call pause() (line 142) and freeze all token transfers, including standard ERC20 transfers between users, not just the buy or mint functions. While pausing is a standard security feature for halting presale operations during emergencies, extending this restriction to all token transfers indefinitely gives the PAUSER_ROLE effectively centralized custody over all user assets. Users cannot move or trade their tokens if the contract is paused.
Resolved
#3 medium Issue
Denial of Service Risk via Beneficiary Push Payment Pattern
The contract employs a "push payment" strategy within the buy function (line 180), where incoming ETH from a user is immediately forwarded to the designated beneficiary address in the same transaction. This design creates a critical dependency: the success of every user's purchase transaction is strictly coupled to the beneficiary address's ability to receive ETH. If the admin sets the beneficiary to a smart contract that cannot accept ETH (e.g., a Gnosis Safe or other multisig wallet lacking a receive or fallback function, or a contract that conditionally reverts), the call will return false. Consequently, the buy function will revert with TransferFailed for every single attempt. This effectively creates a complete Denial of Service (DoS) for the entire presale, rendering it impossible for anyone to purchase tokens until the admin manually intervenes to change the beneficiary address.
low Issues | 1 findings
Resolved
#1 low Issue
Missing Validation Check for limit in setMaxBuy Function
The setMaxBuy function allows the admin to set a maximum buy limit for the presale. However, the function does not validate that the limit parameter is greater than zero when enabled is set to true. If an admin accidentally sets limit to 0 while enabling the restriction, the buy function logic (specifically if (msg.value > maxBuyLimit)) will cause all valid purchase attempts (which require msg.value > 0) to revert with MaxBuyExceeded(). This would effectively create a denial of service for the sale.
informational Issues | 2 findings
Resolved
#1 informational Issue
Missing Validation Check for _maxCap Parameter in Constructor
The contract constructor accepts a _maxCap parameter (lines 60-62) which is used to calculate the maxSupply (line 73). However, there is no validation check to ensure that _maxCap is greater than zero. If the contract is deployed with _maxCap set to 0, the maxSupply state variable will be initialized to 0. Consequently, calls to both the buy() (line 160) and mint() (line 204) functions will essentially always fail with MaxSupplyExceeded() for any amount greater than zero, rendering the contract non-functional for token distribution.
Pending
#2 informational Issue
Centralized Price Control and Exposure to ETH Volatility
The contract relies on an admin-controlled setPrice function to define the token cost in ETH (Wei). This introduces two significant risks: Centralization Risk: The admin has full control to manipulate the price at any time, potentially front-running user transactions or effectively pausing the sale by setting an exorbitant price. Market Volatility Exposure: Since the price is fixed in ETH, the actual USD value of the token fluctuates with the crypto market. If ETH price increases significantly, the token becomes more expensive for investors; if ETH crashes, the project raises less capital than intended. Seed rounds typically target a stable USD valuation.