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.

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 add or remove an admin from the contract.
  • The owner or admin can set the different allocation addresses.
  • The owner or admin can execute the initial distribution.
  • The owner or admin can create a vesting schedule.
  • The owner or admin can revoke the vesting schedule.
  • The owner or admin can do the custom distribution with a category cap, single, or in batches.
  • The owner or admin can create a custom token lockup for a specific user from pre-allocated funds.
  • The owner or admin can unlock the tokens for the users.
  • The owner or admin can cancel the lock.
  • The owner or admin can pause the vesting, distribution, and withdrawal functionalities in the contract.
  • The owner can unpause the vesting, distribution, and withdrawal functionalities in the contract.
  • The owner can rescue the tokens and ETH from the contract.

Note - This Audit report consists of a security analysis of the GFDistributor 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
Informational
high Issues | 1 findings

Resolved

#1 high Issue
The owner can withdraw the locked tokens
GFDistributor.sol
L973-97
Description

The GFDistributor contract's "Lock Pool" feature is designed to act as a custodian for user funds, holding GFTokens that are time-locked for specific beneficiaries via the allocateAndLockForUser function. However, the contract also 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 locked assets it is explicitly meant to protect. This creates a critical vulnerability where a malicious or compromised owner can call rescueERC20 to drain 100% of the locked GFTokens from the contract into their own wallet, stealing all assets from the Lock Pool and causing a total loss for those beneficiaries.

Comments

The rescueERC20 function is dangerously overpowered for a contract that custodies user funds and must be modified. To close this backdoor while retaining the function's utility, a require statement must be added to explicitly block the withdrawal of the contract's primary custodial token. The check should be: require(token != address(gfToken), "Cannot rescue locked tokens");. This will prevent the theft of user funds while still allowing the owner to recover other, accidentally sent tokens.

medium Issues | 3 findings

Resolved

#1 medium Issue
Uncapped Emergency Minting Function Allows for Infinite Token Creation
GFDistributor.sol
L591-501
Description

The emergencyDistribution function is a privileged onlyAdminOrOwner function that allows for the arbitrary minting of GFTokens. Crucially, this function lacks any form of cap or limit. It does not check against the per-category allocations, nor does it check against the GFToken's own TOTAL_SUPPLY. This creates a backdoor that allows an administrator to mint an infinite number of tokens, completely breaking the token's hard-coded economic policy. A malicious or compromised administrator could exploit this function to create a trillion tokens for themselves and dump them on the market, instantly crashing the token's value to zero and destroying the entire project economy.

Comments

This function is too dangerous as written and must be fundamentally redesigned or removed. To mitigate this risk, the function must first be modified to respect the project's tokenomics by adding a call to the _checkCategoryCap function, ensuring that any emergency mint is accounted for within a specific allocation. More importantly, the unilateral power to perform an emergency mint must be decentralized. This authority should be transferred from a single owner to a secure, time-locked multi-signature wallet or a formal governance contract. This would ensure that any emergency minting is a transparent, publicly announced event that requires the consensus of multiple parties or a community vote, preventing a single individual from unilaterally breaking the token's supply cap.

Resolved

#2 medium Issue
Centralized Pausing Power Can Indefinitely Block Users from Withdrawing Locked Tokens
GFDistributor.sol
L969
Description

The withdrawLock function, which is the primary mechanism for a user to claim their tokens from the Lock Pool after the lock duration has expired, is protected by the whenNotPaused modifier. This gives owner and admin accounts the unilateral ability to block users from withdrawing their own matured, unlocked assets. The protocol does not include any time limit on this pause functionality. This creates a significant centralization risk where a malicious or compromised administrator could indefinitely prevent all users from accessing their rightful funds by keeping the contract paused, effectively holding the assets hostage and converting a non-custodial lock into a fully custodial one.

Comments

The ability to pause a core user function like withdrawLock must be decentralized and time-bound. This authority should be transferred from a single owner to a secure multi-signature committee or a formal, time-locked governance contract. 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 only a transparent, temporary emergency measure and cannot be used as a tool to permanently deny users access to their own 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.

Pending

#3 medium Issue
Administrators Can Revoke User Locks, Clawing Back Promised Funds
GFDistributor.sol
L718-733
Description

The contract's "Lock Pool" feature allows admins to lock tokens for users. However, the adminCancelLock function gives an owner or admin the unilateral power to cancel a user's lock at any time before the user has withdrawn it. When a lock is cancelled, the funds are not returned to the user; they are sent back to the original category allocation wallet. This means that a user who has been granted a time-locked allocation of tokens has no on-chain guarantee they will ever receive them. They are subject to the risk that an administrator can revoke their grant at any point, effectively clawing back the promised funds.

Comments

The adminCancelLock function on line 718 is onlyAdminOrOwner and transfers the locked funds to the allocationAddress[l.category] on line 731, not to the l.user.

informational Issues | 1 findings

Resolved

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