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 or remove managers from the contract.
  • The owner or manager can update the NFT pool parameters.
  • The owner or manager can update the details of an existing phase in the contract.
  • The owner or manager can update the whitelist operator.
  • The owner or manager can update the BaseURI in the contract.
  • The owner can withdraw the migration fees from the contract.
  • The owner or manager can set a maximum number of NFTs a lender can whitelist in a phase.
  • The owner or manager can add/remove multiple lenders from whitelisted mapping.
  • The owner can withdraw tokens or ETH from the contract.

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

Acknowledged

#1 high Issue
Ineffective "Trade Lock" Feature Due to Incomplete Implementation
PTO.sol
L1-1136
Description

The contract includes a feature intended to prevent the trading of newly minted NFTs until a specified tradeUnlockTime. However, this security measure is completely ineffective due to a flawed implementation. The code only restricts the approve and setApprovalForAll functions, operating under the incorrect assumption that these approvals are a prerequisite for all transfers. It fails to override the core ERC721 transfer functions, transferFrom and safeTransferFrom. As a result, any NFT owner can easily and completely bypass the trading lock by directly calling transferFrom on their token, which does not require any prior approval. This renders the trade lock feature useless and creates an unfair environment where only technically sophisticated users can trade their assets before the designated unlock time.

Comments

To correctly and robustly enforce the trading lock, the contract must be modified to override all functions that can change token ownership. The time lock validation logic—require(block.timestamp >= pool.tradeUnlockTime)—must be added to the transferFrom, safeTransferFrom(address,address,uint256), and safeTransferFrom(address,address,uint256,bytes) functions. By placing this check within the core transfer functions themselves, the contract will ensure that the rule is applied universally to all types of transfers, whether initiated by the owner directly or by a third-party marketplace. This will make the feature function as intended and guarantee that the trading restriction is enforced fairly for all participants.

Alleviation

The project owner confirmed that the trading lock rule is designed to restrict secondary market sales (e.g., OpenSea, Blur, etc.) before tradeUnlockTime, but it does not prevent users from transferring tokens directly between wallets.

medium Issues | 3 findings

Resolved

#1 medium Issue
Whitelisted Users Blocked from Funding in Phases Without Tiers
PTO.sol
L465-538
Description

A vulnerability exists in the fundLoan function that prevents whitelisted users from participating in sale phases that are configured without a tier-based structure. This issue arises when a phase is set up for whitelisted participants only, meaning its tierLimits array is intentionally left empty. The _getLenderStatusInCurrentPhase function correctly identifies a whitelisted user but incorrectly returns a default tierLimitIndex of 0. The fundLoan function then uses this index to access the empty tierLimits array, causing an out-of-bounds error that reverts the entire transaction. This flaw makes it impossible to run a whitelist-only funding round, directly contradicting a likely business requirement and blocking eligible investors.

Comments

To resolve this, the logic within the fundLoan function must be modified to conditionally update tier-related state. The line that accesses the tierLimits array and updates a tier's nftsReserved count should be wrapped in a conditional block. This block should only execute if the participating user is not on the whitelist, thereby ensuring that their eligibility is derived from a staking tier. This change decouples the execution path for whitelisted users from the tier-based logic, allowing both types of participants to fund loans correctly according to the specific configuration of any given phase.

Acknowledged

#2 medium Issue
Pool Parameters Can Be Changed Mid-Sale, Breaking Contract Logic
PTO.sol
L605-641
Description

A critical vulnerability exists in the setPoolParams function, which allows a privileged administrator to modify core economic parameters of the sale, such as pricePerNFT, after the sale has already commenced. The function lacks a crucial check to prevent execution once block.timestamp has surpassed pool.startTime. This flaw enables a malicious or accidental change to the sale's fundamental rules while users are actively participating. Changing the price mid-sale corrupts the contract's internal accounting, particularly how it calculates available funding inherited from previous phases, which can lead to a permanent loss of sale allocation and break the financial integrity of the system.

Comments

To prevent this vulnerability, the setPoolParams function must be restricted to only execute before the sale begins. This can be achieved by adding a requirement at the start of the function that checks if block.timestamp is less than pool.startTime (and that pool.startTime has been set). If the sale has already started, the function must revert, thereby locking in the economic parameters for the entire duration of the event.

Alleviation

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

Acknowledged

#3 medium Issue
Phase Parameters Can Be Changed While Active or After Completion
PTO.sol
L656-687
Description

A vulnerability exists in the updatePhase administrative function, which allows a manager or owner to modify the parameters of a sale phase at any time, even while the phase is active or after it has already concluded. The function lacks a necessary time-based check to prevent changes to a phase that has already started. This allows for the unilateral alteration of fundamental rules, such as a phase's endTime or its funding cap (maxUSDC), mid-sale. Such actions can lead to an inconsistent contract state, abruptly and unfairly end participation, and introduce a significant centralization risk, fundamentally undermining the trust and predictability of the sale process.

Comments

To secure the function, it must be restricted from altering any phase that is no longer in the future. A check should be implemented at the beginning of the updatePhase function to verify that block.timestamp is less than the startTime of the phase being modified. If the phase has already commenced, the transaction must revert.

Alleviation

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

low Issues | 1 findings

Acknowledged

#1 low Issue
Missing Input Validation in initialize Function
PTO.sol
L278-311
Description

The initialize function in PTO.sol is responsible for setting the initial state of the contract. Currently, it lacks validation for several critical parameters, including the addresses for _usdcToken and _stakingTierManager, as well as key values within the _pool and _phases structs. Deploying the contract with invalid inputs, such as a zero address for a required contract or illogical time ranges (e.g., endTime before startTime), could lead to a permanently misconfigured state. This could render the contract's core functionality inoperable, cause transactions to revert unexpectedly, or create economic vulnerabilities.

Comments

To mitigate this risk, comprehensive input validation should be added to the initialize function. This involves implementing checks to ensure that address parameters like _usdcToken and _stakingTierManager are not address(0). Furthermore, the function should validate the _pool parameters to confirm that pricePerNFT is non-zero, startTime is before endTime, and fee basis points do not exceed the maximum allowed value. Finally, when iterating through the _phases array, each phase should be checked to ensure its own startTime is less than its endTime.

optimization Issues | 1 findings

Acknowledged

#1 optimization Issue
Inefficient Calculation Leads to Rising Gas Costs for Users
PTO.sol
L821-868
Description

The _getCurrentPhaseStatus function contains a design flaw that causes transaction costs to increase over time for users. The function includes a feature to "roll over" any unsold USDC allocation from previous phases to the current one. This is implemented with a for loop that iterates backward from the current phase through all preceding phases, performing a calculation at each step to determine the total inherited amount. Because this function is called by the core fundLoan function, the gas cost for a user to participate in the sale will increase linearly with the number of phases that have passed.

Comments

To resolve this inefficiency, the on-the-fly recalculation of the rolled-over allocation should be replaced with a more efficient state-tracking mechanism. Instead of a loop, the contract should use a state variable, for example uint256 public cumulativeUnsoldAllocation, to keep track of the total unsold amount from all previous phases. An administrative function could be added that, after a phase concludes, is called once to calculate the unsold amount from that specific phase and add it to the cumulative total. The _getCurrentPhaseStatus function can then simply read this state variable to get the inherited amount, ensuring that the gas cost to fund a loan remains low and consistent for all users, regardless of which phase they participate in.

informational Issues | 1 findings

Acknowledged

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