Temptation Token Info
Temptation Token is a crypto-powered voting game built on the Base blockchain. Each week, players vote $TTS on their favorite profiles in a provably fair, weighted competition. Your votes buy lottery tickets — more votes means better odds, but anyone can win. The top voter on the winning profile takes 40% of the weekly prize pool. Winners take 40%. 10% goes to the Polaris Project anti-human trafficking nonprofit. Losing votes are permanently burned — reducing TTS supply every single week.
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 can mint
It is 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.
Token transfer can be locked
Owner can lock user funds with owner functions.
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.
Smart Contract Analysis Statement
Contract Analysis
The Temptation Token (TTS) contract implements an ERC20 token with a 1% transfer tax, UUPS upgradeable proxy pattern, role-based access control (AccessControl), pausability, and a declared blacklist mechanism. The contract is deployed on Base and built on OpenZeppelin v4.9.3 upgradeable libraries. While the overall design follows established patterns for upgradeable tokens, several areas require attention:
- ERC20 Specification Violation: Zero-value transfers revert on non-exempt paths due to the minimum 1-wei tax floor causing an arithmetic underflow. This violates the EIP-20 MUST requirement that zero-value transfers succeed, and can break integrations with DeFi protocols, DEX routers, and yield aggregators on Base.
- Unbounded Minting: The mint() function has no supply cap. A compromised or misused MINTER_ROLE can inflate the token supply without any limit beyond the initial 69 billion tokens minted at deployment.
- Redundant Code in Transfer Hook: The _beforeTokenTransfer hook contains dead tax logic that computes a fee but never applies it. The actual tax is handled correctly in the transfer/transferFrom overrides. This wastes gas and creates confusion about the contract's behavior.
- Non-Functional Blacklist: The blacklisted mapping is declared and checked during transfers, but no setter function exists. The blacklist feature is completely inoperative in the current deployment.
Ownership Privileges
The ownership of the contract has been structured through AccessControl with four distinct roles, all initially granted to the deployer address. The admin retains full privileges including:
- Upgrade Authority (UPGRADER_ROLE): Can upgrade the contract to an entirely new implementation via the UUPS proxy pattern, effectively allowing any behavior change including fee modification, balance manipulation, or removal of security features.
- Minting Authority (MINTER_ROLE): Can mint an unlimited amount of tokens to any address with no supply cap enforced.
- Pause Authority (PAUSER_ROLE): Can pause and unpause all token transfers, minting, and burning globally.
- Admin Authority (DEFAULT_ADMIN_ROLE): Can grant and revoke any role, change the treasury address, and modify tax exemptions for any address.
- Limitation: The tax rate is hardcoded as a constant (1% / 100 BPS) and cannot be changed without a contract upgrade.
- Limitation: The admin cannot blacklist addresses in the current implementation due to the missing setter function.
- Limitation: The admin cannot directly modify user balances or allowances outside of the standard ERC20 transfer/mint/burn flows.
- Limitation: Token holders can burn their own tokens at any time without requiring admin permission.
Security Features
The contract implements several positive security features:
- UUPS Proxy Guards: The upgrade functions (upgradeTo, upgradeToAndCall) are protected by the onlyProxy modifier and a dedicated UPGRADER_ROLE, preventing unauthorized implementation changes.
- Role Separation: The contract uses OpenZeppelin AccessControl with four distinct roles rather than a single owner, enabling fine-grained permission management and the ability to distribute roles across multiple addresses or multi-sigs.
- Pausability: An emergency pause mechanism can halt all token transfers in the event of a security incident, providing a circuit-breaker for the ecosystem.
- Tax Exemption System: The tax exemption mechanism correctly manages exemptions when the treasury address is changed, automatically revoking exemption from the old treasury and granting it to the new one.
- Standard Library Usage: The contract is built entirely on audited OpenZeppelin v4.9.3 upgradeable contracts, minimizing the risk of low-level implementation errors in core ERC20 and access control logic.
- Liquidity Lock: Liquidity has been locked for 12 months on Team.Finance (external claim, not verifiable from contract code).
Note - This Audit report consists of a security analysis of the Temptation Token (TTS) smart contract deployed at 0x5570eA97d53A53170e973894A9Fa7feb5785d3b9 on Base. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main TTS token contract for the Temptation Token team. The other associated contracts (TTSVoting, TTSStaking, TTSAirdrop, TTSWinnerNFT) were not audited as part of this engagement. 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
Pending
#1 medium Issue
ERC20 Compatibility
In both transfer() and transferFrom(), when neither side is tax-exempt, tax is computed as (amount * 100) / 10000 and floored to at least 1 via if (tax == 0) tax = 1. If amount is 0, tax becomes 1, and amount - tax (0 - 1) causes an arithmetic underflow revert under Solidity 0.8+ checked arithmetic. EIP-20 explicitly mandates: 'Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.' This breaks core ERC20 composability. DeFi protocols, DEX routers, and yield aggregators routinely perform zero-value transfers to ping contracts, update state, or claim rewards. Reverting on these calls can cause integration failures or lock user funds in external protocols.
Pending
#2 medium Issue
Missing Supply Cap
The mint() function allows the MINTER_ROLE holder to mint an arbitrary amount of tokens to any address with no upper bound. There is no MAX_SUPPLY constant or check. If the MINTER_ROLE is compromised or misused, the entire token supply can be inflated without limit. The INITIAL_SUPPLY of 69 billion tokens is fixed at initialization, but post-initialization minting is completely unbounded.
Pending
#3 medium Issue
Centralization Risk
On initialization, msg.sender receives ALL four roles: DEFAULT_ADMIN_ROLE, PAUSER_ROLE, MINTER_ROLE, and UPGRADER_ROLE. This single account can pause/unpause all transfers, mint unlimited tokens, upgrade the contract to arbitrary new code, change the treasury, and modify tax exemptions. Combined with the UUPS upgrade pattern, a compromised admin can deploy a malicious implementation that steals all tokens or changes any contract behavior unilaterally.
low Issues | 5 findings
Pending
#1 low Issue
Dead Code / Redundant Logic
The _beforeTokenTransfer hook (lines 2583-2585) computes a tax amount and calls super._beforeTokenTransfer(from, treasury, tax). However, _beforeTokenTransfer is a validation hook - it does NOT transfer tokens. The super call merely re-runs the ERC20PausableUpgradeable pause check for a hypothetical transfer that never happens. The actual tax collection is performed correctly in the transfer/transferFrom overrides. This dead code wastes approximately 2,000-5,000 gas per non-exempt transfer and creates significant confusion about where the tax logic actually lives.
Pending
#2 low Issue
Missing Event Emission
The setTreasury() function changes the treasury address and modifies tax exemptions for both old and new treasury, but does not emit a dedicated TreasuryUpdated event. Additionally, the internal _taxExempt modifications bypass setTaxExempt(), so no TaxExemptUpdated events are emitted either. Off-chain indexers and monitoring tools cannot track treasury changes.
Pending
#3 low Issue
Locked Ether
The inherited upgradeToAndCall() function (from UUPSUpgradeable, line 2494) is marked payable. However, because it is protected by the onlyProxy modifier and _authorizeUpgrade requires UPGRADER_ROLE, only the upgrade admin can actually reach this function with ETH attached during a valid upgrade transaction. A normal user or attacker attempting to send ETH will have their transaction revert, automatically refunding their ETH. The contract has no receive(), fallback(), or withdrawal function, so any ETH attached by the admin during a legitimate upgrade becomes permanently locked. The risk profile is limited to admin operational error, not general user error.
Pending
#4 low Issue
Unprotected Implementation
The TTS contract uses UUPS upgrade pattern but does not include a constructor calling _disableInitializers(). The implementation contract behind the proxy can be initialized by anyone. An attacker who initializes the implementation directly gains all roles on the implementation contract. While the upgrade functions are protected by the onlyProxy modifier (preventing the attacker from calling upgradeTo directly on the implementation), this remains a defense-in-depth best-practice violation flagged by both Slither and OpenZeppelin documentation.
Pending
#5 low Issue
Non-Functional Feature
The contract declares mapping(address => bool) public blacklisted and checks it in _beforeTokenTransfer with require(!blacklisted[from]) and require(!blacklisted[to]). However, there is no function anywhere in the contract to set or modify this mapping. Every address maps to false by default, making the blacklist completely inoperative.
optimization Issues | 1 findings
Pending
#1 optimization Issue
Gas Optimization
In transfer() at line 2589, both msg.sender != address(0) and to != address(0) are redundant. The zero address cannot initiate transactions, and if to is address(0) the condition simply falls through to super.transfer() where OpenZeppelin's _transfer reverts natively. Similarly in transferFrom() at line 2599, from != address(0) and to != address(0) are redundant for the same reason - a false condition falls through to super.transferFrom() which delegates to _transfer where both addresses are validated. All four checks waste gas on every non-exempt call.
informational Issues | 3 findings
Pending
#1 informational Issue
Potential Future Bypass
The _beforeTokenTransfer hook returns early at line 2578 if either from or to is tax-exempt. The blacklist checks at lines 2580-2581 are placed after this early return. This means a blacklisted address could freely transact with any tax-exempt address. Currently not exploitable because the blacklist mapping has no setter function, but if one is added in a future upgrade, this ordering would create a bypass.
Pending
#2 informational Issue
Unchecked Return Value
In transfer(), the return value of super.transfer(treasury, tax) at line 2592 is ignored. Similarly in transferFrom(), super.transferFrom(from, treasury, tax) at line 2602 is ignored. OpenZeppelin ERC20 always returns true or reverts, making this practically safe, but ignoring return values violates best practices.
Pending
#3 informational Issue
Edge Case Behavior
The tax calculation enforces if (tax == 0) tax = 1 (lines 2584, 2591, 2601). For transfers of less than 100 wei, the 1% calculation rounds to 0, so the minimum 1-wei tax is applied. For a 1-wei transfer this is a 100% tax; for a 50-wei transfer this is 2%. While practically irrelevant for normal operations (tokens have 18 decimals), edge-case integrations dealing in very small amounts could be affected.