Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Sylvan Token Info

www.sylvantoken.org

Revolutionizing DeFi with Sustainable Tokenomics on Binance Smart Chain

Sylvan Token Logo
Onboarded date 02/12/2025

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.

92.00
Poor Excellent

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.

Security Assessments

"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
0x50Ff...2e85
Network
BNB Smart Chain - Mainnet
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2025/12/02
Revision date 2025/12/02

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 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:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. 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 exempt wallets from fees.
  • The owner can remove the exemptions for wallets for fees.
  • The owner can manage the fee exemptions list in bulk.
  • The owner can emit the exemption count.
  • The owner can create a vesting schedule.
  • The owner can configure an admin wallet with a specific token allocation for vesting.
  • The owner can process the initial token release for an admin wallet.
  • The owner can process the monthly vested token release for an admin wallet.
  • The owner can process the monthly vested token release for a locked wallet.
  • The owner can set or unset an address as an AMM pair.

Note - This Audit report consists of a security analysis of the SylvanToken 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 SylvanToken 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

Critical
High
Medium
Low
Optimization
Informational
medium Issues | 3 findings

Resolved

#1 medium Issue
Incorrect Vesting Calculation for Admin Wallets in Public Release Function
SylvanToken.sol
L859-915
Description

The releaseVestedTokens function contains a bug that leads to incorrect vesting calculations for admin wallets, resulting in underpayment and a permanent loss of funds. The proof of this flaw is on line 433, where the function exclusively calls the _calculateLockedWalletRelease helper, which is incorrect for admin schedules. This helper function bases its calculation on schedule.totalAmount—the locked 90% portion of an admin's funds—instead of their total original allocation. This error is further proven by the existence of a separate, correct helper function, _calculateAvailableRelease, which contains the proper logic but is never actually used by this public release function. As a result, any admin release processed through this function will be 10% smaller than intended, causing 9% of the admin's total allocation to become permanently trapped in the contract once the vesting period concludes.

Comments

The mitigation for this bug requires refactoring the releaseVestedTokens function to serve as a universal and correct entry point for all vesting claims. This is achieved by introducing a conditional check to differentiate between beneficiary types based on the schedule.isAdmin flag. If the beneficiary is an admin, the function must call the correct internal helper, _calculateAvailableRelease(beneficiary), which properly uses the admin's total allocation for its calculation. Conversely, if the beneficiary is a standard locked wallet, it should proceed to call _calculateLockedWalletRelease. Implementing this logic will resolve the calculation error, ensure all releases are processed according to their intended rules, and prevent the permanent loss of funds for admin wallets.

Resolved

#2 medium Issue
Misleading Vesting Schedule Configuration for Admin Wallets
SylvanToken.sol
L513-559
Description

This function is the origin of the admin vesting bug because it creates a flawed and ambiguous data state on the blockchain. The core of the issue is on line 543, where it sets the totalAmount field in the generic VestingSchedule struct to the lockedAmount (90% of the admin's total allocation). This action creates a data "landmine"; it stores a partial amount in a field that other functions later assume represents a total. The public releaseVestedTokens function and its helper, _calculateLockedWalletRelease, then read this misleading value and incorrectly use it as the basis for their 5% monthly release calculation. This directly causes the underpayment of admins and the permanent locking of 9% of their funds.

Comments

The most robust mitigation is to fix the data at its source by removing the ambiguity. A direct fix would be to modify the VestingSchedule to always be based on the totalAllocation for admins, ensuring all subsequent calculations are performed on the correct base amount. A more targeted (and already implemented) mitigation is to correct the logic in the downstream functions. The _calculateAvailableRelease function correctly ignores the misleading schedule.totalAmount and instead fetches the true totalAllocation from the adminConfigs mapping. The releaseVestedTokens function must be updated to use this correct helper function for admin wallets, ensuring it sidesteps the flawed data state created by configureAdminWallet.

Resolved

#3 medium Issue
The owner can lock token transfer
SylvanToken.sol
L1115-1118
Description

The contract grants the owner a significant centralized power: the ability to unilaterally halt all standard token transfers at any time by calling the pauseContract function. This function acts as a global kill switch for trading, preventing all holders from using transfer and transferFrom to move their assets. While this can be a valuable security tool in the event of an exploit, it also introduces a high degree of centralization and trust in the owner. An important nuance is that this pause only affects public transfers; it does not stop the owner from continuing to move tokens via administrative functions like processing vesting releases, meaning the owner's capabilities are not fully suspended during a pause.

Comments

Mitigating this centralization risk involves changing the governance model of the contract's ownership. The most effective mitigation is decentralization: transferring the ownership of the contract from a single address to a multi-signature wallet controlled by several independent keyholders or to a decentralized autonomous organization (DAO). This would require a consensus among multiple parties before the contract could be paused, removing the single point of failure and control. If retaining a single owner is intended for the project's early stages, the mitigation should be based on transparency, with the team publicly defining a strict policy outlining the exact emergency conditions under which this pausing power would be used.

low Issues | 1 findings

Resolved

#1 low Issue
Unimplemented Trading Control Mechanism
SylvanToken.sol
L1081-1084
Description

The contract includes an enableTrading function and a corresponding tradingEnabled state variable, which are intended to act as a control switch to prevent public token transfers until liquidity is established. However, the core logic to enforce this restriction is completely missing from the _transfer function. The contract never actually checks the value of the tradingEnabled flag before allowing a transfer to proceed. Consequently, this feature is non-functional, and public trading is effectively enabled from the moment the contract is deployed, rendering the enableTrading function and its associated variables useless dead code.

Comments

To properly implement this feature, a validation check must be added to the _transfer logic. This check should revert any transfer unless the tradingEnabled flag is true or the transfer is initiated by an authorized address (such as the contract owner or an exempt wallet). For example: require(tradingEnabled || isExempt(from) || isExempt(to), "Trading not enabled");. If this functionality is not actually required, then the enableTrading function, the isTradingEnabled function, and the tradingEnabled state variable should be completely removed from the contract to reduce deployment gas costs and eliminate confusion about the contract's behavior.

informational Issues | 2 findings

Resolved

#1 informational Issue
Unused Library Initialization in Constructor
SylvanToken.sol
L145-173
Description

The contract's constructor initializes the walletData state variable by calling the initializeWallets function from the WalletManager library. However, a review of the entire contract reveals that this walletData variable is never read from, modified, or utilized in any other function after this initial setup. This makes the function call, the associated state variable, and the corresponding library import entirely redundant.

Comments

To optimize the contract and improve code clarity, the unused code should be removed. This involves deleting the walletData.initializeWallets(...) function call from the constructor, removing the WalletManager.WalletData private walletData; state variable declaration, and deleting the using WalletManager for WalletManager.WalletData; statement. Eliminating this dead code will reduce gas consumption during deployment and simplify the contract, making it easier to read and maintain without altering its functional logic.

Resolved

#2 informational Issue
Unused Stored Variable and Contradictory Logic Comments
SylvanToken.sol
L513-559
Description

The configureAdminWallet function suffers from two distinct code quality issues that increase gas costs and obscure the contract's intended logic. Firstly, it calculates and stores a monthlyRelease value in the AdminWalletConfig struct, an action that consumes gas, yet this variable is never read or used again in the contract's lifecycle. Secondly, and more critically, the function's comments are self-contradictory, most notably stating that the monthly release is both "5% of total allocation" and "calculated on locked amount." This ambiguity is the likely root cause of the critical vesting bug, as it creates confusion about the true basis for the calculation.

Comments

To rectify these issues, the unused monthlyRelease variable should be removed from the AdminWalletConfig struct, and its corresponding calculation should be deleted from the function to save gas on deployment. Furthermore, all related comments must be rewritten to be clear and unambiguous, explicitly stating that the monthly release is 5% of the admin's total original allocation. These changes will not only optimize gas usage but, more importantly, will improve the code's clarity and maintainability, making it less prone to logical errors in the future.