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

BurnBuild Info

burn.love

TBA

BurnBuild Logo
Onboarded date 04/09/2025

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.

19.59
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

Select the audit
"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
0xaa46...0Db0
Network
OKXChain Link
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2025/09/04
Revision date 2025/09/04

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.

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 renounced

The contract does not include owner functions that allow post-deployment modifications.

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 contract includes functions that, prior to renouncement, allowed the owner to:

  • The owner can transfer the tokens.
  • The owner can exclude/include wallets from fees.
  • The owner can set any arbitrary value for the tax fee.
  • The owner can set the liquidity fee to any arbitrary value.
  • The owner can set the burn token contract address.
  • The owner can exclude any account from receiving reflection rewards.
  • The owner can manually trigger reward distributions at any time.
  • The owner can approve addresses to spend tokens held by the contract.
  • The owner can transfer ownership to a new address.
  • The owner can renounce ownership, which would make all owner-only functions permanently inaccessible.
  • The owner can temporarily lock the ownership, preventing any changes for a set period.

However, ownership has been renounced. These functions are now permanently disabled, and no changes can be made to the contract’s settings.

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

1
Critical
High
2
Medium
2
Low
1
Optimization
2
Informational
critical Issues | 1 findings

Acknowledged

#1 critical Issue
Core ERC20 Functions Restricted to Owner, Preventing User Token Transfers
BurnBuild.sol
L794-802
L813-821
L823-838
Description

The smart contract critically deviates from the ERC20 token standard by applying an onlyOwner modifier to the transfer(), approve(), and transferFrom() functions. This design flaw effectively freezes all user-held tokens, as only the contract owner has the authority to move them. Consequently, token holders are unable to perform fundamental actions such as sending tokens to other wallets, trading them on decentralized exchanges (DEXs), or using them in other DeFi applications. This centralization of control undermines the principles of token ownership and exposes users to a complete loss of liquidity and utility, as their assets are locked and managed solely at the discretion of the contract owner.

Comments

To resolve this critical issue and align the contract with universally accepted token standards, the onlyOwner modifier must be removed from the transfer(), approve(), and transferFrom() functions. By making these functions public and removing the ownership restriction, the contract will grant users full control over their own tokens. This change will restore standard ERC20 functionality, enabling users to freely transfer and utilize their assets as they see fit, which is essential for establishing trust, enabling market liquidity, and integrating with the broader DeFi ecosystem.

medium Issues | 4 findings

Acknowledged

#1 medium Issue
Missing Access Control on Public payable Function Exposes Reward Mechanism to Manipulation
BurnBuild.sol
L1386-1391
Description

The arriveFeeRewards() function is declared as external and payable without any access control modifiers, such as onlyOwner. This critical oversight allows any external user to call the function at any time and send ETH to the contract. The primary purpose of this function is to trigger the gas-intensive arriveRewards reward distribution logic. By leaving it publicly accessible, the contract is exposed to several risks, including denial-of-service attacks through "gas griefing," where an attacker can repeatedly call the function with minimal ETH to force costly, useless computations. It also allows for uncontrolled and unpredictable manipulation of the reward cycles, which can destabilize the token's economic model and undermine the project's intended strategy for tokenomics.

Comments

To secure the function and ensure the stability of the reward mechanism, it is essential to implement strict access control. The function signature should be modified to include the onlyOwner modifier, restricting its execution to the contract owner. This change will prevent unauthorized external calls, protect against the described manipulation and gas-griefing attacks, and restore control over the timing and funding of reward distributions to the project administrators.

Resolved

#2 medium Issue
The owner can set fees more than 25%.
BurnBuild.sol
L1184-1186
L1187-1189
Description

The setTaxFeePercent() and setLiquidityFeePercent() functions contain a critical vulnerability related to centralized control. These onlyOwner functions lack any input validation to cap the maximum allowable fee percentage. As a result, the owner can set the combined fees to any arbitrary value, including 100% or even higher. If the fees are set to 100%, any user attempting a transfer will have their entire transaction amount confiscated by the contract as fees. If the fees are set above 100%, the underlying subtraction logic will fail, causing all token transfers to revert and effectively freezing all trading activity.

Comments

To mitigate this severe centralization risk, it is essential to implement strict validation within both the setTaxFeePercent() and setLiquidityFeePercent() functions. A require statement should be added to each function to enforce a reasonable maximum fee limit, such as 25%. For example, adding require(taxFee <= 25, "Tax fee cannot exceed 25%"); would prevent the owner from setting excessively high or malicious fees.

Resolved

#3 medium Issue
Missing Contract Existence Check on Critical Address Setter Allows for Denial of Service
BurnBuild.sol
L1250-1252
Description

The setMainToken() function, which allows the owner to set the address for the critical _burnToken contract, fails to verify that the provided addr parameter is a contract address. The function will successfully accept an Externally Owned Account (EOA) address without reverting. However, any subsequent attempt to call the burnToHolder function will fail because the low-level call to the EOA will not execute as expected. This oversight allows for a simple human error (e.g., a copy-paste mistake by the owner) to permanently break the core functionality of the BurnBuild contract, leading to a denial-of-service condition for all users wishing to burn tokens.

Comments

The setMainToken() function must be improved to include a check that validates the provided address is a contract. The contract already imports the Address utility library, which contains an isContract() function for this exact purpose. A require statement should be added at the beginning of the function, like so: require(addr.isContract(), "Address: provided address is not a contract");.

Acknowledged

#4 medium Issue
Missing Non-reentrant check.
BurnBuild.sol
L1303-1317
L1325-1345
Description

The BurnBuild smart contract contains two critical reentrancy vulnerabilities in its core receiveRewards and burnToHolder functions, both of which dangerously violate the Checks-Effects-Interactions security pattern. The receiveRewards function sends ETH to an external address before zeroing out the user's claimable balance, allowing an attacker to recursively call the function to drain the contract's entire ETH holdings. Similarly, the burnToHolder function calls an external _burnToken contract before updating internal reward and share balances, enabling a malicious token contract to re-enter the function and mint an unbounded number of rewards from a single burn action.

Comments

To mitigate these severe risks, both functions must be refactored to ensure all internal state updates (the "Effects") are fully completed before any ETH is sent or any external contract is called (the "Interactions"), thereby closing both attack vectors and securing the contract's assets.

low Issues | 2 findings

Acknowledged

#1 low Issue
Remove safemath library
BurnBuild.sol
L46-108
Description

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.

Acknowledged

#2 low Issue
Local variables shadowing (shadowing-local)
BurnBuild.sol
L810
L908
L911
L912
Description

Rename the local variables that shadow another component.

optimization Issues | 1 findings

Acknowledged

#1 optimization Issue
Gas Inefficiency and Obfuscated Logic in Reward Distribution Mechanism
BurnBuild.sol
L1397-1399
Description

The arriveRewards function implements a highly inefficient and opaque method for triggering the token's reflection mechanism. Instead of using a direct and clear accounting function, it initiates a three-step token shuffle: transferring funds from the contract to a temporary address, then to a second temporary address, and finally back to the contract. Each of these transfers is a separate, gas-consuming operation on the blockchain. This convoluted process serves only to trigger the internal _reflectFee function multiple times in a roundabout way. This design is a significant flaw as it incurs excessive and unnecessary gas costs, which ultimately drains project or user funds. Furthermore, the non-standard and deliberately obscure logic undermines the contract's transparency and trustworthiness, making it difficult for auditors and users to verify its behavior and intent.

Comments

The contract should be refactored to eliminate the wasteful three-transfer process. The arriveRewards function should be rewritten to directly and transparently call the internal reward accounting functions. Instead of forcing token transfers, it should calculate the intended reflection amount (rFee and tFee) based on the increase parameter and then call the internal _reflectFee function a single time with these values.

informational Issues | 2 findings

Acknowledged

#1 informational Issue
Floating pragma solidity version.
BurnBuild.sol
L3
Description

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.

Acknowledged

#2 informational Issue
Function that are not used (Dead code).
BurnBuild.sol
L10
L124
L138
L153
L363
L390
Description

Remove unused code.