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

GoldFinger Info

goldfinger.finance

GoldFinger is an innovative platform committed to bridging premium yield-generating real-world assets (RWA) with the Web3 ecosystem. The convergence of blockchain technology and traditional finance is reshaping how real-world assets (RWA) are accessed, managed, and traded. By leveraging decentralized networks, transparency, and programmable smart contracts, it is now possible to unlock the liquidity and efficiency of high-quality, yield-generating assets—such as commodities, real estate, and financial instruments—within the Web3 ecosystem.

GoldFinger Logo
Onboarded date 12/11/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.

18.69
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
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2025/11/13
Revision date 2025/11/13

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 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 add or remove admins from the contract.
  • The owner can set the fee recipient address.
  • The owner can set the early penalty percentage up to 100%.
  • The owner can toggle the staking availability by term.
  • The owner or admins can fund ART tokens, in which 5% will be sent to the investor and 95% will be staked.
  • The owner can allocate the private sale with a permit.
  • The owner or admin can pause the staking and claiming functionality in the contract.
  • The owner can unpause the staking and claiming functionality in the contract.
  • The owner can rescue tokens and ETH from the contract.

Note - This Audit report consists of a security analysis of the GFStaking 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 GoldFinger 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
1
Medium
Low
Optimization
1
Informational
high Issues | 1 findings

Resolved

#1 high Issue
Centralized Pausing Power Creates Full Custodial Risk Over All Staked Assets and Rewards
GFStaking.sol
L1212
Description

The core user-facing functions withdraw, earlyWithdraw, and claimRewards are all protected by the whenNotPaused modifier. This grants owner and admin accounts the unilateral and immediate power to block all users from accessing their staked principal and their earned rewards. The protocol does not include any time limit on this pause, meaning an administrator could freeze all withdrawals and reward claims for an indefinite period. This functionality centralizes an extreme level of control, effectively transforming the staking contract into a custodial wallet where users' funds can be held hostage at any time. A malicious or compromised administrator could exploit this to permanently trap all user assets and rewards within the contract.

Comments

The power to pause the contract's core functionalities must be decentralized and time-bound. This authority should be transferred from a single owner/admin to a secure multi-signature committee or a formal governance contract with a mandatory time lock on all proposals. Crucially, any pause action must have a strictly enforced maximum duration (e.g., 7 days), after which the system automatically unpauses. This ensures that pausing is a transparent, community-approved emergency measure, not a permanent control mechanism that can be used to seize user funds.

Alleviation

The project owner has acknowledged the centralization concern. To address this, the ownership of the contract will be assigned to a multi-signature wallet. As the owner will be a multi-signature wallet, the issue is considered resolved.

medium Issues | 2 findings

Acknowledged

#1 medium Issue
Owner Can Set Early Withdrawal Penalty to 100%, Enabling Seizure of User Funds
GFStaking.sol
L457-463
Description

The setEarlyPenaltyBps function is an onlyOwner privileged function that allows the owner to configure the penalty for early withdrawals from locked staking positions. The function's only validation check allows the penalty to be set as high as 100% (10000 basis points). This creates a critical centralization risk. A malicious or compromised owner could set the penalty to 100% and then change other parameters to incentivize users to withdraw early, effectively tricking them into forfeiting their entire staked principal. When a user calls the earlyWithdraw function, their entire withdrawal amount would be calculated as a penalty and sent to the owner-controlled feeRecipient, resulting in a direct and total loss of the user's funds for that position.

Comments

To prevent this risk, the setEarlyPenaltyBps function must be constrained with a reasonable upper limit. A MAX_EARLY_PENALTY_BPS constant should be introduced (e.g., 2500 for 25%), and the function must be modified to include a require statement that prevents the owner from setting a penalty higher than this predefined, sensible maximum. This would preserve the function's purpose of discouraging early withdrawals without turning it into a mechanism for seizing user assets.

Resolved

#2 medium Issue
The owner can claim the staked tokens
GFStaking.sol
L1216-1219
Description

The GFStaking contract is designed to act as a custodian for user-deposited ARTToken and GFToken assets. However, the contract includes a generic rescueERC20 function that gives the owner the unilateral and unchecked power to withdraw the entire balance of any ERC20 token held by the contract. This function does not differentiate between accidentally sent tokens and the staked assets it is explicitly meant to protect. This creates a critical vulnerability where a malicious or compromised owner can call rescueERC20 with the ARTToken and GFToken addresses to drain 100% of all staked funds from the contract into their own wallet, allowing for the direct theft of all user deposits.

Comments

The rescueERC20 function is dangerously overpowered for a contract that holds user-staked assets. It must be modified to explicitly prevent the withdrawal of the core staked tokens. A require statement must be added to the function, such as require(token != address(artToken) && token != address(gfToken), "Cannot rescue staked tokens");. This will preserve the function's ability to recover accidentally sent assets while closing the backdoor that allows for the theft of all user funds.

informational Issues | 2 findings

Resolved

#1 informational Issue
Floating pragma solidity version.
GFStaking.sol
L2
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.

Pending

#2 informational Issue
Minor Precision Loss in Reward Calculation Leads to Fewer Rewards Distributed Than Intended
GFStaking.sol
L904-924
Description

The _updatePoolReward function calculates the rewardPerSecond by dividing the total annualReward by the number of seconds in a year (365 days). Due to the nature of integer division in Solidity, any fractional remainder from this calculation is truncated and permanently lost every second. While the financial impact of this precision loss is minimal (estimated to be less than 0.0005% of the total annual rewards), it creates a discrepancy between the protocol's documented emission rates and the actual amount of rewards distributed on-chain. Over the 10-year lifetime of the incentive program, this will result in a small but measurable amount of rewards being perpetually locked in the emission pool instead of being distributed to stakers as intended.

Comments

To ensure that the full intended rewards are distributed, the calculation logic should be reordered to minimize the impact of integer division. Instead of calculating a rewardPerSecond, the function should first calculate the total emitted rewards by multiplying the annualReward by the elapsed time, and only then perform the division by the number of seconds in a year. The corrected calculation would be: uint256 emitted = (annualReward * elapsed) / (365 days);. This performs the multiplication first, preserving precision and ensuring the reward calculation is mathematically sound and aligns with the protocol's stated economic parameters.