Upscreener Info
Upscreener is a data-driven platform designed to help users discover, analyze, and track emerging crypto projects. It provides insights into market trends, token performance, and on-chain activity to support informed decision-making. The platform combines analytics with a user-friendly interface, simplifying how users identify early-stage opportunities within the crypto market. $UPS is the native utility token of the Upscreener ecosystem. It is used to access platform features such as analytics tools, project visibility enhancements, and future ecosystem integrations. Upscreener aims to provide a transparent and scalable environment where users can explore new projects and monitor their portfolios efficiently.
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 UpscreenerToken contract implements an ERC20 token on the BNB Smart Chain with integrated buy/sell tax mechanics, PancakeSwap V2 auto-swap and distribution, auto-liquidity generation, and staking contract BNB forwarding. The contract is built on OpenZeppelin v5 (ERC20, Ownable, ReentrancyGuard) and is deployed at 0xae5a409773b9a7dd0ae94ff437ac213d8fafba01. While the overall design follows established patterns for taxable tokens on BSC, a few architectural areas warrant attention:
- All DEX interactions (token-to-BNB swaps and liquidity additions) use zero slippage protection and block.timestamp as the deadline, leaving distribution events exposed to sandwich attacks and MEV extraction.
- The distribution pipeline uses empty try/catch blocks for all external calls, meaning swap failures, staking send failures, and liquidity addition failures occur silently without emitting any event - making incident detection and monitoring difficult.
- The core transfer function contains a Checks-Effects-Interactions pattern violation where balance updates occur after external calls; however, the _swapping boolean flag effectively prevents the most critical reentrancy paths, and ownership renouncement has permanently fixed the staking address, eliminating the remaining attack vector.
Ownership Privileges
The ownership of the contract has been renounced - the owner() function returns address(0). All privileged functions are permanently uncallable. Prior to renouncement, the following capabilities existed and are now permanently frozen at their current values:
- Tax rates were adjustable up to a hard cap of 25% - now permanently locked at 3% buy / 3% sell.
- The staking address was changeable - now permanently fixed at 0xe326519b7bd79a43a02fca795e7cff7d1fe4d46f.
- Distribution shares were adjustable - now permanently locked at 2/2/2 (ups/lp/liquidity).
- Fee exclusions, AMM pair mappings, swap thresholds, and swap enable/disable were configurable - all now permanently frozen at their current state.
- Manual distribution (manualDistribute) is permanently unavailable - the contract relies solely on automatic distribution triggered by sell transactions.
- BNB recovery (recoverBNB) and token recovery (recoverTokens) are permanently unavailable - any stuck funds in the contract cannot be administratively retrieved.
- Auto-liquidity LP tokens are now minted to address(0), effectively burning them permanently - no party can remove auto-generated liquidity from the pool.
- The total token supply is fixed at 10,000,000 tokens with no minting capability exposed.
Security Features
The contract implements several positive security features:
- Ownership has been renounced, permanently eliminating all centralization and administrative rug-pull vectors. Tax rates, staking address, fee exclusions, and all other parameters are immutably frozen.
- Tax rates are hard-capped at 25% via an immutable MAX_TAX constant that cannot be bypassed, even by the contract owner (if one existed).
- The token supply is fixed at deployment with no exposed minting capability - the total supply cannot be inflated.
- The contract inherits OpenZeppelin's ReentrancyGuard and employs a _swapping boolean flag to prevent recursive distribution triggers and suppress tax during internal swap operations.
- The contract cannot recover its own tokens (address(this) is excluded from recoverTokens), preventing administrative extraction of the tax pool.
- Auto-generated LP tokens are permanently burned to address(0) due to ownership renouncement, ensuring auto-liquidity cannot be removed from the pool.
- Distribution swap sizes are bounded by maxSwapAmount (0.5% of supply) and swapThreshold (0.05% of supply), limiting per-transaction market impact.
- No blacklist functionality exists - no address can be prevented from transacting.
Note - This audit report consists of a security analysis of the UpscreenerToken smart contract deployed on the BNB Smart Chain. This analysis did not include economic analysis of the contract's tokenomics, nor did it include an audit of the staking contract at 0xe326519b7bd79a43a02fca795e7cff7d1fe4d46f. We only audited the main token contract for the UpscreenerToken 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
Acknowledged
#1 medium Issue
Zero Slippage Protection on DEX Interactions Enables Sandwich Attacks
Both _swapTokensForBNB and _addLiquidity pass 0 for all minimum output amounts (amountOutMin, amountTokenMin, amountETHMin) and use block.timestamp as the swap deadline. This means the contract will accept any amount of output regardless of how unfavorable the rate is. MEV bots can sandwich every distribution transaction by front-running with a large buy to inflate the price, letting this contract swap at the inflated rate (receiving significantly less BNB), then back-running with a sell to profit from the difference. This directly extracts value from the staking rewards and liquidity pool that should benefit token holders.
Acknowledged
#2 medium Issue
Silent Failure Pattern in Distribution Pipeline
All three critical operations in _swapAndDistribute use try/catch with empty catch blocks: the token-to-BNB swap, the staking BNB send (silently ignores success == false), and the liquidity addition. When any of these fails, execution continues without notification. Failed swaps leave tokens stuck in the contract, failed staking sends leave BNB stuck, and failed liquidity additions waste both tokens and BNB - all without emitting any event, making monitoring and debugging impossible.
low Issues | 7 findings
Acknowledged
#1 low Issue
Checks-Effects-Interactions Violation in Core Transfer Logic
During a sell, _update calls _swapAndDistribute() which performs external calls to PancakeSwap (swap and addLiquidity) and a low-level BNB send to stakingAddress. After these external calls return, _update continues to modify _balances via super._update. This is a Checks-Effects-Interactions violation. The _swapping boolean flag effectively prevents recursive distribution triggers, suppresses tax on internal swaps, and blocks the most damaging reentrancy paths.
Pending
#2 low Issue
Hardcoded Gas Limit on Staking Contract Call
The _sendToStaking function uses a hardcoded gas limit of 300,000 on the low-level call to stakingAddress. While this mitigates return-bomb attacks, it may be insufficient for a complex staking contract that needs to process BNB distribution internally. If the staking contract legitimately requires more gas, the call will silently fail and the BNB will remain stuck in the token contract.
Acknowledged
#3 low Issue
Divide-Before-Multiply Precision Loss in Distribution Calculation
The distribution calculation divides tokensForLiquidity by 2 (truncating), then uses that truncated result in a multiplication with bnbReceived. This divide-before-multiply pattern causes minor precision loss. With 18-decimal token amounts and typical swap sizes (thousands of tokens), the rounding dust per transaction is negligible. The edge case where tokensForLiquidity equals 1 (causing liquidityTokenHalf to become 0 and the liquidity portion to be skipped) is unlikely under normal operating parameters.
Resolved
#4 low Issue
ETH Sent to Owner-Controlled Arbitrary Address Without Timelock
The _sendToStaking function sends BNB to stakingAddress, which could be changed by the owner via setStakingAddress() with no timelock or multi-signature requirement. Combined with recoverBNB(), the owner could drain any accumulated BNB from the contract. This was a centralization and trust risk inherent in the Ownable design.
Resolved
#5 low Issue
Fee Exclusion Not Removed From Previous Staking Address
When setStakingAddress is called, it grants fee exclusion to the new staking address but does not revoke it from the old one. If the staking address were changed multiple times, all previous staking addresses would remain permanently excluded from fees.
Resolved
#6 low Issue
Auto-Liquidity LP Tokens Sent to Owner Instead of Being Locked
In _addLiquidity, the LP tokens generated from auto-liquidity are sent to owner(). With an active owner, this would allow the owner to accumulate LP tokens from every auto-liquidity event and remove that liquidity from the pool at any time.
Resolved
#7 low Issue
Unchecked ERC-20 Transfer Return Value
The recoverTokens function calls IERC20(token).transfer(to, balance) without checking its return value. Non-standard ERC-20 tokens that return false on failure instead of reverting would cause the TokensRecovered event to be emitted even though the tokens remain in the contract.
informational Issues | 2 findings
Acknowledged
#1 informational Issue
Dead Code - Inherited _burn Function Never Used
The ERC20._burn function is inherited from OpenZeppelin but never called anywhere in UpscreenerToken. Similarly, Context._msgData and Context._contextSuffixLength are unused. This dead code increases the deployed bytecode size slightly but has no functional or security impact.
Acknowledged
#2 informational Issue
Unused ERC-721 and ERC-1155 Error Interfaces Included
The flattened file includes IERC721Errors and IERC1155Errors interfaces from OpenZeppelin's draft-IERC6093.sol. These interfaces define 15 error types that are completely irrelevant to an ERC-20 token and are never referenced by any code in the contract.