Audit name:
[SCA] Neyro | Neyro SC | May2026
Date:
May 27, 2026
Table of Content
Introduction
We express our gratitude to the Neyro team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Neyro is a streamlined liquidity management solution, designed to automate USDT deposits into PancakeSwap V3 positions on BNB Smart Chain through a role-based operator mechanism.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Neyro |
| Audited By | Olesia Bilenka |
| Approved By | Khrystyna Tkachuk |
| Website | https://neyro.network/→ |
| Changelog | 13/05/2026 - Preliminary Report |
| 25/05/2026 - Final Report | |
| Platform | BNB Smart Chain |
| Language | Solidity |
| Tags | Centralization; Token Standards used: ERC-20; Market Maker; Vault |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Neyro
- Audited By
- Olesia Bilenka
- Approved By
- Khrystyna Tkachuk
- Website
- https://neyro.network/→
- Changelog
- 13/05/2026 - Preliminary Report
- 25/05/2026 - Final Report
- Platform
- BNB Smart Chain
- Language
- Solidity
- Tags
- Centralization; Token Standards used: ERC-20; Market Maker; Vault
Review Scope | |
|---|---|
| Repository | https://bscscan.com/address/0xE197f1229f7625D74780F1F6Be2B9552566FA1e0#code→ |
| Remediation Repository | https://bscscan.com/address/0xAEB9d9B2e38270f18999cDae3de8Ac82A0D6087e#code→ |
| Commit | - |
Review Scope
- Remediation Repository
- https://bscscan.com/address/0xAEB9d9B2e38270f18999cDae3de8Ac82A0D6087e#code→
- Commit
- -
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are not provided.
Technical description is not provided.
NatSpec comments are absent in the main contract.
No inline documentation explaining the intended workflow or assumptions.
Expected behavior for edge cases is not documented.
Code quality
The codebase demonstrates a minimalist approach with a small attack surface:
Utilizes well-audited OpenZeppelin contracts for access control (AccessControl v5.6.1).
Proper dependency management via package imports instead of flattened file structure.
Clear separation between admin and operator responsibilities.
Event emission implemented for core liquidity operations.
SPDX license identifier present.
SafeERC20 library is declared but not consistently utilized for all token operations.
NatSpec documentation is absent.
Floating pragma used instead of locked compiler version.
Test coverage
Code coverage of the project is 0% (branch coverage).
No test suite was provided by the client.
System Overview
Neyro is a liquidity management protocol designed to automate USDC deposits into PancakeSwap V3 positions on BNB Smart Chain. The protocol consists of the following contract:
Neyro_USDC — a role-based liquidity depositor that manages a single PancakeSwap V3 position. The contract holds USDC and, upon operator command, deposits the entire balance into a preconfigured liquidity position. The contract dynamically determines token ordering within the position and applies slippage protection on deposits.
The contract interacts with:
USDC (
0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d) — USD Coin on BNB Smart ChainPancakeSwap V3 NonfungiblePositionManager (
0x46A15B0b27311cedF172AB29E4f4766fbE7F4364) — external contract for managing V3 liquidity positions
Privileged roles
DEFAULT_ADMIN_ROLE: Can configure the target position (
tokenId) and manage operator permissionsOPERATOR_ROLE: Can trigger liquidity deposits via the
loopfunction
Potential Risks
Centralization of admin control: A single DEFAULT_ADMIN_ROLE holder has unilateral authority to configure the target position and manage operators. Compromise of this key grants full control over contract configuration with no timelock or multi-signature protection.
External protocol dependency: The contract is permanently bound to hardcoded PancakeSwap V3 PositionManager and BSC USDC addresses. Any deprecation, migration, or security incident in these external dependencies would render the contract non-functional.
Position NFT ownership ambiguity: The contract's fund recoverability depends entirely on who owns the position NFT. If the NFT is transferred to the Neyro_USDC contract address, deposited liquidity and accumulated fees become permanently inaccessible due to missing withdrawal functions.
USDC blacklist exposure: If USDC's blacklist mechanism is applied to the Neyro_USDC contract address, all held USDC becomes trapped. The contract can receive tokens but PositionManager's transferFrom would revert, with no alternative withdrawal path.
Single-sided deposit assumption: The contract is designed for single-sided liquidity provision only. If the position's current tick requires dual-sided deposits, the transaction will fail or result in zero liquidity added.
Irrecoverable admin renunciation: The inherited renounceRole function allows the admin to permanently abandon control. If executed without first transferring the role, the contract becomes frozen with no ability to update configuration or manage permissions.
No token rescue mechanism: Tokens sent to the contract that cannot be deposited through the intended flow—whether due to position constraints or accidental transfers of non-USDC assets—remain permanently locked with no administrative recovery function.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1701 | Token Order Assumption May Cause Complete Deposit Failures | fixed | Medium | |
| F-2026-1700 | Single-Sided Liquidity Assumption May Cause Deposit Failures | accepted | Medium | |
| F-2026-1701 | Return Values from increaseLiquidity Are Ignored | fixed | Low | |
| F-2026-1700 | Unlimited Token Approval Granted to External Contract on Deployment | fixed | Low | |
| F-2026-1700 | Zero Slippage Tolerance in loop Function Leads to Frequent Transaction Reverts | fixed | Low | |
| F-2026-1702 | Missing SPDX License Identifier in Main Contract | fixed | Observation | |
| F-2026-1702 | Floating Pragma and Version Mismatch with Flattened Dependencies | mitigated | Observation | |
| F-2026-1701 | No Validation That Position Involves USDT Token | mitigated | Observation | |
| F-2026-1701 | Uninitialized tokenId Allows Calls to Invalid Position | mitigated | Observation | |
| F-2026-1701 | Unchecked Return Value of approve Call in Constructor | accepted | Observation |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://bscscan.com/address/0xE197f1229f7625D74780F1F6Be2B9552566FA1e0#code→ |
| Remediation Repository | https://bscscan.com/address/0xAEB9d9B2e38270f18999cDae3de8Ac82A0D6087e#code→ |
| Commit | - |
| Whitepaper | - |
| Requirements | - |
| Technical Requirements | - |
Scope Details
- Remediation Repository
- https://bscscan.com/address/0xAEB9d9B2e38270f18999cDae3de8Ac82A0D6087e#code→
- Commit
- -
- Whitepaper
- -
- Requirements
- -
- Technical Requirements
- -
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.
Frameworks and Methodologies
This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.