ForgeBTC Info
ForgeBTC is a digital Bitcoin mining platform that eliminates the complexity and high costs of traditional mining. We provide institutional-grade mining infrastructure accessible to everyone—from $50 investments to enterprise-scale operations.
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.
Security Assessments
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:
- 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 proposeRate(uint256 newRate) to schedule a future change to the staking reward APY.
- The owner can setRate() to apply the new proposed rate, but only after waiting 1 full day from the proposal time.
- The owner can recoverERC20() to withdraw any WBTC from the contract that is not needed for the user principal or funded rewards (excess only).
- The owner can addSupply(uint256 amount) to deposit WBTC into the contract specifically for funding future reward payouts.
- The owner can transferOwnership(address newOwner) to hand over administrative control to another wallet or multi-sig.
- The owner can renounceOwnership() to permanently remove all administrative access, making the contract immutable.
Note - This Audit report consists of a security analysis of the WBTCStaking 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 ForgeBTC 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
Resolved
#1 high Issue
Hostage Funds (Insolvency Lock)
The contract still couples the withdrawal of principal with the claiming of rewards, leading to a critical flaw. While the updated logic attempts to prevent a revert by checking addedValue <= totalSupply, it introduces a new, equally severe issue: if the contract is insolvent (i.e., addedValue > totalSupply), the reward payment is silently skipped entirely. The function then proceeds to delete userStakes[_msgSender()], which permanently erases the user's accrued rewards without transferring them. The user receives their principal back but unknowingly forfeits all interest earned. Worse, because _updateCusum is only called inside the conditional _claim, skipping it means the global reward accumulator (cusum) is never updated for the duration of that user's stake. This corrupts the reward calculations for all other users in the system, effectively "stealing" the yield generated during that time period from the entire protocol.
medium Issues | 2 findings
Resolved
#1 medium Issue
Token Decimal & Precision Mismatch
The contract hardcodes MAX_PERCENTAGE (formerly PRECISION) to $10^{18}$ (18 decimals), assuming an Ethereum-standard token. However, WBTC uses 8 decimals. This 10-order-of-magnitude mismatch creates severe rounding issues. For users with small stakes (e.g., 1000 Satoshis or 0.00001 WBTC), the reward calculation (stake * rate * time) / 10^18 will consistently truncate to zero because the numerator is too small relative to the high-precision divisor. While not a loss of funds for large whales, it effectively "censors" small retail users from earning any yield, despite their capital being locked. Additionally, this forces administrators to input rates scaled to 18 decimals, increasing the risk of "fat finger" errors where rates are set $10^{10}$ times too low or high.
Resolved
#2 medium Issue
Centralized Rate Control Risk
The contract has been partially patched to include a 1-day timelock (proposalTime + 1 days) and a nominal MAX_PERCENTAGE check. However, the MAX_PERCENTAGE is effectively 100% APY, which is still perilously high for an asset like WBTC. While the timelock mitigates the "Instant Rug Pull," the owner still retains significant power to alter the rate drastically (e.g., from 1% to 100%) without explicit user consent or a "grace period" that pauses deposits during the transition. Furthermore, the timelock can be reset or overridden by proposing a new rate immediately after the old one expires if the admin is persistent.
low Issues | 2 findings
Resolved
#1 low Issue
EVM Opcode Incompatibility
The contract uses the ReentrancyGuardTransient modifier, which relies on TLOAD and TSTORE opcodes (EIP-1153) only available in the "Cancun" hardfork (March 2024). Example: You deploy this contract to an "Optimistic Rollup" L2 or a private enterprise chain that is running an older EVM version (e.g., "Paris"). The deployment succeeds, but when the first user calls stake(), the transaction reverts with an "Invalid Opcode" error because the chain doesn't know what TSTORE is.
Resolved
#2 low Issue
Redundant Precision Math
The code does cusum_ += (_getAddedValue(...) * PRECISION) / 10**18; where PRECISION is 10**18. Multiplying then dividing by the same scalar is a no-op, just burns gas each time cusum updates. No security impact; purely inefficiency.
informational Issues | 3 findings
Resolved
#1 informational Issue
Fee-On-Transfer Insolvency
The contract assumes that amount sent equals amount received. It increases the user's ledger balance by amount before verifying the actual tokens received. If the token has a transfer fee (common in bridged tokens or deflationary mechanics), the contract becomes insolvent immediately. Example: Alice stakes 100 "Fee-BTC". The token takes a 1% tax. The contract receives 99 tokens but credits Alice with 100. The contract now has a liability of 100 but assets of 99. The last user to withdraw will find the vault empty.
Resolved
#2 informational Issue
No Emergency Escape Hatch
The contract lacks a recoverERC20 or emergencyWithdraw function. If funds get stuck due to a logic bug (like the "Hostage Funds" issue) or an external token issue, they are lost forever. Example: The "Hostage Funds" bug triggers, and 50 WBTC are locked. The owner wants to help by withdrawing the funds and manually refunding users, but they physically cannot touch the tokens because there is no function to do so.
Resolved
#3 informational Issue
addSupply Fee-On-Transfer Vulnerability
While stake was fixed, the new addSupply function (used by the owner to fund rewards) suffers from the same original "Fee-On-Transfer" bug. It increases totalSupply by the amount sent, without verifying the actual amount received. If the reward token has a transfer fee, the totalSupply variable will inflate beyond the actual contract balance, misleading the solvency check in withdraw and potentially causing reverts when users try to claim rewards that don't physically exist.