Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →
YFSX Token logo

YFSX Token

Audit name:

[SCA] YFSX Token | YFSX Token Audit | Jul2026

Date:

Jul 29, 2026

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the YFSX Token team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

YfsxCoin (YFSX) is a fixed-supply, nine-decimal reflection-style fee-on-transfer token implementing IERC20 and intended for BNB Smart Chain. Transfers apply configurable reflection and liquidity-style fees, with optional automated token-to-BNB swaps, marketing distributions, and buybacks through a Uniswap-V2-compatible DEX pair.

Document

NameSmart Contract Code Review and Security Analysis Report for YFSX Token
Audited ByIvan Bondar
Approved ByKerem Solmaz
Websitehttps://yfsx.vin/→
Changelog27/07/2026 - Preliminary Report
29/07/2026 - Final Report
PlatformBSC
LanguageSolidity
TagsFungible Token; Token Standards used (ERC20/BEP20); Centralization; Incentives
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for YFSX Token
    Audited By
    Ivan Bondar
    Approved By
    Kerem Solmaz
    Website
    https://yfsx.vin/→
    Changelog
    27/07/2026 - Preliminary Report
    29/07/2026 - Final Report
    Platform
    BSC
    Language
    Solidity
    Tags
    Fungible Token; Token Standards used (ERC20/BEP20); Centralization; Incentives
    Methodology
    https://docs.hacken.io/methodologies/smart-contracts→

Review Scope

Deployed address YFSXhttps://bscscan.com/token/0xb7ec60cf8ef96ed48b119277bc7a954a87f27388→

Audit Summary

17Total Findings
0Resolved
7Accepted
10Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are partially missed.

  • Technical description is not provided.

  • The only available project documentation is the whitepaper published on the project website.

Code quality

  • The code duplicates commonly known contracts instead of reusing them.

  • Several template code patterns were found.

  • No project repository or development environment was shared.

Test coverage

No project tests were provided.

The client shared deployed code without a repository or test suite.

System Overview

YfsxCoin implements the IERC20 interface with a dual balance model (_rOwned / _tOwned) in which the reflection fee component reduces the global _rTotal so remaining included holders receive a proportional share, while the liquidity-style fee accrues as tokens to address(this). The constructor assigns the full supply of 19,999 tokens (9 decimals) to the deployer, creates a token/WBNB pair via the PancakeSwap V2 router, and marks the deployer owner and the contract as fee-exempt. Default constructor values are a 0% reflection tax (_taxFee), a 3% liquidity-style fee (_liquidityFee), marketingDivisor of 2, minimumTokensBeforeSwap of 50,000 YFSX, _maxTxAmount of 100,000,000 YFSX, swapAndLiquifyEnabled true, and buyBackEnabled false. Those defaults are mutable by the owner through dedicated setters and the presale helpers.

On transfers to the DEX pair, when swapAndLiquifyEnabled is true and the contract’s token balance meets minimumTokensBeforeSwap, accrued fee tokens are swapped for BNB and a marketing portion is forwarded via swapTokens. If buyBackEnabled is true and contract BNB exceeds 1 BNB, one percent of the BNB balance capped by buyBackUpperLimit is used to buy tokens sent to the immutable deadAddress. A private addLiquidity helper that would call addLiquidityETH with LP tokens to owner exists but has no call site, so liquidity-fee tokens are fully swapped for BNB rather than added as pool liquidity. Fee application is skipped when the sender or recipient is in _isExcludedFromFee. Ownership is provided by Ownable, including temporary ownership lock via lock / unlock, with owner setters for fees, limits, marketing parameters, and swap/buyback toggles. transferOwnership updates _owner only and does not migrate _isExcludedFromFee to the new owner. The contract does not call or depend on other project tokens.

On the deployed BSC instance, ownership has been renounced: owner() is address(0) and _previousOwner is also address(0), so unlock cannot restore an owner. All onlyOwner setters are permanently inaccessible. Live fee, threshold, flag, marketing, and exemption state are therefore frozen at the values present at renouncement.

Files in Scope

  • YfsxCoin.sol — Defines YfsxCoin, the YFSX IERC20 token with reflection accounting, fee-on-transfer logic, DEX pair creation, automated swap/marketing/buyback paths, and owner configuration. Also contains supporting Context, Ownable, SafeMath/Address libraries, and Uniswap V2 interfaces used by the token.

Privileged roles

  • owner (inherited from Ownable): Full administrative control over ownership, fee/reward exemptions, fee parameters, swap/buyback configuration, and presale mode. Transfers involving the owner as sender or recipient are exempt from _maxTxAmount.

    • Can call renounceOwnership to permanently set ownership to the zero address.

    • Can call transferOwnership to assign ownership to a new non-zero address without automatically updating _isExcludedFromFee for the new owner.

    • Can call lock to store the current owner as _previousOwner, set _owner to the zero address, and set _lockTime to block.timestamp + time.

    • Can call excludeFromReward to exclude an account from reflection rewards.

    • Can call includeInReward to re-include an excluded account in reflection rewards.

    • Can call excludeFromFee to exempt an account from transfer taxes.

    • Can call includeInFee to remove an account’s transfer-tax exemption.

    • Can call setTaxFeePercent to set _taxFee.

    • Can call setLiquidityFeePercent to set _liquidityFee.

    • Can call setMaxTxAmount to set _maxTxAmount.

    • Can call setMarketingDivisor to set marketingDivisor.

    • Can call setNumTokensSellToAddToLiquidity to set minimumTokensBeforeSwap.

    • Can call setBuybackUpperLimit to set buyBackUpperLimit with the input scaled by 10**18.

    • Can call setMarketingAddress to update marketingAddress.

    • Can call setSwapAndLiquifyEnabled to enable or disable automatic swap-and-liquify.

    • Can call setBuyBackEnabled to enable or disable automatic buyback.

    • Can call prepareForPreSale to disable swap-and-liquify, zero _taxFee and _liquidityFee, and raise _maxTxAmount.

    • Can call afterPreSale to re-enable swap-and-liquify, set _taxFee to 2, _liquidityFee to 9, and set _maxTxAmount to the post-presale value.

  • previous owner (inherited from Ownable): Address recorded in _previousOwner when lock is executed; sole party able to restore ownership after the lock period.

    • Can call unlock when msg.sender _previousOwner and block.timestamp > _lockTime to restore _owner to _previousOwner.

  • marketing recipient: Designated BNB recipient for the marketing share of swapped fees; initially hardcoded at 0x48064d1d7B832Df7e36a8812E34977D0435C1E94, updatable by the owner via setMarketingAddress.

    • Receives BNB from swapTokens via transferToAddressETH equal to transferredBalance.div(_liquidityFee).mul(marketingDivisor).

  • fee-exempt accounts: Addresses marked in _isExcludedFromFee; the constructor sets this for the deployer owner and address(this), and the owner may add or remove accounts via excludeFromFee / includeInFee.

    • Transfers where the sender or recipient is fee-exempt skip reflection and liquidity-style fees in _tokenTransfer.

  • reward-excluded accounts: Addresses marked in _isExcluded and tracked in _excluded; managed solely by the owner via excludeFromReward / includeInReward.

    • Hold fixed _tOwned balances, do not receive reflection redistribution, and are subtracted when _getCurrentSupply computes the reflection rate.

Potential Risks

External DEX dependency: YfsxCoin hardcodes PancakeSwap RouterV2 at 0x10ED43C718714eb63d5aA57B78B54704E256024E and binds uniswapV2Pair at construction. Fee conversion and buyback paths depend on that external router and pair. After renouncement, neither the router nor the pair reference can be replaced without redeploying the token.

Initial supply concentrated at deployment: The token constructor assigns the full fixed supply to the deployer in a single initialization step, with no staged mint, vesting, or multi-party distribution enforced on-chain. At launch, that address holds the entire circulating inventory and can transfer, provide liquidity, or retain control without further protocol checks. Market depth, holder distribution, and early trading fairness therefore depend entirely on how the deployer handles that initial allocation after deployment.

Irreversible loss of administrative remediation: The deployed instance has renounced ownership with _previousOwner cleared, so every onlyOwner setter is permanently inaccessible. Fee rates, swap and buyback flags, thresholds, marketing destination, and exemption lists cannot be corrected, rotated, or recovered through the contract. Any misconfiguration present at renouncement is frozen for the life of the deployment.

Frozen constructor fee exemption for the deployer: The constructor marks the deployer as fee-exempt. Renouncement does not clear that exemption and provides no path to revoke it. The original deployer address therefore retains permanent fee-free transfer treatment while ordinary holders continue to pay the frozen fee schedule.

Remediation is instance-specific and does not cover redeploys: Reported issues were assessed against the already-deployed bytecode and live configuration (including ownership renounce and frozen owner-settable parameters). Verdicts of Mitigated apply only where those on-chain conditions permanently close or shrink the relevant paths on that specific instance. Any new deployment of the same source, or any instance that retains an active owner or different configuration, reopens the full set of findings, including those previously recorded as Mitigated.

Findings

Code
―
Title
Status
Severity
F-2026-1821Stale State in restoreAllFee Reinstalls Transfer Fees
mitigated

High
F-2026-1821Stale _previousOwner Enables Repeated Ownership Seizure
mitigated

High
F-2026-1821Stale _rOwned in includeInReward Mints Tokens
mitigated

Medium
F-2026-1822Zero Slippage in swapTokensForEth Enables Sandwich
mitigated

Medium
F-2026-1821Oversized _maxTxAmount Leaves Anti-Whale Limit Inert
accepted

Medium
F-2026-1821deliver Triggers Supply Fallback and Freezes Reported Balances
mitigated

Low
F-2026-1821Reward-Eligible Fee Escrow Dilutes Holder Reflections
accepted

Low
F-2026-1821Five Unsafe Configurations in _transfer Can Block All Sells
mitigated

Low
F-2026-1821Unbounded setMaxTxAmount Can Permanently Freeze Transfers
mitigated

Low
F-2026-1821Unbounded YFSX Fee Setters Can Block Taxed Transfers
mitigated

Low
1-10 of 17 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Deployed address YFSXhttps://bscscan.com/token/0xb7ec60cf8ef96ed48b119277bc7a954a87f27388→
Whitepaperhttps://yfsx.vin/Whitepaper.html→
Requirements
Technical Requirements

Appendix 3. Additional Valuables

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer