FYS DAO Info
FYS DAO is a decentralized ecosystem designed to empower individuals with tools for financial well-being, digital independence, and personal growth—driven by community governance through the BYD token.
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 can mint
It is possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner can set high fees
Contract owner is able to set fees above 25%. Very high fees can also prevent token transfer.
Token transfer can be locked
Owner can lock user funds with owner functions.
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 upgradeable
The contract uses a proxy pattern or similar mechanism, enabling future upgrades. This can introduce risks if the upgrade mechanism is not securely managed.
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 update the tax receiver's address.
- The owner can set the maximum transaction value to any arbitrary value, including zero.
- The owner can set the buy and sell taxes to any arbitrary value.
- The owner can change the total supply of the contract.
- The owner can mint an indefinite number of tokens.
Note - This Audit report consists of a security analysis of the BYD Token smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited the mentioned contract for the FYS DAO 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 | 1 findings
Pending
#1 high Issue
Modifiable Maximum Supply
The contract includes a setMaxTotalSupply function that grants the owner the ability to alter the MAX_SUPPLY variable at any time. This capability undermines the economic certainty of the token, as the owner could potentially increase the maximum supply cap well beyond the originally communicated limit. If combined with the mint function (which relies on this cap), this allows the owner to inflate the token supply indefinitely, diluting the value of existing holders' tokens and effectively removing the scarcity guarantees typically expected from a capped-supply asset.
medium Issues | 2 findings
Pending
#1 medium Issue
Missing Minimum Transaction Limit Check
The function setMaxAmountPerTx allows the contract owner to set the maximum allowable transaction amount (MAX_AMOUNT_PER_TRANSACTION) to any value without restriction. This unrestricted control poses a significant risk, as the owner could maliciously or accidentally set this limit to an extremely low value (e.g., 0 or 1 wei). Such a configuration would effectively freeze token transfers, rendering the token unusable and locking user assets within the contract, as practically all standard transfers would exceed this artificially low cap.
Pending
#2 medium Issue
Unbounded Tax Fees
The setBuySellTaxes function allows the contract owner to modify the BUY_TAX and SELL_TAX rates arbitrarily. Critically, there are no upper bounds or validation checks imposed on the _buyTax and _sellTax inputs. This omission permits the owner to set tax rates to 100% (or effectively 10000 basis points in this context) or even higher, which would result in the confiscation of nearly all tokens during a transfer. This creates a potential "honeypot" risk where users can buy tokens but are penalized with exorbitant fees upon selling or transferring them.
low Issues | 2 findings
Pending
#1 low Issue
Missing Events for Critical State Changes
The contract includes several administrative functions that allow the owner to modify critical protocol parameters, specifically setTaxReciever, setMaxAmountPerTx, setBuySellTaxes, and setMaxTotalSupply. However, none of these functions emit events when successful updates occur. This lack of event logging makes it difficult for external monitoring tools, block explorers, and users to track changes to the token's economic policies (taxes) or security constraints (transaction limits) in real-time.
Pending
#2 low Issue
Missing zero or dead address check.
It is recommended to verify that the address cannot be set to zero or a dead address.
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.
Pending
#2 informational Issue
Remove safemath library
The compiler version above 0.8.0 has the ability to control arithmetic overflow/underflow. It is recommended to remove the unwanted code in order to avoid high gas fees.
Pending
#3 informational Issue
Missing Constructor in Upgradeable Implementation
The contract follows the UUPS/Transparent Proxy pattern and correctly uses an initialize function for the proxy's state setup. However, the logic contract (Implementation) lacks a constructor with _disableInitializers(). In OpenZeppelin upgradeable contracts, it is best practice to lock the implementation contract itself during deployment to prevent it from being initialized directly. Without this lock, an attacker could theoretically call initialize() on the logic contract directly (not via the proxy), take ownership of the logic contract implementation, and potentially deceive users or cause confusion, although this does not directly compromise the funds or state held in the actual Proxy contract.