SurvivorCoin Info
A community‑driven digital asset designed with honesty, fairness, and long‑term sustainability at its core. SURVC is fully verified on Etherscan, audited by Solidproof, and engineered with real mathematics — not hype — to protect investors and reward long‑term holders.
Team and KYC Verification
The team has securely submitted their personal information to SolidProof.io for verification.
In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.
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 can blacklist addresses
It is 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 enable trading (one-time only).
- The owner can blacklist wallets from transferring tokens (cannot blacklist owner, contract, or pair).
- The owner can set the Uniswap pair address (one-time only).
- The owner can change the reflection fee (capped at 10%).
- The owner can exempt any address from fees and buy-side limits.
- The owner can toggle wallet-to-wallet fee mode on/off.
- The owner can change
maxWalletandmaxTxlimits via predefined round tiers. - The owner can exclude addresses from receiving reflection rewards.
- The owner can include previously excluded addresses back into reflection rewards.
- The owner can configure presale parameters (wallet, prices, allocation) at any time.
- The owner can activate or deactivate the presale.
- The owner can set accepted payment tokens (ETH/USDT).
- The owner can change the USDT token address (unlimited times).
- The owner can fund the contract with tokens for the presale.
- The owner can transfer ownership to a new address.
- The owner can renounce ownership entirely.
Note - This Audit report consists of a security analysis of the SurvivorCoin 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 SurvivorCoin 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
high Issues | 2 findings
Resolved
#1 high Issue
Repeated enableTrading() Calls Reset launchBlock, Re-activating Trading Freeze
The enableTrading() function does not enforce a one-time execution guard. Each call sets tradingEnabled = true and overwrites launchBlock with the current block.number. Since the _beforeTokenTransfer hook blocks all non-owner transfers when block.number < launchBlock + 5, a subsequent call to enableTrading() resets this window and re-activates the 5-block trading freeze. The owner can exploit this to repeatedly freeze all non-owner trading at will — each call introducing a new 5-block blackout window where every user transaction reverts with "Sniper protection". This effectively gives the owner an undisclosed pause mechanism that can be triggered without limit, preventing users from selling during critical price movements and trapping liquidity.
Pending
#2 high Issue
USDT transferFrom Non-Standard Return Value Renders Presale USDT Purchases Permanently Non-Functional
The buyPresaleUSDT() function on line 478 invokes IERC20Minimal(USDT_ADDR).transferFrom() through a custom interface that declares the function as returning bool. However, the USDT (Tether) contract deployed on Ethereum mainnet at 0xdAC17F958D2ee523a2206206994597C13D831ec7 does not conform to the ERC-20 return value specification — its transferFrom function is declared as public with no returns (bool) clause and emits no return data. When Solidity 0.8.x executes this external call, the ABI decoder attempts to decode the empty return data (0 bytes) as a bool (32 bytes). Since the return data length is insufficient, the decoder reverts the transaction regardless of whether the underlying USDT transfer succeeded. This has been verified against the actual deployed USDT source code on Ethereum mainnet, where both StandardToken.transferFrom (line 1741) and TetherToken.transferFrom (line 1920) explicitly omit any return value. As the SurvivorCoin contract is already deployed at 0x1c617D4D1021fD8D4bEAF681b5520EB032FDc1cA without a proxy upgrade pattern, this function is permanently broken and cannot be patched.
medium Issues | 4 findings
Resolved
#1 medium Issue
setUniswapPair Can Be Changed Post-Launch to Bypass All Buy-Side Protections
The setUniswapPair() function allows the owner to change the Uniswap pair address at any time without restriction. All buy-side protections — maxWallet, maxTx, and the 30-second cooldown — are gated behind the condition uniswapPairAddress != address(0) && from == uniswapPairAddress. If the owner sets the pair address to address(0) or an arbitrary non-pair address after launch, this condition evaluates to false, effectively disabling all buy-side limits. Since no event is emitted on pair change, this can be done silently, allowing insider wallets to accumulate tokens beyond the intended limits without detection. The pair address can then be restored to its original value, leaving no obvious on-chain trace of the temporary bypass. This constitutes a stealth rug-pull vector through selective limit manipulation.
Pending
#2 medium Issue
Unrestricted Blacklist Allows Indefinite Freezing of User Funds
The blacklist() function grants the owner unrestricted authority to blacklist any address at any time with no expiration, no cooldown, and no on-chain event emission. Once an address is blacklisted, it is permanently unable to send or receive tokens, as enforced by the require(!isBlacklisted[from] && !isBlacklisted[to], "Blacklisted") check in _beforeTokenTransfer. There is no time-bound mechanism, no maximum blacklist duration, and no governance or multisig requirement. The owner can also blacklist critical addresses such as the Uniswap pair itself, effectively halting all trading for every holder. Since no event is emitted, users and monitoring tools have no reliable way to detect when an address has been blacklisted or un-blacklisted. This creates a significant centralization risk where a single private key can freeze any user's funds indefinitely without recourse.
Pending
#3 medium Issue
isFeeExempt Mapping Bypasses Buy-Side Limits in Addition to Fee Exemption
The isFeeExempt mapping on line 102 is intended to exempt designated addresses from the 4% reflection fee. However, in the _transfer function on line 338, the same mapping is used as the gate for all buy-side protections — maxWallet, maxTx, and the 30-second cooldown are all nested inside an if (!isFeeExempt[recipient]) check. This means that any address marked as fee-exempt via the owner-controlled setFeeExempt() function automatically bypasses every buy-side restriction, not just the fee. The owner can silently call setFeeExempt(anyWallet, true) and that wallet gains the ability to buy unlimited tokens in a single transaction, exceed the maxWallet cap, and trade without any cooldown. Since fee exemption and limit exemption are conceptually distinct protections, combining them into a single mapping creates an undisclosed privilege escalation path that undermines the contract's stated anti-whale protections.
Pending
#4 medium Issue
Presale Bypasses maxWallet / maxTx
When tokens are delivered during the presale, the _transfer() call uses address(this) as the sender and the buyer as the recipient. Because the sender is the contract address and not uniswapPairAddress, the isBuy flag on line 335 evaluates to false. This causes the entire buy-side protection block — which includes the maxWallet cap, the maxTx limit, and the 30-second cooldown — to be completely skipped for all presale token deliveries. A single buyer can therefore purchase the full presale allocation in one transaction, accumulating a balance that vastly exceeds the maxWallet ceiling. Once enableTrading() is called and DEX trading begins, this pre-positioned whale already holds a balance above the wallet cap that organic DEX buyers are forced to respect. Since sell-side transfers have no corresponding limits (see M2), the whale can then dump the entire accumulated position in a single sell transaction. The anti-whale protections that the contract advertises to retail buyers are architecturally bypassed for anyone who participated in the presale.
low Issues | 5 findings
Resolved
#1 low Issue
Missing zero or dead address check.
It is recommended to check that the address cannot be set to zero or dead address.
Pending
#2 low Issue
Buy-Side Limits Bypassed via DEX Aggregator Routing
All buy-side protections — maxWallet, maxTx, and the 30-second cooldown — are gated behind the condition from == uniswapPairAddress on line 60. This check only matches direct swaps where the Uniswap pair contract itself is the token sender. When a user purchases tokens through a DEX aggregator such as 1inch, Paraswap, or any multi-hop routing contract, the aggregator's intermediary contract becomes the from address rather than the Uniswap pair. Since from != uniswapPairAddress, the condition evaluates to false and the entire buy-side protection block is skipped. This allows any user to acquire an unlimited number of tokens in a single transaction, exceed the maxWallet cap, and completely avoid the cooldown — simply by routing through an aggregator instead of swapping directly on Uniswap.
Pending
#3 low Issue
Presale and Trading Can Be Active Simultaneously, Enabling Arbitrage
There is no mutual exclusion between the presaleActive flag and the tradingEnabled flag. The owner can call enableTrading() while presaleActive remains true, or can call setPresaleActive(true) after trading has already been enabled. When both are active simultaneously, users can buy tokens through the presale at the fixed presalePriceWeiPerToken and immediately sell them on the DEX at the market price. If the presale price is below the current market price, this creates a risk-free arbitrage opportunity that drains the presale allocation at below-market rates. Intended presale buyers receive fewer tokens as the allocation is consumed by arbitrageurs, and the price disparity undermines fair token distribution.
Pending
#4 low Issue
configurePresale Parameters Can Be Modified During Active Presale
The configurePresale() function on line 387 allows the owner to change the presale wallet, token prices (ETH and USDT), and total allocation at any time, including while the presale is active and users are actively purchasing tokens. There is no require(!presaleActive) guard. A user who sees a presale price of X and submits a transaction may have their purchase executed at a different price if the owner calls configurePresale() in the same block or between the user's approval and purchase transactions. Additionally, the presale wallet can be changed mid-sale, potentially redirecting funds to a different address without buyers' knowledge. The allocation can also be reduced below presaleTokensSold, creating an inconsistent state.
Pending
#5 low Issue
No Sell-Side maxTx or Rate Limit Allows Unguarded Whale Dump
The maxTx check on line 345 and the 30-second cooldown on line 341 only execute inside the if (isBuy) block on line 337. When isSell is true — meaning the recipient is the Uniswap pair — there are zero protections applied: no maximum transaction size, no cooldown between sells, and no rate limiting of any kind. This asymmetry means that while buys are constrained to small increments with mandatory delays, a holder can liquidate their entire position in a single sell transaction of unlimited size. A whale — whether through presale accumulation (M1), owner-distributed tokens, or aggregation across multiple wallets — can dump their full balance into the liquidity pool in one block, causing maximum price impact. The buy-side protections create a false sense of security for retail holders who believe the contract prevents whale manipulation, when in reality only one direction of trade is guarded.
optimization Issues | 1 findings
Pending
#1 optimization Issue
Unbounded _excluded Array Causes Linear Gas Growth on Every Transfer
The _getCurrentSupply() function on line 265 iterates the entire _excluded array to calculate the adjusted reflection supply. This function is called on every single token transfer via _getRate() on line 260, which is invoked within _transfer() on line 352. Each call to excludeFromReward() pushes a new address onto the _excluded array (line 289) with no upper bound. As the array grows, the gas cost of every transfer increases linearly. With enough excluded addresses, the gas required for a standard transfer can exceed the block gas limit, rendering all token transfers — buys, sells, and wallet-to-wallet — permanently impossible. This is a known vulnerability pattern in RFI-style reflection tokens. While only the owner can call excludeFromReward(), an accidental or malicious accumulation of excluded addresses can freeze the entire token economy.
informational Issues | 3 findings
Pending
#1 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.
Resolved
#2 informational Issue
Missing events
It is recommended to emit all the critical changes.
Pending
#3 informational Issue
No Rescue Function for ETH or ERC20 Tokens Accidentally Sent to Contract
The contract has no rescueETH() or rescueERC20() function to recover assets that become trapped in the contract address. ETH sent to the contract through mechanisms that bypass receive() — such as selfdestruct from another contract or coinbase rewards — cannot be withdrawn and is permanently locked. Similarly, any ERC20 tokens sent directly to the contract address by mistake have no recovery path. Additionally, because the contract cannot be excluded from rewards (line 282 explicitly blocks it with require(account != address(this))), it passively accumulates reflection tokens from every taxed trade that occurs on the DEX. Over time, balanceOf(address(this)) grows beyond the original presale allocation, but these accrued reflection tokens have no extraction function and are permanently locked inside the contract.