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

VIN Token

Audit name:

[SCA] VIN Token | VIN 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 VIN Token team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

VulgarTycoon (VIN) is an 18-decimal BEP20 fee-on-transfer token intended for BNB Smart Chain and a Uniswap-V2-compatible DEX (PancakeSwap). Core user activity is trading and transferring VIN, with each non-exempt transfer automatically applying burn, liquidity-pair credit, optional holder and LP dividends, and distributor allocations.

Document

NameSmart Contract Code Review and Security Analysis Report for VIN 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 VIN 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 VulgarTycoonhttps://bscscan.com/token/0x85e43bf8faaf04ceddcd03d6c07438b72606a988→

Audit Summary

10Total Findings
0Resolved
7Accepted
3Mitigated

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

VulgarTycoon implements a single-contract BEP20 token with Ownable access control and SafeMath arithmetic. At construction, a fixed supply of 19,999,000 VIN is minted to the deployer, a VIN/WBNB pair is created via the hardcoded PancakeSwap V2 router, and fee exemptions are set for the deployer, the contract, the router, and a fixed LP-dividend recipient. Threshold parameters for dividend eligibility and LP-dividend swaps are initialized, including a burn-stop threshold at half of initial supply that is never consulted by burn logic. Constructor defaults set buy and sell burn, liquidity, LP-dividend, and distributor fees to 1% each, while holder-dividend fees start at 0%. Transfers are handled through _transfer, which registers new holders and routes buy, sell, and wallet-to-wallet paths through distinct fee logic.

On buys from and sells to the pair, processFee deducts configurable percentage fees for burn (credited to the public dead address, which is the zero address, while reducing _totalSupply), direct credit of a liquidity share to the pair balance, optional pro-rata holder dividends via difidendToHolders over the tokenHolders registry, accumulation of an LP-dividend share on the contract with possible conversion through swapAndDifidend (token-to-WBNB swap supporting fee-on-transfer tokens, proceeds sent to a fixed LP-dividend address), and an optional distributor allocation when distributorAddr is set. Non-pair transfers by non-exempt parties apply a hardcoded 1% burn and, when distributorAddr is configured, a 1% distributor fee. The design depends on PancakeSwap V2 factory and router interfaces (IPancakeFactory, IPancakeRouter02) and exposes owner setters for selected fee rates, thresholds, fee exemptions, and the distributor address.

On the deployed BSC instance, ownership has been renounced (owner() address(0)). All onlyOwner setters are permanently inaccessible. Live fee rates, thresholds, fee exemptions, and distributorAddr are frozen at the values present at renouncement. On that instance, distributorAddr was set before renouncement, so the distributor fee path is live and cannot be disabled or retargeted through the contract.

Files in Scope

  • VulgarTycoon.sol — Contains the VulgarTycoon BEP20 token, Ownable base, SafeMath library, and PancakeSwap V2 interfaces. Encodes construction-time pair creation, fee-on-transfer accounting, holder and LP dividend distribution, and owner configuration entry points.

Privileged roles

  • owner (inherited from Ownable): Controls ownership and all configurable token parameters while ownership is active.

    • Can call transferOwnership to transfer ownership to a new non-zero address.

    • Can call renounceOwnership to set the owner to the zero address.

    • Can call setBuyFeeToBurn to set the buy-side burn fee percentage.

    • Can call setSellFeeToBurn to set the sell-side burn fee percentage.

    • Can call setAmountToStopBurn to set the burn-stop threshold (amountToStopBurn).

    • Can call setAmountTodifidend to set the minimum holder balance required for dividend eligibility.

    • Can call setAmountToLPDifidend to set the minimum contract balance that triggers the LP-dividend swap.

    • Can call exemptFromFee to grant or revoke fee exemption for an account.

    • Can call setDistributorAddr to set the marketing and distributor fee recipient.

    • Can call setBuyFeeToDistributor to set the buy-side marketing fee percentage.

    • Can call setSellFeeToDistributor to set the sell-side marketing fee percentage.

    • Private onlyOwner setters with no call sites (not externally callable): setBuyFeeToLiquidity, setBuyFeeToDifidend, setBuyFeeToLPDifidend, setSellFeeToLiquidity, setSellFeeToDifidend, setSellFeeToLPDifidend.

    • On the deployed BSC instance, ownership is renounced (owner() address(0)). Every public onlyOwner entry point above is permanently unreachable.

  • Fee-exempt accounts (_exemptFee): Accounts marked exempt via construction defaults or exemptFromFee bypass buy, sell, and wallet-to-wallet fee branches in _transfer. At construction, the deployer, the token contract, pancakeRouterAddr, and LPDifidendAddr are exempt.

    • After renouncement, the exemption set is frozen and cannot be expanded or revoked on-chain.

  • LP dividend recipient (LPDifidendAddr): Hardcoded address 0x50b320820aFb41abcD5bbff33a5406863156024E that receives ETH proceeds from swapAndDifidend and is fee-exempt at construction. The address cannot be changed after deployment.

  • Distributor recipient (distributorAddr): Address set by the owner via setDistributorAddr while ownership is active. When non-zero, receives buy, sell, and wallet-to-wallet distributor fee credits.

    • On the deployed BSC instance, distributorAddr is set to 0x0125b0bcE7ceE713C205821bb900De3a1d39a4B9 and is frozen after renouncement.

Potential Risks

External DEX dependency: VulgarTycoon hardcodes pancakeRouterAddr, creates _pairAddress through IPancakeFactory.createPair at construction, and routes LP-dividend conversion through IPancakeRouter02 in swapAndDifidend. After renouncement, neither the router nor the pair reference can be replaced without redeploying the token.

Irreversible loss of administrative remediation: The deployed instance has renounced ownership, so every public onlyOwner setter is permanently inaccessible. Fee rates, thresholds, fee exemptions, and distributorAddr 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 exemptions: The constructor marks the deployer, the token contract, the router, and LPDifidendAddr as fee-exempt. Renouncement provides no path to revoke those exemptions. Those addresses retain permanent fee-free treatment while ordinary holders continue to pay the frozen fee schedule.

Immutable LP-dividend recipient: LPDifidendAddr is hardcoded (0x50b320820aFb41abcD5bbff33a5406863156024E), is fee-exempt at construction, and is the sole ETH recipient of swapAndDifidend. Custody of LP-dividend proceeds cannot be rotated without redeploying VulgarTycoon.

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.

Constructor-pair swaps limited to fee-exempt addresses on the live deployment: Non-exempt buys and sells against _pairAddress enter processFee, which always invokes difidendToHolders and iterates the full tokenHolders array. On the live BSC instance, that registry already exceeds practical block gas limits. Ordinary holders therefore cannot complete taxed swaps on the constructor pair, while fee-exempt addresses bypass processFee and retain pair access. Ownership renouncement provides no path to prune the registry, disable the loop, or expand exemptions, so this restricted pair access is permanent for the deployed token.

Preferential constructor-pair access for fee-exempt addresses: Non-exempt buys and sells against _pairAddress enter processFee, which always runs difidendToHolders over the full tokenHolders registry. On the live BSC instance that registry already exceeds practical block gas limits, so ordinary holders cannot complete taxed swaps on the constructor pair. Fee-exempt addresses bypass processFee, retain pair access, and pay no DEX fee schedule. Ownership renouncement provides no path to prune the registry, disable the loop, or revoke those exemptions, so exclusive practical access to the primary VIN/WBNB pair remains permanent for the exempt set while non-exempt users are limited to alternate pools under the wallet tax path.

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-1822Unsynced Liquidity Credits Can Be Diverted From Reserves
accepted

High
F-2026-1822Unbounded tokenHolders Growth Can Block All Taxed Trades
accepted

High
F-2026-1822Missing Zero-Address Guard in _transfer Corrupts Supply Accounting
accepted

Medium
F-2026-1822Zero Slippage in swapAndDifidend Enables Sandwich
accepted

Medium
F-2026-1822Single _pairAddress Lets Alt Pools Evade DEX Tax
accepted

Medium
F-2026-1822Unreachable Dividend Distribution Defect Would Lose Tokens If Setters Were Exposed
mitigated

Low
F-2026-1822Six Fee Setters Declared private Are Unreachable In Every Deployment
accepted

Low
F-2026-1822Unbounded VIN Fee Setters Can Block Taxed Trades
mitigated

Low
F-2026-1822Silent VIN Fee Credits Desynchronize Event-Based Balances
accepted

Observation
F-2026-1825Owner Setters Omit Events On Configuration Changes
mitigated

Observation
1-10 of 10 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 VulgarTycoonhttps://bscscan.com/token/0x85e43bf8faaf04ceddcd03d6c07438b72606a988→
Whitepaperhttps://yfsx.vin/Whitepaper.html→
Requirements
Technical Requirements

Assets in Scope

VIN Token - VIN Token

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