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

Mey Network Info

mey.network

Mey Network is an integrated blockchain ecosystem designed to bridge the gap between physical assets and the digital world. By combining the power of Meychain—a dedicated Layer 1 blockchain for Real-World Assets (RWAs)—and MeyFi, our decentralized nance platform, Mey Network enables seamless tokenization, trading, and management of assets in a secure, scalable environment.

Mey Network Logo
Onboarded date 26/11/2024

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.

16.56
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/10/21
Revision date 2025/10/21

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 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:

  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/remove managers from the contract.
  • The owner or manager can add a new NFT collection for staking.
  • The owner or manager can update an existing NFT collection.
  • The owner or manager can update the APR bonus tier for an NFT collection.
  • The owner can withdraw tokens and ETH from the contract.

Note - This Audit report consists of a security analysis of the StakingNFT 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 MeyNetwork 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
1
Low
2
Optimization
Informational
medium Issues | 3 findings

Acknowledged

#1 medium Issue
The owner can drain reward tokens.
StakingNFT.sol
L1037-1054
Description

The contract contains a severe centralization risk due to the withdrawERC20 function. This function is restricted to the contract owner and allows them to withdraw any amount of any ERC20 token up to the contract's entire balance. Since user rewards are paid in USDC, the owner has the unilateral ability to transfer the entire USDC reward pool to their own wallet at any time. This action would cause all subsequent user attempts to unstake or claimRewards to fail, as the safeTransfer call for their earned rewards would revert due to insufficient funds.

Comments

To mitigate this critical vulnerability, the contract's design must be altered to create a strict separation between funds owned by the protocol and rewards owed to users. This can be achieved by implementing an internal accounting system with a new state variable, such as uint256 public totalPendingRewards, which would track the total amount of rewards accrued but not yet claimed by all stakers. The logic of the withdrawERC20 function must then be fundamentally changed. Instead of allowing the withdrawal of any amount, it should only permit the owner to withdraw "surplus" funds, calculated as the contract's total USDC balance minus the totalPendingRewards.

Alleviation

The project owner has confirmed that this behavior is part of the intended business logic. Therefore, this issue has been formally acknowledged.

Resolved

#2 medium Issue
Architectural Flaw Leads to Denial of Service in unstake
StakingNFT.sol
L476-582
Description

The unstake function in contains a critical architectural flaw in its core logic for locating user tokens. To process an unstake request, the function employs a triply-nested loop that searches through every stake a user has made to find the specific token IDs requested for withdrawal. This design is fundamentally unscalable. As a user interacts with the platform over time and accumulates a larger number of individual stakes, the computational work required by this function grows exponentially. This will inevitably lead to a situation where the gas cost of executing the unstake function exceeds the block gas limit, causing the transaction to fail permanently. This constitutes a Denial of Service vulnerability, not caused by an external factor, but by the contract's own logic, which will result in permanently locking the assets of the most active users.

Comments

To resolve this flaw, the data structure for tracking staked tokens must be re-architected to eliminate the need for a brute-force search. The most effective mitigation is to introduce a new mapping that provides a direct lookup path from a token ID to its specific stake. For example, a mapping like mapping(address => mapping(uint256 => uint256)) public tokenIdToStakeIndex could be implemented. When a token is staked, its stakeIndex would be recorded in this new mapping. During an unstake operation, this would allow the contract to instantly locate the exact stake for each token ID with a single, gas-efficient O(1) read. This change would completely remove the nested loops, ensuring that the unstaking process remains efficient and functional at any scale, regardless of how many stakes a user accumulates.

Resolved

#3 medium Issue
Improper onERC721Received Implementation Leads to Permanent Loss of Staked NFTs
StakingNFT.sol
L1021-1028
Description

The onERC721Received function in StakingNFT.sol is implemented in a way that creates a critical vulnerability for asset loss. The function correctly returns the required ERC721 selector, signaling to other contracts that it can safely receive NFTs. However, its function body is empty and fails to execute any of the essential accounting logic that is handled by the stake function, such as recording the token's owner and updating the user's stake information. This creates a trap for users who might directly transfer their NFTs to the contract using safeTransferFrom. The transfer will succeed, but because no staking records are created, the user will not earn rewards and, more critically, will be unable to call the unstake function to retrieve their asset, as the contract has no record of their deposit. This results in the user's NFT being permanently and irreversibly locked within the contract.

Comments

To prevent the permanent loss of user assets, the onERC721Received function must be modified to reject direct transfers. Instead of returning the success selector, the function should be changed to unconditionally revert the transaction. The revert message should be informative, explicitly stating that direct transfers are not supported and guiding the user to call the proper stake function to deposit their NFTs.

low Issues | 1 findings

Acknowledged

#1 low Issue
Inefficient Code Structure with Multiple Loops
StakingNFT.sol
L399-469
Description

The stake function is structured in a way that causes it to perform multiple, separate passes over the input tokenIds array. The function iterates through the entire array four times: once for the initial duplicate check, a second time to verify token ownership, a third time to execute the safeTransferFrom calls, and a final time to copy the array into memory before storage. This multi-pass approach is inefficient and leads to wasted gas. Each separate loop incurs its own overhead costs for initialization, bounds checking, and counter increments, and it requires redundantly reading the same data from calldata multiple times.

Comments

The most effective way to mitigate this inefficiency is to refactor the function to use a single, consolidated loop. With the exception of the O(n²) duplicate check (which is best addressed by limiting the input array size), all other operations—verifying ownership, transferring the token, and adding the token ID to a memory array—can be performed within a single pass. By processing each tokenId completely before moving to the next, the function can eliminate the redundant loop overhead and reduce the number of reads from calldata. This refactoring would significantly lower the overall gas cost of the stake function, making it more efficient and cost-effective for users.

optimization Issues | 2 findings

Acknowledged

#1 optimization Issue
High Gas Consumption in Duplicate Token ID Validation
StakingNFT.sol
L741-756
Description

The _validateNoDuplicateTokenIds function is designed to prevent a user from staking the same token ID twice within a single transaction. It accomplishes this by using a nested loop that compares every token ID in the input array against every other token ID. This approach results in a computational complexity of O(n²), where 'n' is the number of tokens being staked. The consequence of this inefficiency is that the gas cost required to execute the function grows exponentially with the number of token IDs provided. This creates a potential gas griefing vulnerability, where a malicious actor could intentionally submit a transaction with a large array of token IDs, causing the transaction to consume an excessive amount of gas and inevitably fail.

Comments

The most practical and secure way to mitigate this issue is to introduce a hard limit on the number of tokens that can be staked or unstaked in a single transaction. This can be implemented by defining a constant, for example MAX_TOKENS_PER_TRANSACTION, and then adding a validation at the beginning of the stake and unstake functions to ensure that the length of the input tokenIds array does not exceed this limit. This approach effectively prevents the O(n²) loop from ever being executed with a large, costly array, thereby capping the maximum gas cost for the transaction.

Acknowledged

#2 optimization Issue
High Gas Consumption Due to Inefficient Staker Validation
StakingNFT.sol
L774-815
Description

The _removeCurrentStaker function is designed to remove a user from the currentStakers array after they have unstaked all of their NFTs. Before removing the user, the function verifies that they have no other active stakes remaining. This verification is performed using a highly inefficient, brute-force search that involves nested loops. The outer loop iterates through every NFT collection ever added to the contract, and the inner loop iterates through every individual stake the user has made for that collection. The gas cost of this operation scales directly with the total number of collections on the platform and the number of stakes a user has, which can lead to excessively high and unpredictable gas costs for a user's final unstake transaction.

Comments

To mitigate this, the brute-force search should be replaced with a more efficient tracking mechanism. This can be achieved by introducing a new state variable, such as a mapping mapping(address => uint256) public userActiveStakeCount;. This counter would be incremented every time a user creates a new stake and decremented whenever a stake becomes empty. With this system in place, the expensive nested loops in _removeCurrentStaker can be replaced with a single, gas-efficient O(1) check of the user's active stake count.