Audit name:
[SCA] TCG-vault | Vault Token | Apr2026
Date:
Jun 2, 2026
Table of Content
Introduction
We express our gratitude to the TCG-vault team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The TCG-VAULT protocol is a token ecosystem centered around a presale, staking, and governance model. It comprises three token contracts, two NFT contracts, a presale mechanism, a dedicated buy/sell router, a staking vault, a liquidity wrapper, and a referral-to-utility token converter.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for TCG-vault |
| Audited By | Khrystyna Tkachuk, Kornel Światłowski |
| Approved By | Olesia Bilenka |
| Website | - |
| Changelog | 16/04/2026 - Preliminary Report |
| 25/05/2026 - Final Report | |
| 02/06/2026 - Update of Final Report | |
| Platform | BSC |
| Language | Solidity |
| Tags | Vesting; Staking; Token Sales; Claims; ERC20; ERC721; Centralization |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for TCG-vault
- Audited By
- Khrystyna Tkachuk, Kornel Światłowski
- Approved By
- Olesia Bilenka
- Website
- -
- Changelog
- 16/04/2026 - Preliminary Report
- 25/05/2026 - Final Report
- 02/06/2026 - Update of Final Report
- Platform
- BSC
- Language
- Solidity
- Tags
- Vesting; Staking; Token Sales; Claims; ERC20; ERC721; Centralization
Review Scope | |
|---|---|
| Repository | https://github.com/tcg-vault/contracts→ |
| Commit | 201d801 |
| Final Commit | 52f9975 |
| Updated Final Commit | 7e785d4 |
Review Scope
- Repository
- https://github.com/tcg-vault/contracts→
- Commit
- 201d801
- Final Commit
- 52f9975
- Updated Final Commit
- 7e785d4
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided.
Technical description is provided.
Run instructions are provided.
Technical specification is provided.
The NatSpec documentation is sufficient.
Code quality
The code leverages OpenZeppelin contracts and follows established patterns.
The development environment is configured.
Test coverage
Code coverage of the project is 92.82% (statement coverage).
Deployment and basic user interactions are covered with tests. Core happy-path flows are tested: token deployment and initialization, presale buy/claim, Founder NFT minting, BuyRouter buy/sell, TCGR referral registration and reward minting, staking vault deposit/withdrawal, and Basic NFT mint/burn on threshold crossings. Presale TCGV and Founder NFT purchase cancelation is not tested.
Negative cases coverage is partly missed.
Interactions by several users are not tested thoroughly.
System Overview
The TCG-VAULT protocol is a token ecosystem centered around a presale, staking, and governance model. It comprises three token contracts, two NFT contracts, a presale mechanism, a dedicated buy/sell router, a staking vault, a liquidity wrapper, and a referral-to-utility token converter.
The protocol lifecycle proceeds in three distinct phases. In the first phase (presale), users purchase Founder NFTs for USDC across two price waves, and separately buy TCGV tokens at fixed USDC prices through the Initial Launch contract. Both presale channels grant a 30% bonus in NEXUS governance tokens. A 14-day MiCA-compliant cancellation window allows buyers to reverse purchases, burning the allocated tokens and clawing back NEXUS bonuses. USDC refunds are handled off-chain by a CASP (Crypto-Asset Service Provider).
The second phase (finalization) begins after a 120-hour countdown that starts 10 days after Founder NFT wave 2 begins (wave 2 is triggered by wave-1 sellout of 245 NFTs or after 7 days from first sale), followed by a mandatory 20-day delay. Finalization sets the TGE (Token Generation Event) timestamp, switches NEXUS cashback from 30% to 3%, and executes a one-time supply recompute that mints allocation buckets: 20% to liquidity, 4% to team vesting (12-month cliff, 24-month linear), 5% directly to operations, and 11% to operations vesting (36-month linear).
In the third phase (post-TGE), TCGV trades on PancakeSwap V2 with configurable buy (default 6%) and sell (default 5%) taxes applied at the token level. A dedicated USDC BuyRouter provides an alternative trading path with its own fee structure (5% buy, 4% sell in USDC), NEXUS cashback minting, and referral reward processing. Presale participants claim vested TCGV on a 10% TGE + 10% monthly schedule over 9 months. Users can stake TCGV in an ERC-4626 vault to receive soulbound Basic NFTs that serve as membership tokens.
Files in scope
TCGVaultToken (TCGV) — ERC-20 token with built-in buy and sell fees applied on DEX pair transfers. Buy tax defaults to 6% and sell tax to 5%, split among vault, marketing, community, and auto-liquidity recipients. Fee rates and distribution shares are configurable by the admin (
AccessControlwith a dedicatedADMIN_ROLE). The contract includes a blacklist mechanism that seizes the target's full balance before blocking further transfers, an emergency pause that halts all transfers, and built-in linear vesting for team (4%, 12-month cliff + 24-month vest) and operations (11%, 36-month vest) allocations. Supply is not pre-minted; it is created during presale viamintPresale()and finalized viafinalizePresaleAndRecompute(), which also switches the NEXUS cashback rate from 30% to 3%.3TCGNexusToken (NEXUS) — ERC-20 soulbound governance token with ERC20Votes and ERC20Permit support. Transfers between non-zero addresses are blocked (mint and burn only). Minted as cashback on TCGV purchases (by TCGVaultToken) and as a 30% presale bonus (by allowed presale minter contracts).
TCGRToken (TCGR) — ERC-20 soulbound referral token. Transfers between non-zero addresses are blocked. Minted by the designated minter (TCGVaultBuyRouter) at 0.5% of the USDC buy value to the buyer's registered referrer. Each account can set a referrer once (immutable binding). The owner can ban accounts from the referral program. TCGR can be burned by the designated converter contract (TCGRToTCGVConverter) when converting to TCGV.
TCGVaultFounderNFT — ERC-721 NFT collection capped at 500 units: 245 + 245 paid across two waves (wave 1 at 200 USDC, wave 2 at 350 USDC) plus 10 strategic reserve (owner-minted, no USDC, no NEXUS bonus). Buyers receive a 30% NEXUS bonus on the mint price. Wave 2 starts on wave-1 sellout (245 paid) or after 7 days; the wave-2 start timestamp is used by TCGVaultInitialLaunch to compute the presale countdown. Includes a 14-day MiCA cooling-off cancellation mechanism that burns the NFT and claws back the NEXUS bonus; USDC refunds are handled off-chain.
TCGVaultBasicNFT — ERC-721 soulbound NFT (transfers between non-zero addresses are blocked). Minted automatically by the staking vault when a user's stake reaches the minimum threshold, and burned when the stake drops below it. Limited to one NFT per wallet.
TCGVaultInitialLaunch — Presale contract for TCGV against USDC. Wave 1 price is 0.005 USDC/TCGV (until Founder NFT wave 2 starts), wave 2 price is 0.008 USDC/TCGV, with a 120-hour countdown starting 10 days after wave 2 begins. Enforces a 600M TCGV hard cap and a 4% per-wallet cap. Buyers receive a 30% NEXUS bonus. Purchased TCGV is vested: 10% at TGE, then 10% per month over 9 months. Includes a 14-day MiCA cooling-off cancellation that burns the allocated TCGV and claws back NEXUS; USDC refunds are emitted as events for off-chain processing. Finalization can only occur 20 days after the presale countdown ends and triggers supply recomputation in TCGVaultToken.
TCGVaultBuyRouter — Dedicated router for buying and selling TCGV against USDC via PancakeSwap V2 pools. On buy: a configurable USDC fee (default 5%) is split among vault, marketing, and community before swapping the remainder for TCGV; NEXUS cashback is minted to the buyer and TCGR referral rewards are processed. On sell: TCGV is swapped for USDC, and a configurable fee (default 4%) is deducted from the USDC output and split among recipients. The router is excluded from TCGV transfer fees and implements fee-on-transfer-aware swap logic.
TCGVaultLiquidityWrapper — Helper contract for adding and removing TCGV/tokenB liquidity on allowed PancakeSwap V2 routers without incurring TCGV transfer fees. The wrapper must be fee-excluded in TCGVaultToken. On removal, tokens are routed through the wrapper to avoid the pair-to-user transfer being taxed as a buy.
TCGVaultStakingVault — ERC-4626 tokenized vault over TCGV (share token: sTCGV, non-transferable/soulbound). Deposits are exact-stake only: the caller must deposit precisely the amount needed to reach the configurable minimum stake threshold for the receiver (no partial or excess deposits). Withdrawals are full-exit only: the caller must redeem the owner's entire share balance in a single transaction (no partial withdrawals). On deposit, if the receiver's share balance reaches the required threshold, a soulbound Basic NFT is automatically minted via the linked TCGVaultBasicNFT contract. On withdrawal, if the owner's share balance drops below the threshold, all Basic NFTs held by the owner are burned. The minimum stake threshold can be set statically by the owner or derived dynamically from a Pancake V2 TWAP price targeting ~25 USDC worth of TCGV (with configurable min/max TWAP windows of 1–7 days). Withdraw and redeem revert if the share owner is blacklisted on TCGVaultToken; the token contract may call
forceWithdrawFromBlacklist()to redeem all shares to the protocol vault during blacklisting.TCGRToTCGVConverter — Utility contract that converts soulbound TCGR into TCGV at a configurable ratio. Burns the caller's TCGR via
burnForConversion()and transfers the corresponding TCGV amount from the contract's pre-funded balance. The conversion ratio is owner-adjustable.
Privileged roles
TCGVaultToken.sol
DEFAULT_ADMIN_ROLE: Grant/revoke all other roles (standard AccessControl admin).
ADMIN_ROLE: Register/remove DEX routers and pairs; set fee recipients (vault, marketing, community); exclude/include addresses from fees; enable/disable fees and cashback globally; set buy/sell tax rates and share distribution (buy capped at 6%, sell capped at 5%); set minimum buy/sell amounts; set allocation recipients for post-presale mint; set the buy router address.
PAUSER_ROLE: Pause all transfers (emergency stop).
UNPAUSER_ROLE: Unpause all transfers.
BLACKLISTER_ROLE: Blacklist addresses with balance seizure (redeems staking vault shares first, then confiscates wallet balance to vault address).
buyRouter (TCGVaultBuyRouter): Trigger NEXUS cashback minting (
recordBuyAndMintCashback()).
TCGVaultBuyRouter.sol
owner: Set the referral token address; update buy fee parameters (vault, marketing, community basis points, sum capped at 5%); update sell fee parameters (tax rate capped at 4%, share distribution must sum to 10000).
TCGVaultInitialLaunch.sol
owner: Set the treasury address for USDC proceeds; trigger emergency finalization if presale exceeds max duration (365 days) and wave 2 never started.
TCGVaultFounderNFT.sol
owner: Set the CASP USDC recipient address; set the base URI for token metadata; mint up to 10 strategic reserve NFTs (no USDC, no NEXUS bonus, not cancellable.
TCGVaultLiquidityWrapper.sol
owner: Add or remove allowed PancakeSwap V2 routers for liquidity operations.
TCGNexusToken.sol
owner: No privileged minting or configuration functions (ownership inherited from Ownable2Step but unused in current implementation).
minter (TCGVaultToken, immutable): Mint NEXUS as cashback on TCGV purchases (
mintCashback).presale bonus contracts (TCGVaultFounderNFT and TCGVaultInitialLaunch, both immutable): Mint presale bonus NEXUS (
mintPresaleBonus); burn presale bonus from holders for MiCA cancellation clawback (clawBackPresaleBonus).
TCGVaultBasicNFT.sol
owner: Set the staking vault address; set the base URI for token metadata.
stakingVault (
TCGVaultStakingVaultcontract): Mint a Basic NFT for an account that meets the staking threshold (mintFor); burn Basic NFTs for an account that drops below the threshold (burnAllFor).
TCGRToken.sol
owner: Set the minter address; set the converter address; set the qualifying NFT for referrer eligibility; ban/unban addresses from the referral program.
minter (TCGVaultBuyRouter): Mint TCGR to referrers on validated buys (
processValidatedBuy).converter (TCGRToTCGVConverter): Burn TCGR from an account that has approved the converter (
burnForConversion); requires account's ERC-20 allowance and sufficient unlocked referral balance.
TCGVaultStakingVault.sol
owner: Set the minimum stake threshold for Basic NFT eligibility; set the Basic NFT contract address; set the Basic NFT pricing router for dynamic TWAP-based threshold computation.
TCGRToTCGVConverter.sol
owner: Set the TCGR-to-TCGV conversion ratio (immediate effect, no timelock).
Potential Risks
Centralized Control of Minting Process: The token contract’s design allows for centralized control over the minting process, posing a risk of unauthorized token issuance, potentially diluting the token value and undermining trust in the project's economic governance.
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.
Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes.
Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.
TCGV Token Tax Arbitrage via Unregistered Pairs: TCGVaultToken's buy and sell tax only applies when the transfer involves a registered pair address (isPair mapping). Any TCGV liquidity pool created on a DEX or AMM that the admin has not registered will process trades as regular fee-free transfers. As the token gains market visibility, third parties or arbitrage bots may deploy competing pools to trade without the 5-6% tax, then arbitrage the price difference against the taxed pool. The admin can reactively register new pairs, but cannot prevent their creation. This is an inherent limitation of the tax-token pattern that could erode the protocol's intended fee revenue model over time, particularly if liquidity fragments across multiple venues.
Uncapped NEXUS Minting Undermines Governance Integrity: TCGNexusToken has multiple uncapped minting paths, including an owner-controlled mint() function with no cap or timelock. Because NEXUS is an ERC20Votes governance token, any new minting directly changes voting power distribution. This allows the owner to arbitrarily dilute existing holders, while ongoing cashback minting causes supply to grow indefinitely with TCGV trading activity. As a result, governance power is not stable or predictable and can be materially influenced by privileged minting or long-term token issuance.
Supply Recalculation Depends Entirely on Presale Allocation Output: TCGVaultToken.finalizePresaleAndRecompute() relies entirely on TCGVaultInitialLaunch.totalTCGVAllocated() to derive the presale-sold amount (60% of total supply), which is then used as the basis for the full post-presale token allocation model. Team vesting, ops vesting, liquidity, and direct ops allocations are all calculated from this derived value. If totalTCGVAllocated() returns an incorrect value due to a low or zero sold amount, or an accounting error, the entire tokenomics distribution will be miscomputed. Because the recomputation is a one-time irreversible operation, any error becomes permanent, and the contract provides no correction mechanism.
Interactions with External DeFi Protocols: Dependence on external DeFi protocols inherits their risks and vulnerabilities. This might lead to direct financial losses if these protocols are exploited, indirectly affecting the audited project.
Insufficient Permissioning and Documentation: Inadequate permissions and under-documentation heighten the risk of unauthorized access and actions, complicating issue resolution and increasing the potential for security breaches.
TCGR-to-TCGV Converter Treasury Depletion: TCGRToTCGVConverter pays out TCGV from its own pre-funded balance. There is no on-chain mechanism to automatically replenish this balance, no cap on conversions, and no circuit breaker. As referral rewards accumulate and users convert TCGR to TCGV, the converter's treasury depletes. If the TCGR supply grows faster than the treasury is manually replenished, convert() will begin reverting with InsufficientTcgvReserve, breaking the referral program's value proposition. The admin must monitor and fund the converter off-chain, creating an ongoing operational dependency with no on-chain alerting or safeguard.
Staking Vault Share Price Manipulation Impact on Basic NFT Eligibility: The Basic NFT eligibility threshold (minStakeForBasicNFT) is denominated in sTCGV shares, not in underlying TCGV value. Since TCGVaultStakingVault is a standard ERC-4626 vault, the share-to-asset ratio changes with donations or rewards to the vault. A large donation of TCGV directly to the vault contract would increase the asset-per-share ratio, meaning fewer shares are needed to represent the same TCGV value. Conversely, if the share price changes significantly, the admin-set minimum share threshold may no longer correspond to the intended USD-equivalent staking requirement (~$25 per whitepaper). The threshold requires manual admin adjustment to track market conditions, with no oracle or automatic recalibration.
TCGRToken Referral Vesting Bucket Boundary Timing: Referral rewards are vested using fixed 30-day timestamp buckets. Rewards earned near a bucket boundary may unlock almost immediately, while rewards earned shortly after the boundary may remain locked for nearly the full 30-day period. This may result in inconsistent vesting periods and unfair reward availability for referrers.
FounderNFT Wave Transition Irreversibility After Cancellations: Wave 2 can start either after the configured Wave 1 duration or earlier when the active sold count reaches the Wave 1 size. Once _wave2StartTimestamp is set, the transition is irreversible. However, cancellations can later reduce _activeSoldCount, meaning Wave 2 remain active even if the number of active sales falls below the original Wave 1 threshold before block.timestamp + WAVE1_DURATION.
Report Modification: This report was modified on June 2, 2026 at the client’s request to update its original content by changing the final commit hash to 7e785d4. While these changes aim to align the report with the most current information provided by the client, it is important to note that modifying previously published content may affect the integrity and continuity of the original audit findings. Hacken has reviewed the modifications to confirm they reflect only the requested updates, but any future changes involving substantial updates or new code commits should be accompanied by a re-assessment to ensure no new risks compromise the security posture.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1595 | Off-Chain Refund Dependency Creates Unenforceable Cancellation Guarantees | mitigated | High | |
| F-2026-1592 | Staking Vault Allows Blacklisted Users to Recover Seized Funds | fixed | Medium | |
| F-2026-1592 | Lack of Slippage Protection Against Ratio Changes in convert() | fixed | Medium | |
| F-2026-1606 | Push-Based Fee Distribution Increases Gas Cost And Introduces Blacklist Dependency | fixed | Medium | |
| F-2026-1596 | Unreset Token Allowance Breaks Subsequent Liquidity Operations With Non Standard ERC20 Tokens | fixed | Medium | |
| F-2026-1592 | Founder NFT Cancellation Does Not Adjust Sold Counter or Wave Transition | fixed | Medium | |
| F-2026-1590 | TCGVaultStakingVault Share Inflation via Direct Token Donation | fixed | Medium | |
| F-2026-1703 | Non-Compliant ERC-4626 Preview and Max View Functions Return Values Inconsistent with Actual Vault Behavior | fixed | Medium | |
| F-2026-1702 | Spot Price Manipulation in Basic NFT Stake Threshold Calculation | fixed | Medium | |
| F-2026-1596 | Absence of Granular Role Separation | fixed | Low |
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 | |
|---|---|
| Repository | https://github.com/tcg-vault/contracts→ |
| Commit | 201d801a82778517d086b52cb5370c28895d317b |
| Final Commit | 52f997563e9e326ac1dcd57ecbd7586fc8010255 |
| Updated Final Commit | 7e785d4872843ba2a78b43daad2761c4ba416413 |
| Whitepaper | WHITEPAPER_REFERENCE.md |
| Requirements | README.md |
| Technical Requirements | README.md |
Scope Details
- Repository
- https://github.com/tcg-vault/contracts→
- Commit
- 201d801a82778517d086b52cb5370c28895d317b
- Final Commit
- 52f997563e9e326ac1dcd57ecbd7586fc8010255
- Updated Final Commit
- 7e785d4872843ba2a78b43daad2761c4ba416413
- Whitepaper
- WHITEPAPER_REFERENCE.md
- Requirements
- README.md
- Technical Requirements
- README.md
Assets in Scope
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.